Subject: On sending SLAAC information into split RAs

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Mar 2020 14:22:30 -0300

Folks,

A related issue was raised 
(https://mailarchive.ietf.org/arch/msg/ipv6/EFQKtYNNLI_L7vLq217aSXX-LUM/) 
in the context of draft-gont-6man-slaac-renum, but I felt like 
discussing the topic in its own thread.

SLAAC routers could, in theory, split the information to be conveyed in 
RAs into multiple RA packets.

IMO, not only I'd be curious about such an implementation approach 
(haven't seen found one so far), but I also believe that:

* it would unnecessarily increase multicast traffic
* it increases the chances of configuration inconsistencies

So, in that light, I'm wondering the wg thoughts on the topic. Namely, 
whether:

1) While theoretically allowed, this doesn't have practical implications 
because all infoarmation is always sent in the smallest possible number 
of packets

2) We may want to be explicit about it, and recommend SLAAC routers that 
SLAAC information should be conveyed in the smallest possible number of 
packets (e.g. one packet if you can fit all the information in one)

Thoughts?

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

---

From: Timothy Winters <[email-masked]>
Date: Mon, 9 Mar 2020 13:28:16 -0400

Hi Fernando,

While I think we could say something about this, I've not seen a Router
implementation split this type of information up into multiple messages.
 Probably safest to recommend that it be done in one message.

Regards,
Tim

On Mon, Mar 9, 2020 at 1:23 PM Fernando Gont <[email-masked]> wrote:

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 9 Mar 2020 16:09:53 -0300

Hello, Tim,

Thanks for your timely and useful data! In-line....

On 9/3/20 14:28, Timothy Winters wrote:
> implementation split this type of information up into multiple 
> messages.   Probably safest to recommend that it be done in one message.

Looking at Section 6.2.3 of RFC4861, it seems such behavior is implicit.

I'm curious: Have you seen any implementations that "omit" information 
as allowed in Section 6.2.3 of RFC4861:

   "A router MAY choose not to include some or all options when sending
    unsolicited Router Advertisements.  For example, if prefix lifetimes
    are much longer than AdvDefaultLifetime, including them every few
    advertisements may be sufficient.  However, when responding to a
    Router Solicitation or while sending the first few initial
    unsolicited advertisements, a router SHOULD include all options so
    that all information (e.g., prefixes) is propagated quickly during
    system initialization."

I've never seen one myself, and also think that it implies more trouble 
(increased code complexity, etc.)

So our plan is to have this doc update this text:

---- cut here ----
    A router MAY choose not to include some or all options when sending
    unsolicited Router Advertisements.  For example, if prefix lifetimes
    are much longer than AdvDefaultLifetime, including them every few
    advertisements may be sufficient.  However, when responding to a
    Router Solicitation or while sending the first few initial
    unsolicited advertisements, a router SHOULD include all options so
    that all information (e.g., prefixes) is propagated quickly during
    system initialization.

    If including all options causes the size of an advertisement to
    exceed the link MTU, multiple advertisements can be sent, each
    containing a subset of the options.
---- cut here ----

with this:

---- cut here ----
    When sending Router Advertisements, a router SHOULD include all
    options wso that all information (e.g., prefixes) propagates
    quickly, and hosts result in more uniform configuration.

    If including all options causes the size of an advertisement to
    exceed the link MTU, multiple advertisements can be sent, each
    containing a subset of the options. In all cases, routers SHOULD
    convey all information using the smallest possible number of
    packets.
---- cut here ----

Thoughts?

Thanks!

Cheers,

---

From: Timothy Winters <[email-masked]>
Date: Mon, 9 Mar 2020 16:50:57 -0400

Hi Fernando,
    My responses are inline.

> (increased code complexity, etc.)
I have never seen this in Implementation, but I haven't seen a lot of
loaded RAs loaded with options.

> Made some small changes to the first paragraph.

When sending Router Advertisements, a router SHOULD include all
options so that all information (e.g., prefixes) propagates
quickly resulting in hosts having the same information available.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 09 Mar 2020 20:05:12 -0400

Fernando Gont <[email-masked]> wrote:
    > (https://mailarchive.ietf.org/arch/msg/ipv6/EFQKtYNNLI_L7vLq217aSXX-LUM/) in
    > the context of draft-gont-6man-slaac-renum, but I felt like discussing the
    > topic in its own thread.

    > SLAAC routers could, in theory, split the information to be conveyed in RAs
    > into multiple RA packets.

    > IMO, not only I'd be curious about such an implementation approach (haven't
    > seen found one so far), but I also believe that:

    > because all infoarmation is always sent in the smallest possible number of
    > packets

As we add new things to RAs, we will hit a point where we have to send
things in more than one packet, and then we'll find out which clients fall
over, and how long it takes to upgrade them, etc.

I would feel better about this if I was reassured that Tim's team was already
testing this scenario in his lab.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Fernando Gont <[email-masked]>
Date: Tue, 10 Mar 2020 00:16:29 -0300

> over, and how long it takes to upgrade them, etc.

FWIW, even in that case, *nothing* breaks here.

The algorithm we specified in draft-gont-6man-slaac-renum un-prefers 
addresses for a given prefix IF the host receives two consecutive RAs 
that contain PIOs, but none of such PIOs correspond to the prefix in 
question.

That means, in order for this algorithm to incorrectly un-prefer a 
prefix, PIOs would need to be split into more than three packets.

In order for a prefix to be incorrectly invalidated, PIO information 
would need to be split into 5 different RAs, with each RA carrying at 
least one PIO other than the one being invalidated.

> testing this scenario in his lab.

Testing what, specifically?

Thanks!

Cheers,

---

From: Philip Homburg <[email-masked]>
Date: Tue, 10 Mar 2020 11:39:47 +0100

>packets (e.g. one packet if you can fit all the information in one)

To rely on all information being in one packet, you have to change the 
standard to 'MUST send all information in one RA'.

If you say SHOULD, then it is always possible that there will be a good
operational reason that a router will send multiple RAs.

When we change host behavior, we have to make sure that that behavior is
valid for a very long time. Now restricting the number of RAs because it
seems convenient may cause a lot of trouble later on.

(Well, I'm a fan of DHCP, so actually restricting RAs would a be a good thing)

---

From: Timothy Winters <[email-masked]>
Date: Tue, 10 Mar 2020 08:38:20 -0400

Hi Michael,
On Mon, Mar 9, 2020 at 8:10 PM Michael Richardson <[email-masked]>
wrote:

>     > (
> https://mailarchive.ietf.org/arch/msg/ipv6/EFQKtYNNLI_L7vLq217aSXX-LUM/)
> in
> (haven't
We haven't tested for loaded RA options in any of the IPv6 Ready Test
Cases.    The real issue is to test this you need to configure the device
to need to transmit that many, which is difficult.

---

From: [email-masked]
Date: Tue, 10 Mar 2020 13:49:42 +0100

> We haven't tested for loaded RA options in any of the IPv6 Ready Test Cases.    The real issue is to test this you need to configure the device to need to transmit that many, which is difficult.

I guess I should resubmit the universal RA option draft...

Ole

---

From: Michael Richardson <[email-masked]>
Date: Tue, 10 Mar 2020 09:13:33 -0400

> FWIW, even in that case, *nothing* breaks here.

yes, I know that't the theory :-)

    > addresses for a given prefix IF the host receives two consecutive RAs that
    > contain PIOs, but none of such PIOs correspond to the prefix in question.

I read that and I think it does a good job.
I just wonder if spreading things out into multiple packets more often might
have a beneficial impact on interoperability :-)

    > Testing what, specifically?

having info spread into multiple packets.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 11 Mar 2020 00:22:55 -0300

> seems convenient may cause a lot of trouble later on.

FWIW, nothing in our proposal "restricts the number of RAs". If 
anything, there's an expectation on how you (unnecessarily) *spread* 
information. But nothing in our doc limits the amount of information you 
can convey in SLAAC.

Thanks,