[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Subject: RIPng
- From: [email protected] ( (Mike Shand REO2 G/C2 DTN:830-4424))
- Date: Thu, 01 Aug 96 10:53:47 +0100
- In-reply-to: Your message of "Wed, 31 Jul 96 19:28:57 EDT." <[email protected]>
> I want to know how they implement ripng on a tunnel. I think that
> the ripng draft doesn't clearly say in case of tunneling. There
> is no link-local address and maybe no multicasting depending on
> its sit implementation. I'm afraid that we need interoperablity
> check on ripng as well. (Have it done at UNH? I'm sorry I'm a
> newcomer) If some of 6bone sites can run ripng, I'd like to make
> a temporal tunnel to it in order to check interoperablity with
> our implementation.
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. The MTU would
have to be set to take account of the additional IPv4 header. There would
be no broadcast/multicasting.
However, thinking about it some more, it starts to get interesting.
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? What other gotchas might be lurking? 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 think we can make it work, but it looks like we need either some mods
to RIPng or a separate draft to specify exectly how it is supposed to be done.
Has anyone else actually got this working?