[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: RIPng
- From: [email protected] (Steve Deering)
- Date: Thu, 8 Aug 1996 15:04:26 PDT
- In-reply-to: shand's message of Thu, 01 Aug 96 02:53:47 -0800. <[email protected]>
> > 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
> 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
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.