summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8114.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8114.txt')
-rw-r--r--doc/rfc/rfc8114.txt1291
1 files changed, 1291 insertions, 0 deletions
diff --git a/doc/rfc/rfc8114.txt b/doc/rfc/rfc8114.txt
new file mode 100644
index 0000000..4aebf88
--- /dev/null
+++ b/doc/rfc/rfc8114.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) M. Boucadair
+Request for Comments: 8114 Orange
+Category: Standards Track C. Qin
+ISSN: 2070-1721 Cisco
+ C. Jacquenet
+ Orange
+ Y. Lee
+ Comcast
+ Q. Wang
+ China Telecom
+ March 2017
+
+
+ Delivery of IPv4 Multicast Services to IPv4 Clients over
+ an IPv6 Multicast Network
+
+Abstract
+
+ This document specifies a solution for the delivery of IPv4 multicast
+ services to IPv4 clients over an IPv6 multicast network. The
+ solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme
+ and uses an IPv6 multicast distribution tree to deliver IPv4
+ multicast traffic. The solution is particularly useful for the
+ delivery of multicast service offerings to customers serviced by
+ Dual-Stack Lite (DS-Lite).
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ http://www.rfc-editor.org/info/rfc8114.
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 1]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+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) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 2]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+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 . . . . . . . . . . . . . . . . . . . . . . . 23
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 3]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+1. Introduction
+
+ DS-Lite [RFC6333] is an IPv4 address-sharing technique that enables
+ operators to multiplex public IPv4 addresses while provisioning only
+ IPv6 to users. A typical DS-Lite scenario is the delivery of an IPv4
+ service to an IPv4 user over an IPv6 network (denoted as a 4-6-4
+ scenario). [RFC6333] covers unicast services exclusively.
+
+ This document specifies a generic solution for the delivery of IPv4
+ multicast services to IPv4 clients over an IPv6 multicast network.
+ The solution was developed with DS-Lite in mind (see more discussion
+ below). However, the solution is not limited to DS-Lite; it can also
+ be applied in other deployment contexts, such as the ones described
+ in [RFC7596] and [RFC7597].
+
+ If customers have to access IPv4 multicast-based services through a
+ DS-Lite environment, Address Family Transition Router (AFTR) devices
+ will have to process all the Internet Group Management Protocol
+ (IGMP) Report messages [RFC2236] [RFC3376] that have been forwarded
+ by the Customer Premises Equipment (CPE) into the IPv4-in-IPv6
+ tunnels. From that standpoint, AFTR devices are likely to behave as
+ a replication point for downstream multicast traffic, and the
+ multicast packets will be replicated for each tunnel endpoint that
+ IPv4 receivers are connected to.
+
+ This kind of DS-Lite environment raises two major issues:
+
+ 1. The IPv6 network loses the benefits of efficient multicast
+ traffic forwarding because it is unable to deterministically
+ replicate the data as close to the receivers as possible. As a
+ consequence, the downstream bandwidth in the IPv6 network will be
+ vastly consumed by sending multicast data over a unicast
+ infrastructure.
+
+ 2. The AFTR is responsible for replicating multicast traffic and
+ forwarding it into each tunnel endpoint connecting IPv4 receivers
+ that have explicitly asked for the corresponding content. This
+ process may significantly consume the AFTR's resources and
+ overload the AFTR.
+
+ This document specifies an extension to the DS-Lite model to deliver
+ IPv4 multicast services to IPv4 clients over an IPv6 multicast-
+ enabled network.
+
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 4]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+ This document describes a stateless translation mechanism that
+ supports either Source-Specific Multicast (SSM) or Any-Source
+ Multicast (ASM) operation. The recommendation in Section 1 of
+ [RFC4607] is that multicast services use SSM where possible; the
+ operation of the translation mechanism is also simplified when SSM is
+ used, e.g., considerations for placement of the IPv6 Rendezvous Point
+ (RP) are no longer relevant.
+
+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 document makes use of the following terms:
+
+ IPv4-embedded IPv6 address: an IPv6 address that embeds a 32-bit-
+ encoded IPv4 address. An IPv4-embedded IPv6 address can be
+ unicast or multicast.
+
+ mPrefix64: a dedicated multicast IPv6 prefix for constructing
+ IPv4-embedded IPv6 multicast addresses. mPrefix64 can be of two
+ types: ASM_mPrefix64 used in Any-Source Multicast (ASM) mode or
+ SSM_mPrefix64 used in Source-Specific Multicast (SSM) mode
+ [RFC4607]. The size of this prefix is /96.
+
+ Note: "64" is used as an abbreviation for IPv6-IPv4
+ interconnection.
+
+ uPrefix64: a dedicated IPv6 unicast prefix for constructing
+ IPv4-embedded IPv6 unicast addresses [RFC6052]. This prefix may
+ 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. Also, it behaves as the corresponding IPv6
+ multicast source for the 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 the IGMP messages into the corresponding Multicast
+ Listener Discovery (MLD) messages and sends the MLD messages to
+ the IPv6 network. In addition, the mB4 decapsulates IPv4-in-IPv6
+ multicast packets.
+
+
+
+Boucadair, et al. Standards Track [Page 5]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+ PIMv4: refers to Protocol Independent Multicast (PIM) when deployed
+ in an IPv4 infrastructure (i.e., IPv4 transport capabilities are
+ used to exchange PIM messages).
+
+ PIMv6: refers to PIM when 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]). As a reminder, MLD specifies separate behaviors for
+ multicast address listeners (i.e., hosts or routers that listen to
+ multicast packets) and 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 document focuses only on the subscription to IPv4 multicast
+ groups and the delivery of IPv4-formatted content to IPv4 receivers
+ over an IPv6-only network. In particular, only the following case is
+ covered:
+
+ IPv4 receivers access IPv4 multicast content over IPv6-only
+ multicast-enabled networks.
+
+ This document does not cover the source/receiver heuristics, where
+ IPv4 receivers can also behave as IPv4 multicast sources. This
+ document assumes that hosts behind the mB4 are IPv4 multicast
+ receivers only. Also, the document covers the host built-in mB4
+ function.
+
+4. Solution Overview
+
+ In the DS-Lite specification [RFC6333], an IPv4-in-IPv6 tunnel is
+ used to carry bidirectional IPv4 unicast traffic between a B4 and an
+ AFTR. The solution specified in this document provides an IPv4-in-
+ IPv6 encapsulation scheme to deliver unidirectional IPv4 multicast
+ traffic from an mAFTR to an mB4.
+
+ An overview of the solution is provided in this section; it is
+ intended as an introduction to how it works but is not normative.
+ For the normative specifications of the two new functional elements,
+ mB4 and mAFTR (Figure 1), refer to Sections 6 and 7.
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 6]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+ ------------
+ / \
+ | 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
+
+ In order to map the addresses of IPv4 multicast traffic with IPv6
+ multicast addresses, an IPv6 multicast prefix (mPrefix64) and an IPv6
+ unicast prefix (uPrefix64) are provided to the mAFTR and the mB4
+ elements, both of which contribute to the computation and the
+ maintenance of the IPv6 multicast distribution tree that extends the
+ IPv4 multicast distribution tree into the IPv6 multicast network.
+ The IPv4/IPv6 address mapping is stateless.
+
+ The mAFTR and the mB4 use mPrefix64 to convert an IPv4 multicast
+ address (G4) into an IPv4-embedded IPv6 multicast address (G6). The
+ mAFTR and the mB4 use uPrefix64 to convert an IPv4 source address
+ (S4) into an IPv4-embedded IPv6 address (S6). The mAFTR and the mB4
+ must use the same mPrefix64 and uPrefix64; they also run the same
+ algorithm for building IPv4-embedded IPv6 addresses. Refer to
+ Section 5 for more details about the address mapping.
+
+
+
+Boucadair, et al. Standards Track [Page 7]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+4.2. Multicast Distribution Tree Computation
+
+ When an IPv4 receiver connected to the device that embeds the mB4
+ capability wants to subscribe to an IPv4 multicast group, it sends an
+ IGMP Report message towards the mB4. The mB4 creates 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 will create the IPv6 source address
+ (S6) using uPrefix64 and the original IPv4 source address.
+
+ The mB4 uses the G6 (and both S6 and G6 in SSM) to create the
+ corresponding MLD Report message. The mB4 sends the Report message
+ towards the IPv6 network. The PIMv6 DR receives the MLD Report
+ message and sends the PIMv6 Join message to join the IPv6 multicast
+ distribution tree. It can send either PIMv6 Join (*,G6) in ASM or
+ PIMv6 Join (S6,G6) in SSM to the mAFTR.
+
+ The mAFTR acts as the IPv6 DR to which the uPrefix64-derived S6 is
+ connected. The mAFTR will receive the source-specific PIMv6 Join
+ message (S6,G6) from the IPv6 multicast network. If the mAFTR is the
+ Rendezvous Point (RP) of G6, it will receive the any-source PIMv6
+ Join message (*,G6) from the IPv6 multicast network. If the mAFTR is
+ not the RP of G6, it will send the PIM Register message to the RP of
+ G6 located in the IPv6 multicast network. For the sake of
+ simplicity, it is recommended to configure the mAFTR as the RP for
+ the IPv4-embedded IPv6 multicast groups it manages; no registration
+ procedure is required under this configuration.
+
+ When the mAFTR receives the PIMv6 Join message (*,G6), it will
+ extract the IPv4 multicast group address (G4). If the mAFTR is the
+ RP of G4 in the IPv4 multicast network, it will create a (*,G4) entry
+ (if such entry does not already exist) in its own IPv4 multicast
+ routing table. If the mAFTR is not the RP of G4, it will send the
+ corresponding PIMv4 Join message (*,G4) towards the RP of G4 in the
+ IPv4 multicast network.
+
+ When the mAFTR receives the PIMv6 Join message (S6,G6), it will
+ extract the IPv4 multicast group address (G4) and IPv4 source address
+ (S4) and send the corresponding (S4,G4) PIMv4 Join message directly
+ to the IPv4 source.
+
+ A branch of the multicast distribution tree is thus constructed,
+ comprising both an IPv4 part (from the mAFTR upstream) and an IPv6
+ part (from mAFTR downstream towards the mB4).
+
+ The mAFTR advertises the route of uPrefix64 with an IPv6 Interior
+ Gateway Protocol (IGP), so as to represent the IPv4-embedded IPv6
+ source in the IPv6 multicast network and to allow IPv6 routers to run
+
+
+
+Boucadair, et al. Standards Track [Page 8]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+ the Reverse Path Forwarding (RPF) check procedure on incoming
+ multicast traffic. Injecting internal /96 routes is not problematic
+ given the recommendation in [RFC7608] that requires that forwarding
+ processes must be designed to process prefixes of any length up to
+ /128.
+
+4.3. Multicast Data Forwarding
+
+ When the mAFTR receives an IPv4 multicast packet, it will encapsulate
+ the packet into an IPv6 multicast packet using the IPv4-embedded IPv6
+ multicast address as the destination address and an IPv4-embedded
+ IPv6 unicast address as the source address. The encapsulated IPv6
+ multicast packet will be forwarded down the IPv6 multicast
+ distribution tree, and the mB4 will eventually receive the packet.
+
+ The IPv6 multicast network treats the IPv4-in-IPv6 encapsulated
+ multicast packets as native IPv6 multicast packets. The IPv6
+ multicast routers use the outer IPv6 header to make their forwarding
+ decisions.
+
+ When the mB4 receives the IPv6 multicast packet (to G6) derived by
+ mPrefix64, it decapsulates it and forwards the original IPv4
+ multicast packet towards the receivers subscribing to G4.
+
+ Note: At this point, only IPv4-in-IPv6 encapsulation is defined;
+ however, 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) is provisioned to the
+ mAFTR and the mB4. The mAFTR and the mB4 use the mPrefix64 to form
+ an IPv6 multicast group address from an IPv4 multicast group address.
+ The mPrefix64 can be of two types: 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 (e.g., 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 of the multicast distribution tree. 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. The mAFTR and the mB4 use the uPrefix64 to form an IPv6 source
+ address from an IPv4 source address as specified in [RFC6052]. The
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 9]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+ uPrefix-formed IPv6 source address will represent 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 in the mB4 using a
+ variety of methods, including an out-of-band mechanism, manual
+ configuration, or a dedicated provisioning protocol (e.g., using
+ 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 are composed according to the
+ following algorithm:
+
+ o 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 are extracted from the IPv4-embedded
+ IPv6 multicast addresses according to the following algorithm:
+
+ o 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 is included in
+ the last 32 bits; therefore, 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 |
+ +---------------------+--------------+----------------------------+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 10]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+ 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 |
+ +---------------------+--------------+----------------------------+
+
+ IPv4 and IPv6 addresses used in this example are derived from the
+ IPv4 and IPv6 blocks reserved for documentation, as per [RFC6676].
+ The unicast IPv4 address of the above example is derived 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 MUST follow the address mapping specified in
+ Section 5.
+
+ The mB4 performs the host portion of the MLD protocol on the upstream
+ interface. The composition of IPv6 membership in this context is
+ constructed through address-synthesizing operations and MUST
+ synchronize with the membership database maintained in the IGMP
+ domain. MLD messages are sent natively to the direct-connected IPv6
+ multicast routers (they will be 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 (e.g., WLAN and Wired Ethernet)
+ facing IPv4 multicast receivers.
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 11]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+6.2. Multicast Data Forwarding
+
+ When the mB4 receives an IPv6 multicast packet, it MUST check the
+ group address and the source address. If the IPv6 multicast group
+ prefix is mPrefix64 and the IPv6 source prefix is uPrefix64, the mB4
+ MUST decapsulate the IPv6 header [RFC2473]; the decapsulated IPv4
+ multicast packet will be forwarded through each relevant interface
+ following standard IPv4 multicast forwarding procedures. Otherwise,
+ the mB4 MUST silently drop the packet.
+
+ As an illustration, if a packet is received from source
+ 2001:db8::192.0.2.33 and needs to be forwarded to group
+ ff3x:20:2001:db8::233.252.0.1, the mB4 decapsulates it into an IPv4
+ multicast packet using 192.0.2.33 as the IPv4 source address and
+ using 233.252.0.1 as the IPv4 destination multicast group. This
+ example assumes that the mB4 is provisioned with uPrefix64
+ (2001:db8::/96) and mPrefix64 (ff3x:20:2001:db8::/96).
+
+6.3. Fragmentation
+
+ Encapsulating IPv4 multicast packets into IPv6 multicast packets that
+ will be forwarded by the mAFTR towards the mB4 along the IPv6
+ multicast distribution tree reduces the effective MTU size by the
+ size of an IPv6 header. In this specification, the data flow is
+ unidirectional from the mAFTR to the mB4. The mAFTR MUST fragment
+ the oversized IPv6 packet after the encapsulation into two IPv6
+ packets. The mB4 MUST reassemble the IPv6 packets, decapsulate the
+ IPv6 header, and forward the IPv4 packet to the hosts that have
+ subscribed to the corresponding multicast group. Further
+ considerations about fragmentation issues are documented in Sections
+ 5.3 and 6.3 of [RFC6333].
+
+6.4. Host Built-In mB4 Function
+
+ If the mB4 function is implemented in the host that is directly
+ connected to an IPv6-only network, the host MUST implement the
+ behaviors specified in Sections 6.1, 6.2, and 6.3. The host MAY
+ optimize the implementation to provide an Application Programming
+ Interface (API) or kernel module to skip the IGMP-MLD Interworking
+ function. Optimization considerations are out of scope of this
+ specification.
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 12]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+6.5. Preserve the Scope
+
+ When several mPrefix64s are available, if each enclosed IPv4-embedded
+ IPv6 multicast prefix has a distinct scope, the mB4 MUST select the
+ appropriate IPv4-embedded IPv6 multicast prefix whose scope matches
+ the IPv4 multicast address used to synthesize an IPv4-embedded IPv6
+ multicast address (specific mappings are listed in Section 8 of
+ [RFC2365]). Mapping is achieved such that the scope of the selected
+ IPv6 multicast prefix does not exceed the original IPv4 multicast
+ scope. If the mB4 is instructed to preserve the scope but no IPv6
+ multicast prefix that matches the IPv4 multicast scope is found, IPv6
+ multicast address mapping SHOULD fail.
+
+ The mB4 MAY be configured to not preserve the scope when enforcing
+ the address translation algorithm.
+
+ Consider that an mB4 is configured with two mPrefix64s,
+ ff0e::db8:0:0/96 (global scope) and ff08::db8:0:0/96 (organization
+ scope). If the mB4 receives an IGMP Report message from an IPv4
+ receiver to subscribe to 233.252.0.1, it checks which mPrefix64 to
+ use in order to preserve the scope of the requested IPv4 multicast
+ group. In this example, given that 233.252.0.1 is intended for
+ global use, the mB4 creates the IPv6 multicast group (G6) address
+ using ff0e::db8:0:0/96 and the original IPv4 multicast group address
+ (233.252.0.1): ff0e::db8:233.252.0.1.
+
+7. Multicast AFTR (mAFTR)
+
+7.1. Routing Considerations
+
+ The mAFTR is responsible for interconnecting the IPv4 multicast
+ distribution tree with the corresponding IPv6 multicast distribution
+ tree. The mAFTR MUST use the uPrefix64 to build the IPv6 source
+ addresses of the multicast group address derived from mPrefix64. In
+ other words, the mAFTR MUST be the multicast source whose address is
+ derived from uPrefix64.
+
+ The mAFTR MUST advertise the route towards uPrefix64 with the IPv6
+ IGP. This is needed by the IPv6 multicast routers so that they
+ acquire the routing information to discover the source.
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 13]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+7.2. Processing PIM Messages
+
+ The mAFTR MUST interwork PIM Join/Prune messages for (*,G6) and
+ (S6,G6) on their corresponding (*,G4) and (S4,G4). The following
+ text specifies the expected behavior of the mAFTR for PIM Join
+ messages.
+
+ +---------+
+ ---------| mAFTR |---------
+ PIMv6 |uPrefix64| PIMv4
+ |mPrefix64|
+ +---------+
+
+ Figure 3: PIMv6-PIMv4 Interworking Function
+
+ The mAFTR contains two separate Tree Information Bases (TIBs): the
+ IPv4 Tree Information Base (TIB4) and the IPv6 Tree Information Base
+ (TIB6), which are bridged by one IPv4-in-IPv6 virtual interface. It
+ should be noted that TIB implementations may vary (e.g., some may
+ rely upon a single integrated TIB without any virtual interface), but
+ they should follow this specification for the sake of global and
+ functional consistency.
+
+ When an mAFTR receives a PIMv6 Join message (*,G6) with an IPv6
+ multicast group address (G6) that is derived from the mPrefix64, it
+ MUST check its IPv6 Tree Information Base (TIB6). If there is an
+ entry for this G6 address, it MUST check whether the interface
+ through which the PIMv6 Join message has been received is in the
+ outgoing interface (oif) list. If not, the mAFTR MUST add the
+ interface to the oif list. If there is no entry in the TIB6, the
+ mAFTR MUST create a new entry (*,G6) for the multicast group.
+ Whether or not the IPv4-in-IPv6 virtual interface is set as the
+ incoming interface of the newly created entry is up to the
+ implementation, but it should comply with the mAFTR's multicast data
+ forwarding behavior (see Section 7.4).
+
+ The mAFTR MUST extract the IPv4 multicast group address (G4) from the
+ IPv4-embedded IPv6 multicast address (G6) contained in the PIMv6 Join
+ message. The mAFTR MUST check its IPv4 Tree Information Base (TIB4).
+ If there is an entry for G4, it MUST check whether the IPv4-in-IPv6
+ virtual interface is in the outgoing interface list. If not, the
+ mAFTR MUST add the interface to the oif list. If there is no entry
+ for G4, the mAFTR MUST create a new (*,G4) entry in its TIB4 and
+ initiate the procedure for building the shared tree in the IPv4
+ multicast network without any additional requirement.
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 14]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+ If the mAFTR receives a source-specific Join message, the (S6,G6) is
+ processed rather than (*,G6). The procedures of processing (S6,G6)
+ and (*,G6) are almost the same. Differences have been detailed in
+ [RFC7761].
+
+7.3. Switching from Shared Tree to Shortest Path Tree
+
+ When the mAFTR receives the first IPv4 multicast packet, it may
+ extract the source address (S4) from the packet and send an Explicit
+ PIMv4 (S4,G4) Join message directly to S4. The mAFTR 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 is no new
+ requirement. IPv6 multicast routers may send an Explicit PIMv6 Join
+ to the mAFTR once the first (S6,G6) multicast packet arrives from
+ upstream multicast routers.
+
+7.4. Multicast Data Forwarding
+
+ When the mAFTR receives an IPv4 multicast packet, it checks its TIB4
+ to find a matching entry and then forwards the packet to the
+ interface(s) listed in the outgoing interface list. If the IPv4-in-
+ IPv6 virtual interface also belongs to this list, the packet is
+ encapsulated with the mPrefix64-derived and uPrefix64-derived
+ IPv4-embedded IPv6 addresses to form an IPv6 multicast packet
+ [RFC2473]. Then another lookup is made by the mAFTR to find a
+ matching entry in the TIB6. Whether or not the RPF check for the
+ second lookup is performed is up to the implementation and is out of
+ the scope of this document. The IPv6 multicast packet is then
+ forwarded along the IPv6 multicast distribution tree, based upon the
+ outgoing interface list of the matching entry in the TIB6.
+
+ As an illustration, if a packet is received from source 192.0.2.33
+ and needs to be forwarded to group 233.252.0.1, the mAFTR
+ encapsulates it into an IPv6 multicast packet using
+ ff3x:20:2001:db8::233.252.0.1 as the IPv6 destination multicast group
+ and using 2001:db8::192.0.2.33 as the IPv6 source address.
+
+7.5. Scope
+
+ The Scope field of IPv4-in-IPv6 multicast addresses should be valued
+ accordingly (e.g., to "E" for global scope) in the deployment
+ environment. This specification does not discuss the scope value
+ that should be used.
+
+ The considerations in Section 6.5 are to be followed by the mAFTR.
+
+
+
+
+Boucadair, et al. Standards Track [Page 15]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+8. Deployment Considerations
+
+8.1. Other Operational Modes
+
+8.1.1. The IPv6 DR is Co-located with the mAFTR
+
+ The mAFTR can embed the MLD Querier function (as well as the PIMv6
+ DR) for optimization purposes. When the mB4 sends an MLD Report
+ message to this mAFTR, the mAFTR should process the MLD Report
+ message that contains the IPv4-embedded IPv6 multicast group address
+ and then send the corresponding PIMv4 Join message (Figure 4).
+
+ +---------+
+ ---------| mAFTR |---------
+ MLD |uPrefix64| PIMv4
+ |mPrefix64|
+ +---------+
+
+ Figure 4: MLD-PIMv4 Interworking Function
+
+ Discussions about the location of the mAFTR capability and related
+ ASM or SSM multicast design considerations are out of the scope of
+ this document.
+
+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 may simply use the uPrefix64 and mPrefix64 prefixes
+ to build the IPv4-embedded IPv6 multicast packets, and the sending of
+ PIMv4 Join messages becomes unnecessary.
+
+8.2. Load Balancing
+
+ For robustness and load distribution purposes, several nodes in the
+ network can embed the mAFTR function. In such case, the same IPv6
+ prefixes (i.e., mPrefix64 and uPrefix64) and algorithm to build
+ IPv4-embedded IPv6 addresses must be configured on 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 the configured addresses
+ should be handled by the mAFTR. Otherwise, packets are silently
+ dropped.
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 16]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+8.4. Static vs. Dynamic PIM Triggering
+
+ To optimize the usage of network resources in current deployments,
+ all multicast streams are conveyed in the core network while only the
+ most popular ones are forwarded in the aggregation/access networks
+ (static mode). Less popular streams are forwarded in the access
+ network upon request (dynamic mode). Depending on the location of
+ the mAFTR in the network, two modes can be envisaged: static and
+ dynamic.
+
+ Static Mode: The mAFTR is configured to instantiate permanent
+ (S6,G6) and (*,G6) entries in its TIB6 using a pre-configured
+ (S4,G4) list.
+
+ Dynamic Mode: The instantiation or withdrawal of (S6,G6) or (*,G6)
+ entries is triggered by the receipt of PIMv6 messages.
+
+9. Security Considerations
+
+ Besides multicast scoping considerations (see Sections 6.5 and 7.5),
+ this document does not introduce any new security concerns in
+ addition to those discussed in Section 5 of [RFC6052], Section 10 of
+ [RFC3810], and Section 6 of [RFC7761].
+
+ Unlike solutions that map IPv4 multicast flows to IPv6 unicast flows,
+ this document does not exacerbate Denial-of-Service (DoS) attacks.
+
+ An mB4 SHOULD be provided with appropriate configuration information
+ to preserve the scope of a multicast message when mapping an IPv4
+ multicast address into an IPv4-embedded IPv6 multicast address and
+ vice versa.
+
+9.1. Firewall Configuration
+
+ The CPE that embeds the mB4 function SHOULD be configured to accept
+ incoming MLD messages and traffic forwarded to multicast groups
+ subscribed to by receivers located in the customer premises.
+
+10. IANA Considerations
+
+ This document does not require any IANA actions.
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 17]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+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>.
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 18]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+ [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>.
+
+
+
+
+Boucadair, et al. Standards Track [Page 19]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+ [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>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 20]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+Appendix A. Use Case: IPTV
+
+ IPTV generally includes two categories of service offerings:
+
+ o Video on Demand (VoD) that streams unicast video content to
+ receivers.
+
+ o Multicast live TV broadcast services.
+
+ Two types of provider are involved in the delivery of this service:
+
+ o Content Providers, who usually own the content that is multicast
+ to receivers. Content providers may contractually define an
+ agreement with network providers to deliver content to receivers.
+
+ o Network Providers, who provide network connectivity services
+ (e.g., network providers are responsible for carrying multicast
+ flows from head-ends to receivers).
+
+ Note that some contract agreements prevent a network provider from
+ altering the content as sent by the content provider for various
+ reasons. Depending on these contract agreements, multicast streams
+ should be delivered unaltered to the requesting users.
+
+ Most current IPTV content is likely to remain IPv4-formatted and out
+ of the control of network providers. Additionally, there are
+ numerous legacy receivers (e.g., IPv4-only Set-Top Boxes (STBs)) that
+ can't be upgraded or easily replaced to support IPv6. As a
+ consequence, IPv4 service continuity must be guaranteed during the
+ transition period, including the delivery of multicast services such
+ as Live TV Broadcasting to users.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 21]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+Appendix B. Older Versions of Group Membership Management Protocols
+
+ Given the multiple versions of group membership management protocols,
+ mismatch issues may arise at the mB4 (refer to Section 6.1).
+
+ If IGMPv2 operates on the IPv4 receivers while MLDv2 operates on the
+ MLD Querier, or if IGMPv3 operates on the IPv4 receivers while MLDv1
+ operates on the MLD Querier, a version mismatch issue will be
+ encountered. To solve this problem, the mB4 should perform the
+ router portion of IGMP, which is similar to the corresponding MLD
+ version (IGMPv2 for MLDv1 or IGMPv3 for MLDv2) operating 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 on which the different version of IGMP is
+ operating.
+
+ Note that the support of IPv4 SSM requires MLDv2 to be enabled in the
+ IPv6 network.
+
+Acknowledgements
+
+ The authors would like to thank Dan Wing for his guidance in the
+ early discussions that initiated 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 22]
+
+RFC 8114 IPv4 over IPv6 Multicast March 2017
+
+
+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.cn
+
+
+
+
+
+
+
+
+
+
+
+Boucadair, et al. Standards Track [Page 23]
+