RE: An alternative to 6to4 and teredo

[Erik Nordmark <Erik.Nordmark@sun.com>]

> Even if you solved the set up issue, there would still be the matter of
> cost. Tunnel brokers are only "cost neutral" if they are provided by the
> user's ISP. On the other hand, if the tunnel broker has to be accessed over
> the Internet, then there is a direct bandwidth cost: the tunnel broker
> essentially becomes a secondary ISP. The cost may not be quite as large as
> the primary ISP, as there is less equipment involved, but it is of the same
> order of magnitude -- maybe 1/4th of the price of a regular subscription.
> You are unlikely to finance that kind of of cost with advertisements alone.

I don't know the cost distribution for an access ISP, but I'm imagining
a lot of it is related to the access equipment and network (modems,
DLS stuff, cable plant and modems) whether they own or lease that.
Some part of the cost is related to the aggregate bandwidth they support,
but I have no idea how big part.

Thus I think this is a business opportunity to explore.
With a vendor hat on I'm sufficiently concerned about the operational
complexity of 6to4 and teredo that I'm willing to put tunnel broker clients
into our product.
 
> Rather than opposing tunnel brokers and automatic solutions, we should
> consider them complementary. Something like, use autoconfiguration by
> default, switch to a provisioned tunnel if one is available. In the case of
> 6to4, this essentially boils down to replacing the default "anycast" route
> by the specific address of a configured (or brokered) relay. In the case of
> Teredo, this requires provisioning a "configured" mode.

So by default the box would use teredo/6to4? And then the user has
to expicitly (or implicitly by configuring a tunnel) disable that?

This means that if the teredo/6to4 is operationally unstable
both the box as well as the new-fangled IPv6 thing will be perceived to
be broken.
Contrast this with a "click her to enable p2p games using the new IPv6 
technology" ability you have if you make the users have to actively take
one step to enable things. If it doesn't work well then they
can at least turn it off.

> I actually debated this "configured Teredo" option with Keith Moore last
> year. You have to solve a basic security issue: a configured option requires
> some way to assert and prove the client's identity, so the client can retain
> a stable IPv6 address even if the NAT mappings happen to change. At the
> time, we could not agree on a simple security procedure, but since draft 08,
> Teredo's initialization process actually includes a sign on procedure. It
> would be fairly easy to program clients to go to a Teredo server and receive
> either a Teredo prefix of a stable prefix; in the latter case, the client
> would simply switch to tunnel mode. This would allow both the "free server"
> model of the current design, and a "configured server" model when the local
> ISP is willing to support it.

In the "tunnel mode" case do you still attempt to establish direct paths 
between NATs? 

We have zero operational experience with such approaches and
I have no idea how to debug such a setup should I be exposed to it
(since there is a NAT between me and the NET I can't view the real
net for sure, which makes debugging a real pain for these types of
improvements).

  Erik