Subject: Re: draft-gont-6man-slaac-renum: Algorithm (Section 4.5) in the presence of Router Lifetime=0

From: Philip Homburg <[email-masked]>
Date: Wed, 01 Apr 2020 14:00:58 +0200

>2) RFC8028 requires that PIOs be associated with routers (otherwise in a 
>multiprefix network scenario, your packets could be egress-filtered). 
>Hence what one router advertises shouldn't affect the behavior wrt other 
>routers.

Note that RFC 8028 only comes into play if you have multiple uplinks and
have routers that do not cooperate.

If all routers know where traffic should go, then it doesn't matter which
default router is used by a host.

In other words, if routers are smart, then hosts that only implement RFC 4861
are fine.

---

From: Richard Patterson <[email-masked]>
Date: Wed, 1 Apr 2020 17:45:44 +0000

On Wed, 1 Apr 2020 at 03:15, Jen Linkova <[email-masked]> wrote:

>
> Keep in mind there 3, not two signals here a router can send:
> 1) PREFIX A has the property X (e.g. is onlink or suitable for SLAAC)
> 2) PREFIX A does not have the property X (e.g. the prefix is not onlink)
> 3) no data about PREFIX A whatsoever.
>

The third "Absence of evidence is not evidence of absence" concern could be
mitigated somewhat by allowing the PIO option within Router Solicits,
allowing end-hosts to proactively check the link for the prefix they wish
to continue using.  Not too dissimilar to including an IA option in a
DHCPv6 Solicit.

Obviously not a quick fix as it requires development on both sides, but
thought I'd throw it out there as a silly idea.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 01 Apr 2020 20:33:19 +0200

In your letter dated Wed, 1 Apr 2020 17:45:44 +0000 you wrote:
>--===============8727173341808635571==
>Content-Type: multipart/alternative; boundary="00000000000095e88205a23e41ff"
>
>--00000000000095e88205a23e41ff

I think it is important to have something that works with unmodified routers.

I'm also not convinced that having a host send a packet just before a 
prefix expires is 'easy'. I.e. the RS maybe lost so the host has to schedule
this well in advance, has to be prepared for retries, etc.

Of course, if sending an RS solves a lot more issues, then it may be worth
it.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 5 Apr 2020 00:19:32 -0300

On 31/3/20 23:14, Jen Linkova wrote:
[....]
>>> last time I checked the Rule 5.5 was not widely supported, which is
>>> very sad indeed.
>>> I'd be very happy to be proved wrong.
>>
>> I will check and report back.
> 
> Would be appreciated, thanks!

I promised I'd report back, so...

This is not really a full report, but since I happened to be looking at 
the Linux source code, I fel like posting a quick note:

* Linux does *not* support Rule 5.5 of RFC6724.  (see function 
ipv6_get_saddr_eval() in sys/net/ipv6/addrconf.c)

* OpenBSD does not even store which next-hop router advertised which 
prefixes (as reported by Florian)

* A quick inspection of FreeBSD seems to indicate which router 
advertised work. But I need to look in more detail to confirm this.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 5 Apr 2020 17:52:30 +1200

Note that RFC8028 is a SHOULD in RFC8504 (IPv6 Node Requirements) and that RFC8028 elevates rule 5.5. to a SHOULD. In terms of RFC engineering, that's about all we can do. If Linux and *BSD ignore SHOULDs in Node Requirements, it requires action outside the IETF I think.

Regards
   Brian

---

From: Fernando Gont <[email-masked]>
Date: Sun, 5 Apr 2020 03:19:50 -0300

Hi, Brian,

On 5/4/20 02:52, Brian E Carpenter wrote:
> Note that RFC8028 is a SHOULD in RFC8504 (IPv6 Node Requirements) and
> that RFC8028 elevates rule 5.5. to a SHOULD. In terms of RFC
> engineering, that's about all we can do.

While I'm not claiming this would necessarily make a difference, I think 
that RFC8028 should be a MUST. If you have a multi-prefix, multi-router 
network, (which we should assume could be the case), RFC8028 warrants a 
RFC2119 MUST.

I was meaning to drop the authors of RFC8504 a note about this, to add 
it to the "TODO list", at least for discussion.

> If Linux and *BSD ignore
> SHOULDs in Node Requirements, it requires action outside the IETF I
> think.

While I'm just guessing, I'd say that in many cases it's just that 
developers are not necessarily following the work we do, and at times 
they may not necessarily realize the importance of each document -- at 
times we may fail at that ourselves!

In this particular case, the changes maybe non-trivial, since it 
deviates from the simple destination-driven FIB implementations have 
traditionally employed.

In the case of Linux, I do remember using what they call "policy-based 
routing", which I bet requires the same hooks as for Rule 5.5. So it 
might be the case that simply Rule 5.5 of RFC6724 is missing -- in fact, 
the code references the previous revision of the source address 
selection RFC... so it might be the case that they simply didn't 
implement the latest bis.

I'll try to fill a bug report/feature request, and if it's just Rule 5.5 
that is missing, I'll try to implement it.

Thanks,

---

From: Florian Obser <[email-masked]>
Date: Sun, 5 Apr 2020 10:12:00 +0200

> Note that RFC8028 is a SHOULD in RFC8504 (IPv6 Node Requirements) and that RFC8028 elevates rule 5.5. to a SHOULD. In terms of RFC engineering, that's about all we can do. If Linux and *BSD ignore…

For OpenBSD it is not so much ignoring a SHOULD, we just didn't get
around to it yet. We are still stuck on RFC3484 :(
I'm typing as fast as I can, but it's a massive yak shave.

I agree, nothing else needs to be done in terms of RFC enginering.

Thanks,
Florian

-- 
I'm not entirely sure you are real.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Sun, 05 Apr 2020 12:32:04 +0000

> advertised work. But I need to look in more detail to confirm this.

Last time I checked a few weeks ago FreeBSD did not yet do 8028;  I have 
a half-done patch somewhere for this but ETIME.

/bz

---

From: Timothy Winters <[email-masked]>
Date: Mon, 6 Apr 2020 10:59:51 -0400

The new USGv6 Profile just started testing for 6724, so I think you will
start to see more implementations of this going forward.

~Tim

On Sun, Apr 5, 2020 at 8:32 AM Bjoern A. Zeeb <
[email-masked]> wrote:

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Apr 2020 08:31:39 +1200

Tim,

What does the profile say about rule 5.5 in RFC6724?

Does the profile endorse RFC8504?

Regards
   Brian Carpenter

On 07-Apr-20 02:59, Timothy Winters wrote:
> The new USGv6 Profile just started testing for 6724, so I think you will start to see more implementations of this going forward.
> 
> ~Tim
> 
> On Sun, Apr 5, 2020 at 8:32 AM Bjoern A. Zeeb <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     [email-masked] <mailto:[email-masked]>

---

From: Timothy Winters <[email-masked]>
Date: Mon, 6 Apr 2020 16:40:13 -0400

Hi Brian,

It follows all the recommendations of 8504 at a minimum.  It allows for
users to require additional things, but it follows it for all the MUST.

~Tim

On Mon, Apr 6, 2020 at 4:31 PM Brian E Carpenter <
[email-masked]> wrote:

> [email-masked] <mailto:[email-masked]>>
> wrote:
> >

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 7 Apr 2020 08:52:41 +1200

Tim,

As you know, SHOULD or RECOMMENDED in (most) standards track RFCs means that "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." It isn't logical to me that a profile would not also include all the SHOULDs.

Regards
   Brian Carpenter

On 07-Apr-20 08:40, Timothy Winters wrote:
> Hi Brian,
> 
> It follows all the recommendations of 8504 at a minimum.  It allows for users to require additional things, but it follows it for all the MUST.
> 
> ~Tim
> 
> On Mon, Apr 6, 2020 at 4:31 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     Tim,
> 
>     > On Sun, Apr 5, 2020 at 8:32 AM Bjoern A. Zeeb <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
>     >     > * A quick inspection of FreeBSD seems to indicate which router
>     >     > advertised work. But I need to look in more detail to confirm this.
>     >
>     >     [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>

---

From: Timothy Winters <[email-masked]>
Date: Mon, 6 Apr 2020 17:04:23 -0400

Hi Brian,

It's a fine line when writing a profile for both users and
implementations.  It has what is said as the base requirements that all
devices should perform which matches the MUST.  It has descriptions about
SHOULD choices and when you should really include them.  This profile
covers all types of network functions from basic host to very complex
routers.  Just getting devices to implement 6724 moves us in the correct
direction.

~Tim

On Mon, Apr 6, 2020 at 4:52 PM Brian E Carpenter <
[email-masked]> wrote:

> Tim,
>
> As you know, SHOULD or RECOMMENDED in (most) standards track RFCs means
> that "there may exist valid reasons in particular circumstances to ignore a
> particular item, but the full implications must be understood and carefully
> weighed before choosing a different course." It isn't logical to me that a
> profile would not also include all the SHOULDs.
>
> Regards
>    Brian Carpenter
>
> [email-masked] <mailto:[email-masked]>> wrote:
> >
> >     Tim,
> >
> >     > The new USGv6 Profile just started testing for 6724, so I think
> you will start to see more implementations of this going forward.
> >     >
> >     > ~Tim
> >     >
> [email-masked] <mailto:[email-masked]>
> <mailto:[email-masked] <mailto:
> [email-masked]>>> wrote:
> >     >
> >     >     Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> >     >
> >     > Administrative Requests:
> https://www.ietf.org/mailman/listinfo/ipv6
> >     >

---

From: Fernando Gont <[email-masked]>
Date: Mon, 6 Apr 2020 18:08:58 -0300

> As you know, SHOULD or RECOMMENDED in (most) standards track RFCs means that "there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must b…

That's why IMO, and in retrspective, RFC8504 should have been a "MUST" 
in the node requirements RFC. :-(

---

From: Timothy Winters <[email-masked]>
Date: Tue, 7 Apr 2020 09:55:28 -0400

Hi Fernando and Brian,

> in the node requirements RFC. :-(
The reason that wasn't included was based on this discussion from 6724
"Discussion: An IPv6 implementation is not required to remember
      which next-hops advertised which prefixes.  The conceptual models
      of IPv6 hosts in Section 5 of [RFC4861] and Section 3 of [RFC4191]
      have no such requirement.  Hence, Rule 5.5 is only applicable to
      implementations that track this information."
Since implementations don't all have the ability to track next-hops, you
can't make this a MUST.  It would be a bigger change to say everyone has to
track this by updating the models.  I'd be willinging to work on a draft
saying this if people are interested.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 7 Apr 2020 23:11:54 +0900

On Sun, Apr 5, 2020 at 3:27 PM Fernando Gont <[email-masked]> wrote:

> routing", which I bet requires the same hooks as for Rule 5.5.

It doesn't. It allows choosing separate different routing tables based on a
number of factors that are known *before* the routing lookup is performed,
such as the interface the app bound to, the socket mark, the UID, the
source address, the TOS etc. It does not allow choosing routes based on the
properties of the routes themselves. For that you either use metrics or
longest match.

> So it

TBH, I doubt that this is easy to implement. I don't think the kernel even
tracks the information of what router announced what prefix, so you'd have
to add that first. I'm not sure what the code should even do if more than
one router announces the same prefix. Does the standard say?

---

From: Fernando Gont <[email-masked]>
Date: Tue, 7 Apr 2020 13:14:32 -0300

On 7/4/20 11:11, Lorenzo Colitti wrote:
> On Sun, Apr 5, 2020 at 3:27 PM Fernando Gont <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
> It doesn't. It allows choosing separate different routing tables based 
> on a number of factors that are known *before* the routing lookup is 
> performed, such as the interface the app bound to, the socket mark, the 
> UID, the source address, the TOS etc. It does not allow choosing routes 
> based on the properties of the routes themselves. For that you either 
> use metrics or longest match.

I seemed to remember that there as something in the so-called 
policy-routing that would "influence which source address is selected". 
But I used that a while ago, and, as you note, my memory might be failing.

Thinking out loud, in any case what you describe might allow for at 
least some hackish implementation that, once a source address is 
selected, employs a subset of the available routers based on the source 
address.

> TBH, I doubt that this is easy to implement. I don't think the kernel 
> even tracks the information of what router announced what prefix, so 
> you'd have to add that first.

And things also get more interesting because, while the kernel does 
forwarding, in cases where SLAAC is implemented in userland (e.g. 
systemd or NetworkManager) those would probably need to be modified 
accordingly.

> I'm not sure what the code should even do 
> if more than one router announces the same prefix. Does the standard say?

RFC8028 essentially notes that a host should remember which prefixes 
were announced by which router. There might be some underspecified 
"corner-cases", though, such as the one I filled as an errata for RFC8028.

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Wed, 08 Apr 2020 09:02:04 +0000

On 7 Apr 2020, at 16:14, Fernando Gont wrote:

>>     might be the case that simply Rule 5.5 of RFC6724 is missing -- 
>> in
>>     fact,
>>     I'll try to fill a bug report/feature request, and if it's just 
>> Rule
>>     5.5

On at least OSX and BSDs ndp -pn will print you such information as the 
kernel does track advertising routers per prefix.

/bz

---

From: Fernando Gont <[email-masked]>
Date: Wed, 8 Apr 2020 06:14:50 -0300

> kernel does track advertising routers per prefix.

That's awesome, and a good start. (and also should make Section 4.5 of 
draft-gont-6man-slaac-renum-06 easy to implement)

Thanks a lot for the info!

Cheers,