[pim] Re: draft-ietf-pim-ipv6-zeroconf-assignment-07 early R tgdir review
"Karstens, Nate" <[email protected]> Wed, 1 Apr 2026 16:27:43 +0000
| Newsgroups | gmane.ietf.pim |
|---|---|
| Message-ID | <CH3PR04MB8794D03FD0A5067552210B369C50A@CH3PR04MB8794.namprd04.prod.outlook.com> |
Toerless, Thanks for your review, I can tell you put a lot of time into it! Also, sorry for the significant delay in my reply. Some of your feedback was already addressed (or at least improved) in v08 of the document, but additional changes were made in v09 based on your comments. Please see below for individual responses. Thanks, Nate From: Toerless Eckert via Datatracker <[email protected]> Sent: Monday, December 22, 2025 12:15 To: [email protected] Cc: [email protected]; [email protected] Subject: [pim] draft-ietf-pim-ipv6-zeroconf-assignment-07 early Rtgdir review Document: draft-ietf-pim-ipv6-zeroconf-assignment Title: Zero-Configuration Assignment of IPv6 Multicast Addresses Reviewer: Toerless Eckert Review result: Has Issues Document: draft-ietf-pim-ipv6-zeroconf-assignment Title: Zero-Configuration Document: draft-ietf-pim-ipv6-zeroconf-assignment Title: Zero-Configuration Assignment of IPv6 Multicast Addresses Reviewer: Toerless Eckert Review result: Has Issues Document: draft-ietf-pim-ipv6-zeroconf-assignment Title: Zero-Configuration Assignment of IPv6 Multicast Addresses Reviewer: Toerless Eckert for RTG DIR Review result: Has Issues This document is on the right path but has several issues that need to be worked out and are discussed in the detailled review feedback below. In summary: - The document forgets to call out its reason of existance, which is not simply IPv6 multicast group address collision but collision of the link-layer addresses as well. [NK] We rely on draft-ietf-pim-zeroconf-mcast-addr-alloc-ps for a detailed discussion of this, but added a note to the end of the first paragraph in the Introduction section. - Unnecessary hand waiving: keep text focussed on deployments thats undestood to work - mDNS, link-local scope, ".local" domain. Move everything outside that scope outside the document or into an appendix. [NK] v08 added a new “Use on Networks with Multiple Subnets” section to discuss this further. - DNS RR PTR format unnecessarily complex, non-descriptive. Review suggests hopefully better/simpler encoding options. [NK] Please see individual responses below. - Incomplete and incorrect statements re this document meeting all of draft-ietf-pim-zeroconf-mcast-addr-alloc-ps requirements. [NK] v08 enumerated the individual requirements and how this protocol meets those requirements. - Various nits. The remainder of this email is output of idnets (with line numbers) interleaved with review comments. Thanks a lot for the work. Toerless Checking nits according to https://urldefense.com/v3/__https://www.ietf.org/id-info/checklist__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpJU_QD7fQ$<https://urldefense.com/v3/__https:/www.ietf.org/id-info/checklist__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpJU_QD7fQ$> : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. 2 Network Working Group N. Karstens 3 Internet-Draft Garmin 4 Intended status: Standards Track D. Farinacci 5 Expires: 3 April 2026 lispers.net 6 M. McBride 7 Futurewei 8 30 September 2025 10 Zero-Configuration Assignment of IPv6 Multicast Addresses 11 draft-ietf-pim-ipv6-zeroconf-assignment-07 minor: Given how this solution specifically relies on mDNS, i would strongly recommend to include mDNS into the title of the document, e.g.: Zero-Configuration Assignment of IPv6 Multicast Addresses using mDNS draft-ietf-pim-ipv6-zeroconf-assignment-07 This also allows to easier distinguish this solution from others in case others will evolve. [NK] Makes sense! 13 Abstract 15 Describes a zero-configuration protocol for dynamically assigning 16 IPv6 multicast addresses. Applications randomly assign multicast ^ mayor: ... that are unique at link-layer. [NK] Good suggestion! 17 group IDs from a specified range and prevent collisions by using 18 Multicast DNS (mDNS) to publish records in a new "eth-addr.arpa" 19 special-use domain. This protocol satisfies all of the criteria 20 listed in draft-ietf-pim-zeroconf-mcast-addr-alloc-ps. ^ nit: suggest: ... "for IPv6 multicast addresses" [NK] The requirements in the problem statement document go beyond IPv6 multicast addresses. In any case, v08 enumerates how each of these requirements is met, hopefully that clarifies this further. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://urldefense.com/v3/__https://datatracker.ietf.org/drafts/current/__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpIVId0xTQ$<https://urldefense.com/v3/__https:/datatracker.ietf.org/drafts/current/__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpIVId0xTQ$>. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 3 April 2026. 39 Copyright Notice 41 Copyright (c) 2025 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://urldefense.com/v3/__https://trustee.ietf.org/__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpI5-IsAXw$<https://urldefense.com/v3/__https:/trustee.ietf.org/__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpI5-IsAXw$> 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Veto Records . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Evaluation of Solution . . . . . . . . . . . . . . . . . . . 4 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 4.1. Domain Name Reservation Considerations . . . . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 6. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 5 64 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 7.2. Informative References . . . . . . . . . . . . . . . . . 6 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] includes a problem 72 statement and requirements for a zero-configuration method for 73 dynamically assigning multicast addresses. This document describes a ^ mayor: add at "^": that are not only unique themselves, but that also map to unique link-layer addresses. [NK] We made a change to clarify that this applies to both IPv6 and link-layer addresses. link- 74 process that fulfills these requirements by having applications ^ nit: "for IPv6 multicast addresses" [NK] This should apply to both because IPv6 multicast addresses have a straightforward mapping to Ethernet addresses (RFC 2464). 75 randomly assign IPv6 multicast group IDs from a specified range and 76 using mDNS [RFC6762] to prevent collisions. 78 Note that DNS-based Service Discovery (DNS-SD) [RFC6763] uses several 79 different DNS record types, published using either Unicast or 80 Multicast DNS, to facilitate service discovery. This document uses a 81 single DNS record type (PTR), published using Multicast DNS, to 82 coordinate IPv6 multicast address assignment in a zero-configuration 83 environment. The DNS records in this protocol may be published nit: The correct term is "DNS resource record", so i would prefer if that term would be used consistently instead of "DNS record". The IETF has been quite lenient though. Seems to me as if all RFC written by DNS people use "DNS resource record", and a larger number of RFCs that are written by "just users of DNS" just say "DNS record".... [NK] Good observation! In reading through RFC 1035 it seems like “resource record” is likely to be used in a general sense, but “resource” is omitted when referring to a specific resource record type (e.g., “PTR record”). The updated document follows suit. nit: s/in a zero-configuration environment/without requiring any configuration/ Reason: I do not know what a "zero-configuration environment" is. Badly defined term. Avoid... [NK] The term appears in RFC 6762 and based on its use there and in other documents it appears to be a term of art. 84 alongside records for other domain name services, such as DNS-SD, or 85 they may be published alone. mDNS is used in favor of a new protocol 86 with the expectation that functionality for address assignment can be 87 achieved using existing mDNS implementations. 89 This protocol is well-suited for networks that rely on IPv6 multicast 90 and already deploy mDNS. 92 1.1. Requirements Language 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in BCP 97 14 [RFC2119] [RFC8174] when, and only when, they appear in all 98 capitals, as shown here. 100 2. Procedure 102 When an application is preparing to transmit a multicast stream, it 103 first generates a random group ID in the range 0x90000000-0x9FFFFFFF, 104 which IANA is REQUESTED to assign from the "Dynamic Multicast Group nit: Start new sentence to avoid confusion about what IANA is requested to assign (the range vs. the ID): ". IANA is requested to assign this range from ..." [NK] Done! 105 IDs" registry (see Section 4). It combines this with the Interface 106 Identifier (IID) of the intended source address for the multicast 107 stream to generate a link-scoped IPv6 multicast address [RFC4489]. 108 The application then calculates the multicast Ethernet address that 109 will be used to transmit the data ([RFC2464], Section 7) and uses 110 that to construct a string like a reverse-mapping domain, using a new 111 "eth-addr.arpa" special-use domain. nit: Any RFC reference for this special-use domain approach ? If so, please add. [NK] v08 of the document does a better job explaining the RFCs and registries involved with these domains. nit: That text is the normative description of the procedure, so you need to formally describe how to construct the eth-addr.arpa string. You should also include the specification of the format of the PTR RR you are introducing here. [NK] This was changed to use more formal requirements language. mayor: I do not think it is necessary to use the complicated reverse representation of a MAC address as proposed in this draft ("0.f.e.d.c.b.a.9.3.3.3.3"). That format is only necessary when you need to support sub-tree delegation within the name space. For IP/IPv6 addresses delegation means that different sub-trees of the address space are maintained by different administrative entities / DNS-servers. This is a) not possible with mDNS, b) not possible with allocated MAC addresses. If you do want to keep this format, then the document really needs to have good justification for doing so. And saying "we thought this is the same problem as for ipv6.arpa, and hence the same solution" - is not a good technical explanation. I also don't think eth-addr.arpa is a good descriptive name. It is open ended and suggests that different uses could re-use this domain, but in reality such additional use could be conflicting in what they want to do into the PTR RR. So, i would suggest: a) Simply use the lower-case representation of a MAC-address without any filler characters, all zero written out to represent the MAC address. b) Use a self descriptive name so anyone seeing such a domain name knows immediately what it means: 33339abcdef0.rfcTHISRFC.arpa You need to add some note like: [RFC-editor / IANA: please replace THISRFC with the RFC number assigned to this document]. 113 For example, given a source address of fe80::a12:34ff:fe56:7890, the 114 IPv6 multicast address may be ff32:00ff:a12:34ff:fe56:7890:9abc:def0, 115 the group ID 9abc:def0, the multicast Ethernet address 116 33:33:9A:BC:DE:F0, and the resulting string is 117 "0.f.e.d.c.b.a.9.3.3.3.3.eth-addr.arpa". [NK] v08 of the document does a better job with the registry entries that are being requested. Specifically: 1) the “eth-addr.arpa” entry in the .arpa registry is for mapping Ethernet addresses to local domain names 2) the “9.3.3.3.3.eth-addr.arpa” narrows the scope to IPv6 addresses with this range of group IDs and leaves other ranges open for future use Although the primary purpose of these resource records is not reverse address lookups, that is certainly a valid use. So, it would probably be best to use the established format for reverse address lookup records. This approach also follows patterns established by other IETF standards. nit: This is too terse and does not follow the order in which it was explained in before, so it is hard to match up against the explanation: 1. The node creates a unique IPv6 link local multicast group address according to [RFC4489] according to the following steps 1.1 The node creates a randomn group ID from the range 0x90000000-0x9FFFFFFF reserved for the procedures of this memo: 9abc:def0 1.2 The node retries the IID portion of the link-local unicast address of the link to use: fe81::a13:34ff:fe56:7890 -> a13:34ff:fe56:7890. 1.3 The node combines IID and random group ID to form the IPv6 link local group address: ff32:00ff:a12:34ff:fe56:7890:9abc:def0. 2. The node knows that the MAC address used for this group address is 33:33:<group-id>, and hence the DNS PTR RR to claim the MAC address is 33339abcdef0.rfcTHISRFC.arpa [NK] Hopefully the new wording is an improvement. 119 The application then uses the mDNS probing algorithm described in 120 [RFC6762], Section 8.1 to continuously query for a PTR record with 121 the same name as the generated string. If the probing algorithm 122 completes without any conflict, then the application begins 123 advertising its own unique PTR record using that name. The PTRDNAME 124 field consists of a unique application identifier, in the form of a 125 DNS label, followed by the device's host name (for example, 126 "application.example.local."). Integrating a unique identifier in 127 this manner allows for multiple applications to be on the same host. mayor: There needs to be more description about the PTR target FQDN and rules for it. First of all, it seems prudent to require the PTR target FQDN to necessarily be uniquely owned by the announcing host, through probing as of rfc6762, section 8.1. Secondly, whether this is just some pre-existing or new hostname of this host, such as example-host.local, or some new sub-domain name such as "application.example-host.local" - that seems like outside the scope of this document because no procedures are defined or pointed to. [NK] The document uses RFC 6762, which already includes rules for establishing the host name. Is it helpful to repeat that here? Also, I’m having a hard time understanding the second comment. 128 Note that A/AAAA records may also be published for this host name 129 ("example.local."), though this is not a requirement for this design. nit: Again: this is just hand waving for something not specified. Better to remove or move into an appendix so as not to cause confusion and followup questions. [NK] This is pointing out something that should already done when implementing RFC 6762 131 Because this protocol is focused specifically on allocating IPv6 132 multicast addresses, records MUST be published using the IPv6 133 multicast address for mDNS, but MAY also be published using the IPv4 134 multicast address for mDNS. minor: KISS (Keep It Simple, Stupid): remove the MAY portion about IPv6 or else explain in the tesxt when and where this is applicable. [NK] v08 explains that this is to provide compatibility with implementations that do not let you specify which protocol to advertise over (some allow IPv6, but require IPv4). 136 Once the PTR record is advertised, the host may then begin 137 transmitting multicast data using the generated address. 139 The application shall retain the group ID value and use it the next 140 time the multicast stream is transmitted. This allows the network to 141 quickly settle on a configuration that will never have another 142 collision as long as the network is unchanged. 144 If a conflict is detected at any point, then the application stops 145 transmitting that multicast stream and starts the process over using 146 a different group ID. 148 The host network stack may optionally monitor the network for traffic 149 that uses the same destination multicast Ethernet address, but a 150 different destination multicast IPv6 address. If this is detected, 151 then the application responds the same as a collision. ^ nit: SHOULD [NK] Changed to SHALL, which is probably more appropriate. 153 While intended primarily for allocating IPv6 multicast addresses on 154 the same subnet (link-local scope), the same technique could also 155 apply to a larger network as long as mDNS traffic is routed between 156 subnets (for any scope excluding global scope). minor: remove whole paragraph. Hand waiving. No supportive normative text what/if/how to do this. [NK] v08 provides more information on how to accomplish this and moves it into a separate section. CONS-1 in draft-ietf-pim-zeroconf-mcast-addr-alloc-ps discusses operation over networks with multiple subnets, so it is relevant. 158 2.1. Veto Records 160 [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] describes collisions 161 occurring in the network infrastructure. nit: Add reference to section [NK] Done! 161 When an infrastructure 162 component detects a collision it cannot resolve, it triggers a 163 conflict with the application by publishing a veto record. A veto 164 record is a unique PTR record using the string generated for the 165 address as its name and the PTRDNAME field set to the string "veto", 166 formatted as a DNS label. The veto record is published without 167 probing. mayor: I can not find somthing in [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] that would point to the need for such a functionality. It would be good to have a clearer specification for the condition in which this problem could occur. [NK] We added some text to clarify this. I would suggest to use the special domain name "veto." (aka: global, not relative) to indicate the specific purpose of anybody but the announcer to cease attempting to claim the RR. [NK] The veto record still needs to use the full address so that a device probing for the address will know that it is not available. 169 Applications respond to the conflict the same as to a collision. The 170 application retains its new group ID, so the same conflict is not 171 repeated in the future. minor: "retains its new group ID" ??? Maybe rephrase ? The application that looses against a veto has to randomnly use a new group ID and try to re-claim the DNS RR for it, right ? [NK] We improved the wording of this. 173 3. Evaluation of Solution 175 [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] contains a list of 176 criteria to evaluate potential solutions. The protocol described in 177 this document satisfies all of the required criteria. mayor: Given how the multicast group address is derived from the IID according to RFC4489, the address is tied to the node that owns this IID. When this node goes away, the mechanism by which the address is "owned" - DAD and/or mDNS will no longer work. Hence this mechanism does not seem to satisfy REQ-2. [NK] Maybe I’m misunderstanding what you’re saying, but the node owning the IID is also allocating the multicast addresses, so it’s not relying on any other devices on the network (i.e., no central servers like you might see with something like DHCP). minor: To satisfy REQ-7: If multiple applications on the same host use the same IID according to RFC4489, then they need to use a single cordinated instance of the allocation procedure in this document so that they do not randomnly generate the same group-ID and hence the same multicast address. Or else they might be able to determine from a shared mDNS library/daemon if both would atempt to allocate the same mDNS RR. Otherwise (e.g.: if mDNS is running independently from each other in each application, the mDNS collision detection would have to work for looped-back packets, something that may cause implementation challenges). These type of issues around satisfying REQ-7 sould be described in the document. [NK] Excellent point, we added text to that effect. This is supported by the mDNS responders I’ve experimented with (which tend to handle this by looping packets back into the socket), and was tested with our proof-of-concept (https://github.com/nkarstens/mdns-zeroconf-mcast). mayor: mDNS is typically supported today only across link-local scopes. Likewise, RFC4489 is only working for link-local addresses. Therefore i can not see how CONS-1 can be suppoted. The document should describe that (and why) CONS-1 is not supported. [NK] v08 of the document added a new section describing how this is supported. 179 However, because mDNS is designed to be a low-bandwidth protocol, it 180 can take a signficant amount of time to detect a record collision 181 after a network partition is repaired. This is not a concern on 182 networks where all multicast streams are established before any 183 likely partition event because all group IDs will have been selected 184 and stored for future use. 186 It is a greater concern on networks where multicast streams may be 187 established at any time. Deployments on these networks may consider 188 engaging a detection mechanism and prompting hosts to send 189 unsolicited mDNS response messages when the partition is repaired. 191 The protocol described in this document also satisfies the 192 recommended criteria, to the extent that a deployment supports 193 publishing mDNS-based DNS-SD records across multiple subnets (see 194 [RFC8766]). 196 4. IANA Considerations 198 IANA should allocate a block of group IDs from the "Dynamic Multicast 199 Group IDs" registry in the "IPv6 Multicast Address Space Registry" 200 registry group that was created by 201 [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id]. The range of this 202 block should be 0x90000000-0x9FFFFFFF and the description should be 203 the title of this document. 205 The special-use domain "eth-addr.arpa" should be registered in the 206 .arpa registry (https://urldefense.com/v3/__https://www.iana.org/domains/arpa__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpKgp26ARA$<https://urldefense.com/v3/__https:/www.iana.org/domains/arpa__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpKgp26ARA$>) and the "Special- 207 Use Domain Names" registry (https://urldefense.com/v3/__https://www.iana.org/assignments/special-__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpIO03_MNA$<https://urldefense.com/v3/__https:/www.iana.org/assignments/special-__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpIO03_MNA$> 208 use-domain-names). This domain should not be delegated. 210 4.1. Domain Name Reservation Considerations 212 The "eth-addr.arpa." domain is effectively a reverse-mapping domain 213 and so has the same considerations as the reverse-mapping domains 214 listed in [RFC6761], Section 6.1. 216 5. Security Considerations 218 This algorithm only works in environments where all hosts are 219 cooperating. Malicious hosts could deny service by repeatedly 220 triggering address conflicts. nit: Might point to the fact that this is not new for this memos functionality, but for all of exclusive DNS RR when using mDNS. [NK] Good point, done! 222 6. Acknowledgement 224 Special thanks to the National Marine Electronics Association for 225 their contributions in developing marine industry standards and their 226 support for this research. 228 Thanks also to the members of the PIM working group for their early 229 brainstorming sessions and review of this draft, and to Esko Dijk for 230 his review of the draft. 232 7. References 233 7.1. Normative References 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, 237 DOI 10.17487/RFC2119, March 1997, 238 <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc2119__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpKUmfsWYg$<https://urldefense.com/v3/__https:/www.rfc-editor.org/info/rfc2119__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpKUmfsWYg$>>. 240 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 241 Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, 242 <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc2464__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpIrSaQr-Q$<https://urldefense.com/v3/__https:/www.rfc-editor.org/info/rfc2464__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpIrSaQr-Q$>>. 244 [RFC4489] Park, J., Shin, M., and H. Kim, "A Method for Generating 245 Link-Scoped IPv6 Multicast Addresses", RFC 4489, 246 DOI 10.17487/RFC4489, April 2006, 247 <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc4489__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpKZ-8C9Bw$<https://urldefense.com/v3/__https:/www.rfc-editor.org/info/rfc4489__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpKZ-8C9Bw$>>. 249 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 250 RFC 6761, DOI 10.17487/RFC6761, February 2013, 251 <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc6761__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpLAdI1Ylw$<https://urldefense.com/v3/__https:/www.rfc-editor.org/info/rfc6761__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpLAdI1Ylw$>>. 253 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 254 DOI 10.17487/RFC6762, February 2013, 255 <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc6762__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpJmV7JByQ$<https://urldefense.com/v3/__https:/www.rfc-editor.org/info/rfc6762__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpJmV7JByQ$>>. 257 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 258 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 259 May 2017, <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc8174__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpICljvsaQ$<https://urldefense.com/v3/__https:/www.rfc-editor.org/info/rfc8174__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpICljvsaQ$>>. 261 7.2. Informative References 263 [I-D.ietf-pim-updt-ipv6-dyn-mcast-addr-grp-id] 264 Karstens, N., Farinacci, D., and M. McBride, "Updates to 265 Dynamic IPv6 Multicast Address Group IDs", Work in 266 Progress, Internet-Draft, draft-ietf-pim-updt-ipv6-dyn- 267 mcast-addr-grp-id-07, 25 August 2025, 268 <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-pim-__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpIGE6650w$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-pim-__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpIGE6650w$> 269 updt-ipv6-dyn-mcast-addr-grp-id-07>. 271 [I-D.ietf-pim-zeroconf-mcast-addr-alloc-ps] 272 Karstens, N., Farinacci, D., and M. McBride, "Zeroconf 273 Multicast Address Allocation Problem Statement and 274 Requirements", Work in Progress, Internet-Draft, draft- 275 ietf-pim-zeroconf-mcast-addr-alloc-ps-07, 30 September 276 2025, <https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpLSHuIV9w$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/html/draft-ietf-__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpLSHuIV9w$> 277 pim-zeroconf-mcast-addr-alloc-ps-07>. 279 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 280 Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, 281 <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc6763__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpI3piEaDw$<https://urldefense.com/v3/__https:/www.rfc-editor.org/info/rfc6763__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpI3piEaDw$>>. 283 [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based 284 Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 285 2020, <https://urldefense.com/v3/__https://www.rfc-editor.org/info/rfc8766__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpJ9Df_8xg$<https://urldefense.com/v3/__https:/www.rfc-editor.org/info/rfc8766__;!!EJc4YC3iFmQ!SBh5Ip1_Z130guGQeP1S1k5LMGfs5RQ9k30gZzmcP51NgCKj7bNmKa5gCH2_8ho00tBwrTCwNpJ9Df_8xg$>>. 287 Authors' Addresses 289 Nate Karstens 290 Garmin International, Inc. 291 1200 E. 151st St. 292 Olathe, KS 66062-3426 293 United States of America 294 Email: [email protected]<mailto:[email protected]> 296 Dino Farinacci 297 lispers.net 298 San Jose, CA 299 United States of America 300 Email: [email protected]<mailto:[email protected]> 302 Mike McBride 303 Futurewei 304 United States of America 305 Email: [email protected]<mailto:[email protected]> EOF _______________________________________________ pim mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> ________________________________ CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient(s) and contain information that may be Garmin confidential and/or Garmin legally privileged. If you have received this email in error, please notify the sender by reply email and delete the message. Any disclosure, copying, distribution or use of this communication (including attachments) by someone other than the intended recipient is prohibited. Thank you. _______________________________________________ pim mailing list -- [email protected] To unsubscribe send an email to [email protected]