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