[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: ISATAP, v6inv4 and 6to4 tunnel interworkings [RE: ISATAP vs a lter natives in 3GPP [Re: comments on draft-ietf-v6 ops-3gpp-analysis-0 9 .txt] ]
Karen,
OK, if you must know it then I believe it is possible to run both 6to4 and
ISATAP from a single interface. Let's say a node wants to send a packet
to a 6to4 destination with prefix 2002:C001:0203::/48, i.e., a node that
is reached via a 6to4 router with unicast IP address 192.1.2.3 (neglecting
for the moment that 192.1.2.3 is non-global and used only as example).
If the node has, e.g., a route in its routing table such as:
2002:C001:0203::/48 -> fe80::0200:5EFE:C001:0203 (via isatap0)
then the packet will go out the isatap0 interface using ISATAP encapsulation
based on the link-local ISATAP address from the routing table as the next-hop
toward the 6to4 router, and the 6to4 router will be unable to tell whether the
encapsulator used 6to4 or ISATAP.
In other words, if we view each 6to4 router as also an ISATAP router with a
link-local address on the "site" that includes the global IPv4 Internet, then it
really makes no difference whether we use a 6to4 interface or an ISATAP
interface for sending the packet.
In terms of receiving packets, if we view every global IPv4 address as a
"Potential Router", then the ISATAP decapsulation checks amount to
exactly the same (optional) checks suggested for 6to4 and, again, either
interface could be used to receive the packet with no differences.
The difference comes when operational deployments will begin to use
non-6to4 global IPv6 prefixes, in which case sending nodes will need to,
e.g., add routes such as:
3FFE:EXAMPLE::/48 -> fe80::0200:5EFE:C001:0203 (isatap0)
Then, the ISATAP router at 192.1.2.3 will appear the same as
if it were a 6to4 relay router that relays from the 6to4 domain to the
3FFE:EXAMPLE::/48 prefix space. Sending nodes will most likely use
the DNS to discover the IPv6 prefix to global IPv4 address mappings for
destinations of interest, and so there really would be no need for running
a BGP-style routing protocol between the ISATAP routers (that are really
acting as 6to4 relay router equivalents). In this case, however, the only
choice would be to use an ISATAP interface, since 6to4 interfaces only
encapsulate packets sent to a 2002:EXAMPLE::48 prefix.
So, I guess that would make the ISATAP interface as the LCD that
needs to be there in any case, and configuring a 6to4 interface also
on the same node (and over the same IPv4 address) could be viewed
as optional. This is not by way of saying that ISATAP is in any way
obsoleting 6to4, but rather the 6to4 and non-6to4 prefix space can
be consolidated into a single automatic tunnel interface footprint
(instead of two) if desired.
Fred
Fred,
I think that the problem is very real, both implementation and
external behavior wise, every time you
want to implement more than one tunneling mechs.
Leaving it up to the implementation to resolve
ambiguities is for me the same as to say
coexistence not in scope of specification (which is fine).
Specification of such coexistence may then of course
appear at a later stage.
However if we actually wish at this stage to enable coexistence of
certain specific combinations of tunneling mechs
then IMO we should say MAY coexist under the following
unambiguous guidelines/rules.
Jordi et al.'s list may of course solve this once and for all.
Karen.
>
> Karen,
>
> Thanks for the additional thoughts. On the non-use of 6to4 prefixes as
> on-link prefixes for ISATAP interfaces, I'd like
to
> back-track on this yet
> again. I don't see a problem with an ISATAP interface and a 6to4
> interface anchored to the same (global unicast) IPv4 address and
> having the same 6to4 prefix as an on-link prefix - just as IP
> addresses
> and prefixes may be assigned to multiple ordinary interfaces.
>
> There is a slight difference in that ISATAP and 6to4 use slightly
> different checks on decapsulation, but it seems sufficient to leave
> as implementor's choice how to resolve the ambiguity, e.g., some
> might choose to always use the 6to4 decapsulation rules (and
> receive interface) in this case.
>
> Fred
> ftemplin@iprg.nokia.com
>
> Karen E. Nielsen (AH/TED) wrote:
>
> >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.
> >
> >
> >
>
>
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.