Subject: RE: IPv6 over UDP/IPv4

From: "Christian Huitema" <[email-masked]>
Date: Fri, 15 Jun 2001 09:12:32 -0700

The UDP tunneling scenario aims at solving the NAT crossing problem.
This is fine, but we need more than just a pot number and a payload
format to make this work. Since the origin of the tunnel is located
behind a NAT, and possibly many, you cannot predict the port number and
the IP address that it will use. Also, it is fair to assume that the
tunnel will probably not be offered by the local ISP -- if this ISP
wished to provide IPv6 service, it could just enable native IPv6, or
possibly native tunneling. I think we must meet the following
requirements:

1) There is no way to "pre-configure" the connection. The association
between a given "user prefix" and a pair of natted address and port must
be discovered in real-time.

2) There must be a way to verify the identity of the party requesting
the tunnel, to mitigate the risk of traffic highjacking, and possibly to
ensure that only authorized parties are using the service.

3) There must be some way to verify the origin of the traffic, in order
to avoid denial of service attacks.

4) There must be a way to "qualify" the tunnel, and check that traffic
is indeed flowing in both directions -- NAT configurations are prone to
bizarre cases of failure.

We should also note that IPv6 over UDP should be designed to work with
all NATs, including those that use "destination specific" port mappings.
The design, and the port discovery, should be focused on bilateral
tunnels. 

-- Christian Huitema

> -----Original Message-----
> From: Francis Dupont [mailto:[email-masked]]
> Sent: Friday, June 15, 2001 7:44 AM
> To: [email-masked]
> Subject: IPv6 over UDP/IPv4
> 
> We know that IPv6 over UDP/IPv4 is very useful for some users.
> This is very easy to do too (see the PS) but an advantage to
> have a document which specifies it is we can get a standard port...
> Do you believe we should write an Internet Draft about it?
> 
> [email-masked]
> 
> PS: on FreeBSD 4.3 with Netgraph a little variation of
> the /usr/share/examples/netgraph/udp.tunnel script does the job.
> With if_tun (for systems without a netgraph-like facility) this takes
> one page of trivial code... or nothing if the user mode PPP has both
> UDP and IPv6 supports.
> --------------------------------------------------------------------
> IETF IPng Working Group Mailing List
> IPng Home Page:                      http://playground.sun.com/ipng
> FTP archive:                      ftp://playground.sun.com/pub/ipng
> Direct all administrative requests to [email-masked]
> --------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Robert Elz <[email-masked]>
Date: Sat, 16 Jun 2001 00:28:38 +0700

Date:        Fri, 15 Jun 2001 09:12:32 -0700
    From:        "Christian Huitema" <[email-masked]>
    Message-ID:  <[email-masked]>

  | I think we must meet the following requirements:

If all that is to be done, then it would probably be easier to
just use TCP.  That doesn't, of itself, satisfy all the requirements,
but it makes it a lot easier to handle them (eg: it pretty much handles
the two way data problem, and it allows some kind of authentication that
doesn't have to be repeated for every packet).

kre

---

From: Francis Dupont <[email-masked]>
Date: Fri, 15 Jun 2001 19:36:19 +0200

In your previous mail you wrote:

=> I'd like to say IPv6 over UDP is useful in other cases but I am afraid
that you are right: this is useful when there is a NAT or a firewall or
both.

   This is fine, but we need more than just a port number and a payload
   format to make this work.

=> this covers some cases so this is perhaps not enough but still useful
(port number: to be allocated by IANA, payload format: one IPv6 packet ==
one UDP packet).

   Since the origin of the tunnel is located
   behind a NAT, and possibly many, you cannot predict the port number and
   the IP address that it will use. Also, it is fair to assume that the
   tunnel will probably not be offered by the local ISP -- if this ISP
   wished to provide IPv6 service, it could just enable native IPv6, or
   possibly native tunneling.

=> there are two common cases where we aren't hurt by this issue:
 - there is only one NAT and it is locally managed
 - the ISP filters out "unknown" protocols (including 41)

   I think we must meet the following requirements:

=> a known port is still useful if NATs don't nat both source
and destination.

   
=> 2 and 3 have the same solution: some kind of IPsec... An option should
be something like [IPv4][UDP][ESP][IPv6]. I believe there are such things
in the IPsec mailing list for NAT tranversal.

=> ah! IPv6 has already the right tool: NUD!

=> I can't see the exact implication of this.

Thanks

PS (1): the idea is to send a magic packet to the destination
at the known port. If only the source is natted then the peer
address and port will be available in the encapsulated stuff.
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Sun, 17 Jun 2001 22:38:58 +0300 (EEST)

> doesn't have to be repeated for every packet).

Tunneling TCP over TCP can get you into "interesting" situations if the
packet loss is significant due to timers etc. activating on both layers.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Jun 2001 14:38:32 +0200 (CEST)

> address and port will be available in the encapsulated stuff.

I've observed that, even if there is traffic every few seconds,
the NAT box I have will change the UDP source port occasionally
for UDP traffic.

Thus it isn't sufficient to send the magic packet once.

  Erik

PS. The above is based on operational experience for IPv4 over UDP/IPv4
to enable IPsec tunnels on top of that.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 18 Jun 2001 15:22:43 +0200

=> argh! This mandates a IPv6 over TCP/IPv4 too because the NAT cannot
do this for a TCP connection...

=> and can IPsec work with such a (broken) NAT?

PS: something like the BSD user-PPP is more and more attractive!

---

From: Erik Nordmark <[email-masked]>
Date: Mon, 18 Jun 2001 15:38:12 +0200 (CEST)

> => and can IPsec work with such a (broken) NAT?

IPsec doesn't run directly over it. There are two layers of
tunneling:
1. Create fixed public IP address for the machine behind the NAT box
   by tunneling IPv4 over UDP/IPv4.
2. Just run regular IPsec tunnel mode on top of the above.

Apart from the tunnel overhead (IPv4 UDP IPv4 IPv4 ESP IPv4 ...)
it appears to be working fine.
But I've only used this heavily for a few weeks so I don't yet understand
how often there has to be packets from behind the NAT to make sure
that tunnel #1 gets the updated UDP port numbers.

   Erik