Re-sending in text format due to Gmail preserving the HTML email I
received and vger (quite reasonably) rejecting my response.
---------- Forwarded message ---------
From: Mark Smith <redacted>
Date: Wed, 31 Jul 2019 at 12:23
Subject: Re: net: ipv6: Fix a bug in ndisc_send_ns when netdev only
has a global address
To: David Ahern <redacted>
Cc: Su Yanjun <redacted>, <redacted>
Hi David,
On Wed., 31 Jul. 2019, 00:11 David Ahern, [off-list ref] wrote:
On 7/30/19 4:28 AM, Mark Smith wrote:
quoted
Hi Su,
<snip>
quoted
quoted
quoted
This patch is not the correct solution to this issue.
<snip>
quoted
In linux implementation, one interface may have no link local address if
kernel config
*addr_gen_mode* is set to IN6_ADDR_GEN_MODE_NONE. My patch is to fix
this problem.
So this "IN6_ADDR_GEN_MODE_NONE" behaviour doesn't comply with RFC 4291.
As RFC 4291 says,
"All interfaces are *required* to have *at least one* Link-Local
unicast address."
That's not an ambiguous requirement.
Interesting. Going back to the original commit:
commit bc91b0f07ada5535427373a4e2050877bcc12218
Author: Jiri Pirko [off-list ref]
Date: Fri Jul 11 21:10:18 2014 +0200
ipv6: addrconf: implement address generation modes
This patch introduces a possibility for userspace to set various (so far
two) modes of generating addresses. This is useful for example for
NetworkManager because it can set the mode to NONE and take care of link
local addresses itself. That allow it to have the interface up,
monitoring carrier but still don't have any addresses on it.
So the intention of IN6_ADDR_GEN_MODE_NONE was for userspace to control
it. If an LLA is required (4291 says yes, 4861 suggests no) then the
current behavior is correct and if IN6_ADDR_GEN_MODE_NONE is used by an
admin some userspace agent is required to add it for IPv6 to work on
that link.
Ok. That seems to be saying that IN6_ADDR_GEN_MODE_NONE means that the
kernel is not going perform any address configuration on the interface
for any prefixes.
That would then place the RFC 4291 burden to generate at least one LL
address for the interface onto the user space application that has
taken over performing IPv6 address configuration on an interface.
<snip>
quoted
It is an IPv6 enabled interface, so it requires a link-local address,
per RFC 4291. RFC 4291 doesn't exclude any interfaces types from the
LL address requirement.
There is no 'link' for loopback, so really no point in generating an LLA
for it.
If your 'link' mean something physical, then I agree, the loopback
virtual interface doesn't have a link.
From IPv6's perspective, there is a link attached, because the
interface is operationally UP and IPv6 can send and receive packets
over it. They just happen to be returned to the sender by the
link-layer below the IPv6 layer. This behaviour is functionally no
different to when a physical loopback cable/plug is plugged into a
physical interface.
IPv6 tries to be fairly generic with definitions such as 'link' and
'interface' to be future proof. Here's the RFC 8200 definitons:
"link a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer
immediately below IPv6. Examples are Ethernets [...];
and internet-layer or higher-layer "tunnels",
such as tunnels over IPv4 or IPv6 itself.
interface a node's attachment to a link."
The loopback virtual interface is providing both "a communication
facility [...] over which nodes can communicate at the link layer,
i.e., the layer immediately below IPv6" and an "attachment to a link".
So the loopback virtual interface is by definition a interface per the
IPv6 specification, and therefore requires a link-local address to be
compliant.
Regards,
Mark.