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

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

[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.

Per RFC 4291 "IP Version 6 Addressing Architecture", all IPv6
interfaces are required to have Link-Local addresses, so therefore
there should always be a link-local address available to use as the
source address for an ND NS.

"2.1. Addressing Model"

...

"All interfaces are required to have at least one Link-Local unicast
   address (see Section 2.8 for additional required addresses)."

I have submitted a more specific bug regarding no Link-Local
address/prefix on the Linux kernel loopback interface through RedHat
bugzilla as I use Fedora 30, however it doesn't seem to have been
looked at yet.

"Loopback network interface does not have a Link Local address,
contrary to RFC 4291"
https://bugzilla.redhat.com/show_bug.cgi?id=1706709


Thanks very much,
Mark.

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

[Su Yanjun]

在 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.
>
> Per RFC 4291 "IP Version 6 Addressing Architecture", all IPv6
> interfaces are required to have Link-Local addresses, so therefore
> there should always be a link-local address available to use as the
> source address for an ND NS.

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.

And what you say is related to the lo interface.  I'm not sure whether 
the lo interface needs a ll adreess.

IMO the ll address is used to get l2 address by sending ND ns. The lo is 
very special.

Thanks

Su

>
> "2.1. Addressing Model"
>
> ...
>
> "All interfaces are required to have at least one Link-Local unicast
>     address (see Section 2.8 for additional required addresses)."
>
> I have submitted a more specific bug regarding no Link-Local
> address/prefix on the Linux kernel loopback interface through RedHat
> bugzilla as I use Fedora 30, however it doesn't seem to have been
> looked at yet.
>
> "Loopback network interface does not have a Link Local address,
> contrary to RFC 4291"
> https://bugzilla.redhat.com/show_bug.cgi?id=1706709
>
>
> Thanks very much,
> Mark.
>
>

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

[Mark Smith]

Hi Su,

On Tue, 30 Jul 2019 at 19:41, Su Yanjun <suyj.fnst@cn.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.

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.

Even special NBMA links/interfaces are not excluded from this
requirement, as Link-Local addresses are formed and used in the NBMA
operation, per RFC 2491.

> IMO the ll address is used to get l2 address by sending ND ns. The lo is
> very special.
>

From an IPv6 perspective, the virtual loopback interface isn't all that special.

A general theme of IPv6 is to try to treat things as similarly as
possible, compared to the IPv4 where a lot of things were treated as
special cases (e.g. ND runs over ICMPv4, in comparison to ARP running
directly and only over Ethernet/802.3. RFC 4861 treats point-to-point
links as multicast capable links, emulating multicast if necessary.
RAs and DHCPv6 are used over PPP links to carry parameters, rather
than using IPv6CP, compared to using IPv4 IPCP to carry e.g. DNS
addresses)

The main place the loopback behaviour causes issues is with IPv6 ND
Duplicate Address Detection. Appendix A of RFC 4861, and RFC 7527,
"Enhanced Duplicate Address Detection" discuss how to deal with that.
Some physical interfaces can be in loopback mode too, so IPv6 DAD has
to deal with that temporary situation.

LL addresses are and can be used for lots of things, including by
end-user applications as a preference when there is a choice between a
set of LL addr(s), GUA and ULA addresses.

Here is an Internet Draft that describes the general characteristics
of Link-Local addresses with references, as well as the benefits of
and how to use them in applications.

"How to use IPv6 Link-Local Addresses in Applications"
https://tools.ietf.org/html/draft-smith-ipv6-link-locals-apps-00


Regards,
Mark.

> Thanks
>
> Su
>
> >
> > "2.1. Addressing Model"
> >
> > ...
> >
> > "All interfaces are required to have at least one Link-Local unicast
> >     address (see Section 2.8 for additional required addresses)."
> >
> > I have submitted a more specific bug regarding no Link-Local
> > address/prefix on the Linux kernel loopback interface through RedHat
> > bugzilla as I use Fedora 30, however it doesn't seem to have been
> > looked at yet.
> >
> > "Loopback network interface does not have a Link Local address,
> > contrary to RFC 4291"
> > https://bugzilla.redhat.com/show_bug.cgi?id=1706709
> >
> >
> > Thanks very much,
> > Mark.
> >
> >
>
>

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

[David Ahern]

On 7/30/19 4:28 AM, Mark Smith wrote:
> Hi Su,
> 
> On Tue, 30 Jul 2019 at 19:41, Su Yanjun <suyj.fnst@cn.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@resnulli.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.

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

[Mark Smith]

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@gmail.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@gmail.com>
Cc: Su Yanjun <suyj.fnst@cn.fujitsu.com>, <netdev@vger.kernel.org>


Hi David,


On Wed., 31 Jul. 2019, 00:11 David Ahern, <dsahern@gmail.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@resnulli.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.