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

[Owen DeLong]

>> 
> 
> 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 "<--->".
> 
I'm not sure everyone wants to move the LSN as far out as the BRAS.

> 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.
> 
More accurately to make sure that the CPE thinks the default next
hop is reachable via the external interface.
> 
> 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.
> 
This is not an entirely accurate assumption. I think many providers intend
to use dedicated hardware for LSN deployed on a regional basis.
This means that you have a pool of LSN devices and groups of
subscribers over a larger area that all need to be unique within that
larger area. In such an implementation, it is not hard to imagine
areas that contain 3 million+ customers.

> 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
> 
It's only excessive if everyone designs around your particular approach.
There are other approaches that are more cost effective for many
networks as they exist today.

The intent here is that the space under this policy would be shared
among those multiple instances within those carriers and that
various carriers could share the same space rather than each
requesting their own.
> 
> 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.
> 
If they force 100% of their customers to NAT444, yes. Most providers want
to subject as few customers as possible to NAT444 implementing it slowly
only where necessarily, primarily for new subscribers post runout.

> 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.
> 
Again, you are making HUGE assumptions about where the LSN occurs
which are not entirely valid.

Take out this incorrect assumption and your entire scenario crumbles.

So, unless you're offering funding for all of the retrofits that would be
required for carriers to redesign their networks around your model,
I think what you are proposing is a non-starter for many of the larger
networks.

Owen