[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-09 .txt] ]
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.