Hi Fred,
Please accept my apologies for sending
half baked thoughts (previous mail) out on the list.
A few comment inline.
BR, Karen
[snip]
Agree that an implementation must be able to prioritize 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:
I simply mean that the prioritization in
between different tunnels in the inbound processing path
(i.e. exact algorithm behind the location of appropriate inbound tunnel interface) can have implications for
the external behavior, wherefore it should be written down in
an IETF document. For what concerns Isatap, e.g., in the Isatap "spec".
(In regard to the latest Isatap draft, e.g. in Section 7.2.3, but this is of course not for me to say :-)).
For outbound traffic there isn't a problem,
the appropriate tunnel 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 incoming
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
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.
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.
I am sorry if that's already spelled out in the current draft.
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 same
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?
First I must say, that the rules above were used by us
in a Router implementation (not host) in which Isatap communication only
was supported to and from the Isatap hosts of the router.
(i.e. no support for Isatap router-to-router).
I apologies for not making that clear !!!!!
Secondly:
I assume that the above rules means to imply that a packet should be:
processed by the Isatap interface when inner packet is destined to and/or sourced from an address with a prefix of the Isatap interface.
I guess that the above rules are sound and lead to unambiguous behavior
both in the host and in the Isatap+6to4 border router case (that is, a router with both 6to4 pseudo (border router) and router-to-host Isatap interfaces, the reason for not including router-to-router isatap interfaces is simply that I haven't thought very deeply about those)
There may be a problem in the following, very very sick could be discarded ?, situation:
Given that a router has a non-6to4 prefixed Isatap interface
as well as a 6to4 relay router interface
anchored on the same address of an IPv4 interface (not using 6to4 anycast address) then v6inv4 encapsulated packets may arrive on the IPv4 interface in which the inner v6packet is destined for an Isatap address with
the mentioned non-6to4 Isatap prefix of the isatap interface but where
the encapsulated packet is sourced from a 6to4 border router using 6to4.
This packet should be processed by the 6to4 interface and not the Isatap interface.
(And yes the hosts should speak Ipv4 instead of Ipv6 given, as it is, that they
both have global Ipv4 addresses).
On the other hand if the above prefix limitations are combined with a split
in a host and a router part, such as:
* ROUTER interfaces: 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.
* HOST interfaces: 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,
then no ambiguity would arise wrt inbound 6to4 and isatap processing.
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:
Again, I apologize wildly for not making it clear that this was
thought only to cover the
router case and only in the router-host situation.
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.
Wouldn't you need
a different R2 for host and for router interfaces
(founded on destination address and source address respectively) ?
In addition, the source address check could potentially be performed by the isatap host interface implementation - e.g. to rule out direct packets from
"non-link" hosts - thus limiting the direct tunnelling function to hosts
using the same prefixes - and/or to rule out packets coming form anything else
than default router in some scenarios.
With the 6to4 prefix limitation on Isatap interfaces this would
eliminate conflicts wrt inbound 6to4 and Isatap interfaces processing.
In addition you would need to prioritize configured tunnel and Isatap
interfaces, but I guess that this is implicitly covered by 1) (in that
specific Ipv4 addresses would take precedence over wildcard in Ipv4 source).
I hope this at least help to clarify my previous mail.
Whether it adds anything useful to the picture, will be for you and
others to decide.
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.