One document matched: draft-ietf-mboned-64-multicast-address-format-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-mboned-64-multicast-address-format-06"
ipr="trust200902" updates="7371">
<front>
<title abbrev="64 Multicast Address Format">IPv6 Multicast Address With
Embedded IPv4 Multicast Address</title>
<author fullname="Mohamed Boucadair" initials="M." role="editor"
surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Jacni Qin" initials="J." surname="Qin">
<organization>Cisco</organization>
<address>
<postal>
<street></street>
<city></city>
<country>China</country>
</postal>
<email>jacni@jacni.com</email>
</address>
</author>
<author fullname="Yiu L. Lee" initials="Y." surname="Lee">
<organization>Comcast</organization>
<address>
<postal>
<street></street>
<city></city>
<country>U.S.A</country>
</postal>
<email>yiu_lee@cable.comcast.com</email>
</address>
</author>
<author fullname="Stig Venaas" initials="S." surname="Venaas">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>Tasman Drive</street>
<city>San Jose</city>
<region>CA</region>
<code>95134</code>
<country>USA</country>
</postal>
<email>stig@cisco.com</email>
</address>
</author>
<author fullname="Xing Li" initials="X." surname="Li">
<organization>CERNET Center/Tsinghua University</organization>
<address>
<postal>
<street>Room 225, Main Building, Tsinghua University</street>
<city>Beijing</city>
<region></region>
<code>100084</code>
<country>P.R. China</country>
</postal>
<phone>+86 10-62785983</phone>
<email>xing@cernet.edu.cn</email>
</address>
</author>
<author fullname="Mingwei Xu" initials="M." surname="Xu">
<organization>Tsinghua University</organization>
<address>
<postal>
<street>Department of Computer Science, Tsinghua University</street>
<city>Beijing</city>
<region></region>
<code>100084</code>
<country>P.R.China</country>
</postal>
<phone>+86-10-6278-5822</phone>
<email>xmw@cernet.edu.cn</email>
</address>
</author>
<date day="24" month="September" year="2014" />
<keyword>IPv4-IPv6 Interconnection, Multicast64, IPv4-Embedded IPv6
Address, IPv4 Address Shortage</keyword>
<abstract>
<t>This document reserves one bit (M-bit) of the unicast prefix-based
multicast IPv6 address for ASM and an IPv6 multicast prefix for SSM mode
to be used in the context of IPv4-IPv6 interconnection.</t>
<t>The document specifies an algorithmic translation of an IPv6
multicast address to a corresponding IPv4 multicast address, and vice
versa. This algorithmic translation can be used in both IPv4-IPv6
translation or encapsulation schemes.</t>
<t>This document updates RFC 7371.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>Various solutions (e.g., <xref
target="I-D.ietf-softwire-mesh-multicast"></xref>, <xref
target="I-D.ietf-softwire-dslite-multicast"></xref>) have been proposed
to allow access to IPv4 multicast content from hosts attached to
IPv6-enabled domains. Even if these solutions have distinct
applicability scopes (translation vs. encapsulation) and target
different use cases, they all make use of specific IPv6 multicast
addresses to embed an IPv4 multicast address. Particularly, the
IPv4-Embedded IPv6 Multicast Address is used as a destination IPv6
address of multicast flows received from an IPv4-enabled domain and
injected by the IPv4-IPv6 Interconnection Function into an IPv6-enabled
domain. It is also used to build an IPv6 multicast state (*, G6) or (S6,
G6) corresponding to their (*, G4) or (S4, G4) IPv4 counter parts by the
IPv4-IPv6 Interconnection Function. <xref
target="I-D.ietf-mboned-v4v6-mcast-ps"></xref> provides more discussion
about issues related to IPv4/IPv6 multicast.</t>
<t>This document reserves one bit of the unicast prefix-based multicast
IPv6 address (<xref target="RFC7371"></xref>) for Any-Source Multicast
(ASM) mode and an IPv6 multicast prefix for Source-Specific Multicast
(SSM) mode to be used in the context of IPv4-IPv6 interconnection. This
document also defines how IPv4-Embedded IPv6 Multicast Addresses are
constructed. Both IPv4-IPv6 translation and encapsulation schemes can
make use of this specification.</t>
<t>This specification can be used in conjunction with other extensions
such as embedding the rendezvous point <xref target="RFC3956"></xref>.
Unicast prefix-based and embedded-RP techniques are important tools to
simplify IPv6 multicast deployments. Indeed, unicast prefix-based IPv6
addressing is used in many current IPv6 multicast deployments, and has
also been defined for IPv4, and is seen as a very useful technique. Also
embedded-RP is used in existing deployments.</t>
<t>This document is a companion document to <xref
target="RFC6052"></xref> which focuses exclusively on IPv4-embedded IPv6
unicast addresses.</t>
</section>
<section title="Terminology">
<t>This document makes use of the following terms:<?rfc subcompact="no" ?><list
style="symbols">
<t>IPv4-Embedded IPv6 Multicast Address: denotes a multicast IPv6
address which includes in 32 bits an IPv4 address.</t>
<t>Multicast Prefix64 (or MPREFIX64 for short) refers to an IPv6
multicast prefix to be used to construct IPv4-Embedded IPv6
Multicast Addresses. This prefix is used to build an IPv4-Embedded
IPv6 Multicast Address as defined in <xref target="algo"></xref>.
<xref target="algo"></xref> specifies also how to extract an IPv4
address from an IPv4-Embedded IPv6 Multicast Address.</t>
<t>ASM_MPREFIX64: denotes a multicast Prefix64 used in Any Source
Multicast (ASM) mode.</t>
<t>SSM_MPREFIX64: denotes a multicast Prefix64 used in Source
Specific Multicast (SSM) mode.</t>
<t>IPv4-IPv6 Interconnection Function: refers to a function which is
enabled in a node interconnecting an IPv4-enabled domain with an
IPv6-enabled one. It can be located in various places of the
multicast network. Particularly, in terms of multicast control
messages, it can be an IGMP/MLD Interworking Function or an
IPv4-IPv6 PIM Interworking Function. An IPv4-IPv6 Interconnection
Function is configured with one or two MPREFIX64s.</t>
</list></t>
</section>
<section title="IPv4-Embedded IPv6 Multicast Prefix & Address">
<t></t>
<section anchor="format_asm" title="ASM Mode">
<t>The format specified in <xref target="address_format_asm"></xref>
uses some bits defined in <xref target="RFC7371"></xref>: M-bit (20th
bit position, where bit 1 is the most significant bit) now has a
meaning.</t>
<t>Details on design considerations are discussed in <xref
target="m-bit"></xref>.</t>
<figure align="center" anchor="address_format_asm"
title="IPv4-Embedded IPv6 Multicast Address Format: ASM Mode">
<preamble></preamble>
<artwork><![CDATA[| 8 | 4 | 4 | 4 | 76 | 32 |
+--------+----+----+----+------------------------------+----------+
|11111111|ff1 |scop|ff2 | sub-group-id |v4 address|
+--------+----+----+----+-----------------------------------------+
+-+-+-+-+
ff2 (flag field 2) is a set of 4 flags: |r|r|r|M|
+-+-+-+-+
"r" bits MUST each be set to 0.
]]></artwork>
<postamble></postamble>
</figure>
<t>The description of the fields is as follows:<?rfc subcompact="yes" ?><list
style="symbols">
<t>ff1 field is defined in <xref target="RFC7371"></xref>.</t>
<t>"scop" field is defined in <xref target="RFC3956"></xref>.</t>
<t>M (20th bit position): When this bit is set to 1, it indicates
that a multicast IPv4 address is embedded in the low-order 32 bits
of the multicast IPv6 address.</t>
<t>sub-group-id: This field is configurable according to local
policies (e.g., enable embedded-RP) of the entity managing the
IPv4-IPv6 Interconnection Function. This field MUST follow the
recommendations specified in <xref target="RFC3306"></xref> if
unicast-based prefix is used or the recommendations specified in
<xref target="RFC3956"></xref> if embedded-RP is used. The default
value is all zeros.</t>
<t>The low-order 32 bits MUST include an IPv4 multicast address
when the M-bit is set to 1. The enclosed IPv4 multicast address
SHOULD NOT be in 232/8 range.</t>
</list><?rfc subcompact="no" ?></t>
</section>
<section anchor="format_ssm" title="SSM Mode">
<t>For SSM mode, and given what is discussed in <xref
target="m-bit"></xref>, the following IPv6 prefix to embed IPv4
multicast addresses is reserved:<list style="symbols">
<t>ff3x:0:8000::/96 ('x' is any valid scope).</t>
</list></t>
</section>
<section anchor="mprefix" title="IPv4-Embedded IPv6 Multicast Address">
<t><!---->For the delivery of the IPv4-IPv6 multicast interconnection
services, a dedicated multicast prefix denoted as MPREFIX64 should be
provisioned (e.g., using NETCONF or <xref
target="I-D.ietf-softwire-multicast-prefix-option"></xref>) to any
function requiring to build an IPv4-Embedded IPv6 Multicast Address
based on an IPv4 multicast address. MPREFIX64 can be of ASM or SSM
type. When both modes are used, two prefixes are required to be
provisioned.</t>
<t>The length of MPREFIX64 MUST be /96. For SSM, MPREFIX64 MUST be
equal to ff3x:0:8000::/96. For the ASM mode, MPREFIX64 MUST have the
M-bit set to 1. Furthermore, the format of the ASM_MPREFIX64 should
follow what is specified in <xref target="RFC3306"></xref> and <xref
target="RFC3956"></xref> if corresponding mechanisms are used. If not,
bits 21-96 can be set to any value.</t>
<t><xref target="address_format"></xref> shows how to build an
IPv4-Embedded IPv6 Multicast Address using a configured MPREFIX64 and
an IPv4 multicast address. The low-order 32 bits MUST include an IPv4
multicast address. The enclosed IPv4 multicast address SHOULD NOT be
in 232/8 range if an ASM_PREFIX64 is configured. The enclosed IPv4
multicast address SHOULD be in 232/8 range if an SSM_PREFIX64 is
configured.</t>
<t>Embedding an IPv4 multicast address in the last 32 bits does not
conflict with the Group IDs assigned by IANA (i.e., 0x00000001 to
0x3FFFFFFF <xref target="RFC3307"></xref>).</t>
<t>When several MPREFIX64 are available, it is RECOMMENDED to use the
MPREFIX64 which preserve the scope of the IPv4 multicast address.</t>
<t><figure align="center" anchor="address_format"
title="IPv4-Embedded IPv6 Multicast Address Format">
<preamble></preamble>
<artwork><![CDATA[| 96 | 32 |
+------------------------------------------------------+----------+
| MPREFIX64 |v4 address|
+------------------------------------------------------+----------+
]]></artwork>
<postamble></postamble>
</figure></t>
</section>
<section anchor="algo" title="Address Translation Algorithm">
<t>IPv4-Embedded IPv6 Multicast Addresses are composed according to
the following algorithm:<list style="symbols">
<t>Concatenate the MPREFIX64 and the 32 bits of the IPv4 address
to obtain a 128-bit address.</t>
</list></t>
<t>The IPv4 multicast addresses are extracted from the IPv4-Embedded
IPv6 Multicast Addresses according to the following algorithm:<list
style="symbols">
<t>If the multicast address has the 20th bit set to 1 or it
matches ff3x:0:8000::/96 or a preconfigured MPREFIX64, extract the
last 32 bits of the IPv6 multicast address.</t>
</list></t>
</section>
<section title="Textual Representation">
<t>The embedded IPv4 address in an IPv6 multicast address is included
in the last 32 bits; therefore dotted decimal notation can be
used.</t>
</section>
<section title="Source IPv4 Address in the IPv6 Realm">
<t>An IPv4 source is represented in the IPv6 realm with its
IPv4-converted IPv6 address <xref target="RFC6052"></xref>.</t>
</section>
</section>
<section title="Examples">
<t><xref target="asm_ex"></xref> provides some examples of ASM
IPv4-Embedded IPv6 Address while <xref target="ssm_ex"></xref> provides
an example of SSM IPv4-Embedded IPv6 Address.</t>
<t>IPv4 multicast addresses used in the examples are derived from the
IPv4 multicast block reserved for documentation in <xref
target="RFC6676"></xref>.</t>
<t><figure align="center" anchor="asm_ex"
title="Example of ASM IPv4-embedded IPv6 address">
<artwork><![CDATA[+----------------------+--------------+-----------------------------+
| MPREFIX64 | IPv4 address | IPv4-Embedded IPv6 Address |
+----------------------+--------------+-----------------------------+
| ff3x:z000:0:abc::/96 | 233.252.0.1 |ff3x:z000:0:abc::233.252.0.1 |
| ff7x:z000:0:abc::/96 | 233.252.0.2 |ff7x:z000:0:abc::233.252.0.2 |
+----------------------+--------------+-----------------------------+
where:
"x" is any valid scope
"z" is any 4 bits where the last bit is set (e.g., 1, 3, 7, ...)]]></artwork>
</figure></t>
<t><figure align="center" anchor="ssm_ex"
title="Example of SSM IPv4-embedded IPv6 address">
<artwork><![CDATA[ +---------------------+--------------+----------------------------+
| MPREFIX64 | IPv4 address | IPv4-Embedded IPv6 Address |
+---------------------+--------------+----------------------------+
| ff3x:0:8000::/96 | 233.252.0.5 | ff3x:0:8000::233.252.0.5 |
+---------------------+--------------+----------------------------+]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requests IANA to reserve:<list style="symbols">
<t>ff3x:0:8000::/96 SSM range to embed an IPv4 multicast address in
the last 32 bits.</t>
</list></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document defines an algorithmic translation of an IPv6 multicast
address into an IPv4 multicast address, and vice versa. The security
considerations discussed in <xref target="RFC6052"></xref> are to be
taken into consideration.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Many thanks to R. Bonica, B. Sarikaya, P. Savola, T. Tsou, C.
Bormann, T. Chown, P. Koch, B. Haberman, and B. Hinden for their
comments and review.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"
?>
<?rfc include='reference.RFC.3956'?>
<?rfc include='reference.RFC.7371'?>
<?rfc include='reference.RFC.3306'?>
<?rfc include='reference.RFC.3307'?>
<?rfc include='reference.RFC.6052'?>
<?rfc include='reference.RFC.4607'?>
</references>
<references title="Informative References">
<?rfc include='reference.I-D.ietf-softwire-multicast-prefix-option'?>
<?rfc include='reference.RFC.6676'?>
<?rfc include='reference.I-D.ietf-mboned-v4v6-mcast-ps'?>
<?rfc include='reference.I-D.ietf-softwire-dslite-multicast'?>
<?rfc include='reference.I-D.ietf-softwire-mesh-multicast'?>
<?rfc include='reference.RFC.7051'?>
<?rfc include='reference.RFC.4566'?>
</references>
<section anchor="design" title="Motivations">
<t></t>
<section anchor="justification"
title="Why an Address Format is Needed for Multicast IPv4-IPv6 Interconnection?">
<t>Arguments why an IPv6 address format is needed to embed multicast
IPv4 address are quite similar to those of <xref
target="RFC6052"></xref>. Concretely, the definition of a multicast
address format embedding a multicast IPv4 address allows:</t>
<t><list style="symbols">
<t>Stateless IPv4-IPv6 header translation of multicast flows;</t>
<t>Stateless IPv4-IPv6 PIM interworking function;</t>
<t>Stateless IGMP-MLD interworking function (e.g., required for an
IPv4 receiver to access to IPv4 multicast content via an IPv6
network);</t>
<t>Stateless (local) synthesis of IPv6 address when IPv4 multicast
address are embedded in application payload (e.g., SDP <xref
target="RFC4566"></xref>);</t>
<t>Except the provisioning of the same MPREFIX64, no coordination
is required between IPv4-IPv6 PIM interworking function, IGMP-MLD
interworking function, IPv4-IPv6 Interconnection Function and any
ALG (Application Level Gateway) in the path;</t>
<t>Minimal operational constraints on the multicast address
management: IPv6 multicast addresses can be constructed using what
has been deployed for IPv4 delivery mode.</t>
</list></t>
</section>
<section anchor="wkp"
title="Why Identifying an IPv4-Embedded IPv6 Multicast Address is Required?">
<t>Reserving a dedicated multicast prefix for IPv4-IPv6
interconnection purposes is a means to guide the address selection
process at the receiver side; in particular it assists the receiver to
select the appropriate IP multicast address while avoiding to involve
an IPv4-IPv6 interconnection function in the path.</t>
<t>Two use cases to illustrate this behavior are provided below:<list
style="numbers">
<t>An ALG is required to help an IPv6 receiver to select the
appropriate IP address when only the IPv4 address is advertised
(e.g., using SDP); otherwise the access to the IPv4 multicast
content can not be offered to the IPv6 receiver. The ALG may be
located downstream the receiver. As such, the ALG does not know in
advance whether the receiver is dual-stack or IPv6-only. The ALG
may be tuned to insert both the original IPv4 address and
corresponding IPv6 multicast address. If a dedicated prefix is not
used, a dual-stack receiver may prefer to use the IPv6 address to
receive the multicast content. This address selection would
require multicast flows to cross an IPv4-IPv6 interconnection
function.</t>
<t>In order to avoid involving an ALG in the path, an IPv4-only
source can advertise both its IPv4 address and IPv4-Embedded IPv6
Multicast Address. If a dedicated prefix is not reserved, a
dual-stack receiver may prefer to use the IPv6 address to receive
the multicast content. This address selection would require
multicast flows to cross an IPv4-IPv6 interconnection
function.</t>
</list>Reserving dedicated IPv6 multicast prefixes for IPv4-IPv6
interconnection purposes mitigates the issues discussed in <xref
target="RFC7051"></xref> in a multicast context.</t>
</section>
<section title="Location of the IPv4 Address">
<t>There is no strong argument to allow for flexible options to encode
the IPv4 address inside the multicast IPv6 address. The option
retained by the authors is to encode the multicast IPv4 address in the
low-order 32 bits of the IPv6 address.</t>
<t>This choice is also motivated by the need to be compliant with
<xref target="RFC3306"></xref> and <xref target="RFC3956"></xref>.</t>
</section>
</section>
<section anchor="m-bit" title="Design Considerations">
<t>The following constraints should be met when reserving dedicated
prefix(es) to be used for IPv4/IPv6 multicast interconnection:</t>
<t><list style="format %d:">
<t>Belong to SSM prefix range (preferably ff3x::/32) and be
compatible with unicast-based prefix <xref target="RFC3306"></xref>
for SSM. Note that <xref target="RFC3306"></xref> suggests to set
"plen" to 0 and "network-prefix" to 0. As such, any prefix in the
33-96 range can be convenient. Given <xref target="RFC4607"></xref>
indicates future specifications may allow a non-zero network prefix
field, a /33 would allow for future extensions but it has the
drawback of reserving a large block. A /96 would be adequate for the
use cases already identified in <xref
target="I-D.ietf-mboned-v4v6-mcast-ps"></xref>. In the event of any
concrete extension, reserving additional prefixes may be
considered.</t>
<t>Be compatible with embedded-RP <xref target="RFC3956"></xref> and
unicast-based prefix <xref target="RFC3306"></xref> for ASM. This
results in associating a meaning with one of the reserved bits in
<xref target="RFC7371"></xref>. Defining the 17-20 bits range to
have a meaning and be used for IPv4/IPv6 transition has the
advantage of allowing for future extensions but it may be seen as a
waste of the multicast address space. Consequently, using one of the
reserved bits (in the range 17-20) from the unicast-based IPv6
multicast address format <xref target="RFC3306"></xref> is
preferred.</t>
</list>Meeting (1) and (2) with the same reserved bit is not feasible
without modifying embedded-RP and unicast-based prefix specifications;
this option is avoided.</t>
<t>As a consequence, this document proposes to reserve a multicast
prefix for SSM and define one bit of the unicast prefix-based multicast
IPv6 address for ASM when embedding IPv4 multicast address in an IPv6
multicast address.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 10:18:44 |