Subject: Should Hosts Process the Prefix option if M bit is set in RA

From: "RAMANAA HV (rhv)" <[email-masked]>
Date: Mon, 24 Aug 2020 08:44:47 +0000

Hi,

I would like a clarification on Host behavior on Receipt of RA message with M bit set.
The RFC 4861 indicates when M bit is set the ipv6 address information has to be obtained via DHCP (stateful addressing).
If M bit is set should hosts still process  the prefix information sent in RA and install the connected routes indicated in the Prefix or ignore the prefix option.
The RFC also does not indicate DHCP to get an address only from the prefix that is advertised. Even if prefix has to be processed if DHCP obtains an address from a different prefix altogether there is no use in processing the prefix option.
How is DHCP supposed to get the prefix length of the IANA address it obtains.

Regards
Ramanaa H.V.

---

From: Vasilenko Eduard <[email-masked]>
Date: Mon, 24 Aug 2020 09:04:20 +0000

Hi Ramanaa,
RA has other flags.
Read additionally RFC 5942<https://tools.ietf.org/html/rfc4862> – you would have less questions on Prefix List.
Eduard
From: ipv6 [mailto:[email-masked]] On Behalf Of RAMANAA HV (rhv)
Sent: 24 августа 2020 г. 11:45
To: [email-masked]
Subject: Should Hosts Process the Prefix option if M bit is set in RA

Hi,

Regards
Ramanaa H.V.

---

From: Mark Smith <[email-masked]>
Date: Mon, 24 Aug 2020 19:32:25 +1000

On Mon, 24 Aug 2020, 18:47 RAMANAA HV (rhv), <rhv=[email-masked]>
wrote:

> The RFC 4861 indicates when M bit is set the ipv6 address information has
> to be obtained via DHCP (stateful addressing).
>
> If M bit is set should hosts still process  the prefix information sent in
> RA and install the connected routes indicated in the Prefix or ignore the
> prefix option.
>
PIOs are to be processed independently of the RA M bit, with the PIO A and
L bits processed as specified.

That can mean a host will have both DHCPv6 supplied addresses and SLAAC
addresses. This is legitimate, and could occur during a transition from
DHCPv6 addressing and SLAAC addressing, or vice versa.

The L bit is also to be obeyed regardless of the M bit.

The RFC also does not indicate DHCP to get an address only from the prefix
> that is advertised. Even if prefix has to be processed if DHCP obtains an
> address from a different prefix altogether there is no use in processing
> the prefix option.
>

RFC 5942 explains this.

In IPv4, the subnet mask both defined the amount of addresses/address space
assigned to the link, and if they are "on-link", meaning to ARP for them.

IPv6 has taken away that overloading of whether to "ARP" or ND for on-link
destinations - this is what the PIO option with the L bit set tells a host
- to ND for addresses within the prefix specified in the PIO. DHCPv6
doesn't tell as host that, which is why an RA PIO has to be processed even
with the M bit set.

Regards,
Mark.

>
> Regards
>
> Ramanaa H.V.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: "RAMANAA HV (rhv)" <[email-masked]>
Date: Mon, 24 Aug 2020 10:44:55 +0000

Hi Mark,

I will go through the RFC5942 .

I also have few doubts:

  1.  Should we mandate that the routers have to advertise the same prefix that will be assigned via DHCP? There are 2 scenarios where DHCP prefix and prefix from RA do not match.
     *   Prefix is an optional parameter which can be skipped . there can be a case where none of the routers sends Prefix .
     *   An host can obtain RA’s from multiple routers each providing their own prefix and the DHCP server can be a different entity which can provide an address which does not belong to any prefix advertised by any routers .

  1.  Also if we assume the prefix from a router and address assigned by the DHPC is also from the same prefix. The lifetimes in RA’s can be different from the DHCP lease timers. If the prefix lifetime expires should DHCP release the address?

  1.  Should not the preferred default router be the router that advertises the prefix that the DHCP server also assigns. Say we have obtained RA’s from multiple routers and picked one of the router as default. Once DHCP obtains the address we can match the address from the prefixes advertised from different routers and select the router which has sent the prefix matching the address assigned by DHCP and change the default router to this router. I do not see the DHCP and ND RFC discussing anything on these lines.

Regards
Ramanaa H.V.

From: Mark Smith <[email-masked]>
Date: Monday, 24 August 2020 at 3:02 PM
To: RAMANAA HV <[email-masked]>
Cc: 6man WG <[email-masked]>
Subject: Re: Should Hosts Process the Prefix option if M bit is set in RA

On Mon, 24 Aug 2020, 18:47 RAMANAA HV (rhv), <rhv=[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I would like a clarification on Host behavior on Receipt of RA message with M bit set.
The RFC 4861 indicates when M bit is set the ipv6 address information has to be obtained via DHCP (stateful addressing).
If M bit is set should hosts still process  the prefix information sent in RA and install the connected routes indicated in the Prefix or ignore the prefix option.
PIOs are to be processed independently of the RA M bit, with the PIO A and L bits processed as specified.

That can mean a host will have both DHCPv6 supplied addresses and SLAAC addresses. This is legitimate, and could occur during a transition from DHCPv6 addressing and SLAAC addressing, or vice versa.

RFC 5942 explains this.

In IPv4, the subnet mask both defined the amount of addresses/address space assigned to the link, and if they are "on-link", meaning to ARP for them.

IPv6 has taken away that overloading of whether to "ARP" or ND for on-link destinations - this is what the PIO option with the L bit set tells a host - to ND for addresses within the prefix specified in the PIO. DHCPv6 doesn't tell as host that, which is why an RA PIO has to be processed even with the M bit set.

Regards,
Mark.

Regards
Ramanaa H.V.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]<mailto:[email-masked]>
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Mark Smith <[email-masked]>
Date: Mon, 24 Aug 2020 20:48:57 +1000

> I will go through the RFC5942 .

You need to do that first.

>
> I also have few doubts:
>
>
>
>    1. Should we mandate that the routers have to advertise the same
>    prefix that will be assigned via DHCP? There are 2 scenarios where DHCP
>    prefix and prefix from RA do not match.
>       1. Prefix is an optional parameter which can be skipped . there can
>       be a case where none of the routers sends Prefix .
>       2. An host can obtain RA’s from multiple routers each providing
>       their own prefix and the DHCP server can be a different entity which can
>       provide an address which does not belong to any prefix advertised by any
>       routers .
>
>
>
>    1. Also if we assume the prefix from a router and address assigned by
>    the DHPC is also from the same prefix. The lifetimes in RA’s can be
>    different from the DHCP lease timers. If the prefix lifetime expires should
>    DHCP release the address?
>
>
>
>    1. Should not the preferred default router be the router that
>    advertises the prefix that the DHCP server also assigns. Say we have
>    obtained RA’s from multiple routers and picked one of the router as
>    default. Once DHCP obtains the address we can match the address from the
>    prefixes advertised from different routers and select the router which has
>    sent the prefix matching the address assigned by DHCP and change the
>    default router to this router. I do not see the DHCP and ND RFC discussing
>    anything on these lines.
>
>
>
> Regards
>
> Ramanaa H.V.
>
>
>
> *From: *Mark Smith <[email-masked]>
> *Date: *Monday, 24 August 2020 at 3:02 PM
> *To: *RAMANAA HV <[email-masked]>
> *Cc: *6man WG <[email-masked]>
> *Subject: *Re: Should Hosts Process the Prefix option if M bit is set in
> RA
>
>
>
>
>
> On Mon, 24 Aug 2020, 18:47 RAMANAA HV (rhv), <rhv=
> [email-masked]> wrote:
>
> Hi,
>
>
>
> In IPv4, the subnet mask both defined the amount of addresses/address
> space assigned to the link, and if they are "on-link", meaning to ARP for
> them.
>
>
>

---

From: Fernando Gont <[email-masked]>
Date: Mon, 24 Aug 2020 07:57:00 -0300

On 24/8/20 06:32, Mark Smith wrote:
> 
> 
> On Mon, 24 Aug 2020, 18:47 RAMANAA HV (rhv), 
> <rhv=[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Hi,____
> 
>     __ __
> 
>     I would like a clarification on Host behavior on Receipt of RA
>     message with M bit set.____
> 
>     The RFC 4861 indicates when M bit is set the ipv6 address
>     information has to be obtained via DHCP (stateful addressing).____
> 
>     If M bit is set should hosts still process  the prefix information
>     sent in RA and install the connected routes indicated in the Prefix
>     or ignore the prefix option.
> 

FWIW, the CPE provided by my ISP (a Sagemcom CPE) used to advertise, by 
default, a global prefix via a PIO with both the A and L bits set, and 
would also set the M and O bits of the RA.

Ubuntu would thus configure addresses with SLAAC *and* with DHCPv6. 
Unfortunately, the DHCPv6 server at the CPE would lease addresses, 
sequentially, and from a small pool, thus leading to predictable 
addresses (::1000 and on).

So I'd end up with RFC7217 + RFC4941 + predictable DHCPv6.. kind of 
annoying, because not only was the DHCPv6 address predictable, but it 
also wasn't employed for anything useful.

It wasn't possible to change the settings in the CPE... so that was yet 
one more reason for me replacing the CPE with something else. :-)

-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Fernando Gont <[email-masked]>
Date: Tue, 25 Aug 2020 00:10:49 -0300

On 24/8/20 05:44, RAMANAA HV (rhv) wrote:
[....]
> I would like a clarification on Host behavior on Receipt of RA message 

Short version of the question: It's largely unspecified. Please see: 
https://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem

The whole thing is tricky.

On one hand, one might be tempted to say "If there's a PIO with A set, 
just do SLAAC". For example, I had a CPE router that would set both M 
and O in RAs, advertise a prefix via a PIO with A set, and DHCPv6-lease 
addresses from the same prefix.

The outcome was that you'd typically end-up with:
1) One SLAAC stable address (RFC7217),
2) One SLAAC temporary address (RFC4941), and,
3) On DHCPv6-leased address.

Since 1) and 3) are equivalent, 3) would be useless. And, what's worse, 
many DHCPv6 servers produce predictable addresses... so your nodes would 
be vulnerable to address scans.

On the other hand, in theory the local DHCPv6 server could lease 
addresses from a different prefix, and in such case configuring both 
SLAAC and DHCPv6 addresses could make sense. -- but I don't remembering 
encountering this scenario in the real world.

[...]
> How is DHCP supposed to get the prefix length of the IANA address it 

It doesn't. DHCPv6 leases addresses. So, either a PIO (with L set) or a 
RIO signals that the prefix is on-link, or you end up sending all 
packets to the default router (the one sending RAs), even if the target 
nodes actually happened to be on-link.

Thanks!

Regards,

---

From: Mark Smith <[email-masked]>
Date: Tue, 25 Aug 2020 13:32:07 +1000

On Tue, 25 Aug 2020, 13:16 Fernando Gont, <[email-masked]> wrote:

> Since 1) and 3) are equivalent, 3) would be useless.

I don't agree. A transition from SLAAC to DHCPv6 is a case where they could
be coexisting.

The thing to remember is that SLAAC, DHCPv6 and manually configured are
address configuration methods.

Once the host has one or more addresses via one or more address
configuration methods, there method to acquire an address loses much of its
relevance - the significant properties of the address to the host and
applications is what scope it is, and what it's valid and preferred
lifetime.

If we prohibited DHCPv6 and SLAAC coexisting, how about prohibiting SLAAC
and manually configured? If an address is manually configured, immediately
remove all SLAAC and/or DHCPv6 addresses, because manual configuration is
the opposite of dynamic configuration?

And, what's worse,

---

From: Fernando Gont <[email-masked]>
Date: Tue, 25 Aug 2020 01:29:15 -0300

On 25/8/20 00:32, Mark Smith wrote:
[....]
> I don't agree. A transition from SLAAC to DHCPv6 is a case where they 
> could be coexisting.

Well, DHCPv6 is optional, so... In reality, I'm not sure you'd ever 
"transition to DHCPv6". Also, if you ewre trying to transition to 
DHCPv6, what would be the point of keeping advertising PIOs?

> address configuration methods.

SLAAC and DHCPv6 are automatic -- that's the point. You may want to 
configure one specific address (manual).. but as for DHCPv6 or SLAAC, 
you just want to automatically configure some address.

> configuration methods, there method to acquire an address loses much of 
> its relevance - the significant properties of the address to the host 
> and applications is what scope it is, and what it's valid and preferred 
> lifetime.

Yes and no.

with DHCPv6, it's up to the server what you get to do. With SLAAC, for 
good or bad, you have anarchy to do what you please. -- including the 
fact that with SLAAC you can generate an unpredictable ipv6 address, 
while with dhcpv6 you are at the mercy of what the dhcpv6 server does.

> If we prohibited DHCPv6 and SLAAC coexisting, how about prohibiting 
> SLAAC and manually configured? 

I didn't say "prohibiting" as in "just pop a network configuration 
error". I'd say "refrain from using it". In my own setup, I couldn't 
stop the CPE from doing both SLAAC and DHCPv6, and there wasn't an 
obvious toggle in the network manager applet to disable dhcpv6.

I wished I had had such option in both the CPE and Ubuntu.

> If an address is manually configured, 
> immediately remove all SLAAC and/or DHCPv6 addresses, because manual 
> configuration is the opposite of dynamic configuration?

manual configuration is generally meant to achive something different 
than slaac/dhcpv6. -- whreas, for the most part slaac and dhcpv6 are 
meant to achieve the same goal.

---

From: Sander Steffann <[email-masked]>
Date: Tue, 25 Aug 2020 09:04:12 +0200

Hi Fernando,

> The outcome was that you'd typically end-up with> 1) One SLAAC stable address (RFC7217),> 2) One SLAAC temporary address
(RFC4941), and,> 3) On DHCPv6-leased address.> > Since 1) and 3) are
equivalent, 3) would be useless. And, what's worse,> many DHCPv6 servers
produce predictable addresses... so your nodes would> be vulnerable to
address scans.
I disagree. There are cases where you'd want centrally managed addresses
(DHCPv6) together with SLAAC temporary addresses. In those cases 1)
would be useless.

An example scenario of how it might work in an enterprise hetwork:

You have a corporate network where you have a mix of Windows clients,
IOS devices and Android devices. The Windows clients need to get a
DHCPv6 lease for remote management etc. The IOS devices don't get a
DHCPv6 lease, and the Android devices can't. All of them need SLAAC
temporary addresses for outbound traffic.

In the current situation I can configure the DHCPv6 server to only give
out leases to the Windows clients. IOS devices will ask for a DHCPv6
lease but won't get one, and the Android devices won't even ask.

The only redundant part is 1) for the Windows clients, as they have 3).

Now, the usual answer I get to this example is to set up different
layer-2 domains. Possible, but do we really want to force an extra VLAN
for more controlled DHCPv6?

Cheers,
Sander

---

From: Fernando Gont <[email-masked]>
Date: Tue, 25 Aug 2020 05:23:53 -0300

Hi, Sander,

> (DHCPv6) together with SLAAC temporary addresses. In those cases 1)

Agreed. What I meant is that having both 1 and 3 at the same time, for 
the same prefix, doesn't seem to make sense. -- one will be configured, 
but not used.

And, for hosts that configure addresses with all available mechanisms by 
default, they run the risk that even when they do RFC7217 and/or 
RFC4941, the DHCPv6 server leases them a predictable address. -- that 
was my case at home, and I didn't find an obvious knob in network 
manager to ignore the "M" bit in RAs..

And, that said, if you are doing stable addresses with DHCPv6, why not 
also do temp addresses with DHCPv6, too?

> for more controlled DHCPv6?

One would probably want these things to happen in a more coherent 
manner, so to speak. :-) I just don't sympathize a lot with the plethora 
of possible outcomes described in 
draft-ietf-v6ops-dhcpv6-slaac-problem., I must say...