Subject: Re: [v4tov6transition] FW: New Version Notification for

From: [email-masked]
Date: Sat, 11 Sep 2010 21:24:27 +0000

draft-lee-v4v6tran-problem-01
Mime-Version: 1.0 (Apple Message framework v1081)
From: Fred Baker <[email-masked]>
In-Reply-To: <[email-masked]>
Date: Thu, 9 Sep 2010 18:39:42 +0900
Cc: <[email-masked]>, IPv6 v6ops <[email-masked]>
Message-Id: <[email-masked]>
References: <[email-masked]>
To: "Yiu L. Lee" <[email-masked]>
X-Mailer: Apple Mail (2.1081)
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Sender: [email-masked]
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 [email-masked]; it is =
[email-masked]. 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>=

---

From: Fred Baker <[email-masked]>
Date: Sat, 11 Sep 2010 21:24:09 +0000

Date: Thu, 9 Sep 2010 17:21:14 +0900
Message-Id: <[email-masked]>

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 [email-masked]; it is =
[email-masked]. 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.=