ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] ]

["Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>]

Hi Pekka, Fred, All

> On Fri, 26 Mar 2004, Karen E. Nielsen (AH/TED) wrote:
> > > Yes.  This is very real if they use the same address.  
> But from the
> > > implementation point of view, this is a huge problem.  How do they
> > > ensure that this won't happen?  Seems like a very 
> difficult thing to
> > > do.
> > 
> > Well, I don't think that I understand why it is such a problem form
> > the implementation point of view (I certainly wasn't for us, but
> > then they may be some autoconfiguration issues that are escaping
> > me).
> 
> If you enforce this in the implementation strongly enough, i.e., with 
> a MUST, then this is doable.  Could be in the spec.

You don't need at MUST only support one kind of tunnels here, 
however the implementation must be able to 
prioritise the tunnel interfaces and rules for
how the prioritisation is done should
be included in the spec.

For outbound traffic there isn't a problem, 
the appropriate tunnnel interface should
be selected from the forwarding table/destination cache.

For inbound traffic there is an issue if the tunnel interfaces, 
lets say an Isatap pseudo tunnel interface and a configured 
v6inv4 tunnel interface, are anchored on the same
(source) address of an Ipv4 interface. 
The implementation must here be able to determine which protocol processing module
(Isatap or configured tunnel respectively) that an incomming
packet should be subject to.

One possibility here (which we have used in one implementation)
it to apply the following inbound processing rules in prioritised order:
R1.	If the outer IPv4 header of the encapsulated packet matches a configured v6inv4 tunnel (if any) the packet is processed by this tunnel interface.
R2.	If the prefix of the source address in the inner IPv6 header of the encapsulated packet matches a prefix of the (if any) ISATAP interface, the packet is processed by this tunnel interface.
R3.	If the prefix of either the source or destination address in the inner IPv6 header is a 6to4 prefix, the packet is processed by the (if any) 6to4 tunnel interface.

I do consider it unlikely to have both 6to4 and Isatap used on the same Ipv4 interface  so a more strict version of the above could be:

An Isatap and a 6to4 tunnel interface SHOULD NOT coexist on the same IPv4 interface 
(address of an IPv4 interface, strictly speaking, the problems only arise if the tunnels are anchored on the samme addresses).

An Isatap tunnel interface and a configured v6inv4 tunnel interface may be anchored on
the same Ipv4 interface (address of Ipv4 interface). In this case the implementation must comply with the following inbound processing rules in prioritized order:
R1. If the outer IPv4 header of the encapsulated packet matches a configured v6inv4 tunnel (if any) the packet is processed by this tunnel interface.
R2.	If the prefix of the source address in the inner IPv6 header of the encapsulated packet matches a prefix of the (if any) ISATAP interface, the packet is processed by this tunnel interface.

(Obviously the same prioritization can be enforced in between v6inv4 configured tunnels and
6to4 pseudo interfaces, but lets leave that out here.)

> 
> The same actually happens with ISATAP and configured tunneling as 
> well.  Luckily enough, there should be relatively little overlap with 
> them as well.

As Fred has pointed out then coexistence in between Isatap tunnels and 
configured tunnel interfaces anchored on the same Ipv4 address/interface
would be nice to have.

BR, Karen

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you.

E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.