Re: IPv6 tunnel over NAT

[Rob Austein <sra+v6ops@hactrn.net>]

At Fri, 27 Sep 2002 10:26:32 -0700 (PDT), Jason Goldschmidt wrote:
> 
> 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.

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