RIPng

[Steve Deering]

Dimitry,

> I believe it would be much cleaner to require all interfaces 
> including tunnels to have link-local addresses.  This way no special 
> considerations have to be applied to p-to-p links.  Address tokens can 
> be trivially generated for tunnel interfaces (e.g. use a local IPv4 
> address for an IPv6-in-IPv4 tunnel or the token of the encapsulating 
> interface for a IPV6-in-IPv6 tunnel).  What are benefits of the totally 
> unnumbered IPv6 interfaces? I guess link-local address space 
> conservation is not one of them :)

Sounds reasonable to me.  I suppose we should move this discussion to the
main IPng list, to see if anyone has any killer counter-arguments.

> > Yes, I think it's important to be able to detect one-way link or interface
> > failures, regardless of link type.  A few of us here at PARC are currently
> > implementing an experimental "RIPng++" which has support for that, plus
> > several other extensions.  We plan to test it out on DARTnet before
> > deciding which specific extensions to suggest for RIPng itself.
> 
> I thought NUD as specified in the ND spec could be quite sufficiently 
> used on all types of links to verify two-way reachability.  Am I missing 
> something?

I don't think NUD is sufficient on multi-access links to verify that
multicast routing updates are reaching all neighboring routers.  NUD
serves to detect the unreachability only of those destinations or next-
hop routers to which one is sending unicast packets.  So yes, we could
depend on NUD on p-to-p links and tunnels, if we specified that RIPng
must use unicast destination addresses over those types of links; however,
we'd still have to employ a different strategy on multi-access links, and
presumably that same strategy would also work in the degenerate case
of a p-to-p link without requiring it to be treated as a special case.

Steve