Hi Adnan, We do ask that you submit this latest update as a new version to Datatracker via the ID submission tool. This way it's clear where the change originated. From there, we can more easily acquire AD approval and proceed with the usual editing process.
Thank you, RFC Editor/st > On Jul 27, 2025, at 10:09 AM, Adnan Rashid <[email protected]> wrote: > > 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]
