Ignoring bogus route 240.0.0.0/4
Hi, Any reason why 240.0.0.0/4+ routes are ignored by bird (1.6.3)? I have tried to blackhole this range in static protocol, but got this message. Attempts to manually add any kernel route from this range were silently ignored. -- With best regards, Alexander.
On mar. 19 sept. 22:32:34 2017, Alexander Demenshin wrote:
Hi,
Any reason why 240.0.0.0/4+ routes are ignored by bird (1.6.3)?
I have tried to blackhole this range in static protocol, but got this message.
Attempts to manually add any kernel route from this range were silently ignored.
Hi, Because this range is not aimed to be routed or added to any host, cf. https://tools.ietf.org/html/rfc1112 section 4. You need to be part of a multicast group to use those addresses, as said in https://en.wikipedia.org/wiki/IP_multicast#Routing -- alarig
On 2017-09-20 00:12, Alarig Le Lay wrote:
Because this range is not aimed to be routed or added to any host, cf. https://tools.ietf.org/html/rfc1112 section 4.
Section 4 defines only 224.0.0.0/4 (multicast), but in my case it is 240.0.0.0/4 Though this space is "reserved for future addressing modes", I see no reason why it is "bogus", especially when routers perfectly accept them. Hardcoding anything that is not loopback is bad idea, IMHO. Best regards, Alexander.
Though this space is "reserved for future addressing modes", I see no reason
why it is "bogus", especially when routers perfectly accept them.
I'd say their behaviour is undefined--do routers just use them like unicast addresses? Reserved for future use is still the status according to IANA: https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml
Hardcoding anything that is not loopback is bad idea, IMHO.
There are lists and documents about special-purpose IPv4 addresses. In fact, the IANA keeps a list of them: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia... I'd say BIRD should generally follow RFCs and object to using addresses contrary to their standard meaning. Calling 240.0.0.0/4 "bogus" is too strong. "Undefined" would be a better, and probably as a (strong) warning. Cheers, -- Jonathan
On 2017-09-20 01:12, Jonathan Stewart wrote:
I'd say their behaviour is undefined--do routers just use them like unicast addresses?
Exactly - at least cisco & linux (the primary reason why I wanted to blackhole it).
There are lists and documents about special-purpose IPv4 addresses. In fact, the IANA keeps a list of them: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-specia... [2]
If everything that is marked as "non-forwardable" is "bogus", then handling is inconsistent, as networks like 198.51.100.0/24 ("documentation" and "forwardable=false") is perfectly accepted.
I'd say BIRD should generally follow RFCs and object to using addresses contrary to their standard meaning.
"Reserved" has no "standard meaning" - it may change any time, that's why I believe that hardcoding is bad idea. Not that this issue makes me cry, but anyway :) Best regards, Alexander.
On Tue, Sep 19, 2017 at 10:32:34PM +0200, Alexander Demenshin wrote:
Hi,
Any reason why 240.0.0.0/4+ routes are ignored by bird (1.6.3)?
Hi I do not know why it was implemented in BIRD originally in such way and i had to need to question that, so it stayed is it was. If Linux and BSD kernels does accept such routes, than it is a strong reason to support that in BIRD, even if only for purpose of defining blackhole static route. While i agree that hardcoding administrative assignments is a bad idea, i would see a case for special handling of 240.0.0.0/4 in contrast to other 'special' ranges. While other ranges were later administratively reassigned from regular uncast forwarding range, 240.0.0.0/4 was reserved for future since deep past, and therefore it is possible that it could be handled in some completely different way in the future (like 224.0.0.0/4 is handled by FIBs differently than unicast). If you just handle it like regular unicast and it is later defined as something completely different, you cannot implement that without breaking backward compatibility. So it seems strange to me that FIBs like Linux kernel does handle it regularly (never tried that), but perhaps they expect that now it will never be reassigned. -- 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."
On 2017-09-20 15:06, Ondrej Zajicek wrote:
If Linux and BSD kernels does accept such routes, than it is a strong reason to support that in BIRD, even if only for purpose of defining blackhole static route.
I could not say about BSD, but in Linux this is definitely possible (I have tried it - just to make sure).
So it seems strange to me that FIBs like Linux kernel does handle it regularly (never tried that), but perhaps they expect that now it will never be reassigned.
Well, the reason is (probably) that Linux gives you a lot of freedom and it is up to you how to do things - apart from few things nothing is hardcoded and nearly everything is tunable (it even allows you to break some RFCs). This is good as there are some cases when (re)compilation is not possible nor feasible (ROM-based embedded systems, for instance), and sometimes you have to deal with systems that are not under your control. I would simply include a (run-time) configuration switch to enforce some rules or to avoid them. Not a high priority task, of course, but it might make sense some day... But at the very least, the message itself should be a bit more informative :) Best regards, Alexander.
participants (4)
-
Alarig Le Lay -
Alexander Demenshin -
Jonathan Stewart -
Ondrej Zajicek