I-D list for Protocols for IP Multicast RSS Feed

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-05T15:11:11.260147+00:00

IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-05T00:33:37.024019+00:00

[Ballot comment]
Thank you to Sue Hares for the GENART review.

** idnits reports:
-- The draft header indicates that this document updates RFC3307, but the
abstract doesn't seem to directly say this.

[Roman] Please explicitly state that this document updates RFC3307.

== The document doesn't use any RFC 2119 keywords, yet seems to have RFC
2119 boilerplate text.

[Roman] Remove the boilerplate text.

** Abstract. Editorial.
It recommends
replacing these allocations with a new IANA registry in the IPv6
Multicast Address Space registry group.

What does it mean to have a recommendation to replace allocations? Doesn’t it define a new allocation? The current text reads like a suggestion is being made.

** Section 3. Consider citing Section 4.1 and 4.2 of RFC8126 to explain the “Private Use” and “Experimental” ranges.

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-05T00:33:37.023908+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-04T20:03:08.841570+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Paul Wouters

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-04T18:58:23.530040+00:00

IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed

Group Address Allocation Protocol (GAAP)

2026-03-04T01:24:31.878829+00:00

Request for Early review by RTGDIR is assigned to Zheng Zhang

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-03T16:57:21.905672+00:00

[Ballot comment]
Thanks to the WG and authors for their work on this document.

I have a few minor comments that should be fixed before publication.

1) No BCP14 keywords seem to be used in the document. Please remove that template and those references.

2) RFC2908 has been obsoleted by RFC6308

3) Section 1:
s/IPv multicast address/IP multicast address

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-03T16:57:21.905579+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Ketan Talaulikar

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-03T08:27:39.782350+00:00

[Ballot comment]

I note the Shepherd writeup says "Majority of the working group is silent, but believe most of the WG silently support it. No one is against." - This seems a very weak position for a PS, and perhaps reflects a lack of review - see Eric's comment on INTAREA.

Abstract
The wording used in the abstract seems to speculate about possible recommendations, and would be better written with terms that "define" and "specify":
/It recommends replacing these allocations with a new registry/ - could this be: /recommends/replaces/?
/The document also suggests initial contents of the new registry:/ - could this be: /suggests/defines/?

The GENART review notes several concerns around the details of the requested allocations. Please check carefully and ammend these.

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-03T08:27:39.782281+00:00

[Ballot Position Update] Position for Gorry Fairhurst has been changed to No Objection from No Record

Multicast Lessons Learned from Decades of Deployment Experience

2026-03-02T23:47:57.465614+00:00

New version available: draft-ietf-pim-multicast-lessons-learned-08.txt

Multicast Lessons Learned from Decades of Deployment Experience

2026-03-02T23:47:57.462051+00:00

New version accepted (logged-in submitter: Mike McBride)

Multicast Lessons Learned from Decades of Deployment Experience

2026-03-02T23:47:57.395219+00:00

Uploaded new revision

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-02T22:25:39.143765+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Orie Steele

Multicast Lessons Learned from Decades of Deployment Experience

2026-03-02T20:50:55.329570+00:00

New version available: draft-ietf-pim-multicast-lessons-learned-07.txt

Multicast Lessons Learned from Decades of Deployment Experience

2026-03-02T20:50:55.326005+00:00

New version accepted (logged-in submitter: Mike McBride)

Multicast Lessons Learned from Decades of Deployment Experience

2026-03-02T20:50:55.271948+00:00

Uploaded new revision

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-02T17:23:35.226299+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Mike Bishop

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-02T13:59:27.698050+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-01T23:01:24.822330+00:00

[Ballot comment]
# Internet AD comments for draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-12
CC @ekline

* comment syntax:
- https://github.com/mnot/ietf-comments/blob/main/format.md

* "Handling Ballot Positions":
- https://ietf.org/about/groups/iesg/statements/handling-ballot-positions/

## Comments

* Find the referencing of RFC 4291 to be confusing, as I can't see how this
document connect the group ID to the 4291 prefix ff02::1: for
this purpose.

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-01T23:01:24.822233+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Erik Kline

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-01T05:02:31.979551+00:00

[Ballot comment]
"Abstract", paragraph 0
> This document describes limitations of the existing range of dynamic
> IPv6 multicast addresses specified in RFC3307. It recommends
> replacing these allocations with a new IANA registry in the IPv6
> Multicast Address Space registry group. The document also defines
> initial contents of the new registry: a reduced allocation for MADCAP
> (RFC2730), a range for SSM, a Private Use range, a range for
> Experimental Use, and Solicited-Node multicast addresses (which were
> not previously noted in RFC3307, Allocation Guidelines for IPv6
> Multicast Addresses).

Generally, the Abstract clearly states if the document is updating or obsoleting another document. This one mentions the document, but not that it is being updated. It is only later in the Introduction that you learn that RFC3307 is being updated.

I also agree with Gorry that for a PS document, the use of words such as "recommends" is a poor choice.

Section 1, paragraph 2
> Only one server allocation protocol has been defined at the time of
> writing (see [RFC2730]), but
> [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] advocates developing a
> decentralized, zero-configuration host allocation protocol. This
> document updates Section 4.3 of [RFC3307] to allow multiple dynamic
> allocation protocols to coexist on the same network, and so that
> dynamic IPv6 multicast group ID ranges better align with current
> practices for protocol number assignment.

I find the last sentence of the paragraph to be confusing. Which "current practices" are being referred to? Can the sentence be simplified to say something like:
"... on the same network, and to enable that the dynamic IPv6 multicast group IP ranges suggested in this document should be followed."

Section 2, paragraph 2
> However, SSM is not universally supported (see [RFC4607], Section 6
> and [RFC8815], Section 3.1). This document defines a range of
> dynamic IPv6 multicast group IDs for use in environments that do
> support SSM.

This section seems to be justifying why a range of addresses should be assigned for SSM, till it does not, based on the first sentence of the above paragraph. If SSM is not widely deployed, why not return the range to unassinged pool and maybe later, when the SSM usage picks up, a range could be allocated for it.

Section 4, paragraph 0
> This document reduces the range of group ID values available for
> MADCAP ([RFC2730]). At the time of writing, there is only one known
> implementation of MADCAP, and there are no known large-scale
> deployments. Any implementations of MADCAP (known or otherwise)
> should be updated to reflect the new group ID range set forth in
> Table 2. Any existing deployments of MADCAP should either use an
> updated implementation or operate in an environment without other
> IPv6 multicast address allocation protocols.

I will note that the Shepherd report, on the question of any existing implementation says "Nothing to implement here". While I agree that it is not protocol implementation in a traditional sense of the word, nevertheless, this document does make a note of how existing implementations could be affected by the new allocation scheme. The Shepherd report should be updated to reflect that.

This document does not use RFC2119 keywords, but contains the RFC8174
boilerplate.

The IANA review of this document seems to not have concluded yet.

No reference entries found for these items, which were mentioned in the text:
[avoiding].

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 2
> This document adheres to the IPv multicast address architecture
> outlined in [RFC4291], [RFC3307], [RFC7371], et al.

What is "IPv"?

Reference [RFC2908] to RFC2908, which was obsoleted by RFC6308 (this may be on
purpose).

Document references draft-ietf-pim-zeroconf-mcast-addr-alloc-ps-11, but -13 is
the latest available revision.

Found non-HTTP URLs in the document:

* lispers.net

These URLs in the document did not return content:

* lispers.net

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-03-01T05:02:31.979459+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Mahesh Jethanandani

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-02-27T15:40:38.680036+00:00

[Ballot comment]
Hi Nate, Dino, and Mike,

Thank you for the discussion and for the changes.

The changes made in [1] addresses all the comments in my previous ballot [2]. Much appreciated.

Cheers,
Med

[1] https://author-tools.ietf.org/iddiff?url1=draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10&url2=draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-12&difftype=--html

[2] https://mailarchive.ietf.org/arch/msg/pim/jJhkEw4kOdazy1-p7_Ou5a2JD-I/

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-02-27T15:40:38.679967+00:00

[Ballot Position Update] Position for Mohamed Boucadair has been changed to No Objection from Discuss

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-02-27T15:11:46.466020+00:00

New version available: draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-12.txt

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-02-27T15:11:46.462590+00:00

New version accepted (logged-in submitter: Nathan Karstens)

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-02-27T15:11:46.407446+00:00

Uploaded new revision

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-02-27T12:04:13.063529+00:00

[Ballot comment]
Thanks to Russ Housley for their secdir review

General: spell out acronyms on first use. MADCAP is one example.

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-02-27T12:04:13.063442+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Deb Cooley

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-02-27T05:16:34.411508+00:00

IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-02-27T05:16:34.154025+00:00

New version available: draft-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-11.txt

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-02-27T05:16:34.149981+00:00

New version accepted (logged-in submitter: Nathan Karstens)

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-02-27T05:16:34.090531+00:00

Uploaded new revision

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-02-27T05:00:10+00:00

IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed

Host Extensions for IP Multicasting and "Any Source Multicasting" (ASM) IP service

2026-02-27T02:39:14.160449+00:00

New version available: draft-ietf-pim-rfc1112bis-08.txt

Host Extensions for IP Multicasting and "Any Source Multicasting" (ASM) IP service

2026-02-27T02:39:14.157011+00:00

New version accepted (logged-in submitter: Toerless Eckert)

Host Extensions for IP Multicasting and "Any Source Multicasting" (ASM) IP service

2026-02-27T02:39:14.103310+00:00

Uploaded new revision

Multi-Topology in PIM

2026-02-27T00:44:22.004374+00:00

New version available: draft-xz-pim-flex-algo-07.txt

Multi-Topology in PIM

2026-02-27T00:44:22.000927+00:00

New version accepted (logged-in submitter: Zheng Zhang)

Multi-Topology in PIM

2026-02-27T00:44:21.940544+00:00

Uploaded new revision

Zeroconf Multicast Address Allocation Problem Statement and Requirements

2026-02-26T17:46:14.977713+00:00

RFC Editor state changed to EDIT from AUTH

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-02-26T10:33:19.067067+00:00

[Ballot comment]
Thanks for the work in this document.

I STRONGLY really regret that this I-D was not in int-area and that the WGLC/CfA were not forwarded to int-area (AFAIK). In my opinion, it *does not fit* the PIM WG charter as it is not about protocol specifications.

But, the most important thing is the content and not the 'wrong' process.

Thanks also to Daniel Migault for his INT directorate review: https://datatracker.ietf.org/doc/review-ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id-10-intdir-telechat-migault-2026-02-19/ and I have to read the authors' response.

Some non-blocking comments:

# Abstract

In a PS, s/the document also suggests/the document also defines/

Also be explicit on how the I-D updates RFC 3307.

# Section 2

s/for destination address G/for destination *group* address G/ ?

# Section 3

Please expand MADCAP.

# Section 5

Please use the (new) correct name rather than ""IPv6 Multicast Address Space Registry", also add a reference URI.

# Section 6

`National Marine Electronics Association` from which country ?

Updates to Dynamic IPv6 Multicast Address Group IDs

2026-02-26T10:33:19.066968+00:00

[Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke

Group Address Allocation Protocol (GAAP)

2026-02-26T00:29:44.791752+00:00

New version available: draft-ietf-pim-gaap-10.txt

Group Address Allocation Protocol (GAAP)

2026-02-26T00:29:44.788288+00:00

New version approved

Group Address Allocation Protocol (GAAP)

2026-02-26T00:29:29.962069+00:00

Request for posting confirmation emailed to previous authors: Dino Farinacci , Mike McBride

Group Address Allocation Protocol (GAAP)

2026-02-26T00:29:29.712900+00:00

Uploaded new revision

Zeroconf Multicast Address Allocation Problem Statement and Requirements

2026-02-26T00:17:28+00:00

IANA Action state changed to No IANA Actions

Native IPv4 multicast in IPv6 Core using PIM

2026-02-25T23:34:59.774024+00:00

New version available: draft-venaas-pim-ipv4-in-ipv6-core-00.txt