IPv6 rip-only routing - no exchange of routes

[Ondrej Filip]

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/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 ;-)

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
>