: Fix deletion of local addresses only varying in prefix length

The deletion of local addresses via netlink doesn't take the prefix length into account resulting in the deletion of the address that was added first given multiple addresses exist only varying in the prefix length.

tgr:axs ~ ip -4 addr show dev lo
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
inet 127.0.0.1/8 scope host lo
inet 1.1.1.1/1 scope global lo
inet 1.1.1.1/2 scope global lo

Quoted 4 lines · Thomas Graf

The deletion of local addresses via netlink doesn't take the prefix length into account resulting in the deletion of the address that was added first given multiple addresses exist only varying in the prefix length.

This has the potential of breaking user-space scripts. For example, this won't work anymore:

ip a a dev eth0 192.168.0.1/24
ip a d dev eth0 192.168.0.1

Quoted 6 lines

tgr:axs ~ ip -4 addr show dev lo
1: lo: <LOOPBACK,UP> mtu 16436 qdisc noqueue
inet 127.0.0.1/8 scope host lo
inet 1.1.1.1/1 scope global lo
inet 1.1.1.1/2 scope global lo

Do we really need to handle this case? If we do then would it be better to consider ifa_prefixlen only when there are multiple addresses present which match but differ by prefix length?

I do not agree but I might have a better idea. Let's change iproute2 to provide a prefixlength of 0 if no prefix was specified and only compare the prefixes if it is non zero. This allows for accurate deletion, no scripts will break (except for really really broken ones). Given there are multiple matching addresses only varying in prefix length and no prefix was specified the first one will get deleted but this is well defined.

Quoted 8 lines · Thomas Graf

I do not agree but I might have a better idea. Let's change iproute2 to provide a prefixlength of 0 if no prefix was specified and only compare the prefixes if it is non zero. This allows for accurate deletion, no scripts will break (except for really really broken ones). Given there are multiple matching addresses only varying in prefix length and no prefix was specified the first one will get deleted but this is well defined.

Yep this is a good solution.

I do not agree but I might have a better idea. Let's change iproute2 to provide a prefixlength of 0 if no prefix was specified and only compare the prefixes if it is non zero. This allows for accurate

Quoted 4 lines

I do not agree but I might have a better idea. Let's change iproute2 to provide a prefixlength of 0 if no prefix was specified and only compare the prefixes if it is non zero. This allows for accurate

A bigger problem with this approach is that we don't have a magical way of getting people to upgrade their ip(8) binary.

To do this safely, we'll need a way of indicating that the ip(8) binary is setting the prefixlen in the way you propose. Perhaps this can be done using a new IFA payload type.

Alternatively you can use the value of /32 to indicate a wildcard match instead of /0. After all, /0 has a specific meaning in this context so it's just as arbitrary to choose /0 as opposed to /32.

I've been thinking about this since yesterday and the best solution I came up so far is to encode it in one of the yet unused bits in the prefixlength field. After all we're only using 5bits of it. What i'm thinking of in particular is to encode it as in 1 bit wildcard flag 5 bits prefix length.

I've been thinking about this since yesterday and the best solution I came up so far is to encode it in one of the yet unused bits in the prefixlength field. After all we're only using 5bits of it. What i'm thinking of in particular is to encode it as in 1 bit wildcard flag 5 bits prefix length.

I think that would be ok. Unrelated to this: for IFA_ADDRESS we don't do an exact match, perhaps we should also do this for IFA_LOCAL for consistency.

Quoted 3 lines · Patrick McHardy

I think that would be ok. Unrelated to this: for IFA_ADDRESS we don't do an exact match, perhaps we should also do this for IFA_LOCAL for consistency.

You mean that we do do an exact match for IFA_ADDRESS?

Quoted 7 lines · Herbert Xu

Quoted 3 lines · Patrick McHardy

I think that would be ok. Unrelated to this: for IFA_ADDRESS we don't do an exact match, perhaps we should also do this for IFA_LOCAL for consistency.

Quoted 1 line

You mean that we do do an exact match for IFA_ADDRESS?

No, I meant that IFA_ADDRESS matches on exact prefixlen, but uses inet_ifa_match() for comparing the addresses. In any case we should keep the behaviour that no given prefix is a wildcard, but if a prefix is given we could do something similar as for IFA_ADDRESS.

This will change the behaviour and makes my work completely useless.

Assuming one adds 1.1.1.1/24, 1.1.1.2/24 and then deletes 1.1.1.2/24 one would expect 1.1.1.2/24 to be deleted but that wouldn't be the case.

I've been thinking about this since yesterday and the best solution I came up so far is to encode it in one of the yet unused bits in the prefixlength field. After all we're only using 5bits of it. What i'm thinking of in particular is to encode it as in 1 bit wildcard flag 5 bits prefix length.

Quoted 6 lines

I've been thinking about this since yesterday and the best solution I came up so far is to encode it in one of the yet unused bits in the prefixlength field. After all we're only using 5bits of it. What i'm thinking of in particular is to encode it as in 1 bit wildcard flag 5 bits prefix length.

That's sound fine as long as we treat the current ip(8) prefix length as a wild card.

Although we should keep the behaviour of ip a a 1.1.1.1/24; ip a d 1.1.1.1, what about ip a a 1.1.1.1/24; ip a d 1.1.1.1/16? I think the latter should not result in a deletion. We could achieve this by checking the prefix length if either the exact-match flag is set or the prefixlength is != 32. This is of course quite minor and only affects old iproute2 versions in combination with newer kernels.

Do we really need to handle this case? If we do then would it be better to consider ifa_prefixlen only when there are multiple addresses present which match but differ by prefix length?