Skip to main content

IPv6 Neighbor Discovery Multicast and Anycast Address Listener Subscription
draft-ietf-6lo-multicast-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-multicast-registration@ietf.org, ek.ietf@gmail.com, rfc-editor@rfc-editor.org, shwetha.bhandari@gmail.com
Subject: Protocol Action: 'IPv6 Neighbor Discovery Multicast and Anycast Address Listener Subscription' to Proposed Standard (draft-ietf-6lo-multicast-registration-16.txt)

The IESG has approved the following document:
- 'IPv6 Neighbor Discovery Multicast and Anycast Address Listener
   Subscription'
  (draft-ietf-6lo-multicast-registration-16.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-multicast-registration/


Ballot Text

Technical Summary

   This document updates the 6LoWPAN extensions to IPv6 Neighbor
   Discovery (RFC 4861, RFC 8505) to enable a listener to subscribe to
   an IPv6 anycast or multicast address; the document updates RPL (RFC
   6550, RFC 6553) to add a new Non-Storing Multicast Mode and a new
   support for anycast addresses in Storing and Non-Storing Modes.  This
   document extends RFC 9010 to enable the 6LR to inject the anycast and
   multicast addresses in RPL.

Working Group Summary

This I-D received feedback and support from 6lo participants. It was jointly reviewed
with ROLL workgroup. 6man was also included in the notifications and review.
There was nothing controversial.

Document Quality

   Are there existing implementations of the protocol?  Have a 
   significant number of vendors indicated their plan to
   implement the specification?  Are there any reviewers that
   merit special mention as having done a thorough review,
   e.g., one that resulted in important changes or a
   conclusion that the document had no substantive issues?  If
   there was a MIB Doctor, Media Type, or other Expert Review,
   what was its course (briefly)?  In the case of a Media Type
   Review, on what date was the request posted?

This document was developed for Wi-Sun and is incorporated in Wi-Sun FAN 1.1.
So all products that conform FAN 1.1 will also conform this.

Personnel

   The Document Shepherd for this document is Shwetha Bhandari. The
   Responsible Area Director was Erik Kline until past the IETF Last Call,
   when Éric Vyncke has become the 6LO responsible AD.

IANA Note

The I Field is defined in [RFC9010] but is missing from the registry, so the bit positions must be added for completeness in conformance with the RFC.

IANA is requested to make changes under the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" [IANA.ICMP] and the "Routing Protocol for Low Power and Lossy Networks (RPL)" [IANA.RPL] registry groupings. Too many requests to be listed here. The registration procedures of the to-be-created registries are "standard action" or "IETF Review" or "IESG action".


RFC Editor Note