[arin-ppml] Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension - IAB comment

[Owen DeLong]

On Jun 29, 2011, at 3:33 AM, Mark Smith wrote:

> 
> 
> On Wed, 29 Jun 2011 02:30:00 -0700
> Owen DeLong <owen at delong.com> wrote:
> 
>> The problems are multiple:
>> 
>> 	1.	It will increase the number of customers that must be moved from
>> 		current access technologies to NAT444.
>> 
> 
> So? IPv4 address sharing is inevitable. The only way to be fair about
> it to customers is to provide two product offerings - a shared and
> non-shared IPv4 address service, and make the latter pay more for it if
> they value it.
> 

Arguably it is more fair to grandfather existing customers as they are
and inflict this on new customers.

> Regardless, 2011-5 does not say minimising NAT444 use is one
> of it's goals. Being a /10, I think it is implying that NAT444 is going
> to be the default for normal residential customers.
> 

Being a /10 it is implying that very large providers anticipate being forced
to deploy very large NAT444 regional environments. It does not imply that
they expect to force all existing customers into that environment. It does
not imply otherwise.

Obviously beyond a certain point, NAT444 will be the default for new
normal residential customers. Whether it is to be inflicted on existing
customers is not clear and not addressed in the policy.

> 
>> 	2.	It will not allow the larger ISPs to approach this on a regional basis
>> 		(which 2001-5 would). By using 2011-5, the ISP can set up a defined
>> 		address space per region and start allocating to NAT boxes and
>> 		customers. While it won't provide one globally unique IP per customer,
>> 		it will allow each customer to have a regionally unique IP.
>> 
> 
> I don't agree. The 1/16th, 1/4, 1/8th etc. I used as examples are likely
> to be regions, as an ISP's network's topology tends to map to
> geographical regions. Regions might vary in size, however that is easy
> enough to deal with by setting your shared IPv4 address "unit of
> allocation" to the smallest of either that or the maximum number of
> customers the LSN box can handle. IIRC, based on a presentation on
> Cisco's CRS1 LSN blade, the latter is around 128K customers. Managing
> varying sizes of regional shared addresses is pretty much the same
> problem as managing variable length subnetting. 

You're ignoring the logistics of the transition process.

> 
>> 	3.	The approach you recommend below requires a lot of moving pieces
>> 		to all fall into place at the same time or nearly the same time and is a
>> 		much more complex and perilous migration scheme.
>> 
> 
> I know a number of networking people at ISPs who are not afraid of this
> "perilous migration", as it isn't any different to moving existing
> dynamic IP addressing pools around between BRASes/LNSes. Here's the
> process of deploying what I suggested -
> 
> 1. Install first LSN and switch it on, leaving this group of customer's
> public addressing as it is.
> 2. Install second LSN and switch it on. Move this group of customers to
> the address space being used by the group in step 1 when the LSN is put
> into production.
> 3. Repeat 2 until finished, likely over a time period of months.
> 
Not everything is a BRAS and all ISPs are not created equal.

> I can think of and have done much more "complex and perilous
> migration[s]". 
> 
So have I, but, that doesn't change the fact that this is a bad idea and
an unnecessary cost and risk.

> That being said, I didn't think RIRs were concerned with any of the
> issues related to how ISPs deploy the address space, and whether that
> deployment was "complex" or "perilous", just how much and what they
> wanted to use it for.
> 

Correct. However, you asked the question, so, I answered it.

> 
>> 	4.	See 1 above... it bears repeating.
> 
> So I'll repeat, IPv4 address sharing is inevitable. Giving away a /10
> implies that it is going to be the default. Giving away a /10 will only
> encourage NAT444's deployment, not reduce it. Only more IPv4 address
> space can reduce the need for it's deployment, and there's none left.
> 

IPv4 address sharing for new customers is inevitable. Nothing says that
IPv4 address sharing is inevitable for everyone. Making a /10 universally
available for shared use for this purpose will actually decrease the
number of customers that must be forced into this environment. It will
not encourage the deployment of NAT444 which is something every
provider I have talked to prefers to minimize and only deploy to the
extent and number of customers absolutely necessary.

More IPv4 space is not the actual answer to reduce the need for it's
deployment. First, it's an impossible goal. Second, the real way to
reduce the need for NAT444 is greater migration to IPv6 which provides
an actual long-term solution.

~15 years ago, we started with NAT as a necessary evil to buy us
enough time to develop and deploy IPv6. Unfortunately, in that time,
we developed and failed to deploy IPv6, so, now we ware where we
are, with NAT444 becoming a necessary evil to allow some IPv4
services to sort of continue to function in a degraded way until
we can migrate those services, devices, etc. over to IPv6.

Other than a few hardware vendors who expect big profits from it,
I don't know of anyone who regards NAT444 as a desirable solution.
Most that I speak to regard it as an inevitable necessary deployment
which will be ineffective and costly and which they thus hope to
deploy only to the extent absolutely necessary and only for the
amount of time it is absolutely required.

Fortunately for me, I'm fully dual stacked and have my own
addresses in both protocols. NAT444 will not affect me other
than to the extent it affects the ability of others to reach my
systems.

When I can't get public IPv4 from my residential ISPs, I'll
insist on public IPv6 and move my tunnels from IPv4 to
IPv6 transport. The dual-stack inside the tunnels will
remain the same and will continue to function just fine
without any NAT of any form.

Owen