[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, 172.16,0.0/12 and 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

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

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