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

[Brian E Carpenter <brc@zurich.ibm.com>]

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

Alain Durand wrote:
> 
> 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?

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