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

[Mark Smith]

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.

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.


> 	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. 

> 	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.

I can think of and have done much more "complex and perilous
migration[s]". 

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.


> 	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.

Regards,
Mark.

> Owen
> 
> On Jun 29, 2011, at 2:24 AM, Mark Smith wrote:
> 
> > On Wed, 29 Jun 2011 06:40:53 +0000
> > John Curran <jcurran at arin.net> wrote:
> > 
> >> On Jun 28, 2011, at 3:05 AM, David Farmer wrote:
> >> 
> > <snip>
> >> 
> >> I will convey this to the ARIN Board as one possible course of action 
> >> when it considers the IAB response. Making the reservation for this 
> >> purpose without conferring with IAB would not have respected the nature
> >> of the ARIN/IANA relationship, and the exact degree of engagement with 
> >> the IETF community which is most appropriate is a matter of judgement.
> >> To the extent that we have a clear document in the IETF which explains
> >> why the reservation is needed, along with a strong show of support in
> >> that community, the path forward will not be difficult.
> >> 
> > 
> > It also needs to describe what the problem is with ISPs
> > reusing/recycling parts of their existing public address space for
> > this purpose i.e.
> > 
> > 1. move 1/16, 1/8, 1/4 etc. of customers behind 1st LSN box.
> > 2. duplicate the use of the ISP's existing public address space being
> > used by that first "LSN domain" group of customers on subsequent LSN
> > domains for the rest of the customer base.
> > 
> > For example, if an ISP has 8 LSN domains, once they're deployed, the
> > ISP has recovered 7/8ths of their existing public allocation through
> > duplicating 1/8th of it 8 times. They could give most of that 7/8ths
> > back to their RIR, which will increase the available IPv4 address pool,
> > extending it's life. On the scale of the ISPs proposing 2011-5, the
> > return of IPv4 addresses should be significant, even if they only
> > deployed 2 LSN domains (i.e. recover 1/2 their IPv4 addresses) across
> > their customer base. An ISP would have a financial incentive to return
> > these addresses, to reduce their RIR fees.
> > 
> > This method won't provide a unique and individual IP address per
> > customer within the ISP, however that is not a requirement stated in
> > 2011-5, and nor will the /10 provide that for some of the ISPs behind
> > this proposal.
> > 
> > 
> >> Thanks!
> >> /John
> >> 
> >> John Curran
> >> President and CEO
> >> ARIN
> >> 
> >> 
> >> _______________________________________________
> >> PPML
> >> You are receiving this message because you are subscribed to
> >> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> >> Unsubscribe or manage your mailing list subscription at:
> >> http://lists.arin.net/mailman/listinfo/arin-ppml
> >> Please contact info at arin.net if you experience any issues.
> > _______________________________________________
> > PPML
> > You are receiving this message because you are subscribed to
> > the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> > Unsubscribe or manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/arin-ppml
> > Please contact info at arin.net if you experience any issues.
>