Re: Defintion of Automatic tunnels

[Pekka Savola <pekkas@netcore.fi>]

On Wed, 30 Jul 2003, Erik Nordmark wrote:
> 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".

This is a very good post, and I agree it's very important to try to get to 
the root causes why automatic tunnels are considered better/worse than 
configured tunnels in some aspects.

My personal belief is that from Christian's Point-of-View (at least), it 
mainly boils down to point 6 -- I think he estimates that the number of 
nodes implementing the automatic tunneling mechanisms capable of 
"short-cut" routes is very high, so that the relay/server deployment is 
not so important.

Personally, I think the non-optimal routing not an important factor; if 
the traffic gets too rough, it just gives people incentive to deploy 
dual-stack (or better tunnels, e.g. to their direct ISP).

And if traffic gets too rough, it's just a sign of us succeeding and the 
time to retire automatic tunnels! :-)

On the other hand, relays are critical because they're needed *ANYWAY* for
communication with native IPv6 addresses, and providing a direct
communication when that criterium is not met is a non-goal for IPv6.  
Better not deploy it at all (i.e. wait for ISP/NAT vendor) than
improperly.

.. some more comments inline ..

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

True.

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

Agreed.  However, there are likely to be counter-arguments for a single
UDP port ("firewall FOO blocks that by default"), some of them maybe valid
and others not.  If we do so, we need to figure out when someone wants to
use a more flexible port number..
 
> 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. 

Yes.. assuming that such a list could be kept up to date somehow (not an 
issue), and that registration to each tunnel broker would be similar (so 
filling one form would be enough, you'd just send it to anyone you'd like 
to connect to).

> Or it would be
> possible to define an anycast address for the tunnel broker setup (not
> used for the tunneled packets).

A good alternative, this could be similar to 192.88.99.0/24.  The two of 
your proposals do not need to be exclusive, of course (could try 
192.88.99.0 and pop up the list of addresses).
 
> 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.

True.

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

Yes.  

Note that there may have to be a mechanism for the subscribers to keep the
same prefix.  It may be sufficient to depend on the IPv4 address of the
SOHO DSL/cable box (if it's acting as a router), and when that changes
(DHCP), the v6 prefix would also change.  In most cases, this would
probably be sufficient.  For full-fledged solution, you'd need 
registration (ie. AAA system to keep track of the prefixes).

So, I guess an important point is to figure out whether the IPv6 prefixes 
can be somehow magically tied to some IP[v4] addresses or other tokens 
when AAA system is not handy.

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

See above.

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

I think the ISP can reasonably well control that 6to4 relays are only used 
by their customers.

But there is more to being simple for ISPs to deploy.

For example, the point above: does it require an AAA system to keep track 
of prefixes given to the users?  The authentication of users?  6to4 does 
not require it; you just add one box to the network, and you're pretty 
much done (as an ISP).

Tunnel brokering is undeniably at least a bit more of a task.  Of course, 
we can mitigate that by giving advice etc.

Note that the ISP will need an AAA system anyway when it starts to offer 
IPv6 dual stack service (for prefix delegation/address assignment), so 
this is just having to implement it a bit earlier; maybe not a problem but 
could be.
 
> 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.

Agreed.

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

Agreed.

> For instance, it seems to me that this benefit goes away
> when only one of the communicating parties implement 6to4/teredo.

Exactly!

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

Exactly; more than once I've been bitten by a non-functioning 6to4 relay 
(for one reason or the other) at 192.88.99.0/24..

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

Yes.

> The teredo interactions
> with the large variation of NAT behavior makes this even harder.

Exactly my concern as well.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings