Defintion of Automatic tunnels

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

> During the Vienna meeting, I sensed that there was a split in the WG
> constituency between those who like automatic tunneling techniques such
> as 6to4 and Teredo because they enable automatic deployment of IPv6, and
> those who have an instinctive dislike for these technologies and would
> much prefer controlled mechanisms and the orderly deployment of tunnels.
> I would like to understand how we can resolve this tension.

I suspect that that the issues are complex and interrelated thus
trying to make a black and white distinction between automatic and
configured tunnels is hard.
Thus I've tried to put down different aspects of tunnels below and taken
the liberty of using tunnel broker as an example where "configured"
can actually look the same to the user as "automatic".

1. IPv6 tunnels on by default

Some vendors might want to make IPv6 easier for the users by turning 
on IPv6 tunneling by default (for instance where there is IPv4 connectivity
and no native IPv6 connectivity). Other vendors might prefer a "click
here to enable IPv6 tunneling". I think this is only implementation
issue except in the case of tunneling across NATs.

1b. IPv6 tunnels across NATs on by default

Tunneling across NATs, which by accident will tunnel across many firewall
configurations, presumably means that the IETF shouldn't endorse  a "default
tunnel across NATs" approach but instead suggest that the user be involved in
turning this on. Also, there might be a reasonable requirement that it should
be easy for network admins to prevent such tunneling by having a simple filter
(e.g. filter on a single UDP port.)

2. Single knob "enable IPv6 tunnel" for user

I think this can be implemented for a large number of tunneling technologies.
For instance, a tunnel broker client could have a list public tunnel brokers
and use ping times to select one. Or it would be possible to define an anycast
address for the tunnel broker setup (not used for the tunneled packets).

3. Registration and authentication of user

Some operators of infrastructure for tunnels, whether they fall in
what Christian calls "automatic" or "configured", might want to be
able to know who is using their infrastructure. Also, in the case
of DoS attacks or other issues such operators might want to be able
to point at "the source of that was this IPv4 address" to help
tracking down the problems.
On the other hand there might be folks, such as ISPs, which want to 
be able to provide tunneling infrastructure for a subset of IPv4 addresses
(such as the subscribers of the ISP) without requiring any explicit 
registration and authentication of the user.

Thus it would seem good if there either is one approach which can
optionally do registration and authentication at tunnel
establishment time, or there is one approach with and one without
registration and authentication.

4. Simple for ISPs to deploy

I'm not sure I understand the comparison here between the so called "automatic"
(6to4 and Teredo) and so called "configured" (tunnel broker or similar)
tunnels. With the latter the ISP can make sure they are only providing service
to their subscribers. Is the same true for 6to4 relays and teredo servers?

5. Providing visibility for those providing infrastructure

A non-technical issue is whether entities that provide some infrastructure 
for tunneling ("servers" or "relays") that is not limited to
users with which they have a subscriber relationship, are visible to the 
end users i.e. that the can derive some name recognition for their help.

6. Avoiding traffic concentration at some "server"/"relay"

One of the benefits of 6to4 and teredo is that traffic between nodes
that use that scheme can avoid going through a single point.
I think that this is really separate from terms like "automatic" vs.
"configured", and it would be good to understand the tradeoffs in
this space better. For instance, it seems to me that this benefit goes away
when only one of the communicating parties implement 6to4/teredo.
Also, at least in the case of 6to4, this benefit is accomplished at
the expense of making certain other things more difficult (such as having
multiple 6to4 routers between some cloud and the rest of the Internet).
Finally, there are operational implications of this type of "short-cut
routing". With tunnel broker configured tunnels I understand how to debug
problems thus I think if ISPs want to use them their staff can understand how
to debug  them as well (try a traceroute to/from the IPv4 address of the
tunnel endpoint, etc). And if things don't work one can try switching to
different tunnel broker.
With the shortcuts provided by teredo and 6to4 it is much harder to determine
whether it is an IPv4 problem (IPv4 might work to/from a relay without working
on the direct path) or IPv6 (IPv6 tunneling might work to/from a relay
without working to/from a particular IPv6 peer). The teredo interactions
with the large variation of NAT behavior makes this even harder.
[And combining this with anycast to simplify #2 above adds to the troubles
to debug.]
So color me concerned - I don't think we need the equivalent NHRP for IPv6
tunnels.

---

Perhaps there are more facets of the "automatic" vs. "configured" distinction
than the ones I've listed above.
But hopefully trying to tease apart the different facets makes
it easier to come to a shared understanding of the issues.

  Erik