IPv6 rip-only routing - no exchange of routes

[Goesta Smekal]

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/14a8f396e1d8fc5787041eace8ab026fe5a0896c
>
>  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));}

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20111101/6f6b7a31/attachment.asc>