[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 William Herrin
> Sent: Thursday, January 20, 2011 2:43 PM
> Subject: Re: [arin-ppml] ARIN-prop-127: Shared Transition Space for
> IPv4 Address Extension
> 
> ... 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. 
[WES] Agree, hold onto that thought for a moment...
>  
> 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.

[WES] Let's be clear, there are two separate problems here:
1) ISP assigns the same block of 1918 space to the external interface as is
already in use on the internal interface of a customer's home GW router and
badness ensues.
As you say, the NAT domain space could be as small as a /16, you'd just need
lots of domains. But that means that you only have to find one /16 that
impacts the least number of customers. When I say it has not been
conclusively proven that there are problems with all of the blocks, I mean
this - no one has put together a list of "vendor/model:default inside
address pool" to show that every single of the 70K /24s in 1918, or even
every /16 are in use BY DEFAULT. Lee cited a study in his message, but that
was done in Japan and I don't view that as representative of the ARIN region
due to the widely different group of gear available in each place.
NAT444 is *going* to suck, it is *going* to break things, it is *going* to
generate calls to tech support. I don't understand the resistance to
considering as collateral damage some subset of CPE devices that have to
change their internal address block config in order to continue functioning
in NAT444. Find the block that has the least number of devices using it by
default (avoid Linksys, Netgear and D-Link defaults, for example), and
choose that. For the rest, give your techs step-by-step documentation on how
to fix it on common routers. This is a long-tail problem that is somehow
masquerading as a huge issue. Further, if someone changes the DEFAULT as you
suggest, that is the same red herring that you say isn't an issue later in
your mail, because clearly they already know how to change it back when it
breaks things. If they don't like it, they're welcome to replace their gear
with something that properly supports IPv6...

2) Collision between external NAT interface address and internal corporate
network addressing. Last I checked, you can't route directly from a
broadband ISP to the inside 1918 address of a corporate network without a
VPN.* You need a routable external address somewhere on both sides. This
negates the issue, because you are then interconnecting the *inside* (home)
NAT to the inside of the corporate network. As long as the VPN works through
NAT444, the ISP NAT (the middle 4) address doesn't figure into the routing
decision. The existing problem of potentially having the same address block
in the home network as in the corporate one doesn't change just because
there's another NAT in between.
*Assuming the one notable exception being corporate customers using
broadband, the cleanest solution is to reserve a block of routable addresses
for this use so that they continue to have the whole of 1918 available for
their internal network use. They pay for business class service, an IP or
two should probably be part of that in the post-exhaustion world, especially
since chances are quite a bit higher than their stuff will break through
NAT444 anyway.


And for those who say "I support this because there's no alternative" I need
to remind you that the alternative has existed for some time now, and while
people are loath to admit it, already in use - squatting on allocated,
routable space that is currently not routed on the public internet. While
some of the space that is dark today might show up in the routing table for
the right price, it's a safe bet that certain parts of "three letter agency"
infrastructure is not going to be selling off their IP blocks to the highest
bidder and it therefore will stay unrouted. It's risky, no doubt, but the
risk is manageable. 

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/b786e390/attachment.bin>