Bug#898527: libnss-mdns: Adding ipv6 scope id breaks NFS mounts
On Mon, May 14, 2018 at 01:38:15PM +0100, Simon McVittie wrote: > On Sat, 12 May 2018 at 18:26:11 -0700, Ross Vandegrift wrote: > > It looks like the scope id was added in #644912. This may be a kernel bug > > if > > the scope id should be accepted. > > I think this might be a bug in whatever user-space tool calls > getaddrinfo() and passes its result to the kernel, which probably means > mount.nfs? If the kernel doesn't want to see scope IDs in this context, > then the user-space tool shouldn't provide them: returning scope IDs is > part of the getaddrinfo() API. I did some digging, here's what I found. mount.nfs accepts scoped ipv6 addresses: $ sudo mount.nfs -vf '[fd7d:612b:f36c:0:4d15:7364:6589:dbef%2]:/' /mnt/tmp -o nfsvers=4.2 mount.nfs: timeout set for Mon May 14 19:11:01 2018 mount.nfs: trying text-based options 'vers=4.2,addr=fd7d:612b:f36c:0:4d15:7364:6589:dbef%2,clientaddr=fd7d:612b:f36c::4c5' But mount(2) fails: $ sudo mount.nfs -v '[fd7d:612b:f36c:0:4d15:7364:6589:dbef%2]:/' /mnt/tmp -o nfsvers=4.2 mount.nfs: timeout set for Mon May 14 19:12:48 2018 mount.nfs: trying text-based options 'nfsvers=4.2,addr=fd7d:612b:f36c:0:4d15:7364:6589:dbef%2,clientaddr=fd7d:612b:f36c::4c5' mount.nfs: mount(2): Invalid argument mount.nfs: an incorrect mount option was specified nfs(5) has the following to say about the source argument: The server's hostname can be an unqualified hostname, a fully qualified domain name, a dotted quad IPv4 address, or an IPv6 address enclosed in square brackets. Link-local and site-local IPv6 addresses must be accompanied by an interface identifier. See ipv6(7) for details on specifying raw IPv6 addresses. And ipv6(7) has this to say about the scope id field: sin6_scope_id is an ID depending on the scope of the address. It is new in Linux 2.4. Linux supports it only for link-local addresses, in that case sin6_scope_id contains the interface index (see netdevice(7)) Best as I can figure there's three wishlist bugs here: 1. nss-mdns should not return scope id for global addresses 2. mount.nfs should strip scope id unless the address is link-local 3. the kernel should accept & ignore scope id on non-global addresses Does this seems like a reasonable reading? Ross
Bug#898527: libnss-mdns: Adding ipv6 scope id breaks NFS mounts
On Mon, May 14, 2018 at 01:38:15PM +0100, Simon McVittie wrote: > Not including the scope ID in the result of address resolution breaks IPv6 > link-local addressing (fe80:*), and link-local addressing and mDNS are both > parts of the Zeroconf stack, so they (should) go well together. Yep, this makes perfect sense - the scope id shouldn't go away entirely. > Or possibly nss-mdns should be setting the scope ID to the interface > index for link-local addresses, but not for other addresses? It isn't > entirely clear to me what nss-mdns is meant to be doing here. On one hand, rfc4007 11.1 says that the scope id should not be used for global scope, loopback, and undefined addresses. On the other, ping & ssh both saw the scope id and handled it without complaint. > Workarounds: > > * don't use mDNS (.local names) to find NFS servers; or > * configure mdns4[_minimal] instead of mdns[_minimal] so .local names > resolve to IPv4 addresses Yea there are workarounds, but I think this use-case is a sensible one that should be supported. My home has provider-assigned addressing via DHCPv6 PD, so it isn't static. ipv6 wisdom might suggest ULA + DNS instead. That requires static addressing or dynamic DNS - both of which are overkill for home users. mDNSv6 has been providing a good solution to exactly this. Ross
Bug#898527: libnss-mdns: Adding ipv6 scope id breaks NFS mounts
On Sat, 12 May 2018 at 18:26:11 -0700, Ross Vandegrift wrote: > After upgrading my laptop from stretch to buster, I'm not able to mount NFS > via > mdns. I have the following entry in /etc/fstab: > > vanvanmojo.local:/mnt/storage /mnt/storage nfs4 > noauto,nofail,x-systemd.automount,x-systemd.mount-timeout=10,x-systemd.requires=network-online.target,x-systemd.idle-timeout=10m > 0 0 > > The mount fails with the following log message: > > stgulik kernel: [ 575.329441] NFS: bad IP address specified: > addr=2606:6000:4502:1d00:4639:c4ff:fe53:e49b%2 > > It looks like the scope id was added in #644912. This may be a kernel bug if > the scope id should be accepted. I think this might be a bug in whatever user-space tool calls getaddrinfo() and passes its result to the kernel, which probably means mount.nfs? If the kernel doesn't want to see scope IDs in this context, then the user-space tool shouldn't provide them: returning scope IDs is part of the getaddrinfo() API. Not including the scope ID in the result of address resolution breaks IPv6 link-local addressing (fe80:*), and link-local addressing and mDNS are both parts of the Zeroconf stack, so they (should) go well together. Or possibly nss-mdns should be setting the scope ID to the interface index for link-local addresses, but not for other addresses? It isn't entirely clear to me what nss-mdns is meant to be doing here. Workarounds: * don't use mDNS (.local names) to find NFS servers; or * configure mdns4[_minimal] instead of mdns[_minimal] so .local names resolve to IPv4 addresses NFS has historically been somewhat fragile against network failures, so I'm not sure that I can recommend mDNS as a way to find NFS shares. If your network is sufficiently static and hand-configured that you can safely put NFS shares in /etc/fstab, then it's probably also sufficiently static that the NFS server has a stable name, or even a stable IP address. smcv
Bug#898527: libnss-mdns: Adding ipv6 scope id breaks NFS mounts
Package: libnss-mdns Version: 0.14.1-1 Severity: normal Tags: ipv6 After upgrading my laptop from stretch to buster, I'm not able to mount NFS via mdns. I have the following entry in /etc/fstab: vanvanmojo.local:/mnt/storage /mnt/storage nfs4 noauto,nofail,x-systemd.automount,x-systemd.mount-timeout=10,x-systemd.requires=network-online.target,x-systemd.idle-timeout=10m 0 0 The mount fails with the following log message: stgulik kernel: [ 575.329441] NFS: bad IP address specified: addr=2606:6000:4502:1d00:4639:c4ff:fe53:e49b%2 It looks like the scope id was added in #644912. This may be a kernel bug if the scope id should be accepted. Thanks, Ross -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing'), (40, 'unstable'), (30, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.16.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libnss-mdns depends on: ii avahi-daemon 0.7-4 ii base-files10.1 ii libc6 2.27-3 libnss-mdns recommends no packages. Versions of packages libnss-mdns suggests: ii avahi-autoipd 0.7-4 -- no debconf information
