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

[Fred Baker <fred@cisco.com>]

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" <dmm@1-4-5.net> wrote:
> 
>> 
>> 
>>> 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
>> 
>>  
>> 
>>