Subject: IPv6 tunnel over NAT

From: [email-masked]
Date: Fri, 27 Sep 2002 13:49:20 +0900

there's a widely-practiced alternative to Teredo, and which does not
	need any special behavior from NAT wrt UDP translation behavior.

	IPv6 over PPP over TCP/SSH.  it needs no documentation.

itojun

---

From: Pekka Savola <[email-masked]>
Date: Fri, 27 Sep 2002 08:44:36 +0300 (EEST)

> 	IPv6 over PPP over TCP/SSH.  it needs no documentation.

No TCP over TCP, please... :-(

-- 
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: Rob Austein <[email-masked]>
Date: Fri, 27 Sep 2002 12:57:41 -0400

> No TCP over TCP, please... :-(

In the general case, I would agree, but this is not the general case.
The question is whether IPv6/PPP/xyz/TCP is good enough for the
particular case of hosts stuck behind a NAT that they cannot remove or
upgrade.  I think that the answer in this case may well be "yes".

Please note that using PPP tunneling would also give us a handle on
some of the nasty relay issues involved with Terado, since they would
convert the exciting problem of what to do with tunneled packets from
strangers into a boring matter of setting up accounts for each PPP
identity, something that most ISPs already know how to do.

To be fair, Terado isn't the only transition scheme that has relay
problems, it's just the only one that has both has relay and NAT
traversal problems.  It's NAT traversal that makes PPP/TCP look good.

For other relay problems (eg, 6to4) it might make sense to look into
some kind of tunnel control using IPsec.  Unless I misremember the
spec, tunnel mode IPsec does allow the inner and outer versions of IP
to be different, so one could have (eg) IPv6/ESP/IPv4 and the only
additional cost over the normal 6to4 encapsulation would be the ESP
header itself.  Account setup for IPsec isn't as well understood as
for PPP, but perhaps we can use what works for PPP as a model.

---

From: Jason Goldschmidt <[email-masked]>
Date: Fri, 27 Sep 2002 10:26:32 -0700 (PDT)

On Fri, 27 Sep 2002, Rob Austein wrote:

Hi Rob,

> for PPP, but perhaps we can use what works for PPP as a model.

There is a problem with what you describe WRT 6to4.  When a 6to4 router is
sending a packet to a "native" IPv6 host it can "discover" a 6to4
relay router using the well known anycast address (RFC 3068) or might send
the packet to a particular relay router (using unicast).  Though it is not
guaranteed that a response from the native IPv6 host will arrive at the
6to4 router by way of the same relay router.  Routing on the native
IPv6 internet will determine which relay router will be used to reply
to 6to4 router in question.  This makes it very difficult to create a
security association with all 6to4 relay routers.  Today there are only a
few 6to4 relay routers deployed (AFAIK), but there is certainly no limit
as to how many will be deployed in the future.  The non-deterministic
nature of what relay routers a 6to4 router may receive traffic from is the
very nature of 6to4's security issues.

-Jason

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Sep 2002 14:11:18 -0400

> upgrade.  I think that the answer in this case may well be "yes".

well, obviously it depends on the applications being run and the
quality of the underlying links.  if you're running real time apps
over UDP over PPP over TCP over a lossy IP link, you'd probably
be much happier using Teredo.  do we really want to say, for instance,
that it's okay for the generic solution to break streaming audio?

Keith

---

From: Rob Austein <[email-masked]>
Date: Fri, 27 Sep 2002 14:22:16 -0400

> very nature of 6to4's security issues.

Yeah, well, I never really bought the RFC 3068 anycast relay router
model anyway, it's kludging around an IPv6 routing issue by turning it
into an IPv4 routing issue :).

I think it makes sense to break down this problem into two separate
problems: traffic coming into the relay routers from the v4 side, and
traffic coming into the relay routers from the v6 side.

The key thing to note here is that most of the tunneling problems are
for the entity that's decapsulating, not the entity that's
encapsulating.  I suppose there might be lurking issues for the
encapsulator as well, but presumably the encapsulator has a reason for
deciding to send traffic into the tunnel.  It's the decapsulator that
has to be worry about what this stuff is and whether it should be
forwarding it or dropping it on the floor.

So, getting back to the two cases: when traffic is coming into the
relay routers from the v4 side, the relay router is the decapsulator
and has a serious problem deciding what to do unless it has some kind
of relationship with the encapsulator.  That's what I'm suggesting we
might be able to solve using IPsec.

When traffic is coming into the relay routers from the v6 side, the
relay router is the encapsulator, and has nothing to worry about
(assuming that proper ingress filtering was done elsewhere in the v6
net, etcetera, but that's an understood problem, nothing new there).
In this case it's the receiving 6to4 site router that's the
decapsulator and has the worries, but, as I've mentioned in other
postings, I think the problems for the 6to4 site router are much less
severe because such a router can make reasonably sane decisions based
on physical network topology (eg: "if it came in via an external
interface, it does not go out again on an external interface,
period").

---

From: Rob Austein <[email-masked]>
Date: Fri, 27 Sep 2002 15:05:53 -0400

> that it's okay for the generic solution to break streaming audio?

a) Begs the question of whether any of our transition tools are robust
   enough to support serious real-time streaming use.

b) PPP/TCP looks like a reliable link with very erratic timing
   characteristics.  I'm fairly certain that unidirectional streaming
   protocols can deal with that via buffering (so that it's not real
   time anymore).  Whether the deployed implementations can or not is
   another matter.

   Bi-directional real time may be hard enough that (a) applies.

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Sep 2002 15:02:45 -0400

> into an IPv4 routing issue :).

granted that it doesn't change the issue to move it from v6 to v4,
but what is the real problem you're concerned about?

---

From: Rob Austein <[email-masked]>
Date: Fri, 27 Sep 2002 15:17:15 -0400

> but what is the real problem you're concerned about?  

Many of the open packet relay problems (potential as DDoS reflectors,
potential for circumvention of ingress controls, etc -- and note that
this applies to all flavors of open packet relays, not just 6to4
relays) stem from treating the entire IPv4 internet as one giant link
layer network, making it impossible to apply the usual tools that we
use in the IPv4 universe (ingress control, fault isolation, etc) in
any useful way.

Now set the wayback machine to the days when we were still debating
the relative merits of giant bridged networks versus routers in IPv4.
Ring any bells?

In other words, we have divide-and-conquer techniques for dealing with
the problems that arise from excessively large link layer networks.
We're not using them at the moment because they'd require us to divide
the relevant portions of the IPv6 address space up into smaller
subnetworks and deploy routers, which would be unpleasant, but might
not be as unpleasant as living with various instantiations of the open
packet relay problem for the next decade.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 27 Sep 2002 23:02:16 +0300 (EEST)

> identity, something that most ISPs already know how to do.
[...]

I do not believe, as of late, that Teredo will be the right solution.

Instead, I think we just need a generic bidirectional tunnel through the 
NAT; in addition to using some UDP port there should be some keepalives 
and such of course.  Plain and simple, always works, no problems at all.

Except it must be manually configured.  Can't be helped, really, but 
Teredo was always a cornercase anyway.

---

From: Alain Durand <[email-masked]>
Date: Fri, 27 Sep 2002 13:13:14 -0700

>interface, it does not go out again on an external interface,

No. The 6to4 router has a  serious problem in that space.

IPv6 routing using 6to4 relays is asymetric, a 6to4 router may
choose which relay it send its traffic to for native v6, but has
absolutly no control where the packets will come back from.

So the decapsulating 6to4 router has no way  to know if incoming
packets are coming from a real relay or if it is spoofed trafic.

    - Alain.

---

From: Rob Austein <[email-masked]>
Date: Fri, 27 Sep 2002 16:50:10 -0400

> absolutly no control where the packets will come back from.

Correct.

> packets are coming from a real relay or if it is spoofed trafic.

Correct.  So what?

If you're suggesting that if I knew who the "real relay" was I could
trust it, I can only assume that you live in a much friendlier world
than I do.  If it comes from the outside world it's dangerous until
proven otherwise.  This isn't an IPv6-specific issue.

---

From: Rob Austein <[email-masked]>
Date: Fri, 27 Sep 2002 19:35:17 -0400

At Fri, 27 Sep 2002 23:02:16 +0300 (EEST), Pekka Savola wrote:
> 
> I think we just need a generic bidirectional tunnel through the NAT;
> in addition to using some UDP port there should be some keepalives

In general, I think this is a reasonable approach (assuming that the
scenario work supports it, but I expect that it will).

No doubt there will be cases in which it will not work (particularly
restrictive NAT boxes or firewalls), but perhaps we can build
consensus around the idea that in such cases PPP/TCP is ok?

> Except it must be manually configured.

Including some kind of authorization model, yeah.

---

From: Alain Durand <[email-masked]>
Date: Fri, 27 Sep 2002 17:06:04 -0700

> proven otherwise.  This isn't an IPv6-specific issue.

I think we are in violent agreement here.
This may not be a v6-specific issue, but this is a
v6-operational/transition issue.
Another way to say this, if open relay is the show stopper for teredo,
it becomes automatically a 'serious embarrassment' for 6to4.

	- Alain.

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Sep 2002 20:16:49 -0400

>    enough to support serious real-time streaming use.

6to4 has a fixed overhead/delay per packet.  Teredo and NATs probably do also.
 
>    time anymore).  Whether the deployed implementations can or not is

PPP/TCP considerably amplifies the amount of jitter in the underlying
network.  In general, apps that are jitter sensitive will do worse
with PPP/TCP (assuming any significant jitter or packet loss in the
underlying network) than any per-packet tunneling or translation mechanism.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Sep 2002 20:18:08 -0400

> packet relay problem for the next decade.

to what extent could BGP policy be used to accomplish divide-and-conquer
for 6to4 relay routers?

---

From: Rob Austein <[email-masked]>
Date: Fri, 27 Sep 2002 21:46:43 -0400

> to what extent could BGP policy be used to accomplish divide-and-conquer

I'm pretty sure that it wouldn't solve the problem (I suspect you need
actual routers to do that, not just routing policy), and from
everything I hear BGP is already badly overloaded without taking on
new duties, but I confess that the idea of trying to do this with BGP
hadn't occurred to me, so I can't claim to have thought about it much.

---

From: Rob Austein <[email-masked]>
Date: Sat, 28 Sep 2002 00:57:19 -0400

> I think we are in violent agreement here.

Not sure.

The point I was trying to make was that, while the defenses that a
edge router has to deploy are annoying, they are a straightforward
extrapolation of what we already do for IPv4, and are based in large
part on topological information that happens to be one of the very few
things that the 6to4 edge router -can- trust.  In the common simple
case, the router's interfaces partition into two disjoint sets: "my
site" and "the rest of the world".  Unless the router is badly
configured or otherwise crippled, it knows which interfaces are are in
which set, and can apply packet filtering rules as necessary when
decapsulating to keep itself from being used as a DDoS reflector or as
a circumvention tool to get around ingress filtering.  The packet
filtering rules are seriously ugly, but at the conceptual level this
is a small matter of programming.

The relay router, on the other hand, does not have any useful
topological information on which to make such decisions (to a first
approximation, everything a relay router sees is from "the rest of the
world").  So it needs to have kind of additional mechanism for
figuring out who's allowed to use it as a decapsulator.

---

From: Randy Bush <[email-masked]>
Date: Sat, 28 Sep 2002 05:12:24 -0700

> figuring out who's allowed to use it as a decapsulator.

bingo!

and relays out in the net would have serious problems of scaling in
security associations, where site gateways have little if any.

randy

---

From: Brian Haberman <[email-masked]>
Date: Sat, 28 Sep 2002 10:39:59 -0400

> hadn't occurred to me, so I can't claim to have thought about it much.

I work with a group of BGP developers who are very concerned with
the amount of work that has been piled on BGP.  I doubt that we
should rely on BGP to enforce a whole bunch of new policy for 6to4.

Brian

---

From: "Jim Fleming" <[email-masked]>
Date: Sun, 29 Sep 2002 05:13:27 -0500

----- Original Message ----- 
From: "Rob Austein" <[email-masked]>
To: <[email-masked]>
Sent: Friday, September 27, 2002 8:46 PM
Subject: Re: IPv6 tunnel over NAT 

> hadn't occurred to me, so I can't claim to have thought about it much.

Note, BGP goes away once the 32-bit "core" transport is secured.
Announcements become a thing of the past.

Whitehouse Ready to Release Next Generation Internet Plan
http://news.com.com/2100-1023-958159.html?tag=politech
http://www.politechbot.com/p-03994.html
http://www.uscryptomail.org/cybersecurity/

Note: The new plan calls for the same architecture used with IPv8 and IPv16,
whereby, users do not have direct access to the (out-of-band) IPv16 network.

Jim Fleming
2002:[IPv4]:000X:03DB:...IPv8 is closer than you think...IPv16 is even closer...
http://ipv8.dyndns.tv
http://ipv8.yi.org
http://ipv8.dyns.cx
http://ipv8.no-ip.com
http://ipv8.no-ip.org
http://ipv8.no-ip.biz
http://ipv8.no-ip.info
http://ipv8.myip.us
http://ipv8.dyn.ee
http://ipv8.community.net.au
http://ipv8.ods.org

---

From: "Jim Fleming" <[email-masked]>
Date: Sun, 29 Sep 2002 07:14:19 -0500

----- Original Message ----- 
From: "Jim Fleming" <[email-masked]>
> Announcements become a thing of the past.

Correction....the "43-bit *core* transport"....
although, one could argue the SNOOPY bit is a 1/2 bit but people seem confused with 43.5 bits...

128-bit DNS AAAA Record Flag Day Formats
2002:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
[YMDD]:[IPv4]:[SDLL.OFFF.FFFF.TTTT]:[64-bit IPv8 or IPv16 Persistent Address]
1-bit to set the Reserved/Spare ("SNOOPY") bit in Fragment Offset [S]
1-bit to set the Don't Fragment (DF) bit [D]
2-bits to select 1 of 4 common TTL values (255, 128, 32, 8) [LL]
1-bit for Options Control [O]
7-bits to set the Identification Field(dst) [FFFFFFF]
4-bits to set the TOS(dst) Field [TTTT]
Default SDLL.OFFF.FFFF.TTTT = 0000.0000.0000.0000
FFF.FFFF.TTTT = GGG.SSSS.SSSS
http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt

Jim Fleming
3:219...IN-ADDR.INFO