Disallow creation of "default gateway" route/route6 objects

[job]

Describe the bug
It doesn't make sense for objects like these to exist:

$ date
Tue Jan 30 16:32:55 UTC 2024

$ whois -h rr.level3.net 0.0.0.0/32
route:          0.0.0.0/32
origin:         AS10753
mnt-by:         TCCGlobalNV-MNT
changed:        [email protected]
source:         LEVEL3
last-modified:  2024-01-30T11:04:49Z

Expected behaviour
IRRd should throw an error when an operator attempts to create a route/route6 object for 0.0.0.0/0, 0.0.0.0/32, ::/0, or ::/128.

IRRd version you are running
4.2.6

[dtaht]

In a world where someday, 0.0.0.0/8 was available, having 0.0.0.0/32 exist would actually be useful.

https://www.ietf.org/archive/id/draft-schoen-intarea-unicast-0-00.html 0.0.0.0/8 has been supported in linux at least, for over 5 years now.

[job]

I hear you, but the IRRd software package is used in context of the global Internet routing system, in which no network operator has been assigned authority for 0.0.0.0/8 or 0.0.0.0/32, thusly it should not appear in public Internet Routing Registries.

A further complication IRRd's primary purpose is to facilitate generation of BGP prefix filters, and 0.0.0.0 has special meaning in BGP signalling to indicate the BGP UPDATE carries a so-called default route; making that particular address inappropriate in the context in which this software is used.

[dtaht]

Thank you for the explanation. As to your latter point, are you saying that BGP does not distribute 0.0.0.0/0 as a default route, but 0.0.0.0 with the implicit assumption of that?

[rubenskuhl]

scopefilter.prefixes default values in irrd.yaml could get a 0.0.0.0/8, perhaps ? Some others we could see there:

scopefilter:
    prefixes:
        - 0.0.0.0/8
        - 10.0.0.0/8
        - 100.64.0.0/10
        - 127.0.0.0/8
        - 172.16.0.0/12
        - 192.0.2.0/24
        - 192.168.0.0/16
        - 198.51.100.0/24
        - 203.0.113.0/24
        - 224.0.0.0/3

[job]

Thank you for the explanation. As to your latter point, are you saying that BGP does not distribute 0.0.0.0/0 as a default route, but 0.0.0.0 with the implicit assumption of that?

Yes, in BGP-2 and BGP-3 it was literally encoded on-the-wire as 0.0.0.0 RFC1397, but in BGP-4 the default route is encoded as the value 0 (zero) in the NLRI's length field, however in the user interfaces of common Network Operating Systems particular encoding is expanded to 0.0.0.0.

Because in various network protocols and implementations 0.0.0.0 is taken to mean all IP addresses, I don't think it is suitable to be repurposed as a regular unicast address. This concern only applies to the lowest address in 0.0.0.0/8.

[nickhilliard]

Not clear how 0.0.0.0/8 would be appropriate in a public registry. The IANA status of 0.0.0.0/8 is "local identification", defined in rfc791, and 0.0.0.0/32 is defined in rfc1122, section 3.2.1.3 (self-host). Unless these RFCs are changed, the IRRD default should not be to publish them. Raising an error sounds reasonable.

[fischerdouglas]

Before I even finished reading the entire thread I had already thought about Scope Filter, as suggested by Rubens.

From where I can see, this is not a business rule to be hardcoded, but rather something to be adjusted and parameterized in each instance of IRRd.

I just don't remember if the Scope Filter only has an effect on Objects from the base itself, or if it also has an effect on objects originating from base replication.

In my opinion, the "owner" of the IRR base should decide how this type of object should be treated in "his" base.

[nickhilliard]

In my opinion, the "owner" of the IRR base should decide how this type of object should be treated in "his" base.

Yep, agreed. The default should reflect IANA assignments / IETF policies, i.e. raise an error for anything in 0.0.0.0/8 or other address blocks marked as reserved in the IANA address space registry (https://www.iana.org/assignments/ipv4-address-space). But if someone wants to configure 0.0.0.0/32 or /8, or another reserved block in a private irrd instance, they should be able to do it.

If the block assignment is changed by IANA, the default in irrd can change too.

[rubenskuhl]

In my opinion, the "owner" of the IRR base should decide how this type of object should be treated in "his" base.

Yep, agreed. The default should reflect IANA assignments / IETF policies, i.e. raise an error for anything in 0.0.0.0/8 or other address blocks marked as reserved in the IANA address space registry (https://www.iana.org/assignments/ipv4-address-space). But if someone wants to configure 0.0.0.0/32 or /8, or another reserved block in a private irrd instance, they should be able to do it.

We used TEST-NET allocations to showcase IRR operation in training classes, so having the (non-default) option to allow them is useful.

[rubenskuhl]

Before I even finished reading the entire thread I had already thought about Scope Filter, as suggested by Rubens.

From where I can see, this is not a business rule to be hardcoded, but rather something to be adjusted and parameterized in each instance of IRRd.

I just don't remember if the Scope Filter only has an effect on Objects from the base itself, or if it also has an effect on objects originating from base replication.

In my opinion, the "owner" of the IRR base should decide how this type of object should be treated in "his" base.

All sources, authoritative ou replications, have options to enable or disable RPKI filtering and scope filtering:

sources.{name}.rpki_excluded
sources.{name}.scopefilter_excluded

[rubenskuhl]

One thing I haven't tested is whether having a scope filter for a particular slice of the IPv4 space (like 10.0.0.0/8) blocks 0.0.0.0/0 or not. It should, since 0.0.0.0/0 means the whole IPv4 space. But only a scope filter of 0.0.0.0/8 or smaller would block 0.0.0.0/32.

[schoen]

Hi! As @dtaht mentioned above, we're continuing to work on a standards proposal under which 0/8 could become useful in the future. Contrary to his recollection, we wouldn't allow 0.0.0.0/32 to refer to a host or network route, but we would allow 0.0.0.0/8.

The IETF standards do indeed call for all of 0/8 to be rejected, and that hasn't changed yet, but the local-configuration mechanism for which 0/8 was originally meant to be used was obsolete by the time of RFC 1122. So there's not actually a competing use there.

We'd like to ask everybody to make it straightforward to use 0/8 (or smaller subnets, other than 0/32) in the future, either for testing and experimentation around this, or in response to possible future standards changes. It sounds like this is already what you're expecting to do here!

[job]

Sure, but in the context of the hierarchical use of this application and its intended context, a route object which covers 0.0.0.0/8 would also cover 0.0.0.0/32, which is Not Good (as that's the default gateway's address). I maintain that any submission of an route: object covering 0.0.0.0/32 or route6: object covering ::/128 is an error and should be treated as such.

Similarly, an overclaim in this context (for example 0.0.0.0/0 or ::/0) also is a strong indicator for human error.

IRRd v4 erroring on 0.0.0.0 does not in any way impede on the effort to make parts of 0.0.0.0/8 useful.

[schoen]

@job, do you think that in a hypothetical future deployment of parts of 0/8, we need to specifically carve out some space around 0.0.0.0 to exclude from announcements (beyond just continuing to reserve 0.0.0.0/32 itself)? E.g. only announcing 0.0.1.0/24 and up, or something?

[rubenskuhl]

IANA depletion rate was 20 /8s in the last year of downstream allocations. So, allowing 0.0.0.0/8 gives us 18 days of IPv4.
Sorry for not being overwhelmed by this.

That said, if it comes to that, removing it from a possible default IRRd configuration will hardly be the only codebase to be updated to allow for such use. So it doesn't hurt following current allocation scenario for now, and updating it if the future brought us a use for such space.

[fischerdouglas]

If I understood Job's intention correctly, he wants to prevent NNF[1] installations of IRRd from allowing negligent maintainers to create objects that could cause harm.
That being the case, I don't see any harm.

But I reiterate that this should not be hardcoded.
If any IRRd operator, for some unimaginable reason at this moment, would want ROUTE 0.0.0.0/32 object to be allowed in its base, he can do so.

I'm not a programmer! So a deep understanding of what the difficulties and negative impacts of my following suggestion would be.

But I imagine that in a new minor release (4.X), and not in a patch (4.X.Y), respecting the concepts of semantic versioning, the IRRd installer/updater could add a scope filter specifically for 0.0.0.0/32 that was enabled by default.

In doing so, anyone who wanted to disable this scope-filter would have to do so on purpose, which would create a feeling of co-responsibility on the part of the operator of this base if any problem on the global Internet occurs due to their deliberate attitude.

The old concept of: "If you don't know what it means, don't touch it! If you touch it and it appears broken, it's your fault!

[1] Next-Next-Finish

[mxsasha]

I do not think we should enforce this in the code.

• A hardcoded business rule is relatively very hard to change. It requires a new release and an upgrade by the operator. IRRD has a variety of operators. Hardcoding should mainly be used for evident data integrity or incompatibility issues.
• The scope filter can already do this easily, by adding 0.0.0.0/32 as out of scope (not 0/0 - scope filter finds anything that has any overlap with an out of scope prefix). This is exactly one of the purposes the scope filter was intended for.
• Should this become a significant issue in an instance, it is an easy fix by the operator, using the scope filter, i.e. the situation is recoverable.
• This would only help for authoritative IRRD deployments, that also have some real authority in the global routing system, who use Next-Next-Finish. I don't think anyone deploys so sloppily, and if they do, a 0/0 route object is probably not the biggest concern.
• The length of this discussion already indicates that this issue is not unambiguously clear cut, so leaving it up to the operator seems reasonable.

[tangledhelix]

• The scope filter can already do this easily, by adding 0.0.0.0/32 as out of scope (not 0/0 - scope filter finds anything that has any overlap with an out of scope prefix). This is exactly one of the purposes the scope filter was intended for.

Another way to read this statement is that the scope filter is incapable of covering the 0/0 case, meaning it would remain at issue.

• The length of this discussion already indicates that this issue is not unambiguously clear cut, so leaving it up to the operator seems reasonable.

I understand this thought, but I would counter it with the observation that much of the discussion above was actually about 0/8, which isn't what Job asked to suppress. IMO that distracts from the original request and confuses the question.

These two specific cases are special and aren't ever going to change.

• Even if 0/8 were released for assignment, 0/32 would have to be left as an exception (and most probably 0/24 would remain reserved)
• 0/0 is not contained by 0/8 anyway; therefore whether 0/8 might become assignable is irrelevant to its treatment.

I support Job's original request which, as a reminder, was only related to 0.0.0.0/0, 0.0.0.0/32, ::/0, and ::/128.

[fischerdouglas]

Two points here:

A) Default-Configs, Default-Behavior
I believe it is possible to compare this issue of considering default-configs as dummies-proof with what DNS engine developers go through and have gone through.
The recommended best practices for issues such as DNSSEC and Special/Local Zones have been included in DNS engines for a long time, but only began to gain effective traction after they began to be included as standard configuration for DNS engines.

I understand that it is a responsibility that one wants to avoid, but it is as Antoine de Saint-Exupéry said: "you become responsible, forever, for what you have tamed"

B) Blacklist/Whitelist, Exclude/Include, in scope.
I believe you will agree that this issue of the default route is just the tip of the iceberg of exceptions that will certainly arise as we manage to get network operators to use RPSL correctly.

An example of this is the MESS that ASN operators are making with AS-SETs... AS-SETs containing 10-12 thousand ASNs.

Based on Dan Lowe's statement, I imagine that a condition composed of includes and excludes in the scope would be what would bring a solution closer to what is desirable for this issue.

Given this issue of the default route, and also the prospect of future problems with ASN scope filtering, I suggest that a combined use of excludes and includes be considered.