Subject: RE: (ngtrans) Re: I-D ACTION:draft-huitema-natreq4ipv6-00.txt

From: "Christian Huitema" <[email-masked]>
Date: Tue, 20 Feb 2001 17:27:52 -0800

I am not sure that we actually need a specific draft for solving the UDP
tunneling problem. I initially thought that since many NAT only accept
UDP, we would need to write something like "6to4 over UDP", basically
copying the 6to4 design; the 6to4u prefixes would have a /16 prefix in
the aggregatable class, then 32 bits of IP address, then 16 bits of port
number, providing you with a /64 prefix that could cross a NAT. The
problem with that is, it will only work with about 50% of the NAT that
are deployed today. The other 50% insist on checking the source address
of the UDP packets that they receive; they will only pass the packet if
the internal host already sent a packet to that address. On the other
hand, the "good" NATs that would accept UDP packets frommultiple source
are also the ones hat can easily be convinced to let protocol type 41
pass through. So, a generic 6to4u solution would not be terribly useful.

What would be useful is something else, a configured tunnel that runs
over UDP. That will work with 100% of NAT, if the two ends of the
tunnels sustain some amount of traffic such as at least one packet every
minute, so that the UDP mapping does not time-out. But the requirements
for configured tunnels entail more than merely sticking an IPv6 packet
in an UDP payload. The "IPv6 backbone" end of the tunnel is essentially
acting as an IPv6 ISP, which means that it should have a way to decide
to whom it offers the service, check that the accounts are current,
maybe provide a fixed IPv6 prefix to the user. It turns out that we have
a solution that comes pretty close to the requirement, the VPN protocol
L2TP. The stack will be:

 +----------------+
 | app, transport |
 +----------------+---------+--------+
 | IPv6 encaps    | IPv6 CP | PPP CP |
 +----------------+---------+--------+
 | PPP                               |
 +-----------------------------------+
 | L2TP "shim" layer                 |
 +-----------------------------------+
 | UDP                               |
 +-----------------------------------+
 | IPv4                              |
 +-----------------------------------+

Because the stack includes PPP, we get the natural plugs into the AAA
functions that are needed in an ISP environment, e.g. Radius. We also
get various forms of compression, including header compression. And, we
don't have to create a specific protocol, just reuse a solution that is
already defined.

Indeed, the expert will have observed that the traditional
implementation of L2TP includes an IPSEC layer between UDP and IPv4.
This is a known issue, since the use of IPSEC in that mode precludes
L2TP from working behind a NAT; it has to be fixed for tunneling IPv4 as
well as IPv6.

-- Christian Huitema

---

From: Keith Moore <[email-masked]>
Date: Tue, 20 Feb 2001 21:21:46 -0500

I've been thinking of "6overNAT" merely as a solution for use within
an enterprise network - so it covers roughly the same space as 6over4
except that it works even if there are NATs internal to the underlying
v4 network.  the idea is to lower the cost of upgrading your local
infrastructure to IPv6 by leveraging the existing IPv4 network (even
if it's NATted) rather than requiring that all of your routers, etc. 
be upgraded to IPv6.  as I've been thinking about it, external v6 
connectivity for that network would be provided by 6to4 or configured 
tunnel or native v6, whichever is available, rather than IPv6 over UDP.

the draft I'm working on discusses various possible locations for 
the box that does the UDP encapsulation/decapsulation relative to
the NATs.  if that box is behind a NAT, it does assume that
the NAT can be configured to provide that box with a stable 
IPv4 address and also that the NAT can be told to route incoming 
type 41 packets to the box - which pretty much assumes that the NAT
is under your control rather than (say) being run by some ISP.
but the box can also be located external to the NAT, or in parallel
with the NAT (if you can give it its own IP address), or co-located
with the NAT.

I agree that some sort of configured tunnel over UDP could also be useful
for external links going over a NAT (where the NAT isn't under your
control), and that the external end of the tunnel would want to require 
some sort of authentication if this were to be used on a large scale.

Keith

---

From: Steve Deering <[email-masked]>
Date: Tue, 20 Feb 2001 18:45:51 -0800

At 5:27 PM -0800 2/20/01, Christian Huitema wrote:
>The stack will be:

Gag.

You know, not every feature requires its own layer.

Steve

---

From: [email-masked]
Date: Wed, 21 Feb 2001 11:53:23 +0900

>tunnel or native v6, whichever is available, rather than IPv6 over UDP.

	I guess you are talking about the same issue as christian, it just
	depend on how the target network is configured, that's all.

	btw, there are other ways to circumvent IPv4-only-router-in-site
	problem - for example, many of IPv4 routers have functionality to
	bridge ethernet packet with certain ethernet protocol type (basically
	for bridging appletalk, i guess).  if you bridge 0x86dd you can go
	across the IPv4 router.
	or, if your company uses centralized VLAN switch (it looks common these
	days), you can put a single IPv6 router with VLAN support into the
	trunk port and reach all the segments.
	i'm not saying that ipv6-over-udp is not necessary, but there are
	lots of tricks we can play without protocol changes/new protocols.
	i'm writing up a set of tutorial slides for but have no idea where
	to present.

itojun

---

From: Keith Moore <[email-masked]>
Date: Tue, 20 Feb 2001 22:16:56 -0500

it's similar.  if your border NAT is under your control and immediately 
outside of that NAT is public v4 Internet then you can probably 
get IPv6 packets into your network in several different ways.  if the NAT
is not under your control then you need some sort of external box
to serve as a tunnel endpoint.  one difference may be that in 
Christian's proposal (as it seems to me) that box serves as one endpoint of 
a per-site 6overUDP tunnel, whereas in my proposal the box (assumed to be 
located near the periphery of the enterprise network) potentially had a 
separate tunnel for each IPv6 host.  you could use more-or-less the same
tunneling mechanism for both cases, but the security needs are probably 
different.

true.  the hope I have for the UDP trick is that it can be made to work
more-or-less off-the-shelf with most existing enterprise v4 networks -
the assumption is that more networks can do this with UDP than with VLANs
or ethernet bridging.

Keith

---

From: [email-masked]
Date: Wed, 21 Feb 2001 13:06:09 +0900

>the assumption is that more networks can do this with UDP than with VLANs

	how normal it is to have NAT inside a company network, like the story
	you've told us?  i guess it more common to have single NAT box at the
	edge (entrypoint) of a company network, otherwise we will have
	multi-level NATs.  I really hope that multi-level NAT is uncommon...  

	if we don't have NAT between tunnel endpoints, normal RFC1933/2893
	tunnel should work fine (we don't need UDP encapsulation unless
	there's some strict filter).

itojun

---

From: Keith Moore <[email-masked]>
Date: Wed, 21 Feb 2001 01:02:05 -0500

>         multi-level NATs.  I really hope that multi-level NAT is uncommon...

I think you're right that the single NAT box is the most common case,
but my understanding is that multiple NATs are used in some large 
corporate networks.  NATs are also used for private links between 
private networks, and it might be worthwhile to consider this case.

at any rate, it doesn't seem much more difficult to implement a 
tunnel across multiple NATs than to implement one across a single NAT -
the chief difference is that having multiple layers of NATs makes it
more difficult for a router to return NA messages allowing 6overNAT hosts 
to tunnel messages directly to other 6overNAT hosts in the same  
IPv4 addressing realm, since if there are multiple NATs it's hard
for the router to know whether those hosts are in the same addressing 
realm.  

>         there's some strict filter).

mostly agree.    though the 6overNAT tunnel is sort of a half-configured
tunnel - instead of each end knowing the address of the other endpoint,
the host running 6overNAT knows the IPv4 address of the router, but the
router has to be periodically reminded as to the IPv4 address of the host.  
this is needed because NATs can discard or lose address bindings, but it
might also be useful in an ordinary IPv4 network which had short lease
times for IPv4 addresses, to provide stable IPv6 addresses for its hosts.  

Keith

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 21 Feb 2001 09:51:29 +0000

> You know, not every feature requires its own layer.

When you build complex stacks like this, you might give some
thought to how fast you ever want to go. The more bytes you
have to look at, the longer the header (not the same thing), 
and the more "ambigous" the decision, the slower the router.

Stewart