Change rules for 'Disallow assigning bcast/networks to interfaces'

[PieterL75]

NetBox version

v3.5.2

Feature type

Change to existing functionality

Proposed functionality

#9068 introduced a new limitation to adding IPs to device interfaces.
The parameters chosen for this FR are limiting how IPs are used.

Use case

IPv6 does not have broadcast or network addresses. All is handled with linklocal addresses and multicast.. You can used to :: or :ffff ip's without problems. We tend to use the lowest address (aaaa:bbbb:1234:5678::) as gateway.

For IPv4, there are use cases for the network and broadcast address. When I route an entire subnet to a firewall, we can use all ips for NAT translations. Those IPs are added to the device on a virtual interface.
I tend to flag that prefix as a 'pool' (All IP addresses within this prefix are considered usable). Can that 'pool' be taken into account in the validation ?

Database changes

No response

External dependencies

No response

[decoupca]

For IPv6, does it therefore make sense to remove any limits on interface assignment?

For v4, In general I agree that limiting choice is a bad thing, because there's always an edge case I haven't thought of. But I also like to weigh that against the helpfulness of preventing common problems with sanity checking.

Two suggestions come to mind:

1. Change the ValidationError into a warning. Not sure if there is already GUI components in place to do this, but warning the user that what they're doing is typically not valid seems like a good balance.
2. Leave the ValidationError in place but introduce a config flag that disables the validation check

Thoughts?

[PieterL75]

The GUI prevented from creating broadcast/network addresses in the prefix view, unless the 'Pool' box is checked.

The only way to create a broadcast/network address around that GUI, is using the API, or by manually changing the IP at time of creation.

My view is
IPv6

• remove the validation

IPv4

• allow all ips when the prefix is a 'pool'
• in the GUI, when an IP address is entered, do a clientside check if it is a network/broadcast and show a warning there, even before the save button is pressed
• in the API, return a warning that a broadcast/network address is used.

but i would not prevent the IPs from being created...

[decoupca]

Agreed on IPv6, validation is not appropriate and I support removing it entirely.

As for your IPv4 suggestions, I'll defer to maintainers for guidance. IMHO I think this needs some level of user customizability, as I can imagine use cases where disabling this kind of validation could cause as many problems as leaving it enabled.

In any case, the validation only happens when assigning the net ID/bcast to an interface. You can create those objects directly with no errors.

[matejv]

In our network we use subnets /31 for IPv4 and /127 for IPv6 on all point to point links between routers. With this change we can no longer assign IP addresses to interfaces which is a major headache.

At least for /31 and /127 subnets there should be no validation of network and broadcast addresses, as both addresses in subnet are considered host addresses.

[decoupca]

@matejv there is no such validation on /31 and /127, they were excluded for exactly this reason. Are you sure they don't work?

[matejv]

I looked at the code and there are exceptions when validating network (first) address but not broadcast (last) address. And my colleague did show me the broadcast error message.

When assigning /31 (or /127) IPs for point to point links, one address is assigned to one router and the other to the other router. So I think the validation exclusion should apply to broadcast as well.

[decoupca]

The validator won't fail on either end of a PtP, since in such cases network.broadcast will evaluate to None. The code is a bit confusing, granted, but that's how netaddr.IPNetwork objects behave.

If you have a confirmed failure of assigning a /31 address, open a bug report with full details on how to reproduce.

[matejv]

Apologies for causing confusion before regarding validation of PtP subnets. It seems only IPv6 is affected and not IPv4.

If you try to assign the last IPv6 address with /127 mask to an interface you get a validation error that this is a broadcast address. The same error happens with IPv6 with /128 mask.

I've tested all possible combinations with /31, /32, /127 and /128 masks and only above two cases are problematic.

Steps to Reproduce:

1. Navigate to device interface
2. Click "Add IP address"
3. On "Add a new IP address" form set Address: 2001:db8::1/127 (or 2001:db8::1/128) and click Create

An error is shown:

2001:db8::1/127 is a broadcast address, which may not be assigned to an interface.

The same error will be shown if you try to assign 2001:db8::1/128

Expected Behavior:

A new IP Address object for 2001:db8::1/127 (or 2001:db8::1/128) should be created and assigned to interface. As /127 and /128 are considered subnet sizes that should be excluded from network/broadcast validation.

[MichaelSasser]

It would be great to remove those limitations, at least for IPv6. I encountered the same error message @matejv mentioned while trying to create IPv6-Addresses for Tailscale (Headscale) interfaces like fd7a:115c:a1e0::31/128 (the default prefix is fd7a:115c:a1e0::/48).

[decoupca]

@matejv Thanks for the info. Opening a separate issue to address IPv6 validation.

This issue should now focus solely on how to handle IPv4 validation

I see two ways forward:

1. Add a configuration option to disable validation
2. Change validation to raise a warning instead, ideally in TypeScript (before the form is submitted and any potential webhooks are fired)

Awaiting maintainer input.

[candlerb]

IPv6 does not have broadcast or network addresses. All is handled with linklocal addresses and multicast.. You can used to :: or :ffff ip's without problems.

This is not actually true.

With the exception of /127 point-to-point links, the all-zeros address is reserved in IPv6 as the "Subnet-Router Anycast address": see https://datatracker.ietf.org/doc/html/rfc4291#section-2.6.1 - it cannot be assigned to an individual host.

And address which end with all-ones and 80 to FF for the last byte are also reserved anycast addresses: https://www.rfc-editor.org/rfc/rfc2526.txt