[PATCH] Don't treat 0/8 and 240/4 specially in IPv4 classification
With the exception of 0.0.0.0 and 255.255.255.255, which have additional special meanings, treat 0/8 and 240/4 as normal unicast addresses by default. This is because some people are experimenting with using these addresses as regular unicast (either for private addresses or for potential future public addresses). On the public Internet, they would still currently be regarded as bogons and one could make (maybe by default) a bogon-filtering rule in bird.conf that would not permit these addresses to be routed, e.g. with a pair of static routes route 0.0.0.0/8 prohibit; route 240.0.0.0/4 prohibit; or simply route 0.0.0.0/8 blackhole; route 240.0.0.0/4 blackhole; Dave Taht, who wrote a prior version of this patch, suggested that in any case it is better to have bogons defined in a configuration file than hard-coded in software. --- lib/ip.c | 7 +++++-- lib/ip.h | 2 +- 2 files changed, 6 insertions(+), 3 deletions(-) diff --git a/lib/ip.c b/lib/ip.c index 4c5fa47f..e13bbce0 100644 --- a/lib/ip.c +++ b/lib/ip.c @@ -87,8 +87,10 @@ ip4_classify(ip4_addr ad) if (b < 0xe0) { - if (b == 0x00) /* 0.0.0.0/8 This network */ + if (a == 0x00000000) /* 0.0.0.0/32 Unset address */ return IADDR_INVALID; + /* 0.0.0.0/8 is otherwise reserved, but + * some people are using it or trying to */ if (b == 0x7f) /* 127.0.0.0/8 Loopback address */ return IADDR_HOST | SCOPE_HOST; @@ -107,7 +109,8 @@ ip4_classify(ip4_addr ad) if (a == 0xffffffff) /* 255.255.255.255 Broadcast address */ return IADDR_BROADCAST | SCOPE_LINK; - return IADDR_HOST | SCOPE_SITE; /* 240.0.0.0/4 Reserved / private */ + return IADDR_HOST | SCOPE_UNIVERSE; /* 240.0.0.0/4 Reserved / private, but + * some people are using it or trying to */ } int diff --git a/lib/ip.h b/lib/ip.h index 9eef2e16..875b9f5e 100644 --- a/lib/ip.h +++ b/lib/ip.h @@ -245,7 +245,7 @@ static inline int ip6_is_v4mapped(ip6_addr a) #define ipa_is_link_local(x) ip6_is_link_local(x) static inline int ip4_is_unicast(ip4_addr a) -{ return _I(a) < 0xe0000000; } +{ return _I(a) < 0xe0000000 || (_I(a) >= 0xf0000000 && _I(a) != 0xffffffff); } /* XXXX remove */ static inline int ipa_classify_net(ip_addr a) -- 2.25.1
With respect to (for example) RFC 8212, such features should have reverse logic - default behavior should be blocking that, but there might be configuration option to change default prefix clasification explicitly, if needed for any reason... In such cases, mind is changing. And it's more secure to have strict defaults here... Your patch doesn't care about security here... For example - Junos has for these special cases different behavior ( routing-options martians x.x.x.x/y allow ). Such way of handling of special prefixes should be generally preffered... - Daniel On 11/19/22 00:38, Seth David Schoen via Bird-users wrote:
With the exception of 0.0.0.0 and 255.255.255.255, which have additional special meanings, treat 0/8 and 240/4 as normal unicast addresses by default. This is because some people are experimenting with using these addresses as regular unicast (either for private addresses or for potential future public addresses).
On the public Internet, they would still currently be regarded as bogons and one could make (maybe by default) a bogon-filtering rule in bird.conf that would not permit these addresses to be routed, e.g. with a pair of static routes
route 0.0.0.0/8 prohibit; route 240.0.0.0/4 prohibit;
or simply
route 0.0.0.0/8 blackhole; route 240.0.0.0/4 blackhole;
Dave Taht, who wrote a prior version of this patch, suggested that in any case it is better to have bogons defined in a configuration file than hard-coded in software. --- lib/ip.c | 7 +++++-- lib/ip.h | 2 +- 2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/lib/ip.c b/lib/ip.c index 4c5fa47f..e13bbce0 100644 --- a/lib/ip.c +++ b/lib/ip.c @@ -87,8 +87,10 @@ ip4_classify(ip4_addr ad)
if (b < 0xe0) { - if (b == 0x00) /* 0.0.0.0/8 This network */ + if (a == 0x00000000) /* 0.0.0.0/32 Unset address */ return IADDR_INVALID; + /* 0.0.0.0/8 is otherwise reserved, but + * some people are using it or trying to */
if (b == 0x7f) /* 127.0.0.0/8 Loopback address */ return IADDR_HOST | SCOPE_HOST; @@ -107,7 +109,8 @@ ip4_classify(ip4_addr ad) if (a == 0xffffffff) /* 255.255.255.255 Broadcast address */ return IADDR_BROADCAST | SCOPE_LINK;
- return IADDR_HOST | SCOPE_SITE; /* 240.0.0.0/4 Reserved / private */ + return IADDR_HOST | SCOPE_UNIVERSE; /* 240.0.0.0/4 Reserved / private, but + * some people are using it or trying to */ }
int diff --git a/lib/ip.h b/lib/ip.h index 9eef2e16..875b9f5e 100644 --- a/lib/ip.h +++ b/lib/ip.h @@ -245,7 +245,7 @@ static inline int ip6_is_v4mapped(ip6_addr a) #define ipa_is_link_local(x) ip6_is_link_local(x)
static inline int ip4_is_unicast(ip4_addr a) -{ return _I(a) < 0xe0000000; } +{ return _I(a) < 0xe0000000 || (_I(a) >= 0xf0000000 && _I(a) != 0xffffffff); }
/* XXXX remove */ static inline int ipa_classify_net(ip_addr a)
Hi, So, I've been continuing to work on possibilities for this and I see three main approaches. I was wondering what the developers and users think of these options. (1) Don't hard-code the special treatment of 0/8 and 240/4 (like my original patch), but also include a default like route 0.0.0.0/8 prohibit; route 240.0.0.0/4 prohibit; in the sample bird.conf (and maybe in the documentation too). (2) Add a new configuration directive available in bird.conf like "unbogon" or "unicast" or something similar, which takes a netblock as an argument and instructs BIRD not to reject that specific netblock (or its subnets). Like one might then say something like unbogon 0.0.0.0/8; unbogon 240.0.0.0/4; (3) Add a new configuration directive with no arguments that is disabled by default, but, when encountered, disables the behavior of rejecting any IPv4 blocks as bogons. (However, netblocks could still be individually prohibited with additional configuration like in option 1.) In a kernel TCP/IP implementation I would imagine options like 2 and 3 could pose efficiency concerns because they would add more tests to the critical path for routing decisions. But in BIRD's case this is probably not relevant because tests for address range validity do not need to be repeated extremely often. I have a patch for option 1 already, but I've also been looking at the configuration parser and could complete a patch for options 2 or 3 if either of these would be preferable. To be clear about the reason for suggesting this, we've been proposing changes at IETF that would eventually eliminate the special treatment of these ranges in Internet standards. We would like to demonstrate that this is technically feasible and conduct tests in the future to understand the extent to which historically reserved address can or can't be used on the Internet. Apart from that, several large networks are already known to be making unofficial internal use of subnets of 240/4 as private address space. (If any of those networks are using BIRD, they've most likely patched it themselves.) Most TCP/IP implementations (except Microsoft Windows) have already done something similar to option 1 above, while several commercial infrastructure-oriented routers have done something similar to option 2 (I speculate at the request of customers who use 240/4 unofficially).
Hello! TL;DR: 240/4 is already allowed, allowing 0/8 is not tested. Long version: I have several reasons why to reject this patch: (1) Everybody who is in need of bigger address space should have already migrated to IPv6. I see no good reason to continue the legacy IP agony with proposals like this. This point is first on purpose. (2) BIRD already treats 240/4 the same way as 10/8. We can't simply enable 0/8 as it may be used or checked internally in some protocols and its use is not safe without thorough assessment and testing. (3) Even if you managed to make 240/4 public and assigned, it would postpone the legacy IP address crisis just by months. Migration to IPv6 is inevitable. There are good technical reasons to keep legacy IP classifications, and even reclassifying 240/4 as site-local was essentially a bad compromise itself. I regret changing the default behavior in such a way that less vigilant operators may let unassigned 240/4 through BGP on the public internet. It's just a security hole itself. If there is any problem or missing feature in BIRD in IPv6 routing, fixing or reporting that is the way to go. Thank you for your understanding. Maria On 21 December 2022 06:13:40 CET, Seth David Schoen via Bird-users <bird-users@trubka.network.cz> wrote:
Hi,
So, I've been continuing to work on possibilities for this and I see three main approaches. I was wondering what the developers and users think of these options.
(1) Don't hard-code the special treatment of 0/8 and 240/4 (like my original patch), but also include a default like
route 0.0.0.0/8 prohibit; route 240.0.0.0/4 prohibit;
in the sample bird.conf (and maybe in the documentation too).
(2) Add a new configuration directive available in bird.conf like "unbogon" or "unicast" or something similar, which takes a netblock as an argument and instructs BIRD not to reject that specific netblock (or its subnets). Like one might then say something like
unbogon 0.0.0.0/8; unbogon 240.0.0.0/4;
(3) Add a new configuration directive with no arguments that is disabled by default, but, when encountered, disables the behavior of rejecting any IPv4 blocks as bogons. (However, netblocks could still be individually prohibited with additional configuration like in option 1.)
In a kernel TCP/IP implementation I would imagine options like 2 and 3 could pose efficiency concerns because they would add more tests to the critical path for routing decisions. But in BIRD's case this is probably not relevant because tests for address range validity do not need to be repeated extremely often.
I have a patch for option 1 already, but I've also been looking at the configuration parser and could complete a patch for options 2 or 3 if either of these would be preferable.
To be clear about the reason for suggesting this, we've been proposing changes at IETF that would eventually eliminate the special treatment of these ranges in Internet standards. We would like to demonstrate that this is technically feasible and conduct tests in the future to understand the extent to which historically reserved address can or can't be used on the Internet. Apart from that, several large networks are already known to be making unofficial internal use of subnets of 240/4 as private address space. (If any of those networks are using BIRD, they've most likely patched it themselves.)
Most TCP/IP implementations (except Microsoft Windows) have already done something similar to option 1 above, while several commercial infrastructure-oriented routers have done something similar to option 2 (I speculate at the request of customers who use 240/4 unofficially).
Hello Maria, [off list] I love your answer! Finally a clear statement on that re-classification mess. Next time we meet, remind me to buy you a drink of your choice! Thanks a lot for this, I fully support & agree with your statements. Best regards, Nico Maria Matejka via Bird-users <bird-users@trubka.network.cz> writes:
Hello!
TL;DR: 240/4 is already allowed, allowing 0/8 is not tested.
Long version:
I have several reasons why to reject this patch:
(1) Everybody who is in need of bigger address space should have already migrated to IPv6. I see no good reason to continue the legacy IP agony with proposals like this. This point is first on purpose.
(2) BIRD already treats 240/4 the same way as 10/8. We can't simply enable 0/8 as it may be used or checked internally in some protocols and its use is not safe without thorough assessment and testing.
(3) Even if you managed to make 240/4 public and assigned, it would postpone the legacy IP address crisis just by months. Migration to IPv6 is inevitable.
There are good technical reasons to keep legacy IP classifications, and even reclassifying 240/4 as site-local was essentially a bad compromise itself. I regret changing the default behavior in such a way that less vigilant operators may let unassigned 240/4 through BGP on the public internet. It's just a security hole itself.
If there is any problem or missing feature in BIRD in IPv6 routing, fixing or reporting that is the way to go.
Thank you for your understanding.
Maria
On 21 December 2022 06:13:40 CET, Seth David Schoen via Bird-users <bird-users@trubka.network.cz> wrote:
Hi,
So, I've been continuing to work on possibilities for this and I see three main approaches. I was wondering what the developers and users think of these options.
(1) Don't hard-code the special treatment of 0/8 and 240/4 (like my original patch), but also include a default like
route 0.0.0.0/8 prohibit; route 240.0.0.0/4 prohibit;
in the sample bird.conf (and maybe in the documentation too).
(2) Add a new configuration directive available in bird.conf like "unbogon" or "unicast" or something similar, which takes a netblock as an argument and instructs BIRD not to reject that specific netblock (or its subnets). Like one might then say something like
unbogon 0.0.0.0/8; unbogon 240.0.0.0/4;
(3) Add a new configuration directive with no arguments that is disabled by default, but, when encountered, disables the behavior of rejecting any IPv4 blocks as bogons. (However, netblocks could still be individually prohibited with additional configuration like in option 1.)
In a kernel TCP/IP implementation I would imagine options like 2 and 3 could pose efficiency concerns because they would add more tests to the critical path for routing decisions. But in BIRD's case this is probably not relevant because tests for address range validity do not need to be repeated extremely often.
I have a patch for option 1 already, but I've also been looking at the configuration parser and could complete a patch for options 2 or 3 if either of these would be preferable.
To be clear about the reason for suggesting this, we've been proposing changes at IETF that would eventually eliminate the special treatment of these ranges in Internet standards. We would like to demonstrate that this is technically feasible and conduct tests in the future to understand the extent to which historically reserved address can or can't be used on the Internet. Apart from that, several large networks are already known to be making unofficial internal use of subnets of 240/4 as private address space. (If any of those networks are using BIRD, they've most likely patched it themselves.)
Most TCP/IP implementations (except Microsoft Windows) have already done something similar to option 1 above, while several commercial infrastructure-oriented routers have done something similar to option 2 (I speculate at the request of customers who use 240/4 unofficially).
-- Sustainable and modern Infrastructures by ungleich.ch
Maria Matejka writes:
Hello!
Hi Maria!
I have several reasons why to reject this patch:
(1) Everybody who is in need of bigger address space should have already migrated to IPv6. I see no good reason to continue the legacy IP agony with proposals like this. This point is first on purpose.
(2) BIRD already treats 240/4 the same way as 10/8. We can't simply enable 0/8 as it may be used or checked internally in some protocols and its use is not safe without thorough assessment and testing.
(3) Even if you managed to make 240/4 public and assigned, it would postpone the legacy IP address crisis just by months. Migration to IPv6 is inevitable.
There are good technical reasons to keep legacy IP classifications, and even reclassifying 240/4 as site-local was essentially a bad compromise itself. I regret changing the default behavior in such a way that less vigilant operators may let unassigned 240/4 through BGP on the public internet. It's just a security hole itself.
If there is any problem or missing feature in BIRD in IPv6 routing, fixing or reporting that is the way to go.
Thank you for your understanding.
My own TL;DR: We don't have evidence of any harm from uses of 0/8, and it makes sense in general to have bogons/Martians be configurable rather than hard-coded, so different users have as much flexibility as possible to use routing daemons for their own purposes. First, with regard to the 0/8 vs. 240/4 distinction: it's true that there may be systems or protocols that have a special meaning for 0/8 addresses. We looked at a lot of RFC text and found that typically only 0.0.0.0 has a special meaning in standards, with very few exceptions (for instance in certain SNMP MIBs); the rest of 0/8 doesn't. Of course, there could very well be some software that does assign a special meaning to 0/8 in a way that's not specified or documented by an RFC. If so, we'd very much like to identify and document those, and potentially to try to change those behaviors or our proposals, or both. Both 0/8 and 240/4 (except 0.0.0.0/32 and 255.255.255.255/32) are now treated as ordinary unicast addresses by a very large number of hosts and routers' TCP/IP implementations, typically permitting them to take global address scope. When giving talks about this, I told people that the device they were using to listen to me probably already supported 240/4 as global-scope unicast. (Almost certainly, if it's not running Windows.) Here, similarly, most devices on which people are reading this very message will also accept 240/4, and many will accept 0/8. Of course, these addresses will currently only be assigned as part of an organization's unofficial private use. It might be that the consequences of making this change in routing protocols are different from making the change in hosts. If so, I would also like to understand why. Currently there are things like the https://www.cidr-report.org/as2.0/#Bogons report that identify ASNs that are making announcements for unallocated address space, and I think one concern you're pointing to is that, if more routing protocol implementations are happy to share routes for reserved address space, we might see more bogon routes leaking into routing tables outside of organizations that use those internally. Still, I'd expect that could be handled well now and in the future by having configurable tables of bogon/Martian spaces in devices, which can readily be updated over time, rather than hard-coding them in the software logic. And also by continued coordination within the Internet community (as things like the CIDR Report encourage). Right now I see no route announcements leaking for 240/4 or 0/8 space in the CIDR Report, though maybe they do leak between some ASes and are stopped from propagating further by filters, and maybe some operators have headaches from that. I'm not sure that it's worth having an IPv6-vs.-IPv4 debate here on the list. I strongly encourage everyone to support and deploy IPv6. Going IPv6-only is a challenge for those hosting public Internet sites and services that are trying to address a global audience; without IPv4 addresses, they'd still be unreachable to most Internet users. It may be different in particular countries or regions where IPv6 deployment is already more universal. But globally, most Internet users still lack native IPv6 connectivity, and it would be a huge sacrifice for services to say that they won't serve those users at all. So it's unsurprising that there are still extremely few public Internet services, large or small, old or new, that choose to operate IPv6-only without IPv4 addresses. We anticipate that strong demand for IPv4 addresses will continue for many years, and that it's worth maximizing the available addressing resources from many different angles, even as a long-term project. In the coming year, we hope to be able to do practical testing of reserved addresses over the public Internet in order to better understand the current compatibility situation. For the benefit of flexibility for BIRD users during these tests or in the future, it would be helpful to have fewer hard-coded assumptions about what addresses are or will be valid. It wasn't controversial for the Linux kernel to support unicast use of 240/4 (back in 2010) or of of 0/8 (in 2019). OpenBSD and FreeBSD have supported both of these in 2022. Gobgp release 3.0.0 also supports them. The Internet didn't break; in fact, enabling these ranges went virtually unnoticed. But together they make it likelier that the Internet community will have broader options for IPv4 addressing resources in the future.
Hello! I needa repeat myself.
(1) Everybody who is in need of bigger address space should have already migrated to IPv6. I see no good reason to continue the legacy IP agony with proposals like this. This point is first on purpose.
This point is first on purpose. Extending the life of legacy IP will just harm more people in long-term. Everybody with legacy-only connection can and should use an IPv6 tunnel or other techniques.
(2) BIRD already treats 240/4 the same way as 10/8. We can't simply enable 0/8 as it may be used or checked internally in some protocols and its use is not safe without thorough assessment and testing.
Until 240/4 is officially marked as Internet and available for assignment, there is not only no reason to mark it as Internet in BIRD. You can use it now, BIRD doesn't do any difference between site-local and Internet routes. We should at least reject site-locals in eBGP sessions by default to remedy the fact that we gave way for the previous 240/4-enabling patch without proper assessment of its security implications. And as I'm thinking about it once again, we should probably just revert the 240/4 classification to invalid as it is of better performance than filtering it in filters. BIRD is open-source and everybody involved in the 240/4 technological backwardness may simply build their own binary with the patch applied on their own risk, or stick with 2.0.10-11.
(3) Even if you managed to make 240/4 public and assigned, it would postpone the legacy IP address crisis just by months. Migration to IPv6 is inevitable.
And instead of trying to make 240/4 public, IANA should start retracting any legacy IP block as it gets free, while publishing an official list of deprecated prefixes which should be never seen on the Internet again. (Credits for this idea: https://twitter.com/becomethewaifu/status/1605754063320059904)
My own TL;DR: We don't have evidence of any harm from uses of 0/8, and it makes sense in general to have bogons/Martians be configurable rather than hard-coded, so different users have as much flexibility as possible to use routing daemons for their own purposes.
It makes literally no sense to upstream changes which go against Internet security. If we do it, it is a bug, not a good thing.
First, with regard to the 0/8 vs. 240/4 distinction: it's true that there may be systems or protocols that have a special meaning for 0/8 addresses. We looked at a lot of RFC text and found that typically only 0.0.0.0 has a special meaning in standards, with very few exceptions (for instance in certain SNMP MIBs); the rest of 0/8 doesn't. Of course, there could very well be some software that does assign a special meaning to 0/8 in a way that's not specified or documented by an RFC. If so, we'd very much like to identify and document those, and potentially to try to change those behaviors or our proposals, or both.
Until there is a reasonably complete autotest suite for BIRD, checking that 0/8 does break literally nothing, there is no reason to believe it. BTW there is a SNMP AgentX implementation in progress inside BIRD so thank you for pointing out that we really shouldn't debogonize 0/8 at all.
Both 0/8 and 240/4 (except 0.0.0.0/32 and 255.255.255.255/32) are now treated as ordinary unicast addresses by a very large number of hosts and routers' TCP/IP implementations, typically permitting them to take global address scope. When giving talks about this, I told people that the device they were using to listen to me probably already supported 240/4 as global-scope unicast. (Almost certainly, if it's not running Windows.) Here, similarly, most devices on which people are reading this very message will also accept 240/4, and many will accept 0/8.
Argumentum ad populum.
In the coming year, we hope to be able to do practical testing of reserved addresses over the public Internet in order to better understand the current compatibility situation. For the benefit of flexibility for BIRD users during these tests or in the future, it would be helpful to have fewer hard-coded assumptions about what addresses are or will be valid.
It's a good measure of how much the Internet is incapable of filtering bogons, not a compatibility test at all.
It wasn't controversial for the Linux kernel to support unicast use of 240/4 (back in 2010) or of of 0/8 (in 2019). OpenBSD and FreeBSD have supported both of these in 2022. Gobgp release 3.0.0 also supports them. The Internet didn't break; in fact, enabling these ranges went virtually unnoticed. But together they make it likelier that the Internet community will have broader options for IPv4 addressing resources in the future.
Argumentum ad populum again. Maria
Hello!
Until 240/4 is officially marked as Internet and available for assignment, there is not only no reason to mark it as Internet in BIRD. You can use it now, BIRD doesn't do any difference between site-local and Internet routes. [...]
Speaking as the person who likely introduced the IP address classification scheme in BIRD years ago... :-) I no longer think I have chosen wisely. Policy should be matter of configuration, not hard-wired inside the code. Usability of 240/4 in various situations is just matter of policy, I am not aware of any bit of Internet standards which would proscribe its use. So it should be configurable. On the other hand, the configuration should default to the safest choice, which is rejecting these addresses. This way, we both contribute to Internet reliability/security, and allow people to experiment and burn their fingers as they wish. --- 0/8 is a slightly different story, but I am still in favor of making things configurable instead of rejecting them unconditionally without a convincing reason. Also, I do not believe in our choice contributing to (non-)adoption of IPv6 in any measurable way. It might contribute to (non-)adoption of BIRD, though :) Have a nice fortnight -- Martin `MJ' Mareš <mj@ucw.cz> http://mj.ucw.cz/ United Computer Wizards, Prague, Czech Republic, Europe, Earth, Universe "In theory, practice and theory are the same, but in practice they are different." -- Larry McVoy
Hey everyone, Martin Mareš via Bird-users <bird-users@trubka.network.cz> writes: [...]
Also, I do not believe in our choice contributing to (non-)adoption of IPv6 in any measurable way. It might contribute to (non-)adoption of BIRD, though :)
from my perspective the time to prolong the IPv4 usage is over. We are over it. IPv6 has surpassed 50% utilisation in many countries and if anyone is in a region or situation that needs help in regards to IPv6 deployment, the community is there to help. Wasting more time on a dead horse is, IMNSHO, a waste of everyone's time. Bird is a great software and supports small and big deployments, for free for most of us. That means we should focus on the sustainable, long term important features, not on technology that is supposed to be turned off a long time ago. Routing IPv4 via IPv6? Ok, fair enough, as a transition. Adding MORE time for IPv4 by quirking and hacking? No, thanks. For a cleaner, healthier, easier and more sustainable future I ask everyone to concentrate on switching over to IPv6 instead of feeding the IPv4 zombie, it has eaten enough resources and (not literally) brains. In that sense: thanks everyone for this great piece of software, I really appreciate configuring and running bird and I wish everyone an as IPv4 free as possible 2023. Best regards, Nico -- Sustainable and modern Infrastructures by ungleich.ch
from my perspective the time to prolong the IPv4 usage is over.
I agree. But that's not what this debate is about. It's about whether it is the role of the authors and maintainers to enforce the desired behaviour (which is what Maria is arguing for), or whether the maintainers should merely provide reasonable defaults but refrain from dictating how the users should use the software (which is Martin's position). It's an interesting debate, and one that most free software projects go through at one point or another. I, for one, have changed my mind on the subject multiple times. -- Juliusz
On 31.12.22 15:45, Juliusz Chroboczek via Bird-users wrote:
from my perspective the time to prolong the IPv4 usage is over.
I agree. [..] [..] I, for one, have changed my mind on the subject multiple times.
Even as I (have to) totally agree with Nico, too; the sad reality as I had to observe it: For some reason some/many people are totally unaware of the possibility of IPv4 transport via IPv6. Be it using MP-BGP or nowadays Babel, too. This should get more "advertisement"/awareness. But on the other hand: I have heard stories of unlucky sysadmins maintaining totally broken/cluttered networks with no clear vision how to enable IPv6, and they never got a proper address planning scheme and they have to live with no more space in RFC1918. These people would benefit of making 240/4 a configurable option. I wish everyone a good fortnight, too, and stay safe! Bernd
Hello! On 12/31/22 16:17, Bernd Naumann via Bird-users wrote:
On 31.12.22 15:45, Juliusz Chroboczek via Bird-users wrote:
from my perspective the time to prolong the IPv4 usage is over.
I agree. [..] [..] I, for one, have changed my mind on the subject multiple times.
To clarify (and maybe amend a little) my position, I shall state this: First of all, there is the previous patch which we reworked and merged, not realizing that if somebody has a policy "accept unless bad", then we are changing their behavior and they start accepting inherently bogon prefixes by upgrading to 2.0.10-11. This wasn't right and we should definitely fix it in 2.0.12 by reverting such unintended default behavior change. Not so strong is my opinion on whether we should enforce the default behavior by code. BIRD is released under GPL and anybody can apply their patches and do their forks. This can be used as an argument both ways. Our code isn't definitive. Hardcoding something is just "marking the right way". We can mark the right way just by setting the default behavior and allowing to configure what the user wants. In the end, the question reduces to this: If somebody wants to route 240/4 by BIRD, how high should the cost be? Simple (or not so simple) configuration change or patching and rebuilding?
Even as I (have to) totally agree with Nico, too; the sad reality as I had to observe it: For some reason some/many people are totally unaware of the possibility of IPv4 transport via IPv6. Be it using MP-BGP or nowadays Babel, too. This should get more "advertisement"/awareness.
I totally agree.
But on the other hand: I have heard stories of unlucky sysadmins maintaining totally broken/cluttered networks with no clear vision how to enable IPv6, and they never got a proper address planning scheme and they have to live with no more space in RFC1918. These people would benefit of making 240/4 a configurable option.
To be honest, I have heard lots of horror stories, more or less unbelievable, and I feel sorry for all the people involved. These people are probably stockpiling workarounds for years. Their deployments are probably the most challenging to convert to IPv6. Maybe we should primarily look for ways how to motivate them to share their issues with IPv6. Maybe their problems really can't be solved by current state of IPv6 and we should do our best to fix it. Anyway, I'm not sure whether the right thing is to simply enable 240/4 for them. It will also dry out, sooner or later, and IIRC there are efforts to make this range public, not site-local. I still remember what Cloudflare people discovered when deploying their 1.1.1.1 DNS resolver and I don't like hearing their stories again. Maybe we might make it configurable but write a big scary warning to the documentation? It may be the cleaner way. Yet we should somehow pass the information to anybody who wants to use 240/4: There is probably a better and more sustainable solution to your problem than using 240/4. And you can't see any, please go public and describe your problem to make it possible to solve. I wish you all wonderful following 365 days, regardless whether you call them "year 2023" or not. And thank you all for this discussion, for all your opinions and views. Maria
On Sat, Dec 31, 2022 at 08:56:02PM +0100, Maria Matejka via Bird-users wrote:
Hello!
On 12/31/22 16:17, Bernd Naumann via Bird-users wrote:
On 31.12.22 15:45, Juliusz Chroboczek via Bird-users wrote:
from my perspective the time to prolong the IPv4 usage is over.
I agree. [..] [..] I, for one, have changed my mind on the subject multiple times.
To clarify (and maybe amend a little) my position, I shall state this:
First of all, there is the previous patch which we reworked and merged, not realizing that if somebody has a policy "accept unless bad", then we are changing their behavior and they start accepting inherently bogon prefixes by upgrading to 2.0.10-11. This wasn't right and we should definitely fix it in 2.0.12 by reverting such unintended default behavior change.
Hi I did not want to delve into this issue as i have no strong opinion one way or the other, but i must disagree here. It was pretty clear to me that merging the previous patch was changing the default behavior (so it was an intended change), that is why i was hesitant with it. But it was probably the least bad option and we should stick with it. The issue with changing the default behavior cannot be undone by changing it again, that just makes it two issues instead of one, and changing something to be allowed is much less likely to break some setup than changing something to be forbidden. In this specific case, such change was unlikely to cause real problems outside of pretty artificial scenarios, while reverting it would obviously break setups that use 240/4. In general, i think that 'keeping stable behavior' is a commitment that should not be interpreted so strictly that it would conflict with allowing new behavior. For example, we sometimes add new BGP capabilities and make them enabled by default. -- 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."
participants (8)
-
Bernd Naumann -
Daniel Suchy -
Juliusz Chroboczek -
Maria Matejka -
Martin Mareš -
Nico Schottelius -
Ondrej Zajicek -
Seth David Schoen