Re: [v6ops] Operational Consensus on deployment

["Fred Baker (fred)" <[e-mail]>]

Following up on my note of a bit ago. Let me walk though a bit more of my line of reasoning by saying what question I would expect these drafts to answer.

On Aug 4, 2014, at 9:55 AM, Fred Baker (fred) <[e-mail]> wrote:
>   - a short draft, counterpart to RFC 6540, stating a change in the operational consensus toward IPv6-only deployment

The current consensus regarding dual stack transition is captured in https://tools.ietf.org/html/rfc4213
     Basic Transition Mechanisms for IPv6 Hosts and Routers. E.
     Nordmark, R. Gilligan. October 2005. (Format: TXT=58575 bytes)
     (Obsoletes RFC2893) (Status: PROPOSED STANDARD)

That is the third in a series; RFCs 1933 and 2893 looked at possible transition plans and suggested the approach. In short, it suggests that IPv6 be brought up in an operator’s existing IPv4 network as “ships in the night”, the two networks be operated together until the need for IPv4 goes away, and the operator then turn off IPv4.

The simplest and clearest statement I have seen of an alternative plan is Pater Lothberg and Axel Clauberg’s comments regarding what they call “Kaikaku for IP networks”. See slide 5 of https://ripe67.ripe.net/presentations/131-ripe2-2.pdf. In short, operators are today running “dual stack” on a variety of different technologies, and doing so costs money. Peter and Axel are therefore asking what it would take to make the hard choices, jettison unnecessary costs, and dramatically simplify their service infrastructure. “IPv6-only” is part of that, but only part. The game plan is, instead of bringing IPv6 up in the existing network and subsequently convincing themselves to make other parts go away, to build a network based on a very few fundamental building blocks (IPv6, DHCPv6, YANG, one overlay technology, Metro Ethernet on the fastest fiber optics they can find, one IGP, BGP, and as little else as they can convince themselves they need), and then move customers to it. The older-and-more-expensive network dies when it has no customers.

That may be the most dramatic version, but what I see in 464xlat is similar; the underlying infrastructure is dual stack, but the handsets are one or the other and use separate sets of services. If the handsets and services supporting them are all moved to the IPv6 service, nobody will notice if IPv4 is turned off. 

Facebook has been making some pretty public comments about their movement toward IPv6-only; at first, their developers apparently pushed back pretty hard against becoming version-agnostic, but now they actually ask “would anyone mind if I simply leave the IPv4 part of this code out?”. http://www.internetsociety.org/deploy360/resources/case-study-facebook-moving-to-an-ipv6-only-internal-network/

For the IETF to have this conversation, we pretty much need a draft that makes a bold statement: “the time is soon coming, or perhaps has arrived, to turn IPv4 off.” I expect that bold statement to be controversial, both on this list and during IETF Last Call. I expect it to make the press. If we think we’re ready for that conversation, let’s have it. Whenever we have it, we will need a draft to focus it. If we’re not ready for it, that’s fine too. But how do we tell when we’re ready?

>   - a practical approach on “how to get there” (probably more than one draft, addressing differing operational requirements)

You might listen to the first 35 seconds of http://www.youtube.com/watch?v=kwFvJog2dMw, which was a seminal moment in the speaker’s presidency. “We choose to go to the moon. We choose to go to the moon in this decade... not because it is easy, but because it is hard.” I see the draft I just spoke about as a similar vision statement: “we choose to turn IPv4 off...”.

Jack Kennedy’s speech, delivered when I was ten, didn’t get us to the moon. We wouldn’t have gotten there without it, though. What got us to the moon was a lot of research, and a lot of very solid engineering. We have, I think, done the research, built the products, and tested them operationally. I’m looking for that engineering in these drafts. How do we get to the moon?

The alternative is where Microsoft Azure finds itself now. They are out of IPv4 address space and do not have a publicly announced IPv6 service. To fill the gap, they are moving address space from Brazil to the US. Now, lest someone think I’m slamming them, I have little doubt that they have a long term plan; it’s just not in evidence at the moment. But where they stand, if they don’t have a plan, they’re screwed. They are only the most public of a long list of companies with that problem...

>   - a practical translation solution (possibly more than one draft)

I’m also looking for solid engineering in this...