OK. I looked at proto/rip/rip.c a bit more and figured that I might as
well give it a shot and hack around a little bit. I ended up making this
tiny mod:
--- a/proto/rip/rip.c
+++ b/proto/rip/rip.c
@@ -706,7 +706,11 @@
rif->sock->dport = P_CF->port;
if (new)
{
+#ifndef IPV6
rif->sock->ttl = 1;
+#else
+ rif->sock->ttl = 255;
+#endif
rif->sock->tos = IP_PREC_INTERNET_CONTROL;
rif->sock->flags = SKF_LADDR_RX;
}
Subsequently, I did a full Debian package build based on
http://backports.debian.org/debian-backports/pool/main/b/bird/bird_1.3.7-1~bpo60+1.diff.gz
I added the above patch to the debian/patches dir and appended the patch
file name (I named it "011-ripng_hopcount.patch") to debian/patches/series.
The package built fine. I installed it on my test box and lo and behold:
Vyatta/Quagga is now happy and I'm seeing my IPv6 routes propagate via
RIPng.
Tcpdump reveals that RIP(v2) is still using a TTL of 1 and RIPng is
using an HLIM (IPv6 equivalent of TTL) of 255.
Thanks.
- Simon
On 06/14/2013 03:04 PM, Simon Dickhoven wrote:
Hi,
I just started experimenting with BIRD for an IPv6 deployment. I am
using Vyatta VC6.6R1 router VMs on either side of my BIRD VM (which runs
on a customized Debian Squeeze release with kernel 3.3.1). I installed
bird/bird6 1.3.7 from the squeeze-backports repository.
Here my setup.
Lab Net --- Vyatta --- BIRD on Debian --- Vyatta --- Stub Net
Anyway, I don't have any problems with my configs or anything like that.
My problem is that Vyatta's ripngd (part of Quagga) complains about an
RFC violation when it receives RIPng advertisements from BIRD:
Jun 14 21:43:40 vyatta ripngd[1682]: RIPng packet comes with non 255 hop
count 1 from fe80::20c:29ff:fef8:cbc5
I looked at the source code in rip.c and see this line:
rif->sock->ttl = 1;
which is the only reference I can find to TTL/Hop Count. So I'm guessing
this is the culprit. The latest source code (1.3.10) is identical in
this respect.
RFC 2080 states
[...]
As an additional check, periodic advertisements must have their hop
counts set to 255, and inbound, multicast packets sent from the RIPng
port (i.e. periodic advertisement or triggered update packets) must be
examined to ensure that the hop count is 255.
[...]
The use of the term "must" leads me to believe that this is not optional
and is therefore required for RFC-compliance.
There seems to be no such requirement for RIP (v1/v2) so simply changing
the source code to indiscriminately set the TTL to 255 is probably not
the right thing to do.
Have others encountered this problem and is there possibly a patch or
something for getting RFC-compliance and hence interoperability with
Vyatta/Quagga(ripngd)?
Thanks.
- Simon
