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

From: Rémi Després <[email-masked]>
Date: Mon, 1 Aug 2011 14:48:49 +0200

Le 29 juil. 2011 à 16:27, Cameron Byrne a écrit :

> 
> On Jul 29, 2011 7:15 AM, "Rémi Després" <[email-masked]> wrote:
> >
> >
> > Le 29 juil. 2011 à 15:48, Satoru Matsushima a écrit :
> >
> > > Cameron,
> > ...
> > > Stateless is not exclusive with stateful one, and also NAT64.
> > > I agree with Hui.
> >
> > +1
> > RD
> >
> 
> 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.
> 
Some providers may indeed prefer to have only a stateless solution, especially in for DSL networks where ISP's provide CPE's, but there is no technical reason preventing both solutions to coexist.
> ... I am skeptical about stateless operation scaling. I don't even have 2000 ports per user (growth to 2015 ...),
> 
Since concerned ports are only those that are residually used in IPv4 (while more and more traffic should sooner or later become IPv6), 2000 IPv4 ports per user seems quite sufficient.
If not, would you have figures that show it?

(Besides, note that 16 users per IPv4 address (a quite significant increase), 3840 ports are available per customer (almost twice 2000).

> and I don't want to get into a position where I have to tactically move ipv4 addresses around to meet demand.
> 
If each 3GPP user gets a different IPv4 address each time it is connected, this shouldn't be a concern.
is there a different use case you have in mind?

Last point: are you in fact proposing that 3GPP IPv4v6 bearers be _replaced_ by IPv6-only bearers with IPv4/IPv6 translation, or that both should coexist to widen the number of options?

Regards,
RD

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 1 Aug 2011 08:20:10 -0500

Hi Cameron,

Please see inline,

> 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.  

Thanks for sharing your opinion about the 4v6 encap mode as well as
other tunneling modes (e.g DS-Lite). We agree.

We make a distinction between 4v6 encap mode and tunneling mode for one
simple reason - unlike an IPv4-in-IPv6 tunnel, which would carry any
IPv4 datagram inside an IPv6 tunnel, 4v6 encap mode (i.e. 4rd) is about
carrying only certain types (particular layer4 such as TCP, UDP) of IPv4
datagram inside an IPv6 tunnel. 

	For ex, IP-in-IP tunnel can carry GRE encapsulated IP datagrams
or
	L2TP encaped IP datagrams, whereas 4v6 encap mode can not, as 	
	defined. 

One could deduce that 6rd and DS-Lite employ IP-in-IP tunnel, whereas
4rd doesn't really, strictly speaking. Of course, it is not a
significant issue.

> I believe it is best to state
> that clearly for the 3GPP case, and move on without elaboration.

At v6ops meeting last week, there was a consensus that softwire was to
be made home for this draft (as well as various stateless NAT
solutions), if Behave was to close down. Or form a new WG for stateless
NAT/A+P solutions.

> Is the reference to RFC6053 right?

Oops. Typo. Should be 6052. Thanks for pointing it out.

> 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.

That's certainly one way to tackle this.

> 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.  

Many SPs have to abide by the government/regulatory mandates for Lawful
Intercept and honor customers' request for particular
port-forwarding/opening, and they find stateless NAT in SP network being
more useful than anything else. The advantages are being better captured
in the 'motivation draft'.
http://tools.ietf.org/html/draft-operators-softwire-stateless-4v6-motiva
tion-02

Cheers,
Rajiv

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
On Behalf
> Of Cameron Byrne
> Sent: Thursday, July 28, 2011 5:43 PM
> To: Hui Deng
> Cc: [email-masked]; Wojciech Dec (wdec); Paco Cortes
> Subject: Re: [Softwires] 3gpp related comments on
draft-dec-stateless-4v6-02
> 
> On Thu, Jul 28, 2011 at 10:48 AM, Hui Deng <[email-masked]>
wrote:
> > Hi Cameron,
> >
> > You may need spend time to review it later, it's different from 6RD
and
> > DS-Lite,
> >
> 
> 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
> _______________________________________________
> Softwires mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/softwires

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 1 Aug 2011 07:33:52 -0700

On Aug 1, 2011 5:48 AM, "Rémi Després" <[email-masked]> wrote:
>> 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.
>
> Some providers may indeed prefer to have only a stateless solution,
especially in for DSL networks where ISP's provide CPE's, but there is no
technical reason preventing both solutions to coexist.
>>
>> ... I am skeptical about stateless operation scaling. I don't even have
2000 ports per user (growth to 2015 ...),
>
> Since concerned ports are only those that are residually used in IPv4
(while more and more traffic should sooner or later become IPv6), 2000 IPv4
ports per user seems quite sufficient.
> (Besides, note that 16 users per IPv4 address (a quite significant
increase), 3840 ports are available per customer (almost twice 2000).
> is there a different use case you have in mind?

Many, if not most, 3gpp users get rfc1918 or bogon public addresses today.
Giving my users public addresses using 4v6 stateless probably does not make
sense for me or many similar mobile operators. ... there are not enough
public address to give these users (growth through 2015) each 2000 ports.

This is just a 3gpp data point, since the draft chooses to include 3gpp as
motivation.

Cb
>
>
> Last point: are you in fact proposing that 3GPP IPv4v6 bearers be
_replaced_ by IPv6-only bearers with IPv4/IPv6 translation, or that both
should coexist to widen the number of options?

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 1 Aug 2011 07:36:12 -0700

Both do exist today. I have had the latter in beta for over a year and it
will go to production soon.

Cb

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 1 Aug 2011 10:09:19 -0500

Cameron,

> ... there are not enough public
> address to give these users (growth through 2015) each 2000 ports.	

Agreed. Please note that 2000 ports per subscriber is just one allocation point. It could be as low as 16 ports per subscriber. 

In wireline deployments, 256 or 512 or 1000 ports per subscriber may be chosen (per my discussion with various ISPs).

Cheers,
Rajiv

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Cameron Byrne
> Sent: Monday, August 01, 2011 10:34 AM
> To: Rémi Després
> Cc: Softwires-wg; Paco Cortes; Wojciech Dec (wdec)
> Subject: Re: [Softwires] 3gpp related comments on draft-dec-stateless-4v6-02
> 
> 
> >> 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.
> >
> > Since concerned ports are only those that are residually used in IPv4 (while
> more and more traffic should sooner or later become IPv6), 2000 IPv4 ports per
> user seems quite sufficient.
> sense for me or many similar mobile operators. ... there are not enough public
> address to give these users (growth through 2015) each 2000 ports.	
> 
> > Last point: are you in fact proposing that 3GPP IPv4v6 bearers be _replaced_
> by IPv6-only bearers with IPv4/IPv6 translation, or that both should coexist
> to widen the number of options?
> >
> >
> >
> > Regards,
> > RD
> >
> >>
> >> >
> >> >
> >
> >
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 1 Aug 2011 17:24:40 +0200

Cameron,

Thanks for the clarification.
More below.
 
Le 1 août 2011 à 16:33, Cameron Byrne a écrit :
...
> > Some providers may indeed prefer to have only a stateless solution, especially in for DSL networks where ISP's provide CPE's, but there is no technical reason preventing both solutions to coexist
> 
...
> Many, if not most, 3gpp users get rfc1918 or bogon public addresses today.  Giving my users public addresses using 4v6 stateless probably does not make sense for me or many similar mobile operators. ... there are not enough public address to give these users (growth through 2015) each 2000 ports.
> 
I don't se a significant disagreement here. 

If you have an overwhelming need for dynamic port sharing, it has to be faced, and you will go for CGN's. I don't argue against this.

Some other operators may however have different constraints, and should be permitted to operate whatever simpler solution applies to their case.

Note that one can expect that in 2015 users should work mostly, if not exclusively in IPv6, so that their need should be well well below 2000 IPv4 ports for each.

> This is just a 3gpp data point, since the draft chooses to include 3gpp as motivation.
> 
I appreciate that, and agree that the case for stateless A+P mapping is clearer for DSL and optical fibers than for 3GPP 

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 1 Aug 2011 17:32:53 +0200

Le 1 août 2011 à 16:36, Cameron Byrne a écrit :

> > are you in fact proposing that 3GPP IPv4v6 bearers be _replaced_ by IPv6-only bearers with IPv4/IPv6 translation, or that both should coexist to widen the number of options?
> >
> 
> 
> Both do exist today. I have had the latter in beta for over a year and it will go to production soon.
> 

Thank you for sharing this information.

I infer that the extra header size of 20 octets that 4V6 Translation has, compared to the IPv4v6 Bearer, isn't considered a show stopper.
Hopefully, we won't hear too much of the header size argument in the future.

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 1 Aug 2011 08:36:18 -0700

especially in for DSL networks where ISP's provide CPE's, but there is no
technical reason preventing both solutions to coexist
>
> ...
>>
>> Many, if not most, 3gpp users get rfc1918 or bogon public addresses
today.  Giving my users public addresses using 4v6 stateless probably does
not make sense for me or many similar mobile operators. ... there are not
enough public address to give these users (growth through 2015) each 2000
ports.
> If you have an overwhelming need for dynamic port sharing, it has to be
faced, and you will go for CGN's. I don't argue against this.
>
> Some other operators may however have different constraints, and should be
permitted to operate whatever simpler solution applies to their case.

Of course, agreed.

> Note that one can expect that in 2015 users should work mostly, if not
exclusively in IPv6, so that their need should be well well below 2000 IPv4
ports for each.
> I appreciate that, and agree that the case for stateless A+P mapping is
clearer for DSL and optical fibers than for 3GPP

The authors may want to note this point.

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 1 Aug 2011 10:38:15 -0500

> clearer for DSL and optical fibers than for 3GPP

There are other 3GPP operators who favor using stateless A+P mapping, so I would shy away from the above agreement. Of course, different operators have different constraints that make them favor one or the other solution, as you rightly said. 

Cheers,
Rajiv

> Of Rémi Després
> Sent: Monday, August 01, 2011 11:25 AM
> To: Cameron Byrne
> today.  Giving my users public addresses using 4v6 stateless probably does not
> make sense for me or many similar mobile operators. ... there are not enough
> If you have an overwhelming need for dynamic port sharing, it has to be faced,
> and you will go for CGN's. I don't argue against this.
>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 1 Aug 2011 10:44:14 -0500

We agree that different operators (whether in 3GPP/mobile space or Wireline (DSL/Cable/Fiber) space) would embrace stateful or stateless NAT based solution, per their short-term & long-term plans and associated constraints. 

Perhaps, it could be phrased a bit better in the draft, but that's not to say that stateless NAT/A+P becomes inapplicable to a particular space right away.

Cheers,
Rajiv

> Sent: Monday, August 01, 2011 11:36 AM
> To: Rémi Després

---

From: Rémi Després <[email-masked]>
Date: Mon, 1 Aug 2011 18:21:13 +0200

> We agree that different operators (whether in 3GPP/mobile space or Wireline (DSL/Cable/Fiber) space) would embrace stateful or stateless NAT based solution, per their short-term & long-term plans a…

Note that with stateless mappings + encapsulation, "stateless NAT" is an inappropriate wording, because there is no translation:
- This ensures e2e transparency, 
- At least for customers that are assigned exclusive IPv4 addresses, this e2e transparency is important (IP options, TOS, maybe others).

Cheers,
RD

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 1 Aug 2011 18:26:31 +0200

Any operator wired/wireless/whatever can deploy dual stack and NAT/CGN, and
there is abundant evidence of that. Equally well, any operator can deploy
stateless (once we actually have it) Some may also choose to do a mix. Some
may do neither... In fact this is what is said to be an operator's choice.

-Woj.

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 1 Aug 2011 18:34:27 +0200

On 1 August 2011 18:21, Rémi Després <[email-masked]> wrote:

> > We agree that different operators (whether in 3GPP/mobile space or
> Wireline (DSL/Cable/Fiber) space) would embrace stateful or stateless NAT
> based solution, per their short-term & long-term plans and associated
> constraints.
>
> Note that with stateless mappings + encapsulation, "stateless NAT" is an
> inappropriate wording, because there is no translation:
>

 All of the current Stateless46 variants TRANSLATE Layer 4 (TCP/UDP) + layer
3 (IPv4) info into Layer 3 (IPv6). Would be happy to use another term if...

> - At least for customers that are assigned exclusive IPv4 addresses, this
> e2e transparency is important (IP options, TOS, maybe others).
>

Perhaps for some, but for some the loss of IP Options vs the
efficiencies/gains in other areas are a price worth paying. (note: we have
already agreed that TOS transparency is achievable with either mode)

Cheers,
Woj.

>
> Cheers,
> RD
>
>
> >
> > Perhaps, it could be phrased a bit better in the draft, but that's not to
> say that stateless NAT/A+P becomes inapplicable to a particular space right
> away.
> >
> > Cheers,
> > Rajiv
> >
> >
> today.
> public

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 1 Aug 2011 09:37:50 -0700

> There are other 3GPP operators who favor using stateless A+P mapping, so I would shy away from the above agreement. Of course, different operators have different constraints that make them favor on…

Is it possible for those 3GPP operators to speak for themselves and
not via a vendor?  If not, i understand. I always consider the source
of information.

I am looking to avoid an echo chamber where the IETF is doing
something it thinks the 3GPP wants and therefore the 3GPP adopts
something that it thinks the IETF wants.  Does that make sense?

I would prefer that the draft drop reference to 3GPP since this is a
generic solution, right?  It is not appropriated to try and
sell/target this solution in the RFC to a particular market segment.
There is no specific 3GPP engineering in this solution, so lets just
say it is a generic solution.  Or, we can go a step further and call
it NAT464, then people would intuitively know what it is.

Cameron

>>       > Some providers may indeed prefer to have only a stateless solution,

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 1 Aug 2011 09:49:15 -0700

On Mon, Aug 1, 2011 at 8:32 AM, Rémi Després <[email-masked]> wrote:
>> are you in fact proposing that 3GPP IPv4v6 bearers be _replaced_ by
>> IPv6-only bearers with IPv4/IPv6 translation, or that both should coexist to
>> widen the number of options?
>>
>
> I infer that the extra header size of 20 octets that 4V6 Translation has,
> compared to the IPv4v6 Bearer, isn't considered a show stopper.

I don't think headers are the issue, yes, some bit twiddlers will
disagree.  The challenge is getting the UE software implemented.  Take
IPv6 for example.  Many operators have been asking for support for
years, and now  Nokia is closing down Symbian.  With Symbian gone  as
a platform for new phones (effective now in many operators), there
will be ZERO IPv6 handsets available for GSM/UMTS that you can
purchase.

I feel confident this will change, but i just want to share with you
the fact that the UE ecosystem is a very complex balance of power
between chipsets / Mobile OS / OEM / and service provider.  New
features are very hard to get committed, especially when NAT444 and
NAT44 + IPv6 just work today in the mobile router segment.

Cameron

---

From: Wojciech Dec <[email-masked]>
Date: Mon, 1 Aug 2011 18:57:19 +0200

Indeed, there is nothing here which says that this or that operator or body
needs to do or adopt something. It leaves the pro/con for the operator to
weigh, but to do that there must be some context. This draft thus
illustrates not only the issues attributable to A+P based solutions and
their impact, but also a likely impact to various system contexts formed by
standard/generic architectures. It happened to have been written with
operator input and in doing that we think it provides a useful picture (ie
how this stuff may actually be used in a system).

Regards,
Wojciech.

On 1 August 2011 18:37, Cameron Byrne <[email-masked]> wrote:

> > There are other 3GPP operators who favor using stateless A+P mapping, so
> I would shy away from the above agreement. Of course, different operators
> have different constraints that make them favor one or the other solution,
> as you rightly said.
> >
>
> faced,
> >>       This is just a 3gpp data point, since the draft chooses to include
> 3gpp
> >> as motivation.
> >>

---

From: "Rajiv Asati (rajiva)" <[email-masked]>
Date: Mon, 1 Aug 2011 12:06:39 -0500

Cameron,

Your points are valid. I agree to all but the last one. 

The draft is not intended to provide/propose/recommend a solution, rather share the analysis (e.g. impact if such a solution was to be deployed). Do you find the abstract worthy of rephrasing?

There are other drafts that talk about solutions, of course.

Cheers,
Rajiv

> From: Cameron Byrne [mailto:[email-masked]]
> Sent: Monday, August 01, 2011 12:38 PM
> To: Rajiv Asati (rajiva)
> Cc: Rémi Després; Softwires-wg; Paco Cortes; Wojciech Dec (wdec)
> > There are other 3GPP operators who favor using stateless A+P mapping, so I
> would shy away from the above agreement. Of course, different operators have
> different constraints that make them favor one or the other solution, as you
> rightly said.
> >
> 
> not

---

From: Rémi Després <[email-masked]>
Date: Mon, 1 Aug 2011 19:35:32 +0200

Le 1 août 2011 à 18:49, Cameron Byrne a écrit :

> disagree.  

Agreed.

> The challenge is getting the UE software implemented.  Take
> between chipsets / Mobile OS / OEM / and service provider.  

Same understanding.

> New

Agreed.

As a matter of fact, adding 4rd to IPv6, in order to statelessly provide a few IPv5 incoming ports to customers, in addition to their outgoing ports of NAT444, might be a way to avoid the need for PCP.
(If you find this subject too controversial, it's fine with me to avoid opening it now, but if don't, why not).

Regards,
RD

---

From: Hui Deng <[email-masked]>
Date: Tue, 2 Aug 2011 07:27:25 +0800

Hi Cameron

==> this should be emphasized here in order to not mis-guiding, so I cut off
other wordings.
those bogon public addresses are not static, they are dynamical to assigned
to dynamical online user, I don't see there are not enough bogon public
address, because not all mobile subscriber are always online.

Secondly, they are considered as mobile CPE case at this moment, not for
mobile itself,
there are maybe more mobile user under mobile CPE. it won't conflict with
your stateful NAT64 deployment hopefully.

Regards,

-Hui

---

From: Hui Deng <[email-masked]>
Date: Tue, 2 Aug 2011 07:33:23 +0800

Hi Cameron,

inline please

2011/8/2 Cameron Byrne <[email-masked]>

> not via a vendor?  If not, i understand. I always consider the source
==> I could forsee the stateless 464 could benefit for 3GPP operator CPE
case after BBF deployed if opeartor could has similar management and
opeation platform. As you said, doesn't see the potential of handset
solution for it.

> something that it thinks the IETF wants.  Does that make sense?
==> probably bring to 3GPP for discussion early, then could make right
judgement I guess.

> it NAT464, then people would intuitively know what it is.
==> stateless 464. it will be dfiferent from today's your trial stateful
NAT64.
how could make them work together will be one key for 3GPP to consider about
it.

-Hui

---

From: Hui Deng <[email-masked]>
Date: Tue, 2 Aug 2011 07:35:51 +0800

Hi Cameron

> NAT44 + IPv6 just work today in the mobile router segment.
==> I share your concern here, since TE+ME eco system will be different for
mobiel CPE case. hope it will make difference.

-Hui

---

From: Rémi Després <[email-masked]>
Date: Tue, 2 Aug 2011 14:57:49 +0200

Le 1 août 2011 à 18:34, Wojciech Dec a écrit :
...
>  All of the current Stateless46 variants TRANSLATE Layer 4 (TCP/UDP) + layer 3 (IPv4) info into Layer 3 (IPv6). Would be happy to use another term if...
>  

Right, if IPv4 packets are encapsulated, they cannot be said to be "translated".

"Stateless NAT" isn't therefore an adequate generic term for all the stateless solutions being discussed or IPv4 via IPv6. 
"Stateless IPv4-via-IPv6", as in your draft, is AFAIK much better.

4V6 variants could then be named, for example:
- Stateless 4V6 Translation 
- Stateless 4V6 Encapsulation
- Stateful 4V6 without CGN (RFC 6145, but no NAPT64)
- Stateful 4V6 with CGN (NAPT64)

If acronyms are needed (and they tend to be), they could be something like:
- 4V6T, 4V6E, 4V6N , 4V6C 
- or 4V6-T, 4V6-E, 4V-6N , 4V6-C
- whatever expresses both what is common and what is different

Thoughts?

Cheers,
RD