RFC 8114
Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network
Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6 Multicast Network 💖
Okay so bestie, this is RFC 8114, a Standards Track doc from the IETF, dated March 2017 🎀. It's written by M. Boucadair (Orange), C. Qin (Cisco), C. Jacquenet (Orange), Y. Lee (Comcast), and Q. Wang (China Telecom) 🫶. It's in the ISSN 2070-1721 series and it does not obsolete or update any other RFC, so it's totally standalone vibes ✨. Let's get into it 💅
Abstract
This doc is all about getting IPv4 multicast streams to IPv4 clients who are sitting on an IPv6 multicast network 🦋. The trick is a stateless IPv4-in-IPv6 encapsulation scheme, and the actual delivery runs on an IPv6 multicast distribution tree 🌈. It's especially giving for customers on Dual-Stack Lite (DS-Lite) 👑.
Status of This Memo
This is an Internet Standards Track document 🔥.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community 💜. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG) ✨. If you want more on Internet Standards, check Section 2 of RFC 7841 🧚.
For the current status, any errata, or to send feedback, go to http://www.rfc-editor.org/info/rfc8114 🌸.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved 🎀.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stood on the publication date 💅. Read these carefully, bestie, because they spell out your rights and restrictions. Code Components pulled from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty as described in the Simplified BSD License 🙈.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 6
4.1. IPv4-Embedded IPv6 Prefixes . . . . . . . . . . . . . . . 7
4.2. Multicast Distribution Tree Computation . . . . . . . . . 8
4.3. Multicast Data Forwarding . . . . . . . . . . . . . . . . 9
5. IPv4/IPv6 Address Mapping . . . . . . . . . . . . . . . . . . 9
5.1. Prefix Assignment . . . . . . . . . . . . . . . . . . . . 9
5.2. Multicast Address Translation Algorithm . . . . . . . . . 10
5.3. Textual Representation . . . . . . . . . . . . . . . . . 10
5.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Multicast B4 (mB4) . . . . . . . . . . . . . . . . . . . . . 11
6.1. IGMP-MLD Interworking Function . . . . . . . . . . . . . 11
6.2. Multicast Data Forwarding . . . . . . . . . . . . . . . . 12
6.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 12
6.4. Host Built-In mB4 Function . . . . . . . . . . . . . . . 12
6.5. Preserve the Scope . . . . . . . . . . . . . . . . . . . 13
7. Multicast AFTR (mAFTR) . . . . . . . . . . . . . . . . . . . 13
7.1. Routing Considerations . . . . . . . . . . . . . . . . . 13
7.2. Processing PIM Messages . . . . . . . . . . . . . . . . . 14
7.3. Switching from Shared Tree to Shortest Path Tree . . . . 15
7.4. Multicast Data Forwarding . . . . . . . . . . . . . . . . 15
7.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8. Deployment Considerations . . . . . . . . . . . . . . . . . . 16
8.1. Other Operational Modes . . . . . . . . . . . . . . . . . 16
8.1.1. The IPv6 DR is Co-located with the mAFTR . . . . . . 16
8.1.2. The IPv4 DR is Co-located with the mAFTR . . . . . . 16
8.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 16
8.3. mAFTR Policy Configuration . . . . . . . . . . . . . . . 16
8.4. Static vs. Dynamic PIM Triggering . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Firewall Configuration . . . . . . . . . . . . . . . . . 17
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
11.1. Normative References . . . . . . . . . . . . . . . . . . 18
11.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Use Case: IPTV . . . . . . . . . . . . . . . . . . . 21
Appendix B. Older Versions of Group Membership Management
Protocols . . . . . . . . . . . . . . . . . . . . . 22
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 231. Introduction ✨
1.1. Requirements Language 🎀
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 RFC 2119 [RFC2119].
2. Terminology 🦋
This doc uses the following terms, so let's get on the same page 🫶.
IPv4-embedded IPv6 address: an IPv6 address that embeds a 32-bit-encoded IPv4 address. It can be unicast or multicast 🌸.
mPrefix64: a dedicated multicast IPv6 prefix for building IPv4-embedded IPv6 multicast addresses. There are two flavours: ASM_mPrefix64, used in Any-Source Multicast (ASM) mode, and SSM_mPrefix64, used in Source-Specific Multicast (SSM) mode [RFC4607]. The size of this prefix is /96 💜.
Note: "64" is short for IPv6-IPv4 interconnection 🧚.
uPrefix64: a dedicated IPv6 unicast prefix for building IPv4-embedded IPv6 unicast addresses [RFC6052]. It can be either the Well-Known Prefix (i.e., 64:ff9b::/96) or a Network-Specific Prefix (NSP) 🍓.
Multicast AFTR (mAFTR): a functional entity that supports an IPv4-IPv6 multicast interworking function (refer to Figure 3). It receives and encapsulates the IPv4 multicast packets into IPv4-in-IPv6 packets. It also acts as the corresponding IPv6 multicast source for those encapsulated IPv4-in-IPv6 packets 👑.
Multicast Basic Bridging BroadBand (mB4): a functional entity that supports an IGMP-MLD Interworking function (refer to Section 6.1) that translates IGMP messages into the matching Multicast Listener Discovery (MLD) messages and sends those MLD messages to the IPv6 network. On top of that, the mB4 decapsulates IPv4-in-IPv6 multicast packets 🌈.
PIMv4: refers to Protocol Independent Multicast (PIM) when it's deployed in an IPv4 infrastructure (i.e., IPv4 transport capabilities are used to exchange PIM messages) 💅.
PIMv6: refers to PIM when it's deployed in an IPv6 infrastructure (i.e., IPv6 transport capabilities are used to exchange PIM messages) 🌸.
Host portion of the MLD protocol: refers to the part of MLD that applies to all multicast address listeners (Section 6 of [RFC3810]). Quick reminder: MLD has separate behaviours for multicast address listeners (hosts or routers that listen to multicast packets) and for multicast routers 🙈.
Router portion of IGMP: refers to the part of IGMP that is performed by multicast routers (Section 6 of [RFC3376]) 🎀.
DR: refers to the Designated Router as defined in [RFC7761] ✨.
3. Scope 💖
This doc only looks at subscribing to IPv4 multicast groups and delivering IPv4-formatted content to IPv4 receivers over an IPv6-only network 🦋. Specifically, only this one case is covered:
IPv4 receivers access IPv4 multicast content over IPv6-only multicast-enabled networks.
It does not cover source/receiver heuristics, where IPv4 receivers can also act as IPv4 multicast sources 🙈. The doc assumes that hosts behind the mB4 are IPv4 multicast receivers only. It also covers the host built-in mB4 function 🧚.
Part 1 of 4 is done, bestie 🫶 Say the word and I'll pick up with Section 4 (Solution Overview) next 💅✨
4. Solution Overview ✨
okay so, the DS-Lite spec [RFC6333] already uses an IPv4-in-IPv6 tunnel to carry two-way IPv4 unicast traffic between a B4 and an AFTR. This document adds an IPv4-in-IPv6 encapsulation scheme that delivers one-way IPv4 multicast traffic from an mAFTR to an mB4. 🦋
This section is a friendly overview of how it all works. It's an intro, not normative. For the real normative specs of the two new elements, mB4 and mAFTR (Figure 1), go check out Sections 6 and 7. 💅
------------
/ \
| IPv4 network |
\ /
------------
IPv4 multicast : | ^ PIMv4 Join
v | :
+-------------+
| mAFTR |
+-------------+
IPv6 multicast |:| | ^ PIMv6 Join (PIMv6
(IPv4 embedded) |:| | : routers in between)
------------
/ \
| IPv6 network |
\ /
------------
|:| | ^ MLD Report
|v| | :
+-----------+
| mB4 |
+-----------+
IPv4 multicast : | ^ IGMP Report
v | :
+-----------+
| IPv4 |
| receiver |
+-----------+Figure 1: Functional Architecture
4.1. IPv4-Embedded IPv6 Prefixes
so to map IPv4 multicast addresses onto IPv6 multicast addresses, the mAFTR and the mB4 each get an IPv6 multicast prefix (mPrefix64) and an IPv6 unicast prefix (uPrefix64). Both of these help build and maintain the IPv6 multicast distribution tree, which stretches the IPv4 tree out into the IPv6 multicast network. The address mapping is stateless, so there's no per-flow state to keep track of. 🧚
The mAFTR and the mB4 use mPrefix64 to turn an IPv4 multicast address (G4) into an IPv4-embedded IPv6 multicast address (G6). They use uPrefix64 to turn an IPv4 source address (S4) into an IPv4-embedded IPv6 address (S6). The mAFTR and the mB4 must use the same mPrefix64 and uPrefix64, and they also run the same algorithm for building IPv4-embedded IPv6 addresses. Check out Section 5 for more details on the address mapping. 🌸
4.2. Multicast Distribution Tree Computation
when an IPv4 receiver hanging off a device with mB4 capability wants to subscribe to an IPv4 multicast group, it sends an IGMP Report message toward the mB4. The mB4 builds the IPv6 multicast group (G6) address using mPrefix64 and the original IPv4 multicast group address. If the receiver sends a source-specific IGMPv3 Report message, the mB4 also creates the IPv6 source address (S6) using uPrefix64 and the original IPv4 source address. 🎀
The mB4 uses G6 (and both S6 and G6 in SSM) to create the matching MLD Report message, then sends that Report toward the IPv6 network. The PIMv6 DR receives the MLD Report and sends a PIMv6 Join message to join the IPv6 multicast distribution tree. It can send either a PIMv6 Join (*,G6) in ASM or a PIMv6 Join (S6,G6) in SSM to the mAFTR. 🦋
The mAFTR acts as the IPv6 DR that the uPrefix64-derived S6 is connected to. It receives the source-specific PIMv6 Join message (S6,G6) from the IPv6 multicast network. If the mAFTR is the Rendezvous Point (RP) of G6, it receives the any-source PIMv6 Join message (*,G6) from the IPv6 multicast network instead. If the mAFTR is not the RP of G6, it sends the PIM Register message to the RP of G6, which lives in the IPv6 multicast network. For simplicity's sake, it is recommended to configure the mAFTR as the RP for the IPv4-embedded IPv6 multicast groups it manages. Under this configuration, no registration procedure is required. 💅
When the mAFTR receives the PIMv6 Join message (*,G6), it pulls out the IPv4 multicast group address (G4). If the mAFTR is the RP of G4 in the IPv4 multicast network, it creates a (*,G4) entry (if one doesn't already exist) in its own IPv4 multicast routing table. If the mAFTR is not the RP of G4, it sends the matching PIMv4 Join message (*,G4) toward the RP of G4 in the IPv4 multicast network. 🍓
When the mAFTR receives the PIMv6 Join message (S6,G6), it pulls out the IPv4 multicast group address (G4) and the IPv4 source address (S4), then sends the corresponding (S4,G4) PIMv4 Join message directly to the IPv4 source. 🫶
So a branch of the multicast distribution tree gets built, with an IPv4 part (from the mAFTR upstream) and an IPv6 part (from the mAFTR downstream toward the mB4). Iconic. 👑
The mAFTR advertises the uPrefix64 route with an IPv6 Interior Gateway Protocol (IGP). This represents the IPv4-embedded IPv6 source in the IPv6 multicast network and lets IPv6 routers run the Reverse Path Forwarding (RPF) check on incoming multicast traffic. Injecting internal /96 routes isn't a problem, because [RFC7608] recommends that forwarding processes must be designed to handle prefixes of any length up to /128. Main character energy, literally. ✨
4.3. Multicast Data Forwarding
when the mAFTR gets an IPv4 multicast packet, it encapsulates that packet into an IPv6 multicast packet. The destination address is the IPv4-embedded IPv6 multicast address, and the source address is an IPv4-embedded IPv6 unicast address. The encapsulated IPv6 multicast packet then gets forwarded down the IPv6 multicast distribution tree, and the mB4 eventually receives it. 🌈
The IPv6 multicast network treats these IPv4-in-IPv6 encapsulated multicast packets as native IPv6 multicast packets. The IPv6 multicast routers make their forwarding decisions using the outer IPv6 header. 🧚
When the mB4 gets an IPv6 multicast packet (to G6) derived via mPrefix64, it decapsulates the packet and forwards the original IPv4 multicast packet toward the receivers subscribed to G4. 🎀
Note: At this point, only IPv4-in-IPv6 encapsulation is defined. Other types of encapsulation could be defined in the future. 🙈
5. IPv4/IPv6 Address Mapping 🗺️
5.1. Prefix Assignment
a dedicated IPv6 multicast prefix (mPrefix64) gets provisioned to the mAFTR and the mB4. They both use mPrefix64 to form an IPv6 multicast group address from an IPv4 multicast group address. The mPrefix64 comes in two flavors: ASM_mPrefix64 (an mPrefix64 used in ASM mode) or SSM_mPrefix64 (an mPrefix64 used in SSM mode). The mPrefix64 MUST be derived from the corresponding IPv6 multicast address space. For example, the SSM_mPrefix64 must be in the range of the multicast address space specified in [RFC4607]. 💖
The IPv6 part of the multicast distribution tree can be seen as an extension of the IPv4 part. The IPv4 source address MUST be mapped to an IPv6 source address. An IPv6 unicast prefix (uPrefix64) is provisioned to the mAFTR and the mB4, and they both use uPrefix64 to form an IPv6 source address from an IPv4 source address, as specified in [RFC6052]. That uPrefix-formed IPv6 source address represents the original IPv4 source in the IPv6 multicast network. The uPrefix64 MUST be derived from the IPv6 unicast address space. 🦋
The multicast address translation MUST follow the algorithm defined in Section 5.2. 🫶
The mPrefix64 and uPrefix64 can be configured on the mB4 in a bunch of ways: an out-of-band mechanism, manual configuration, or a dedicated provisioning protocol (for example, DHCPv6 [RFC8115]). 🌸
The stateless translation mechanism described in Section 5 does not preclude use of Embedded-RP [RFC3956] [RFC7371]. ✨
5.2. Multicast Address Translation Algorithm
IPv4-embedded IPv6 multicast addresses get composed with the following algorithm:
- Concatenate the 96 bits of the mPrefix64 and the 32 bits of the IPv4 address to obtain a 128-bit address.
the IPv4 multicast addresses get extracted from the IPv4-embedded IPv6 multicast addresses with this one:
- If the multicast address has a pre-configured mPrefix64, extract the last 32 bits of the IPv6 multicast address.
an IPv4 source is represented in the IPv6 realm with its IPv4-converted IPv6 address [RFC6052]. 💅
5.3. Textual Representation
the embedded IPv4 address in an IPv6 multicast address lives in the last 32 bits, so dotted decimal notation can be used. 🧚
5.4. Examples
Group address mapping example:
+---------------------+--------------+----------------------------+
| mPrefix64 | IPv4 address | IPv4-Embedded IPv6 address |
+---------------------+--------------+----------------------------+
| ff0x::db8:0:0/96 | 233.252.0.1 | ff0x::db8:233.252.0.1 |
+---------------------+--------------+----------------------------+Source address mapping example when a /96 is used:
+---------------------+--------------+----------------------------+
| uPrefix64 | IPv4 address | IPv4-Embedded IPv6 address |
+---------------------+--------------+----------------------------+
| 2001:db8::/96 | 192.0.2.33 | 2001:db8::192.0.2.33 |
+---------------------+--------------+----------------------------+the IPv4 and IPv6 addresses in this example come from the IPv4 and IPv6 blocks reserved for documentation, as per [RFC6676]. The unicast IPv4 address in the example above comes from the documentation address block defined in [RFC6890]. 🌈
6. Multicast B4 (mB4) 🎀
6.1. IGMP-MLD Interworking Function
the IGMP-MLD Interworking function combines the IGMP/MLD Proxying function and the address-synthesizing operations. The IGMP/MLD Proxying function is specified in [RFC4605]. The address translation is stateless, and it MUST follow the address mapping specified in Section 5. 💖
The mB4 performs the host portion of the MLD protocol on the upstream interface. The IPv6 membership is composed through address-synthesizing operations, and it MUST synchronize with the membership database maintained in the IGMP domain. MLD messages go natively to the directly connected IPv6 multicast routers, which are processed by the PIM DR. The mB4 also performs the router portion of IGMP on the downstream interface(s). Refer to [RFC4605] for more details. 🦋
+----------+ IGMP +-------+ MLD +---------+
| IPv4 |---------| mB4 |---------| PIM |
| Receiver | | | | DR |
+----------+ +-------+ +---------+Figure 2: IGMP-MLD Interworking
If SSM is deployed, the mB4 MUST construct the IPv6 source address (or retrieve the IPv4 source address) using the uPrefix64. The mB4 MAY create a membership database that associates the IPv4-IPv6 multicast groups with the interfaces (for example, WLAN and wired Ethernet) facing IPv4 multicast receivers. 🫶
6.2. Multicast Data Forwarding ✨
okay so bestie, when the mB4 gets an IPv6 multicast packet, it MUST check the group address AND the source address 👀 if the group prefix is mPrefix64 and the source prefix is uPrefix64, it MUST decapsulate the IPv6 header [RFC2473] 🎀 then the IPv4 multicast packet gets forwarded out each relevant interface using normal IPv4 multicast forwarding 💅 if it doesn't match, the mB4 MUST silently drop the packet 🙈 no drama, just gone ✨
here's an example so it clicks 🦋 a packet comes in from source 2001:db8::192.0.2.33 headed for group ff3x:20:2001:db8::233.252.0.1. the mB4 decapsulates it into an IPv4 multicast packet with 192.0.2.33 as the IPv4 source and 233.252.0.1 as the IPv4 destination group 😭 this one assumes the mB4 is provisioned with uPrefix64 (2001:db8::/96) and mPrefix64 (ff3x:20:2001:db8::/96) 🫶
Source: 2001:db8::192.0.2.33
Group: ff3x:20:2001:db8::233.252.0.1
-> IPv4 source: 192.0.2.33
-> IPv4 group: 233.252.0.16.3. Fragmentation 🍓
bestie, so here's the thing: wrapping IPv4 multicast into IPv6 multicast along the IPv6 distribution tree shaves the effective MTU by the size of an IPv6 header 😩 this data only flows one way, from the mAFTR to the mB4 🦋 the mAFTR MUST fragment the oversized IPv6 packet AFTER encapsulating it into two IPv6 packets 🔥 the mB4 MUST reassemble those IPv6 packets, decapsulate the IPv6 header, and forward the IPv4 packet to the hosts that subscribed to that group 💖 more fragmentation details live in Sections 5.3 and 6.3 of [RFC6333] 🧚
6.4. Host Built-In mB4 Function 💜
if the mB4 is built into a host that's directly connected to an IPv6-only network, that host MUST implement the behaviors in Sections 6.1, 6.2, and 6.3 🫶 it MAY optimize things by offering an Application Programming Interface (API) or kernel module that skips the IGMP-MLD Interworking function ✨ optimization stuff is out of scope for this spec, so no spiraling about it 🙈
6.5. Preserve the Scope 🌈
when several mPrefix64s are around and each embedded IPv4-embedded IPv6 multicast prefix has its own scope, the mB4 MUST pick the prefix whose scope matches the IPv4 multicast address used to build the IPv4-embedded IPv6 multicast address (the specific mappings are in Section 8 of [RFC2365]) 👑 the mapping has to be set up so the selected IPv6 prefix's scope never goes past the original IPv4 scope 💅 if the mB4 is told to preserve the scope and no IPv6 prefix matches, IPv6 multicast address mapping SHOULD fail 😭 the mB4 MAY skip scope preservation when it's running the address translation algorithm 🦋
example time 🎀 say an mB4 has two mPrefix64s: ff0e::db8:0:0/96 (global scope) and ff08::db8:0:0/96 (organization scope) 💖 if it gets an IGMP Report from an IPv4 receiver wanting 233.252.0.1, it checks which mPrefix64 keeps the scope of that group intact 🔍 since 233.252.0.1 is meant for global use, the mB4 builds the IPv6 group (G6) address with ff0e::db8:0:0/96 plus the original IPv4 group: ff0e::db8:233.252.0.1 ✨
mPrefix64 (global): ff0e::db8:0:0/96
mPrefix64 (organization): ff08::db8:0:0/96
Selected G6 address: ff0e::db8:233.252.0.1- Multicast AFTR (mAFTR) 🦋
7.1. Routing Considerations 💅
the mAFTR is the bridge between the IPv4 multicast distribution tree and the matching IPv6 multicast distribution tree 🌸 it MUST use uPrefix64 to build the IPv6 source addresses for the multicast group address derived from mPrefix64 💖 in other words, the mAFTR MUST be the multicast source whose address comes from uPrefix64 👑 it also MUST advertise the route toward uPrefix64 with the IPv6 IGP 🔥 that's how IPv6 multicast routers learn the routing info they need to find the source 🧚
7.2. Processing PIM Messages 🫶
the mAFTR MUST interwork PIM Join/Prune messages for (,G6) and (S6,G6) on their matching (,G4) and (S4,G4) ✨ here's what the mAFTR should do with PIM Join messages 👀
+---------+
---------| mAFTR |---------
PIMv6 |uPrefix64| PIMv4
|mPrefix64|
+---------+
Figure 3: PIMv6-PIMv4 Interworking Functionthe mAFTR has two separate Tree Information Bases (TIBs): the IPv4 Tree Information Base (TIB4) and the IPv6 Tree Information Base (TIB6), linked by one IPv4-in-IPv6 virtual interface 🦋 TIB implementations can vary (some might use a single integrated TIB with no virtual interface), but they SHOULD still follow this spec for global and functional consistency 💜
when an mAFTR gets a PIMv6 Join message (,G6) with an IPv6 group address (G6) derived from mPrefix64, it MUST check its TIB6 🔍 if there's already an entry for G6, it MUST check whether the interface the Join came in on is in the outgoing interface (oif) list, and if it isn't, the mAFTR MUST add it 🎀 if there's no TIB6 entry, the mAFTR MUST create a new (,G6) entry for that group 🌈 whether the IPv4-in-IPv6 virtual interface becomes the incoming interface of that new entry is up to the implementation, but it SHOULD line up with the mAFTR's multicast data forwarding behavior (see Section 7.4) 💅
the mAFTR MUST pull the IPv4 group address (G4) out of the IPv4-embedded IPv6 multicast address (G6) inside the PIMv6 Join message 🧚 then it MUST check its TIB4 ✨ if there's an entry for G4, it MUST check whether the IPv4-in-IPv6 virtual interface is in the oif list, and if not, the mAFTR MUST add it 💖 if there's no G4 entry, the mAFTR MUST create a new (*,G4) entry in its TIB4 and start building the shared tree in the IPv4 multicast network, with no extra requirements 🔥
if the mAFTR gets a source-specific Join message, the (S6,G6) gets processed instead of (*,G6) 🦋 the two procedures are almost the same, and the differences are detailed in [RFC7761] 👑
7.3. Switching from Shared Tree to Shortest Path Tree 🌸
when the mAFTR gets the first IPv4 multicast packet, it may pull the source address (S4) out of the packet and send an Explicit PIMv4 (S4,G4) Join message straight to S4 🫶 the mAFTR then switches from the shared Rendezvous Point Tree (RPT) to the Shortest Path Tree (SPT) for G4 ✨
for IPv6 multicast routers to switch to the SPT, there's no new requirement 💅 they may send an Explicit PIMv6 Join to the mAFTR once the first (S6,G6) multicast packet shows up from upstream multicast routers 🧚
7.4. Multicast Data Forwarding 🎀
when the mAFTR gets an IPv4 multicast packet, it checks TIB4 for a matching entry and forwards the packet out the interface(s) on the outgoing interface list 🦋 if the IPv4-in-IPv6 virtual interface is on that list too, the packet gets encapsulated using the mPrefix64-derived and uPrefix64-derived IPv4-embedded IPv6 addresses to form an IPv6 multicast packet [RFC2473] 💖 then the mAFTR does another lookup to find a matching entry in TIB6 👀 whether the RPF check happens on that second lookup is up to the implementation and out of scope for this doc 🔍 the IPv6 multicast packet then goes out along the IPv6 distribution tree, based on the oif list of the matching TIB6 entry 💜
as an example, a packet from source 192.0.2.33 headed for group 233.252.0.1 gets encapsulated by the mAFTR into an IPv6 multicast packet with ff3x:20:2001:db8::233.252.0.1 as the IPv6 destination group and 2001:db8::192.0.2.33 as the IPv6 source address 🫶
IPv4 source: 192.0.2.33
IPv4 group: 233.252.0.1
IPv6 source: 2001:db8::192.0.2.33
IPv6 group (G6): ff3x:20:2001:db8::233.252.0.17.5. Scope 🌈
the Scope field of IPv4-in-IPv6 multicast addresses SHOULD be set appropriately for the deployment (for example, to "E" for global scope) 💅 this spec doesn't say which scope value to use 🙈
the mAFTR has to follow the considerations in Section 6.5 too 👑
- Deployment Considerations ✨
8.1. Other Operational Modes 🦋
8.1.1. The IPv6 DR is Co-located with the mAFTR 💖
the mAFTR MAY embed the MLD Querier function (along with the PIMv6 DR) for optimization 🔥 when the mB4 sends an MLD Report message to this mAFTR, the mAFTR SHOULD process the MLD Report containing the IPv4-embedded IPv6 multicast group address and then send the matching PIMv4 Join message (Figure 4) 🧚
+---------+
---------| mAFTR |---------
MLD |uPrefix64| PIMv4
|mPrefix64|
+---------+
Figure 4: MLD-PIMv4 Interworking Functionwhere the mAFTR capability sits and the ASM or SSM multicast design stuff are out of scope for this doc 🙈
8.1.2. The IPv4 DR is Co-located with the mAFTR 🌸
if the mAFTR is co-located with the IPv4 DR connected to the original IPv4 source, it can just use the uPrefix64 and mPrefix64 prefixes to build the IPv4-embedded IPv6 multicast packets, and sending PIMv4 Join messages becomes unnecessary 🎀
8.2. Load Balancing 🫶
for robustness and load distribution, several nodes can embed the mAFTR function 💜 in that case, the same IPv6 prefixes (mPrefix64 and uPrefix64) and the same algorithm for building IPv4-embedded IPv6 addresses MUST be configured on all of those nodes 👑
8.3. mAFTR Policy Configuration 💅
the mAFTR MAY be configured with a list of IPv4 multicast groups and sources 🦋 only multicast flows bound to those configured addresses SHOULD be handled by the mAFTR 🔍 otherwise, packets get silently dropped 🙈
8.4. Static vs. Dynamic PIM Triggering ⭐
to save network resources in current deployments, all multicast streams are sent through the core network, while only the most popular ones get forwarded in the aggregation/access networks (static mode) 💖 less popular streams go to the access network only when someone requests them (dynamic mode) 🧚 depending on where the mAFTR sits in the network, there are two modes: static and dynamic 🌈
Static Mode: The mAFTR is configured to set up permanent (S6,G6) and (*,G6) entries in its TIB6 using a pre-configured (S4,G4) list 🎀
Dynamic Mode: Adding or removing (S6,G6) or (*,G6) entries is triggered by receiving PIMv6 messages 💅
9. Security Considerations 🛡️
okay bestie, security time, and it's a little dramatic 💀 Besides the multicast scoping stuff (see Sections 6.5 and 7.5), this document doesn't bring any new security drama beyond what's already covered in Section 5 of [RFC6052], Section 10 of [RFC3810], and Section 6 of [RFC7761]. Lowkey a relief 🫶
Unlike solutions that map IPv4 multicast flows to IPv6 unicast flows, this document does not make Denial-of-Service (DoS) attacks worse. That's a major slay ✨
An mB4 SHOULD be given the right configuration info so it keeps the scope of a multicast message intact when it maps an IPv4 multicast address into an IPv4-embedded IPv6 multicast address, and back again. Scope is everything, babe 💅
9.1. Firewall Configuration
The CPE that embeds the mB4 function SHOULD be set up to accept incoming MLD messages, plus traffic forwarded to the multicast groups that receivers in the customer premises have subscribed to. Let the multicast in, periodt 🌸
10. IANA Considerations
This document doesn't need any IANA actions. Zero registry drama, iconic 🎀
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23,
RFC 2365, DOI 10.17487/RFC2365, July 1998,
<http://www.rfc-editor.org/info/rfc2365>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<http://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<http://www.rfc-editor.org/info/rfc3810>.
[RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick,
"Internet Group Management Protocol (IGMP) / Multicast
Listener Discovery (MLD)-Based Multicast Forwarding
("IGMP/MLD Proxying")", RFC 4605, DOI 10.17487/RFC4605,
August 2006, <http://www.rfc-editor.org/info/rfc4605>.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, DOI 10.17487/RFC4607, August 2006,
<http://www.rfc-editor.org/info/rfc4607>.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
DOI 10.17487/RFC6052, October 2010,
<http://www.rfc-editor.org/info/rfc6052>.
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
Stack Lite Broadband Deployments Following IPv4
Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011,
<http://www.rfc-editor.org/info/rfc6333>.
[RFC7608] Boucadair, M., Petrescu, A., and F. Baker, "IPv6 Prefix
Length Recommendation for Forwarding", BCP 198, RFC 7608,
DOI 10.17487/RFC7608, July 2015,
<http://www.rfc-editor.org/info/rfc7608>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <http://www.rfc-editor.org/info/rfc7761>.11.2. Informative References
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", RFC 2236, DOI 10.17487/RFC2236, November 1997,
<http://www.rfc-editor.org/info/rfc2236>.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, DOI 10.17487/RFC3956, November 2004,
<http://www.rfc-editor.org/info/rfc3956>.
[RFC6676] Venaas, S., Parekh, R., Van de Velde, G., Chown, T., and
M. Eubanks, "Multicast Addresses for Documentation",
RFC 6676, DOI 10.17487/RFC6676, August 2012,
<http://www.rfc-editor.org/info/rfc6676>.
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., Ed., and B. Haberman,
"Special-Purpose IP Address Registries", BCP 153,
RFC 6890, DOI 10.17487/RFC6890, April 2013,
<http://www.rfc-editor.org/info/rfc6890>.
[RFC7371] Boucadair, M. and S. Venaas, "Updates to the IPv6
Multicast Addressing Architecture", RFC 7371,
DOI 10.17487/RFC7371, September 2014,
<http://www.rfc-editor.org/info/rfc7371>.
[RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I.
Farrer, "Lightweight 4over6: An Extension to the Dual-
Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596,
July 2015, <http://www.rfc-editor.org/info/rfc7596>.
[RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S.,
Murakami, T., and T. Taylor, Ed., "Mapping of Address and
Port with Encapsulation (MAP-E)", RFC 7597,
DOI 10.17487/RFC7597, July 2015,
<http://www.rfc-editor.org/info/rfc7597>.
[RFC8115] Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6
Option for IPv4-Embedded Multicast and Unicast IPv6
Prefixes", RFC 8115, DOI 10.17487/RFC8115, March 2017,
<http://www.rfc-editor.org/info/rfc8115>.Appendix A. Use Case: IPTV 📺
IPTV generally comes in two flavours of service, and I'm obsessed with both 🍓
- Video on Demand (VoD) that streams unicast video content to receivers.
- Multicast live TV broadcast services.
There are two types of provider involved in delivering this service:
- Content Providers, who usually own the content that gets multicast to receivers. Content providers may contractually define an agreement with network providers to deliver content to receivers.
- Network Providers, who provide network connectivity services (e.g., network providers are responsible for carrying multicast flows from head-ends to receivers).
Some contract agreements stop a network provider from altering the content as the content provider sent it, for various reasons. Depending on those contracts, multicast streams should be delivered unaltered to the requesting users. Boundaries matter, no cap 🙈
Most current IPTV content is likely to stay IPv4-formatted and out of the control of network providers. There are also loads of legacy receivers (e.g., IPv4-only Set-Top Boxes (STBs)) that can't be upgraded or easily replaced to support IPv6. So IPv4 service continuity must be guaranteed during the transition period, including delivery of multicast services such as Live TV Broadcasting to users. Non-negotiable, bestie 👑
Appendix B. Older Versions of Group Membership Management Protocols 🧚
Since there are multiple versions of group membership management protocols, mismatch issues may pop up at the mB4 (refer to Section 6.1). Lowkey messy, but solvable ✨
If IGMPv2 runs on the IPv4 receivers while MLDv2 runs on the MLD Querier, or if IGMPv3 runs on the IPv4 receivers while MLDv1 runs on the MLD Querier, you'll hit a version mismatch issue. To fix it, the mB4 should perform the router portion of IGMP, which is similar to the matching MLD version (IGMPv2 for MLDv1 or IGMPv3 for MLDv2) running in the IPv6 domain. Then the protocol interaction approach specified in Section 7 of [RFC3376] can be applied to exchange signaling messages with the IPv4 receivers that are running the different version of IGMP. It's giving problem-solver 💖
Note that support for IPv4 SSM requires MLDv2 to be enabled in the IPv6 network. Don't forget this one, iykyk 🫶
Acknowledgements 🌈
The authors would like to thank Dan Wing for his guidance in the early discussions that kicked off this work. We also thank Peng Sun, Jie Hu, Qiong Sun, Lizhong Jin, Alain Durand, Dean Cheng, Behcet Sarikaya, Tina Tsou, Rajiv Asati, Xiaohong Deng, and Stig Venaas for their valuable comments.
Many thanks to Ian Farrer for the review.
Thanks to Zhen Cao, Tim Chown, Francis Dupont, Jouni Korhonen, and Stig Venaas for the directorates review. The whole squad showed up 🙌
Authors' Addresses 💌
Mohamed Boucadair
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Chao Qin
Cisco
Shanghai
China
Email: jacni@jacni.com
Christian Jacquenet
Orange
Rennes 35000
France
Email: christian.jacquenet@orange.com
Yiu L. Lee
Comcast
United States of America
Email: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Qian Wang
China Telecom
China
Phone: +86 10 58502462
Email: 13301168516@189.cnThat's the whole RFC, bestie! 🌈✨ Main character energy, fr fr 💅
📦 where this page comes from
- ietf: rfc8114 2017-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms