[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
6to4; ISATAP interfaces configured over same IPv4 address (was: Re: FYI Isatap implementations info)
Hi Karen,
I'll focus on just the 6to4/isatap stuff for now if you don't mind:
Karen E. Nielsen (AH/TED) wrote:
Fred Templin wrote:
If a 6to4 interface and ISATAP interface are configured over the same
IPv4 address, it would have to be a global IPv4 address assigned to an
interface connected to the global Internet due to 6to4
requirements. In
that case, I believe the correct behavior should be for the
6to4 interface
to take precedence for packets received with an on-link 6to4 prefix in
the IPv6 destination, and for the ISATAP interface to take precedence
for all others. Comments?
When I say takes precedence over I (still) mean the following:
First Priority: If the prefix of the source address in the inner
IPv6 header of the encapsulated packet matches a prefix of the
ISATAP interface, the packet is processed by this tunnel interface.
This would seem like the correct natural choice, since it seems consistent
with the notion of "intra-site". Again, I assume by this you are intending
to include link-locals? (Perhaps that's *all* you are intending to include?)
Second Priority: 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 6to4 tunnel interface.
Let's take a closer look at the cases; please tell me if I mis-represent
anything:
1) If both the source and destination are 6to4, then the packet is
originating
and terminating within the 6to4 domain. So, use of the 6to4
interface would
seem natural and appropriate. (Note that the destination might not
belong to
*this* 6to4 router in which case L3 might forward (redirect?) the
packet to
the correct 6to4 router - but, this is irrelevant for L2.5
decapsulation.)
2) If the destination is 6to4, but the source is not 6to4, then the
packet is
originating from behind a 6to4 relay router and terminating within the
6to4 domain. Again, the 6to4 interface seems the natural choice.
3) If the source is 6to4, but the destination is not 6to4, then the packet
is originating from within the 6to4 domain and will eventually
terminate within the native IPv6 Internet. To do this, it will have
to transition from the 6to4 domain to the native IPv6 Internet via
a relay router which may/may not occur on *this* 6to4 router.
Is the 6to4 interface the correct interface to decapsulate for this
case?
It seems somewhat less obvious to me, but still a better choice than
the ISATAP interface when the source prefix is not on-link.
**Here again it should be emphasized that these rules are not intended to
apply to the Isatap router-to-router tunnelling situation.**
I am fine with leaving this aspect out from the current discussion.
I am not 100 % sure what you mean by an on-link 6to4 prefix.
I think I may have been stuck with a mis-conception that 6to4 interfaces
should only decapsulate packets with an IPv6 destination prefix of
2002:V4ADDR::/48, where "V4ADDR" is assigned to one of the
node's IPv4 interfaces.
I can imagine that you refer to one of the following 2 situations:
(I)
_ _ _ _ - - - - - - - - - - - - - -
| | ___ | Global Internet/exterior |
| 6to4 |-v6-/ R \ | _ _ _ _ _ |
| Site | \___/-globalV4ADDR-| Intra | |
|_ _ _ _| | -site | |
- - - - - - - - - - - - - -
(II) - - - - - - - - - -
___ | Global Internet/ |
/ R \ | _ _ _ _ _ exterior|
\___/-globalV4ADDR-| Intra | |
| -site | |
| of 6to4 | |
| prefix | |
- - - - - - - - - -
In both situations a packet with the mentioned inner source address
should be from within the intra-site and should be processed by the Isatap
interface and not the 6to4 interface turned towards the exterior.
In (I), then in our 6to4 implementation, the packet with the mentioned source address,
will be discarded by the 6to4 tunnel interfaces as we rely on trusted relay routers.
It wil not be accepted as a packet from a 6to4 border router since the v6 and the v4 sources
don't add up.
In (II)
The packet is a packet coming from and destined for the Intra-site and should
be processed by the intra-site router interface (i.e. the Isatap
interface). Again
the 6to4 interface would discard the packet,
further It should be redirected but thats another matter.
I'm not prepared to comment on this in detail since I'm not entirely sure
what you are referring to by "the mentioned inner source address", and
your examples might have been motivated by the misconception I mentioned
above. Perhaps this discussion is obviated by the examination of the cases
I provided earlier?
Fred
ftemplin@iprg.nokia.com