Hi Adnan, Thank you for the clarification!
Sincerely, RFC Editor/st > On Jul 29, 2025, at 4:05 PM, Adnan Rashid <[email protected]> wrote: > > Dear Sarah, > > I am not the Author of this draft, and I can not do what you told me to do. > I am sure Pascal will do it as soon as possible, as I already highlighted > this error in the last IETF meeting. > > > On Mon, Jul 28, 2025 at 4:01 PM Sarah Tarrant <[email protected]> > wrote: > 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 > > > > -- > Regards, > > Adnan _______________________________________________ 6lo mailing list -- [email protected] To unsubscribe send an email to [email protected]
