Am 2011-10-30 22:04, schrieb Roman Hoog Antink:
Hi Goesta
As you can see by this commit, RIP for IPv4 was fixed recently in the git repo (after 1.3.4 came out).
https://git.nic.cz/redmine/projects/bird/repository/revisions/14a8f396e1d8fc...
Before that, it was broken for more than a year: http://marc.info/?l=bird-users&m=127633818913449&w=2 http://marc.info/?l=bird-users&m=130715340100894&w=2
The line with the comment /* Does not really work on Linux */ seems to be the spot that breaks RIP with IPv6.
Thankfully Roman sent me two patches off list, that led to the inclusion of the routes, seen in the RIP packets to the local routing table. However, there are still some bugs within the packets which make me think that RIPng in BIRD is in fact rather RIPv2 with longer addresses ;-) Here are my observations after studying RFC 2080 and the packets I captured from the wire: *) UDP port should be 521 for RIPng (is 520, same as in RIPv1 and 2) *) version number in the RIP header should be 1 (is 2, like in RIPv2) *) the first RTE is entirely empty (except for a metric of 1) - if this is meant to be the next hop RTE, indicating that the packets source address should be used as next hop, the "metric" field should be set to 0xff instead *) the next hop written into the recipients routing table is built from the prefix of the route and the local part of the senders address. As far as I can judge, this is not correct with IPv6, where the link local address should be used to communicate to neighbours instead. Quoted from RFC 2080: ---8<--- An address specified as a next hop must be a link-local address. ---8<--- Here is an example of such a packet, captured by wireshark on my virtualized testing network (plain text is removed to prevent line breaks): ---8<--- 0000 33 33 00 00 00 09 08 00 27 a9 2a be 86 dd 60 00 0010 00 00 00 5c 11 01 fe 80 00 00 00 00 00 00 0a 00 0020 27 ff fe a9 2a be ff 02 00 00 00 00 00 00 00 00 0030 00 00 00 00 00 09 02 08 02 08 00 5c 43 6d 02 02 0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0050 00 00 00 00 00 01 20 01 aa aa bb bb 0b ef 00 00 0060 00 00 00 00 00 00 00 00 40 01 20 01 aa aa bb bb 0070 0b ee 00 00 00 00 00 00 00 00 00 00 40 10 20 01 0080 aa aa bb bb 0b b8 00 00 00 00 00 00 00 00 00 00 0090 40 01 ---8<--- There are four RTEs: *) starting at 0x42: an empty prefix with a metric of 1 (next hop? see above) *) 0x56: local prefix on eth1, metric 1 *) 0x6a: the other router's prefix (learned), metric 16(!?) *) 0x7e: local prefix on eth0, metric 1 So this looks quite fine, apart from the port and version number and the infinite distance to the other router ;-) Sadly my knowledge of C is not sufficient to contribute to the solution by sending patches, but I am willing to do further tests an send results, if someone could help fixing these flaws - unless I misunderstood the results of my tests so far. thanks in advance, Goesta -- #!/usr/bin/perl foreach $c (split(/ /,"47 6f 65 73 74 61 20 53 6d 65 6b 61 6c 0d 0a")) { print pack("C", hex($c));}