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

[Chris Engel]

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

I can confirm that Tony's description of the Vista/Win7/Server 2008 stack matches the behavior we've seen on all the OEM installs we've gotten in from that generation. It's why unbinding IPv6 and disabling teredo are part of are standard setup routine for all Windows machines. The two inevitably cause things to break within the Enterprise and are a potential security complication as well. But I can confirm that MS doggedly does it's best to try to get you to use them, whether you want to or not ;)


Christopher Engel