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

[Cameron Byrne <cb.list6@gmail.com>]

On Wed, Aug 18, 2010 at 4:27 PM, Fred Baker <fred@cisco.com> wrote:
> 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.
>

Right, IPv4 literals are a problem for IPv6-only networks.  But, i am
trying to control the FUD that tends to steam up from this type of
issue as well as resolve the root cause issues.  To that end, i direct
you to http://groups.google.com/group/ipv4literals.  I have been
IPv6-only on mobile for 6 months and i have 2 known issues in the
catalog.  If you know of more, please help me catalog them so that
problems that can be fixed, get fixed.  I know there are problems that
cannot be fixed, but those applications will evolve to deal with IPv6
and IPv4 exhaust or fade away into brokeness.  Please, lets keep a
close eye on this IPv4 literal issue and make sure we wrap our
concerns in facts and use those facts to drive action.

> 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 am seeing a broad brush strokes here.  From Jari's slide deck, i see
a delta of 0.2% breakage between IPv4-only and IPv6+NAT64 for web.
That is the long tail.  I am willing to send that 0.2% an email and
tell them they need to fix their IPv4 referrals or move to IPv6 to
ensure reachability in 12 months when IPv6-only service appear in
earnest.  I agree that online games are an issue per Jari's report,
but my mobile customers don't really do that today on their phones.
It might also be relevant to say that when many ISPs add their
aggregate traffic to Facebook and Google together, it starts to look
like around 40% of their bits go to these 2 AS's..... and those 2 AS's
have strong IPv6 efforts today.... so they don't even go via NAT64.


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

A great effort.  Thank you and the team.


>   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"?
>

That sounds better to me.


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

As in my note to Randy, i am just talking about end-nodes and access
network, and really only mobile.  Not many end-nodes and access
network are dual-stack.  Comcast is an outstanding example of going
dual-stack.  Nearly everyone else in the access space is not, hence
6RD.


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

Ok.  I know 2 IPv4 literal users, they are in the catalog.  Your above
statement makes me feel like you know of more, please share them at
http://groups.google.com/group/ipv4literals  IPv4 literals will not go
away on their own, but i feel like i have a good grasp on how IPv4
literals impact today's user experience, and it is negligible impact
(on mobile).  Amazon Video and mobile.nytimes.com may not think the
impact is negligible, but i have already made a good faith attempt to
educate and encourage them to resolve this issue before it becomes
negatively impactful for them.  Finally, customer know they have
options when viewing online video and news.  I know of one major IPv6
adopter that provides news and video over IPv6 today .... They are
sure to work well in an IPv6-only access network.



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