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

[William Herrin]

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

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.


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



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

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.


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.


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

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