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

William Herrin bill at herrin.us
Thu Jan 20 14:42:35 EST 2011


On Thu, Jan 20, 2011 at 11:26 AM, ARIN <info at arin.net> wrote:
> ARIN-prop-127: Shared Transition Space for IPv4 Address Extension
>
> Updates 4.10 of the NRPM:
> A second contiguous /10 IPv4 block will be reserved to facilitate IPv4
> address extension. This block will not be allocated or assigned to any
> single organization, but is to be shared by Service Providers for
> internal use for IPv4 address extension deployments until connected
> networks fully support IPv6.

Tentatively SUPPORT.

It would have been nice if the IETF had gotten traction with a version
of this that didn't originate from a particular region but their
effort collapsed and that leaves the question to us. I don't know
about the rest of you but the five big-name ISPs I deal with *still*
haven't turned up IPv6 for me. This is gonna be a -long- transition
and conflicting your carrier NAT with your customers' interior private
IPs doesn't strike me as a winning proposition. Setting aside one
space that every ISP can use seems like a smarter solution than each
ISP carving out a piece of their otherwise publicly routable space for
the task.


On Thu, Jan 20, 2011 at 1:51 PM, George, Wes E [NTK]
<Wesley.E.George at sprint.com> wrote:
> - a /8 wouldn't even be enough in many cases (Mobile networks),
> - a /10 won't be enough in even more cases (they dropped to a /10 because a
> /8 was even more unanimously shot down in IETF), both meaning that you'd
> still end up with multiple NAT regions where you have to reuse the same
> space

Hi Wes,

As someone else pointed out, the only place you can't have duplication
is within the particular NAT domain. That could usefully span a /4 and
it could usefully span a /16. It's just a question of how many
addressing domains you have to break your CGN into. /10 strikes me as
a reasonable compromise number.


> - no conclusive evidence has been shown that there is actually a conflict
> with all portions of RFC1918 that make it unusable

I just programmed 10.0.0.0/8, 172.16,0.0/12 and 192.168.0.0/16 on my
network. My ISPs are now conclusively shown to have a conflict with my
active and valid internal addressing.

Seriously Wes, that's not a sound argument. There are only 70,000
/24's in RFC1918 space and folks who don't take their home routers'
default often select much more than a /24. Of _course_ any ISP of
non-trivial size is going to conflict with some of his customers if
they're both selecting from the same relatively small pool.

ULA needed a massive bit space to statistically avoid collisions. It
ain't in the numbers for RFC 1918.


> - there is no guarantee that people won't immediately start using it as an
> extension of RFC1918.

This is a red herring. Customers who deliberately break their networks
are in a whole different category than the ones where I've
inadvertently stomped on their reasonable and legitimate
configuration.


> - it breaks 6to4 and anything else that knows to behave differently if it's
> getting RFC1918 (non-unique) space

I'll give you that one for now, though I'm very suspicious of any
technology hard-coded to behave differently depending on where in the
unicast address space it finds itself.

Regards,
Bill Herrin



-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004



More information about the ARIN-PPML mailing list