IPv6 address scope not set to operator-configured value

IPv6 address scope not set to operator-configured value

[Tj]

Using iproute2 and kernel v6.5.0 with Debian 12 Bookworm amd64 (tested also with v6.136 nixos) setting scope on an IPv6 fails silently with no indications as to why and the address is configured with what appears to be a scope based on the prefix (usually 0 but for fe80::/16 addresses scope is set to 253). Doesn't matter whether using scope names (from /etc/iproute2/rt_scopes) or numbers. Similar command for IPv4 succeeds.

ip address add fddc::2/64 scope 200 dev PUBLIC
ip -N -6 address show dev PUBLIC
...
inet6 fddc::2/64 scope 0

I used `gdb` to trace this expecting somehow the scope was not being read correctly but it is:

2577            if (!scoped && cmd != RTM_DELADDR)
(gdb) p scoped
$22 = <optimized out>
(gdb) p cmd
$23 = <optimized out>
(gdb) n
2580            req.ifa.ifa_index = ll_name_to_index(d);
(gdb) p req.ifa.ifa_scope
$24 = 200 '\310'
...
2607            if (echo_request)
(gdb) n
2610                    ret = rtnl_talk(&rth, &req.n, NULL);
(gdb) p req.n
$25 = {nlmsg_len = 64, nlmsg_type = 20, nlmsg_flags = 1537, nlmsg_seq = 0, nlmsg_pid = 0}
(gdb) p rth
$26 = {fd = 3, local = {nl_family = 16, nl_pad = 0, nl_pid = 2381950, nl_groups = 0}, peer = {nl_family = 0, nl_pad = 0, nl_pid = 0, nl_groups = 0}, seq = 1694191286,
   dump = 0, proto = 0, dump_fp = 0x0, flags = 4}
(gdb) s
rtnl_talk (rtnl=0x5555555f7020 <rth>, n=n@entry=0x7fffffffe140, answer=answer@entry=0x0) at ./lib/libnetlink.c:1170
1170    {
...
ipaddr_modify (cmd=<optimized out>, flags=<optimized out>, argc=<optimized out>, argv=0x7fffffffe478) at ./ip/ipaddress.c:2612
2612            if (ret)
(gdb) p ret
$27 = 0

Re: IPv6 address scope not set to operator-configured value

[Guillaume Nault]

[ Cc: David Ahern, who might have an opinion on this]

On Fri, Sep 08, 2023 at 06:02:00PM +0100, Tj wrote:
> Using iproute2 and kernel v6.5.0 with Debian 12 Bookworm amd64
> (tested also with v6.136 nixos) setting scope on an IPv6 fails
> silently with no indications as to why and the address is configured
> with what appears to be a scope based on the prefix (usually 0 but
> for fe80::/16 addresses scope is set to 253). Doesn't matter whether
> using scope names (from /etc/iproute2/rt_scopes) or numbers. Similar
> command for IPv4 succeeds.

I don't think we could let the user manually set the scope of IPv6
addresses. As you realised, with IPv6, the scope is automatically
derived from the address.

I had a patch to reject IPv6 netlink commands that have a scope
attribute. I've never sent it though, as I was affraid to break
existing users. But now that I read your message, I feel that maybe
we'd better explicitely reject such commands instead of silently
ignoring the scope. That'd avoid this kind of misunderstanding.

If anyone feels we should reject the scope attribute when adding
IPv6 routes or addresses, just let me know and I'll send this patch.

> ip address add fddc::2/64 scope 200 dev PUBLIC
> ip -N -6 address show dev PUBLIC
> ...
> inet6 fddc::2/64 scope 0
> 
> I used `gdb` to trace this expecting somehow the scope was not being read correctly but it is:
> 
> 2577            if (!scoped && cmd != RTM_DELADDR)
> (gdb) p scoped
> $22 = <optimized out>
> (gdb) p cmd
> $23 = <optimized out>
> (gdb) n
> 2580            req.ifa.ifa_index = ll_name_to_index(d);
> (gdb) p req.ifa.ifa_scope
> $24 = 200 '\310'
> ...
> 2607            if (echo_request)
> (gdb) n
> 2610                    ret = rtnl_talk(&rth, &req.n, NULL);
> (gdb) p req.n
> $25 = {nlmsg_len = 64, nlmsg_type = 20, nlmsg_flags = 1537, nlmsg_seq = 0, nlmsg_pid = 0}
> (gdb) p rth
> $26 = {fd = 3, local = {nl_family = 16, nl_pad = 0, nl_pid = 2381950, nl_groups = 0}, peer = {nl_family = 0, nl_pad = 0, nl_pid = 0, nl_groups = 0}, seq = 1694191286,
>   dump = 0, proto = 0, dump_fp = 0x0, flags = 4}
> (gdb) s
> rtnl_talk (rtnl=0x5555555f7020 <rth>, n=n@entry=0x7fffffffe140, answer=answer@entry=0x0) at ./lib/libnetlink.c:1170
> 1170    {
> ...
> ipaddr_modify (cmd=<optimized out>, flags=<optimized out>, argc=<optimized out>, argv=0x7fffffffe478) at ./ip/ipaddress.c:2612
> 2612            if (ret)
> (gdb) p ret
> $27 = 0
> 
> 
> 
> 
> 
> 

Re: IPv6 address scope not set to operator-configured value

[Tj]

Apologies if this doesn't thread - I've had to manually add the In-Reply-To header because I did not receive Guillaume's reply and only discovered it via the email archive.

Not being able to set the scope causes a problem. The scenario in which I need to use it is interfaces with multiple global and ULA addresses where a multicast-DNS responder needs to choose the correct address to send in reply to queries. This affects both avahi and systemd-resolved which currently seem to chose almost - but not quite - at random; but enough so that it often breaks.

E.g: if the query originates from a ULA address the response should give a ULA address; if the query originates from a global then a global address, etc. In fact, being able to simply set scopes and enable the responder to be configured to use a specific scope would be helpful. It'd certainly avoid having to hard-code logic to determine what address ranges represent a particular logical zone.

Re: IPv6 address scope not set to operator-configured value

[David Ahern]

On 9/14/23 7:51 AM, Tj wrote:
> Apologies if this doesn't thread - I've had to manually add the
> In-Reply-To header because I did not receive Guillaume's reply and only
> discovered it via the email archive.
> 
> Not being able to set the scope causes a problem. The scenario in which
> I need to use it is interfaces with multiple global and ULA addresses
> where a multicast-DNS responder needs to choose the correct address to
> send in reply to queries. This affects both avahi and systemd-resolved
> which currently seem to chose almost - but not quite - at random; but
> enough so that it often breaks.
> 
> E.g: if the query originates from a ULA address the response should give
> a ULA address; if the query originates from a global then a global
> address, etc. In fact, being able to simply set scopes and enable the
> responder to be configured to use a specific scope would be helpful.
> It'd certainly avoid having to hard-code logic to determine what address
> ranges represent a particular logical zone.

We cannot change the behavior of an existing API. We have tried that
many times in the past, and inevitably most changes are reverted.