Re: [v4tov6transition] FW: New Version Notification for

[Fred Baker <fred@cisco.com>]

draft-lee-v4v6tran-problem-01
In-Reply-To: <C8ADCBAA.317AD%yiu_lee@cable.comcast.com>
Date: Thu, 9 Sep 2010 17:21:14 +0900
Cc: <v4tov6transition@ietf.org>, IPv6 v6ops <v6ops@ops.ietf.org>
Message-Id: <927EA826-CEF7-4942-8AA5-45C0FA353446@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 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.

The effect of that 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 a lot 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, =
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, it won't be our networks that are no longer viable =
businesses, it will be yours. 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.

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 it must take second place to =
IPv6 deployment and operation of IPv6-only and dual stack networks.=