netdev - Fwd: net: ipv6: Fix a bug in ndisc_send_ns when netdev only has a global address

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:   Wed, 31 Jul 2019 13:32:27 +1000
From:   Mark Smith <markzzzsmith@...il.com>
To:     David Ahern <dsahern@...il.com>,
        Su Yanjun <suyj.fnst@...fujitsu.com>, netdev@...r.kernel.org
Subject: Fwd: net: ipv6: Fix a bug in ndisc_send_ns when netdev only has a
 global address

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 <markzzzsmith@...il.com>
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 <dsahern@...il.com>
Cc: Su Yanjun <suyj.fnst@...fujitsu.com>, <netdev@...r.kernel.org>


Hi David,


On Wed., 31 Jul. 2019, 00:11 David Ahern, <dsahern@...il.com> wrote:
>
> On 7/30/19 4:28 AM, Mark Smith wrote:
> > Hi Su,
> >


>
> <snip>


>
> >>> This patch is not the correct solution to this issue.
> >>>
> >
> > <snip>
> >
> >> 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 <jiri@...nulli.us>
> 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>
> >
> > 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.