RIPng

[Steve Deering]

Mike,

> > I want to know how they implement ripng on a tunnel. ...
> 
> Well, we don't at the moment. At first sight it seems pretty trivial.
> You just define a pseudo pt-pt interface for the tunnel and run
> RIPng (or whatever other routing protocol you fancy) over that 
> interface. Presumably you assign a link local address by whatever
> means you would normally use for a pt-pt (e.g. PPP) link.

Whether or not the endpoints of a tunnel need their own link-local addresses
is an open issue.  I don't think RIPng should require that, since RIP
classically has operated fine over unnumbered p-to-p links.

> There would be no broadcast/multicasting.

Well, there's no broadcasting since IPv6 does not have broadcast addresses.
But RIPng might as well use its assigned IPv6 link-scope multicast address
for messages sent to neighbors across across p-to-p links, including tunnels,
just like on multi-access links.  The implementation of multicast on a p-to-p
link is a trivial and degenerate -- just send the packet to the other end of
the link.

> Suppose the IPv4 tunnel becomes unidirectional, either because it was
> wrongly configured, or because the underlying IPv4 routing becomes
> unidirectional. Do we need any special mehanisms to dectect such
> misconfiguiration?

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.

> Do we need to send router advertisements over such a link which should
> only have another router at the other end? Presumably so, since it could
> in theory be a host running RIP in listen mode (say). etc. etc.

I hope we can get away from the use of routing-protocol-snooping by hosts.

Steve