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

[Mark Smith]

On Thu, 20 Jan 2011 14:42:35 -0500
William Herrin <bill at herrin.us> wrote:

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

Why should the global Internet community (i.e. the end-users of
the Internet) have to help wear the costs of individual ISPs not
deploying IPv6 quickly enough? An ISP having to re-use its own publicly
routable address space for this purpose seems perfectly fine to me -
they created the problem and the cost by not deploying IPv6 soon enough,
now they themselves need to accept and pay the consequences, despite
not wanting to. Helping ISPs avoid those costs turns the
situation into one of a Moral Hazard. It won't encourage IPv6
adoption; it'll delay it because both the incentive to do so, and the
consequence of not doing so, are reduced. This is in effect "bailing
out the ISPs" using public address space.

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