aboutgitcodebugslistschat
path: root/dhcp.c
diff options
context:
space:
mode:
authorStefano Brivio <sbrivio@redhat.com>2023-12-27 14:46:39 +0100
committerStefano Brivio <sbrivio@redhat.com>2023-12-30 11:45:27 +0100
commitf091893c1ffe1a531989a599737031089f6cfcb4 (patch)
tree2c01695133194a45d6b13570c451f4d2e9d22658 /dhcp.c
parent62b94c3ec832f23b985db7d27b30052d2a83cf9a (diff)
downloadpasst-f091893c1ffe1a531989a599737031089f6cfcb4.tar
passt-f091893c1ffe1a531989a599737031089f6cfcb4.tar.gz
passt-f091893c1ffe1a531989a599737031089f6cfcb4.tar.bz2
passt-f091893c1ffe1a531989a599737031089f6cfcb4.tar.lz
passt-f091893c1ffe1a531989a599737031089f6cfcb4.tar.xz
passt-f091893c1ffe1a531989a599737031089f6cfcb4.tar.zst
passt-f091893c1ffe1a531989a599737031089f6cfcb4.zip
netlink: Fetch most specific (longest prefix) address in nl_addr_get()2023_12_30.f091893
This happened in most cases implicitly before commit eff3bcb24547 ("netlink: Split nl_addr() into separate operation functions"): while going through results from netlink, we would only copy an address into the provided return buffer if no address had been picked yet. Because of the insertion logic in the kernel (ipv6_link_dev_addr()), the first returned address would also be the one added last, and, in case of a Linux guest using a DHCPv6 client as well as SLAAC, that would be the address assigned via DHCPv6, because SLAAC happens before the DHCPv6 exchange. The effect of, instead, picking the last returned address (first assigned) is visible when passt or pasta runs nested, given that, by default, they advertise a prefix for SLAAC usage, plus an address via DHCPv6. The first level (L1 guest) would get a /64 address by means of SLAAC, and a /128 address via DHCPv6, the latter matching the address on the host. The second level (L2 guest) would also get two addresses: a /64 via SLAAC (same prefix as the host), and a /128 via DHCPv6, matching the the L1 SLAAC-assigned address, not the one obtained via DHCPv6. That is, none of the L2 addresses would match the address on the host. The whole point of having a DHCPv6 server is to avoid (implicit) NAT when possible, though. Fix this in a more explicit way than the behaviour we initially had: pick the first address among the set of most specific ones, by comparing prefix lengths. Do this for IPv4 and for link-local addresses, too, to match in any case the implementation of the default source address selection. Reported-by: Yalan Zhang <yalzhang@redhat.com> Fixes: eff3bcb24547 ("netlink: Split nl_addr() into separate operation functions") Signed-off-by: Stefano Brivio <sbrivio@redhat.com>
Diffstat (limited to 'dhcp.c')
0 files changed, 0 insertions, 0 deletions