Hi All, As this specification is in the publishing queue, I would like to correct the mistake in the existing draft.
*As per RFC8929:* - EDAR and EDAC messages SHOULD carry an SLLAO and a TLLAO, respectively. - 3.1. Updating RFCs 6775 and 8505 ................ This specification allows the deployment of a 6LBR on the backbone where EDAR and EDAC messages coexist with classical ND. It also adds the capability to insert IPv6 ND options in the EDAR and EDAC messages. A 6BBR acting as a 6LR for the Registered Address can insert an SLLAO in the EDAR to the 6LBR in order to avoid causing a multicast NS(lookup) back. This enables the 6LBR to store the link-layer address associated with the Registered Address on a link and to serve as a mapping server as described in [UNICAST-LOOKUP]. *Corrected Text: *Both figures must add the Options field in the existing Draft 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |CodePfx|CodeSfx| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P=3| Reserved | TID | Registration Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... ROVR ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Prefix + | | + (up to 120 bits, padded with 0s) + | | + +-+-+-+-+-+-+-+-+ | |r|Prefix Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: EDAR Message Format with P == 3 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type |CodePfx|CodeSfx| Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status | TID | Registration Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ... ROVR ... | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Prefix + | | + (up to 120 bits, padded with 0s) + | | + +-+-+-+-+-+-+-+-+ | |r|Prefix Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options.. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: EDAC Message Format On Mon, Jul 7, 2025 at 9:03 PM The IESG <[email protected]> wrote: > The IESG has approved the following document: > - 'IPv6 Neighbor Discovery Prefix Registration' > (draft-ietf-6lo-prefix-registration-15.txt) as Proposed Standard > > This document is the product of the IPv6 over Networks of > Resource-constrained Nodes Working Group. > > The IESG contact persons are Erik Kline and Éric Vyncke. > > A URL of this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-6lo-prefix-registration/ > > > > > Technical Summary > > This document updates IPv6 Neighbor Discovery RFC4861 and the 6LoWPAN > extensions (RFC8505, RFC8928, RFC8929, RFC7400) to enable a node that > owns or is directly connected to a prefix to register that prefix to > neighbor routers. The registration indicates that the registered > prefix can be reached via the advertising node without a loop. The > unicast prefix registration allows to request neighbor router(s) to > redistribute the prefix in a larger routing domain regardless of the > routing protocol used in the larger domain. This document extends > RPL (RFC6550, RFC6553, RFC9010) to enable the 6LR to inject the > registered prefix in RPL. > > The text documents why the usual IPv6 techniques do not work well > in a power/bandwidth constrained network. > > During the authoring of this I-D, the WG detected that RFC 8928 > made a mistake in the flags, hence there is a new draft > draft-ietf-6lo-updating-rfc-8928 fixing the flags > > Working Group Summary > > The working group consensus was broad. In discussions on the 6LoWPAN and > RPL > mailing lists, most participants actively contributed to the evolution of > the > draft. There was general agreement on the need to extend address > registration > to cover prefixes, and improvements were made iteratively based on > widespread > feedback rather than the viewpoints of only a few individuals. > > While some discussion took place regarding the use and encoding of the new > flags (for example, the F flag and the extended use of the P-field for > prefix > registrations), the WG discussions were productive. The alternative > approaches > were debated with data and simulation results where available. In the end, > the > consensus reflected a balanced choice that improved backward compatibility > and > interoperability with existing implementations. There were no extremely > contentious points or rough consensus blocks. > > Document Quality > > Not too many reviews have been done, but the I-D was forwarded multiple > times to 6MAN for reviews: > https://mailarchive.ietf.org/arch/msg/ipv6/gcGSctZ9lWmQDqVxNL8T7kpWyCc/ > > Personnel > > The Document Shepherd for this document is Shwetha Bhandari. The > Responsible Area Director is Éric Vyncke. > > IANA Note > > IANA is requested to add one entry in two existing registries (see [IANA > #1417806]): > - P-field in "Internet Control Message Protocol version 6 (ICMPv6) > Parameters" registry > - F-flag in "6LoWPAN Capability Bits" in "Internet Control Message > Protocol version 6 (ICMPv6) Parameters" registry > > > > > RFC Editor Note > > Please process draft-ietf-6lo-updating-rfc-8928 and > draft-ietf-6lo-prefix-registration together (they should actually be in a > cluster anyway) and allocate two sequential RFC number if possible. The > lower RFC number should be for draft-ietf-6lo-updating-rfc-8928 and the > higher for draft-ietf-6lo-prefix-registration. > > Thanks > > -éric > > _______________________________________________ > 6lo mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Regards, Adnan
_______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
