RE: automatic tunneling and v6 interoperation

["Christian Huitema" <huitema@windows.microsoft.com>]

> 1) the implication of economics to automatic tunneling mechanisms
> 
> Christian stated that tunnel brokers and similar mainly make sense
(from
> economics perspective etc.) if the ISP [or maybe also a transit of the
> ISP, btw.] is providing the service.
> 
> However, what was not clearly noted that similar economics problem
exists
> with automatic mechanisms as well.  For example, if you want to go
from
> a Teredo host to {native,6to4} hosts, who is providing the relay
service?
> Clearly, the ISP where the Teredo host resides is not, because then by
> definition they could deploy e.g. tunnel service instead.

The hypothesis is that the relay is close to the "native host". During
the transition period, the native ISP have an interest in providing a
relay service for use by their native subscribers. Their subscribers
will enjoy better connectivity, i.e. will be happier. Providing the
service does not result in extra bandwidth requirement: the packets are
exchanged between your subscribers and the Internet; they are simply
using a v6-v4 path instead of a v6-v6 path.

> 2) the implication of "no relays" deployment to v6 interoperability
> 
> If there are no relays, note that every node a Teredo host needs to
> communicate with has to implement and enable Teredo, as well as
publicize
> the Teredo addresses in the DNS in addition to the others, correct?

They don't actually publish a Teredo address. I showed you Tuesday the
result of "ipconfig" on my XP laptop: I have public addresses associated
to the wireless interface, using the 2001:468:19ff:80::/64 prefix
announced on the IETF network; the Teredo interface is available for use
as a local relay, but only documents a link-local address on that
interface. (And we do not advertise link local addresses in the DNS).

> (Similar would be equally applicable to no-relays deployment of 6to4,
with
> the difference that every site, not every node, would have one enabled
> 6to4 router and publicized addresses.)

We should discuss 6to4 separately. There are significant differences.

> 3) lifespan of a solution
> 
> Solution like this must be supported for a long time, as long as there
are
> people who go through NATs, unless their mechanisms are collectively
> everywhere replaced by something else.  That may or may not be
reasonable,
> if you expect the implementation of the techniques in every node.
> 
> ==> trying to summarize..
> 
> So, I don't think Teredo (or 6to4 for that matter, but it's slightly
> better from the second perspective) really solves the "economics of
> providing IPv6 service" -problem.  The only thing it seems to solve,
to an
> extent, is a relatively smooth and direct IPv6 connectivity between
Teredo
> hosts.  On the other hand, speaking to any other kind of nodes (e.g.,
> 6to4, native, ...) is riddled with identical problems as the IPv6
> deployment at ISPs.

See above. The trick is that the relays are deployed by other ISPS, for
the benefits of their own customers.

> But I guess the question is whether we want 3 separate IPv6 Internets,
and
> reducing that would only be possible through the addition of the
lowest
> common denominator, Teredo, everywhere? (The alternative is a network
of
> relay systems, which don't make sense economically.)

We were actually careful to avoid that in the design of Teredo and in
our implementation choices. Native hosts definitely do not have to
advertise a Teredo address, and they would not have to implement a "host
based relay" if the ISP provided the service.

An IPv6 ISP that really wants to isolate its customers from the Teredo
technology can do that by providing native connectivity and a Teredo
relay (not a server). The ISP's customers will not need to implement
their own relay.

-- Christian Huitema