Multicast Listener Discovery Version 2 (MLDv2) for IPv6
draft-ietf-pim-3810bis-12

[Ballot comment]
I reviewed the diff between this and RFC3810 only for this position.

I don't understand the SHOULD NOTs in Section 5.2.13.  What harm to interoperability results from sending them if they are simply ignored?

[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-pim-3810bis-11

Thank you for the work put into this document. I have mainly reviewed the diff with RFC 3810:
https://author-tools.ietf.org/iddiff?url1=rfc3810&url2=draft-ietf-pim-3810bis-11&difftype=--html

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and one nit.

Special thanks to Stig Venaas for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status (i.e., it is "Internet Standard").

Other thanks to Sheng Jiang, the Internet directorate reviewer (at my request), please consider this int-dir review:
https://datatracker.ietf.org/doc/review-ietf-pim-3376bis-11-intdir-telechat-halley-2024-07-28/ (just one nit that I have repeated in my ballot)

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non-blocking)

## Section 5.1.6

Should the IANA registry name be used rather than the reference to the RFC creating that registry ?

Unsure whether allocation is the right term to be used here, suggest to use "Specification".

Should there be the usual text "unassigned bits in the Flags field MUST be set to 0 on transmission and MUST be ignored on reception" ?

## Section 5.1.11

Should `unicast addresses` be refined ? I.e., can it be link-local ? or unspecified ?

## Appendix B.1

Unsure whether this section (about changes from MLDv1) is useful in a -bis document.

# NITS (non-blocking / cosmetic)

## Sections 7.6.2

Repeating Sheng Jiang nits about using lower case in IPv6 addresses per RFC 5952 (especially since all other IPv6 addresses are rightfully written).

[Ballot comment]
# Orie Steele, ART AD, comments for draft-ietf-pim-3810bis-11
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-pim-3810bis-11.txt&submitcheck=True

## Comments

### Why not MUST NOT?

```
1182           multicast address, if it is non-empty.  An SSM-aware host
1183           SHOULD NOT send a MODE_IS_EXCLUDE record type for multicast
1184           addresses that fall within the SSM address range as they will
1185           be ignored by SSM-aware routers [RFC4604].
```

```
1206           the specified multicast address, if it is non-empty.  An SSM-
1207           aware host SHOULD NOT send a CHANGE_TO_EXCLUDE_MODE record
1208           type for multicast addresses that fall within the SSM address
1209           range.
```

Is this simply a SHOULD because it won't cause harm, because it is ignored?

Are there cases where an SSM-aware host MUST / MUST NOT send MODE_IS_EXCLUDE or CHANGE_TO_EXCLUDE_MODE ?

### Why not MUST?

```
1292   Records of the Report message.  From now on, it will treat packets
1293   sent to those multicast addresses according to this new listening
1294   state.  Once a valid link-local address is available, a node SHOULD
1295   generate new MLDv2 Report messages for all multicast addresses joined
1296   on the interface.
```

Under which conditions should a node not generate new new MLDv2 Report messages.

```
2414   SHOULD log an error.  It is RECOMMENDED that implementions provide a
2415   configuration option to disable use of Host Compatibility Mode to
2416   allow networks to operate only in SSM mode.  This configuration
2417   option SHOULD be disabled by default.
```

implementions -> implementations

Under which conditions is it ok to leave this configuration enabled by default?

[Ballot comment]
Thanks to Valery Smyslov for his secdir review.  I'm copying part of his review here:

--------------------------------------------
I think that the Security Consideration section should be expanded and be
rewritten in a more structural way. In particular, it should be mentioned that
the protocol lacks any cryptographic protection, thus its messages are not
authenticated, provide no confidentiality and can be replayed. Then I would
discuss the consequences of each of these deficiencies.

The lack of replay protection seems to have no effect on the protocol security,
because it is (at least it should be) designed so that it tolerates IP packets
duplication (correct me if I'm wrong, I read the protocol itself briefly, but
this was my impression).

The lack of authentication leads to possible message forgery. The corresponding
attacks are described in the draft, however, I'm not sure taht the list is
complete. For example, it seems to me that forged Current State Report message
from a malicious node may report a lot number of faked listening multicast
addresses, aiming to consume router's resources (a kind of DoS attack).

The lack of confidentiality is not discussed in the draft. In fact, it leads to
privacy issues - any passive attacker on the local link can learn what
multicast addresses other nodes are listen to, which may be quite sensitive
information.
---------------------------

With respect to that review, and the author response:

It is understood that it is very difficult/impossible to provide either confidentiality or integrity protection for traffic in protocols such as MLD - both multicast and discovery.  From my point of view, the only option would be to modify the Security Consideration section.  I think one could use Valery's suggestions, as appropriate (if replay isn't an issue, then leave that part out, etc.).

Thanks for your attention.

[Ballot comment]
Thank you to Russ Housley for the GENART review.

** Idnits reported the following:

  -- The document seems to contain a disclaimer for pre-RFC5378 work, and may
    have content which was first submitted before 10 November 2008.  The
    disclaimer is necessary when there are original authors that you have
    been unable to contact, or if some do not wish to grant the BCP78 rights
    to the IETF Trust.  If you are able to get all authors (current and
    original) to grant those rights, you can and should remove the
    disclaimer; otherwise, the disclaimer is needed and you can ignore this
    comment. (See the Legal Provisions document at
    https://trustee.ietf.org/license-info for more information.)

Has one of the original authors of RFC3376 been approached to file the appropriate paperwork with the Trust to assign the new rights?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-pim-3810bis-10. If any part of this review is inaccurate, please let us know.

IANA has a question about one of the actions requested in the IANA Considerations section of this document.

In section 11 of the current draft, the authors note that IANA has assigned the IPv6 link-local multicast address FF02:0:0:0:0:0:0:16, called "all MLDv2-capable routers", as described in Section 5.2.15.

IANA Question --> Should the reference for that registration be changed to [ RFC-to-be ]?

Also in section 11, the authors note that IANA has assigned the ICMPv6 message type value of 143 for Version 2 Multicast Listener Report messages, as specified in Section 4.

IANA Question --> Should the reference for that type value be changed to [ RFC-to-be ]?

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist

The following Last Call announcement was sent out (ends 2024-06-05):

From: The IESG
To: IETF-Announce
CC: draft-ietf-pim-3810bis@ietf.org, gunter@vandevelde.cc, pim-chairs@ietf.org, pim@ietf.org, stig@venaas.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Multicast Listener Discovery Version 2 (MLDv2) for IPv6) to Internet Standard


The IESG has received a request from the Protocols for IP Multicast WG (pim)
to consider the following document: - 'Multicast Listener Discovery Version 2
(MLDv2) for IPv6'
  as Internet Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-06-05. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This document updates RFC 2710, and it specifies Version 2 of the
  Multicast Listener Discovery Protocol (MLDv2).  MLD is used by an
  IPv6 router to discover the presence of multicast listeners on
  directly attached links, and to discover which multicast addresses
  are of interest to those neighboring nodes.  MLDv2 is designed to be
  interoperable with MLDv1.  MLDv2 adds the ability for a node to
  report interest in listening to packets with a particular multicast
  address only from specific source addresses or from all sources
  except for specific source addresses.

  This document obsoletes RFC 3810.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-pim-3810bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc2464: Transmission of IPv6 Packets over Ethernet Networks (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc2710: Multicast Listener Discovery (MLD) for IPv6 (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc2711: IPv6 Router Alert Option (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc4607: Source-Specific Multicast for IP (Proposed Standard - Internet Engineering Task Force (IETF))

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
Several people, some of the more active participants, have voiced their support.
Some concerns were raised during WGLC related to fallback to older versions and
SSM. This has been resolved after a longer discussion. No other issues raised.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
There were some differences of opinion on whether it was necessary to add text on
fallback to older versions and SSM, after some discussion this was added. It
looks like we found a good compromise.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
There are many implementations of MLDv2. This is updating that based on errata
and implementation/deployment experiences. The WG did a survey to get input.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
Yes, the document is in great shape. Only minor changes from RFC 3810.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
All areas should be sufficiently addressed by 3376, and this just has minor
changes.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
Internet Standard. Not sure which attributes.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
Yes. Not aware of any IPR for the original document. The author/editor of this
document is not aware of any IPR either.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
Authors of the previous document are listed as contributors. We are assuming they
are okay with this. The author of the new document is willing.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Not aware of any nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
No

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
No, but please note that there is an informative reference to draft-ietf-pim-3228bis. We have just requested publication of that, and it would be good if this document and 3228bis can be grouped together by the RFC editor to get the up to date references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
It will obsolete RFC 3810 and update 2710. Not sure about the metadata.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
These are covered by draft-ietf-pim-3228bis. Publication of that was requested on 2024-05-21.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
None

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/

# Document Shepherd Write-Up for Group Documents

*This version is dated 4 July 2022.*

Thank you for your service as a document shepherd. Among the responsibilities is
answering the questions in this write-up to give helpful context to Last Call
and Internet Engineering Steering Group ([IESG][1]) reviewers, and your
diligence in completing it is appreciated. The full role of the shepherd is
further described in [RFC 4858][2]. You will need the cooperation of the authors
and editors to complete these checks.

Note that some numbered items contain multiple related questions; please be sure
to answer all of them.

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?
Several people, some of the more active participants, have voiced their support.
Some concerns were raised during WGLC related to fallback to older versions and
SSM. This has been resolved after a longer discussion. No other issues raised.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?
There were some differences of opinion on whether it was necessary to add text on
fallback to older versions and SSM, after some discussion this was added. It
looks like we found a good compromise.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)
No

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?
There are many implementations of MLDv2. This is updating that based on errata
and implementation/deployment experiences. The WG did a survey to get input.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.
No

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?
N/A

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.
N/A

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?
Yes, the document is in great shape. Only minor changes from RFC 3810.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?
All areas should be sufficiently addressed by 3376, and this just has minor
changes.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?
Internet Standard. Not sure which attributes.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.
Yes. Not aware of any IPR for the original document. The author/editor of this
document is not aware of any IPR either.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front page
    is greater than five, please provide a justification.
Authors of the previous document are listed as contributors. We are assuming they
are okay with this. The author of the new document is willing.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

Not aware of any nits.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].
No

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?
No

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.
No, but please note that there is an informative reference to draft-ietf-pim-3228bis. We have just requested publication of that, and it would be good if this document and 3228bis can be grouped together by the RFC editor to get the up to date references.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?
No

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.
It will obsolete RFC 3810 and update 2710. Not sure about the metadata.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).
These are covered by draft-ietf-pim-3228bis. Publication of that was requested on 2024-05-21.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.
None

[1]: https://www.ietf.org/about/groups/iesg/
[2]: https://www.rfc-editor.org/rfc/rfc4858.html
[3]: https://www.rfc-editor.org/rfc/rfc7942.html
[4]: https://wiki.ietf.org/group/ops/yang-review-tools
[5]: https://www.rfc-editor.org/rfc/rfc8342.html
[6]: https://wiki.ietf.org/group/iesg/ExpertTopics
[7]: https://www.rfc-editor.org/info/bcp79
[8]: https://www.ietf.org/tools/idnits/
[9]: https://www.rfc-editor.org/rfc/rfc3967.html
[10]: https://www.rfc-editor.org/info/bcp97
[11]: https://www.rfc-editor.org/rfc/rfc8126.html
[12]: https://www.rfc-editor.org/rfc/rfc2026.html#section-5
[13]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.1
[14]: https://www.rfc-editor.org/rfc/rfc2026.html#section-4.2
[15]: https://authors.ietf.org/en/content-guidelines-overview
[16]: https://www.ietf.org/about/groups/iesg/statements/normative-informative-references/
[17]: https://datatracker.ietf.org/doc/downref/