Subject: (IPng 7096) RE: I-D ACTION:draft-ietf-ipngwg-6over4-02.txt

From: Richard Draves <[email-masked]>
Date: Tue, 26 Jan 1999 21:22:07 -0800

There's an interesting (to me at least) issue that arises when a node
supports both 6over4 and configured tunnels.

The problem is demultiplexing received encapsulated packets (v6 packet
encapsulated in a v4 packet) to the proper interface in the v6
implementation. This is 95% an implementation issue, but I suspect it's
common to many implementations and there's also an operational element
involved. So I hope this note proves at least mildly interesting to some.

A node that supports 6over4 will have a logical or virtual interface for the
6over4 link. (To simplify the discussion, let's just consider nodes with a
single physical interface, eg, ethernet.) The virtual 6over4 interface will
behave in the implementation exactly like a real physical interface.

A node that expects to receive packets sent to it via configured tunnels
will probably have an interface, call it the tunnel interface. The
encapsulated packets will be "received by" the tunnel interface. The tunnel
interface might be just an implementation convenience but it can have
addresses assigned to it.

Why does it matter what interface "receives" a packet? For example, it makes
a difference if the receiving node needs to generate an ICMP error in
response. The ICMP error will take a source address from the receiving
interface. It makes a difference for IPsec - there's an inbound policy check
in the Security Policy Database, which is per-interface. There may be other
implementation-specific reasons why it's important to figure out which
interface is receiving a packet.

Now when this node receives an encapsulated packet, should the 6over4
interface or the tunnel interface be considered the receiving interface?

The information available to make this decision is the v4 source &
destination and the v6 source and destination. The v6 source and destination
are no help, in general. For example the v6 destination might not be
assigned to any of the node's interfaces if the node is a router, and
similarly the v6 source might be anything if the sending node is a v6
router. The v4 destination is no help, in general. If it's a 6over4
link-layer multicast address, then the packet can be assigned to the 6over4
interface. But in general the v4 destination will just be the node's v4
unicast address.

This leaves us with the v4 source address. Recall that configured tunnels
are nominally unidirectional - if A has a configured tunnel to B then A
knows B's v4 address but not vice-versa. The configured tunnel requires
configuration of A but not of B. Suppose that configured tunnels were
"biconfigured", so A & B both know each other's v4 address. Now B has a way
of demultiplexing encapsulated packets - if they're from A, assign them to
the tunnel interface, otherwise assign them to the 6over4 interface.

So my conclusion is that one solution to making 6over4 and configured
tunnels work together in an implementation, is to have configured tunnels be
"biconfigured" so recipients know about sources.

Another possibility is to have a single interface receiving all encapsulated
traffic. But then this single interface will also be sending both 6over4 and
configured tunnel traffic. This might be awkward for the implementation
because the 6over4 traffic uses Neighbor Discovery and the configured tunnel
traffic does not. It also means that the implementation can't have separate
IPsec SPDs for 6over4 and configured tunnel traffic.

From this IPsec/administrative point of view, it might be useful to have
multiple tunnel interfaces, one for each configured tunnel over which the
implementation is sending or receiving. And use the v4 source/destination
addresses to demultiplex received traffic to the appropriate tunnel
interface. This would support configured tunnels as a bidirectional
construct, instead of purely a unidirectional construct.

Anyway, I'm curious what other implementations do.

Thanks,
Rich
--------------------------------------------------------------------
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: Cyndi Jung <[email-masked]>
Date: Tue, 26 Jan 1999 22:49:27 -0800

At 09:22 PM 1/26/99 -0800, you wrote:
> [much good stuff deleted]

You wouldn't want to put these into the same tunnel interface.  The 6over4 
is a fairly "local area" IPv6 subnet, spanning several IPv4 subnets that 
are all within the same administrative scope for IPv4 multicast.  The
configured tunnels would be with IPv6 routers in other domains, beyond
the scope of the Neighbor Discovery protocol.  These could conceivably
use the same source IPv4 address locally - the destination IPv4 address
would be the distinguishing piece of information. 

>construct, instead of purely a unidirectional construct.

I would expect that in usage, the configured tunnels end up being
bidirectional, even if the routing isn't symmetric.

>Anyway, I'm curious what other implementations do.

So am I,

Cyndi

---

From: Peter Grehan <[email-masked]>
Date: Tue, 26 Jan 1999 22:07:18 -0800

>Anyway, I'm curious what other implementations do.

 This problem also applies to ipv4 DVMRP tunnels, and in that case,
our implementation uses a configured v4 src/dst and is assumed
bi-directional for the reasons you mentioned. Also, routing
protocols assume that links are symmetrical, so if you want to
run routing over a tunnel, it is required to be bidirectional.

 Another compelling reason is that at some stage, the tunnels usually
go through a firewall, and f/w admins don't like to configure 
wildcard sources in their rulebases.

later,

Peter.

---

From: Steve Deering <[email-masked]>
Date: Wed, 27 Jan 1999 10:19:12 -0800

At 9:22 PM -0800 1/26/99, Richard Draves wrote:
> "biconfigured", so A & B both know each other's v4 address.

Rich,

Whether or not both ends of a tunnel are configured to know about the
other end is orthogonal to whether or not the tunnel is unidirectional.
In other words, you might well configure the receive end of unidirectional
tunnel to know the address of the sending end.  For a tunneled packets
that arrives on an "unknown" tunnel (i.e., from an encapsulating source
address that has not been configured), it should probably be a local
configuration choice whether to drop such a packet or to instantiate
a new virtual interface for the newly-discovered tunnel.

(The local configuration variable might be called something like
"tunnel-promiscuous".  It's not immediately clear to me what the
default value of that variable should be.  Perhaps promiscuous for
routers and non-promiscuous for hosts?)

I think it is architecturally cleanest if the endpoint of each tunnel
is treated as a separate virtual interface, rather than having a
single virtual interface for all tunnels originating or terminating
at a node.  You listed some of the problems with the later approach.

Different tunnels can be distinguished from each other by the type of
the encapsulating header (e.g., IPv4 vs. IPv6) and by the addresses
in that encpasulating header:

	- point-to-point tunnels are identified by the encapsulating
	  source and destination unicast addresses.

	- multi-access tunnels are identified by the encapsulating
	  destination multicast address alone.

A separate attribute of a tunnel virtual interface is whether it is
unidirectional-incoming, unidirectional-outgoing, or bidirectional
(anologous to unidirectional and bidirectional physical interfaces).
That attribute is set at tunnel configuration time.  (Inconsistent
configuration of different ends of the same tunnel is analogous to
having a broken physical interface.)  For dynamically-established
tunnel interfaces (through promiscuous tunnel acceptance), the
attribute is set to unidirectional-incoming.

How does that sound?

Steve

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 27 Jan 1999 14:23:50 -0800 (PST)

I don't think this issue needs to be discussed in the draft. It is
all implementation issues.

> interface or the tunnel interface be considered the receiving interface?

Even though we haven't built 6over4 we have a similar issue with
configured and automatic tunnels.

Basically we assume that the configured tunnels, while not necessarily 
bidirectional, have a counterpart at the other end.
For router-router tunnels you end with pairs of configured tunnels.
(You need something like that in any case as pointed out in
draft-ietf-ngtrans-mech-01.txt to not make tunneling be a tool to
circumvent ingress filtering.)

When a packet is received we first check for configured tunnels
using the IPv4 source and destination. If they match a configured tunnel
we pass the packet to that pseudo interface. If it doesn't match
any configured tunnel we look for an automatic (and in the future 6over4)
tunnel pseudo-interface where we just match on the local IPv4 address.

This allows simple things like N different configured tunnels (perhaps with
different security policy) together with 1 automatic tunnel OR 1 6over4
tunnel. But we can't do multiple 6over4 pseudo interfaces unless we node
has multiple local IPv4 addresses.

I think that's all that can be done unless you get something like VLAN
support in 6over4 (some tag in the packet which identifies the virtual
6over4 LAN) which would be overkill. Except for configured tunnels
I don't expect machines to have more than one "encapsulate in IPv4"
tunnel per physical interface.

   Erik

---

From: Jim Bound <[email-masked]>
Date: Thu, 28 Jan 1999 11:11:03 -0500

I agree with Erik it is an implementation issue.

Having did psuedo tunnels, then only configured tunnels, we went back to
psuedo tunnels.  Its the only way to make all this work and for other
parts of IPv6 too (e.g. routing).  Psuedo tunnels are harder but better.

/jim