draft-ietf-mboned-64-multicast-address-format-02.txt   draft-ietf-mboned-64-multicast-address-format-03.txt 
MBONED Working Group M. Boucadair, Ed. MBONED Working Group M. Boucadair, Ed.
Internet-Draft France Telecom Internet-Draft France Telecom
Updates: 4291 (if approved) J. Qin Intended status: Standards Track J. Qin
Intended status: Standards Track Cisco Expires: February 11, 2013 Cisco
Expires: November 24, 2012 Y. Lee Y. Lee
Comcast Comcast
S. Venaas S. Venaas
Cisco Systems Cisco Systems
X. Li X. Li
CERNET Center/Tsinghua CERNET Center/Tsinghua
University University
M. Xu M. Xu
Tsinghua University Tsinghua University
May 23, 2012 August 10, 2012
IPv6 Multicast Address Format With Embedded IPv4 Multicast Address IPv6 Multicast Address With Embedded IPv4 Multicast Address
draft-ietf-mboned-64-multicast-address-format-02 draft-ietf-mboned-64-multicast-address-format-03
Abstract Abstract
This document specifies an extension to the IPv6 multicast addressing This document reserves two IPv6 multicast prefixes to be used in the
architecture to be used in the context of IPv4-IPv6 interconnection. context of IPv4-IPv6 interconnection. The document specifies an
In particular, this document defines an address format for IPv4- algorithmic translation of an IPv6 multicast address to a
embedded IPv6 multicast addresses. This address format can be used corresponding IPv4 multicast address, and vice versa. This
for IPv4-IPv6 translation or encapsulation schemes. algorithmic translation can be used in both IPv4-IPv6 translation or
encapsulation schemes.
This document updates RFC4291.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 2, line 5 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 11, 2013.
This Internet-Draft will expire on November 24, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPv4-Embedded IPv6 Multicast Address Format: ASM Mode . . . . 5 3. IPv4-Embedded IPv6 Multicast Prefix & Address . . . . . . . . 5
4. IPv4-Embedded IPv6 Multicast Address Format: SSM Mode . . . . 6 3.1. Reserving Dedicated Prefixes . . . . . . . . . . . . . . . 5
5. Textual Representation . . . . . . . . . . . . . . . . . . . . 7 3.2. IPv4-Embedded IPv6 Multicast Address . . . . . . . . . . . 6
6. Multicast PREFIX64 . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Address Translation Algorithm . . . . . . . . . . . . . . 7
7. Source IPv4 Address in the IPv6 Realm . . . . . . . . . . . . 8 3.4. Textual Representation . . . . . . . . . . . . . . . . . . 7
8. Address Translation Algorithm . . . . . . . . . . . . . . . . 8 3.5. Source IPv4 Address in the IPv6 Realm . . . . . . . . . . 7
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
13.1. Normative References . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
13.2. Informative References . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Design Choices . . . . . . . . . . . . . . . . . . . 11 Appendix A. Motivations . . . . . . . . . . . . . . . . . . . . . 10
A.1. Why an Address Format is Needed for Multicast A.1. Why an Address Format is Needed for Multicast
IPv4-IPv6 Interconnection? . . . . . . . . . . . . . . . 11 IPv4-IPv6 Interconnection? . . . . . . . . . . . . . . . . 10
A.2. Why Identifying an IPv4-Embedded IPv6 Multicast A.2. Why Identifying an IPv4-Embedded IPv6 Multicast
Address is Required? . . . . . . . . . . . . . . . . . . 11 Address is Required? . . . . . . . . . . . . . . . . . . . 10
A.3. Location of the IPv4 Address . . . . . . . . . . . . . . 12 A.3. Location of the IPv4 Address . . . . . . . . . . . . . . . 11
A.4. Location of the M-bit . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
A.5. Encapsulation vs. Translation . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Various solutions (e.g., [I-D.ietf-softwire-mesh-multicast], Various solutions (e.g., [I-D.ietf-softwire-mesh-multicast],
[I-D.ietf-softwire-dslite-multicast]) have been proposed to allow [I-D.ietf-softwire-dslite-multicast]) have been proposed to allow
access to IPv4 multicast content from hosts attached to IPv6-enabled access to IPv4 multicast content from hosts attached to IPv6-enabled
domains. Even if these solutions have distinct applicability scopes domains. Even if these solutions have distinct applicability scopes
(translation vs. encapsulation) and target different use cases, they (translation vs. encapsulation) and target different use cases, they
all make use of specific IPv6 multicast addresses to embed an IPv4 all make use of specific IPv6 multicast addresses to embed an IPv4
multicast address. Particularly, the IPv4-embedded IPv6 multicast multicast address. Particularly, the IPv4-embedded IPv6 multicast
address is used as a destination IPv6 address of multicast flows address is used as a destination IPv6 address of multicast flows
received from an IPv4-enabled domain and injected by the IPv4-IPv6 received from an IPv4-enabled domain and injected by the IPv4-IPv6
Interconnection Function into an IPv6-enabled domain. It is also Interconnection Function into an IPv6-enabled domain. It is also
used to build an IPv6 multicast state (*, G6) or (S6, G6) used to build an IPv6 multicast state (*, G6) or (S6, G6)
corresponding to their (*, G4) or (S4, G4) IPv4 counter parts by the corresponding to their (*, G4) or (S4, G4) IPv4 counter parts by the
IPv4-IPv6 Interconnection Function. [I-D.ietf-mboned-v4v6-mcast-ps] IPv4-IPv6 Interconnection Function. [I-D.ietf-mboned-v4v6-mcast-ps]
provides more discussion about issues related to IPv4/IPv6 multicast. provides more discussion about issues related to IPv4/IPv6 multicast.
This document specifies an extension to the IPv6 multicast addressing This document reserves two prefixes to be used to synthesize IPv4-
architecture to be used in the context of IPv4-IPv6 interconnection. embedded IPv6 multicast address. This document also defines how
In particular, this document defines an address format for IPv4- IPv4-embedded IPv6 multicast addresses are constructed. Both IPv4-
embedded IPv6 multicast addresses. This address format can be used IPv6 translation or encapsulation schemes can make use of these
for IPv4-IPv6 translation or encapsulation schemes. prefixes.
This document updates [RFC4291]. A new M-bit is defined; if set to Appendix A.1 enumerates the arguments in favor of reserving dedicated
"1", it indicates an IPv4 multicast address is embedded in the low- prefixes Appendix A.2 discusses why identifying an IPv4-embedded IPv6
order 32 bits of the IPv6 multicast address. Appendix A.1 enumerates
the arguments in favor of defining an address format while
Appendix A.2 discusses why identifying an IPv4-embedded IPv6
multicast address is needed. multicast address is needed.
This specification can be used in conjunction with other extensions This specification can be used in conjunction with other extensions
such as building unicast prefix-based multicast IPv6 address such as building unicast prefix-based multicast IPv6 address
[RFC3306] or embedding the rendezvous point [RFC3956]. [RFC3306] or embedding the rendezvous point [RFC3956]. These
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.
This document is a companion document to [RFC6052] which focuses This document is a companion document to [RFC6052] which focuses
exclusively on IPv4-embedded IPv6 unicast addresses. exclusively on IPv4-embedded IPv6 unicast addresses.
Details about design choices are documented in Appendix A.
2. Terminology 2. Terminology
This document makes use of the following terms: This document makes use of the following terms:
o IPv4-embedded IPv6 multicast address: denotes a multicast IPv6 o IPv4-embedded IPv6 multicast address: denotes a multicast IPv6
address which includes in 32 bits an IPv4 address. Two types of address which includes in 32 bits an IPv4 address.
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 Section 3 for Any Source Multicast (ASM) mode and
Section 4 for Source Specific Multicast (SSM) mode.
o Multicast Prefix64 (or MPREFIX64 for short) refers to an IPv6 o Multicast Prefix64 (or MPREFIX64 for short) refers to an IPv6
multicast prefix to be used to construct IPv4-embedded IPv6 multicast prefix to be used to construct IPv4-embedded IPv6
multicast addresses. This prefix is used to build an IPv4- multicast addresses. This prefix is used to build an IPv4-
embedded IPv6 multicast address as defined in Section 8. embedded IPv6 multicast address as defined in Section 3.3.
Section 8 specifies also how to extract an IPv4 address from an Section 3.3 specifies also how to extract an IPv4 address from an
IPv4-embedded IPv6 multicast address. IPv4-embedded IPv6 multicast address.
o ASM_MPREFIX64: denotes a multicast Prefix64 used in ASM mode. It o ASM_MPREFIX64: denotes a multicast Prefix64 used in Any Source
follows the format described in Section 3. Multicast (ASM) mode.
o SSM_MPREFIX64: denotes a multicast Prefix64 used in SSM mode. It o SSM_MPREFIX64: denotes a multicast Prefix64 used in Source
follows the format described in Section 4. Specific Multicast (SSM) mode.
o IPv4-IPv6 Interconnection Function: refers to a function which is o IPv4-IPv6 Interconnection Function: refers to a function which is
enabled in a node interconnecting an IPv4-enabled domain with an enabled in a node interconnecting an IPv4-enabled domain with an
IPv6-enabled one. It can be located in various places of the IPv6-enabled one. It can be located in various places of the
multicast network. Particularly, in terms of multicast control multicast network. Particularly, in terms of multicast control
messages, it can be an IGMP/MLD Interworking Function or an IPv4- messages, it can be an IGMP/MLD Interworking Function or an IPv4-
IPv6 PIM Interworking Function. An IPv4-IPv6 Interconnection IPv6 PIM Interworking Function. An IPv4-IPv6 Interconnection
Function is configured with one or two MPREFIX64s. Function is configured with one or two MPREFIX64s.
3. IPv4-Embedded IPv6 Multicast Address Format: ASM Mode 3. IPv4-Embedded IPv6 Multicast Prefix & Address
To meet the requirements listed in Appendix A.4, the IPv6 multicast
address format defined in [RFC4291] is modified to enclose an IPv4
multicast address. Figure 1 shows the modified address format when
ASM mode is used.
| 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.
Figure 1: IPv4-Embedded IPv6 Multicast Address Format: ASM Mode
The description of the fields is as follows:
o "flgs" and "scop" fields are defined in [RFC4291].
o 64IX field (IPv4-IPv6 interconnection bits): The first bit is the 3.1. Reserving Dedicated Prefixes
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.
o 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 [RFC3306] if unicast-based prefix is
used or the recommendations specified in [RFC3956] if embedded-RP
is used. The default value is all zeros.
o 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.
4. IPv4-Embedded IPv6 Multicast Address Format: SSM Mode The following constraints should be met when reserving dedicated
prefix(es) to be used for IPv4/IPv6 multicast interconnection:
As mentioned in Appendix A.4, any IPv4-embedded IPv6 address used in 1: Belong to ff3x::/32 and be compatible with unicast-based prefix
SSM mode MUST be part of ff3x::/32 [RFC4607]. Figure 2 describes the [RFC3306] for SSM. Note that [RFC3306] suggests to set "plen" to
format of the IPv6 multicast address to be used to enclose an IPv4 0 and "network-prefix" to 0. As such, any prefix in the 33-96
multicast address. range can be convenient. Given [RFC4607] 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 [I-D.ietf-mboned-v4v6-mcast-ps]. In
the event of any concrete extension, reserving additional
prefixes may be considered.
| 8 | 4 | 4 | 16 | 4 | 60 | 32 | 2: Be compatible with embedded-RP [RFC3956] and unicast-based prefix
+--------+----+----+-----------+----+------------------+----------+ [RFC3306] for ASM. This results in a prefix length to be in the
|11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address| 17-20 range. A /17 has the advantage of allowing for future
+--------+----+----+-----------+----+------------------+----------+ extensions but it may be seen as a waste of the multicast address
+-+-+-+-+ space. Consequently, a /20 is preferred.
IPv4-IPv6 Interconnection bits (64IX): |M|resvd|
+-+-+-+-+
"resvd" are reserved bits.
Figure 2: IPv4-Embedded IPv6 Multicast Address Format: SSM Mode 3: Avoid ff3x::4000:0001-ff3x::7fff:ffff which is reserved for IANA.
The description of the fields is as follows: Meeting (1) and (2) with the same prefix is not feasible without
modifying embedded-RP and unicast-based prefix specifications; this
option is avoided.
o Flags MUST be set to 0011. As a consequence, two multicast prefixes are proposed to be used when
o "scop" is defined in [RFC4291]. embedding IPv4 address: one prefix for ASM and another one for the
o 64IX field (IPv4-IPv6 interconnection bits): Same meaning as SSM. This document reserves the following multicast prefixes to be
Section 3. used in the context of IPv4/IPv6 multicast interconnection:
o sub-group-id: The default value is all zeros.
o 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 [RFC4607].
5. Textual Representation o ff3x:0:8000::/96 SSM range to embed an IPv4 multicast address in
the last 32 bits.
The embedded IPv4 address in an IPv6 multicast address is included in o ffxx:8000::/20 ASM range to embed an IPv4 multicast address in the
the last 32 bits; therefore dotted decimal notation can be used. last 32 bits.
6. Multicast PREFIX64 3.2. IPv4-Embedded IPv6 Multicast Address
For the delivery of the IPv4-IPv6 multicast interconnection services, For the delivery of the IPv4-IPv6 multicast interconnection services,
a dedicated multicast prefix denoted as MPREFIX64 should be a dedicated multicast prefix denoted as MPREFIX64 should be
provisioned (e.g., using NETCONF or provisioned (e.g., using NETCONF or
[I-D.ietf-softwire-multicast-prefix-option]) to any function [I-D.ietf-softwire-multicast-prefix-option]) to any function
requiring to build an IPv4-embedded IPv6 multicast address based on requiring to build an IPv4-embedded IPv6 multicast address based on
an IPv4 multicast address. MPREFIX64 can be of ASM or SSM type. an IPv4 multicast address. MPREFIX64 can be of ASM or SSM type.
When both modes are used, two prefixes are required to be When both modes are used, two prefixes are required to be
provisioned. provisioned.
The structure of the MPREFIX64 follows the guidelines specified in The length of MPREFIX64 MUST be /96. MPREFIX64 should belong to
Section 3 for the ASM mode and Section 4 when SSM mode is used. ffxx:8000::/20 for ASM mode and ff3x:0:8000::/96 for the SSM mode.
The length of MPREFIX64 MUST be /96 (as shown in Figure 3).
The format of the MPREFIX64 should follow what is specified in
[RFC3306] and [RFC3956] if corresponding mechanisms are used.
The format specified in Section 3 uses some reserved bits defined For the ASM mode, the format of the MPREFIX64 should follow what is
in [RFC3306] and [RFC3956]: the first of the reserved bits now has specified in [RFC3306] and [RFC3956] if corresponding mechanisms are
a meaning, while the remaining bits MUST be set to 0. used. If not, bits 21-96 can be set to any value.
ASM Mode: Figure 1 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.
| 8 | 4 | 4 | 4 | 76 | 32 | Embedding an IPv4 multicast address in the last 32 bits does not
+--------+----+----+----+------------------------------+----------+ conflict with the Group IDs assigned by IANA (i.e., 0x00000001 to
|11111111|flgs|scop|64IX| sub-group-id |v4 address| 0x3FFFFFFF [RFC3307]).
+--------+----+----+----+------------------------------+----------+
| | |
v v v
+------------------------------------------------------+----------+
| ASM_MPREFIX64 |v4 address|
+------------------------------------------------------+----------+
SSM Mode: When several MPREFIX64 are available, it is RECOMMENDED to use the
MPREFIX64 which preserve the scope of the IPv4 multicast address.
| 8 | 4 | 4 | 16 | 4 | 60 | 32 | | 96 | 32 |
+--------+----+----+-----------+----+------------------+----------+
|11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address|
+--------+----+----+-----------+----+------------------+----------+
| | |
v v v
+------------------------------------------------------+----------+ +------------------------------------------------------+----------+
| SSM_MPREFIX64 |v4 address| | MPREFIX64 |v4 address|
+------------------------------------------------------+----------+ +------------------------------------------------------+----------+
Figure 3: MPREFIX64 Figure 1: IPv4-Embedded IPv6 Multicast Address Format
7. Source IPv4 Address in the IPv6 Realm
An IPv4 source is represented in the IPv6 realm with its IPv4-
converted IPv6 address [RFC6052].
8. Address Translation Algorithm 3.3. Address Translation Algorithm
IPv4-embedded IPv6 multicast addresses are composed according to the IPv4-embedded IPv6 multicast addresses are composed according to the
following algorithm: following algorithm:
o Concatenate the MPREFIX64 and the 32 bits of the IPv4 address to o Concatenate the MPREFIX64 and the 32 bits of the IPv4 address to
obtain a 128-bit address. obtain a 128-bit address.
The IPv4 multicast addresses are extracted from the IPv4-embedded The IPv4 multicast addresses are extracted from the IPv4-embedded
IPv6 multicast addresses according to the following algorithm: IPv6 multicast addresses according to the following algorithm:
o If the multicast address belongs to ff3x:0:8000/33 or ffxx:
8000/17, extract the last 32 bits of the IPv6 multicast address.
9. Examples o If the multicast address belongs to ff3x:0:8000::/96 or ffxx:
8000::/20, extract the last 32 bits of the IPv6 multicast address.
Figure 4 provides an example of ASM IPv4-Embedded IPv6 Address while 3.4. Textual Representation
Figure 5 provides an example of SSM IPv4-Embedded IPv6 Address.
The embedded IPv4 address in an IPv6 multicast address is included in
the last 32 bits; therefore dotted decimal notation can be used.
3.5. Source IPv4 Address in the IPv6 Realm
An IPv4 source is represented in the IPv6 realm with its IPv4-
converted IPv6 address [RFC6052].
4. Examples
Figure 2 provides an example of ASM IPv4-Embedded IPv6 Address while
Figure 3 provides an example of SSM IPv4-Embedded IPv6 Address.
IPv4 multicast addresses used in the examples are derived from the
IPv4 multicast block reserved for documentation in
[I-D.ietf-mboned-mcaddrdoc].
+---------------------+--------------+----------------------------+ +---------------------+--------------+----------------------------+
| MPREFIX64 | IPv4 address | IPv4-embedded IPv6 address | | MPREFIX64 | IPv4 address | IPv4-embedded IPv6 address |
+---------------------+--------------+----------------------------+ +---------------------+--------------+----------------------------+
| ffxx:8000:abc::/96 | 224.1.2.3 | ffxx:8000:abc::224.1.2.3 | | ffxx:8000:0:abc::/96| 233.252.0.1 |ffxx:8000:0:abc::233.252.0.1|
+---------------------+--------------+----------------------------+ +---------------------+--------------+----------------------------+
Figure 4: Example of ASM IPv4-embedded IPv6 address Figure 2: Example of ASM IPv4-embedded IPv6 address
+---------------------+--------------+----------------------------+ +---------------------+--------------+----------------------------+
| MPREFIX64 | IPv4 address | IPv4-embedded IPv6 address | | MPREFIX64 | IPv4 address | IPv4-embedded IPv6 address |
+---------------------+--------------+----------------------------+ +---------------------+--------------+----------------------------+
| ff3x:0:8000::/96 | 232.1.2.3 | ff3x:0:8000::232.1.2.3 | | ff3x:0:8000::/96 | 233.252.0.5 | ff3x:0:8000::233.252.0.5 |
+---------------------+--------------+----------------------------+ +---------------------+--------------+----------------------------+
Figure 5: Example of SSM IPv4-embedded IPv6 address Figure 3: Example of SSM IPv4-embedded IPv6 address
10. IANA Considerations 5. IANA Considerations
Authors of this document request to reserve: Authors of this document request to reserve:
o ff3x:0:8000/33 SSM block to embed an IPv4 multicast address in the
last 32 bits. o ff3x:0:8000::/96 SSM range to embed an IPv4 multicast address in
o ffxx:8000/17 ASM block to embed an IPv4 multicast address in the the last 32 bits.
o ffxx:8000::/20 ASM range to embed an IPv4 multicast address in the
last 32 bits. last 32 bits.
11. Security Considerations 6. Security Considerations
This document defines an address format to embed an IPv4 multicast This document defines an algorithmic translation of an IPv6 multicast
address in an IPv6 multicast address. The same security address into an IPv4 multicast address, and vice versa. The security
considerations as those discussed in [RFC6052] are to be taken into considerations discussed in [RFC6052] are to be taken into
consideration. consideration.
12. Acknowledgements 7. Acknowledgements
Many thanks to R. Bonica, B. Sarikaya, P. Savola, T. Tsou and C. Many thanks to R. Bonica, B. Sarikaya, P. Savola, T. Tsou and C.
Bormann for their comments and review. Bormann for their comments and review.
13. References 8. References
13.1. Normative References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002. Multicast Addresses", RFC 3306, August 2002.
[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast
Addresses", RFC 3307, August 2002.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address", Point (RP) Address in an IPv6 Multicast Address",
RFC 3956, November 2004. RFC 3956, November 2004.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006. IP", RFC 4607, August 2006.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010. October 2010.
13.2. Informative References 8.2. Informative References
[I-D.ietf-behave-nat64-learn-analysis] [I-D.ietf-behave-nat64-learn-analysis]
Korhonen, J. and T. Savolainen, "Analysis of solution Korhonen, J. and T. Savolainen, "Analysis of solution
proposals for hosts to learn NAT64 prefix", proposals for hosts to learn NAT64 prefix",
draft-ietf-behave-nat64-learn-analysis-03 (work in draft-ietf-behave-nat64-learn-analysis-03 (work in
progress), March 2012. progress), March 2012.
[I-D.ietf-mboned-mcaddrdoc]
Venaas, S., Parekh, R., Velde, G., Chown, T., and M.
Eubanks, "Multicast Addresses for Documentation",
draft-ietf-mboned-mcaddrdoc-04 (work in progress),
May 2012.
[I-D.ietf-mboned-v4v6-mcast-ps] [I-D.ietf-mboned-v4v6-mcast-ps]
Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T., Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T.,
and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and
Use Cases", draft-ietf-mboned-v4v6-mcast-ps-00 (work in Use Cases", draft-ietf-mboned-v4v6-mcast-ps-00 (work in
progress), May 2012. progress), May 2012.
[I-D.ietf-softwire-dslite-multicast] [I-D.ietf-softwire-dslite-multicast]
Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q.
Wang, "Multicast Extensions to DS-Lite Technique in Wang, "Multicast Extensions to DS-Lite Technique in
Broadband Deployments", Broadband Deployments",
draft-ietf-softwire-dslite-multicast-02 (work in draft-ietf-softwire-dslite-multicast-02 (work in
progress), May 2012. progress), May 2012.
[I-D.ietf-softwire-mesh-multicast] [I-D.ietf-softwire-mesh-multicast]
Xu, M., Cui, Y., Yang, S., Wu, J., Metz, C., and G. Xu, M., Cui, Y., Wu, J., Yang, S., Metz, C., and G.
Shepherd, "Softwire Mesh Multicast", Shepherd, "Softwire Mesh Multicast",
draft-ietf-softwire-mesh-multicast-02 (work in progress), draft-ietf-softwire-mesh-multicast-03 (work in progress),
April 2012. July 2012.
[I-D.ietf-softwire-multicast-prefix-option] [I-D.ietf-softwire-multicast-prefix-option]
Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6 Boucadair, M., Qin, J., Tsou, T., and X. Deng, "DHCPv6
Option for IPv4-Embedded Multicast and Unicast IPv6 Option for IPv4-Embedded Multicast and Unicast IPv6
Prefixes", draft-ietf-softwire-multicast-prefix-option-00 Prefixes", draft-ietf-softwire-multicast-prefix-option-01
(work in progress), March 2012. (work in progress), August 2012.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
Appendix A. Design Choices Appendix A. Motivations
A.1. Why an Address Format is Needed for Multicast IPv4-IPv6 A.1. Why an Address Format is Needed for Multicast IPv4-IPv6
Interconnection? Interconnection?
Arguments why an IPv6 address format is needed to embed multicast Arguments why an IPv6 address format is needed to embed multicast
IPv4 address are quite similar to those of [RFC6052]. Concretely, IPv4 address are quite similar to those of [RFC6052]. Concretely,
the definition of a multicast address format embedding a multicast the definition of a multicast address format embedding a multicast
IPv4 address allows: IPv4 address allows:
o Stateless IPv4-IPv6 header translation of multicast flows; o Stateless IPv4-IPv6 header translation of multicast flows;
skipping to change at page 11, line 25 skipping to change at page 10, line 26
A.1. Why an Address Format is Needed for Multicast IPv4-IPv6 A.1. Why an Address Format is Needed for Multicast IPv4-IPv6
Interconnection? Interconnection?
Arguments why an IPv6 address format is needed to embed multicast Arguments why an IPv6 address format is needed to embed multicast
IPv4 address are quite similar to those of [RFC6052]. Concretely, IPv4 address are quite similar to those of [RFC6052]. Concretely,
the definition of a multicast address format embedding a multicast the definition of a multicast address format embedding a multicast
IPv4 address allows: IPv4 address allows:
o Stateless IPv4-IPv6 header translation of multicast flows; o Stateless IPv4-IPv6 header translation of multicast flows;
o Stateless IPv4-IPv6 PIM interworking function; o Stateless IPv4-IPv6 PIM interworking function;
o Stateless IGMP-MLD interworking function (e.g., required for an o Stateless IGMP-MLD interworking function (e.g., required for an
IPv4 receiver to access to IPv4 multicast content via an IPv6 IPv4 receiver to access to IPv4 multicast content via an IPv6
network); network);
o Stateless (local) synthesis of IPv6 address when IPv4 multicast o Stateless (local) synthesis of IPv6 address when IPv4 multicast
address are embedded in application payload (e.g., SDP [RFC4566]); address are embedded in application payload (e.g., SDP [RFC4566]);
o Except the provisioning of the same MPREFIX64, no coordination is o Except the provisioning of the same MPREFIX64, no coordination is
required between IPv4-IPv6 PIM interworking function, IGMP-MLD required between IPv4-IPv6 PIM interworking function, IGMP-MLD
interworking function, IPv4-IPv6 Interconnection Function and any interworking function, IPv4-IPv6 Interconnection Function and any
ALG (Application Level Gateway) in the path; ALG (Application Level Gateway) in the path;
o Minimal operational constraints on the multicast address o Minimal operational constraints on the multicast address
management: IPv6 multicast addresses can be constructed using what management: IPv6 multicast addresses can be constructed using what
has been deployed for IPv4 delivery mode. has been deployed for IPv4 delivery mode.
A.2. Why Identifying an IPv4-Embedded IPv6 Multicast Address is A.2. Why Identifying an IPv4-Embedded IPv6 Multicast Address is
Required? Required?
Reserving an M-bit in the IPv6 multicast address (which is equivalent Reserving a dedicated multicast prefix for IPv4-IPv6 interconnection
to reserving a dedicated multicast block for IPv4-IPv6 purposes is a means to guide the address selection process at the
interconnection purposes) is a means to guide the address selection receiver side; in particular it assists the receiver to select the
process at the receiver side; in particular it assists the receiver appropriate IP multicast address while avoiding to involve an IPv4-
to select the appropriate IP multicast address while avoiding to IPv6 interconnection function in the path.
involve an IPv4-IPv6 interconnection function in the path.
Two use cases to illustrate this behavior are provided below: Two use cases to illustrate this behavior are provided below:
1. An ALG is required to help an IPv6 receiver to select the 1. An ALG is required to help an IPv6 receiver to select the
appropriate IP address when only the IPv4 address is advertised appropriate IP address when only the IPv4 address is advertised
(e.g., using SDP); otherwise the access to the IPv4 multicast (e.g., using SDP); otherwise the access to the IPv4 multicast
content can not be offered to the IPv6 receiver. The ALG may be content can not be offered to the IPv6 receiver. The ALG may be
located downstream the receiver. As such, the ALG does not know located downstream the receiver. As such, the ALG does not know
in advance whether the receiver is dual-stack or IPv6-only. The in advance whether the receiver is dual-stack or IPv6-only. The
ALG may be tuned to insert both the original IPv4 address and ALG may be tuned to insert both the original IPv4 address and
corresponding IPv6 multicast address. If the M-bit is not used, corresponding IPv6 multicast address. If a dedicated prefix is
a dual-stack receiver may prefer to use the IPv6 address to not used, a dual-stack receiver may prefer to use the IPv6
receive the multicast content. This address selection would address to receive the multicast content. This address selection
require multicast flows to cross an IPv4-IPv6 interconnection would require multicast flows to cross an IPv4-IPv6
function. interconnection function.
2. In order to avoid involving an ALG in the path, an IPv4-only 2. In order to avoid involving an ALG in the path, an IPv4-only
source can advertise both its IPv4 address and IPv4-embedded IPv6 source can advertise both its IPv4 address and IPv4-embedded IPv6
multicast address. If the M-bit is not used, a dual-stack multicast address. If a dedicated prefix is not reserved, a
receiver may prefer to use the IPv6 address to receive the dual-stack receiver may prefer to use the IPv6 address to receive
multicast content. This address selection would require the multicast content. This address selection would require
multicast flows to cross an IPv4-IPv6 interconnection function. multicast flows to cross an IPv4-IPv6 interconnection function.
Reserving an M-bit in the IPv6 multicast address for IPv4-IPv6
Reserving dedicated IPv6 multicast prefixes for IPv4-IPv6
interconnection purposes mitigates the issues discussed in interconnection purposes mitigates the issues discussed in
[I-D.ietf-behave-nat64-learn-analysis] in a multicast context. [I-D.ietf-behave-nat64-learn-analysis] in a multicast context.
A.3. Location of the IPv4 Address A.3. Location of the IPv4 Address
There is no strong argument to allow for flexible options to encode There is no strong argument to allow for flexible options to encode
the IPv4 address inside the multicast IPv6 address. The option the IPv4 address inside the multicast IPv6 address. The option
retained by the authors is to encode the multicast IPv4 address in retained by the authors is to encode the multicast IPv4 address in
the low-order 32 bits of the IPv6 address. the low-order 32 bits of the IPv6 address.
This choice is also motivated by the need to be compliant with This choice is also motivated by the need to be compliant with
[RFC3306] and [RFC3956]. [RFC3306] and [RFC3956].
A.4. Location of the M-bit
Figure 6 is a reminder of the IPv6 multicast address format as
defined in [RFC4291]:
| 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]
Figure 6: IPv6 Multicast address format as defined in RFC4291
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:
o ff3x::/32 is defined as SSM. Defining a new flag would require
standards and implementations to also treat ffbx::/32 as SSM.
o Prefixes starting with ff7x are defined as embedded-RP, but not
prefixes starting with fffx. Below is provided an excerpt from
[RFC3956]:
" ...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."
as such defining a new flag would require implementations to
also treat ff7x::/12 as embedded-RP prefix.
o This is the last remaining flag and at this stage we are not sure
whether there is other usage scenarios of the flag.
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:
(1) Belong to ff3x::/32 and be compatible with unicast-based
prefix [RFC3306] for SSM. Note that [RFC3306] suggests to set
"plen" to 0 and "network-prefix" to 0.
(2) Be compatible with embedded-RP [RFC3956] and unicast-based
prefix [RFC3306] for ASM;
(3) Avoid ff3x::4000:0001-ff3x::7fff:ffff which is reserved for
IANA.
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.
As a consequence, two multicast blocks are proposed to be used when
embedding IPv4 address: one block for ASM (Section 3 ) and another
one for the SSM (Section 4).
A.5. Encapsulation vs. Translation
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.
As such, there is no need to reserve a bit in the IPv6 multicast
address to separate between the translation and the encapsulation
schemes.
Authors' Addresses Authors' Addresses
Mohamed Boucadair (editor) Mohamed Boucadair (editor)
France Telecom France Telecom
Rennes, 35000 Rennes, 35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Jacni Qin Jacni Qin
 End of changes. 66 change blocks. 
272 lines changed or deleted 181 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/