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



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?

> >>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..)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings