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

From: "Karen E. Nielsen (AH/TED)" <[email-masked]>
Date: Mon, 29 Mar 2004 12:01:20 +0200

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.

---

From: Fred Templin <[email-masked]>
Date: Mon, 29 Mar 2004 15:09:37 -0800

Karen,

The points you raise warrant careful consideration; see below:

>You don't need at MUST only support one kind of tunnels here,

I don't think "MUST only support one kind of tunnels" was

>how the prioritisation is done should

Agree that an implementation must be able to prioritise the
tunnel interfaces. Not quite as clear on what should be included
in "the spec", and not entirely sure exactly which document you

>be selected from the forwarding table/destination cache.

Agreed; longest-prefix match will select the appropriate tunnel
interface for outbound traffic.

>packet should be subject to.

Agree with the above assertions regarding inbound traffic.

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

IP-proto-41 packets are first checked to determine whether they belong
to a configured tunnel by checking the (source/destination addresses) in
the IPv4 header, yes. This much seems consistent with the current
ISATAP draft version, but thanks for reminding of this.

>(address of an IPv4 interface, strictly speaking, the problems only arise if the tunnels are anchored on the samme addresses).

(Retracting a bit from some comments in an earlier message on this subject.)
According to RFC 3056, 6to4 can only occur over global unicast IPv4 
addresses.
ISATAP interfaces can also occur over global unicast IPv4 addresses, in 
which
case the ISATAP link would span the entire global IPv4 Internet.

If we allowed both a 6to4 interface and an ISATAP interface to be anchored
to the *same* global unicast IPv4 address (e.g., "V4ADDR"), it should be
OK as long as no prefixes derived from "2002:V4ADDR::/48" (i.e., the /48
prefix itself, or any finer-grained derivative prefix) are configured as 
on-link
prefixes on the ISATAP interface. This would keep the "6to4-prefixed IPv6
Internet" from overlapping with the "everything-else-prefixed IPv6 
Internet",
where "everything-else" is a candidate prefix for ISATAP.

I think there may be several possible ways of expressing this, ranging from
"least restrictive" to: "most restrictive"; below are two possible examples
that lie at the extremities of the range of alternatives:

Least restrictive:
**************
  "An ISATAP and a 6to4 tunnel interface MAY coexist on the same global
    unicast IPv4 address ("V4ADDR"), but in this case the ISATAP interface
    MUST NOT configure a prefix derived from " 2002::V4ADDR/48" as
    an on-link prefix."

Most restrictive:
**************
  "An ISATAP interface configured over a global  unicast IPv4 address
    MUST NOT configure a prefix derived from "2002::/16" as an
    on-link prefix." 

(Note that both of these examples still allow for ISATAP interfaces
configured over private IPv4 addresses to configure 6to4 prefixes,
but the ISATAP tunneling would be strictly intra-site in that case.)

Any comments on this?

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

Agreed, as above.

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

I have to say that I have thought hard about this rule and am not
entirely sure what to make of it, since it seems to simplistic.
But, I will try:

  1) What we have considered for this space to-date is that an ISATAP
    interface would match a specific IPv4 destination address and a
    wild-card source address in the IPv4 header of an ip-proto-41 packet.
  2) Multiple ISATAP interfaces might be matched by this criteria,
    and so we require a means for identifying the correct one.
  3) An ISATAP interface that configures a prefix that matches the IPv6
    source of the packet (if found) is clearly the best first-choice to 
receive
    the packet.
  4) If no ISATAP interface with a matching prefix is found, this could
    be a packet from an off-link source that is being forwarded to (or,
    through this decapsulator by a member of the Potential Router List.

But, stopping now for a closer look at item 4), there seems to be no
way to determine which ISATAP interface (among possibly many)
might be the correct one to receive and decapsulate the packet - if
any. It could be that the IPv6 destination address is a foreign address
also, making for a router<->router transaction which is a non-goal
for ISATAP.

This says that, in order to disambiguate the search, we really need to
treat all possible IPv6 source addresses as on-link for the purpose of
receiving packets, but off-link for the purpose of sending return
packets. In other words, we would need an ISATAP interface
with a distinct /128 prefix for each destination we are actively
communicating with that uses the same IPv6 next-hop address
for return addresses. In other words, from a host's viewpoint the
sources of IPv6 packets for which a matching ISATAP interface
exists would all appear to be on-link, but the destinations would
all appear to be off-link and reachable through a particular IPv6
next-hop address. There is a (somewhat) subtle implication here
for decapsulation validity checks of the IPv4 source address,
but should be very simple to express.

If what I am saying makes sense, and if we can agree that ISATAP
support for router<->router tunneling is a non-goal, then I believe
your R2 above could provide a useful simplification for the spec.

>6to4 pseudo interfaces, but lets leave that out here.)

Agree with let's leave it out.

>configured tunnel interfaces anchored on the same Ipv4 address/interface

Already allowed in the current draft, and will make sure it stays that way.

Fred
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Mon, 29 Mar 2004 21:07:18 -0800

The issue raised here is not limited to  6to4 & isatap but in fact it 
arises anytime
you will have two or more tunneling protocols over IPvx anchored
on the same IPvx address.
For example, we saw that issue while implementing 6to4 and IPv4 
compatible addresses.
Our implementation choice at the time was to say we do not support both 
at the same time
on the IPv4 address.

So if you want do set rules, they will have to include
configured tunnel v6 over v4 (and its many tunnel broker variants),
6to4
6over4
isatap
IPv4 compatible

Given the fact that all those protocols have been 
standardized/implemented
to (at least) some extend, the only two alternatives IMHO are:
- either declare them all mutually exclusive
- create that ordered list.

Note that it may be more or less difficult for some implementation to 
actually
see both inner and outer address of the packet at the same time.
This gets, of course, even trickier if multiple levels of tunneling are 
in place,
e.g. v6 in v6 in v4 in v6 in v4 ....

I have not really seen a compelling, practical, case where having two 
or more
of those protocols anchored to the same IPv4 address was necessary, so 
I would be
tempted to favor the 'mutually exclusive' approach.

	- Alain.

On Mar 29, 2004, at 3:09 PM, Fred Templin wrote:

> ISATAP interfaces can also occur over global unicast IPv4 addresses, 
> in which
> prefix itself, or any finer-grained derivative prefix) are configured 
> as on-link

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 30 Mar 2004 14:33:43 +0200

I think this is a case for a SHOULD though; there may be cases we haven't
thought of where more than one could rationally be active.

   Brian

-- 
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Brian E Carpenter 
Distinguished Engineer, Internet Standards & Technology, IBM

---

From: Fred Templin <[email-masked]>
Date: Tue, 30 Mar 2004 10:05:41 -0800

Alain,

Appreciate the thoughts. As to your assertion of not seeing a compelling,
practical case I tend to disagree with that as a sufficiently strong 
arguement
towards disallowing multiple tunneling protocols anchored to the  same
IPv4 address.  So, my leaning is toward your suggestion of a prioritized
set of rules, or something similar.

Thanks - Fred
[email-masked]

Alain Durand wrote:

> Our implementation choice at the time was to say we do not support 
> both at the same time
> on the IPv4 address.
>
> This gets, of course, even trickier if multiple levels of tunneling 
> are in place,

---

From: Alain Durand <[email-masked]>
Date: Tue, 30 Mar 2004 10:09:27 -0800

> set of rules, or something similar.

Fred,

Could you provide an example where anchoring two or more tunneling 
protocols
on the same IPv4 interface makes real sense and cannot be done 
differently?

	- Alain.

---

From: Fred Templin <[email-masked]>
Date: Tue, 30 Mar 2004 10:26:54 -0800

> on the same IPv4 interface makes real sense and cannot be done 

Yes, but probably not without sending the list into the same sort tailspin
we've seen in the past whenever this subject comes up.

I think there are plenty of messages in the archives to draw on on this
subject, but the main point is that I don't see how a: "MUST NOT configure
multiple tunneling types over the same IPv4 address" can be justified in the
face of reasonable doubt that such configurations will be required in near
term or future operational deployments.

Fred
[email-masked]

---

From: Alain Durand <[email-masked]>
Date: Tue, 30 Mar 2004 10:35:38 -0800

> we've seen in the past whenever this subject comes up.

Well, one could take this as a sign that the case is not that solid...

> term or future operational deployments.

I'm not looking at a MUST. Brian pointed earlier that a SHOUD rather 
than a
MUST was more suitable. Actually the discussion is more between a MAY 
and a SHOULD.
Essentially, the text I would like to see is something like 
"Implementations MAY
decide not to  support multiple tunneling types over the same IPv4 
address"

	- Alain.

---

From: "JORDI PALET MARTINEZ" <[email-masked]>
Date: Tue, 30 Mar 2004 16:09:23 -0300

Hi all,

In the I-D that we are preparing "auto-trans" that Pekka already mentioned some days ago, we are taking in consideration this priorized set of rules.

Regards,
Jordi

----- Original Message ----- 
From: "Fred Templin" <[email-masked]>
To: "Alain Durand" <[email-masked]>
Cc: "IPv6 Operations" <[email-masked]>; "Karen E. Nielsen (AH/TED)" <[email-masked]>; "'Pekka Savola'" <[email-masked]>
Sent: Tuesday, March 30, 2004 3:05 PM
Subject: Re: Multiple tunneling protocols on the same Ipv4 address )Re: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs alter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-09.txt] ]

> >> that lie at the extremities of the range of alternatives:

**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.