[arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension]

[George, Wes E [NTK]]

-----Original Message-----
From: Owen DeLong [mailto:owen at delong.com] 
Sent: Tuesday, February 22, 2011 1:13 PM
Subject: Re: [arin-ppml] [Fwd: Draft Policy 2011-5: Shared Transition Space for IPv4 Address
Extension]

>Their 40 parallel RFC-1918 addressing domains are all under their control and can easily be
coordinated by VZW.

>You're option 4 expands that to 100 million parallel addressing domains not managed by VZW + 40
that are + some additional >number that are, but, by definition likely overlap the existing 40.

[WEG] Owen, this statement is mostly FUD, and I'll thank you to stop confusing the issue. 
The original problem was "we don't want to use 1918 for outside CPE NAT interface because we're
worried that it'll conflict with the address space assigned on the inside NAT by default". Somehow
that has now morphed into 100 million parallel addressing domains and a concern about overlap
between them because they're not all managed by the same entity. So now it's my turn to say, "Huh?"
You're right that it's not a perfect justification for expecting to use 1918 space in a NAT without
conflicting with CPE default config, because this CPE is centrally managed by the ISP, but that has
nothing to do with how many places it is being used. 
It actually provides an excellent proof that RFC 1918 can be used in a Carrier NAT without
conflicting with other networks' NAT and internal use of RFC1918 space, because it's not possible to
route directly from your internal address behind $ISP's CGN to another company's internal address
behind their NAT without traversing the externally routed public IPs between destinations, meaning
that each sees a unique address that doesn't conflict.

Address collision between NAT domains within a company that is repeatedly using the same block of
addresses is a problem regardless of if you use 1918 or an ARIN-designated /10, assuming you need
more than a /10 of addresses, so I don't see that as a valid justification for ignoring 1918 as a
possible solution.

The point of contention that remains is exactly how much of a problem managing some minority of CPE
devices that are configured to use the "wrong" portion of 1918 and have to be reconfigured (or
better still, replaced with something that supports IPv6) to prevent that conflict. I maintain that
CGN is going to cause enough support calls that it's overly simplistic to assume that just because
you're not using 1918 it'll be orders of magnitude easier. But without real evidence, it's just one
set of conjecture against another, and we're really not getting anywhere.

Wes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6781 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110222/e39a7ed1/attachment.p7s>