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

[Fred Baker <[e-mail]>]

On Apr 28, 2011, at 1:07 PM, Martin Millnert wrote:

> Ole, 
> 
> part of this is slightly off-topic, to point 9, but highly on-topic in
> general.

Correct me if I'm wrong; the comment is specific to Teredo and not to 6to4, correct?

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

What I do not expect the IETF to do is recommend one overlay architecture instead of another. 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".
<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