[arin-ppml] ARIN-prop-127: Shared Transition Space for IPv4 Address Extension

[Mark Smith]

On Fri, 21 Jan 2011 13:32:07 -0600
Jack Bates <jbates at brightok.net> wrote:

> On 1/21/2011 12:22 PM, Owen DeLong wrote:
> > You are running a much smaller network than many of these guys.
> >
> > They are planning to duplicate this /10 around their different network areas.
> >
> 
> My point is that if they are large enough to utilize a /10, they 
> probably already have much larger than a /10 in their network. Duping 
> existing assignments would be just fine.
> 
> > To do this from existing space, you would basically need to turn off 2 regions and renumber
> > all of the subscribers in one to match the addresses of the other. Then you would need
> > to come up with additional addresses for all of the LSN/CGN boxes on the interior side
> > and for the shared external addresses. I suppose you could use the addresses recovered
> > from the second region, but, if your region contains more than 1,000,000 customers, it
> > seems to me like it would be pretty difficult to do this juggling without significant down
> > time.
> 
> The interior addressing would be an already existing network. It would 
> also be the first network to undergo NAT444. That network can then be 
> duplicated onto other networks.
> 
> > Instead, it's much easier to write up a use-case for the addresses you need for this
> > and submit it to the RIR. Sure, probably nobody gets a /10 for this, but, not hard
> > to imagine ways several /14s, possibly a few /12s, and certainly a number of
> > /15s and /16s go out the door that way. If it goes that way, none of the ISPs have
> > any incentive to share those intermediate addresses with the other ISPs and
> > a few downsides to doing so.
> 
> If they ask, they'll be asking for the public facing addressing (which 
> must be unique) while they work on renumbering the millions of internal 
> addressing. The request for external addressing is much less.
> 
> 
> > I think many providers are goint to hit the wall with need for NAT444 well before IPv6 is the mainstream protocol and not before we have run out of IPv4.
> >
> 
> Perhaps, and they easily can use their existing addresses. The 
> additional addressing you need is to cover the external side of the 
> NAT444. Once that is established, you can renumber inside to heart's 
> delight. Could be that you have multiple /8's worth of inside 
> addressing. The NAT444 system isn't really going to care what's on the 
> inside much.
> 
> The /10 shared won't work for the outside. People will request for 
> outside facing addressing to deal with the transition to NAT444. The 
> inside addressing can be anything, and as NAT444 is deployed, they can 
> start replicating their entire address space.
> 

To further expand on this, here would the scenario within an
primarily residential ISP -

<RFC1918>[CPE NAPT]<--->[LS NAPT]-{ISP network/Internet}

The address space being discussed is what is used between the [CPE
NAPT] and [LSN(BRAS)] device - in the segment shown as "<--->".

The requirements for this addressing are

- doesn't overlap with any RFC1918, to be sure the CPE uses it's
  default route for outbound traffic.

- doesn't overlap with any Internet/ISP destinations outside the LSN
  domain, so that the CPE doesn't think the addresses are onlink on
  it's WAN interface, and ARP for them instead of using the LS NAPT to
  reach public Internet/ISP destinations.

- is enough addresses to uniquely address every CPE's WAN interface and
  the LS NAPTs downstream interface, so that for inbound traffic, post
  NAPT, is sent to the correct CPE. Note, this uniqueness requirement
  is limited to the CPE/LS NAPT domain. Outside of it / upstream of it,
  this CPE/LS NAPT address space can be duplicated, because it is
  hidden behind the NAPT function being performed by the LS NAPT device.

So, assuming the LS NAPT device is either a BRAS or CMTS, the size of
the address space needed between the CPE and LS NAPT is dictated by the
number of subscribers that can be realistically served by the BRAS/CMTS
LS NAPT device or pool of devices. I'm pretty sure it isn't 4 194 304
(/10), and more likely absolute maximum of 128K, and probably more
commonly no more than 32K. Bear in mind that a new constraint on the
capacity of an BRAS/CMTS also performing LS NAPT is the maximum size of
the NAPT state tables and the processing involved in maintaining them,
such as watching TCP flags, aging out UDP "connections", translating
addresses in headers and payloads etc.

So if ARIN were to give away public address space for this specific
purpose, a /17 should be a reasonable maximum size, or possibly a /16 -
a /10 is obviously excessive. However, I still think ISPs should be
using their own existing, or newly requested via existing mechanisms,
address space for this purpose, duplicating it for how ever many
instances of CPE/LS NAPT the need for their customer base size. That
scenario will look as follows

<RFC1918>[CPE NAPT]<--->[LS NAPT]-{ISP network/Internet}
                                   /  /  /
<RFC1918>[CPE NAPT]<--->[LS NAPT]-/  /  /
                                    /  /
<RFC1918>[CPE NAPT]<--->[LS NAPT]--/  /
                                     /
<RFC1918>[CPE NAPT]<--->[LS NAPT]---/

The pool of global addresses shared by the downstream CPE are provided
at the LS NAPTs. If an ISP adopts a 1 to 2 address/CPE sharing ratio at the
LS NAPT location, they've immediately halved their global address
requirements for the CPE LS NAPT domain. Assuming they don't put
business customers behind the LS NAPT, and if they have a large
residential customer base, they're likely to be able to nearly halve
their existing global address requirements, which should free up plenty
of their own existing address space for use in the CPE /LS NAPT domains.

For ISPs who are providing services via PPP/PPPoE, they may actually only
need one single address for this purpose - the unique CPE identification
requirement between the LS NAPT and the CPE could be served by the
point-to-point session/interface descriptor, rather than using an IP
address assigned to the CPE. All customers would be assigned the same
WAN address on their CPE, with only that single IP address needing to
meet the requirements I outlined above.

Regards,
mark.