Re: draft-ietf-6man-slaac-renum: Conveying Information in Router Advertisement (RA) Messages

This text seems correct to me. I suspect that implementations generally
already do this, but advising them to do it is not a bad idea.

On Thu, Jun 9, 2022 at 4:03 AM Fernando Gont <fgont@si6networks.com> wrote:

> Hi,
>
> Section 4.4 of draft-ietf-6man-slaac-renum-03 contains a "[TBD]"
> placeholder for text that had not yet been incorporated from the
> individual submission version of the document
> (draft-gont-6man-slaac-renum).
>
> We'd like to hear from you regarding whether you have any thoughts or
> objections about incorporating the following text for Section 4.4:
>
> ---- cut here ----
> 4.4.  Conveying Information in Router Advertisement (RA) Messages
>
>     Intentionally omitting information in Router Advertisements may
>     prevent the propagation of such information, and may represent a
>     challenge for hosts that need to infer whether they have received a
>     complete set of SLAAC configuration information.  As a result, this
>     section aims that, to the extent that is possible, RA messages
>     contain a complete set of SLAAC information.
>
>     This document replaces the following text from 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.
>
>        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.
>
>     with:
>
>        When sending Router Advertisements, a router SHOULD include all
>        options.
>
>        If including all options would cause 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. and try to convey options of the same type in the same
>        packet.
>
>     RATIONALE:
>
>        *  Sending information in the smallest possible number of packets
>           was somewhat already implied by the original text in [RFC4861].
>           Including all options when sending RAs leads to simpler code
>           (as opposed to dealing with special cases where specific
>           information is intentionally omitted), and also helps hosts
>           infer when they have received a complete set of SLAAC
>           configuration information.  Note that while [RFC4861] allowed
>           some RAs to omit some options, to the best of the authors'
>           knowledge, all SLAAC router implementations always send all
>           options in the smallest possible number of packets.  Therefore,
>           this section simply aligns the protocol specifications with
>           existing implementation practice.
> ---- cut here ----
>
> Thanks!
>
> Regards,
> --
> Fernando Gont
> SI6 Networks
> e-mail: fgont@si6networks.com
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>