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

[Fred Baker <fred@cisco.com>]

I'd appreciate remarks on the proposed update at

    ftp://ftpeng.cisco.com/fred/v6ops/transition-diffs.html
    ftp://ftpeng.cisco.com/fred/v6ops/transition-guideline.txt
    ftp://ftpeng.cisco.com/fred/v6ops/transition-guideline.xml

If you believe that I have addressed your concerns regarding 4.4 and timing, I'll post that as an update-in-WGLC.

I'll comment on your comments inline.

On Aug 20, 2010, at 9:08 AM, Cameron Byrne wrote:

> On Fri, Aug 20, 2010 at 6:56 AM, Cameron Byrne <cb.list6@gmail.com> 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.
>> 
>> My feed back is this document, as it stands,  is not an operational
>> utility since I do not believe it helps people in operating an access
>> network (most networks have end nodes on them, backbone ISPs know what
>> to do).  Do we need yet another anthology of IPv6 tools?  I do not
>> think there is good reason that this document should move forward
>> since it does not add anything new or, IMHO, good advice to people
>> with numbering problems.
>> 

You have seen, in the past few days, comments cross-posted to v4tov6transition@ietf.org; I believe that you are also on that list. This is a set of service providers that are specifically asking the IETF for guidance on how to go about IPv6 deployment and eventual transition. Jari originated this document because he is asked the question, and many of us are.

>> Here are my concerns:
>> 
>> 1.  The only reason people want to deploy IPv6 is because of IPv4
>> exhaust, right?   Yet this document  recommends dual-stack as the
>> right approach forward.

May I invite you to look at RFC 4192? You will recall that it was intended to be the first draft of an operational renumbering plan; if someone wants to renumber their network or a part of it, they can look at this for a general structure. I would expect them to draft what I will call a "second draft", that follows the guidelines, addresses the issues raised, and is tailored to their network and its needs.

"Dual Stack" is a renumbering plan, if you will. Instead of renumbering an IPv6 network, it renumbers an IPv4 network as an an IPv6 network. RFC 4192 explicitly addresses business continuity on the existing numbering plane (IPv4 in this case) during deployment, and discusses how one tells whether and when one is ready to shift to the new numbering plan (IPv6 in this case), and ultimately how to turn down the old numbering plan.

I find your remark here confusing. Why would one disrupt one's own business for a network reason? Why would one not seek to continue their business operations during the change? Help me out here.

>> The IETF should know that DS does not solve a
>> numbering problem and there is no incentive for folks to go dual
>> stack. DS is pure altruism to make IPv6 easier to the stragglers and
>> free-riders.  But, even technology forward companies like Cisco and
>> Ericsson do not have dual stack websites today, 10+ years after the
>> IETF told everyone they should go DS.  So once again, from on high,
>> "do as I say, not as i do".
>> 

Actually, we do have some help for IPv4 numbering issues; the translation technology that we have developed in behave and comment on in 4.4 enables a network to carefully husband its IPv4 address space by allocating it (stateless translation) as IPv4-accessible IPv4-embedded IPv6 addresses applied to servers, and deploy ipv6-only clients - historically 40:1 over servers - that can access IPv4 servers using a translation technology not so very different from the IPv4/IPv4 NAT in current wide use. During the IPv6 deployment, there remains a very real question of business continuity; there will be no flag day, which means that there will for a period of time be systems that either have not got IPv4 enabled or whose networks are not IPv6-clean end to end, and this kind of thing can help.

>> 2.  If this document is to take a realist view and assert the IETF
>> position as a though leader and guide to the future, it should paint
>> the real picture of IPv4 exhaust and provide real solutions to what
>> happens when there is no more IPv4 to be had.  It should also, for
>> historical perspective, explain why DS did not work so people can
>> avoid going down this path.... or at the least, know that going DS is
>> not the end-state where we don't have to worry about IPv4 any more
>> .... DS is just a multi-protocol network that is more expensive and
>> more complicated.  In some corners of the world, when i tell people DS
>> does not solve the number problem, it is the first time they have
>> looked at DS with a critical eye.
>> 

Which is to say that you have convinced them that they actually have to turn on IPv6, and good for you. Understand that dual stack has not failed for anyone that has tried it. What has failed is "not turning on IPv6".

>> 3..  Fred made it clear that deployment is turning something on.
>> Transition is turning something off.  This document is called
>> transition but it does not recommend or articulate how to turn IPv4
>> off in any detail.
>> 

I believe that you are referring to the title of the document. the title is "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", not "how to carry out an IPv4 to IPv6 transition". I believe that RFC 5211 gives some thoughts about the latter.

>> 4.  Perhaps it would be helpful to specify a scope for this document?
>> Enterprise networks?  Access networks?  Transit ISPs?
>> 

It might be, but here I would be interested in comments from people in those various networks.

In private email, you castigated me for saying anything on IPv6 deployment at all, as in your words "Cisco is not deploying IPv6". I'll repeat for the record the comment I sent in private email.

/*****
 * comment from private email
 *****/
As you may be aware, Cisco is in the process of internal deployment; IPv6 is deployed in parts of the company, and as I type I am on a phone call related to the deployment itself. That deployment will be dual stack. The reason it is dual stack is that Cisco is not stopping doing business during the transition; we still need to communicate with customers and business partners that have not yet deployed, and world-wide we have roughly 100,000 people that have to do their work during the transition.

When IPv6 has been fully deployed throughout Cisco, a process started a year ago and which I expect will take the coming year, Cisco will start asking the question of IPv4 turn-down. That will not be a technical decision; it will be a business decision. One by one, I would expect Cisco to temporarily and then permanently disable IPv4 access to various internal applications. When Cisco has no more internal applications running that use IPv4, the only real use of IPv4 in Cisco will be access to the outside world. At some point, I would expect Cisco to determine that the business need to use IPv4 to do that has diminished, and IPv4 support is no longer needed.

Very honestly, the turn-down process is not a priority for Cisco. The equipment and configurations required for IPv4 are sunk cost, and the bandwidth is essentially the same whether IPv4 or IPv6. I expect the turn-down process to take as long as is necessary, and probably a lot longer.

Who am I to tell people to do dual stack? Someone who is doing dual stack, and whose corporate share-holders and management will consider nothing else.
/*****
 *****/

If I am incorrect, I know someone will correct me; my guess is that the fundamental needs of enterprise, access, and transit networks are roughly the same, although they are discussed and carried out in different ways. 

First, we all need enough addresses to run our businesses, whether we are edge networks, access networks, or transit networks.

Not all are feeling the address pinch yet, and a surprising number of edge networks that I talk with don't expect an address pinch at all. The issue of address availability applies to networks that need a flow of address space to deploy new services or meet new customer needs; businesses that don't require addresses to do that don't have that requirement. So when I say that IPv4 addresses are running out, those businesses yawn. For them, the issue that the coming few years impose is one of accessibility to business partners that do have the issue and as a result will deploy. Call that "denial" if you like; it's a viewpoint that I hear expressed.

Any network that does require additional address space from time to time is looking at a continuity of business situation. Not continuity of business with its existing infrastructure, which is paid-in-full, operational, and working, but its new businesses, services, or customer bases. It will deploy IPv6 to meet that new addressing need.

Second, we all need to serve the needs of our customers. Those "customers" may be employees, who need to use the network to access applications relevant to the operation of our own business, or who need to talk with business partners and corporate clients in the course of doing business. They may literally be customers in the case of access networks, or peers in the case of transit networks. 

These face a problem - many of their employees or customers require access to the IPv4 Internet in some form while that deployment is happening, and turning up IPv6 requires them to audit their networks (does the current software support what they want to do? If not, do they need new hardware to deploy the needed new software?), prove out new configurations, and turn them up. As you know, that is not a matter of snapping one's fingers. If they had started when they should have, it would literally have been a matter of turning up IPv6 in their existing IPv4 networks; they didn't, and many are now turning to some variation on CGN as described in draft-ietf-v6ops-incremental-cgn to keep IPv4 services stumbling along while they deploy. 

You would like us to tell people to, while they are turning IPv6 on, to turn IPv4 off or in their new network zones deploy no IPv4 capability. This doesn't work, due to business continuity. At some point in the future, an IPv6-only service that is not a walled garden will be feasible; today, without IPv4 service, nothing on the IPv4 Internet - by every estimate I see larger than 95% of the Internet - is accessible. I have above given you a very clear view of the implications of that for an edge network; for an access network, selling a service that fails to provide access seems an oxymoron, and for a transit network, it's a dead end. I fail to see how any network, SOHO, SMB, Enterprise, Access, or Transit, is served by failing to meet the needs of its employees or customers.

> 1. Please reconsider explicitly recommending dual stack.  Perhaps put
> it some verbiage about "no pain, no gain"

In view of my argument above, what argument should I give that will convince someone to discontinue their current business operation while they deploy IPv6?

> 2. Revise statement about literals.  The current unqualified and
> unbounded statement without context gives the wrong impression.

I believe that I have addressed your comments in
     ftp://ftpeng.cisco.com/fred/v6ops/transition-guideline.txt

I would appreciate your further constructive remarks.

> 3. Squarely face the issue of a fragmented internet where there is
> ipv6.google.com, ipv6.t-mobile.com, www.ipv6.cisco.com
> www.v6.facebook.com as well as aaaa whitelist that Yahoo and Google
> are pushing.  I believe the reality of these sites and the DNS
> whitelist are more votes against DS.

http://www.ipv6.cisco.com/, like IPv6.Google.Com and IPv6.Facebook.Com, is indeed IPv6-only. There is a reason, and it has nothing to do with deploying a perfectly usable service. It is to test access to Cisco's public web site using IPv6. What purpose would dual stack deployment have in that context?

In time, I fully expect the deployment of AAAA records for www.cisco.com and its counterparts at the other companies you mention. That will not be a "trial" scenario; it will be a "service" scenario. I think the correct way to read the existence of sites like these that are IPv6-only and force one to "do something different" to get to them is that the companies don't yet consider them to be ready for prime time.

Given that, I'm not sure what you are asking me to squarely face. I would, though, invite you to squarely face the business requirements of networks that are deploying in a dual stack configuration. 

If you would like, we could jointly look at an RFC 4192 follow-on that discusses the process of transition. I suspect, though, that the "transition" part, the part where we turn down IPv4, will in most places be as it is at Cisco - a business matter. IPv4 will stay up while there is a business need, and will probably stay up for a period of time when there is no remaining real business need "just in case". It will be turned down when its day is simply over.