RFC 3956
Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address
Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address 🦋
okay so bestie, this is RFC 3956 💖 It's a Standards Track document from the Network Working Group, dated November 2004. The authors are P. Savola (CSC/FUNET) and B. Haberman (JHU APL) 🫶 It updates RFC 3306 (that's the header line, and it's the reason this memo changes the addressing format from that RFC). The header doesn't list anything it obsoletes.
Status of this Memo ✨
This document specifies an Internet standards track protocol for the Internet community, and asks for discussion and suggestions for improvements. For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.
Copyright Notice 🌸
Copyright (C) The Internet Society (2004).
Abstract 💜
This memo defines an address allocation policy in which the address of the Rendezvous Point (RP) is encoded in an IPv6 multicast group address. For Protocol Independent Multicast - Sparse Mode (PIM-SM), this can be seen as a specification of a group-to-RP mapping mechanism. This allows an easy deployment of scalable inter-domain multicast and simplifies the intra-domain multicast configuration as well. This memo updates the addressing format presented in RFC 3306.
Table of Contents 📑
1. Introduction ............................................... 2
1.1. Background ............................................ 2
1.2. Solution ............................................. 2
1.3. Assumptions and Scope ................................. 3
1.4. Terminology .......................................... 4
1.5. Abbreviations ........................................ 4
2. Unicast-Prefix-based Address Format ........................ 4
3. Modified Unicast-Prefix-based Address Format ............... 5
4. Embedding the Address of the RP in the Multicast Address ... 5
5. Examples ................................................... 7
5.1. Example 1 ............................................ 7
5.2. Example 2 ............................................ 7
5.3. Example 3 ............................................ 8
5.4. Example 4 ............................................ 8
6. Operational Considerations ................................. 8
6.1. RP Redundancy ......................................... 8
6.2. RP Deployment ........................................ 9
6.3. Guidelines for Assigning IPv6 Addresses to RPs ........ 9
6.4. Use as a Substitute for BSR ........................... 9
6.5. Controlling the Use of RPs ............................ 9
7. The Embedded-RP Group-to-RP Mapping Mechanism .............. 10
7.1. PIM-SM Group-to-RP Mapping ............................ 10
7.2. Overview of the Model ................................. 11
8. Scalability Analysis ....................................... 12
9. Acknowledgements ........................................... 13
10. Security Considerations ..................................... 13
11. References .................................................. 15
11.1. Normative References .................................. 15
11.2. Informative References ................................ 15
A. Discussion about Design Tradeoffs ........................... 16
Authors' Addresses .............................................. 17
Full Copyright Statement ......................................... 181. Introduction ✨
1.1. Background 🧚
okay so, as has been noticed [V6MISSUES], there's a deployment problem with global, interdomain IPv6 multicast 😭 PIM-SM [PIM-SM] RPs have no way of telling other multicast domains about (active) multicast sources, because Multicast Source Discovery Protocol (MSDP) [MSDP] was deliberately not specified for IPv6. So the whole interdomain Any Source Multicast (ASM) model is basically unusable 💀 Source-Specific Multicast (SSM) [SSM] dodges these problems, but it isn't a complete solution, for several reasons (noted below).
It's also been noted that there are some problems with the support and deployment of the mechanisms SSM would need [V6MISSUES]. It seems unlikely that SSM could be the only interdomain multicast routing mechanism in the short term, not gonna lie 🙈
1.2. Solution 🎀
This memo describes a multicast address allocation policy where the address of the RP is encoded in the IPv6 multicast group address. It also specifies a PIM-SM group-to-RP mapping that uses this encoding, leveraging and extending unicast-prefix-based addressing [RFC3306]. It's giving clever reuse 👑
This mechanism gives a simple solution for IPv6 interdomain Any Source Multicast, and it can also be a simple solution for IPv6 intra-domain ASM with scoped multicast addresses 🦋
It can also work as an automatic RP discovery mechanism in deployment scenarios that would otherwise have used the Bootstrap Router protocol (BSR) [BSR] 🌈
The solution has three elements:
- A specification of a subrange of [RFC3306] IPv6 multicast group addresses, defined by setting one previously unused bit of the Flags field to "1".
- A specification of the mapping by which such a group address encodes the RP address that is to be used with this group.
- A description of operational procedures for running ASM with PIM-SM on these IPv6 multicast groups.
Addresses in the subrange will be called embedded-RP addresses 💜
This scheme makes MSDP unnecessary, and the routers are not required to include any multicast configuration, except when they act as an RP 🍓
This memo updates the addressing format presented in RFC 3306.
Some design tradeoffs are discussed in Appendix A 🧁
1.3. Assumptions and Scope 🌷
A 128-bit RP address can't be embedded into a 128-bit group address with space left over to carry the group identity itself. So an appropriate form of encoding is defined by requiring that the Interface-IDs of RPs in the embedded-RP range can be assigned to be a specific value 🎀
If these assumptions can't be followed, operational procedures and configuration have to change slightly, or this mechanism can't be used 🙈
Assigning multicast addresses is outside the scope of this document. It's up to the RP and applications to make sure group addresses are unique, using some method that isn't specified here. However, the mechanisms are probably similar to those used with [RFC3306] ✨
Similarly, RP failure management methods, such as Anycast-RP, are out of scope for this document. They don't work without additional specification or deployment. This is covered briefly in Section 6.1 💅
1.4. Terminology 📖
Embedded-RP behaves as if all the members of the group were intra-domain to the information distribution. But since it gives a solution for the global IPv6 multicast Internet, spanning multiple administrative domains, we say it's a solution for inter-domain multicast 🌍
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] 🫶
1.5. Abbreviations 🔤
ASM Any Source Multicast
BSR Bootstrap Router
DR Designated Router
IGP Interior Gateway Protocol
MLD Multicast Listener Discovery
MSDP Multicast Source Discovery Protocol
PIM Protocol Independent Multicast
PIM-SM Protocol Independent Multicast - Sparse Mode
RIID RP Interface ID (as specified in this memo)
RP Rendezvous Point
RPF Reverse Path Forwarding
SPT Shortest Path Tree
SSM Source-Specific Multicast2. Unicast-Prefix-based Address Format 🧩
As described in [RFC3306], the multicast address format looks like this:
| 8 | 4 | 4 | 8 | 8 | 64 | 32 |
+--------+----+----+--------+----+----------------+----------+
|11111111|flgs|scop|reserved|plen| network prefix | group ID |
+--------+----+----+--------+----+----------------+----------+Where flgs is "0011". (The first two bits are as yet undefined, sent as zero and ignored on receipt.) 💖
3. Modified Unicast-Prefix-based Address Format 💅
okay this is the fun part 😭 This memo changes the unicast-prefix-based address format by giving the second high-order bit (the "R-bit") a job, like this:
| 8 | 4 | 4 | 4 | 4 | 8 | 64 | 32 |
+--------+----+----+----+----+----+----------------+----------+
|11111111|flgs|scop|rsvd|RIID|plen| network prefix | group ID |
+--------+----+----+----+----+----+----------------+----------+
+-+-+-+-+
flgs is a set of four flags: |0|R|P|T|
+-+-+-+-+When the highest-order bit is 0, R = 1 means the multicast address embeds the address on the RP. Then P MUST be set to 1, and consequently T MUST be set to 1, as specified in [RFC3306]. In effect, this implies the prefix FF70::/12. In this case, the last 4 bits of the previously reserved field are interpreted as embedding the RP interface ID, as specified in this memo. 🌸
The behavior is unspecified if P or T is not set to 1, because then the prefix wouldn't be FF70::/12. Likewise, the encoding and the protocol mode used when the two high-order bits in flgs are set to 11 (FFF0::/12) are intentionally unspecified until the highest-order bit is defined. Without further IETF specification, implementations SHOULD NOT treat the FFF0::/12 range as Embedded-RP. 🙈
When R = 0, the multicast address does not embed the address of the RP, and it follows the semantics defined in [ADDRARCH] and [RFC3306]. In this context, the value of RIID MUST be sent as zero and MUST be ignored on receipt. 🦋
Part 1 done!! 🌈
4. Embedding the Address of the RP in the Multicast Address ✨
okay so the RP address can ONLY be embedded in unicast-prefix-based ASM addresses 💅
to figure out if an address is a multicast address defined in this memo and needs more processing, it has to pass all of these checks 🫶
- It MUST be a multicast address with
flgsset to 0111, which means it has to be in theFF70::/12prefix. plenMUST NOT be 0 (aka not SSM, bestie 🙅).plenMUST NOT be greater than 64.
once it passes, you can grab the RP address with two steps:
- Copy the first
plenbits of thenetwork prefixinto a zeroed 128-bit address structure, and - replace the last 4 bits with the contents of
RIID.
here's the vibe in a diagram 🎀
| 20 bits | 4 | 8 | 64 | 32 |
+---------+----+----+----------------+----------+
|xtra bits|RIID|plen| network prefix | group ID |
+---------+----+----+----------------+----------+
|| \\ vvvvvvvvvvv
|| ``====> copy plen bits of "network prefix"
|| +------------+--------------------------+
|| | network pre| 0000000000000000000000 |
|| +------------+--------------------------+
\\
``=================> copy RIID to the last 4 bits
+------------+---------------------+----+
| network pre| 0000000000000000000 |RIID|
+------------+---------------------+----+heads up 👀 there are several operational scenarios (check Example 3 below) where the [RFC3306] rule that "all non-significant bits of the network prefix field SHOULD be zero" gets ignored. this is so multicast group allocations stay consistent with unicast prefixes, and the multicast addresses still use the RP tied to the network prefix. it's giving flexibility 🌈
plen higher than 64 MUST NOT be used, bc it would overlap with the high-order bits of the multicast group-id. no thank you 🙅♀️
when routers are turning an encoding into an RP address, they MUST run at least the same address validity checks on the calculated RP address as they would on one received through other means (like BSR [BSR] or MSDP for IPv4). at minimum, fe80::/10, ::/16, and ff00::/8 MUST be excluded. this is super important bc the info comes from an untrusted source, aka any Internet user's input 😭🔥
also, the 4 bits reserved for "RIID" set the upper bound on RPs for a combo of scope, network prefix, and group ID. without changing any of those, you can have 2^4-1 = 15 different RPs (since RIID=0 is reserved, see section 6.3). but each of these is its own IPv6 group address, so there can be only one RP per multicast address 💜
5. Examples 🧚
four examples of multicast address allocation and the resulting group-to-RP mappings are below, so you can see all the possibilities this encoding gives you 🍓
5.1. Example 1
the network admin of 2001:DB8::/32 wants an RP for the network and all the customers, so they put it on an existing subnet, e.g., 2001:DB8:BEEF:FEED::/64 🌸
in that case, the group addresses would look something like FF7x:y40:2001:DB8:BEEF:FEED::/96, and their RP address would be 2001:DB8:BEEF:FEED::y. there are still 32 bits of multicast group-IDs to hand out to customers and self ("y" could be anything from 1 to F, since 0 must not be used).
5.2. Example 2
same admin as Example 1, but this time they want the RP to be more flexible. so they place it on a specifically routed subnet and keep a bigger chunk of address space for group allocations. basically, the admin picks the least specific part of the unicast prefix, with plen=32, and the group addresses come from the multicast prefix:
FF7x:y20:2001:DB8::/64where "x" is the multicast scope, "y" is the interface ID of the RP address, and there are 64 bits for group-IDs or assignments. in this case the RP address would be:
2001:DB8::ythe address 2001:DB8::y/128 gets assigned to a router as a loopback address and injected into the routing system 🦋. if the admin only sets up one or two RPs (e.g., not one RP per subnet), this approach might be the move over Example 1.
5.3. Example 3
same as Example 2, but now the admin can also hand out multicast prefixes like FF7x:y20:2001:DB8:DEAD::/80 to some customers. the RP address still stays 2001:DB8::y. (this is just a more specific subcase of Example 2, where the admin assigns a multicast prefix instead of just individual group-IDs ✨)
check out the second rule for deriving the RP address: the "plen" field in the multicast address, 0x20 = 32, refers to the length of the "network prefix" field used when getting the RP address. so only the first 32 bits of the network prefix field, "2001:DB8", are kept. the value of "plen" doesn't say anything about the actual unicast/multicast prefix lengths allocated or used in the networks (here it's from 2001:DB8:DEAD::/48) 🙈
tl;dr this distinction gives you more flexible RP address config when you want group addresses to line up with the unicast prefix allocations. iconic 👑
5.4. Example 4
in the network from Examples 1, 2, and 3, the network admin sets up addresses for customers, but one organization wants its own PIM-SM domain. the org can pick multicast addresses like FF7x:y30:2001:DB8:BEEF::/80, and then the RP address would be 2001:DB8:BEEF::y 💖
6. Operational Considerations 🌈
this section covers the major operational considerations for anyone deploying this mechanism 🫶
6.1. RP Redundancy
okay so "Anycast RP" is a technique used inside a PIM-SM domain to share an address and multicast state info between a set of RPs, mainly for redundancy 🔁. MSDP has typically been used for this too [ANYCASTRP]. there are other approaches as well, like using PIM to share this info [ANYPIMRP].
the most feasible option for RP failover is using PIM for Anycast RP, or "anycasting" (aka the shared-unicast model [ANYCAST]), the RP address in the Interior Gateway Protocol (IGP) without state sharing. (depending on your redundancy requirements, though, this might or might not be enough 🤷♀️). the redundancy mechanisms are outside the scope of this memo, tho.
6.2. RP Deployment
since there's no need to share inter-domain state with MSDP, each Designated Router connecting multicast sources could act as an RP without any scalability worries about setting up and maintaining MSDP sessions 💅
this is especially appealing when RP redundancy is on your mind. if the DR close to a major source for a group acts as the RP, you get a certain amount of fate-sharing for free, with no RP failover mechanisms needed. but if the DR goes down, the multicast transmission may stop working anyway 💀
along the same lines, it may also be desirable to spread RP responsibilities across multiple RPs. as long as different RPs serve different groups, this is trivial: each group can map to a different RP (or enough different RPs that the load on any one of them isn't a problem). the load sharing challenges a single group faces are similar to those of Anycast-RP, though 🧩
6.3. Guidelines for Assigning IPv6 Addresses to RPs
with this mechanism, the RP can be given basically any unicast network prefix up to /64. the interface identifier will have to be manually configured to match "RIID" 🎀
RIID = 0 must not be used, bc using it would cause ambiguity with the Subnet-Router Anycast Address [ADDRARCH] ⚠️
if an admin wants an RP address that doesn't match the addressing topology but is still from the network provider's unicast prefix (e.g., an additional loopback address on a router, like in Example 2 in Section 5.1), that address can be injected into the routing system via a host route 🦋
6.4. Use as a Substitute for BSR
with embedded-RP, you don't need BSR or other RP config mechanisms throughout the PIM domain, bc each group address already specifies the RP to be used. no extra setup, periodt 🙌
6.5. Controlling the Use of RPs
compared to the MSDP inter-domain ASM model, the control and management of who can use an RP, and how, changes a little and deserves its own discussion 🧐
MSDP advertisement filtering usually includes at least two capabilities: filtering who can create a global session ("source filtering") and filtering which groups should be globally accessible ("group filtering"). these are done to stop local groups from being advertised outside, or unauthorized senders from creating global groups 🛑
but these controls don't block outsiders from using such groups, bc they could still join the groups without a Source Active advertisement, using a (Source, Group) or (S,G) Join by guessing or learning the source and/or group address 👀. for proper protection, you should set up things like PIM multicast scoping borders at the border routers. so by default, embedded-RP has a roughly equivalent level of "protection" to MSDP with SA filtering 💜
a new control issue is that nodes in a "foreign domain" may register to an RP, or send a PIM Join to an RP. (these have been possible before too, to a degree, but only through willful attempts or purposeful RP configuration at DRs.) the main threat here is that an outsider might illegitimately use the RP to host their own group(s) 😤. this can be mitigated to an extent by filtering which groups or group ranges are allowed at the RP. more specific controls are beyond the scope of this memo. and honestly, this doesn't seem to be a serious threat in the first place, since anyone with a /64 unicast prefix can create their own RP without having to illegitimately get one from someone else 🙄
7. The Embedded-RP Group-to-RP Mapping Mechanism 🔥
this section specifies the group-to-RP mapping mechanism for Embedded RP ✨
7.1. PIM-SM Group-to-RP Mapping ✨
okay so the only PIM-SM change you need is adding this as one group-to-RP mapping method 💅 that's literally it bestie
the implementation has to recognize the address format and derive the RP address using the rules in Section 4, then actually use it. that info gets used at least when doing RPF lookups, processing Join/Prune messages, or doing Register-encapsulation 🔥
to avoid loops and inconsistencies, for addresses in the range FF70::/12, the Embedded-RP mapping MUST be considered the longest possible match and higher priority than any other mechanism. the rules are strict here, no exceptions 👑
worth noting: the other group-to-RP mapping mechanisms can be precomputed, but the embedded-RP mapping has to be redone for every new IPv6 group address that would map to a different RP. for efficiency, the results may be cached in an implementation-specific way, so you're not recomputing for every single embedded-RP packet 🧚
this group-to-RP mapping mechanism must be supported by the RP, the DR adjacent to the senders, and any router on the path from any receiver to the RP. paths for Shortest Path Tree (SPT) formation and Register-Stop don't need that support, since those are handled with an (S,G) Join 🦋
7.2. Overview of the Model 🌸
this section is a high-level, non-normative overview of how Embedded RP works, as specified in the previous section. it's just the vibe check, not the rulebook 🙈
the steps when a receiver wants to join a group:
- A receiver finds out a group address by some means (e.g., SDR or a web page).
- The receiver issues an Multicast Listener Discovery (MLD) Report, joining the group.
- The receiver's DR will initiate the PIM-SM Join process towards the RP encoded in the multicast address, irrespective of whether it is in the "local" or "remote" PIM domain.
the steps when a sender wants to send to a group:
- A sender finds out a group address by using an unspecified method (e.g., by contacting the administrator for group assignment or using a multicast address assignment protocol).
- The sender sends to the group.
- The sender's DR will send the packets unicast-encapsulated in PIM-SM Register-messages to the RP address encoded in the multicast address (in the special case that DR is the RP, such sending is only conceptual).
in fact, all the messages go exactly as specified in [PIM-SM]. embedded-RP just acts as a group-to-RP mapping mechanism 🎀 instead of getting the RP address from local configuration or config protocols (e.g., BSR), the algorithm derives it transparently from the encoded multicast address. no extra drama, just math ✨
8. Scalability Analysis 🌈
okay the interdomain MSDP model for connecting PIM-SM domains is mostly hierarchical in configuration and deployment, but flat when it comes to information distribution. the embedded-RP interdomain model acts like every group formed its own Internet-wide PIM domain, with the group mapping to a single RP, no matter where the receivers or senders are located. so interdomain multicast becomes a flat, RP-centered topology 💖 the scaling issues are below.
previously, foreign sources sent the unicast-encapsulated data to their "local" RP. now they go to the "foreign" RP responsible for that specific group. this matters a lot with large multicast groups that have a lot of heavy senders, especially if implementations don't handle unicast-decapsulation well 😭
with IPv4 ASM multicast, there are roughly two kinds of Internet-wide state: MSDP (propagated everywhere) and multicast routing state (on the receiver or sender branches). the former is eliminated, but backbone routers might end up with (*, G) and (S, G, rpt) state between receivers (and past receivers, for PIM Prunes) and the RP, in addition to (S, G) state between receivers and senders if SPT is used. still, the total amount of state is smaller 🍓
in both interdomain and intradomain cases, the embedded-RP model is practically identical to traditional PIM-SM in intradomain. on the other hand, PIM-SM has been deployed (in IPv4) interdomain using MSDP. compared to that model, this spec simplifies tree construction (aka multicast routing) by removing the RP for senders and receivers in foreign domains and eliminating the MSDP information distribution. simplification era 💅
the address of the RP is tied to the multicast address, so RP failure management gets harder. the deployed failover or redundancy mechanisms (e.g., BSR, Anycast-RP with MSDP) can't be used as-is. however, Anycast-RP using PIM provides equal redundancy, and this is described briefly in Section 6.1 🦋
the PIM-SM spec states, "Any RP address configured or learned MUST be a domain-wide reachable address". what "reachable" precisely means isn't clear, even without embedded-RP. this statement can't be proven, especially with foreign RPs, since you can't even guarantee the RP exists 🙈 instead of manually configuring RPs and DRs (configuring a non-existent RP was possible, though rare), this spec has hosts and users indirectly specify the RP themselves, which lowers the expectancy of RP reachability. it's a relatively significant problem, but not much different from current multicast deployment. e.g., MLDv2 (S,G) joins, whether ASM or SSM, yield the same result [PIMSEC].
being able to join or send to remote RPs raises security concerns that are considered separately. it has an upside though: every group has a "responsible RP" that can control (to some extent) who gets to send to the group 👑
a more extensive description and comparison of the interdomain multicast routing models (traditional ASM with MSDP, embedded-RP, SSM) and their security properties is in [PIMSEC].
9. Acknowledgements 💜
Jerome Durand commented on an early version of this memo. Marshall Eubanks noted an issue regarding short plen values. Tom Pusateri noted problems with an earlier SPT-join approach. Rami Lehtonen pointed out issues with the scope of SA-state and provided extensive commentary. Nidhi Bhaskar gave the document a thorough review. Toerless Eckert, Hugh Holbrook, and Dave Meyer provided very extensive feedback. In particular, Pavlin Radoslavov, Dino Farinacci, Nidhi Bhaskar, and Jerome Durand provided good comments during and after WG last call. Mark Allman, Bill Fenner, Thomas Narten, and Alex Zinin provided substantive comments during the IESG evaluation. The whole MboneD working group is also acknowledged for continued support and comments. thank you all, you're the real ones 🫶
10. Security Considerations 💀
this section is serious business, so read it carefully bestie 🚨
the addresses of RPs are encoded in the multicast addresses, which makes them more visible as single points of failure. even though this doesn't significantly affect multicast routing security, it may expose the RP to other kinds of attacks. operators are encouraged to pay special attention to securing these routers. see Section 6.1 for considerations on failover and Section 6.2 for RP placement that leads to a degree of fate-sharing properties.
any RP has to accept PIM-SM Join/Prune/Register messages from any DR, which might cause a potential Denial of Service attack scenario. however, this can be mitigated, because the RP can discard all such messages for all multicast addresses that don't encode the address of the RP. both sender- and receiver-based attacks are described at greater length in [PIMSEC].
additionally, the implementation SHOULD also allow manual configuration of which multicast prefixes are allowed to be used. this can be used to limit the use of the RP to designated groups only. in some cases, being able to restrict (at the RP) which unicast addresses are allowed to send or join to a group is desirable. (however, note that Join/Prune messages would still leave state in the network, and Register messages can be spoofed [PIMSEC].) obviously, these controls are only possible at the RP, not at the intermediate routers or the DR.
It is RECOMMENDED that routers supporting this specification do not act as RPs unless explicitly configured to do so, as becoming an RP does not require any advertisement (e.g., through BSR or manually). Otherwise, any router could potentially become an RP (and be abused as such). Further, multicast groups or group ranges to-be-served MAY need to be explicitly configured at the RPs, to protect them from being used unwillingly. Note that the more specific controls (e.g., "insider-must-create" or "invite-outsiders" models) as to who is allowed to use the groups are beyond the scope of this memo.
excluding internal-only groups from MSDP advertisements doesn't protect the groups from outsiders. it only offers security by obscurity, and embedded-RP offers a similar level of protection. when real protection is desired, PIM scoping, for example, should be set up at the borders. this is described at more length in Section 6.5.
one should observe that the embedded-RP threat model is actually rather similar to SSM. both mechanisms significantly reduce the threats at the sender side. on the receiver side, the threats are somewhat comparable, since an attacker could do an MLDv2 (S,G) join towards a non-existent source, which the local RP could not block based on the MSDP information.
the implementation MUST perform at least the same address validity checks on the embedded-RP address as it would on one received via other means. at least fe80::/10, ::/16, and ff00::/8 should be excluded. this is particularly important, because the information is derived from an untrusted source (i.e., any user on the Internet), not from local configuration 🚨
a more extensive description and comparison of the interdomain multicast routing models (traditional ASM with MSDP, embedded-RP, SSM) and their security properties has been done separately in [PIMSEC].
11. References 📚
11.1. Normative References
[ADDRARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.11.2. Informative References ✨
Okay bestie, this is the "if you want the deep lore" reading list 📚💖. Every entry is copied exactly as written:
[ANYCAST] Hagino, J. and K. Ettikan, "An analysis of IPv6 anycast",
Work in Progress, June 2003.
[ANYCASTRP] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci,
"Anycast Rendevous Point (RP) mechanism using Protocol
Independent Multicast (PIM) and Multicast Source
Discovery Protocol (MSDP)", RFC 3446, January 2003.
[ANYPIMRP] Farinacci, D. and Y. Cai, "Anycast-RP using PIM", Work in
Progress, June 2004.
[BSR] Fenner, B., et al., "Bootstrap Router (BSR) Mechanism for
PIM Sparse Mode", Work in Progress, July 2004.
[MSDP] Fenner, B. and D. Meyer, "Multicast Source Discovery
Protocol (MSDP)", RFC 3618, October 2003.
[PIMSEC] Savola, P., Lehtonen, R., and D. Meyer, "PIM-SM Multicast
Routing Security Issues and Enhancements", Work in
Progress, October 2004.
[PIM-SM] Fenner, B. et al, "Protocol Independent Multicast -
Sparse Mode (PIM-SM): Protocol Specification (Revised)",
Work in Progress, July 2004.
[SSM] Holbrook, H. et al, "Source-Specific Multicast for IP",
Work in Progress, September 2004.
[V6MISSUES] Savola, P., "IPv6 Multicast Deployment Issues", Work in
Progress, September 2004.A. Discussion about Design Tradeoffs 💅
Okay so this appendix is the "why did we do it this way" tea ☕🔥. Here's the spill:
The document only specifies FF70::/12 for now 🎀. If and when the upper-most bit gets used, somebody has to spell out how FFF0::/12 applies to Embedded-RP. For example, a different mode of PIM or another protocol might use that range, while FF70::/12 as currently specified is for PIM-SM only 🌸.
Instead of using flags bits (FF70::/12), we could have used the leftmost reserved bits instead (FF3x:8000::/17) 🦋.
People have argued that instead of letting the operator specify the RIID, the value could be pre-determined (for example, 1) ✨. This hasn't been adopted, though, because it takes away address assignment flexibility from the operator 🙈.
Values 64 < plen < 96 would overlap with the upper bits of the multicast group-id 😭. Because of this restriction, plen must not exceed 64 bits. This is in line with RFC 3306 💜.
The embedded-RP addressing could be used to carry other information too, not just the RP address. For example, it could carry the RPT threshold for PIM-SM 🧚. Whether that's feasible or not, it could be encoded in the RP address somehow, or in the multicast group address. Either way, such modifications are beyond the scope of this memo 💀.
For the cases where the RPs do not exist or are unreachable, or too much state is being generated to reach in a resource exhaustion Denial of Service attack, some forms of rate-limiting or other mechanisms could be deployed to mitigate the threats while trying not to disturb the legitimate usage. However, as the threats are generic, they are considered out of scope and discussed separately in [PIMSEC]. 🚨
Authors' Addresses 🫶
Pekka Savola
CSC/FUNET
Espoo, Finland
EMail: psavola@funet.fi
Brian Haberman
Johns Hopkins University Applied Physics Lab
11100 Johns Hopkins Road
Laurel, MD 20723-6099
US
Phone: +1 443 778 1319
EMail: brian@innovationslab.netFull Copyright Statement 📜
The legal bits, copied word for word so nothing gets lost in translation 🙏:
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Intellectual Property 🌈
Also legal, also verbatim, because this part matters 💅:
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.Acknowledgement 🍓
Last but not least, the thank-you note 🫶✨. Funding for the RFC Editor function is currently provided by the Internet Society 💖.
📦 where this page comes from
- ietf: rfc3956 2004-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms