[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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] ]
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" <ftemplin@iprg.nokia.com>
To: "Alain Durand" <Alain.Durand@Sun.COM>
Cc: "IPv6 Operations" <v6ops@ops.ietf.org>; "Karen E. Nielsen (AH/TED)" <karen.e.nielsen@ericsson.com>; "'Pekka Savola'" <pekkas@netcore.fi>
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] ]
> 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
> ftemplin@iprg.noka.com
>
> 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?
> >
> >
>
**********************************
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.