[v6ops] On Teredo [was Re: 6to4-historic summary point: 9. "why 6to4 is preventing 6to4 roll out"]

[Martin Millnert <[e-mail]>]

Fred,


On Thu, 2011-04-28 at 13:31 -0700, Fred Baker wrote:
> Correct me if I'm wrong; the comment is specific to Teredo and not to 6to4, correct?

Yes, you are right. Overall the comment was mostly specific to Teredo.

> </chair>
> Speaking strictly for myself, I would seriously wonder why the
> alternative to any overlay architecture is not native deployment. 

I agree completely that native IPv6 is the end-goal.

My (before mis-placed) point is simply that recommending the removal of
an overlay protocol (Teredo in this case) without proof of actual
users/providers actually being adversely affected by it (clearly not the
case with 6to4), *will not* in itself result in giving these users
native IPv6.  And leaving the protocol in place, will, likewise, not
give these users access to IPv6 web servers via native IPv6
connectivity.

That was clearly not the topic of point 9, and in retrospect I should've
restricted my response to the lack of evidence of any causality between
the (non-http) traffic levels seen in Teredo with applications not
following the provided 3484 on their host and doing their own thing,
presented in Geoff's thorough research article.

I did continue by offering an explanation on why I believe that largely
to be a completely inaccurate explanation for the traffic measured in
Geoff's work. (Ie, largely, traffic exists with no rule-breaking going
on).

> The concern raised with 6to4 is the set of use cases in which it
> doesn't work as expected, for any of a variety of reasons, and as a
> result inhibits consumer interest in IPv6 or distracts service
> provider attention from native deployment. 

Yes, and I'm also in agreement that phasing out 6to4 is the right action
now.

> If your statement is that the IETF is irresponsible in pointing out a
> deployment solution that isn't working as well as hoped for without
> providing an alternative, I think the IETF has set forth (and service
> providers are in the process of deploying) a replacement.

No, that was not my statement (see above)!

> What I do not expect the IETF to do is recommend one overlay
> architecture instead of another. 

I was not suggesting the IETF to recommend operators to let their users
rely on overlay architectures as the users means of IPv6 connectivity.  
  I very much welcome clear evidence that Teredo is an obstacle to
native deployment.  I don't think it is, and I can't remember seeing any
such evidence so far.  Teredo is there, with a purpose, [and until
proven otherwise, ] it does not hurt native v6 deployment - and
recommending removing it solves nothing.

> In RFC 6180 (aka draft-arkko-ipv6-transition-guidelines), Jari and I
> tried to point out things that were known to work in deployment as
> general advice in "how to get over a bump in the deployment roadmap",
> but our point was explicitly not to say "deploy this overlay and
> stop". To our minds, and I understood the working group's mind, the
> finish-line is "the universal deployment of native IPv6".

No arguments here.  Personally, I believe we can approximate having
reached the finish line to when deploying a single-stack native IPv6
network is the norm.


Best,
Martin

> <chair>
> 
> > On Thu, 2011-04-28 at 20:37 +0200, Ole Troan wrote:
> > <snip>
> >> that's only measured at a web site. 
> >> if I understoof Geoff's (cc'ed) analysis correctly, there is a lot of other traffic too.
> >> http://www.potaroo.net/ispcol/2011-04/teredo.html
> >> 
> >> created by applications doing their 'own' thing and not following the default policy table.
> > 
> > Yes and no.
> > Yes, there is a substantial amount of Teredo traffic, yet the protocol
> > is virtually never used for HTTP.
> > No, I find no suggestion in his article that this traffic is created by
> > "applications doing their 'own' thing and not following the default
> > policy table".  
> > 
> > To take a very real example: the various torrent DHT "clouds" are
> > teeming with IPv6 end-point addresses.  Connecting to these with Teredo,
> > if available, is in accordance with 3484, if that is the only v6
> > connectivity a host has.  The alternative is, of course, to not connect
> > to them at all.   Same goes for a host using any other form of IPv6
> > connectivity to make a connection.
> >  These are not hostnames resolving to A/AAAA records. And even if they
> > were, as Geoff points out in his article, Windows 7/Vista will not even
> > resolve the AAAA record, if Teredo is the only non-link-local v6
> > connectivity a host has! Now we may discuss an operating system not
> > following the default policy table, but not applications.
> > 
> > 
> > Let me drive my point home:
> > 
> > People say/argue Teredo (and 6to4) is bad because many connections fail,
> > among other problems, but Teredo isn't the black sheep in the automated
> > v6-tunneling family, and it does address a very real problem (lack of
> > IPv6 connectivity). I haven't heard a single content provider say they
> > will hold back deployment of AAAA records because of it.
> >  The responsible thing for IETF to do wrt. any deprecation of Teredo is
> > to provide a realistic alternative solution *before* doing so (to
> > include in a phase-out plan of the protocol, for example), unless it
> > wants to be tilting at windmills.
> > 
> > If Teredo can be replaced by another protocol addressing the same
> > problem space, which somehow has a much better connection rate, I would
> > be all for that :)  If not, the problem does not really truly lie with
> > the IETF, short of a Teredo-advisory.
> > 
> > 
> > I do think this may be showing that 3484 is insufficient when it comes
> > to addressing (no pun intended) the *varying* connectivity needs of
> > various applications:  
> >  Some applications, predominantly such with plenty of redundancy, are
> > quite fine with a v6 where connections fail 1 out of 3 times. To me this
> > mostly shows how insufficient non-end-to-end NATed IPv4 is on the
> > Internet today.
> >  Other applications really depend on their connections to succeed if
> > attempted, and would probably prefer to fail with
> > -EINADEQUATECONNECTIVITYPRESENT, rather than launch a connection attempt
> > using last-resort connectivity.
> > 
> > More skilled socket API folks than I are highly welcome to school me on
> > the following idea:
> >  If OS socket API:s were to provide a way for applications to require
> > better-than-last-resort connectivity (or inverse, accept last-resort
> > connectivity), that could be useful for application developers IMO.  
> > I guess it could be a two-dimensional approach, with the ability to make
> > or relax this requirement on both the source and the destination
> > address.
> > 
> > Blizzard recently seems to have figured out to suggest native IPv6 to be
> > used ("Use IPv6" box default checked with this connectivity present at
> > the box), but not 6to4/Teredo ("Use IPv6" defaults to unchecked).
> > This seems IMO like a useful approach in addressing this problem, i.e,
> > application-specific, since only the application itself can know its
> > requirements.
> > 
> > Best,
> > Martin
> > 
> > _______________________________________________
> > v6ops mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/v6ops
>