[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 6to4; ISATAP interfaces configured over same IPv4 address (wa s: Re: FYI Isatap implementations info)
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
> 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 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?)
> >>
> >>
> >>
> >
> >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 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?
> >>
> >>
> >>
> >
> >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
> >
> >
> >
> >
>
>