IPv6 Neighbor Discovery Prefix Registration
draft-ietf-6lo-prefix-registration-18

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: 6lo-chairs@ietf.org, 6lo@ietf.org, The IESG <iesg@ietf.org>, draft-ietf-6lo-prefix-registration@ietf.org, evyncke@cisco.com, rfc-editor@rfc-editor.org, shwetha.bhandari@gmail.com
Subject: Protocol Action: 'IPv6 Neighbor Discovery Prefix Registration' to Proposed Standard (draft-ietf-6lo-prefix-registration-15.txt)

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/

Ballot Text

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

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