Hi, again If you were paying attention (unlike myself) you may have noticed that the below fix doesn't actually make BIRD RFC-compliant. Rather, it makes BIRD interoperate with other RFC-compliant RIPng routers. After all, the RFC doesn't state that route advertisements must be sent with an HLIM of 255 (though that's implied, of course), but rather that routers must _check_ that the HLIM is 255 when they _receive_ routing updates. I tried getting that to work by checking s->ttl in the rip_rx function. However, that always returns 255 (or, I suspect, whatever rif->sock->ttl was set to in the new_iface function) regardless of the incoming packet's HLIM. I then tried using the sk_set_min_ttl function on the socket in the new_iface function but got this error: Kernel does not support IPv6 TTL security (i.e. the socket protocol doesn't support that option). Since I'm on Linux (Debian) this error comes from sysdep/linux/sysio.h. Anyway, I am not familiar enough with the BIRD code to understand where I can obtain the actual HLIM (TTL) of the incoming packet in order to ensure that the HLIM (TTL) is 255. I'll keep digging but if anybody has any suggestions or pointers to get me moving in the right direction I'd appreciate it. Thanks. - Simon On 06/14/2013 05:41 PM, Simon Dickhoven wrote:

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~b...

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

Alright. After a lot of digging I got a working RIPng hopcount check. See attached patch file. Here's what I did: 1) In order to reduce any deleterious effects of my subsequent modifications I first introduced a new socket flag in lib/socket.h. #define SKF_HLIM_RX 8 /* Report Hop Limit for RX packets */ 2) I then modified sysdep/unix/io.c to do the following. 2.1) Based on the above flag, I added a setsockopt statement in the sysio_register_cmsgs function that causes the IPv6 HLIM field to be passed as ancillary data in the recvmsg call (which takes place in the sk_read function). if ((s->flags & SKF_HLIM_RX) && setsockopt(s->fd, IPPROTO_IPV6, IPV6_RECVHOPLIMIT, &ok, sizeof(ok)) < 0) return "IPV6_RECVHOPLIMIT"; 2.1.1) In order to actually receive this additional information I had to increase the control message buffer size by 13 (a number I arrived at through trial and error and certainly a hack, rather than the correct way of doing this... FIXME!!!). #define CMSG_RX_SPACE CMSG_SPACE(sizeof(struct in6_pktinfo) + 13) 2.1.2) For backward-compatibility with RFC 2292 I also included this: #ifndef IPV6_RECVHOPLIMIT #define IPV6_RECVHOPLIMIT IPV6_HOPLIMIT #endif 2.2) Then I reworked the sysio_process_rx_cmsgs function to parse out the HLIM info from the control message and set the TTL field in the socket struct (s->ttl) (if and only if the SKF_HLIM_RX flag is set). (see attached) 3) Finally, I modified proto/rip/rip.c to take advantage of this new functionality. 3.1) In the new_iface function I set my newly created socket flag. #ifndef IPV6 rif->sock->ttl = 1; rif->sock->flags = SKF_LADDR_RX; #else rif->sock->ttl = 255; rif->sock->flags = (SKF_LADDR_RX | SKF_HLIM_RX); #endif 3.2) Once that was done, the rip_rx function had access to the HLIM info via the socket struct (s->ttl). if (s->ttl < 255) { log( L_REMOTE "%s: Discarding packet with HLIM = %d < 255 from %I on %s.", p->name, s->ttl, s->faddr, i->iface ? i->iface->name : "(dummy)" ); return 1; } As far as I can tell, the only thing that could possible affect other protocols is 2.1.1). Other than that, all my changes exclusively apply to RIPng since that's the only code that sets the SKF_HLIM_RX flag. As long as this flag is not set, all my modifications are disabled and the code is functionally equivalent to what it was before. Please feel free to use the above modifications and also to give me feedback on it. I have tested these modifications with a Quagga (Vyatta) router and a Cicso router. I used ip6tables on the Quagga (Vyatta) router to mangle the HLIM in order to force a rejection of routing updates from it. ip6tables -t mangle -A OUTPUT -p udp -m udp --sport 521 -j HL --hl-set 10 When I removed the mangle rule, routes were accepted. When I re-added it, routes were rejected again and removed from the routing table. Note: The above modifications were made to version 1.3.7 of the source code so they may not apply to the latest code. Thanks. - Simon PS: I saw that my Cisco router sets the class for RIPng advertisements to 0xe0 though I couldn't find any RFCs that call for that. The current BIRD code (or at least version 1.3.7 of the code) doesn't set the class at all because it hasn't (/hadn't) been defined by an RFC. On 06/18/2013 05:48 PM, Simon Dickhoven wrote:

Correction: The RFC does state explicitly that advertisements must be sent with an HLIM of 255, as well as that receiving routers must check that the HLIM is 255.

So I guess my little patch makes BIRD half-compliant in that respect then :).

- Simon

On Jun 18, 2013, at 17:38, "Simon Dickhoven" <Simon.Dickhoven@tachyon.com> wrote:

...

Hi, again

If you were paying attention (unlike myself) you may have noticed that the below fix doesn't actually make BIRD RFC-compliant.

Rather, it makes BIRD interoperate with other RFC-compliant RIPng routers.

After all, the RFC doesn't state that route advertisements must be sent with an HLIM of 255 (though that's implied, of course), but rather that routers must _check_ that the HLIM is 255 when they _receive_ routing updates.

I tried getting that to work by checking s->ttl in the rip_rx function. However, that always returns 255 (or, I suspect, whatever rif->sock->ttl was set to in the new_iface function) regardless of the incoming packet's HLIM.

I then tried using the sk_set_min_ttl function on the socket in the new_iface function but got this error:

Kernel does not support IPv6 TTL security

(i.e. the socket protocol doesn't support that option). Since I'm on Linux (Debian) this error comes from sysdep/linux/sysio.h.

Anyway, I am not familiar enough with the BIRD code to understand where I can obtain the actual HLIM (TTL) of the incoming packet in order to ensure that the HLIM (TTL) is 255.

I'll keep digging but if anybody has any suggestions or pointers to get me moving in the right direction I'd appreciate it.

Thanks.

- Simon

On 06/14/2013 05:41 PM, Simon Dickhoven wrote:

...

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~b...

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