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

Hi Fernando,
How long host should wait next/last RA to make sure that all information was received?
To start deprecating prefixes.
Eduard
-----Original Message-----
From: ipv6 [mailto:ipv6-bounces@ietf.org] On Behalf Of Fernando Gont
Sent: Thursday, June 9, 2022 11:03 AM
To: ipv6@ietf.org
Cc: draft-ietf-6man-slaac-renum@ietf.org
Subject: draft-ietf-6man-slaac-renum: Conveying Information in Router Advertisement (RA) Messages

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