RIPng advertisement hop count 1 (should be 255 per RFC)

[Simon Dickhoven]

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 at 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~bpo60+1.diff.gz
>>
>> 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
>>>
>
>


Confidentiality Notice:  The information contained in this electronic e-mail and any accompanying attachment(s) is intended only for the use of the intended recipient and is confidential and/or privileged. If you and we have a confidentiality agreement or other non-disclosure obligations between us, this Notice shall be deemed to mark and identify the content of this email and any attachments as confidential and proprietary.   If any reader of this communication is not the intended recipient, unauthorized use, disclosure or copying is strictly prohibited, and may be unlawful.  If you have received this communication in error, please immediately notify the sender by return e-mail, and delete the original message and all copies from your system.  Thank you.

IRS Circular 230 Disclosure: To ensure compliance with requirements imposed by the IRS, please be advised that any U.S. federal tax advice contained in this communication (including any attachments) is not intended or written to be used or relied upon, and cannot be used or relied upon, for the purpose of (i) avoiding penalties under the Internal Revenue Code, or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein.

E-mail is susceptible to data corruption, interception, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.