[arin-ppml] ARIN Draft Policy 2011-5: Shared Transition Space

[William Herrin]

On Tue, Jul 5, 2011 at 3:57 PM, Chris Grundemann <cgrundemann at gmail.com> wrote:
> In response to the IAB statement regarding ARIN-2011-5, several of us
> have compiled an Internet Draft analyzing the need for shared
> transition space. You can find it online here:
> http://tools.ietf.org/html/draft-bdgks-arin-shared-transition-space.

Thanks Chris, and everybody else who worked on this!

Some comments:

1. In 2.1.3, SP services is not a good use case. Quasi-multihoming
with a NAT box switching traffic between two separately numbered
Internet connections is becoming increasingly common. With a /10,
there's a very small chance of collision between the address assigned
on each connection, but with services hosted on that /10 that the
customer wants to reach, the chance of mayhem rises sharply.

2. Router interface numbering is a potential use case. Filtering of
RFC1918 is too widespread to overcome, so using it outside the NAT
breaks path MTU detection. That's not inherently true of this new
space and nonfiltering could be encouraged in a way that renders it
usable in a few years.

3. In 2.2.2 there's another conflict risk. Consider:

ISP uses: 10.1.0.0/16.
Customer directly connects a Windows PC. Assigned 10.1.2.3 by DHCP.
Customer connects Cisco VPN client (UDP tunneled IPSec) to work at 192.0.2.1
Work uses 10.0.0.0/8
www.intranet.work is at 10.1.2.3.

Uh oh.


4. In 4.1.2, common getaddrinfo() implementations follow RFC 3483 rule
7's requirement to prefer native transports. As a result, the 6to4
destination address is tried last (behind IPv4), further mitigating
effects from incorrect 6to4 instantiation behind a firewall that
obstructs its function.

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