Re: [v4tov6transition] FW: New Version Notification for

[owner-v6ops@ops.ietf.org]

draft-lee-v4v6tran-problem-01
Mime-Version: 1.0 (Apple Message framework v1081)
From: Fred Baker <fred@cisco.com>
In-Reply-To: <C8ADCBAA.317AD%yiu_lee@cable.comcast.com>
Date: Thu, 9 Sep 2010 18:39:42 +0900
Cc: <v4tov6transition@ietf.org>, IPv6 v6ops <v6ops@ops.ietf.org>
Message-Id: <3C17977D-A798-411C-93A8-A9EB6723B733@cisco.com>
References: <C8ADCBAA.317AD%yiu_lee@cable.comcast.com>
To: "Yiu L. Lee" <yiu_lee@cable.comcast.com>
X-Mailer: Apple Mail (2.1081)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

On Sep 9, 2010, at 12:24 PM, Yiu L. Lee wrote:
>> The objective is to turn on IPv6;
>=20
> I agree with that, but please don't forget the other important =
objective: To continue offer v4 services during transition while no more =
public v4 address is available.

I hope I have been clear that keeping your IPv4 business running is =
something I agree is important for the lifetime of that IPv4-only =
equipment and software.

The problem is that you really don't have a lot of options in that; =
there is no magic that this working group or anyone else can provide for =
you, which is why the IPv6 Forum and others have spent the past decade =
trying to get companies to prepare themselves for this point. Once you =
cannot reliably get global IPv4 addresses, you will be forced to either

(a) use RFC 1918 space within the ISP on paths to customers, who further =
NAT themselves. Since the edge user's domains use 10.0.0.0/8 and =
192.168.0.0/16, but 172.16.0.0/12 is less widely used, 172.16.0.0/12 is =
your option. You build multiple instances of it, as many as you need, =
and you NAT those areas to the general Internet - or

(b) deploy an IPv6-only network for a growing portion of your network, =
translate IPv4 to IPv6 within that domain, and tunnel IPv4 to an IPv4 =
CGN when crossing that domain, - or

(c) deploy an IPv6-only domain, allow customer IPv6 traffic into that =
domain, and tunnel IPv4 over the domain to an upstream CGN.

You'll recognize those as topics being discussed in v6ops, softwire, and =
behave...

The effect of CGN, however accomplished, is much like today's IPv4 =
Internet with NAT around the periphery, but applications work even less =
well than they do in the single-NAT'd IPv4 of today. I can think of more =
than one ISP that has built layered NAT domains and has come to me =
asking me to speak with the RIRs on their behalf, because it is no fun =
for the ISP and no fun for the customer. As a vendor, I talk with =
customers that use CGN now. They don't talk about being "on the =
Internet" as much as they talk about being some number of "hops away =
from the Internet". IPv4 CGN is not a great service, but it's what =
exists if you don't have the address space to build out with global =
addresses.

It's also a lot of effort for you. In essence, it means that you will =
renumber your network, withdrawing global addresses from customers and =
deploying private addresses. At some point, you will do so again - and =
again. It's like running with a stack of plates; you can always handle =
"just one more on the pile" with a little extra effort, but at some =
point the cumulative extra effort becomes quite a bit.

I will now refer you to the name of the email alias that Tina set up for =
this project. It is not KeepV4Running@ietf.org; it is =
V4toV6Transition@ietf.org. We'll acknowledge and help you with your very =
real business issues with your IPv4 network to the extent that we can - =
we all have them - and we will expect the network operator groups to do =
the same. But if you don't spend at least as much concern and effort on =
moving into the IPv6 future, the implications are yours, not ours. You =
really can't expect a lot of sympathy for not taking advantage of the =
available education, or for lack of planning, given how long we have =
known we were coming to this point.

<soapbox>
Speaking as the Chair of the "IPv6 Operations Working Group", I very =
seriously expect, starting now and from this point forward, that the =
discussion will not be about "keeping IPv4 running" anywhere near as =
much as it will be about IPv6 deployment issues, IPv4/IPv6 coexistence =
issues, and strategizing on moving your network and your customers into =
the very real IPv6 future. Keeping IPv4 running for a period of time =
will be among those coexistence issues, but cannot be allowed to =
dominate the discussion.
</soapbox>=