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] ]

[Fred Templin <ftemplin@iprg.nokia.com>]

Pekka,

Pekka Savola wrote:

> On Wed, 31 Mar 2004, Fred Templin wrote:
>  
>
> > > > 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.
> > > >   
> > > >
> > > >        
> > > I don't think that's accurate.  For example, you don't use link-locals
> > > on top of 6to4.  With ISATAP, you'd be accepting link-local traffic
> > >      
> > >
> > > from everyone.
> >    
> >
> > I see your point. In the ISATAP decapsulation checks, we currently
> > say that we accept packets coming from any member of the Potential
> > Router List and (thorough error of omission, perhaps) that could
> > include link-locals. Seems like this should be pretty
> > straightforward to fix - or do you still think there is some tricky
> > aspect of it that I'm not seeing?
> >    
>
> I'm not sure what you're saying:
>
> 1) modifying the reception from members of PRL list (in some fashion)
>
> 2) modifying the acceptance of link-local messages in general
> 2.a) for all members of PRL
> 2.b) for PRL members and ISATAP nodes both
>
> I think you were proposing 2.a), but not sure? (Or 2.b?)
>
> Disallowing link-locals could have a number of effects depending on
> which of these methods it's used.  E.g., it could prevent running a
> routing protocol on top of the links (not sure if you'd want that).  
> It might also be confusing to disallow it as you're typically
> configuring an ISATAP link-local address as your next-hop (and you
> couldn't ping the next-hop).  
>
> I.e., if the link-local address would only work as a "pseudo-address",
> it would be used only as a means to specify "send to node 192.1.2.3
> through isatap interface".
>
> How would the ISATAP nodes send RS to the router, and the router send
> RA to the nodes to configure the on-link prefix, btw, if this was
> disallowed?

No; not disallow link-locals, since they are fundamental to ND over ISATAP.
The intent of the proposal was only to stop link-locals from coming from
incorrect nodes. In the current document (section 8.6), we have the 
following
checks for IPv4 source address verification:

      For packets received on an ISATAP interface, the IPv4 source
      address is correct if:

      -  the IPv6 source address is an ISATAP address that embeds the
         IPv4 source address in its interface identifier, or:

      -  the IPv6 source address is the address of an IPv6 neighbor on
         an ISATAP interface associated with the locator that matched
         the packet (see: section 7.2.3), or:

      -  the IPv4 source address is a member of the Potential Router
         List (see: section 9.1).

Neglecting for the moment the middlemost of the three checks, we see that
the first check accepts link local IPv6 source addresses that embed the IPv4
source address in the interface identifier. However, the third check also
accepts link local IPv6 source addresses that *do not* embed the IPv4
source address - so long as the IPv4 source address is in the Potential
Router List - and this is the part that could cause trouble.

The fix suggestion is to modify the third check in the list to exclude
packets with IPv6 link-local source addresses from the check, forcing
IPv6 link-locals to be either verified or rejected via the first check only.
Comments?

> > > > 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.
> > > >   
> > > >
> > > >        
> > > Uh, no.  6to4 relay routers are also reachable through the 6to4 
> > > interface, right?
> > >
> > >      
> > Well, yes - I agree with your point, and the ISATAP interface is not
> > the only choice. I don't believe this changes the fact that one possible
> > implementation alternative is to combine both the ISATAP and 6to4
> > functions over a single interface, however.
> >    
>
> (I haven't gone through the thought exercise of looking through the
> details, but the prospect leaves me with a fuzzy bad feeling..)

Well, the good news is that this would fall under implementation details,
and not anything necessary for protocol specification - right?

Fred
ftemplin@iprg.nokia.com