netdev - Re: 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>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <8e63c39f-3117-7446-e204-df076f43a454@gmail.com>
Date:   Tue, 30 Jul 2019 08:11:03 -0600
From:   David Ahern <dsahern@...il.com>
To:     Mark Smith <markzzzsmith@...il.com>,
        Su Yanjun <suyj.fnst@...fujitsu.com>
Cc:     netdev@...r.kernel.org
Subject: Re: net: ipv6: Fix a bug in ndisc_send_ns when netdev only has a
 global address

On 7/30/19 4:28 AM, Mark Smith wrote:
> Hi Su,
> 
> On Tue, 30 Jul 2019 at 19:41, Su Yanjun <suyj.fnst@...fujitsu.com> wrote:
>>
>>
>> 在 2019/7/30 16:15, Mark Smith 写道:
>>> Hi,
>>>
>>> I'm not subscribed to the Linux netdev mailing list, so I can't
>>> directly reply to the patch email.
>>>
>>> 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.

> 
> This specific, explicit requirement goes as back as far as RFC 2373
> from 1998, the ancestor of RFC 4291. It is also heavily implied in RFC
> 1884s, 2.7 A Node's Required Addresses.
> 
>> And what you say is related to the lo interface.  I'm not sure whether
>> the lo interface needs a ll adreess.
>>
> 
> 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.