[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

Karen,

The points you raise warrant careful consideration; see below:

Karen E. Nielsen (AH/TED) wrote:

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,


I don't think "MUST only support one kind of tunnels" was
exactly what Pekka was implying, but see more below:

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.


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
are referring to when you say: "the spec", but see more below:

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


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

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.


Agree with the above assertions regarding inbound traffic.

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.


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.

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


(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?

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.


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.

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


Agree with let's leave it out.

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.


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

Fred
ftemplin@iprg.nokia.com


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.