Subject: RE: An alternative to 6to4 and teredo

From: "Christian Huitema" <[email-masked]>
Date: Sun, 19 Jan 2003 13:14:51 -0800

>> That's not all.  6to4/Teredo offer an automatic configuration using
>> anycast addresses.  Much easier than trying to figure out the closest
>> tunnel broker, configuring to use that etc.
>
> If somebody wants to provide a good tunnel broker service they can
> automate this without any changes in the clients. Just have multiple tunnel
> servers at different places in the topology and have the tunnel broker
> meaure or estimate the location of the client before handing it
> off to a tunnel server.

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.
 
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.
 
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.
 
-- Christian Huitema

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 20 Jan 2003 02:45:10 +0100 (CET)

> 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

---

From: Marc Blanchet <[email-masked]>
Date: Sun, 19 Jan 2003 22:26:15 -0500

-- dimanche, janvier 19, 2003 13:14:51 -0800 Christian Huitema
<[email-masked]> wrote/a écrit:

>> automate this without any changes in the clients. Just have multiple
>> tunnel servers at different places in the topology and have the tunnel
>> broker meaure or estimate the location of the client before handing it
>> off to a tunnel server.
> 
> 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.  
> 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.  
> 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

tsp with NAT traversal (udp encap similar to teredo) have an authentication
framework for users, so 
proving the identity of the user is already there.

Marc.

> 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.  
> -- Christian Huitema
> 

------------------------------------------
Marc Blanchet
Viagénie
tel: +1-418-656-9254x225

------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
http://www.normos.org: IETF(RFC,draft),
  IANA,W3C,... standards.
------------------------------------------

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 20 Jan 2003 11:14:49 -0800

Christian Huitema wrote:
 > 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.

There is also the cost issue of the number of messages required to set
up the tunnel. There needs to be a reasonably persistent flow of messages
from a source to a particular destination (or, from a source *through* a
particular tunnel broker) before the cost for tunnel setup can be amortized.
Thus, I agree with Christian that tunnel brokers provided by the ISP are
one example in which the cost is justified. In other cases, e.g., when the
source sends only a few messages to a particular destination) automatic
tunnelling mechanisms are more cost-efficient.

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

I agree with the complementary observation. Automatic tunneling
can provide the default behavior and configured tunnels (or,
"semi-automatic" tunnels) can be established when/if needed.
(Longest-prefix-match will steer packets to the appropriate
interface.)

Fred Templin
[email-masked]