Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

From: Fred Baker <[email-masked]>
Date: Wed, 25 Aug 2010 07:18:14 -0700

On Aug 25, 2010, at 7:05 AM, Yiu L. Lee wrote:

> From user’s perspective, do they care IPv4 or IPv6? Most don’t. For example: a casual web user wants to access his/her favorite IPv4-only website. If his web client and PC support IPv6 and on an IPv6-only network with NAT64, the web traffic will go through the NAT once. If his web client and PC support IPv4-only on an IPv4 network with NAT444, the web traffic will go through the NAT twice. In the end, he/she still gets the same content. From this perspective, both experience “could be” very similar. 

Yes and no. For the web, which is a client-server protocol, you are correct. Any protocol that requires the receiver to have a stable address at the time the sender decides to send to it - a server of any kind, or a peer-to-peer protocol like SIP - one has to have some kind of NAT-traversal mechanism to cross it - it pretty much becomes a service the user is sold or (think bittorrent) the application goes through some kind of hijinks to evade the service provider. For the user, the freedom of being able to use such applications without heaving to have them as a service has been one of the drivers of p2p applications.

> However, this use case is rather limited and not applicable to many applications. This is why I said “could be”. Also, both Cameron and I agree that this is easier to implement IPv6-only on mobile network than on fixed network because mobile operators have more control over the devices and apps. IMHO, it will take longer time for fixed network operators to support NAT64 only solution in the network.

CERNET/CERNET2 started from stateless translation, and is a fixed network. So I would be careful saying "never". But frankly, the solution for the fixed operators is not translation 6<->4; it is IPv6 deployment.

On 8/25/10 9:41 AM, "huang cancan" <[email-masked]> wrote:

>> well, I mean: why customer experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64?
>> 
>> On Wed, Aug 25, 2010 at 9:24 PM, Yiu L. Lee <[email-masked]> wrote:
>>> In order to deploy IPv6-only + NAT64, the client and network must talk IPv6. It also requires DNS64. These requirements are not needed for IPv4-only + NAT444. From the deployment point of view, they are very different technologies. 
>>> 
>>> 
>>> 
>>> On 8/25/10 7:13 AM, "huang cancan" <[email-masked] <http://[email-masked]> > wrote:
>>> 
>>>> hi,Yiu:
>>>>   As you mentioned below:
>>>> > All I am saying is the customer
>>>> > experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64, but
>>>> > the technologies and plan to offer these service are very different.
>>>>  
>>>>   Do you have any test data to support this conclusion?
>>>>  
>>>> Can-can Huang
>>>> 
>>>> 
>>>> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee <[email-masked] <http://[email-masked]> > wrote:
>>>>> 
>>>>> > Agreed.  The 2x cost is really just the packet core ... which is of
>>>>> > course a lot of money to double for no tangible benefit ..... talk
>>>>> > about no business case .... And, still have numbering issues, customer
>>>>> > experience is the same as IPv4-only + NAT44 and approximately the same
>>>>> > as IPv6-only + NAT64
>>>>> >
>>>>> Life cycle of mobile equipments could be every 2-3 years, but life cycle of
>>>>> consumer electronics could be 5+ years. Consider many large TVs with
>>>>> Internet service selling today are still running IPv4-only, fixed line
>>>>> operators must prepare to support them in foreseeable future.
>>>>> 
>>>>> That said, I am not saying an operator must build a dual-stack core network,
>>>>> there are technologies such as DS-lite and Softwire Mesh available to run a
>>>>> pure IPv6 core network with dual-stack edge. All I am saying is the customer
>>>>> experience of IPv4-only + NAT444 could be the same as IPv6-only + NAT64, but
>>>>> the technologies and plan to offer these service are very different.
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> v4tov6transition mailing list
>>>>> [email-masked] <http://[email-masked]> 
>>>>> https://www.ietf.org/mailman/listinfo/v4tov6transition
>>>> 
>>>> 
>> 
>> 
> _______________________________________________
> v4tov6transition mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v4tov6transition

---

From: David Meyer <[email-masked]>
Date: Wed, 25 Aug 2010 07:49:03 -0700

CERNET/CERNET2 started from stateless translation, and is a fixed network.
> So I would be careful saying "never". But frankly, the solution for the
> fixed operators is not translation 6<->4; it is IPv6 deployment.
>

I have to agree with Fred here. While there may be advantages to
PT in some cases, native IPv6 deployment has the advantage of
preserving end-to-end (choose your definition of e2e), among others.

Dave

---

From: David Meyer <[email-masked]>
Date: Wed, 25 Aug 2010 08:09:04 -0700

Yiu,

On Wed, Aug 25, 2010 at 8:00 AM, Yiu L. Lee <[email-masked]>wrote:

>  e2e IPv6 is the goal, nobody argues with it. However, China Telecom said
> they would put 100+ million customers in the next 3 years. Obviously neither
> they would get 100+ million public IPv4 addresses nor all the services in
> the world would be IPv6 ready. Yes 6->4 may not be an immediate problem we
> try to solve, but IPv4 exhaustion problem is immediate. I guess we are all
> here to find out the real problems and give guidelines to solve the IPv4
> exhaustion problem and deploy IPv6 in parallel.
>
>
Sure, and this seems like exactly the use case where you might
need PT (6to4), since as you say, you need IPv6 to address the
10^8 hosts but those hosts will want to talk to some non-zero
number of IPv4 services.

Dave

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Aug 2010 00:25:20 +0900

> the solution for the fixed operators is not translation 6<->4; it is
> IPv6 deployment.

i suspect we do not disagree, but just to clarify.

fixed operators (in the non-wireless-phone sense) need to support home,
enterprise, etc. customers who will have both ipv4 and, we hope, ipv6
needs for a while.  so we need to deploy ipv6 *along side* ipv4, i.e.
dual stack.  stateless translation tools do not scale or perform well at
isp backbone scale.

our dual stack edge customers will use our dual stack backbones in a
simple fashion, no impedance matching needed.  the ipv6-only customer
will need nat64/dns64 to reach legacy ipv4-only destinations.

the ipv4-only customer will use ______ to reach ipv6-only destinations?

randy

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 Aug 2010 08:30:24 -0700

> the ipv4-only customer will use ______ to reach ipv6-only destinations?

that of course would have to be stateless translation or ds-lite.

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Aug 2010 00:47:01 +0900

>> that of course would have to be stateless translation or ds-lite
>
> Wrong direction...  DS-lite would enable a customer that is physically
> connected to a v6-only network to contact v4 nodes using his v4 apps.
>
> Think more 6rd in that case to make that customer v6 capable

no thanks.  i have a dual stack backbone.  i don't need or want to fake
v6.

> or some variation on NAT46.

is nat46 in the cards?  i thought that died in montreal or shortly
thereafter.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Aug 2010 01:01:21 +0900

> If what we mean here is the the operator only provided an IPv4 address
> to a IPv6-capable device

that is not what i meant.  i meant ...

> If what we mean here is that the end device is addressed with
> IPv4-only and is also IPv4-only-capable (i.e. XP without v6 stack
> enabled), then this is not longer just a network connectivity issue.
> We are now looking at how to make IPv6 content (for example) available
> to IPv4 endpoints (proxy? NAT46 [scary?], Other mechanisms?).

exactly.  i would add 'disgusting.'  but i am not known for tact.

i was just enumerating the cases.  and they all exist.  of course a v4
customer wanting access to v6 only content over my dual stack backbone
may be a while off.  but we do hope it will come.  and when it does, how
do we support it?

randy

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 25 Aug 2010 09:04:16 -0700

> exhaustion problem and deploy IPv6 in parallel.
 +1

For me, the problem is uniquely numbering a very large number of NEW
(m2m, mobile web, current BOGON mess, current n*RFC1918 mess...) hosts
given that IPv4 (public and private), for all intents and purposes, is
strategically (think current planning cycle) exhausted.

My belief is that the reality of edge growth (especially in mobile)
will force IPv6 deployments instead of counter-productive NAT444 and
RFC1918 version 2.  IPv6-only edge deployments will force NAT64 (more
in mobile) and DSlite (more in fixed).   The obvious disadvantages of
DSlite and NAT64 will encourage all parties involved (users, SP,
content) to earnestly TRANSITION to IPv6.  And, hopefully, NAT64 and
DSlite will only be a crutch for the long-tail.  For my users in the
USA, that fact that Facebook and Google / Youtube are already IPv6
make my last statement very close to being true today.

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Aug 2010 01:10:06 +0900

> RFC1918 version 2.

i wish i had your optimism.  that would be sooooo coooool!

randy

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 25 Aug 2010 09:10:13 -0700

On Wed, Aug 25, 2010 at 9:03 AM, Yiu L. Lee <[email-masked]> wrote:
> Hi Dave,
>
> Well, I can’t imagine an operator can launch an IPv6-only service with NAT64
> to its customers in the next 3 years even the projection of growth is 10^8.
>  The roadblock is the legacy IPv4-only hosts (TV, xbox, PS3, WinXP, etc) in
> customer’s homes.
>

T-Mobile USA will launch IPv6-only + NAT64 in the next ~12 months for
a controlled set of new handsets models directed at consumers.

The service is up and running today and you can try it if you like at
http://groups.google.com/group/tmoipv6beta

I have been using IPv6-only + NAT64 for the past 6 months, no major
issues.  ~99% of apps work (thank you IP version agnostic API / SDK),
content works (very few IPv4 literals), .... It's really not the
problem that many may think it is .... especially if you are a mobile
operator.  For mobile, LSN is not a new and neither is RFC1918
exhaust.

Regards,

Cameron

---

From: Fred Baker <[email-masked]>
Date: Wed, 25 Aug 2010 09:25:58 -0700

On Aug 25, 2010, at 8:00 AM, Yiu L. Lee wrote:

> e2e IPv6 is the goal, nobody argues with it. However, China Telecom said they would put 100+ million customers in the next 3 years. Obviously neither they would get 100+ million public IPv4 addresses nor all the services in the world would be IPv6 ready. Yes 6->4 may not be an immediate problem we try to solve, but IPv4 exhaustion problem is immediate. I guess we are all here to find out the real problems and give guidelines to solve the IPv4 exhaustion problem and deploy IPv6 in parallel.

Yes. From my admittedly-narrow perspective, it's primarily about turning on IPv6; you're not going to "solve" IPv4 exhaustion - it's not going to somehow become less exhausted. So if I may rephrase; it's about how to keep your IPv4 business running while you deploy IPv6. If you have an IPv4 network now, I would add "in your IPv4 network". If you have a green field, we built the translation technology in behave and it is now available from at least one vendor, and we have tunneling capabilities. What I find a lot of is people letting the "how will I access IPv4" question get in the way of deploying IPv6.

It brings to my mind a joke common in the US that may not be in China. I googled to find the canonical image, and mostly found US political humor. So I'll describe it. The picture shows either a person walking through a swamp and therefore waist-deep or chest-deep in water, or (funnier version) someone climbing a small tree in a swamp, desperately trying to get away from what is below. Caption: "when you're up to your ass in alligators (or snakes), it's hard to remember that you set out to drain the swamp". Based on the image, you will find Americans frequently talk about solving a big problem in terms of "draining the swamp".

In this case, "draining the swamp" is IPv6 deployment. At the point where we have universal deployment, this entire discussion will seem to have been a little pointless. Right now, the pressures of IPv4 access can seem overwhelming. 

The point of the joke is an object lesson in problem-solving. Yes, alligators and snakes are a problem, and have to be dealt with. If you let the issues consume you, that's all that will happen - you will be caught in the middle in perpetuity. If you focus on the objective, which is solving the "big problem", in this case IPv6 deployment, in time you will find that you have also solved the other. So yes, deal with what you have to, but don't let yourself be distracted from the real problem at hand. In this case, deal with IPv4 of course, but don't let that concern slow you down in deploying IPv6.

If you have an existing IPv4 network, Free.FR deployed an IPv6 service in their existing IPv4 network using 6rd with a team of a couple of people and a month's time if I have the story straight. That involved almost no actual native IPv6; 6rd is an IPv6/IPv4 tunnel infrastructure. But it allowed them to provide both IPv4 and IPv6 *services* to their customers while they took time to think about what they wanted to do natively. They can change their network under the hood, so to speak, an their own schedule.

Changing the network under the hood - that is the process hardware and software audit and upgrade, proving out configurations, and applying them where needed. No intention to trivialize, but if one can separate "delivery of the service" from "deployment of the technology", it might make the road a little easier.

Comcast has been a proponent of ds-lite. In this some portion of the network (at least one router or one link, but I should think more in practice) is converted to IPv6-only, and IPv4/IPv6 tunneling is used to carry IPv4 over that infrastructure to an IPv4/IPv4 NAT. IPv4 service is provided by tunnel while IPv6 is deployed natively. 3GPP has expressed interest in this approach, and specifically gateway-initiated ds-lite; in green field networks, several carriers (T-Mobile and Sprint that I know of, and I know of more that have talked about it) have deployed IPv6-only and used some form of tunnel infrastructure to provide IPv4 access, again through IPv4/IPv4 NAT.

The number of wireline networks that have literally turned up IPv6 within their existing IPv4 networks is pretty large. Many of them are on this list - Randy's comment a moment ago epitomizes their viewpoint. I don't think any of them would describe it as "without challenges", but I do get a lot of them quizzically wondering what the question here is. "So you have IPv4 access to IPv4 systems, and you have IPv6 access to IPv6 systems. Your point is what precisely?" Comments I get suggest that solutions like 6to4 and ISATAP are interesting ways to prototype the service, but if you need to do a build-out, they are science fair projects by comparison, primarily useful for testing IPv6 applications in a pre-IPv6 network.

And yes, CERNET's case demonstrates that stateless translation between an IPv4-only infrastructure and an IPv6-only infrastructure in fact works.

If it were my network to deploy in - and yes, this is the advice I am giving in my own shop - I think there are solutions on the table that have been shown to work. I would say "Pick one and do it". The hardest step in any journey is the first one. Take it, and you're that much closer to the destination.

> Yiu
> 
> On 8/25/10 10:49 AM, "David Meyer" <[email-masked]> wrote:
> 
>> 
>>

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 25 Aug 2010 12:43:54 -0700 (PDT)

----- Original Message ----
> From: Cameron Byrne <[email-masked]>
> To: Yiu L. Lee <[email-masked]>
> Cc: David Meyer <[email-masked]>; Erik Lindqvist <[email-masked]>; IPv6 
>v6ops <[email-masked]>; [email-masked]; [email-masked]
> Sent: Wed, August 25, 2010 11:10:13 AM
> Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
> 

This is good news indeed and shows some real good progress.
I tried my IPhone 4 on v6only AP in Maastrict and it did not work, 
I think that contrary to what I hear, IPhone 4 does not seem to support IPv6.

Regards,

Behcet

---

From: Leo Vegoda <[email-masked]>
Date: Wed, 25 Aug 2010 14:54:08 -0700

On 25 Aug 2010, at 12:43, Behcet Sarikaya wrote:

[...]

> I think that contrary to what I hear, IPhone 4 does not seem to support IPv6.

It works in the sense that it will load web pages, etc... over IPv6. See:

http://twitpic.com/2i50fj

I suspect it relies on DHCP for DNS resolver configuration though and so fails to work for most purposes in IPv6-only at the moment.

Regards,

Leo

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 26 Aug 2010 11:07:20 +1200

> same as IPv6-only + NAT64?

There are application scenarios that will work through a single layer
of NAT and fail through a double layer of NAT. I would have thought
this would have considerable impact on customer experience.

There are other negative impacts on content providers too, that were
discussed in a bar BOF in Anaheim.

   Brian

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Aug 2010 11:30:32 +0900

> Free.FR deployed an IPv6 service in their existing IPv4 network using
> 6rd with a team of a couple of people and a month's time if I have the
> story straight.

first, all free.fr stories are one engineer in two weeks.

second, we should not confuse this with ipv6 deployment, as your words
are very careful to hint.  this is one way to hack ipv6 service when you
do not deploy ipv6 in your network.

i do not mean to dis free.fr.  really great isp (with abyssmal customer
service).  but we really need to differentiiate ipv6 deployment from
hacks to get around non-deployment.

and they are not 'transition' mechanisms, as the network is not being
transitioned to ipv6.  just another hack to get around non-transition.
but a lot better than teredo, 6to4, ...

> That involved almost no actual native IPv6; 6rd is an IPv6/IPv4 tunnel
> infrastructure. But it allowed them to provide both IPv4 and IPv6
> *services* to their customers while they took time to think about what
> they wanted to do natively. They can change their network under the
> hood, so to speak, an their own schedule.

yep.  one good strategy if you do not want to deploy ipv6.

> Comcast has been a proponent of ds-lite.

well, alain was.  i would judge comcast by what it actually has done.

> And yes, CERNET's case demonstrates that stateless translation between
> an IPv4-only infrastructure and an IPv6-only infrastructure in fact
> works.

well, with some difficulty, as there are a lot of tunnels to get to the
ipv4 internet.

randy

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 25 Aug 2010 22:44:18 -0700

> the ipv4-only customer will use ______ to reach ipv6-only destinations?

prayer.

you're back to the typical problem, you make a query, you get back only
a aaaa record, so you're dead.

since the likelyhood of you changing the v4 only customer's stack is
limited you're stuck with alg's, and presumably only for a limited
subset of applications.

---

From: Randy Bush <[email-masked]>
Date: Thu, 26 Aug 2010 15:12:29 +0900

> a aaaa record, so you're dead.

well, the dns64 hack for those hiding behind a nat64 won't work here, as
you can't kludge the v6 address inside a v4 address.  so no stateless
solution.

> limited you're stuck with alg's, and presumably only for a limited

sigh.  i just don't have a happy business model that includes forcing
customers to make significant change.  especially not when the change
consists of giving their money to someone else :)

randy

---

From: Joel Jaeggli <[email-masked]>
Date: Wed, 25 Aug 2010 23:46:39 -0700

> I think that contrary to what I hear, IPhone 4 does not seem to support IPv6.

A lot of consumer oriented devices continue to operate under the
assumption that if they were unable to dhcp v4 that they should try
another available network. That's not a problem from the cellular
operator's vantage point, but if you happen to be planning an ipv6 only
wireless lan you should take it under advisement.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 26 Aug 2010 08:44:44 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Randy Bush
> Sent: Wednesday, August 25, 2010 7:31 PM
> To: Fred Baker
> Cc: IPv6 v6ops

Coexistence does not need to be through dint of hackery.

Coexistence need not even stand in the way of transition.

Coexistence faces up to the fact that there are billions
of pieces of legacy network equipment out in the wild that
will take years/decades/centuries to change out. It takes
ownership of the legacy lemons and makes lemonade.

Fred
[email-masked]

---

From: Rémi Després <[email-masked]>
Date: Fri, 27 Aug 2010 18:43:53 +0200

Le 25 août 2010 à 18:25, Fred Baker a écrit :
> ...
> If you have an existing IPv4 network, Free.FR deployed an IPv6 service in their existing IPv4 network using 6rd with a team of a couple of people and a month's time if I have the story straight.

Not in a month's time, to be accurate, but still in only 5 weeks! 
IMHO, everyone involved in IPv6 deployment should be interested in this story.
For more details:
- tools.ietf.org/html/rfc5569 
- www.ripe.net/ripe/meetings/ripe-58/content/presentations/ipv6-free
 
Regards,
RD

> That involved almost no actual native IPv6; 6rd is an IPv6/IPv4 tunnel infrastructure. But it allowed them to provide both IPv4 and IPv6 *services* to their customers while they took time to think about what they wanted to do natively. They can change their network under the hood, so to speak, an their own schedule.
> 
> ...

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 27 Aug 2010 15:16:40 -0400

Not an endorsement, merely a data point:  I am currently using 6rd for 
IPv6 access as part of a trial deployment by Comcast.  The shipped me 
the 6rd-enhanced router, and it was plug-and-play.  If not for the 
dancing turtle (and Google and Facebook via IPv6) I would hardly notice 
a difference from my baseline service.  WFM, YMMV.

This is a methodology to consider if modification of CPE is reasonable 
in your network.  If not, there are variants being discussed that will 
work with unmodified CPE.

http://tools.ietf.org/html/rfc5569
http://tools.ietf.org/html/rfc5969
http://tools.ietf.org/html/draft-despres-softwire-6rdplus-00
http://tools.ietf.org/html/draft-lee-softwire-6rd-udp-02

Ed J

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 28 Aug 2010 08:55:37 +1200

Ed,

To your list of alternatives, please add
http://tools.ietf.org/html/draft-carpenter-softwire-sample

Regards
   Brian Carpenter

On 2010-08-28 07:16, Ed Jankiewicz wrote:
>>> If you have an existing IPv4 network, Free.FR deployed an IPv6
>>> service in their existing IPv4 network using 6rd with a team of a
>>> couple of people and a month's time if I have the story straight.
>>> That involved almost no actual native IPv6; 6rd is an IPv6/IPv4
>>> tunnel infrastructure. But it allowed them to provide both IPv4 and
>>> IPv6 *services* to their customers while they took time to think
>>> about what they wanted to do natively. They can change their network
>>> under the hood, so to speak, an their own schedule.
>>>
>>> Changing the network under the hood - that is the process hardware
>>> and software audit and upgrade, proving out configurations, and
>>> applying them where needed. No intention to trivialize, but if one
>>> can separate "delivery of the service" from "deployment of the
>>> technology", it might make the road a little easier.
>>> ...
>>

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 27 Aug 2010 17:37:48 -0400

As I said, that comment was just one data point; there are a lot of 
proposals and alternatives and I'm sure we are all swamped.  I am 
willing to try to collate all the docs floating around the topic into a 
comprehensive (eventually) annotated bibliography for this group to 
consider.  This should help authors find each other, avoid duplication 
and cite related work.

I am accepting any and all suggestions and pointers.  Please reply on 
this thread, either just directly to me, or to the 
[email-masked] if it might be of interest to all.

Internet-Drafts, RFCs, other publications and websites on topics of 
interest:
transition problem statements
network operator experience, implementation reports
experiments, trials and prototypes
vendor/operator white papers, how-to, FAQs
coexistence and transition tools
and anything that you think is relevant

Thanks
Ed J.

---

From: Fred Baker <[email-masked]>
Date: Sat, 28 Aug 2010 23:08:58 -0700

</chair> <!-- v6ops -->
<author> <!-- draft-ietf-behave-v6v4-xlate -->

May I ask a question?

When you say you tested it with NAT64, what did you test with?

There are two modes for translation between IPv4 and IPv6. The stateful mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essentially identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to connect to IPv4 systems but not the reverse. The stateless mode, described in draft-ietf-behave-v6v4-xlate, allows connections to be initiated in either direction. The downside of the stateless mode is that it requires a direct mapping between an IPv4 and an IPv6 address. The are two parts of a common framework, use the same addressing plan, and the same DNS extension.

Are you running both modes, or only the stateful mode? If you are only running the stateful mode, that what you're reporting is what we have been saying for some time it will behave like.

http://datatracker.ietf.org/doc/draft-ietf-behave-address-format
http://tools.ietf.org/html/draft-ietf-behave-address-format
  "IPv6 Addressing of IPv4/IPv6 Translators", Congxiao Bao, Christian
  Huitema, Marcelo Bagnulo, Mohammed Boucadair, Xing Li, 15-Aug-10,
  <draft-ietf-behave-address-format-10.txt>

http://datatracker.ietf.org/doc/draft-ietf-behave-dns64
http://tools.ietf.org/html/draft-ietf-behave-dns64
  "DNS64: DNS extensions for Network Address Translation from IPv6 Clients
  to IPv4 Servers", Marcelo Bagnulo, Andrew Sullivan, Philip Matthews,
  Iljitsch van Beijnum, 5-Jul-10, <draft-ietf-behave-dns64-10.txt>

http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-framework
http://tools.ietf.org/html/draft-ietf-behave-v6v4-framework
  "Framework for IPv4/IPv6 Translation", Fred Baker, Xing Li, Congxiao
  Bao, Kevin Yin, 17-Aug-10, <draft-ietf-behave-v6v4-framework-10.txt>

http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate
  "IP/ICMP Translation Algorithm", Xing Li, Congxiao Bao, Fred Baker,
  22-Aug-10, <draft-ietf-behave-v6v4-xlate-22.txt>

http://datatracker.ietf.org/doc/draft-ietf-behave-v6v4-xlate-stateful
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-stateful
  "Stateful NAT64: Network Address and Protocol Translation from IPv6
  Clients to IPv4 Servers", Marcelo Bagnulo, Philip Matthews, Iljitsch van
  Beijnum, 12-Jul-10, <draft-ietf-behave-v6v4-xlate-stateful-12.txt>

On Aug 28, 2010, at 5:40 PM, YangGL wrote:

> Tests in my lab have proved that many popular applications cannot work on IPv6-only network with NAT64, such as IM, P2P, games, and part of video. WEB and part of mail (Outlook and Outlook express) are the only applications we can find working properly with NAT64. But there are more than 50% traffic is P2P, WEB traffic is less than 20% on CT’s network. I think it is not a good news to NAT64.
> Tests also prove that almost all of popular applications on Internet can work on IPv4-only network with single level and double level NAT44, such as WEB, mail, IM, P2P, games, video and etc.
> NAT64 and NAT44 are similar in theory. But what make the difference of application support? I think it should be timing. NAT44 appears ten years ago. There are a few applications on internet at that time. Subsequent applications, such as IM, P2P, were designed to work with NAT44. NAT64 come after this popular applications, situation is totally different. If NAT64 is deployed on commercial network now, CT’s network traffic will cut down 70% immediately, and most applications will release a new version for IPv6-only or NAT64 in the next one year. But it is not a good idea to providers.
>  
> Best regards,
> Yang Guoliang
>  
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Yiu L. Lee
> 发送时间: 2010年8月25日 22:05
> 收件人: huang cancan
> 抄送: Kurt Erik Lindqvist; IPv6 v6ops; [email-masked]
> 主题: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC
>

---

From: Randy Bush <[email-masked]>
Date: Sun, 29 Aug 2010 15:22:21 +0900

[ mailing lists trimmed ]

>> Tests in my lab have proved that many popular applications cannot
>> work on IPv6-only network with NAT64, such as IM, P2P, games, and
>> part of video. WEB and part of mail (Outlook and Outlook express) are
>> the only applications we can find working properly with NAT64. But
>> there are more than 50% traffic is P2P, WEB traffic is less than 20%
>> on CT’s network. I think it is not a good news to NAT64.

can you please explain the nanog, menog, apricot, ... experiments?  were
their drugs in the drinking water?

randy

---

From: Cameron Byrne <[email-masked]>
Date: Mon, 30 Aug 2010 15:42:16 -0700

2010/8/28 YangGL <[email-masked]>:
> Tests in my lab have proved that many popular applications cannot work on
> IPv6-only network with NAT64, such as IM, P2P, games, and part of video. WEB
> and part of mail (Outlook and Outlook express) are the only applications we
> can find working properly with NAT64. But there are more than 50% traffic is
> P2P, WEB traffic is less than 20% on CT’s network. I think it is not a good
> news to NAT64.
>

I agree, NAT64 is not great for fixed line operators today, but i am
sure someone has suggested DS-lite to you.

Mobile wireless in the USA is a different case, 90+% of my traffic is
Web (tcp 80 and 443) and Email (pop,smtp, imap ...).  And, 40+% of my
overall aggregate ISP bandwidth goes to content providers that have
substantial capability to deliver IPv6 content today (Google,
Facebook, ...).  As draft-arkko-ipv6-only-experience states, mobile
can reach near 100% functionality today with IPv6-only on the
handsets.  The expedience varies greatly between handset manufactures,
but the gap is closing quickly.  Most folks know Nokia is a leader in
IPv6, and now we see substantial IPv6 efforts from Android and Apple
(Windows phone 7?).

>From an access network perspective, i have found it is extremely
important to partner with content providers as well as applications
developers and have an open dialog about native IPv6 as well as how
transition mechanisms will impact the user experience.  In my real
world experience, the content providers take user experience very
seriously, and they know CGN is harmful and IPv6 is a near term
reality.  And, i have taken the wiki approach to fix IPv4 literals
http://groups.google.com/group/ipv4literals , at least the ones that
can be fixed as i encounter them in my real world pilot network.

I believe the point here, as someone else likely said, there is no one
size fits all.  Using a search engine, you can find enough general and
enough specific information to find what works best for you.  Review
it with your vendors, do labs, trials, pilots, betas .... learn,
repeat, deploy at small scale, learn, then deploy at large scale,
monitor, learn, fix ... probably need to do training in there
somewhere too.  From a technology evolution and process perspective,
there is nothing new with IPv6.

Finally, it is interesting you said that 50% of the traffic is P2P and
you are concerned P2P will not work with IPv6.  According to this
link, P2P traffic is driving IPv6 growth http://tinyurl.com/lkjwhq and
http://tinyurl.com/25ka5jp  From the operators that i have talked to,
rolling out IPv6 natively in the fixed-line environment reveals a
substantial amount of P2P  IPv6 traffic.  uTorrent is an IPv6
vanguard.  Others will follow if they have not already in making their
apps work with IPv6.

Once again, the knife cuts both ways. Some P2P applications will
thrive in IPv6 (seems obvious given e2e nature of things) while others
will be forced to evolve or be deprecated by their users.

Regards,

Cameron
=======
=======

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 31 Aug 2010 10:38:10 +1200

Hi,

On 2010-08-30 21:26, huang cancan wrote:
> Another reason why we don't test stateless NAT64 is that there are few
> application clients support IPv6, we can only test web or mail applications
> which are also OK with the stateful one.

But you reported other applications failing. How can they fail with NAT64 if
they have no IPv6 support in the first place?

   Brian

> 2010/8/29 Fred Baker <[email-masked]>
> 
>> </chair> <!-- v6ops -->
>> There are two modes for translation between IPv4 and IPv6. The stateful
>> mode, described in draft-ietf-behave-v6v4-xlate-stateful, is essentially
>> identical in function to IPv4/IPv4 NAT, and allows IPv6 systems to connect
>> to IPv4 systems but not the reverse. The stateless mode, described in
>> draft-ietf-behave-v6v4-xlate, allows connections to be initiated in either
>> direction. The downside of the stateless mode is that it requires a direct
>> mapping between an IPv4 and an IPv6 address. The are two parts of a common
>> framework, use the same addressing plan, and the same DNS extension.
>>
>> Are you running both modes, or only the stateful mode? If you are only
>> running the stateful mode, that what you're reporting is what we have been
>> saying for some time it will behave like.
>>
>>> Tests also prove that almost all of popular applications on Internet can
>> work on IPv4-only network with single level and double level NAT44, such as
>> WEB, mail, IM, P2P, games, video and etc.
>>> NAT64 and NAT44 are similar in theory. But what make the difference of
>> application support? I think it should be timing. NAT44 appears ten years
>> ago. There are a few applications on internet at that time. Subsequent
>> applications, such as IM, P2P, were designed to work with NAT44. NAT64 come
>> after this popular applications, situation is totally different. If NAT64 is
>> deployed on commercial network now, CT’s network traffic will cut down 70%
>> immediately, and most applications will release a new version for IPv6-only
>> or NAT64 in the next one year. But it is not a good idea to providers.
>>> Best regards,
>>> Yang Guoliang
>>>
>>> 发件人: [email-masked] [mailto:
>> [email-masked]] 代表 Yiu L. Lee
>>> 发送时间: 2010年8月25日 22:05
>>> 收件人: huang cancan
>>> From user’s perspective, do they care IPv4 or IPv6? Most don’t. For
>> example: a casual web user wants to access his/her favorite IPv4-only
>> website. If his web client and PC support IPv6 and on an IPv6-only network
>> with NAT64, the web traffic will go through the NAT once. If his web client
>> and PC support IPv4-only on an IPv4 network with NAT444, the web traffic
>> will go through the NAT twice. In the end, he/she still gets the same
>> content. From this perspective, both experience “could be” very similar.
>>> However, this use case is rather limited and not applicable to many
>> applications. This is why I said “could be”. Also, both Cameron and I agree
>> that this is easier to implement IPv6-only on mobile network than on fixed
>> network because mobile operators have more control over the devices and
>> apps. IMHO, it will take longer time for fixed network operators to support
>> NAT64 only solution in the network.
>>>
>>> In order to deploy IPv6-only + NAT64, the client and network must talk
>> IPv6. It also requires DNS64. These requirements are not needed for
>> IPv4-only + NAT444. From the deployment point of view, they are very
>> different technologies.
>>>
>>>
>>> On 8/25/10 7:13 AM, "huang cancan" <[email-masked] <
>> http://[email-masked]> > wrote:
>>> hi,Yiu:
>>>   As you mentioned below:
>>> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee <[email-masked] <
>> http://[email-masked]> > wrote:
> ------------------------------------------------------------------------
>

---

From: Tina TSOU <[email-masked]>
Date: Tue, 31 Aug 2010 11:12:58 +0800

Technically, these drafts are well written and very useful. It is really 
appreciated. Fred, would you explicitly point out the answers of the 
following questions from these drafts? Thanks.

1) There are some applications, server, clients don’t support IPv6. These 
situations will be met regardless of stateful or stateless NAT64. No one has 
right to request these applications must support IPv6 (Monocrat may have), 
but these applications have existed and been used for many people. In the 
migration to IPv6, if these users can’t use these service and applications, 
it will result in the losing of subscribers for operators, unless all the 
operators of the world support IPv6 at the same moment.

2) Some applications have supported NAT44 traversal maturely, but in a long 
period of time in the future these applications would unlikely to support 
NAT64’s traversal. If adopting NAT64, these applications would be impacted. 
No one has the right to request these applications must support NAT64 
traversal, so after the usage of NAT64, these application will conk out 
inevitably. Both stateful and stateless NAT64 have the same issues.

3) Some applications contain the senders’ IP address in the packet payload, 
even in the encrypted packet case. These will have problems when using 
NAT64. Since these applications are existing applications, no one has right 
to requesting stop using these applications. These issues will be 
encountered when using NAT64 (both stateful and stateless ones have the same 
problem).

4) No one has the right to force all the UE to support IPV6, therefore from 
the technology evolution point of view, we don't have to consider IPV4 only 
user actively visits IPv6 only service, but in the actual use people have to 
consider it, otherwise it may result in the subscriber losing. Yes, it is 
not NAT64.

5) For some P2P application, after using NAT64, IPv4 only peer is not able 
to actively scan the IPv6 only peer; some P2P applications don’t consider 
NAT64 traversal for the time being.

Again, these drafts are very practical drafts, any way.

B. R.
Tina
http://tinatsou.weebly.com/index.html

----- Original Message ----- 
From: "YangGL" <[email-masked]>
To: "'Fred Baker'" <[email-masked]>
Cc: "'Behave WG'" <[email-masked]>; "'Kurt Erik Lindqvist'" 
<[email-masked]>; "'IPv6 v6ops'" <[email-masked]>; 
<[email-masked]>
Sent: Tuesday, August 31, 2010 10:27 AM
Subject: Re: [v4tov6transition] draft-arkko-ipv6-transition-guidelines WGLC

> Hi Fred,
> You are really the dictionary of IPv6! Your mail always make me feel
> difficult to answer, too many references to read, give me some time, I 
> will
> come back after reading those documents mentioned in your mail.
>
>
> Best regards,
> Yang Guoliang
>
>
> </chair> <!-- v6ops -->
>> 发件人: [email-masked]
> [mailto:[email-masked]] 代表 Yiu L. Lee
>> 发送时间: 2010年8月25日 22:05
>> 收件人: huang cancan
> applications. This is why I said “could be”. Also, both Cameron and I
> agree that this is easier to implement IPv6-only on mobile network than on
> fixed network because mobile operators have more control over the devices
> and apps. IMHO, it will take longer time for fixed network operators to
> support NAT64 only solution in the network.
>>
>>
>> On 8/25/10 7:13 AM, "huang cancan" <[email-masked]
> <http://[email-masked]> > wrote:
>>
>> hi,Yiu:
>>   As you mentioned below:
>> > experience of IPv4-only + NAT444 could be the same as IPv6-only + 
>> > NAT64,
> but
>> On Sat, Aug 21, 2010 at 7:37 AM, Yiu L. Lee <[email-masked]
> <http://[email-masked]> > wrote:
>>

---

From: Joel Jaeggli <[email-masked]>
Date: Mon, 30 Aug 2010 21:23:36 -0700

Just a few observations without the wg-cochair hat on.

On 8/30/10 8:12 PM, Tina TSOU wrote:
> 1) There are some applications, server, clients don’t support IPv6.
> These situations will be met regardless of stateful or stateless NAT64.
> No one has right to request these applications must support IPv6
> (Monocrat may have), but these applications have existed and been used
> for many people. In the migration to IPv6, if these users can’t use
> these service and applications, it will result in the losing of
> subscribers for operators, unless all the operators of the world support
> IPv6 at the same moment.

Legacy ipv4 only apps aren't going to support v6 period, it has nothing
to do with when operators support or don't support ipv6. legacy
applications do not become new again. see (3) for dicussion of rights.

> 2) Some applications have supported NAT44 traversal maturely, but in a
> long period of time in the future these applications would unlikely to
> support NAT64’s traversal. If adopting NAT64, these applications would
> be impacted. No one has the right to request these applications must
> support NAT64 traversal, so after the usage of NAT64, these application
> will conk out inevitably. Both stateful and stateless NAT64 have the
> same issues.

An application that supports nat64 traversal is fact a native ipv6
application that isn't dependent on layer violations for it's signaling
of among other things ip address port numbers or security bindings. You
sort of characterized this in (3).

> 3) Some applications contain the senders’ IP address in the packet
> payload, even in the encrypted packet case. These will have problems
> when using NAT64. Since these applications are existing applications, no
> one has right to requesting stop using these applications. These issues
> will be encountered when using NAT64 (both stateful and stateless ones
> have the same problem).

The word "right" is a challenge to me here. Supporting a protocol on a
network is a business decision(for example, when do I add ipv6 aaaa
records to a service in my network). It is is in the interests of
internet service providers to induce as little deliberate breakage into
the network as possible. As a content and services provider (which is
what I do) if I don't adhere to this axiom I get to look for a new job.

> 4) No one has the right to force all the UE to support IPV6, therefore
> from the technology evolution point of view, we don't have to consider
> IPV4 only user actively visits IPv6 only service, but in the actual use
> people have to consider it, otherwise it may result in the subscriber
> losing. Yes, it is not NAT64.

There is going to be a time where ipv4 only users cannot access a
resource because it only accessible via v6, in superficial cases this
happens all the time. It is in the interests of most if perhaps not all
network operators, application vendors and end users, to push the time
in which that occurs routinely, beyond the window in which ipv6
deployment largely occurs. That said it seems like that workarounds
associated with ipv4 support post-runout will result in a gradually less
usable ipv4 network, which is if anything and incentive against holding
out to the bitter end.

> 5) For some P2P application, after using NAT64, IPv4 only peer is not
> able to actively scan the IPv6 only peer; some P2P applications don’t
> consider NAT64 traversal for the time being.

p2p applications have a built-in assumption of the existence of usable
endpoint identifiers. To the extent that ipv4 identifiers become
progressively less usable, p2p applications will prefer ipv6, that will
require upgrade or substitution.

> Again, these drafts are very practical drafts, any way.

It is useful to understand what on a v6 native host is not going to work
well through a 6to4 gateway. It is not so useful to have an
existence-proof for problems with ipv4 only applications, given that we
have ipv4-only-hosts to support into the immediately forseeable future.
The assumption that I make with those devices be they embedded systems,
pc's, mobile phones, etc, Is that I have the luxury of zero stack change.

> ----- Original Message ----- From: "YangGL" <[email-masked]>
>>> work on
>>> > experience of IPv4-only + NAT444 could be the same as IPv6-only + >
>>> NAT64,
>> but
>>> there are technologies such as DS-lite and Softwire Mesh available to
>>> run
>> a
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>