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

[Tony Hain]

William Herrin wrote:
> On Thu, Jun 30, 2011 at 11:10 AM, Tony Hain <alh-ietf at tndh.net> wrote:
> > William Herrin:
> >> 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.
> 
> Tony,
> 
> To be clear, you mean that if you're both using an IPv6 address from
> the 6to4 range (2002::/16) and have the appropriate encapsulators
> nearby then it will work reasonably. This is true to a point.
> 
> The point where it breaks is that the IPv6 address selection
> algorithms are not smart enough to prefer the 6to4-range IP address
> when the source is a 6to4 address and deprefrence it when the source
> isn't. 

Funny, mine has no problem with a 6to4, HE-prefix, & a ULA. Are you
suggesting IPv4 should be preferred to IPv6? If so you will never get there
because there will be no IPv6 traffic, therefore no investment by carriers,
therefore no traffic ... rinse & repeat. 

> V6's address selection algorithm uses the same
> order-I-got-it-from-the-name-server approach that IPv4 uses and the
> name server uses the same round-robining on AAAA records that it uses
> for A records.

That would be a broken implementation. The address selection rules
specifically state 'longest match'. The only time DNS order comes into play
is when you fall into the 'I don't care'/default policy table entry. 6to4
and teredo have explicit policy table entries, so DNS is a secondary
influence. 

> 
> Multiple address assignments on a single machine or single DNS name is
> IPv6's great White Whale. Like Ahab, we chase it at our peril.

It is a different model, so it will take time for people to get used to it.
We might even need a generational shift to get past mental blockages.

> 
> 
> > 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...
> 
> You offer a draft to remove the restriction on 2002:local:prefix
> appearing in the Internet's BGP table from the 6to4 RFC and I'll stand
> in support.

At this point that approach is DOA. By the time you get it through the
process 6rd deployments will be widespread. This is one where operators have
to just decide it is a best practice and move on without the official stamp
of approval.

> 
> 
> 
> >> 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.
> 
> It isn't there, but let's back off and talk about two points it seems
> we *all* agree on:
> 
> 1. Win7 won't configure a 6to4 tunnel if it sees an RA with another
> IPv6 address. Therefore even if Joel's problem were exactly as serious
> as he claims, it is within every ISP's power to prevent it from
> showing up by simply configuring an IPv6 pool alongside the 2011-5
> IPv4 address pool.

Absolutely, but most ISPs are not foresighted enough to get past the
eye-candy of the 'easy out' in a NAT444.

> 
> If Joel's concern was real, then IPv6 deployment is indicated in
> parallel with NAT444 using ARIN 2011-5's addresses. As policy
> side-effects go, that strikes me as very beneficial.

Unfortunately allocation policy does not dictate deployment practice. 

> 
> 
> 2. Win7 also defaults to installing Microsoft patches automatically.
> This means the one modifying tunnelling behavior for ARIN's new pool
> will be installed on the overwhelming majority of Win7 machines
> shortly after ARIN issues the space. Anyone with the wherewithal to
> alter that behavior can deal with other Windows oddities.

It is not that trivial. Pushing out a policy table change is one thing, but
a stack code change that might have region specific 1918-ish blocks is
another. 

> 
> 
> > Today you will find failure cases where people are using public IPv4
> behind
> > a nat,
> 
> I observe that most of the US Federal agencies use public IPv4
> addresses behind a NAT. Renumbering the internal networks out of their
> class B's when they deployed their NAT firewalls a decade ago was seen
> as costly and unnecessary.

And those federal agencies were supposed to be working on IPv6 deployments
more than 3 years ago ... ;0
They also have a much simpler situation because they can deploy isatap
routers, and as soon as that name resolves and the prefix is acquired from
the router it will be preferred before 6to4. This works fine as several
non-fed (ostensibly for-profit) companies have been doing exactly that for
years. 

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