Almost, except that I think it might be possible for more than one
ISATAP
interface to be configured over the same IPv4 address (IPv4
address-to-
interface mapping, actually).
OK.
For each such ISATAP
interface for which
the IPv6 source is on-link,
Why
should the IPv6 source be on-link -
The
IPv6 source could be anything in principle, couldn't it ?
Shouldn't the destination address alone point the
packet
to
the Isatap interface. Letting Isatap
specific decapsulation checks be applied
subsequent
as
part of Isatap interface receive processing - ?
the IPv6 destination address
should be checked
until a match is found. If no matching ISATAP interface is found, the
6to4
interface(s) should be checked next. BTW, checking for a matching
IPv6
destination address is part of what I mean when I say "belongs to"
an
interface.
Fred Templin
Hi
Fred,
Yes,
given that router-to-router tunnelling isn't an
issue.
I agree wrt the router case.
Wrt the host case,
I
believe that the rules should be bound to the
destination address rather
than the source address - that is:
if a 6to4 interface and an isatap
interface are configured over
the same IPv4 address, a received packet's
inner IPv6 destination address
is first checked to see if it matches an
address of the Isatap interface
(in which case it should be processed by
that interface).
Next, if the packet does not belong to the isatap
interface,
it is checked to see if it belongs to the 6to4
interface.
BR, Karen
> -----Original
Message-----
> From: Fred Templin
[mailto:ftemplin@iprg.nokia.com]
> Sent: 16. april 2004 18:40
>
To: Karen E. Nielsen (AH/TED)
> Cc: IPv6 Operations
&! gt;
Subject: Re: 6to4; ISATAP interfaces configured over same IPv4
address
> (was: Re: FYI Isatap implementations info)
>
>
> Hi Karen,
>
> It looks like we have reached
conclusions on this topic. Conclusions
> are that, if a 6to4 interface
and isatap interface are configured over
> the same IPv4 address, a
received packet's inner IPv6 source address
> is first checked to see
if it has an on-link prefix on the
> isatap interface.
> Next,
if the packet does not belong to the isatap interface,
> it is
checked
> to see if it belongs to the 6to4 interface.
>
>
Can we consider this case now closed?
>
> Fred
>
ftemplin@iprg.nokia.com
>
> Karen E. Nielsen (AH/TED)
wrote:
>
> >Hi Fred,
> >
> >
>
>
> >>>
> >>>
> >>>
> >>>
> >>>>If a 6to4 i! nterface 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?)
> >>
> >>
>
>>
> >
> >Prefixes local to the Intra-site of the
Isatap interface
> >including link-locals are what I intend 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.)
> >>
> >>
>
>>
> >
> >I agree, though in case the destination is
6to4 but doesn't
> belong to this router,
> >the packet
will and should be silently discarded by the 6to4
> tunnel interface.
> >[in compliance with e.g. section 5.2 of
>
draft-ietf-v6ops-6to4-security-02.txt].
> >
> >
>
>
> >
> >> 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.
> >>
>
>>
> >>
> >
> >I agree.
>
>
> >
> >
> >> 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.
> >>
>
>>
> >
> >If the 6to4 interface isn't a 6to4 relay
interface
> >the 6to4 interface will and should discard the packet
silently.
> >
> >
> >
> >>>**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 t! o 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?
> >>
> >>
>
>>
> >
> >I apologize. The above was an attempt to
explain why the
> >Isatap source address check should precede the
6to4
> destination check when allocating
> >the appropriate
tunnel interface on the inbound path in case
> >where both 6to4 and
isatap interfaces are anchored on the
> same ipv4 interface.
>
>
> >But then I understand now that we may be in agreement on
that.
> >
> >By "mentioned inner source address", I mean
an encapsulated
> packet where inner
> > source address
matches a prefix of the ISATAP interface.
> >
> >BR,
Karen
> >
> >
> >
> >
>
>