happily selects deprecated addresses

Zugschlus commented 2 years ago

Hi,

I have a system with the following configuration:

[115/5089]mh@salida:~ $ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 52:54:00:a9:68:07 brd ff:ff:ff:ff:ff:ff
    altname enp0s3
    inet 192.168.192.209/24 metric 1024 brd 192.168.192.255 scope global dynamic ens3
       valid_lft 8668sec preferred_lft 8668sec
    inet6 2001:16b8:3040:8d2:5054:ff:fea9:6807/64 scope global dynamic mngtmpaddr noprefixroute 
       valid_lft 6081sec preferred_lft 2481sec
    inet6 2a01:238:42bc:a192:5054:ff:fea9:6807/64 scope global deprecated dynamic mngtmpaddr noprefixroute 
       valid_lft 3429sec preferred_lft 0sec
    inet6 2a01:238:42bc:a192::d1:100/64 scope global 
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fea9:6807/64 scope link 
       valid_lft forever preferred_lft forever
[116/5090]mh@salida:~ $

Please note that one of the SLAAC addresses on ens3 isl deprecated; the router announces it with a zero lifetime, and a static address is set via DHCPv6 with a non-zero lifetime.

I have the following oas.conf, which should be the same on all systems:

[116/5090]mh@salida:~ $ cat /etc/oas.conf 
cmdlines:
ssh

addresses:
2a01:238:42bc:a180::/60
2a01:238:42bc:a100::/56
[117/5091]mh@salida:~ $

In this setup, ssh to another system with the IP address 2a01:238:42bc:a192::d2:100 causes oas to select the deprecated SLAAC address while a non-deprecated address is actually available.

This is not what I want, this is not how a system without oas would behave, and I am pretty sure that I can find an RFC forbidding the use of a deprecated address when a non-deprecated address is available (RFC6724 probably).

It looks like oas cannot blindly choose the first matching address it finds, it needs to

detect whether an address is deprecated
make note of this address
continue searching for a non-deprecated address
if a non-deprecated address is found, abort search, use non-deprecated address
if no non-deprecated address is found, use the deprecated one

The last step is probably an RFC violation as well, but it's acting according to local configuration.

Thanks in advance!

Greetings Marc

ThomasNoll commented 2 years ago

Hello Marc,

right now oas fully ignores RFC6724 section 5 source address selection rules if a configuration entry matches. Making it RFC conform would mean only rule 4 (prefer home address), 5.5 (prefer prefixes from next-hop), 7 (prefer temporary address) and 8 (prefer longest matching prefix) could be overruled. And i would have to implement all data gathering and checks for rule 1,2,3,5 and 6.

In situations where you have only deprecated addresses matching the config and a preferred that does not, RFC would require to use the latter.

I think best solution would be to give the user the choice which parts of RFC he wants to overule.

Best regards Thomas

Zugschlus commented 2 years ago

right now oas fully ignores RFC6724 section 5 source address selection rules if a configuration entry matches.

Things get interesting if multiple local addresses match, which is likely if a system has both an SLAAC or a privacy extension address and a static address from the same /64 and the /64 matches.

For my current user story, it would be enough not to choose a deprecated matching address if there is a non-deprecated matching address available.

I agree with your other reasoning as well, but it would really by great if machine-specific oas.conf files could be avoided; having a network-specific oas.conf is enough pain already.

Greetings Marc

ThomasNoll commented 2 years ago

Things get interesting if multiple local addresses match, which is likely if a system has both an SLAAC or a privacy extension address and a static address from the same /64 and the /64 matches.

Maybe you can use existing features. oas matches addresses with arbitrary bits to be considered.

So this configuration:

cmdlines: ssh

addresses: 2a01:238:42bc:a180::/FFFF:FFFF:FFFF:FFF0:FFFF:FFFF:: 2a01:238:42bc:a100::/56

would prefer 2a01:238:42bc:a192::d1:100/64 over 2a01:238:42bc:a192:5054:ff:fea9:6807/64 from your example. Of course this depends on your address schema.

Zugschlus commented 2 years ago

I would not have come to the idea to use a non-continguous netmask for IPv6 addresses. But of course, that works. Looks to me like 2001:db8:42bc:a100::/ffff:ffff:ffff:ffff:0000:00ff:: will NOT match EUI64 addresses since the lower 8 bits from the 6th quibble are fixed to zero. If you have a bigger network, this will also work with shorter prefixes like 2001:db8:42bc::/ffff:ffff:ffff:0000:0000:00ff:: for the /48.

Do you want me to add those examples to config_example?

Greetings Marc

P.S.: I'd still like to have full 6724 conformance, but I understand that's a lot of work.

ThomasNoll / oas

happily selects deprecated addresses #6