Subject: RE: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt

From: "Christian Huitema" <[email-masked]>
Date: Tue, 4 May 2004 18:26:58 -0700

> How widely is IP proto 41 forwarding deployed? If it is not much,
> I suppose that forcing an extra layer of encapsulation would
> not be that terrible... and also would allow for more than one
> tunnel to go through the NAT box.
> So, I do not think that detecting NAT proto 41 forwarding is
> an important requirement.

You have to be concerned with the case when there are two hosts doing
this behind the same NAT. At most one of them will get proto 41
connectivity. If one got it and a second tries, the first one will loose
it. The support issues are going to be interesting.

-- Christian Huitema

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 May 2004 08:41:22 +0300 (EEST)

> it. The support issues are going to be interesting.

This is a good point to keep in mind, seems to clear call for using
UDP encapsulation in all the NAT traversal cases by default.  The
implementations might have a manual means to force using proto-41, but
even that might be far-fetched.

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

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Wed, 5 May 2004 09:47:39 +0200

That's true if both hosts try to use the same Tunnel server.

But I also believe that when there are several host behind a NAT, or in the same LAN, is more interesting to use proto-41 or any other mechanism to provide a single prefix to all the LAN. It provides a lot of advantages.

It should not be very difficult, as part of the implementation of the tunneling protocol (TSP or whatever), detect this situation automatically and even configure one of the host as "router" for the rest of the network.

I'm trying to clarify this in the next release of my I-D.

Regards,
Jordi

----- Original Message ----- 
From: "Christian Huitema" <[email-masked]>
To: "Alain Durand" <[email-masked]>; "Pekka Savola" <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, May 05, 2004 3:26 AM
Subject: RE: REVIEW NEEDED: draft-durand-v6ops-assisted-tunneling-requirements-00.txt

-- Christian Huitema

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 5 May 2004 10:59:26 +0300 (EEST)

> That's true if both hosts try to use the same Tunnel server.

Obviously, as we want to implement a discovery protocol, these would 
almost always be the same.

> But I also believe that when there are several host behind a NAT, or
> in the same LAN, is more interesting to use proto-41 or any other
> mechanism to provide a single prefix to all the LAN. It provides a
> lot of advantages.

Obviously, but may be non-trivial to set up, and might not be 
supported at all by the non-registered mode (if it only provided a 
/128, which would remain to be seen).

> It should not be very difficult, as part of the implementation of
> the tunneling protocol (TSP or whatever), detect this situation
> automatically and even configure one of the host as "router" for the
> rest of the network.

Actually, I would argue that this _would_ be very challenging.  Note
that the NAT may be done by the operator as well, not just the user.  
It would be simpler to try to figure out whether there are other v6
nodes behind the same NAT, but that's deep magic and failure-prone as
well.

Proto-41 forwarding seems work within certain specific scenarios
(i.e., the only NAT is done by the customer's CPE, a host would be
willing to serve as an IPv6 router, and that a prefix delegation is
available), but it doesn't seem to be possible to generalize its
detection and use for the protocol.

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 05 May 2004 10:07:39 +0200

> even that might be far-fetched.

I suggest that a TB (or any other method for that matter) should support
both proto-41 and udp as an encaps method.

Technically speaking it shouldn't be much of a difference, either the
IPv6 packets come inside proto-41 or inside udp packets.

What actually where the reasons for not using UDP at the time and going
for a seperate protocol that became proto-41?

The same goes for TCP btw, but TCP has inherent latency issues as I have
tested out with tinc (http://tinc.nl.linux.org) but one is able to setup
something like: IPv6 over tinc in TCP over http(s)tunnel and thus repeat
after me "which firewall?" ;) Using UDP is much smoother and doesn't
seem to differ from proto-41 usage and the main advantage is that it
does cross a NAT. As long as source/dest port pairs differ it should not
be a problem to have multiple hosts behind a single NAT and one TB on
the outside either. This is a setup which we are testing in .it btw...

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 05 May 2004 10:16:10 +0200

> almost always be the same.

Unless the protocol does load balancing, but we must assume that there
could be multiple hosts behind the same NAT and talking to the same
server, may that be a TB, teredo, dstm.. whatever.

> /128, which would remain to be seen).

Next to that there are ISPs who NAT their complete userbase, say 100k
hosts behind a single IPv4 address. It is simply not possible to put up
an RA behind it, well it would work but for that single part of the LAN.

> nodes behind the same NAT, but that's deep magic and failure-prone as

Also that would make one host suddenly be a 'transit' for the other
hosts, automatically. I don't think many users will like this setup.
Paying for others, especially with bandwidth/traffic limitations is not
something most people like to do.

> detection and use for the protocol.

I even would stretch it as far as saying:
directly connected: proto-41
NAT: udp

Just to keep it simple. Anyone written a IPv6-over-UDP draft yet btw?

Greets,
 Jeroen

---

From: Tim Chown <[email-masked]>
Date: Wed, 5 May 2004 11:47:05 +0100

Hi,

This is valuable WG work.

Alain, you may wish to check this recently expired draft for other issues
or requirements (the URL is temporary):
http://www.ecs.soton.ac.uk/~tjc/draft-chown-v6ops-unmanaged-connectivity-00.txt

The index of requirements covered in the draft is:
 Desirable Properties of Tunneling Solutions
 Security
 Simplicity
 Ease of Management
 Handling Dynamic IPv4 Addresses
 Support for Hosts or Sites
 Scalability 
 NAT Traversal 
 Can be Used Behind a NAT
 Tunnel Service Ownership
 Tunnel Service Discovery
 Support for Special Services
 Route Optimisation
 Reverse DNS Lookups Available
 Accountability

I may update it soon, but your work, and work by Pekka, probably supercedes
it.   Just worth checking we pick up all the points people contributed to
the above draft.

There may be other things specific to your draft, for example handling of
dynamic IPv4 addresses, and how the tunneling overcomes/handles that
situation (both for the current user, and any user picking up the IPv4
address previously assigned to someone else running a tunnel), also 
ensuring that the v6 prefix assigned remains static when the client comes
back in via a new v4 address to avoid v6 renumbering (this may be easier
in registered mode than non-registered).

I'll have a detailed look when the WG version of the draft is out :)

Tim