IPv6 rip-only routing - no exchange of routes
Dear list, looking for a small routing daemon for dynamic IPv6 routing on embedded devices, I came across bird recently. Looks pretty much like what I need, but I must have missed something ... The goal is to have two tiny routers, linked to a shared LAN segment (at eth0 in my test). Each router advertises an IPv6 prefix to a local network (wireless in the end, just another ethernet segment on eth1 so far). Nodes on the separate networks should be able to talk to each other via the two routers. And if a third router (ore some more) joins in, the new segment(s) should automatically appear in the routers routing tables - dynamic routing ;-) I compiled bird 1.3.4 from the sources on two test hosts (Debian GNU/Linux - not the embedded stuff yet) using the commands: root@edge01:/usr/src/bird-1.3.4# ./configure --prefix=/usr/local --enable-ipv6 --with-protocols=static,radv,rip root@edge01:/usr/src/bird-1.3.4# make all && make install My first config looked like this: ---8<--- # bird.conf # # dynamic routing configuration # # v0.1 2011-10-21 GS (goesta@smekal.at) # global parameters log syslog all; debug protocols { routes, events, packets }; router id 192.168.0.34; ## routing protocols # device parameters protocol device { scan time 10; } # kernel routing table protocol kernel { scan time 10; persist yes; learn yes; import all; export all; } # router advertisements protocol radv { interface "eth1"; } # dynamic routing using RIPng protocol rip{ authentication md5; password "verysecure"; honor neighbor; interface "eth*"; } ---8<--- Bird started fine on both nodes (obviously the router id was different, but the password was the same) but the routes did not appear on the other router. Router advertisements work fine. After some re-thinking and re-reading the docs I tried to add 'primary' statements to the "protocol device" section, and played with authentication and other rip specific parameters. Eventually I captured RIPng (UDP port 520) packets on the network with empty routes and after adding this: ---8<--- protocol direct{ interface "*"; } ---8<--- the packets contain the two prefixes, LAN and local subnet, I expect the routers to exchange. However the routes do not show up and wireshark mentions "Unknown address family 8193" in the packet details section of the RIPng packets. Here is what syslog says: ---8<--- Oct 28 21:13:50 edge01 bird6: device1: Initializing Oct 28 21:13:50 edge01 bird6: direct1: Initializing Oct 28 21:13:50 edge01 bird6: kernel1: Initializing Oct 28 21:13:50 edge01 bird6: radv1: Initializing Oct 28 21:13:50 edge01 bird6: rip1: Initializing Oct 28 21:13:50 edge01 bird6: device1: Starting Oct 28 21:13:50 edge01 bird6: device1: Scanning interfaces Oct 28 21:13:50 edge01 bird6: device1: State changed to feed Oct 28 21:13:50 edge01 bird6: direct1: Starting Oct 28 21:13:50 edge01 bird6: direct1: State changed to feed Oct 28 21:13:50 edge01 bird6: kernel1: Starting Oct 28 21:13:50 edge01 bird6: kernel1: State changed to feed Oct 28 21:13:50 edge01 bird6: radv1: Starting Oct 28 21:13:50 edge01 bird6: radv1: State changed to feed Oct 28 21:13:50 edge01 bird6: rip1: Starting Oct 28 21:13:50 edge01 bird6: rip1: Listening on (dummy), port 520, mode broadcast (::) Oct 28 21:13:50 edge01 bird6: rip1: State changed to feed Oct 28 21:13:50 edge01 bird6: Started Oct 28 21:13:50 edge01 bird6: device1: State changed to up Oct 28 21:13:50 edge01 bird6: direct1 < primary address ::1/128 on interface lo added Oct 28 21:13:50 edge01 bird6: direct1 < primary address 2001:aaaa:bbbb:ccb8::/64 on interface eth0 added Oct 28 21:13:50 edge01 bird6: direct1 > added [best] 2001:aaaa:bbbb:ccb8::/64 dev eth0 Oct 28 21:13:50 edge01 bird6: direct1 < secondary address fe80::/64 on interface eth0 added Oct 28 21:13:50 edge01 bird6: direct1 < primary address 2001:aaaa:bbbb:ccee::/64 on interface eth1 added Oct 28 21:13:50 edge01 bird6: direct1 > added [best] 2001:aaaa:bbbb:ccee::/64 dev eth1 Oct 28 21:13:50 edge01 bird6: direct1 < secondary address fe80::/64 on interface eth1 added Oct 28 21:13:50 edge01 bird6: direct1: State changed to up Oct 28 21:13:50 edge01 bird6: kernel1: Connected to table master Oct 28 21:13:50 edge01 bird6: kernel1 < rejected by protocol 2001:aaaa:bbbb:ccee::/64 dev eth1 Oct 28 21:13:50 edge01 bird6: kernel1 < rejected by protocol 2001:aaaa:bbbb:ccb8::/64 dev eth0 Oct 28 21:13:50 edge01 bird6: kernel1: State changed to up Oct 28 21:13:50 edge01 bird6: radv1 < interface lo goes up Oct 28 21:13:50 edge01 bird6: radv1 < primary address ::1/128 on interface lo added Oct 28 21:13:50 edge01 bird6: radv1 < interface eth0 goes up Oct 28 21:13:50 edge01 bird6: radv1 < primary address 2001:aaaa:bbbb:ccb8::/64 on interface eth0 added Oct 28 21:13:50 edge01 bird6: radv1 < secondary address fe80::/64 on interface eth0 added Oct 28 21:13:50 edge01 bird6: radv1 < interface eth1 goes up Oct 28 21:13:50 edge01 bird6: radv1: Adding interface eth1 Oct 28 21:13:50 edge01 bird6: radv1 < primary address 2001:aaaa:bbbb:ccee::/64 on interface eth1 added Oct 28 21:13:50 edge01 bird6: radv1 < secondary address fe80::/64 on interface eth1 added Oct 28 21:13:50 edge01 bird6: radv1: State changed to up Oct 28 21:13:50 edge01 bird6: rip1: Connected to table master Oct 28 21:13:50 edge01 bird6: rip1 < interface lo goes up Oct 28 21:13:50 edge01 bird6: rip1 < interface eth0 goes up Oct 28 21:13:50 edge01 bird6: rip1 < interface eth1 goes up Oct 28 21:13:50 edge01 bird6: rip1 < added 2001:aaaa:bbbb:ccee::/64 dev eth1 Oct 28 21:13:50 edge01 bird6: rip1 < added 2001:aaaa:bbbb:ccb8::/64 dev eth0 Oct 28 21:13:50 edge01 bird6: rip1: State changed to up Oct 28 21:13:50 edge01 bird6: kernel1: Scanning routing table Oct 28 21:13:50 edge01 bird6: kernel1: ::/0: [alien] created Oct 28 21:13:50 edge01 bird6: kernel1: Pruning table master Oct 28 21:13:50 edge01 bird6: kernel1: Pruning inherited routes Oct 28 21:13:51 edge01 bird6: kernel1 > added [best] ::/0 via fe80::20c:29ff:fe04:48bc on eth0 Oct 28 21:13:51 edge01 bird6: kernel1 < rejected by protocol ::/0 via fe80::20c:29ff:fe04:48bc on eth0 Oct 28 21:13:51 edge01 bird6: rip1 < added ::/0 via fe80::20c:29ff:fe04:48bc on eth0 Oct 28 21:13:51 edge01 bird6: rip1: Listening on eth1, port 520, mode multicast (ff02::9) Oct 28 21:13:51 edge01 bird6: rip1: Listening on eth0, port 520, mode multicast (ff02::9) Oct 28 21:13:51 edge01 bird6: radv1: Event Init on eth1 Oct 28 21:13:51 edge01 bird6: radv1: Timer fired on eth1 Oct 28 21:13:51 edge01 bird6: radv1: Sending RA via eth1 Oct 28 21:14:00 edge01 bird6: device1: Scanning interfaces Oct 28 21:14:00 edge01 bird6: rip1: Broadcasting routing table to eth0 Oct 28 21:14:00 edge01 bird6: rip1: Broadcasting routing table to eth1 Oct 28 21:14:00 edge01 bird6: kernel1: Scanning routing table Oct 28 21:14:00 edge01 bird6: kernel1: ::/0: [alien] seen Oct 28 21:14:00 edge01 bird6: kernel1: Pruning table master Oct 28 21:14:00 edge01 bird6: kernel1: Pruning inherited routes Oct 28 21:14:06 edge01 bird6: radv1: Timer fired on eth1 Oct 28 21:14:06 edge01 bird6: radv1: Sending RA via eth1 ---8<--- This is where the startup sequence is over, the last few lines repeat in a ten second interval (obviously, since this is configured in protocols "device" and "kernel" ... The configuration now looks like this: ---8<--- # bird.conf # # dynamic routing configuration # # v0.1 2011-10-21 GS (goesta@smekal.at) # global parameters log syslog all; debug protocols all; #debug protocols { routes, events, packets }; router id 192.168.0.34; ## routing protocols # device parameters protocol device { scan time 10; primary "eth0" 2001:aaaa:bbbb:ccb8::1:1:1; primary "eth1" 2001:aaaa:bbbb:ccee::1:1:1; } protocol direct{ interface "*"; } # kernel routing table protocol kernel { scan time 10; persist no; learn yes; import all; export all; } # router advertisements protocol radv { interface "eth1"; } #protocol static{ # export all; # route 2001:aaaa:bbbb:ccee::/64 via "eth1"; # route ::/0 via 2001:aaaa:bbbb:ccb8:20c:29ff:fe04:48bc; #} # dynamic routing using RIPng protocol rip{ authentication none; password "verysecure"; honor always; import all; export all; interface "eth*"; } ---8<--- As you can see, I also fiddled around with static routes, which did no good either. There must be something missing somewhere, but I cannot figure it out ... Can anybody help? 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));}
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. Suggestion: copy an array of four zeroed integers into rif->sock->saddr instead and see if that works for you. Watch your syslog. Can you see any suspicious messages from bird? If that works, make sure multiple rip protocol instances on the same host but different interfaces still work. Cheers, Roman On 29/10/11 06:31, Goesta Smekal wrote:
Dear list,
looking for a small routing daemon for dynamic IPv6 routing on embedded devices, I came across bird recently. Looks pretty much like what I need, but I must have missed something ...
The goal is to have two tiny routers, linked to a shared LAN segment (at eth0 in my test). Each router advertises an IPv6 prefix to a local network (wireless in the end, just another ethernet segment on eth1 so far). Nodes on the separate networks should be able to talk to each other via the two routers. And if a third router (ore some more) joins in, the new segment(s) should automatically appear in the routers routing tables - dynamic routing ;-)
I compiled bird 1.3.4 from the sources on two test hosts (Debian GNU/Linux - not the embedded stuff yet) using the commands:
root@edge01:/usr/src/bird-1.3.4# ./configure --prefix=/usr/local --enable-ipv6 --with-protocols=static,radv,rip root@edge01:/usr/src/bird-1.3.4# make all && make install
My first config looked like this:
---8<--- # bird.conf # # dynamic routing configuration # # v0.1 2011-10-21 GS (goesta@smekal.at)
# global parameters
log syslog all; debug protocols { routes, events, packets };
router id 192.168.0.34;
## routing protocols
# device parameters protocol device { scan time 10; }
# kernel routing table protocol kernel { scan time 10; persist yes; learn yes; import all; export all; }
# router advertisements protocol radv { interface "eth1"; }
# dynamic routing using RIPng protocol rip{ authentication md5; password "verysecure"; honor neighbor; interface "eth*"; } ---8<---
Bird started fine on both nodes (obviously the router id was different, but the password was the same) but the routes did not appear on the other router. Router advertisements work fine.
After some re-thinking and re-reading the docs I tried to add 'primary' statements to the "protocol device" section, and played with authentication and other rip specific parameters.
Eventually I captured RIPng (UDP port 520) packets on the network with empty routes and after adding this:
---8<--- protocol direct{ interface "*"; } ---8<---
the packets contain the two prefixes, LAN and local subnet, I expect the routers to exchange. However the routes do not show up and wireshark mentions "Unknown address family 8193" in the packet details section of the RIPng packets.
Here is what syslog says:
---8<--- Oct 28 21:13:50 edge01 bird6: device1: Initializing Oct 28 21:13:50 edge01 bird6: direct1: Initializing Oct 28 21:13:50 edge01 bird6: kernel1: Initializing Oct 28 21:13:50 edge01 bird6: radv1: Initializing Oct 28 21:13:50 edge01 bird6: rip1: Initializing Oct 28 21:13:50 edge01 bird6: device1: Starting Oct 28 21:13:50 edge01 bird6: device1: Scanning interfaces Oct 28 21:13:50 edge01 bird6: device1: State changed to feed Oct 28 21:13:50 edge01 bird6: direct1: Starting Oct 28 21:13:50 edge01 bird6: direct1: State changed to feed Oct 28 21:13:50 edge01 bird6: kernel1: Starting Oct 28 21:13:50 edge01 bird6: kernel1: State changed to feed Oct 28 21:13:50 edge01 bird6: radv1: Starting Oct 28 21:13:50 edge01 bird6: radv1: State changed to feed Oct 28 21:13:50 edge01 bird6: rip1: Starting Oct 28 21:13:50 edge01 bird6: rip1: Listening on (dummy), port 520, mode broadcast (::) Oct 28 21:13:50 edge01 bird6: rip1: State changed to feed Oct 28 21:13:50 edge01 bird6: Started Oct 28 21:13:50 edge01 bird6: device1: State changed to up Oct 28 21:13:50 edge01 bird6: direct1 < primary address ::1/128 on interface lo added Oct 28 21:13:50 edge01 bird6: direct1 < primary address 2001:aaaa:bbbb:ccb8::/64 on interface eth0 added Oct 28 21:13:50 edge01 bird6: direct1 > added [best] 2001:aaaa:bbbb:ccb8::/64 dev eth0 Oct 28 21:13:50 edge01 bird6: direct1 < secondary address fe80::/64 on interface eth0 added Oct 28 21:13:50 edge01 bird6: direct1 < primary address 2001:aaaa:bbbb:ccee::/64 on interface eth1 added Oct 28 21:13:50 edge01 bird6: direct1 > added [best] 2001:aaaa:bbbb:ccee::/64 dev eth1 Oct 28 21:13:50 edge01 bird6: direct1 < secondary address fe80::/64 on interface eth1 added Oct 28 21:13:50 edge01 bird6: direct1: State changed to up Oct 28 21:13:50 edge01 bird6: kernel1: Connected to table master Oct 28 21:13:50 edge01 bird6: kernel1 < rejected by protocol 2001:aaaa:bbbb:ccee::/64 dev eth1 Oct 28 21:13:50 edge01 bird6: kernel1 < rejected by protocol 2001:aaaa:bbbb:ccb8::/64 dev eth0 Oct 28 21:13:50 edge01 bird6: kernel1: State changed to up Oct 28 21:13:50 edge01 bird6: radv1 < interface lo goes up Oct 28 21:13:50 edge01 bird6: radv1 < primary address ::1/128 on interface lo added Oct 28 21:13:50 edge01 bird6: radv1 < interface eth0 goes up Oct 28 21:13:50 edge01 bird6: radv1 < primary address 2001:aaaa:bbbb:ccb8::/64 on interface eth0 added Oct 28 21:13:50 edge01 bird6: radv1 < secondary address fe80::/64 on interface eth0 added Oct 28 21:13:50 edge01 bird6: radv1 < interface eth1 goes up Oct 28 21:13:50 edge01 bird6: radv1: Adding interface eth1 Oct 28 21:13:50 edge01 bird6: radv1 < primary address 2001:aaaa:bbbb:ccee::/64 on interface eth1 added Oct 28 21:13:50 edge01 bird6: radv1 < secondary address fe80::/64 on interface eth1 added Oct 28 21:13:50 edge01 bird6: radv1: State changed to up Oct 28 21:13:50 edge01 bird6: rip1: Connected to table master Oct 28 21:13:50 edge01 bird6: rip1 < interface lo goes up Oct 28 21:13:50 edge01 bird6: rip1 < interface eth0 goes up Oct 28 21:13:50 edge01 bird6: rip1 < interface eth1 goes up Oct 28 21:13:50 edge01 bird6: rip1 < added 2001:aaaa:bbbb:ccee::/64 dev eth1 Oct 28 21:13:50 edge01 bird6: rip1 < added 2001:aaaa:bbbb:ccb8::/64 dev eth0 Oct 28 21:13:50 edge01 bird6: rip1: State changed to up Oct 28 21:13:50 edge01 bird6: kernel1: Scanning routing table Oct 28 21:13:50 edge01 bird6: kernel1: ::/0: [alien] created Oct 28 21:13:50 edge01 bird6: kernel1: Pruning table master Oct 28 21:13:50 edge01 bird6: kernel1: Pruning inherited routes Oct 28 21:13:51 edge01 bird6: kernel1 > added [best] ::/0 via fe80::20c:29ff:fe04:48bc on eth0 Oct 28 21:13:51 edge01 bird6: kernel1 < rejected by protocol ::/0 via fe80::20c:29ff:fe04:48bc on eth0 Oct 28 21:13:51 edge01 bird6: rip1 < added ::/0 via fe80::20c:29ff:fe04:48bc on eth0 Oct 28 21:13:51 edge01 bird6: rip1: Listening on eth1, port 520, mode multicast (ff02::9) Oct 28 21:13:51 edge01 bird6: rip1: Listening on eth0, port 520, mode multicast (ff02::9) Oct 28 21:13:51 edge01 bird6: radv1: Event Init on eth1 Oct 28 21:13:51 edge01 bird6: radv1: Timer fired on eth1 Oct 28 21:13:51 edge01 bird6: radv1: Sending RA via eth1 Oct 28 21:14:00 edge01 bird6: device1: Scanning interfaces Oct 28 21:14:00 edge01 bird6: rip1: Broadcasting routing table to eth0 Oct 28 21:14:00 edge01 bird6: rip1: Broadcasting routing table to eth1 Oct 28 21:14:00 edge01 bird6: kernel1: Scanning routing table Oct 28 21:14:00 edge01 bird6: kernel1: ::/0: [alien] seen Oct 28 21:14:00 edge01 bird6: kernel1: Pruning table master Oct 28 21:14:00 edge01 bird6: kernel1: Pruning inherited routes Oct 28 21:14:06 edge01 bird6: radv1: Timer fired on eth1 Oct 28 21:14:06 edge01 bird6: radv1: Sending RA via eth1 ---8<---
This is where the startup sequence is over, the last few lines repeat in a ten second interval (obviously, since this is configured in protocols "device" and "kernel" ...
The configuration now looks like this:
---8<--- # bird.conf # # dynamic routing configuration # # v0.1 2011-10-21 GS (goesta@smekal.at)
# global parameters
log syslog all; debug protocols all; #debug protocols { routes, events, packets };
router id 192.168.0.34;
## routing protocols
# device parameters protocol device { scan time 10; primary "eth0" 2001:aaaa:bbbb:ccb8::1:1:1; primary "eth1" 2001:aaaa:bbbb:ccee::1:1:1; }
protocol direct{ interface "*"; }
# kernel routing table protocol kernel { scan time 10; persist no; learn yes; import all; export all; }
# router advertisements protocol radv { interface "eth1"; }
#protocol static{ # export all; # route 2001:aaaa:bbbb:ccee::/64 via "eth1"; # route ::/0 via 2001:aaaa:bbbb:ccb8:20c:29ff:fe04:48bc; #}
# dynamic routing using RIPng protocol rip{ authentication none; password "verysecure"; honor always; import all; export all; interface "eth*"; } ---8<---
As you can see, I also fiddled around with static routes, which did no good either.
There must be something missing somewhere, but I cannot figure it out ... Can anybody help?
thanks in advance,
Goesta
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));}
On 1.11.2011 17:49, Goesta Smekal wrote:
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 ;-)
Hi Goesta, If must sadly confirm, the RIP implementation is quite poor. The reason we are not working on it was that nobody really uses this protocol. Should somebody demand it, we could look at it. But currently we are concentrated on other issues. Do you need it for some production environment? Ondrej
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
Am 2011-11-01 17:57, schrieb Ondrej Filip:
If must sadly confirm, the RIP implementation is quite poor. The reason we are not working on it was that nobody really uses this protocol. Should somebody demand it, we could look at it. But currently we are concentrated on other issues. Do you need it for some production environment?
Yes, I do intend to use RIPng for dynamic routing on embedded devices. Limitations in terms of very little memory (both RAM and flash) and the short range of expected routes make RIP the ideal protocol for this project. IPv6 is mandatory, since the nodes will interconnect 6LoWPAN segments. As I already stated, I am willing to help as much as I can. I will try to find the lines in the source, where modifications have to be made, but I am sure, there are lots of people, who can do this faster and more reliable ;-) I don't think there are too many changes to be made. The most obvious should be quite easily implemented: *) change UDP port to 521 *) change RIP version to 1 *) omit the empty RTE (since the default next hop is the sending host anyway) *) when writing the route to the local table, use the senders link local address instead of some tailored global unicast. If this is done, I can do extended tests to see if it works. Maybe I get some other RIPng implementation to test against (hopefully not the striped one, which I find pretty hard to configure ;-) ) cheers 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));}
On Tue, Nov 01, 2011 at 05:49:42PM +0100, Goesta Smekal wrote:
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 ;-)
You are right, after Roman Hoog Antink sent his patches for RIP, i also checked RIPng if it is possible to do some quick fix and found that is is broken beyond any repair and probably really never worked (at least as specified by RFC). Rewrite of RIP is one of my long term plans, but had a low priority because of its minimal usage. It would be not so hard (as RIP is pretty simple protocol and most research and thinking about it i already did), probably worth the effort just to not bother my mind any more :-). -- Elen sila lumenn' omentielvo Ondrej 'SanTiago' Zajicek (email: santiago@crfreenet.org) OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net) "To err is human -- to blame it on a computer is even more so."
Hi Ondrej In the meantime please apply my second RIP patch which fixes the same socket issue for IPv6 as did my last patch for IPv4. See attachment. The two patches mentioned by Goesta earlier in this thread are my already applied IPv4 patch and this one. Cheers, Roman On 02/11/11 06:36, Ondrej Zajicek wrote:
You are right, after Roman Hoog Antink sent his patches for RIP, i also checked RIPng if it is possible to do some quick fix and found that is is broken beyond any repair and probably really never worked (at least as specified by RFC).
Rewrite of RIP is one of my long term plans, but had a low priority because of its minimal usage. It would be not so hard (as RIP is pretty simple protocol and most research and thinking about it i already did), probably worth the effort just to not bother my mind any more :-).
participants (4)
-
Goesta Smekal -
Ondrej Filip -
Ondrej Zajicek -
Roman Hoog Antink