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

[George, Wes E [NTK]]

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Matthew Kaufman
> Sent: Thursday, January 20, 2011 12:00 PM
> Subject: Re: [arin-ppml] ARIN-prop-127: Shared Transition Space for
> IPv4 Address Extension
>  
> ... or IETF can direct IANA to allocate
> additional space for private addressing via the RFC process, extending
> the existing RFC1918 space. This is a region-independent solution.

[WES] Tried and failed.
http://datatracker.ietf.org/doc/draft-weil-opsawg-provider-address-space/ or
http://tools.ietf.org/html/draft-shirasaki-isp-shared-addr-05
I've had lengthy discussions with the authors of the draft and this policy
during and after the last IETF, which actually resulted in this draft:
http://tools.ietf.org/html/draft-george-ipv6-required-00

So we don't have to rehash this entire argument here, I encourage you to
read the archives of the IETF OPSAreaWG,
http://www.ietf.org/mail-archive/web/opsawg/current/maillist.html from about
10/26-11/17/2010, specifically the subjects that match draft-weil, and the
ones that start with "Heads Up"

TL;dr version of the arguments made in those threads- I oppose this. 
I'll be among the first to admit that NAT44(4) is inevitable, and blocking
this policy won't change that. 
I oppose it because:
- 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
- no conclusive evidence has been shown that there is actually a conflict
with all portions of RFC1918 that make it unusable 
- there is no guarantee that people won't immediately start using it as an
extension of RFC1918. 
- it breaks 6to4 and anything else that knows to behave differently if it's
getting RFC1918 (non-unique) space

> 
> Note that this is also a case where some providers might be able, due
> to
> the characteristics of their devices, to use class E space, some of
> which could also be set aside for this purpose.

[WES] This has also been discussed in the past. There are too many devices
that reject Class E space as invalid. Stupid on the part of the vendors in
question, but that ship sailed long ago. The work necessary to fix this (or
to tack additional space onto RFC1918) would be much better served replacing
the same legacy gear with gear that supports IPv6 properly to reduce the
need for NAT44(4). Since I know NAT44(4) will be required (I have to do it
too), it's best to just acknowledge that we have to either squat or use 1918
and deal with the repercussions of either. I know ARIN can't officially
sanction squatting on legacy space that will never be routed on the public
internet, but it's already happening, and reserving this space is too
little, too late.

Wes George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6793 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110120/73639ebc/attachment.bin>