Subject: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02

From: Paco Cortes <[email-masked]>
Date: Thu, 28 Jul 2011 14:08:02 +0200

Hi Wojciech,

two comments on the 3gpp sections of draft-dec-stateless-4v6-02.

First, the definition of "Rx" is missing in section 4.2.1.

Second, the table in section 4.2.2 claims "No discernible impact" for
"AF Application Function" for the 4V6 translation mode. This is not
fully correct.
The PCC architecture support a plurality of AFs communication over Rx
with the PCRF, and most of them "interact" in some way with the end
user payload.
An AF might terminate, proxy or transparently inspect a subset of the
UE traffic (for instance control signalling, like SIP).
An AF might also terminate, proxy or transparently inspect all UE
traffic (application server acting as AF, deep packet inspection
device, ...).
And the most important point: An AF might located in different
locations inside the operators networks, or even outside the operators
network.
Referring to your own "Figure 2" in the draft, this means that for
IPv4 traffic an AF might "intercept" traffic between the "PDN-Gw" and
the "S46 Gateway", i.e. with an IPv6 header, BUT it might also
intercept traffic behind the "S46 Gateway", i.e., with an IPv4 header.

I propose to change the impact to "No impact for IPv6. Feature to map
IPv4-IPv6 addresses may be needed only in case of  IPv4-only
applications".

I'm aware that it would be theoretically possible to "hide" this
impact from an AF by using a more complex PCRF implementation that
"translates" IPv4 addresses in Rx message (including TFTs) into the
mapped IPv6, but this would imply limitations, and would just be one
implementation possibility. I believe that this draft should not
assume a specific implementation, unless clearly documented.

br,
  Paco

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 28 Jul 2011 06:57:33 -0700

> assume a specific implementation, unless clearly documented.

+1, I believe this section causes confusion.

I have not had time to do a full review.

Tunneling traffic breaks pcc and a new bearer type is a tall order. We
already visited these issues when concluding 6rd and ds-lite were not good
fits for 3gpp.

Cb

> br,
>  Paco
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Hui Deng <[email-masked]>
Date: Thu, 28 Jul 2011 13:46:52 -0400

Hi Paco,

To have such complicated DPI functionality in the network is totally out of
scope of IETF.
I don't think IETF should discuss this type of complicated DPI here.

Best regards,

-Hui

2011/7/28 Paco Cortes <[email-masked]>

---

From: Hui Deng <[email-masked]>
Date: Thu, 28 Jul 2011 13:48:16 -0400

Hi Cameron,

You may need spend time to review it later, it's different from 6RD and
DS-Lite,

Secondly, I am wondering whether it could fit for mobile CPE case.

Best regards,

-Hui

2011/7/28 Cameron Byrne <[email-masked]>

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 28 Jul 2011 14:42:33 -0700

> You may need spend time to review it later, it's different from 6RD and

I just now read it in more detail.  My first piece of feedback is that
it is too long :)  I assume future revisions will be more tight.  I
would also say that the translation part be put into a separate draft
that goes to BEHAVE.

I believe the mapped mode has some similar challenges in mobile as
DS-lite.  It is an IP in IP tunnel.  It is really a non-starter in
3GPP networks as the draft amply notes.  I believe it is best to state
that clearly for the 3GPP case, and move on without elaboration.

The translation mode looks like NAT464, and i like it NAT464 + DNS64
since it solves a real problem, as noted here
http://www.ietf.org/mail-archive/web/behave/current/msg09480.html

Is the reference to RFC6053 right?

"The operation of the 4V6 CE and
   gateway are very similar, if not identical, to that of stateless
   NAT64 as specified in RFC 6053."

So is this right?

CPE/UE (NAT46) --->ipv6 only network--> NAT64 (stateless port restricted)

And the port-set is delivered via some encoding in the IPv6 address
assigned to the UE?  This is clever.  I remain concerned about being
able to engineer stateless port allocations that sufficiently meet
everyone's needs with a limited free public IPv4 pool vs. dynamic
allocation.  I do not have much experience with stateless LSN, i am
not sure anyone has much experience at scale with port restricted
stateless?  I believe there are ways of going beyond 65k ports per
IPv4 address in stateful, what about in stateless?  I think this will
be a requirement as the IPv4 pool keeps getting stretched thin.

Right now, i feel like it would be easier for the IETF to just define
NAT464 in general and stateless translation 4V6 is a flavor of NAT464.

I understand the allure of stateless.  But, IMHO the address
multiplexing of stateful is very useful and many large SPs already run
this way, and that operational experience is very important.  The IPv6
transition space is becoming very crowded, i personally would like to
see more work to make IPv6 a true replacement for IPv4 instead of yet
another transition mechanism that meets some set for checkboxs.

This architecture is complicated.

CB

---

From: Hui Deng <[email-masked]>
Date: Fri, 29 Jul 2011 07:18:59 -0400

Hi Cameron.

Inline please,

> ==>I think your observation is correct.

> ==>the scenario is right,  for port assignment,
2000 ports assignment per user would be fine? the algorithm allow dynamic
port assignment.

> ==> stateless 464 is good in his own environment, it may not be able to
compatible with NAT64 or others, stateful 464 has advantage which could work
with others, will see.

-Hui

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 29 Jul 2011 09:48:35 -0400

Cameron,

> http://www.ietf.org/mail-archive/web/behave/current/msg09480.html

I don't understand why is DNS64 needed with NAT464. Could you elaborate it?

>   NAT64 as specified in RFC 6053."

I think that it should be RFC6052.

> another transition mechanism that meets some set for checkboxs.

Stateless is not exclusive with stateful one, and also NAT64.
I agree with Hui.

cheers,
--satoru

---

From: Xing Li <[email-masked]>
Date: Fri, 29 Jul 2011 21:58:45 +0800

? 2011/7/29 19:18, Hui Deng ??:
> ==> stateless 464 is good in his own environment, it may not be able 
> to compatible with NAT64 or others, stateful 464 has advantage which 
> could work with others, will see.

FYI, the dIVI 
(https://datatracker.ietf.org/doc/draft-xli-behave-divi/https://datatracker.ietf.org/doc/draft-xli-behave-divi/)
and dIVI-PD (https://datatracker.ietf.org/doc/draft-xli-behave-divi-pd/) 
models are fully compatiple with stateless NAT64, i.e. RFC6052 and RFC6145.

Regards,

xing

---

From: Rémi Després <[email-masked]>
Date: Fri, 29 Jul 2011 16:15:33 +0200

> Cameron,
...
> Stateless is not exclusive with stateful one, and also NAT64.

+1
RD

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 29 Jul 2011 07:27:54 -0700

> > Stateless is not exclusive with stateful one, and also NAT64.

Ok. I do think the draft would benefit from narrowing some of the options.
It seemed to me that statelessness was a key feature, but I may have
misread.

Either way, I think it is helpful if the true cost and benefits of
statelessness is explored. It sounds like there may be a seperate thread on
this.

I am skeptical about stateless operation scaling. I don't even have 2000
ports per user (growth to 2015 ...), and I don't want to get into a position
where I have to tactically move ipv4 addresses around to meet demand.

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 29 Jul 2011 11:14:27 -0400

Cameron,

On 2011/07/29, at 10:27, Cameron Byrne wrote:

> I am skeptical about stateless operation scaling. I don't even have 2000 ports per user (growth to 2015 ...), and I don't want to get into a position where I have to tactically move ipv4 addresses around to meet demand. 

That's a trade-off. Many people require to make clear the trade-off among stateless and steteful that the softwire wg is now going to do. Fundamentally, to support much port demand, applications should utilize IPv6. Otherwise, restricted port sets should be utilize as much as possible. There are some techniques could be helpful to do it, multiple mapping rule is for example.

cheers,
--satoru