[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 2:15 AM, Joel Jaeggli <joelja at bogus.com> wrote:
> > On Jun 29, 2011, at 4:44 PM, William Herrin wrote:
> >> You are mistaken sir.
> >
> > I would like an apology.
> 
> Joel,
> 
> Your experience differs from others'. Is it because you tested with
> home premium and I tested with another version? Is it because you
> tested with the rare store-bought version while I tested with a
> preinstall? Is it because you tested with an unpatched version while
> my service pack and patches are up to date?
> 
> I also can't help but notice that your "freshly installed" windows
> already has vmware server on it. What other extra features and
> software were installed that aren't ordinarily there?
> 
> When you can explain why your experience differs from everybody
> else's, we'll talk about who is owed an apology.

The defined behavior for Vista onward is for IPv6 to be on by default, and
attempt the most efficient tunneling in sequence when native is not on the
local network, and the previous tunnel failed. This is not SKU dependent, as
the stack is common across Vista/W7/Server2008/SBS2008/SBS2011. It really
doesn't matter what apps get installed, this is the core Windows stack
functionality. 

The only difference you will find between service pack versions of those is
in recent address selection policy changes. Those changes are not the most
effective for getting IPv6 enabled applications deployed, but they are
pragmatic in the face of the lame infrastructure deployment that is still
not really happening. The most significant difference is found between the
current stack and the XP/W2003 stack, but even in the older stack the tunnel
approach is consistent.

The entire point of tunneling from the host was to "make the API just work".
It was clear a decade ago that infrastructure providers would not deploy
until there were apps, but app developers couldn't make progress without a
network. To break the stalemate I put the stake in the ground that the API
would just work and the stack would take care of the details of making that
happen. It will always defer to native, and will prefer the most efficient
mechanism first, but at the end of the day bit delivery was the point. 

Where that falls down is that the content providers have decided they want
to play a purest game of 'the single address model is how I do IPv4 and I
will do the same for IPv6'. By refusing to put content directly on the "IPv4
as a global NBMA L2" infrastructure, they force traffic through 3rd parties.
This is not a technology requirement, it is an operational choice, and even
when the Dr. says "stop banging your head against the wall and it will stop
hurting", they continue to insist on historical practice.

Given your local system doesn't seem to be establishing tunnels, I suspect
you will find there is an IPv4 firewall blocking both protocol 41 and the
UDP port teredo needs. If you watch it will likely also be asking DNS for
isatap.your.domain because it is not getting anything native to work with.
It will periodically try all 3 tunnels unless it hears a native RA, and even
if one tunnel technology gets established, it will periodically try more
efficient ones and switch to the 'best available'. Again, the point is that
app developers don't want to care about how bits get delivered, they just
want their app to work without causing them support nightmares. Synchronized
global deployment is not going to happen, and anything less becomes a
nightmare for app support. Masking over the haphazard native deployment
events is the only way to break the stalemate.

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
> _______________________________________________
> PPML
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.