Subject: FW: New Version Notification for draft-koodli-ipv6-in-mobile-networks-02

From: Rajeev Koodli <[email-masked]>
Date: Thu, 15 Apr 2010 15:04:40 -0700

Hello folks,

I was asked at the Anaheim meeting to clarify the intended audience for this
ID, which I have done in the Introduction; this document can be a useful
reference for service providers and network designers.
This ID does not propose any new protocols or suggest any new protocol work.

I also got a good review from Mohamed Boucadier (thanks!) which I have
addressed. 

It seemed there was good interest that this ID is useful.

So, Chairs: how do we proceed?

Thanks,

-Rajeev

http://tools.ietf.org/html/draft-koodli-ipv6-in-mobile-networks-02

------ Forwarded Message
From: IETF I-D Submission Tool <[email-masked]>
Date: Tue, 13 Apr 2010 16:30:59 -0700 (PDT)
To: Rajeev Koodli <[email-masked]>
Subject: New Version Notification for
draft-koodli-ipv6-in-mobile-networks-02

A new version of I-D, draft-koodli-ipv6-in-mobile-networks-02.txt has been
successfully submitted by Rajeev Koodli and posted to the IETF repository.

Filename:  draft-koodli-ipv6-in-mobile-networks
Revision:  02
Title:   Mobile Networks Considerations for IPv6 Deployment
Creation_date:  2010-04-14
WG ID:   Independent Submission
Number_of_pages: 15

Abstract:
Mobile Internet access from smartphones and other mobile devices is
accelerating the exhaustion of IPv4 addresses.  IPv6 is widely seen
as crucial for the continued operation and growth of the Internet,
and in particular, it is critical in mobile networks.  This document
discusses the issues that arise when deploying IPv6 in mobile
networks.  Hence, this document can be a useful reference for service
providers and network designers.

The IETF Secretariat.

------ End of Forwarded Message

---

From: Fred Baker <[email-masked]>
Date: Thu, 15 Apr 2010 17:08:52 -0700

I would like feedback from the working group. Rajeev would like to make this a working group document. Is there support?

> ------ End of Forwarded Message

http://www.ipinc.net/IPv4.GIF

---

From: Cameron Byrne <[email-masked]>
Date: Thu, 15 Apr 2010 18:12:10 -0700

> I would like feedback from the working group. Rajeev would like to make this a working group document. Is there support?

I support.  Rajeev is bringing a unique and focused discussion.  My
own interest  is with his discussion of the the public and private
IPv4 address exhaustion which gives rise to the IPv6-only scenario.
This is very relevant to large mobile operators that operate 2G, 3G,
and now 4G networks -- all of which are growing.

Cameron

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Apr 2010 14:04:57 +1200

I found it a very informative document and I think it
should move forward.

Regards
   Brian

---

From: <[email-masked]>
Date: Fri, 16 Apr 2010 08:13:40 +0200

Dear Fred, all,

I support this ID to become informative WG document.

Cheers,
Med 

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Fred Baker
Envoyé : vendredi 16 avril 2010 02:09
À : IPv6 Operations
Objet : Re: New Version Notification for draft-koodli-ipv6-in-mobile-networks-02

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: [email-masked]
Date: Fri, 16 Apr 2010 11:25:31 +0300

I support it as well.
It is a very useful reference

Roman

From:   Rajeev Koodli <[email-masked]>
To:     <[email-masked]>
Date:   16-04-10 01:31
Subject:        FW: New Version Notification for 
draft-koodli-ipv6-in-mobile-networks-02
Sent by:        [email-masked]

Hello folks,

I was asked at the Anaheim meeting to clarify the intended audience for 
this
ID, which I have done in the Introduction; this document can be a useful
reference for service providers and network designers.
This ID does not propose any new protocols or suggest any new protocol 
work.

Thanks,

-Rajeev

------ Forwarded Message

Abstract:

The IETF Secretariat.

---

From: <[email-masked]>
Date: Fri, 16 Apr 2010 11:25:58 +0200

Hi Rajeev, all,

I'm worried about the on-demand DHCP based address allocation descriptions herein. 

Majority of 3GPP devices do not implement DHCP at all today for 3GPP access, because it is optional and gives very little when compared to mandatory PPP-like address allocation during bearer establishment procedures. 

Introduction of DHCP for significant host population (to get statistical savings) just for the deferred IPv4 address allocation feature does not sound right thing to do for me.

We should be adding IPv6 features to hosts, not IPv4 features.

Best regards,

Teemu

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of ext Rajeev Koodli
> Sent: 16. huhtikuuta 2010 01:05
> To: [email-masked]
> Subject: FW: New Version Notification for draft-koodli-ipv6-in-mobile-
> networks-02
> 
> 
> Hello folks,
>

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 16 Apr 2010 06:15:50 -0700

> We should be adding IPv6 features to hosts, not IPv4 features.

Teemu, many handsets have DHCP for  the WiFi.  I agree with you in
principle somewhat (many transition steps add IPv4 functions), but i
believe the reality makes your point moot in many relevant cases.  I
strongly feel the transient on-demand IPv4 connection that  Rajeev has
suggested is very useful in IPv4 constrained environments that require
always-on connectivity (IMS ...).  I believe the on-demand IPv4
address can help address the IPv4 literal issue that is described in
draft-wing-behave-http-ip-address-literals, similar to a
dial-on-demand function... the handset always has a path to IPv4, but
the PDP is only setup when a packet needs to be transmitted.

Prior to release 7, i believe this is easy to control (give back ipv4
quickly) since we can configure the handset to terminate idle IPv4 PDP
quickly while the IPv6 is always up.  Once to release 8 and we have
dual-stack bearers, i am not sure the best way to address the
on-demand use of a transient IPv4 address.

Would you suggest the EPS bearer be re-established / re-negotiated to
deliver the IPv4 and IPv6 addresses over PCO- IE?  Is it possible to
send / request PCO-IE without dropping the original EPS bearer?

Cameron

ps.  This type of discussion is why the WG should accept this draft

---

From: Rémi Després <[email-masked]>
Date: Fri, 16 Apr 2010 15:55:09 +0200

Hi Fred,

The informational part of the draft very clear and IMHO extremely valuable.
Like Mohamed, I therefore support, like Mohamed in particular, that it can become an "informational" WG document. 

As far as the proposal that "an LTE deployment may be IPv6-only" is concerned (sec. 3.3), it is more than informational (which BTW is consistent with the Standards Track intended status of the current draft).
It could therefore IMHO be part of another draft, but should not be included in the informational WG document.

(About this particular proposal, I rather think that LTE mobile access networks should be all made dual stack, for some undetermined time, while those of previous generation should continue to evolve so as to become all dual stack.)

Regards,
RD

---

From: <[email-masked]>
Date: Fri, 16 Apr 2010 16:05:42 +0200

Hi,

My suggestion is to provide hosts with a (private) IPv4 address always when dual-stack type of connection has been established. There are several documents that describe solutions for solving private IPv4 address shortage on the network side (DS-Lite, GI-DS-Lite, L2NAT and probably more).

In the discussion during the winter the conclusion was, afaik, that host changes should be avoided.

Mandating hosts to change its address allocation method used in an access technology, and even to include IPv4 on-demand (with deferred DHCPv4 and also "quick" release) is a significant host change, imho. Even in the case handset has DHCP for WiFi (and not all handsets have WiFi). Even more in the split-UE case, where DHCP is running on a separate device (such as laptop).

Best regards,

Teemu

> From: ext Cameron Byrne [mailto:[email-masked]]
> Sent: 16. huhtikuuta 2010 16:16
> To: Savolainen Teemu (Nokia-D/Tampere)
> Cc: [email-masked]; [email-masked]
> Subject: Re: New Version Notification for draft-koodli-ipv6-in-mobile-
> networks-02
> 
> > Majority of 3GPP devices do not implement DHCP at all today for 3GPP
> access, because it is optional and gives very little when compared to
> mandatory PPP-like address allocation during bearer establishment
> procedures.
> >
> > Introduction of DHCP for significant host population (to get
> statistical savings) just for the deferred IPv4 address allocation
> feature does not sound right thing to do for me.
> >
> >> A new version of I-D, draft-koodli-ipv6-in-mobile-networks-02.txt
> has
> >> been

---

From: jouni korhonen <[email-masked]>
Date: Fri, 16 Apr 2010 17:27:01 +0300

Hello,

Thanks for the updated draft. I have few comments and questions regarding Section 3.1.

   (typically a /64) at the time of connection establishment, and an
   IPv4 address is assigned only on-demand (e.g., when an application
   binds to an IPv4 socket interface).  This is feasible on the same
   (dual-stack) PDN in LTE networks (with short DHCP lease times), or
   with on-demand IPv4 PDNs.  On-demand IPv4 PDN and address management
   can be effective in conserving IPv4 addresses; however, such a
   management could have some implications to how the PDN and addresses
   are managed at the MN.

Does the on-demand IPv4 PDN management here imply establishing and tearing down IPv4 PDN connections based on the IPv4 use? If so, how does the stack figure out when to tear down the IPv4 PDN connection? Such dynamic IPv4 PDN connection handling probably has somewhat undesired signaling load effect against the core network.

Regarding delayed IPv4 address management. I have my concerns on "split UE" cases, where the host OS runs DS stack and the  3G/4G terminal acts as a modem. How would the (DHCP-based) delayed address management work in that case without modifying the host OS stack? Typically the host OS stack would try to configure the IPv4 address also immediately.. of course one can do tricks on the driver level and fake addresses toward the host OS but..

IMHO the draft should discuss side effects and constrains in more detail related to the on-demand IPv4 PDN connection and address management before suggesting them as a general guideline.

- Jouni

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 16 Apr 2010 10:46:11 -0400

Hi RD,

thank you for your support.

the "Standards Track" part is an error - this is an Informational ID (please see previous versions for instance)

Regarding the IPv6-only mobile deployment section: it is an important consideration for mobile networks. The relevant section is discussing what are the issues, specifically roaming and applications impact. It is not proposing anything new here, but highlighting the considerations.

Regards,

-Rajeev

-----Original Message-----
From: [email-masked] on behalf of Rémi Després
Sent: Fri 4/16/2010 6:55 AM
To: Fred Baker
Cc: IPv6 Operations
Subject: Re: New Version Notification for  draft-koodli-ipv6-in-mobile-networks-02
 
Hi Fred,

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Fri, 16 Apr 2010 17:27:05 +0200

> the "Standards Track" part is an error - this is an Informational ID (please see previous versions for instance)

I see.
Thanks for the clarification.

> Regarding the IPv6-only mobile deployment section: it is an important consideration for mobile networks. The relevant section is discussing what are the issues, specifically roaming and applications impact.

> It is not proposing anything new here, but highlighting the considerations.

Well, I didn't understand it quite this way (with the two following sentences in particular), so that the text can probably be improved in this respect.
-"This is a realistic scenario today where an LTE deployment may be IPv6-only, whereas a roamed 3G UMTS network may not offer IPv6 PDN"
-"In summary, IPv6-only deployments should be encouraged."

Also, when you say:
 "However, by taking the initiative to introduce IPv6-only for the
 newer MNs, the mobile networks can significantly reduce the demand
 for private IPv4 addresses."
It doesn't take into account the following:
- if a dual-stack MN only connects to IPv6-enabled servers (like an IPv6-only that consumes no public IPv4 address space at all), it doesn't consume any public-IPv4 address space.
- It has a NET10 IPv4 address, which gives access to a NAT44, but never uses it. 

In summary, that is *dual-stack deployments* that must be "encouraged" today.
In my understanding, this is the current IETF stand, and should remain so until more experience is gained.

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 16 Apr 2010 09:02:43 -0700

> In my understanding, this is the current IETF stand, and should remain so until more experience is gained.

Disagree.  Any solution that is dependent on IPv4 is not easily
achievable for a larger network operator. Large mobile operators do
not have enough private or public space to operate the networks they
have now.  Overlapping spacing introduces several challenges,
especially in an IMS environment.  Dual-stack also cost 2x the price
in pre-release 8 networks (per PDP pricing...)

The IETF-3GPP joint meeting recognized this is supporting the
IPv6-only + v6v4 interworking model

http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100060.zip

Dual-stack would have been great if this were 2005, but the dual-stack
ship has sailed.  It's too late. The easiest path forward is IPv6-only
given that devices are always,  the only IPv4 space available is BOGON
or overlapped with SBCs and complicated internal NATs, communication
is any to any, connected devices grow exponentially, and major content
is going IPv6 in the next year (Google is there now, others are on
their way).  I predict by this time next year i have AAAA for over 50%
of the bandwidth my customers use.

On a personal note, for the last 2 months i have been IPv6-only with
NAT64 on my 3G mobile (work and persona) devices for the last 2 months
with not negative impacts.

Cameron

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 16 Apr 2010 09:45:00 -0700

> Does the on-demand IPv4 PDN management here imply establishing and tearing down IPv4 PDN connections based on the IPv4 use? If so, how does the stack figure out when to tear down the IPv4 PDN conne…

My view on this is that NAT44 and NAT64 are equal costs.  So, i deploy
NAT64 and my UE is IPv6-only.  If there were a scenario where
DNS64/NAT64 does not work (IPv4 literal, IPv4-only App, ...), then the
IPv4 PDP is establish.  As i mentioned before, IPv6-only handset is a
very acceptable user experience using today's technology and
standards.  What Rajeev is suggesting helps with some corner cases (at
least that is how I would use it).

Cameron

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 16 Apr 2010 12:45:12 -0400

Hi RD,

perhaps it is useful to mention here is that this ID addresses multiple considerations - IPv4 exhaust, NAT placement, Roaming (in the context of IPv6-only models) and Fixed-Mobile Convergence. 
 
The ID states that the IETF dual-stack model is readily applicable in mobile networks, and that's the likely deployment model for a majority of mobile providers today. 

Towards the end of Section 3.1:
 
" In other words, the IETF's dual-stack model
   of separate IPv6 and IPv4 networks is readily applicable to mobile
   networks with the support for distinct APNs and the ability to carry
   IPv6 traffic on PDP/PDN connections."

And in Section 4:

"The IETF dual-stack model [RFC4213] can be applied to the mobile networks readily."

Your input on dual-stack applies here (specifically Section 3.1).

Separately, IPv6-only deployments may be relatively few, but need to be looked into. In IPv6-only deployments, there can be no IPv4 connectivity (PDN/PDP) at all.  Please see more below.

-----Original Message-----
From: Rémi Després [mailto:[email-masked]]
Sent: Fri 4/16/2010 8:27 AM
To: Koodli, Rajeev
Cc: Fred Baker; IPv6 Operations
Subject: Re: New Version Notification for  draft-koodli-ipv6-in-mobile-networks-02

>>Well, I didn't understand it quite this way (with the two following sentences in particular), so that the text can probably be improved in this respect.

okay.

>>-"This is a realistic scenario today where an LTE deployment may be IPv6-only, whereas a roamed 3G UMTS network may not offer IPv6 PDN"

What this is stating is that if an LTE deployment is IPv6-only, there is likelihood that the roamed 3G network does not offer IPv6 PDN connectivity; the emphasis is on the "may". It should be read together with 

"The service providers can control their own network design but not their peer's networks which they rely on for roaming.  Perhaps more importantly, the users expect similar experience even when they are roaming. 
This imposes a constraint on providers interested in IPv6-only deployments to also support IPv4 addressing when their own (outbound) subscribers roam to networks which do not offer IPv6. This is a realistic scenario today where an LTE deployment may be IPv6-only, whereas a roamed 3G UMTS network may not offer IPv6 PDN connectivity service."
 
I could reword the last sentence to: "For instance, if an LTE deployment is IPv6-only, a roamed 3G UMTS network may not offer IPv6 connectivity"

>>- if a dual-stack MN only connects to IPv6-enabled servers (like an IPv6-only that consumes no public IPv4 address space at all), it doesn't consume any >>public-IPv4 address space.

The MN is assumed to be dual-stack. With IPv6-only mobile network deployments, the MN is only allowed to activate the IPv6 PDN/PDP connection. 
So, there is no IPv4 connectivity even though the MN is dual-stack. As I explain in the ID, the MN will likely need this dual-stack capability during roaming (when the roamed network does not support IPv6 connectivity).

>>- It has a NET10 IPv4 address, which gives access to a NAT44, but never uses it. 

Same consideration as above. Since the network offered connectivity (i.e., PDN/PDP) is IPv6-only, there is no IPv4 connectivity/addressing.

Note that this is a deployment model that some providers may consider, but it comes with the issues associated with roaming and applications.

>>In summary, that is *dual-stack deployments* that must be "encouraged" today.

Sure, dual-stack is not only encouraged but the *recommended* model. This is captured in the ID (as I mentioned above):

" In other words, the IETF's dual-stack model
   of separate IPv6 and IPv4 networks is readily applicable to mobile
   networks with the support for distinct APNs and the ability to carry
   IPv6 traffic on PDP/PDN connections."

>>In my understanding, this is the current IETF stand, and should remain so until more experience is gained.

Dual-stack is the recommended model. I am suggesting *encouraging* IPv6-only models modulo considerations described in Section 3.3

I could reword "In summary, IPv6-only deployments should be encouraged." to

"In summary, IPv6-only deployments should be encouraged while considering the roaming and applications issues"

Thanks again,

-Rajeev

Regards,
RD

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 Apr 2010 13:05:09 -0400

On 2010-04-16 12:02, Cameron Byrne wrote:
> Disagree.

Dual-stack deployment, as encouraged by the IETF, didn't mean IPv6+NAT44.

In my opinion, IPv6+NAT64 is less evil than IPv6+NAT44.

Simon
-- 
NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca
STUN/TURN server        --> http://numb.viagenie.ca
vCard 4.0               --> http://www.vcarddav.org

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 16 Apr 2010 10:22:15 -0700

> In my opinion, IPv6+NAT64 is less evil than IPv6+NAT44.

+1

And in 3GPP Pre-Release 8, there is business case for it based saving
cost per PDP (cost per PDP in a vendors hardware charging model, or
cost per PDP in the related cost of signalling, state, and mobility
events of 2x the PDP).

Cameron

---

From: Fred Baker <[email-masked]>
Date: Fri, 16 Apr 2010 10:28:41 -0700

chair hat off.

I don't think that RFC 4213 says anything about NATs pro or con; a quick scan of the document didn't find the character string "NAT" or "[nN]etwork [aA]ddress" anywhere in it. What it says could be summarized as "turn on IPv6 in your existing IPv4 network", without making much comment on the IPv4 network. In today's world, any IPv4 network that interfaces with edge networks, which is to say the edge networks themselves or the ISPs they talk with, will find a NAT somewhere in the discussion.

In other words, I disagree that the the statement has anything to do with the IPv4 implementation whatsoever. It says to turn on IPv6 without changing your IPv4 implementation.

---

From: Rémi Després <[email-masked]>
Date: Fri, 16 Apr 2010 19:30:16 +0200

>> In my understanding, this is the current IETF stand, and should remain so until more experience is gained.

Thanks for the debate then, hopefully constructive.

>  Any solution that is dependent on IPv4 is not easily
> have now.  

> Overlapping spacing introduces several challenges,
> especially in an IMS environment.  

Agreed.
However, like 6rd permits to easily offer native IPv6 on IPv4-only infrastructures (see RFC 5569), the same principle reversed permits to offer public IPv4 (with restricted port sets) on IPv6-only infrastructures. 

> Dual-stack also cost 2x the price

It doesn't need to.

> http://www.3gpp.org/ftp/workshop/2010-03-01_IPv4-to-IPv6_with-IETF/Docs/IPW100060.zip

Thanks for the reference.
It's indeed useful to know.

> ship has sailed.  It's too late.

Maybe if mobile operators have already made up their mind.
I believe however that many operational problems if IPv6-only is proposed with NAT64s are still overlooked.
In particular:
- The Port-Control Protocol that is under study in Softwire and considered for NAT64s is an example of additional complexity that has to be considered.
- If hosts cannot always distinguish whether IPv6 addresses of remote hosts are IPv6 end-to-end or are subject to NAT64 translations, the effect is in my understanding still hard to predict.   

> The easiest path forward is IPv6-only
> is any to any, connected devices grow exponentially,

(I didn't get the meaning of this sentence.)

> and major content

That's certainly a good expectation, which I share to a good extent (I use native IPv6 in my home-office, deployed by Free since December 2007).

> with not negative impacts.

That's good indeed (although of course it doesn't prove that others, with different terminals and/or applications, would also be fully satisfied with IPv6-only) 

Regards,
RD

---

From: Simon Perreault <[email-masked]>
Date: Fri, 16 Apr 2010 13:44:24 -0400

On 2010-04-16 13:28, Fred Baker wrote:
> I don't think that RFC 4213 says anything about NATs pro or con; a
> quick scan of the document didn't find the character string "NAT" or
> "[nN]etwork [aA]ddress" anywhere in it. What it says could be
> summarized as "turn on IPv6 in your existing IPv4 network", without
> making much comment on the IPv4 network. In today's world, any IPv4
> network that interfaces with edge networks, which is to say the edge
> networks themselves or the ISPs they talk with, will find a NAT
> somewhere in the discussion.

Exactly my point. RFC 4213 doesn't consider NATs.

> In other words, I disagree that the the statement has anything to do
> with the IPv4 implementation whatsoever. It says to turn on IPv6
> without changing your IPv4 implementation.

If an ISP wants to go from providing NAT44 to providing IPv6+NAT64, 
would that go against the IETF's dual-stack recommendation? It sure 
seems like it since it involves completely shutting down IPv4.

Thanks,
Simon

---

From: "Koodli, Rajeev" <[email-masked]>
Date: Fri, 16 Apr 2010 13:53:04 -0400

Hi Teemu,

thanks for the input.

Agree to your point about adding IPv6 features and not IPv4.
However, the description of DHCP-based addressing is for LTE, not 3G.
And the description is about having DHCP as a mechanism to manage the available IPv4 addressing pool.
Are you saying that it should not be available or should not be used?

Regards,

-Rajeev

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Fri 4/16/2010 2:25 AM
To: Koodli, Rajeev; [email-masked]
Subject: RE: New Version Notification for  draft-koodli-ipv6-in-mobile-networks-02
 
Hi Rajeev, all,

Best regards,

Teemu

---

From: Fred Baker <[email-masked]>
Date: Fri, 16 Apr 2010 11:05:02 -0700

As I said, the IETF's recommendation makes no suggestion that one even think about one's IPv4 implementation. It says "turn on IPv6 in your existing IPv4 network". If your existing IPv4 network is using IPv4/IPv6 translation to convert the edge network's IPv4 to the core network's IPv6, I would guess that means "use IPv4/IPv6 translation". Somehow, I don't think that's a common model.

I'll refer you to http://tools.ietf.org/html/draft-arkko-ipv6-transition-guidelines
  "Guidelines for Using IPv6 Transition Mechanisms", Jari Arkko, Fred
  Baker, 24-Feb-10

While it is not itself a consensus document (I'd like to make it one, but that's another discussion), I believe that it represents the current IETF consensus. In the discussion in section 4, you'll find that IPv4/IPv6 translation mentioned but is not pushed. Says one of the co-authors of the IPv4/IPv6 translation approach.

On Apr 16, 2010, at 10:44 AM, Simon Perreault wrote:

> If an ISP wants to go from providing NAT44 to providing IPv6+NAT64, would that go against the IETF's dual-stack recommendation? It sure seems like it since it involves completely shutting down IPv4.
> 
> Thanks,
> Simon
> --

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 16 Apr 2010 11:15:28 -0700

Hi Teemu,

On 4/16/10 7:05 AM, "[email-masked]"
<[email-masked]> wrote:

> My suggestion is to provide hosts with a (private) IPv4 address always when
> dual-stack type of connection has been established. There are several
> documents that describe solutions for solving private IPv4 address shortage on
> the network side (DS-Lite, GI-DS-Lite, L2NAT and probably more).

Well, those are options for some. But the main point here is that IPv4
address is tied to the corresponding PDN/PDP. The network may want to
reclaim the PDN/PDP due to session timers. So, when the PDN/PDP is deleted,
so is the IP address. IMO, we cannot disallow this.

> Mandating hosts to change its address allocation method used in an access
> technology, and even to include IPv4 on-demand (with deferred DHCPv4 and also
> "quick" release) is a significant host change, imho. Even in the case handset
> has DHCP for WiFi (and not all handsets have WiFi). Even more in the split-UE
> case, where DHCP is running on a separate device (such as laptop).

As I mentioned in a previous email, Deferred IP address allocation is
specified for use in LTE. If 3G handsets do not do DHCP, it does not mean
LTE handsets should not, right?

Thanks,

-Rajeev

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 16 Apr 2010 11:19:52 -0700

> Thanks for the debate then, hopefully constructive.

yes, always.

> However, like 6rd permits to easily offer native IPv6 on IPv4-only infrastructures (see RFC 5569), the same principle reversed permits to offer public IPv4 (with restricted port sets) on IPv6-only…

As others have pointed out, changes to requirement or technology on
handsets is highly discouraged. So, yet another protocol will not gain
much support unless the value is substantially better than what is
provided today. Furthermore, the IPv6 need is now a pressing
operational and business continuity issue.

>> in pre-release 8 networks (per PDP pricing...)

Renegotiating vendor contracts of that magnitude is above my pay grade :)

But regardless, of how you pay for capacity, 2x the PDP session will
result in 2x the hardware since you will be doing 2x the signalling
and 2x the mobility events within the mobility core.

> - The Port-Control Protocol that is under study in Softwire and considered for NAT64s is an example of additional complexity that has to be considered.

I have seen it cited that roughly 50% of mobile operators do NAT44
today.  My network does NAT44 today, so NAT64 is not an additional
complexity for me since the function and resulting quality of
experience is similar to NAT44. In fact, since NAT64 does not have to
be "on path", i can leverage the DNS64 to drive more effective load
balancing and high availability schemes.

> - If hosts cannot always distinguish whether IPv6 addresses of remote hosts are IPv6 end-to-end or are subject to NAT64 translations, the effect is in my understanding still hard to predict.

Like above, assuming that your only option is NAT44 (with BOGON or
multiple instances of 10/8 on the inside) for IPv4 and that NAT64 is a
similar quality of experience to NAT44, i believe it is unlikely a
subscriber will be materially impacted. There are indeed cases where
NAT64 and IPv6-only don't work perfect with today's standards, but
what Rajeev is suggesting with on-demand IPv4 may help with that.

> (I didn't get the meaning of this sentence.)

Sorry, i rushed this last email between meetings and did not do a good
job editing.

My point is that for a mobile operator that does NAT44 today,
IPv6-only with NAT64 is the simplest path forward.  This is because:

1.  More and more devices are alway-on.  Before, handsets would only
have IP address when you go to a web site or actively transfer data.
Now, handsets are always connected to mobile network and always
transmitting data on your location, sycn your email and contacts,
register with SIP / IMS ...  This is a big change for the dimensioning
of the network.

2.  Mobile operators have deployed both BOGON and overlapping IP
address space, both are bad and substantially limit peer to peer (e2e)
communication.  In case of BOGON, the operator needs to change IP
address space periodically as the space they are using is claimed by
its rightful owner.  That is a risk to be managed.  In the re-using IP
address space case, any mobile to mobile communication (voice, video,
p2p) must go through some device that can disambiguate the addresses
based on location and state, like a SIP B2BUA or Session Border
Controller.  This is costly and complicated to operate.

3.  Users are increasingly communicating end to end  IMS / SIP services.

4.  As everyone know, mobile subscribers are growing very quickly

All of the above make the case that work-arounds with IPv4 are poor
investments.  The smart money is being spent to bring IPv6 primary
services in quickly since the pay back time on the investment is as
long as you use IPv6, not the life of a NAT444 CGN or other
infrastructure.  Any technology that has a lead time of 18 months to
develop and other 2 years to tune in production cannot meet the
investments requirements since they will be obsolete too soon.   As we
agree, IPv6 content will be here very soon.

> That's good indeed (although of course it doesn't prove that others, with different terminals and/or applications, would also be fully satisfied with IPv6-only)

IPv4-only service won't go away any time soon.  IPv6-only will be
specific handsets and services that will certainly be regression
tested to make sure the user experience is acceptable.  For people
where IPv6-only + NAT64 works, we should encourage them to use it.
For people that it does not work, we can have products / services for
that too.

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 16 Apr 2010 11:26:45 -0700

Hi Jouni,

Thanks fo ryour input.

On 4/16/10 7:27 AM, "jouni korhonen" <[email-masked]> wrote:

> Does the on-demand IPv4 PDN management here imply establishing and tearing
> down IPv4 PDN connections based on the IPv4 use?

Not necessarily. This is typically based on session (PDN/PDP) timers on the
network side. 

> If so, how does the stack
> figure out when to tear down the IPv4 PDN connection? Such dynamic IPv4 PDN
> connection handling probably has somewhat undesired signaling load effect
> against the core network.

The MN does not have to do any signaling.

> 
> Regarding delayed IPv4 address management. I have my concerns on "split UE"
> cases, where the host OS runs DS stack and the  3G/4G terminal acts as a
> modem. How would the (DHCP-based) delayed address management work in that case
> without modifying the host OS stack? Typically the host OS stack would try to
> configure the IPv4 address also immediately.. of course one can do tricks on
> the driver level and fake addresses toward the host OS but..

As you know, Deferred Address Allocation is specified in 3GPP.
The above is an issue for Deferred Address Allocation procedure for split-UE
case in 3GPP. AFAIK, there has been no discussion of the split-UE case
addressing. Are you aware of anything, specifically how Deferred Address
Allocation would be used in split-UE case?

Separately, I wonder how prevalent is/will-be the UE-as-a-modem model..

> 
> IMHO the draft should discuss side effects and constrains in more detail
> related to the on-demand IPv4 PDN connection and address management before
> suggesting them as a general guideline.

I would be glad to add more text, based on the WG discussion and consensus.

Before I do that, I would like to know whether there is interest in having
this as a WG document :-)

Regards,

-Rajeev

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 16 Apr 2010 13:05:17 -0700 (PDT)

Hi Fred,
  This draft is not a v6ops draft. Is it possible to take it as WG draft? It is submitted to 6man, I think.

Regards,

Behcet

----- Original Message ----
> From: Fred Baker <[email-masked]>
> To: IPv6 Operations <[email-masked]>
> Sent: Thu, April 15, 2010 7:08:52 PM
> I would like feedback from the working group. Rajeev would like to make this a 
> working group document. Is there support?

On Apr 15, 2010, at 3:04 PM, 
> Rajeev Koodli wrote:

> 
> Hello folks,
> 
> I was 
> asked at the Anaheim meeting to clarify the intended audience for this
> 
> This ID does not 
> propose any new protocols or suggest any new protocol work.
> 
> I 
> also got a good review from Mohamed Boucadier (thanks!) which I have
> 
> addressed. 
> 
> From: IETF I-D 
> Submission Tool <> href="mailto:[email-masked]">[email-masked]>
> Date: 
> To: Rajeev Koodli <> ymailto="mailto:[email-masked]" 
> href="mailto:[email-masked]">[email-masked]>
> Subject: New 
> Version Notification for
> A new version of I-D, 
> draft-koodli-ipv6-in-mobile-networks-02.txt has been
> successfully 
> submitted by Rajeev Koodli and posted to the IETF repository.
> 
> 
> Revision:  
> 02

---

From: Fred Baker <[email-masked]>
Date: Fri, 16 Apr 2010 13:16:05 -0700

All things are possible. The question is what the right thing to do is. Speaking for myself, this seems like a better fit to v6ops than 6man, as it talks about operational deployment of IPv6 rather than maintenance of IPv6 itself. That said, I'm looking for a supporting consensus. What I read so far today suggests that there is sufficient consensus. If anyone disagrees, that's important for me to know.

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 16 Apr 2010 13:32:36 -0700 (PDT)

----- Original Message ----
> To: Behcet Sarikaya <[email-masked]>
> Cc: IPv6 Operations <[email-masked]>
> Sent: Fri, April 16, 2010 3:16:05 PM
> All things are possible. The question is what the right thing to do is. Speaking 
> for myself, this seems like a better fit to v6ops than 6man, as it talks about 
> operational deployment of IPv6 rather than maintenance of IPv6 itself. That 
> said, I'm looking for a supporting consensus. What I read so far today suggests 
> that there is sufficient consensus. 

Another point: I hear people agreeing on this draft as informational. However the draft itself is going for standards track.

There is disagreement right there.

Regards,

Behcet

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 16 Apr 2010 13:37:39 -0700

Hi Behcet,

This draft is intended for v6ops. It was not submitted to 6man or
discussed/presented there.

The absence of 'v6ops' moniker was a slip when I submitted 00 version, and I
have not added it to reflect the version changes (00->02).

At the top left corner of the ID template, you will see "v6ops Working
Group" from version 00 onwards..

Regards,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 16 Apr 2010 13:40:15 -0700

I pointed out earlier that it is Informational (I did not change the type in
xml2rfc template), and that Standards Track is an error.
Please see previous versions.

Thanks,

-Rajeev

On 4/16/10 1:32 PM, "Behcet Sarikaya" <[email-masked]> wrote:

> Another point: I hear people agreeing on this draft as informational. However
> the draft itself is going for standards track.
>

---

From: Fred Baker <[email-masked]>
Date: Fri, 16 Apr 2010 14:24:58 -0700

OK, Rajeev:

Please refile this as draft-ietf-v6ops-v6-in-mobile-networks, and tell the secretariat that it replaces draft-koodli-ipv6-in-mobile-networks

When you do, please make sure it is marked as informational.

Let's move the discussion to something more substantive.

Fred

---

From: Rajeev Koodli <[email-masked]>
Date: Fri, 16 Apr 2010 14:51:36 -0700

OK, will do.

Thanks everyone for the interest. Look forward to the discussions.

-Rajeev

On 4/16/10 2:24 PM, "Fred Baker" <[email-masked]> wrote:

> OK, Rajeev:
> 
> Please refile this as draft-ietf-v6ops-v6-in-mobile-networks, and tell the
> secretariat that it replaces draft-koodli-ipv6-in-mobile-networks
>

---

From: Rémi Després <[email-masked]>
Date: Sat, 17 Apr 2010 09:31:00 +0200

Le 16 avr. 2010 à 20:19, Cameron Byrne a écrit :

>> ... like 6rd permits to easily offer native IPv6 on IPv4-only infrastructures (see RFC 5569), the same principle reversed permits to offer public IPv4 (with restricted port sets) on IPv6-only infrastructures.
>> 
> 
> handsets is highly discouraged.

Solving unsolved problems with incrementally deployable new technologies remains a good way to make progress.

Reversed 6rd (or "4rd", as Satoru Matsushima privately suggested to call it) is something handsets MAY support to get improved service, introducing no restriction to other handsets (or PCs or whatever hosts use LTE access):
- If they don't support 4rd, they depend on DNS64 and NAT64 to reach IPv4-only remote hosts.
- If they do support 4rd, they get public IPv4 addresses (port-restricted), statelessly derived from their IPv6 addresses. They can use them to reach IPv4-only remote hosts with e2e transparency (no dependence on a DNS64 and a NAT64).

If you have read RFC 5569 which shows native IPv6 has been offered in 2007 across an IPv4-only infrastructure, with a trivially simple mechanisms, you may guess how simple in can be to offer public IPv4 addresses (port restricted) across IPv6-only infrastructures, e.g. LTE access networks.

So far, "4rd" is described only in sections 3.2 and 2.6 of draft-despres-softwire-sam-00, but indirectly (and without the name).
I plan to have a specific draft on "4rd" for IETF 78.
Your reactions to it will be most welcome. 

> ... regardless, of how you pay for capacity, 2x the PDP session will

Not with 4rd. 
(IPv4 packets are encapsulated in IPv6 packets, which are transmitted using their PDP session.)  

> ... My point is that for a mobile operator that does NAT44 today,

With 4rd, the port-restricted IPv4 address derived from an IPv6 address is as stable as the IPv6 address.

Note that if an operator restricts to 256 ports the assignment each handset gets for its IPv4 connections, this multiplies the number of hosts it supports with a given IPv4 address space by 256. (And 256 ports is much much more than the handset will need for IPv4 when most of the traffic becomes end-to-end IPv6.)

> investments.  

DNS64 and NAT64 ARE "work-araounds".
Their advantage is to be almost completely specified, but their drawback is to have complex and hard to predict consequences. 
By adding 4rd in handsets (a stateless function), they can get during the v4/v6 coexistence period, a cleaner and safer service from operators that support 4rd (border relays that, unlike NAT64s, operate statelessly at the transport layer).

> The smart money is being spent to bring IPv6 primary

We also agree that the v4/v6 coexistence period won't be finished in 18 months ;-).
IMHO, offering better service to upgraded handsets for this coexistence period, and this at extremely low cost, still makes sense.

> where IPv6-only + NAT64 works, we should encourage them to use it.

It seems to me you plan more to "force" them to use it than to "encourage" them.
Now, if the handset acts as a small router with an integrated NAT44 (as at least some Nokia handset do today), it will have to support a NAT46 which will be cascaded with NAT64s. With 4rd, it the NAT44 needs only to work with restricted port sets.

> For people that it does not work, we can have products / services for

Without any upgrade in handsets?

It might be easier to pursue this discussion when a better description of the 4rd proposal is available.

Kind regards,
RD

---

From: Jouni <[email-masked]>
Date: Sat, 17 Apr 2010 12:59:40 +0300

Hi Rajeev,

Thanks for your clarifications. I have few more comments inline.

> Not necessarily. This is typically based on session (PDN/PDP) timers on the

We have seen mobiles trying to be too clever here as well (not for preserving IPv4 addresses but battery). However, the outcome will be more or less the same if the document encourages establishing and tearing down connections "in a clever way". 

> The MN does not have to do any signaling.

I am not concerned about MN doing IP layer signaling, that's peanuts. I am worried about the signaling caused by the MN playing around with the PDN connection that is then seen between core network nodes as signaling bursts. This is an issue especially with pre-LTE stuff, which seems to be the part that would actually get affected by recommendation of on-demand IPV4 connection management.. Even if the draft targets for the LTE, majority of the networks will be mix of 3G and LTE for a long time. Some text explaining pros and cons/side effects would actually be all that is needed.

> Allocation would be used in split-UE case?

Not really.. that's why this document could/should actually make a clear distinction which of the recommended models/approaches apply where. 

> Separately, I wonder how prevalent is/will-be the UE-as-a-modem model..

As for data volumes that will probably be the dominant. Also, notebooks with cellular broadband access seem to be and become increasingly popular..

- Jouni

---

From: <[email-masked]>
Date: Sun, 18 Apr 2010 22:44:29 +0200

Hi Rajeev,

I'm saying having DHCP for deferred address allocation is quite a host change:
1) a host has to support DHCP for 3GPP access at first place
2) a host has to support deferred DHCP for 3GPP access (reserve/release on-demand)
3) a host has to support negotiation of used address allocation mechanism for 3GPP access:
3a) A host will have to ask if DHCP is used for this particular PDN connection
3b) If DHCP is not used, host shall get the address from bearer signaling instead

Also in LTE the DHCP is optional for both host and network.

So what I'm also saying is that it is not so straightforward to use IPv4 on-demand with DHCP as I think the draft is implying (but maybe it is just my view), which is a concern for feasibility of this approach (recall how in 3GPP discussions getting transition mechanism changes to hosts was considered so hard).

This DHCPv4 on-demand sound for me quite like a host based transition mechanisms (DSTM without encapsulation?).

Furthermore, to gain real benefits a significant host population should support this, and it may or may not be a challenge depending on LTE deployment schedules and speed.

Best regards,

Teemu

> From: ext Koodli, Rajeev [mailto:[email-masked]]
> Sent: 16. huhtikuuta 2010 20:53
> To: Savolainen Teemu (Nokia-D/Tampere); [email-masked]

---

From: <[email-masked]>
Date: Sun, 18 Apr 2010 22:41:33 +0200

> in pre-release 8 networks (per PDP pricing...)

Shouldn't applications that have issues with overlapping addresses go directly to IPv6? Especially IMS?

Then, should the possible vendor pricing models really affect technology selections in SDOs? After the discussions in 3GPP last winter I got the impression that cost of PDP contexts is not a factor when choosing transition mechanisms. In fact, I was told by several people that GTP tunnels are so cheap that we should not look for anything more complex than that - and I thought that was the case until these discussions started again:)

Now, if the cost of PDP contexts really would be an issue and rather significant host changes in LTE timeframe would be allowed (as seems to be the case here..) then why not go for single hop IPv4-in-IPv6 tunnel from UE to PDN-GW - maybe flavored with DSTM kind of dynamic IPv4 address allocation (deferred address allocation) or maybe even with AFTR at the PDN GW. 

IPv4v6 bearer type would not be needed, IPv6 type would suffice.

Traffic filtering & QoS & DPI thingies could happen before IPv4 is encapsulated to IPv6 and right after IPv4 has been decapsulated.

MTU is not really an issue, 1500 has been difficult to have anyway due network fragmentation avoidance (i.e. at least some hosts have been using less-than-1500 MTU to avoid fragmentation of GTP tunnels).

Extra header overhead for bulk traffic is relatively small and RoHC can squeeze away also the tunnel headers of VoIP traffic.

But all-in all, I think the discussions concluded that native dual-stack, with moving as many apps to IPv6 as possible, and network providing (possibly overlapping) IPv4 addresses to hosts, was seen as the best way forward.

I think the draft, now that it is WG draft, should reflect the conclusions that have been already achieved and not restart transition mechanism selection discussions... 

Best regards,

Teemu

---

From: <[email-masked]>
Date: Sun, 18 Apr 2010 22:44:30 +0200

> specified for use in LTE. If 3G handsets do not do DHCP, it does not
> mean LTE handsets should not, right?

DHCP is optional in Release-8. 

Handsets have managed to work in 3GPP access for a decade or so without DHCP based address allocation (GPRS, EGPRS, WCDMA, HSDPA..). Why they would want to implement DHCP for LTE?

Best regards,

Teemu

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 18 Apr 2010 16:26:14 -0700

> I think the draft, now that it is WG draft, should reflect the conclusions that have been already achieved and not restart transition mechanism selection discussions...

When you say conclusion, you mean the conclusion from the 3GPP-IETF
meeting in San Francisco?  Which is dual-stack AND IPv6-only as
solutions?  Lets make sure the drafts currently being developed
reflect that to the best extent possible.  The San Francisco meeting
was very meaningful for me since it was the first time the larger
community began to grasp the notion that IPv6-only is feasible and
real.

Regarding cost per PDP, i have told the list how it is in my case, 2x
the cost for 3GPP dual-stack.  Look at it from a pricing contract
perspective or signalling load on core elements, the result is 2x the
PDP is 2x the cost.  I am not sure who you are talking to or what the
context is when you say PDP is cheap, but we all know smartphone are
overwhelming signalling load these days, especially PDP setup and
tear-down (battery saving technique).  Some service providers pay for
ALL of their infrastructure in the packet core based on PDP numbers,
just as they pay for all their circuit switched infrastructure based
on busy hour call attempts.  Sometimes it is a simple PDP license fee
mix ($5 per PDP per quarter) with capital purchases ($10 million per
GGSN kit).  There are many variation, but i am not aware of any SP
that would say 2x PDP is acceptable without 2x the revenue.  I 100%
assure you the cost per PDP is NOT trivial, and the increased
signalling from 2x the PDP attach and 2x the mobility events will be
substantial. Especially considering the revenue per byte is eroding,
service providers are very adverse to changes that drive up costs.  If
another network operator posts to the list and says they have a
different cost structure and contract where PDP is trivial (in
contract, in signalling, in capacity ...), great lets here from them
directly as another data point.

Ii am not interested in any new methods (DS-lite ...), they have their
place, but it is not appealing to the mobile scenario (handset impact)
and their time to market is variable.  As mentioned, i really don't
need any new technology to make my own path work.  IPv6-only works
today with NAT64/DNS64, we demonstrated to the IETF-3GPP in San
Francisco and our friendly user trial is growing as IPv6-only,
products are planned for IPv6-only.  What Rajeev adds makes things
clearer and defines a possible path for covering some corner cases.

Also, very important, Rajeev does state that the IPv6-only path exists
and is viable, which is something none of the other drafts on 3G/4G
IPv6 do to a meaningful extent.  This is a shame considering the
results of the San Francisco meeting.  The impression i get is that
most of the drafts see IPv6-only as a niche for M2M and not the
general Internet access case.  In saying that IPv6-only should be
encouraged, Rajeev is faithfully reflecting the 3GPP-IETF community's
official San Francisco meeting summary as well as championing the need
for service providers and vendors to aggressively pursue the urgent
need for IPv6 as a mainstream network protocol.

I am starting to feel like this thread is becoming an echo chamber
with the same people saying the same things.

Cameron

---

From: joel jaeggli <[email-masked]>
Date: Sun, 18 Apr 2010 20:58:15 -0700

On 4/16/2010 6:15 AM, Cameron Byrne wrote:
> On Fri, Apr 16, 2010 at 2:25 AM,<[email-masked]>  wrote:
>> Hi Rajeev, all,
>>

What happens when the device actually requires that the ipv4 databearer 
be in use all the time? Insofar as I have experience that case is not 
particularly rare, and likely to get less so rather than more.

Given that the ipv4 problem described in 3.1 and 3.2 exists today and is 
addressed using existing techniques there doesn't seem to be that much 
to solve really for the v4 case. certainly nothing that I'd want to 
design new software for handsets and mngs to address.

>>> From: IETF I-D Submission Tool<[email-masked]>
>>> To: Rajeev Koodli<[email-masked]>

---

From: Cameron Byrne <[email-masked]>
Date: Sun, 18 Apr 2010 22:04:23 -0700

On Sun, Apr 18, 2010 at 8:58 PM, joel jaeggli <[email-masked]> wrote:
>>> Introduction of DHCP for significant host population (to get statistical
>>> savings) just for the deferred IPv4 address allocation feature does not
>>> sound right thing to do for me.
>>>
> What happens when the device actually requires that the ipv4 databearer be
> in use all the time? Insofar as I have experience that case is not

I strongly believe in Occum's Razor.  If an IPv4 data bearer is
"required", then it is required and should be established.  If a
"service" to a subscriber can be designed where applications are IP
version agnostic (Symbian is a good example, i have not found anything
IP version specific yet in Ovi), the case should NOT be that an IPv4
bearer is required.  The only thing required is the bearer that
enables the communication to be established.  A relevant example that
Rajeev cites is the roaming scenario, where an IPv6-only service in
the home network now needs to be an IPv4-only service in the visited
network that only supports IPv4 PDP type (no dual-stack service here
either, just v4).  Keep in mind, the handset is alway dual-stack
capable, but the service can be defined as one bearer at a time
depending on if the user is roaming or not, or perhaps 2 bearers if
the user "requires" a transient IPv4 bearer to deal with an IPv4
literal or a legacy IPv4-only applications.  If the service the
customer needs is IPv4 alway-on, then the customer should buy an IPv4
service.  IPv4 services will not go away any time soon.

If the application and OS are IP version agnostic AND there is a
suitable protocol translation scheme like DNS64/NAT64 AND there is
legitimate reason to believe that a substantial amount of content will
become available via IPv6, then it just might make sense to encourage
IPv6-only (the better term is IPv6-primary) deployments.

Thanks,
Cameron

> addressed using existing techniques there doesn't seem to be that much to
> solve really for the v4 case. certainly nothing that I'd want to design new
> software for handsets and mngs to address.
>

---

From: <[email-masked]>
Date: Mon, 19 Apr 2010 13:07:44 +0200

Yes, that meeting and discussion before that. The host based transition mechanisms were rejected because transition was agreed to be more easily done by networks than by all hosts - and hosts were discussed to have dual-stack connectivity or IPv6-only connectivity. I agree these discussions sound echoing, they are, but for me it seems there is interest to restart this discussion again as the draft that, from my point of view, talks about host based transition mechanism called "DHCPv4 on-demand", was adopted...

In my opinion the draft can mention it is possible to build such IPv4 address on demand system, but for it to be really useful it would have to be supported by wide variety of hosts, and that is not at all certain because as said many times, DHCP is optional to implement on 3GPP access. Therefore, I'm not at all certain this sentence is really valid in wide-scale:
--
Finally, operators can make IPv6 as the default for always-on mobile connections, and use IPv4 (private) addressing only on-demand.
--

The parallel IPv4 and IPv6 bearer usage should anyhow be transitional phase until the whole network supports IPv4v6 type of bearer. Then with IPv4v6 your cost structure *relating to PDN connections* should be similar to just having IPv6? 

Best regards,

Teemu

> Sent: 19. huhtikuuta 2010 02:26
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> > I think the draft, now that it is WG draft, should reflect the
> conclusions that have been already achieved and not restart transition
> mechanism selection discussions...
> >
>

---

From: Rémi Després <[email-masked]>
Date: Mon, 19 Apr 2010 19:02:37 +0200

> The ID states that the IETF dual-stack model is readily applicable in mobile networks, and that's the likely deployment model for a majority of mobile providers today. 

"Likely", yes, but not "recommended" as IPv6-only in the text as is. 
> Separately, IPv6-only deployments may be relatively few, but need to be looked into.

"Looked into", I do agree, but not prematurely "recommended".

Among problems I see, one is IMHO very important:
- E2E transparency is a key feature that IPv6 restores.
- If DNS64-NAT64 synthesizes IPv6 addresses that hosts don't distinguish today from real IPv6 addresses, this destroys the IPv6 guarantee of e2e transparency.

In my understanding, until all concerned applications do recognize IPv4-embeded IPv6 addresses from real ones, DNS64-NAT64 will be harmful to IPv6, and should be advised against.

Dual-stack deployments (with NAT44 CGNs and guaranteed IPv6 e2e transparency), offer on the other hand a clean IPv6 service that IPv6-only deployments with DNS64-NAT64 can't offer.

> In IPv6-only deployments, there can be no IPv4 connectivity (PDN/PDP) at all.  Please see more below.

In sec 3.3, you have (asterisks added):
   " Hence a service provider may
   choose to enforce IPv6-only PDN and address assignment for their own
   subscribers in their Home Networks, see Figure 1.  This is feasible
   for the newer MNs when the provider's network is "IPv6-ready", which
   means the network is able to provide IPv6-only PDN support *and
  IPv6 - IPv4 interworking*  for Internet access."

I therefore understood the considered "IPv6-only" networks as having DNS64-NAT64s (not as having no IPv4 connectivity at all). 

> ...

Isn't it true that the lack of IPv6 connectivity of some 3G UMTS networks is independent from whether LTE networks are dual-standard or not?

> ...
> Dual-stack is the recommended model.

Making it very clear will then be an improvement (IMHO). 

> "In summary, IPv6-only deployments should be encouraged while considering the roaming and applications issues"

I still can't agree on this because:
- The market of real IPv6-ony is too limited.
- IPv6-only + DNS64-NAT64 is harmful to IPv6 e2e transparency.
- With simple additions in LTE MNs port-restricted public IPv4 addresses can be made available across IPv6-only access networks, which reconciles IPv6 e2e transparency and IPv4 connectivity with an IPv6-only routing plan in LTE access networks. (About this, see also what I answered to Cameron Byrne in http://ops.ietf.org/lists/v6ops/v6ops.2010/msg00609.html).

IMHO, if your draft can be a great informational document if relieved of general "encouragements" to deploy IPv6-only (at least as long as it implicitly goes with DNS64-NAT64), and if noting the conflict between IPv6 e2e transparency and DNS64-NAT64.

Best Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 19 Apr 2010 19:04:44 +0200

> In my opinion, IPv6+NAT64 is less evil than IPv6+NAT44.

Different view here.
See in particular my answer to Rajeev.

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Mon, 19 Apr 2010 19:25:38 +0200

Le 16 avr. 2010 à 20:05, Fred Baker a écrit :

> While it is not itself a consensus document (I'd like to make it one, but that's another discussion), I believe that it represents the current IETF consensus.

As I said in Anaheim, adding some reference to 6rd to this draft would IMHO make it an even better document:
- The draft says:"This document discusses the IPv6 deployment models and migration tools, and recommends ones that have been found to work well in many common   situations."
- The first large scale IPv6 deployment based on 6rd was operational in december 2007 (ref RFC 5569), and has worked satisfactorily since then.
- As Google has seen, it has led to the largest native IPv6 use in 2008-2009. 

Regards,
RD

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 19 Apr 2010 10:30:16 -0700

> - IPv6-only + DNS64-NAT64 is harmful to IPv6 e2e transparency.

Why must IPv6 be pure? There is no precedent for IPv6 by nature of its
structure being pure or meaning E2E transparency. NAT-PT has been
around in the IPv6 ecosystem for a long time, so IPv6 addresses
representing IPv4 destinations is by no means new.  I agree that IPv6
is the path to E2E transparency, but IPv6 does not imply e2e by virtue
of the technology. IMHO IPv6-only expedites that journey to e2e.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 19 Apr 2010 13:47:45 -0400

On 2010-04-19 13:02, Rémi Després wrote:
> - If DNS64-NAT64 synthesizes
> IPv6 addresses that hosts don't distinguish today from real IPv6
> addresses, this destroys the IPv6 guarantee of e2e transparency.
>
> In my understanding, until all concerned applications do recognize
> IPv4-embeded IPv6 addresses from real ones, DNS64-NAT64 will be
> harmful to IPv6, and should be advised against.
>
> Dual-stack deployments (with NAT44 CGNs and guaranteed IPv6 e2e
> transparency), offer on the other hand a clean IPv6 service that
> IPv6-only deployments with DNS64-NAT64 can't offer.

In both situations there is a NAT only for IPv4-only services, and 
nowhere else. I fail to see why one would be "cleaner" than the other.

Simon

---

From: Fred Baker <[email-masked]>
Date: Mon, 19 Apr 2010 10:47:39 -0700

>> - If DNS64-NAT64 synthesizes IPv6 addresses that hosts don't distinguish today from real IPv6 addresses, this destroys the IPv6 guarantee of e2e transparency.

Only for communications that leave the IPv6 domain and are translated to IPv4, which already has this problem. If the communication stays within the IPv6 domain, whether the two hosts know it or not, they are communicating transparently.

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 19 Apr 2010 10:53:16 -0700

Hi Jouni,

> We have seen mobiles trying to be too clever here as well (not for preserving
> IPv4 addresses but battery). However, the outcome will be more or less the
> same if the document encourages establishing and tearing down connections "in
> a clever way". 

The document is not proposing any cleaver ways. This is tied to PDN/PDP
session management. Whether we like it or not, session timers can clean up
state.

> I am not concerned about MN doing IP layer signaling, that's peanuts. I am
> worried about the signaling caused by the MN playing around with the PDN
> connection that is then seen between core network nodes as signaling bursts.
> This is an issue especially with pre-LTE stuff, which seems to be the part
> that would actually get affected by recommendation of on-demand IPV4
> connection management.. Even if the draft targets for the LTE, majority of the
> networks will be mix of 3G and LTE for a long time. Some text explaining pros
> and cons/side effects would actually be all that is needed.

Could you explain the signaling bursts?

Agree on the comment about LTE and 3G coexistence.

> Not really.. that's why this document could/should actually make a clear
> distinction which of the recommended models/approaches apply where.

So, the issue here is really about getting some clarity on split-UE in 3GPP,
right? Currently, the document does not differentiate the cases, but I could
some text in the next version.

> As for data volumes that will probably be the dominant. Also, notebooks with
> cellular broadband access seem to be and become increasingly popular..

I would think that dongles, built-in laptop models would be more prevalent..

Thanks,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 19 Apr 2010 11:26:12 -0700

On 4/19/10 10:02 AM, "Rémi Després" <[email-masked]> wrote:

>> The ID states that the IETF dual-stack model is readily applicable in mobile
>> networks, and that's the likely deployment model for a majority of mobile
>> providers today.
> 

I will make it explicit that dual-stack is the IETF recommended model.
However, I do think that IPv6-only deployments in mobile networks need to be
*looked into* and *encouraged*. See below..

> - If DNS64-NAT64 synthesizes IPv6 addresses that hosts don't distinguish today
> from real IPv6 addresses, this destroys the IPv6 guarantee of e2e
> transparency.
> 
> IPv4-embeded IPv6 addresses from real ones, DNS64-NAT64 will be harmful to
> IPv6, and should be advised against.
> 
> Dual-stack deployments (with NAT44 CGNs and guaranteed IPv6 e2e transparency),
> offer on the other hand a clean IPv6 service that IPv6-only deployments with
> DNS64-NAT64 can't offer.

We are trying to get to IPv6 which offers many things (including e2e
transparency), but we have to face the fact that it is not a clean switch.
Some folks argue that investments in NAT44 would "silo" IPv6 into some
select usage only. Other folks do not wish to have to worry about private
IPv4 addressing at all; this can be argued as an impending acute problem in
mobile networks. Yet another consideration is the need to maintain multiple
PDN/PDP if you do separate IPv6 and IPv4. IPv6-only deployments offer *a*
choice here. Whether it comes with a clean switch is moot. So, there are
tradeoffs.
 
Having said this, dual-stack is the easier choice for many. The draft BTW is
not preferring one over the other.

> I therefore understood the considered "IPv6-only" networks as having
> DNS64-NAT64s (not as having no IPv4 connectivity at all).
> 

It's both: no IPv4 connectivity, and IPv6 - IPv4 interworking.

Dual-stack deployments do not have either of these.

>> ...
>> I could reword the last sentence to: "For instance, if an LTE deployment is
>> IPv6-only, a roamed 3G UMTS network may not offer IPv6 connectivity"
> 
> Isn't it true that the lack of IPv6 connectivity of some 3G UMTS networks is
> independent from whether LTE networks are dual-standard or not?
> 

Yes. However, the point here is that if an LTE deployment chooses to be
IPv6-only, a roamed 3G network may not offer IPv6 connectivity, which means
the home network (that offers IPv6-only service) needs to be able to provide
IPv4 connectivity to such roamed users.

> Making it very clear will then be an improvement (IMHO).

Check.

> - The market of real IPv6-ony is too limited.

Well, someone has to start. There are arguments on why some want to do
IPv6-only in mobile networks.

> - IPv6-only + DNS64-NAT64 is harmful to IPv6 e2e transparency.

See comments above.

> - With simple additions in LTE MNs port-restricted public IPv4 addresses can
> be made available across IPv6-only access networks, which reconciles IPv6 e2e
> transparency and IPv4 connectivity with an IPv6-only routing plan in LTE
> access networks. (About this, see also what I answered to Cameron Byrne in
> http://ops.ietf.org/lists/v6ops/v6ops.2010/msg00609.html).

I understand. Making changes to MNs is another story. I reckon 3GPP would be
a good place to bring this kind of proposal.

> 
> IMHO, if your draft can be a great informational document if relieved of
> general "encouragements" to deploy IPv6-only (at least as long as it
> implicitly goes with DNS64-NAT64), and if noting the conflict between IPv6 e2e
> transparency and DNS64-NAT64.

Thanks. 
However, I do believe that there is a case for IPv6-only deployments from a
variety of angles, including - private IPv4 address exhaustion, side effects
of overlapped addresses etc., investments in NAT44, speedier transition to
IPv6 and so on. This does have costs associated with it, as you point out
above.

It may be worthwhile to refer to NAT64+DNS64 considerations to an
appropriate BEHAVE document?

Again, I would point out that the ID is not intending to prefer IPv6-only
over Dual-stack. The latter is the default, the former should be a choice,
at least for some. I will clarify..

Thanks,

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 19 Apr 2010 12:11:00 -0700

Hi Teemu,

We need to separate this into what is already specified and what the draft
is saying. This draft is not introducing a host change in the form of DHCP.
3GPP has already included DHCP as a mechanism. Please see below.

> 1) a host has to support DHCP for 3GPP access at first place

If PGW includes a Deferred Address Allocation PCO in Create Session Response
(and hence no IPv4 address in it), the host has to do DHCP.

> 2) a host has to support deferred DHCP for 3GPP access (reserve/release

Yes, some hosts do this based on application trigger. OTOH, you could
initiate DHCP right away (after attach) but the network could use shorter
lease times. 

> 3b) If DHCP is not used, host shall get the address from bearer signaling

Yes. This is part of 3GPP TS 23.401, TS 29.274/5.

> Also in LTE the DHCP is optional for both host and network.

My understanding is that the assignment at attach is default, but PGW may
choose to instead use DHCP.

> 
> So what I'm also saying is that it is not so straightforward to use IPv4
> on-demand with DHCP as I think the draft is implying (but maybe it is just my
> view), which is a concern for feasibility of this approach (recall how in 3GPP
> discussions getting transition mechanism changes to hosts was considered so
> hard).
> 

Let us try to separate the issues here.

1. When DHCP is initiated. 1a) right after attach, 1b) as a response to an
application trigger. Your concern is with 1b) right?

2. Regardless of 1a), 1b), a network could use lease times of its choice
right (subject to pros/cons)?

> This DHCPv4 on-demand sound for me quite like a host based transition
> mechanisms (DSTM without encapsulation?).

Hmm..interesting. Going by this, one could argue that DHCP with shorter
lease times is host based transition, and the network cleaning up PDN/PDP
sessions due to timers is network-based transition :-)
 
> 
> Furthermore, to gain real benefits a significant host population should
> support this, and it may or may not be a challenge depending on LTE deployment
> schedules and speed.
> 

IMO, a mobile network provider may require DHCP from vendors. Not all
providers may go for it, but some may find it useful.

Thanks,

-Rajeev

---

From: jouni korhonen <[email-masked]>
Date: Mon, 19 Apr 2010 22:12:27 +0300

Hi Rajeev,

One clarification below..

On Apr 19, 2010, at 8:53 PM, Rajeev Koodli wrote:

[snip]

> I would think that dongles, built-in laptop models would be more prevalent..

Bad terminology or rather grouping my side. I actually summed UE-as-a-modem and build-in stuff as the same (point being that dongles, build-in modems and UE-as-a-modem are all used in a similar manner from e.g. a laptop point of view).

- Jouni

[sanp]

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 19 Apr 2010 12:21:59 -0700

On 4/19/10 4:07 AM, "[email-masked]"
<[email-masked]> wrote:

> Yes, that meeting and discussion before that. The host based transition
> mechanisms were rejected because transition was agreed to be more easily done
> by networks than by all hosts - and hosts were discussed to have dual-stack
> connectivity or IPv6-only connectivity. I agree these discussions sound
> echoing, they are, but for me it seems there is interest to restart this
> discussion again as the draft that, from my point of view, talks about host
> based transition mechanism called "DHCPv4 on-demand", was adopted...

Let me assure you that I am *not* interested in restarting a new discussion
on transition mechanisms, that too a *host-based* one! :-)

> 
> In my opinion the draft can mention it is possible to build such IPv4 address
> on demand system, but for it to be really useful it would have to be supported
> by wide variety of hosts, and that is not at all certain because as said many
> times, DHCP is optional to implement on 3GPP access.

Sure, I will add the corresponding text.

> Therefore, I'm not at all
> certain this sentence is really valid in wide-scale:
> --
> Finally, operators can make IPv6 as the default for always-on mobile
> connections, and use IPv4 (private) addressing only on-demand.
> --

Fair enough. I will add additional text as mentioned above.

Thanks,

-Rajeev

> 
> The parallel IPv4 and IPv6 bearer usage should anyhow be transitional phase
> until the whole network supports IPv4v6 type of bearer. Then with IPv4v6 your
> cost structure *relating to PDN connections* should be similar to just having
> IPv6? 
> 
> Best regards,
> 
> Teemu
>

---

From: jouni korhonen <[email-masked]>
Date: Mon, 19 Apr 2010 22:36:20 +0300

Hi Rajeev,

Thanks again for you answers. Few more comments inline.

> session management. Whether we like it or not, session timers can clean up

Ok. The draft could actually mention that. Session idle timers controlled IPv4 PDP context/PDN connection tearing down from network side sounds reasonable.

> Could you explain the signaling bursts?

Establishing and tearing down a PDP context/PDN connection is a costly operation system wide. You don't want to do that too frequently unless you somehow have determined the connection is idle or so (which might be somewhat impossible.. considering e.g. how talkative modern OSes are).

Cheers,
	jouni

[snip]

---

From: <[email-masked]>
Date: Mon, 19 Apr 2010 23:24:44 +0200

Hi Rajeev,

> 3GPP has already included DHCP as a mechanism. Please see below.

It has, as optional. This draft in my opinion talks like DHCP would be commonplace. See below.

> (and hence no IPv4 address in it), the host has to do DHCP.

Incorrect. Standard does not allow network to behave that way.

23.401 says:
--
- the UE may indicate that it prefers to obtain an IPv4 address as part of the default bearer activation procedure. In such a case, the UE relies on the EPS network to provide IPv4 address to the UE as part of the default bearer activation procedure.
--
Both EPS network elements and UE shall support the following mechanisms:
a. IPv4 address allocation via default bearer activation, if IPv4 is supported.
--
Both EPS network elements and UE may support the following mechanisms:
a.	IPv4 address allocation and IPv4 parameter configuration after the attach procedure via DHCPv4 according to RFC 2131 [19] and RFC 4039 [25];
--

Please note the *shall* for both EPS network and UE to support IPv4 address allocation in bearer activation, and *may* for both EPS network and UE to support DHCPv4.

Hence as DHCP is optional for UE, network cannot force DHCP usage for UE supporting only the *shall* and that is not indicating support for DHCP, which is *may*.

This is the specification I read. There are many of those, so please point to specification where you read host must do DHCP if network so says.

> > 2) a host has to support deferred DHCP for 3GPP access
> (reserve/release
> > on-demand)
> 

Right, some hosts may, but not all. Especially those that don't do DHCP for 3GPP.

> > 3) a host has to support negotiation of used address allocation
> mechanism for
> > 3GPP access:
> > 3b) If DHCP is not used, host shall get the address from bearer
> signaling
> > instead
> 

Yes, but this is *may* per 3GPP TS 23.401. Your draft should be more explicit in telling that the percentage of host population that actually implements the *may* part is unknown for time being.

> My understanding is that the assignment at attach is default, but PGW
> may choose to instead use DHCP.

Yes if UE indicates optional DHCP support.

> application trigger. Your concern is with 1b) right?

Of those two, my concern is 1b.

But the bigger concern is talking so much about DHCP that is optional by standard.
 
> right (subject to pros/cons)?

Right. But the lease time is IMHO mostly irrelevant, if the host is stubborn to just renew even if it hasn't applications running. Thus the host would have to be smart enough not to renew if it doesn't have imminent need for IPv4.

> lease times is host based transition, and the network cleaning up
> PDN/PDP sessions due to timers is network-based transition :-)

As said, DHCP with short lease times and network cleaning PDP sessions does help nothing if the host has decided to keep IPv4 connection up "just in case", and instantly renews what network tries to bring down. You must have host support not to open "just in case".

> providers may go for it, but some may find it useful.

This is absolutely true. However, the standard does not mandate DHCP. Hence the standard documents, like this draft, should be clear on what is certainly available by standards compliant devices (that implements musts and shalls), and what may require something extra (i.e. what is possible by standard, but not necessarily supported by default - the mays).

Best regards,

Teemu

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 19 Apr 2010 18:45:56 -0700

> Incorrect. Standard does not allow network to behave that way.

Agree, I wrote too soon. UE includes a PCO for DHCP which is carried in
Create Session Request.

> Right, some hosts may, but not all. Especially those that don't do DHCP for

What about the laptops with built-in 3G/4G or using UE as a modem?

> 
> Yes, but this is *may* per 3GPP TS 23.401. Your draft should be more explicit
> in telling that the percentage of host population that actually implements the
> *may* part is unknown for time being.
> 

I would rather say that DHCP is optional but a provider may require it to be
used.

> But the bigger concern is talking so much about DHCP that is optional by

Actually I would have to talk much now (there are just a couple of sentences
currently) :-)

Optional does not mean that it is not used (and vice versa).
In our context here, it is up to a service provider to require it if they
feel there is value in using it for their IPv4 address management.

> Right. But the lease time is IMHO mostly irrelevant, if the host is stubborn
> to just renew even if it hasn't applications running. Thus the host would have
> to be smart enough not to renew if it doesn't have imminent need for IPv4.
> 

Sure, hosts can do clever stuff. Providers may have compliance requirements
if a node is to be on their network OTOH (I am not justifying the approach
itself, but pointing it out).

> As said, DHCP with short lease times and network cleaning PDP sessions does
> help nothing if the host has decided to keep IPv4 connection up "just in
> case", and instantly renews what network tries to bring down. You must have
> host support not to open "just in case".
> 

See above. In summary, for a significant population of hosts, session timers
may be useful. For "just in case" hosts, this may be less useful.

-Rajeev

> This is absolutely true. However, the standard does not mandate DHCP. Hence
> the standard documents, like this draft, should be clear on what is certainly
> available by standards compliant devices (that implements musts and shalls),
> and what may require something extra (i.e. what is possible by standard, but
> not necessarily supported by default - the mays).
> 
> Best regards,
> 
> Teemu

---

From: <[email-masked]>
Date: Tue, 20 Apr 2010 08:50:40 +0200

> What about the laptops with built-in 3G/4G or using UE as a modem?

I don't know much about how that interface usually goes (PPP or DHCP+Ethernet), but sure laptops could be modified e.g. by driver updates(?). But then I don't know about laptop OS'es capability for doing DHCPv4 on-demand (I would expect the laptop OS'es would rather try to keep IPv4 address allocated all the time).

> I would rather say that DHCP is optional but a provider may require it
> to be used.

Right, consumers often has this power over producers..

Best regards,

Teemu

---

From: Rémi Després <[email-masked]>
Date: Tue, 20 Apr 2010 10:38:30 +0200

Le 19 avr. 2010 à 19:30, Cameron Byrne a écrit :

> structure being pure or meaning E2E transparency.

> NAT-PT has been
> around in the IPv6 ecosystem for a long time,

... but deprecated almost as soon as documented,

> so IPv6 addresses
> representing IPv4 destinations is by no means new.  

Not new as an idea, but AKAIK not deployed as a standard service.
Note that the DS-lite approach, in which IPv6-only access networks maintain IPv4 connectivity with NAT44s rather than NAT64s, doesn't need IPv4-embedded IPv6 addresses. 

> I agree that IPv6
> is the path to E2E transparency,

More than that: users of IPv6 today HAVE e2e transparency in IPv6.
DNS64-NAT64 in operator infrastructures, if done without serious precautions, is a path to BREAKING IPv6 e2e transparency.
This may be regrettable, but this in my understanding an inescapable fact.  

> but IPv6 does not imply e2e by virtue
> of the technology.

It just RESTORES e2e transparency, which had been lost when one address per host became impossible.

This happened long ago, and launched the painful complexity of NATs (cone, symmetric, port-resticted symmetric etc.), of their ALGs, of sophisticated tools to make pinholes in traversed NAT like TURN, STUN, Teredo, etc.

> IMHO IPv6-only expedites that journey to e2e.

Again, hosts that communicate today with public IPv6 addresses HAVE e2e transparency. 
This journey is therefore already finished... unless a step backward is consciously made to reintroduce complexity where it shouldn't exist :-(.

Note that NAT64 between a private scope IPv6 address (e.g. a ULA of RFC 4193) and IPv4, doesn't suffer from breaking e2e transparency, because private addresses have to be translated somewhere. This could provide a way for applications to know whether they can rely on e2e transparency or not, but this requires in my understanding more work.
   
Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 20 Apr 2010 11:06:47 +0200

Le 19 avr. 2010 à 19:47, Fred Baker a écrit :

> Only for communications that leave the IPv6 domain and are translated to IPv4, which already has this problem.

This problem is indeed inherent to NAT64.
But fortunately it is not inherent to the more general problem of IPv4 connectivity across IPv6-only access network:
- If hosts are dual stack, and have means to encapsulate IPv4 in IPv6 across provider access networks, no IPv6-IPv4 translation is necessary.
- This is possible in particular with DS-lite, where operator NATs are NAT44s.
- This is also possible with the reversed 6rd I plan to document and which is essentially as simple as 6rd (encapsulations with stateless address mappings). With it, customer sites can derive from their IPv6 addresses their IPv4 addresses (typically shared, with disjoint port sets). Where applicable, no operator NAT at all is needed.

> If the communication stays within the IPv6 domain, whether the two hosts know it or not, they are communicating transparently.

Right, but, unless it is impossible, e2e transparency in IPv6 should also apply across the Internet in general. 
(And AFAIKT this is NOT impossible).

Regards,
RD

---

From: Rémi Després <[email-masked]>
Date: Tue, 20 Apr 2010 11:42:20 +0200

> It's both: no IPv4 connectivity, and IPv6 - IPv4 interworking.

OK, this is a vocabulary problem.
(To me, NAT64s provide IPv4 connectivity to hosts that are IPv6-only enabled.)

> Dual-stack deployments do not have either of these.

Here, I am confused.
In my understanding, dual stack everywhere provides IPv4 connectivity.

> IPv4 connectivity to such roamed users.

I see, and like better this way of saying it.

> IPv6-only in mobile networks.

I understand the argument about a single routing family in the access network, and agree with it.
But like 6rd permits public IPv6 across IPv4-only infrastructures, reversed 6rd (say 4rd) permits to offer public IPv4 (typically port-restricted) across IPv6-only infrastructures.

Since LTE handsets are new, having in them the simple support of 4rd shouldn't be a big deal, and AFAIKT would avoid, with operators that also support 4rd all problems associated with IPv4-IPv6 translations.
It is clear that, until an easy to read and complete enough description of 4rd is available, entering into more details is difficult.
I should therefore concentrate on writing it.
    
> a good place to bring this kind of proposal.

I do think so, very much so.
I hope we can try to proceed quickly in this direction.

> IPv6 and so on. This does have costs associated with it, as you point out

If you agree, we can resume the discussion when the 4rd description is available.

> appropriate BEHAVE document?

Maybe, but your draft seems a good place to start with.

> at least for some. I will clarify..

Thanks for this discussion.
RD

---

From: Cameron Byrne <[email-masked]>
Date: Tue, 20 Apr 2010 07:11:34 -0700

> This journey is therefore already finished... unless a step backward is consciously made to reintroduce complexity where it shouldn't exist :-(.

With all due respect,  I don't think you and I will come to an
agreement, we simply have different priorities and values. A major
network that I work at will take this "step backwards" with IPv6-only
and NAT64, it is already deployed in a trial, the trial is going VERY
well.  The customer experience on IPv4 + NAT44 and IPv6 + NAT64 are
identical for the target handsets and users.   IMHO, your arguments
are not strong enough to justify yet another solution and will not
appeal to mobile operators.  Mobile has IPv6 solutions, they were
described in full at the San Francisco 3GPP-IETF meeting, and I
believe operators are moving forward with those solution, the timeline
requires movement now.  A major outcome from that San Francisco
meeting that you need to be very aware of is that there is a very
large resistance to adding new features to the mobile handset.  As
soon as you bring that up, the mobile operator will dismiss 4RD just
as they moved away from PNAT and DS-Lite.

I don't believe you are communicating with IPv6 hosts at NetFlix and
Google, right?  Your e2e is between a host and a stateful load
balancer doing protocol translations.  Like many thing, if it works
today and is inexpensive, it gets deployed.

In any technology decision, trade-offs must be made.  IMHO, NAT64
trades off some E2E (IPv4 is NAT44 anyways today) to expedite the
deployment of IPv6 where all flows will have E2E (aside from content
load balancers).  Given that IPv4 is NAT44 today, going to NAT64 is
steady state, no new downsides and I get the upside of direct e2e for
ipv6.

> Note that NAT64 between a private scope IPv6 address (e.g. a ULA of RFC 4193) and IPv4, doesn't suffer from breaking e2e transparency, because private addresses have to be translated somewhere. Thi…

Not sure of the value of this.

Thanks for the discussion.

Cameron

---

From: Rémi Després <[email-masked]>
Date: Tue, 20 Apr 2010 18:44:50 +0200

Le 20 avr. 2010 à 16:11, Cameron Byrne a écrit :

> identical for the target handsets and users.

User experience may be the same so far but, to take an example, the impossibility to translate UDP datagrams with null checksum exists in NAT64s and doesn't exist in NAT44s. 
(With all due respect, the fact that a decision has been made doesn't forbid to look at its foreseeable consequences, without any taboo.)
 
>   IMHO, your arguments
> requires movement now.  

"Moving forward" with dual-stack routing IS possible (no need for another solution for a deployment today).
Depending on interpretation, it remains the ONLY recommended model, or just one of them.
(As you have understood, dual stack should be IMHO remain so far the ONLY recommended model.)

One can choose to deploy NAT64, taking then the responsibility for all known and foreseeable consequences.  

> A major outcome from that San Francisco
> large resistance to adding new features to the mobile handset.  

I certainly didn't wait for this meeting to notice it.
That's why dual-stack is the safest way to avoid urgent fixes in mobile handsets when problems that were never experienced before but are foreseeable start to appear.

> As

You may be right. 

LTE could however have been a nice opportunity to include in the specification a simple complement to IPv6 drivers, to the effect that:
- port-restricted IPv4 would be statelessly available across IPv6-only LTE infrastructures 
- LTE access networks could have been deployed with IPv6 only in routers and without any DNS64-NAT64 to be supported (an important saving in operational costs)

Note that 4rd is also a solution for DSL operators, applicable between ISP border routers and home gateways (like 6rd), which may be sufficient for its future.

> today and is inexpensive, it gets deployed.

I don't use NetFlix.

I never doubted that when using Google, or the IETF site, servers were directly accessible in IPv6.
(IPv6 load balancers would no longer be load balancers if they would have to do, in addition to their essential function, IPv6-IPv4 translations.)

In my understanding, that's solutions without NAT64s that so far ARE deployed, and work, and are inexpensive (with 6rd being a particular tool for this in ISP environments).

> steady state, no new downsides and I get the upside of direct e2e for

NAT64 is NOT steady state from NAT44, for various reasons (UDP null checksum, being one of them).
Dual-stack is much more steady state.

Regards,
RD

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 20 Apr 2010 14:27:25 -0700

> In my understanding, dual stack everywhere provides IPv4 connectivity.

Right. I meant Dual-stack deployments *do not* have "*no* IPv4 connectivity
&& IPv6-IPv4 interworking" considerations.

> But like 6rd permits public IPv6 across IPv4-only infrastructures, reversed
> 6rd (say 4rd) permits to offer public IPv4 (typically port-restricted) across
> IPv6-only infrastructures.
> 
> Since LTE handsets are new, having in them the simple support of 4rd shouldn't
> be a big deal, and AFAIKT would avoid, with operators that also support 4rd
> all problems associated with IPv4-IPv6 translations.
> It is clear that, until an easy to read and complete enough description of 4rd
> is available, entering into more details is difficult.

Okay.

> If you agree, we can resume the discussion when the 4rd description is

Okay.

> Maybe, but your draft seems a good place to start with.

I was wondering if these issues are already documented somewhere..

> Thanks for this discussion.

Welcome.

-Rajeev

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 20 Apr 2010 14:29:33 -0700

On 4/19/10 11:50 PM, "[email-masked]"
<[email-masked]> wrote:

> I don't know much about how that interface usually goes (PPP or
> DHCP+Ethernet), but sure laptops could be modified e.g. by driver updates(?).
> But then I don't know about laptop OS'es capability for doing DHCPv4 on-demand
> (I would expect the laptop OS'es would rather try to keep IPv4 address
> allocated all the time).
> 

We should make this distinction (laptops, UE-only). Laptop OS's do support
DHCP obviously. 

-Rajeev

---

From: joel jaeggli <[email-masked]>
Date: Tue, 20 Apr 2010 15:13:32 -0700

>> (I would expect the laptop OS'es would rather try to keep IPv4 address

There's traditional tethering vs the cpe approach, at the point where 
the handset simply acts a a router, maintenance of the pdp context(s) 
and indeed the whole air interface is solely at the discretion of the 
handset/router, and the PC is invisble in that equation.