Re: draft-arkko-ipv6-transition-guidelines WGLC

[Fred Baker <fred@cisco.com>]

I'd let Jari speak for himself, but he's gone for a couple of weeks.

On Aug 18, 2010, at 3:57 PM, Cameron Byrne wrote:

> On Sun, Aug 15, 2010 at 11:00 AM, Fred Baker <fred@cisco.com> wrote:
>> This is to initiate a two week working group last call
>> of draft-arkko-ipv6-transition-guidelines. Please read it now. If you find
>> nits (spelling errors, minor suggested wording changes, etc), comment to the
>> authors; if you find greater issues, such as disagreeing with a statement or
>> finding additional issues that need to be addressed, please post your
>> comments to the list.
>> We are looking specifically for comments on the importance of the document
>> as well as its content. If you have read the document and believe it to be
>> of operational utility, that is also an important comment to make.
> 
> Dear authors,
> 
> I remain troubled that we are still pushing dual-stack as the
> preferred transition mechanism.  I think we should add more language
> stating that IPv6-only + NAT64 is very viable for general use,
> especially in mobile, a very high growth area for IP address usage.

I certainly tried to edit that in, in section 4.4. It does have issues, notably in dealing with refers (if the target system tells you to redirect your request to an IPv4 address, how do you handle that?). But yes, it is operationally useful in those networks that have deployed it.

Can I ask you to suggest text?

> Jari has already presented his finding, which i view as very positive,
> here http://www.ietf.org/proceedings/78/slides/behave-6.pdf

Hmm. You might read http://tools.ietf.org/html/draft-arkko-ipv6-only-experience
  "Experiences from an IPv6-Only Network", Jari Arkko, Ari Keranen,
  12-Jul-10, <draft-arkko-ipv6-only-experience-01.txt>

which is Jari's write-up on his experience. In the deck you refer to, the key take-awways are on slide 4 and 10; there are some things that worked, and some things that really didn't. Jari, having tried IPv6-only, was pleased with what worked but troubled  by the things that didn't. Xing Li has also commented to me on issues that CERNET2 has.

> I would like to see some of the content from his deck added to this
> draft.  As it stands, the draft gives me the impression that IPv6-only
> is only for niche deployments and futuristic sensor networks.

OK, no problem. I'll add the second recommendation on slide 10 of Jari's deck to the draft. Oops, I don't need to - it's already there.

> Today,
> IPv6-only is a real solution that i have trials going on with, and i
> believe it is very functional for most common users, more at
> http://groups.google.com/group/tmoipv6beta
> 
> Also, unilateral sounds bad.  Makes me feel like IPv6-only is not a
> cooperative or friendly path.  I would say "Pure IPv6" or "IPv6
> end-state deployments" which require gateways to IPv4

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

which is on its way to RFC-dom defines:

   IPv6-only:  An IPv6-only implementation, in this context, comprises
      an IPv6-enabled end system stack, applications directly or
      indirectly using that IPv6 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.

Would it be OK with you if I changed that to "IPv6-only deployment"?

> IMHO, traditional dual-stack is not viable for transition.  There are
> not incentives for me to dual stack at home, work, or while mobile.

That's interesting, given the number of networks that have followed that route. I wonder what other operators would say about that?

> Traditional dual-stack does not provide a better user experience and
> it does not save me any IPv4 addresses.  Dual-stack + NAT44 may
> eventually have some benefits if I can by-pass the NAT44 with native
> IPv6.  Same can be said for DS-lite.  But, traditional dual-stack
> (public IPv4 and IPv6) is a non-starter.  And the idealistic notion
> that dual-stack leads to a future where eventually everything will go
> IPv6 and we can just turn off IPv4 without anyone knowing stopped
> being viable around 2005, transition time ran out and nobody deployed
> it.  Without incentives (carrots, sticks, other ...) dual-stack will
> remain a science experiment for those inclined to do so, not a real
> solution for end users numbering.  The real solutions that real
> network service providers are deploying are address sharing mechanisms
> that favor IPv6 end to end (DS + NAT44, DS-lite, NAT64).  Anything
> else does not have the appropriate market mechanisms (Bad CGN
> experience, motivate IPv6 native content to avoid CGN, uniquely
> numbered users for e2e multimedia) to engender change.
> 
> I believe the IETF needs to be much more forceful in pushing
> IPv6-first solutions.  Straddling the fence with traditional
> dual-stack in not a real solution and re-enforces the notion that "I
> do not have to do anything with IPv6, since dual-stack people will
> always have IPv4" or "IPv6-only is not ready".  If we embrace a more
> aggressive IPv6 path (which is the reality of IPv4 exhaust), then we
> begin to stimulate the Internet ecosystem to understand that IPv4 is
> really not the best strategic investment for client to (server | cloud
> | client) communications.

On that point I agree. That said, for the vast number of networks, the issue is not bringing up IPv6 where IPv4 isn't; the issue is bringing up IPv6 in the existing IPv4 network. Hence, in talks I give (ftp://ftpeng.cisco.com/fred/nav6tf/Fred_Recent_Talk.pdf being an example), I very explicitly tell my audience that the term "transition" implies turning something ON and turning something OFF, and I am simply talking about DEPLOYMENT, which involves turning something ON. I have no problem with IPv6-only networks apart from protocols like SMTP, HTTP, FTP, and so on that carry IP addresses at the application layer. If we could get those to use names instead of addresses, I would be right with you.

> Regards,
> 
> Cameron
> 
> ps.  Even in the face of IPv4 exhaust *you* don't need to be worried
> about IPv4 exhaust
> http://www.pcpro.co.uk/realworld/360418/why-you-shouldnt-worry-about-ipv6-just-yet