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

[Tony Hain]

William Herrin:

> On Thu, Jun 30, 2011 at 9:49 AM, Tony Hain <alh-ietf at tndh.net> wrote:
> > The braindead concept that 6to4 gateways are required is driven by
> the
> > myopic view of the content providers.
> 
> Tony,
> 
> I wish that was the case. Sadly, traffic is two-way. Even if the
> content providers encapsulate the packets back to IPv4 before they
> leave their network, the the client-side's nearest usually
> volunteer-run anycast gateway from the v4 to the v6 core also has to
> be reasonably located.

Look closely at the technology. I understand it is two way, and the point is
that if they are running a 6to4 ROUTER (note not -relay- as recent testing
results are doing) they will be doing a peer-to-peer IPv4 encapsulation. The
thing they need to do is ADD a 2002:: prefix to their content. Address
selection on the client will prefer longest match, so if it is in 2002::
space it will pick the 2002:: destination and the 6to4 routers will do
direct encaps to each other. The only time a 3rd party gets involved is when
one end of the conversation is not in 2002:: space.

> 
> I like the 6to4 protocol. I too wish its use had turned out
> differently. But the unfortunate choice not to allow its prefixes to
> migrate into the global table guaranteed it would be a side show
> instead of the major transition tool that would have smoothed the path
> into v6.

This is another FUD / BS / ... position that is an operational choice.
People violate RFCs all the time, but the FUD mindset here puts a one-liner
added at the last minute as sacrosanct. If every access provider ran a 6to4
relay and injected the 2002:local:prefix:: into IPv6 BGP, yes the table
would grow, but it would be exactly the same outcome as deploying 6rd. What
are people doing? They are certainly not concerned about IPv4 table growth,
as they continue to do intentional deaggregation. They are deploying 6rd in
separate prefixes, again not caring about table growth. If someone suggests
that they do the same to support 6to4, all the zealots come out and scream
about violating an RFC. This is nothing more than theatrics intended to
stall deployment...

> 
> 
> >> Sadly, I must report the story to be false. My Windows 7 laptop did
> >> not, in fact, install a 6to4 adapter or configure an IPv6 address
> when
> >> I reprogrammed my DHCP server to give out a global scope IPv4
> address.
> >> And the Teredo Tunneling interface remained in state "Media
> >> disconnected." Indeed, only the normal fe80 link local IPv6 address
> >> configured itself on my machine.
> >>
> >> You are mistaken sir.
> >
> > Look around, because your symptoms indicate there is an IPv4 firewall
> > filtering both 6to4 and teredo packets.
> 
> Ordinarily. However, in my tests last night I removed that equipment
> from the path. And I should know. I personally built the network in
> question all the way out to where it trades BGP upstream.

I understand, but look again. I am not speaking for MSFT, but I was the
program manager the put the stake in the ground and set the direction for
how that stack works and why. This is a much bigger problem than managing a
network, and all the problems created in the network core are noise in the
grand scheme of managing all the application endpoints. This is all about
trade-offs, and sometimes the core has to be less efficient for the good of
the overall eco-system.

> 
> But then, if Windows is smart enough to test for actual connectivity
> before bringing up a v6 auto-tunnel my point is proven anyway. It'll
> fail to find 6to4 connectivity in the NAT444 scenario using a public
> scope IPv4 address, invalidating Joel's claim of relevance to ARIN
> proposal 2011-5.

It doesn't test for connectivity because there is no valid test. Just
because it can or cannot find a relay means nothing in terms of its utility
for peer-to-peer functions. You have to test every endpoint separately
because the logical substrate is an NBMA L2 network. 

Today you will find failure cases where people are using public IPv4 behind
a nat, and that will only be worse as carriers deploy more nat using
non-1918 space. Again, there is no valid test at the 6to4 level to figure
out if this is happening. One might use something like stun to detect the
presence of a nat, but lack of one does not tell you if a firewall is
blocking protocol 41. Both of those will prevent 6to4 from working. Even if
you tested and found a relay at the anycast address, you don't know there is
a valid path. One of the mitigations I tell enterprise managers about is to
deploy a 6to4 relay on the anycast internally, then null-route the back
side. This will both ensure that client systems are not automatically
bypassing firewall rules by tunneling, as well as provide an IPv4 identity
of a client that is attempting to do so if they intended that function to be
turned off. 

The point is there are lots of ways to break things, the trick is to find
ways to make them work without requiring end user awareness, or massive
support structures...

Tony

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