Subject: [BEHAVE] Where is the definition of IPv6 only host for NAT64/DNS64

From: Hui Deng <[email-masked]>
Date: Mon, 13 Jul 2009 23:10:27 +0800

Could anybody kindly help to point out the link I could study?

-Hui

---

From: Hui Deng <[email-masked]>
Date: Thu, 16 Jul 2009 16:30:12 +0800

Hi, Dave,

Thanks for your detail explanation.
Since current world wide computer, maybe 99.99% already have dual stack ability.

does this mean NAT64/DNS64 are solving the problem 0.001% of the
Internet computer?

Thanks again.

-Hui

2009/7/16 Dave Thaler <[email-masked]>:
> Hi Hui,
>
> I didn't see if this was answered before, but "IPv6 only" is currently
> defined in draft-ietf-behave-v6v4-framework-00 section 1.2, though
> I think the definition needs work:
>
>>   IPv6-only:  An IPv6-only implementation, in this context, comprises
>>     an IPv6 enabled end system stack plus routing in the network.  It
>>     implies that two application instances are capable of
>>     communicating using IPv6, but not IPv4 - they have an IPv6 stack,
>>     addresses, and network support including routing in IPv6, but some
>>     element is missing that prevents communication with IPv4 hosts.
>
> The dns64 draft also contains this statement in section 2:
>
>> By
>> IPv6-only hosts we mean hosts running IPv6-only applications, IPv6-
>> only hosts, as well as the cases where only IPv6-only connectivity is
>> available to the client.
>
> -Dave
>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On
>> Behalf Of Hui Deng
>> Sent: Monday, July 13, 2009 8:10 AM
>> To: [email-masked]
>> Subject: [BEHAVE] Where is the definition of IPv6 only host for
>> NAT64/DNS64
>>
>> _______________________________________________
>> Behave mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/behave
>
>

---

From: Dave Thaler <[email-masked]>
Date: Thu, 16 Jul 2009 03:37:03 +0000

Hi Hui,

-Dave

---

From: "Dan Wing" <[email-masked]>
Date: Thu, 16 Jul 2009 10:54:28 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Hui Deng
> Sent: Thursday, July 16, 2009 1:30 AM
> To: Dave Thaler
> Cc: [email-masked]
> Subject: Re: [BEHAVE] Where is the definition of IPv6 only 
> host forNAT64/DNS64
> 
> Hi, Dave,
> 

Operating dual stack increases the operational complexity (and
thus cost) of the host and the dual-stack network.  Running
dual stack also consumes an IPv4 address, so thus does not help
IPv4 exhaustion.  If a service provider cannot get IPv4 
addresses, they can't run dual stack.  

The host could operate dual stack, and have its IPv4 traffic
NATted, such as is done by Dual-Stack Lite.  But stateful 
NAT of multiple IPv4 subscribers to one IPv4 address incurs 
all of the pain of NAT -- breaks end-to-end model; necessarily 
restricts each subscriber to a limited number of TCP/UDP ports; 
restricts user to 3 protocols (TCP, UDP, ICMP); and so on.

> does this mean NAT64/DNS64 are solving the problem 0.001% of the

Most, if not all, of the mobile providers are anticipating IPv6-only handsets
on their LTE/"4G" networks.  Some companies, some universities, and some
wireline service providers, in an effort to reduce the operational complexity
of the end hosts and their network, want to run a single-stack network with
IPv6.  Those handsets and those hosts would still need to contact servers on
the IPv4 Internet.

Most of this should be explained in the Framework document,
draft-ietf-behave-v6v4-framework-00.  If additional text should be added to
explain the use cases please suggest text!  Send your suggestions to the list
or to the authors.  

-d

---

From: Dave Thaler <[email-masked]>
Date: Thu, 16 Jul 2009 17:03:47 +0000

> From: Hui Deng [mailto:[email-masked]]
> Subject: Re: [BEHAVE] Where is the definition of IPv6 only host for
> NAT64/DNS64
>
> Hi, Dave,
>

No.  Dual-stack implementation is only one of the reasons, which is
one of the reasons I said the framework definition needs work.
The quote in the dns64 draft makes it clearer there are several cases.
The case where the destination has a public IPv6 but not a public IPv4
address (just a private IPv4 address), but the source is running an
IPv4-only app, is an increasingly common case.

-Dave

---

From: Hui Deng <[email-masked]>
Date: Fri, 17 Jul 2009 18:19:19 +0800

Hi, Dave,

I couldn't agree with you any more about the common case,
a public IPv6 but not a public IPv4 address (just a private IPv4 address),
and the source is running IPv4 only app.

One of key scenario of our PNAT proposal is targetting to that.

Many thanks

-Hui

---

From: Hui Deng <[email-masked]>
Date: Fri, 17 Jul 2009 18:31:36 +0800

Hi, Dan

Thanks for the discussion, reply inline.

> addresses, they can't run dual stack.
==>It's still easy the host could get private IPv4 address
or public IPv4 address +port number

> restricts user to 3 protocols (TCP, UDP, ICMP); and so on.
==> it is the pain, but it is still expanding, more and more mobile
internet service developed based on this model.

> IPv6.  Those handsets and those hosts would still need to contact servers on
==> China Mobile is leading IPv6 transition work item in 3GPP, acting
as a rapporteur.
I personally deeply involve in this work, but until today, I haven't
heard about IPv6 only handset
requirement proposed.

> explain the use cases please suggest text!  Send your suggestions to the list
==> Sure, as Dave said, I will think about and try to propose text.

thanks again

-Hui

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 17 Jul 2009 08:59:01 -0700 (PDT)

> or public IPv4 address +port number

It is not easy to get private addresses. Most of the large mobile operators that I know of, including my own, are completely out of RFC1918 addresses (between enterprise networks, wifi networks, 2g, 3g, 4g).  

We could not get traction with moving 240/4 to be legal private space, so we must use "illegal addresses" from RFC3330 and other places.  This is a very common practice in the enterprise world, and now it is becoming common in the infrastructure world out of necessity.  Other mobile operators i know must NAT RFC1918 addresses between regions within their own networks, such that they break the end to end model, even within their own network!  NAT internal to the mobile operator's network is a big challenge on a mobile provider's ability to do VoIP and IMS in an always-on All-IP network.

> internet service developed based on this model.

Agreed, it is a pain.  And expensive.  NAT64 is our salvation to this pain.  When i launch NAT64 in my network, in the worst case, I will have exactly the same amount of state i have today for each flow.  99% of my traffic today is NAT44. I do busy hour gigs and gigs of NAT44.   As soon as i turn up NAT64 with an IPv6 only mobile device (UE), I will have less state in my network since at least flows to google.com will be end-to-end IPv6 with no state required.  Going to google.com today requires NAT44 in my network.  As IPv6 gains more traction, i will have less and less NAT state as more and more flows are end-to-end IPv6.

> > on their LTE/"4G" networks.  

This is 100% true about 4G networks.  3G as well. In fact, anywhere where the demand for IPv4 exceeds supply, including RFC1918 addresses and bleeding into RFC3330 addresses.  But, the LTE/4G offers a green field opportunity, and frankly IPv4 addresses are not a tactical or strategic option.

>Some companies, some
> universities, and some

Many of the operators i work with, including my own network, are strongly focused and driving towards IPv6 only UE as soon as possible, and the NAT64 work is critical to delivering the IPv6 only UE vision.  Given that we (mobile operators) are already out of IPv4 address, public and private, and that the other LSN strategies don't as gracefully lead us on a path towards end-to-end IPv6,  NAT64 with IPv6 only client / UE is critical to our ability to scale.  I think we all agree that we want IPv6 only devices as the end state, since IPv4 cannot last forever. So making that leap now will serve us better than taking a more circuitous / complicated route. 

Cameron Byrne
Principal Engineer
T-Mobile USA

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 17 Jul 2009 18:10:30 +0200

On 17 jul 2009, at 17:59, Cameron Byrne wrote:

> Given that we (mobile operators) are already out of IPv4 address

Why don't you request more?

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 17 Jul 2009 11:39:06 -0700

> Sent: Friday, July 17, 2009 3:32 AM
> To: Dan Wing
> Cc: [email-masked]; Dave Thaler
> heard about IPv6 only handset requirement proposed.

Dual-stack handset, running on the mobile operator's network, means
the mobile operator:

  * operates two networks (IPv4 and IPv6).  For both IP address
    families you need routing tables, ACLs, DHCP, and training
  * operates a stateful NAT44 for the subscribers to access 
    the IPv4 Internet

IPv6-only handset means the mobile operator:

  * operates one network (IPv6)
  * operates a stateful NAT64 for the subscribers to access 
    the IPv4 Internet

> ==> Sure, as Dave said, I will think about and try to propose text.

Thanks.

-d

---

From: Hui Deng <[email-masked]>
Date: Sat, 18 Jul 2009 22:00:31 +0800

Interesting discussion, T-Mobile (including T-Mobile USA) is a
co-signed operator for 3GPP IPv6 work Item
We appreciate it and will be happy with working together. Anyhow, from 3GPP,
the impression I got is that T-Mobile is not that hurry like the
situation you described above :).
Reply inline.

> It is not easy to get private addresses. Most of the large mobile operators that I know of, including my own, are completely out of RFC1918 addresses (between enterprise networks, wifi networks, 2g…
==> it really depends, most operators running their service network
with public IPv4 address, so they
are not that really running out RFC 1918 addresses as far as I know
based on current 3GPP situation.

> We could not get traction with moving 240/4 to be legal private space, so we must use "illegal addresses" from RFC3330 and other places.  This is a very common practice in the enterprise world, and…
==> I understand the T-Mobile USA's situation, the coming 3GPP SA2
meeting will have the time slot for IPv6 transition,
Please bring the T-Mobile's contribution to that, we could have more
disucssion over there.
I guess everybody in 3GPP knows that T-Mobile is doing GAN, I don't
know whether the statement above about IMS is still valid?

> Agreed, it is a pain.  And expensive.  NAT64 is our salvation to this pain.  When i launch NAT64 in my network, in the worst case, I will have exactly the same amount of state i have today for each…
==> I guess the state of GW have about Google.com will not be a big deal for it.
The most big issue will be how could your conventional IPv4
application running over there.
China Mobile proposed a solution for that, I guess maybe it meet best
the requirement from T-Mobile .
Please kind help to review and comments, thanks
http://www.ietf.org/internet-drafts/draft-huang-pnat-host-ipv6-01.txt
http://www.ietf.org/internet-drafts/draft-chen-host-ipv6-ps-00.txt

> This is 100% true about 4G networks.  3G as well. In fact, anywhere where the demand for IPv4 exceeds supply, including RFC1918 addresses and bleeding into RFC3330 addresses.  But, the LTE/4G offer…
==> I guess there are lots of people who work both 3GPP and IETF or
Wimax and IETF,
they may doubt about it, I personally also hestitate to believe it:)

> Many of the operators i work with, including my own network, are strongly focused and driving towards IPv6 only UE as soon as possible, and the NAT64 work is critical to delivering the IPv6 only UE…
==> if that is true, please contribute to 3GPP about ur scenario, that
is the best place to do it, but I haven't see anything happen there.
The best and fast way to do it is to move the service network to IPv4
public address, which may save us 20 years until IPv6 really is
needed.

For the end of day, IPv6 only Internet, I don't know how far it is, do
we really need to solve that problem at the moment.

thanks for the discussion

-Hui

---

From: Hui Deng <[email-masked]>
Date: Sat, 18 Jul 2009 22:11:52 +0800

>  * operates a stateful NAT44 for the subscribers to access
==> Mobile opeartor network architecture is different from fixed operator,
the situation is not that really hard,

>  * operates a stateful NAT64 for the subscribers to access
==> the big issue will be how could the conventional millions of IPv4
application running on it?

thanks

-Hui

---

From: Cameron Byrne <[email-masked]>
Date: Sat, 18 Jul 2009 08:36:46 -0700 (PDT)

--- On Sat, 7/18/09, Hui Deng <[email-masked]> wrote:

> From: Hui Deng <[email-masked]>
> Subject: Re: [BEHAVE] Where is the definition of IPv6 only host forNAT64/DNS64
> To: "Cameron Byrne" <[email-masked]>
> Cc: [email-masked], "Dave Thaler" <[email-masked]>, "Dan Wing" <[email-masked]>
> Date: Saturday, July 18, 2009, 10:00 AM

I understand how that can be confusing, the situation in each T-Mobile region is different and the priorities change over time as the challenges change. This is natural result of different regions having different spectrum resources and different technology choices to best suite the served market, including variations on GAN and IMS and RF technologies.  For all of T-Mobile, IPv6 is a much more of a priority than it was even 6 months ago.  T-Mobile USA is pressing eagerly for IPv6 only UE with a focused consideration for end to end connectivity.  GAN and IMS are not mutually exclusive.  If you are interested in more about the T-Mobile USA situation, you can contact me off the list.  In the mean time, it may be best to let the individual operators describer their situation first hand.

Cameron Byrne
Principal Engineer
T-Mobile USA

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 19 Jul 2009 10:18:52 +1200

Hi Hui,

On 2009-07-19 02:00, Hui Deng wrote:
...
> we really need to solve that problem at the moment.

Yes, as the standards body for IPv6 basic specifications, we certainly
do, even if the actual deployment is years ahead. We are supposed to
solve tomorrow's problems.

Just to be clear, we are here (in BEHAVE and SOFTWIRE) because the
original dual stack transition model got out of step with the real-world
deployment model. The new model has to deal with a world in which
IPv4 addresses have been exhausted before IPv6 is universally deployed,
and paradoxicaly, that leads to large IPv6-only realms needing to
interwork with the IPv4-only realm.

    Bria

---

From: Hui Deng <[email-masked]>
Date: Sun, 19 Jul 2009 10:24:56 +0800

Thanks for experienced people remindness, I will make some snip below.
Reply inline, thanks.

thanks

-Hui

---

From: Hui Deng <[email-masked]>
Date: Sun, 19 Jul 2009 10:42:10 +0800

Hi, Brian

> solve tomorrow's problems.
==> I agree that we should solve the problem of tomorrow,
but I am hestitating to say that we should solve the problem of 20
years later or even 10 years later.
Even we solve the problem of 10 years later, it may not suitable for
standard work today, anyhow, you have more experience than I have:), I
am learning from u here.

> interwork with the IPv4-only realm.
==> we also agree with it, and with one more consideration, how could
conventional IPv4 application in large IPv6-only realms needing to
interworking with the IPv4 -only realm.
and this is the reason we propose two drafts below:
http://www.ietf.org/internet-drafts/draft-huang-pnat-host-ipv6-01.txt
http://www.ietf.org/internet-drafts/draft-chen-host-ipv6-ps-00.txt

Please kind help to review and comments,
many thanks

-Hui

---

From: "Dan Wing" <[email-masked]>
Date: Sun, 19 Jul 2009 09:59:13 -0700

> Sent: Saturday, July 18, 2009 7:25 PM
> To: Dan Wing
> hostforNAT64/DNS64
> ==> Mobile opeartor network architecture is different from 
> fixed operator, the situation is not that really hard,
> 
> >

Dual-stack lite, draft-ietf-softwire-dual-stack-lite, allows the 
operator to have an IPv6-only network and tunnel IPv4 packets to a
NAT44 device.  This would allow IPv4 applications to exist on the
handsets.  Of course, if there are millions of such applications and
any of them expect or require to have a publicly-routable IPv4
address, they'll break; this is true of any NAT44 technique, though.
Nothing works perfectly.

-d

---

From: <[email-masked]>
Date: Tue, 21 Jul 2009 10:06:14 +0200

Dear Dan, all,

See inline

Cheers,
Med

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Dan Wing
Envoyé : vendredi 17 juillet 2009 20:39
À : 'Hui Deng'
Cc : [email-masked]; 'Dave Thaler'
Objet : Re: [BEHAVE] Where is the definition of IPv6 only hostforNAT64/DNS64

> heard about IPv6 only handset requirement proposed.

Dual-stack handset, running on the mobile operator's network, means the mobile operator:

Med: This can be true in some configurationss. But, other solutions may be envisaged to offer both IPv4 and IPv6 connectivty services to end-user with ***IPv6-only*** network and ***stateless*** IPv4-IPv6 interworking. See http://tools.ietf.org/html/draft-boucadair-behave-ipv6-portrange-01#section-6.6.1. A ds-lite compliant solution can also be envisaged http://tools.ietf.org/html/draft-boucadair-dslite-interco-v4v6-01.

---

From: Kevin Y <[email-masked]>
Date: Fri, 24 Jul 2009 21:01:52 +0800

>  * operates a stateful NAT64 for the subscribers to access

Or if mobile SP think they can **really** control all mobile endpoints OS,
then  mobile SP can even operate a stateless translator for its subscribers
to access the IPv4  Internet   Xing's IVI approach solved this !

BR,

Kevin Yin

---

From: Kevin Y <[email-masked]>
Date: Fri, 24 Jul 2009 21:16:23 +0800

On Sat, Jul 18, 2009 at 11:36 PM, Cameron Byrne <[email-masked]> wrote:

> I understand how that can be confusing, the situation in each T-Mobile
> region is different and the priorities change over time as the challenges
> change. This is natural result of different regions having different
> spectrum resources and different technology choices to best suite the served
> market, including variations on GAN and IMS and RF technologies.  For all of
> T-Mobile, IPv6 is a much more of a priority than it was even 6 months ago.
>  T-Mobile USA is pressing eagerly for IPv6 only UE with a focused
> consideration for end to end connectivity.  GAN and IMS are not mutually
> exclusive.  If you are interested in more about the T-Mobile USA situation,
> you can contact me off the list.  In the mean time, it may be best to let
> the individual operators describer their situation first hand.
>
> Cameron Byrne
> Principal Engineer
> T-Mobile USA
>
>

Agree.  Even from China mobile operating teams,  I heard they are so worry
about
    a.  RFC1918 is not big enough for  CMCC,
    b.  They are worry about too many NATs which will compromise their
quality of new service.

The past experience for IPv6 slow adoption may not be
future predication,  in past, people do not need to make decision why they
have to go to IPv6,  in next two years,  thing will be different,  people
will have to make decision,   then IPv6-only is very viable option for
consideration,  we will see attitude change !

BR,

Kevin Yin