One document matched: draft-ietf-mboned-64-multicast-address-format-02.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-02"
ipr="trust200902" updates="4291">
<front>
<title abbrev="64 Multicast Address Format">IPv6 Multicast Address Format
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="23" month="May" year="2012" />
<workgroup>MBONED Working Group</workgroup>
<keyword>IPv4-IPv6 Interconnection, Multicast64, IPv4-Embedded IPv6
Address, IPv4 Address Shortage</keyword>
<abstract>
<t>This document specifies an extension to the IPv6 multicast addressing
architecture to be used in the context of IPv4-IPv6 interconnection. In
particular, this document defines an address format for IPv4-embedded
IPv6 multicast addresses. This address format can be used for IPv4-IPv6
translation or encapsulation schemes.</t>
<t>This document updates RFC4291.</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 specifies an extension to the IPv6 multicast addressing
architecture to be used in the context of IPv4-IPv6 interconnection. In
particular, this document defines an address format for IPv4-embedded
IPv6 multicast addresses. This address format can be used for IPv4-IPv6
translation or encapsulation schemes.</t>
<t>This document updates <xref target="RFC4291"></xref>. A new M-bit is
defined; if set to "1", it indicates an IPv4 multicast address is
embedded in the low-order 32 bits of the IPv6 multicast address. <xref
target="justification"></xref> enumerates the arguments in favor of
defining an address format while <xref target="mbit"></xref> discusses
why identifying an IPv4-embedded IPv6 multicast address is needed.</t>
<t>This specification can be used in conjunction with other extensions
such as building unicast prefix-based multicast IPv6 address <xref
target="RFC3306"></xref> or embedding the rendezvous point <xref
target="RFC3956"></xref>.</t>
<t>This document is a companion document to <xref
target="RFC6052"></xref> which focuses exclusively on IPv4-embedded IPv6
unicast addresses.</t>
<t>Details about design choices are documented in <xref
target="design"></xref>.</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. Two types of IPv6
addresses are defined that carry an IPv4 address in the low-order 32
bits of the address. The format to build such addresses is defined
in <xref target="format_asm"></xref> for Any Source Multicast (ASM)
mode and <xref target="format_ssm"></xref> for Source Specific
Multicast (SSM) mode.</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 ASM mode. It
follows the format described in <xref
target="format_asm"></xref>.</t>
<t>SSM_MPREFIX64: denotes a multicast Prefix64 used in SSM mode. It
follows the format described in <xref
target="format_ssm"></xref>.</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 anchor="format_asm"
title="IPv4-Embedded IPv6 Multicast Address Format: ASM Mode">
<t>To meet the requirements listed in <xref target="m-bit"></xref>, the
IPv6 multicast address format defined in <xref target="RFC4291"></xref>
is modified to enclose an IPv4 multicast address. <xref
target="address_format"></xref> shows the modified address format when
ASM mode is used.</t>
<figure align="center" anchor="address_format"
title="IPv4-Embedded IPv6 Multicast Address Format: ASM Mode">
<preamble></preamble>
<artwork><![CDATA[| 8 | 4 | 4 | 4 | 76 | 32 |
+--------+----+----+----+------------------------------+----------+
|11111111|flgs|scop|64IX| sub-group-id |v4 address|
+--------+----+----+----+-----------------------------------------+
+-+-+-+-+
IPv4-IPv6 Interconnection bits (64IX): |M|resvd|
+-+-+-+-+
"resvd" are reserved bits.
]]></artwork>
<postamble></postamble>
</figure>
<t>The description of the fields is as follows:<?rfc subcompact="yes" ?><list
style="symbols">
<t>"flgs" and "scop" fields are defined in <xref
target="RFC4291"></xref>.</t>
<t>64IX field (IPv4-IPv6 interconnection bits): The first bit is the
M-bit. When "M-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. All the remaining bits are reserved and MUST be set to
0.</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></t>
</section>
<section anchor="format_ssm"
title="IPv4-Embedded IPv6 Multicast Address Format: SSM Mode">
<t>As mentioned in <xref target="m-bit"></xref>, any IPv4-embedded IPv6
address used in SSM mode MUST be part of ff3x::/32 <xref
target="RFC4607"></xref>. <xref target="address_format_ssm"></xref>
describes the format of the IPv6 multicast address to be used to enclose
an IPv4 multicast address.</t>
<t><figure align="center" anchor="address_format_ssm"
title="IPv4-Embedded IPv6 Multicast Address Format: SSM Mode">
<preamble></preamble>
<artwork><![CDATA[| 8 | 4 | 4 | 16 | 4 | 60 | 32 |
+--------+----+----+-----------+----+------------------+----------+
|11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address|
+--------+----+----+-----------+----+------------------+----------+
+-+-+-+-+
IPv4-IPv6 Interconnection bits (64IX): |M|resvd|
+-+-+-+-+
"resvd" are reserved bits.]]></artwork>
<postamble></postamble>
</figure>The description of the fields is as follows:<?rfc subcompact="yes" ?></t>
<t><list style="symbols">
<t>Flags MUST be set to 0011.</t>
<t>"scop" is defined in <xref target="RFC4291"></xref>.</t>
<t>64IX field (IPv4-IPv6 interconnection bits): Same meaning as
<xref target="format_asm"></xref>.</t>
<t>sub-group-id: 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 embedded IPv4 address SHOULD be in the
232/8 range <xref target="RFC4607"></xref>.</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 anchor="mprefix" title="Multicast PREFIX64">
<t><!--add a reference to ietf-softwire-multicast-prefix-option-00-->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 structure of the MPREFIX64 follows the guidelines specified in
<xref target="format_asm"></xref> for the ASM mode and <xref
target="format_ssm"></xref> when SSM mode is used.</t>
<t>The length of MPREFIX64 MUST be /96 (as shown in <xref
target="mprefix64"></xref>).</t>
<t>The format of the MPREFIX64 should follow what is specified in <xref
target="RFC3306"></xref> and <xref target="RFC3956"></xref> if
corresponding mechanisms are used. <?rfc subcompact="no" ?></t>
<t><list style="empty">
<t>The format specified in <xref target="format_asm"></xref> uses
some reserved bits defined in <xref target="RFC3306"></xref> and
<xref target="RFC3956"></xref>: the first of the reserved bits now
has a meaning, while the remaining bits MUST be set to 0.</t>
</list> <?rfc subcompact="yes" ?></t>
<t><figure align="center" anchor="mprefix64" title="MPREFIX64">
<preamble></preamble>
<artwork><![CDATA[ASM Mode:
| 8 | 4 | 4 | 4 | 76 | 32 |
+--------+----+----+----+------------------------------+----------+
|11111111|flgs|scop|64IX| sub-group-id |v4 address|
+--------+----+----+----+------------------------------+----------+
| | |
v v v
+------------------------------------------------------+----------+
| ASM_MPREFIX64 |v4 address|
+------------------------------------------------------+----------+
SSM Mode:
| 8 | 4 | 4 | 16 | 4 | 60 | 32 |
+--------+----+----+-----------+----+------------------+----------+
|11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address|
+--------+----+----+-----------+----+------------------+----------+
| | |
v v v
+------------------------------------------------------+----------+
| SSM_MPREFIX64 |v4 address|
+------------------------------------------------------+----------+
]]></artwork>
<postamble></postamble>
</figure></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 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 belongs to ff3x:0:8000/33 or
ffxx:8000/17, extract the last 32 bits of the IPv6 multicast
address.</t>
</list></t>
</section>
<section title="Examples">
<t><xref target="asm_ex"></xref> provides an example of ASM
IPv4-Embedded IPv6 Address while <xref target="ssm_ex"></xref> provides
an example of SSM IPv4-Embedded IPv6 Address.</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 |
+---------------------+--------------+----------------------------+
| ffxx:8000:abc::/96 | 224.1.2.3 | ffxx:8000:abc::224.1.2.3 |
+---------------------+--------------+----------------------------+]]></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 | 232.1.2.3 | ff3x:0:8000::232.1.2.3 |
+---------------------+--------------+----------------------------+]]></artwork>
</figure></t>
<t></t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>Authors of this document request to reserve:<list style="symbols">
<t>ff3x:0:8000/33 SSM block to embed an IPv4 multicast address in
the last 32 bits.</t>
<t>ffxx:8000/17 ASM block 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 address format to embed an IPv4 multicast
address in an IPv6 multicast address. The same security considerations
as those 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 and C.
Bormann 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.3306'?>
<?rfc include='reference.RFC.4291'?>
<?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.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.I-D.ietf-behave-nat64-learn-analysis'?>
<?rfc include='reference.RFC.4566'?>
</references>
<section anchor="design" title="Design Choices">
<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="mbit"
title="Why Identifying an IPv4-Embedded IPv6 Multicast Address is Required?">
<t>Reserving an M-bit in the IPv6 multicast address (which is
equivalent to reserving a dedicated multicast block 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 the M-bit 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 the M-bit 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>
</list>Reserving an M-bit in the IPv6 multicast address for
IPv4-IPv6 interconnection purposes mitigates the issues discussed in
<xref target="I-D.ietf-behave-nat64-learn-analysis"></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 anchor="m-bit" title="Location of the M-bit">
<t><xref target="af_4291"></xref> is a reminder of the IPv6 multicast
address format as defined in <xref target="RFC4291"></xref>:</t>
<t><figure anchor="af_4291"
title="IPv6 Multicast address format as defined in RFC4291">
<preamble></preamble>
<artwork><![CDATA[ | 8 | 4 | 4 | 112 bits |
+------ -+----+----+---------------------------------------------+
|11111111|flgs|scop| group ID |
+--------+----+----+---------------------------------------------+
+-+-+-+-+
flgs is a set of 4 flags: |0|R|P|T|
+-+-+-+-+
* "T-bit" is defined in [RFC4291];
* "P-bit" is defined in [RFC3306]
* "R-bit" is defined in [RFC3956]
]]></artwork>
<postamble></postamble>
</figure></t>
<t>It was tempting to use the remaining flag to indicate whether an
IPv6 address embeds an IPv4 address or not. This choice has been
abandoned by the authors for various reasons: <?rfc subcompact="yes" ?><list
style="symbols">
<t>ff3x::/32 is defined as SSM. Defining a new flag would require
standards and implementations to also treat ffbx::/32 as SSM.</t>
<t>Prefixes starting with ff7x are defined as embedded-RP, but not
prefixes starting with fffx. Below is provided an excerpt from
<xref target="RFC3956"></xref>: <list style="empty">
<t>" ...the encoding and the protocol mode used when the two
high-order bits in "flgs" are set to 11 ("fff0::/12") is
intentionally unspecified until such time that the
highest-order bit is defined. Without further IETF
specification, implementations SHOULD NOT treat the fff0::/12
range as Embedded-RP."</t>
<t>as such defining a new flag would require implementations
to also treat ff7x::/12 as embedded-RP prefix.</t>
</list></t>
<t>This is the last remaining flag and at this stage we are not
sure whether there is other usage scenarios of the flag.</t>
</list></t>
<t>As a conclusion, the remaining flag is not used to indicate an IPv6
multicast address embeds an IPv4 multicast address. However the
following constraints should be met:<?rfc subcompact="yes" ?></t>
<t><list style="empty">
<t>(1) Belong to 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.</t>
<t>(2) Be compatible with embedded-RP <xref
target="RFC3956"></xref> and unicast-based prefix <xref
target="RFC3306"></xref> for ASM;</t>
<t>(3) Avoid ff3x::4000:0001-ff3x::7fff:ffff which is reserved for
IANA.</t>
</list>Meeting (1) and (2) with the same location of the M-bit is
not feasible without modifying embedded-RP and unicast-based prefix
specifications; this option is avoided.</t>
<t>As a consequence, two multicast blocks are proposed to be used when
embedding IPv4 address: one block for ASM (<xref
target="format_asm"></xref> ) and another one for the SSM (<xref
target="format_ssm"></xref>).</t>
</section>
<section anchor="why_s_bit" title="Encapsulation vs. Translation">
<t>IPv4-IPv6 encapsulator and translator may be embedded in the same
device or even implemented with the same software module. In order to
help the function whether an encapsulated IPv6 multicast packets or
translated IPv6 ones are to be transferred. It was tempting to define
an S-bit for that purpose but this choice has been abandoned in favor
of the recommendation to use distinct MPREFIX64 for each scheme.</t>
<t>As such, there is no need to reserve a bit in the IPv6 multicast
address to separate between the translation and the encapsulation
schemes.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 05:33:04 |