< draft-boucadair-behave-64-multicast-address-format-02.txt   draft-boucadair-behave-64-multicast-address-format-03.txt >
BEHAVE WG M. Boucadair BEHAVE WG M. Boucadair
Internet-Draft France Telecom Internet-Draft France Telecom
Updates: 4291, 6052 (if approved) J. Qin Updates: 4291 (if approved) J. Qin
Intended status: Standards Track ZTE Intended status: Standards Track ZTE
Expires: December 26, 2011 Y. Lee Expires: April 28, 2012 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
June 24, 2011 October 26, 2011
IPv4-Embedded IPv6 Multicast Address Format IPv4-Embedded IPv6 Multicast Address Format
draft-boucadair-behave-64-multicast-address-format-02 draft-boucadair-behave-64-multicast-address-format-03
Abstract Abstract
This document specifies an extension to the IPv6 multicast addressing This document specifies an extension to the IPv6 multicast addressing
architecture to be used in the context of IPv4-IPv6 interconnection. architecture to be used in the context of IPv4-IPv6 interconnection.
In particular, this document defines an address format for IPv4- In particular, this document defines an address format for IPv4-
embedded IPv6 multicast addresses. This address format can be used embedded IPv6 multicast addresses. This address format can be used
for IPv4-IPv6 translation or encapsulation schemes. for 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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 December 26, 2011.
This Internet-Draft will expire on April 28, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. IPv4-Embedded IPv6 Multicast Address Format: ASM Mode . . . . 5
4. Why an Address Format is Needed for Multicast IPv4-IPv6 4. IPv4-Embedded IPv6 Multicast Address Format: SSM Mode . . . . 6
Interconnection? . . . . . . . . . . . . . . . . . . . . . . . 6 5. Textual Representation . . . . . . . . . . . . . . . . . . . . 6
5. Why Identifying an IPv4-Embedded IPv6 Multicast Address is 6. Multicast PREFIX64 . . . . . . . . . . . . . . . . . . . . . . 7
Required? . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Source IPv4 Address in the IPv6 Ream . . . . . . . . . . . . . 8
6. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6.1. Location of the IPv4 Address . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6.2. Location of the M-bit . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Encapsulation vs. Translation . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. IPv4-Embedded IPv6 Multicast Address Format: ASM Mode . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9
8. IPv4-Embedded IPv6 Multicast Address Format: SSM Mode . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . . 9
9. Textual Representation . . . . . . . . . . . . . . . . . . . . 11 Appendix A. Design Choices . . . . . . . . . . . . . . . . . . . 11
10. Multicast PREFIX64 . . . . . . . . . . . . . . . . . . . . . . 11 A.1. Why Identifying an IPv4-Embedded IPv6 Multicast
11. Source IPv4 Address in the IPv6 Ream . . . . . . . . . . . . . 12 Address is Required? . . . . . . . . . . . . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 A.2. Why an Address Format is Needed for Multicast
13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 IPv4-IPv6 Interconnection? . . . . . . . . . . . . . . . . 11
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 A.3. Location of the IPv4 Address . . . . . . . . . . . . . . . 12
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 A.4. Location of the M-bit . . . . . . . . . . . . . . . . . . 12
15.1. Normative References . . . . . . . . . . . . . . . . . . . 13 A.5. Encapsulation vs. Translation . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This document specifies an extension to the multicast IPv6 addressing Recently various solutions (e.g.,
architecture [RFC4291]. This extension is used for building IPv4- [I-D.venaas-behave-v4v6mc-framework],
embedded IPv6 multicast addresses. [I-D.ietf-softwire-mesh-multicast],
[I-D.ietf-softwire-dslite-multicast],
[I-D.sarikaya-behave-netext-nat64-pmip] or
[I-D.sarikaya-behave-mext-nat64-dsmip]) 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.
This document aims at harmonizing the definition of an IPv4-embedded
IPv6 address format. It specifies an extension to the multicast IPv6
addressing architecture [RFC4291]. This extension is used for
building IPv4-embedded IPv6 multicast addresses.
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].
This document updates [RFC6052] which focuses exclusively on IPv4- This document is a companion document to [RFC6052] which focuses
embedded IPv6 unicast addresses. exclusively on IPv4-embedded IPv6 unicast addresses.
More discussion about issues related to IPv4/IPv6 multicast can be More discussion about issues related to IPv4/IPv6 multicast can be
found at [I-D.jaclee-behave-v4v6-mcast-ps]. found at [I-D.jaclee-behave-v4v6-mcast-ps].
Details about design choices are documented in Appendix A.
1.1. Scope 1.1. Scope
The address format defined in this document applies for both IPv4- The address format defined in this document applies for both IPv4-
IPv6 translation and encapsulation schemes. IPv6 translation and encapsulation schemes.
It is out of scope of this document to define the overall procedure It is out of scope of this document to define the overall procedure
for the delivery of IPv4-embedded IPv6 multicast to the requesting for the delivery of IPv4-embedded IPv6 multicast to the requesting
receivers. Practical details about the procedure is defined in receivers. Practical details about the procedure is defined in
specific documents such as [I-D.venaas-behave-v4v6mc-framework] and specific documents such as [I-D.venaas-behave-v4v6mc-framework] and
[I-D.qin-softwire-dslite-multicast].
[I-D.ietf-softwire-dslite-multicast].
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. Two types of
IPv6 addresses are defined that carry an IPv4 address in the low- IPv6 addresses are defined that carry an IPv4 address in the low-
order 32 bits of the address. The format to build such addresses order 32 bits of the address. The format to build such addresses
is defined in Section 7 for ASM mode and Section 8 for SSM mode. is defined in Section 3 for ASM mode and Section 4 for 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. IPv6-enabled one.
An IPv4-IPv6 Interconnection Function can be implemented using
encapsulation or translation techniques.
It can be located in various places of the multicast network;
it is deployment-specific issue left to operators.
Particularly, in terms of multicast control message, it can be
an IGMP/MLD Interworking Function or an IPv4-IPv6 PIM
Interworking Function. Since from the protocol perspective,
the MLD protocol [RFC3810] is a translation of IGMP [RFC3376]
in the semantics of IPv6 and PIM [RFC4601] has been designed to
accommodate both IPv4 and IPv6, no extra functionality is
needed to be defined, but to follow the address format
specified in Section 7 for ASM mode and Section 8 for SSM mode.
In terms of multicast traffic forwarding, it can be
translation-based or encapsulation-based.
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. multicast addresses.
o ASM_MPREFIX64: denotes a multicast Prefix64 used in ASM mode. It
follows the format described in Section 3.
o SSM_MPREFIX64: denotes a multicast Prefix64 used in SSM mode. It
follows the format described in Section 4.
o ASM_MPREFIX64: denotes a multicast Prefix64 used in ASM mode 3. IPv4-Embedded IPv6 Multicast Address Format: ASM Mode
(Section 7).
o SSM_MPREFIX64: denotes a multicast Prefix64 used in SSM mode
(Section 8).
3. Motivations
Recently various solutions (e.g.,
[I-D.venaas-behave-v4v6mc-framework],
[I-D.xu-softwire-mesh-multicast],
[I-D.qin-softwire-dslite-multicast],
[I-D.sarikaya-behave-netext-nat64-pmip] or
[I-D.sarikaya-behave-mext-nat64-dsmip]) 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.
This document aims at harmonizing the definition of an IPv4-embedded
IPv6 address format.
4. Why an Address Format is Needed for Multicast IPv4-IPv6
Interconnection?
Arguments why an IPv6 address format is needed to embed multicast
IPv4 address are quite similar to those of [RFC6052]. Concretely,
the definition of a multicast address format embedding a multicast
IPv4 address allows:
o Stateless IPv4-IPv6 header translation of multicast flows;
o Stateless IPv4-IPv6 PIM interworking function;
o Stateless IGMP-MLD interworking function (e.g., required for an
IPv4 receiver to access to IPv4 multicast content via an IPv6
network);
o Stateless (local) synthesis of IPv6 address when IPv4 multicast
address are embedded in application payload (e.g., SDP [RFC4566]);
o 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;
o Minimal operational constraints on the multicast address
management: IPv6 multicast addresses can be constructed using what
has been deployed for IPv4 delivery mode.
5. Why Identifying an IPv4-Embedded IPv6 Multicast Address is Required?
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.
Two use cases to illustrate this behavior are provided below:
1. 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 using for instance the ALTC
SDP attribute [I-D.boucadair-mmusic-altc]. 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.
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
multicast address using for instance the ALTC SDP attribute. 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.
Reserving an M-bit in the IPv6 multicast address for IPv4-IPv6
interconnection purposes mitigates the issues discussed in
[I-D.ietf-behave-nat64-learn-analysis] in a multicast context.
6. Design Choices
6.1. Location of the IPv4 Address
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.
This choice is also motivated by the need to be compliant with
[RFC3306] and [RFC3956].
6.2. Location of the M-bit
Figure 1 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 1: 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. Blow 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 7 ) and another
one for the SSM (Section 8).
6.3. 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.
7. IPv4-Embedded IPv6 Multicast Address Format: ASM Mode
To meet the requirements listed in Section 6.2, the following address To meet the requirements listed in Appendix A.4, the following
format is defined to enclose an IPv4 multicast address when ASM mode address format is defined to enclose an IPv4 multicast address when
is used: ASM mode is used:
| 8 | 4 | 4 | 4 | 76 | 32 | | 8 | 4 | 4 | 4 | 76 | 32 |
+--------+----+----+----+------------------------------+----------+ +--------+----+----+----+------------------------------+----------+
|11111111|flgs|scop|64IX| sub-group-id |v4 address| |11111111|flgs|scop|64IX| sub-group-id |v4 address|
+--------+----+----+----+-----------------------------------------+ +--------+----+----+----+-----------------------------------------+
+-+-+-+-+ +-+-+-+-+
IPv4-IPv6 Interconnection bits (64IX): |M|r|r|r| IPv4-IPv6 Interconnection bits (64IX): |M|r|r|r|
+-+-+-+-+ +-+-+-+-+
Figure 2: IPv4-Embedded IPv6 Multicast Address Format: ASM Mode Figure 1: IPv4-Embedded IPv6 Multicast Address Format: ASM Mode
The description of the fields is as follows: The description of the fields is as follows:
o "flgs" and "scop" fields are defined in [RFC4291]. o "flgs" and "scop" fields are defined in [RFC4291].
o 64IX field (IPv4-IPv6 interconnection bits): The first bit is the o 64IX field (IPv4-IPv6 interconnection bits): The first bit is the
M-bit. When "M-bit" is set to 1, it indicates that an multicast M-bit. When "M-bit" is set to 1, it indicates that an multicast
IPv4 address is embedded in the low-order 32 bits of the 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 IPv6 address. All the remaining bits are reserved and MUST be set
to 0. to 0.
o sub-group-id: This field is configurable according to local o sub-group-id: This field is configurable according to local
policies of the entity managing the IPv4-IPv6 Interconnection policies of the entity managing the IPv4-IPv6 Interconnection
Function. This field must follow the recommendations specified in Function. This field must follow the recommendations specified in
[RFC3306] if If unicast-based prefix is used or the [RFC3306] if unicast-based prefix is used or the recommendations
recommendations specified in [RFC3306] if embedded-RP is used. specified in [RFC3956] if embedded-RP is used. The default value
The default value is all zeros. is all zeros.
o The low-order 32 bits MUST include an IPv4 multicast address when 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 the M-bit is set to 1. The enclosed IPv4 multicast address SHOULD
NOT be in 232/8 range. NOT be in 232/8 range.
[[DISCUSSION NOTE: Restrict an IPv6 ASM address to embed only [[DISCUSSION NOTE: Restrict an IPv6 ASM address to embed only
an ASM IPv4 address or relax it?]] an ASM IPv4 address or relax it?]]
8. IPv4-Embedded IPv6 Multicast Address Format: SSM Mode 4. IPv4-Embedded IPv6 Multicast Address Format: SSM Mode
As mentioned above, any IPv4-embedded IPv6 address used in SSM mode As mentioned above, any IPv4-embedded IPv6 address used in SSM mode
MUST be part of ff3x::/32 [RFC4607]. Figure 3 describes the format MUST be part of ff3x::/32 [RFC4607]. Figure 2 describes the format
of the IPv6 multicast address to be used to enclose an IPv4 multicast of the IPv6 multicast address to be used to enclose an IPv4 multicast
address. address.
| 8 | 4 | 4 | 16 | 4 | 60 | 32 | | 8 | 4 | 4 | 16 | 4 | 60 | 32 |
+--------+----+----+-----------+----+------------------+----------+ +--------+----+----+-----------+----+------------------+----------+
|11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address| |11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address|
+--------+----+----+-----------+----+------------------+----------+ +--------+----+----+-----------+----+------------------+----------+
+-+-+-+-+ +-+-+-+-+
IPv4-IPv6 Interconnection bits (64IX): |M|r|r|r| IPv4-IPv6 Interconnection bits (64IX): |M|r|r|r|
+-+-+-+-+ +-+-+-+-+
Figure 3: IPv4-Embedded IPv6 Multicast Address Format: SSM Mode Figure 2: IPv4-Embedded IPv6 Multicast Address Format: SSM Mode
The description of the fields is as follows: The description of the fields is as follows:
o Flags must be set to 0011. o Flags must be set to 0011.
o "scop" is defined in [RFC4291]. o "scop" is defined in [RFC4291].
o 64IX field (IPv4-IPv6 interconnection bits): Same meaning as o 64IX field (IPv4-IPv6 interconnection bits): Same meaning as
Section 7. Section 3.
o sub-group-id: The default value is all zeros. o sub-group-id: The default value is all zeros.
o The low-order 32 bits MUST include an IPv4 multicast address when 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 the M-bit is set to 1. The embedded IPv4 address SHOULD be in the
232/8 range [RFC4607]. 232.0.0.1-232.0.0.255 range is being 232/8 range [RFC4607]. 232.0.0.1-232.0.0.255 range is being
reserved to IANA. reserved to IANA.
[[DISCUSSION NOTE: Restrict an IPv6 SSM address to embed only [[DISCUSSION NOTE: Restrict an IPv6 SSM address to embed only
an SSM IPv4 address?]] an SSM IPv4 address?]]
9. Textual Representation 5. Textual Representation
The embedded IPv4 address in an IPv6 multicast address is included in The embedded IPv4 address in an IPv6 multicast address is included in
the last 32 bits; therefore dotted decimal notation can be used. the last 32 bits; therefore dotted decimal notation can be used.
10. Multicast PREFIX64 6. Multicast PREFIX64
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 to any function requiring to build an IPv4-embedded IPv6 provisioned to any function requiring to build an IPv4-embedded IPv6
multicast address based on an IPv4 multicast address. MPREFIX64 can multicast address based on an IPv4 multicast address. MPREFIX64 can
be of ASM or SSM type. When both modes are used, two prefixes are be of ASM or SSM type. When both modes are used, two prefixes are
required to be provisioned. required to be provisioned.
The structure of the MPREFIX64 follows the guidelines specified in The structure of the MPREFIX64 follows the guidelines specified in
Section 7 for the ASM mode and Section 8 when SSM mode is used. Section 3 for the ASM mode and Section 4 when SSM mode is used.
MPREFIX64 MAY be of any length from /32 to /96; /96 being the MPREFIX64 MAY be of any length from /32 to /96; /96 being the
RECOMMENDED prefix length as shown in Figure 4). RECOMMENDED prefix length as shown in Figure 3).
The format of the MPREFIX64 should be compatible with what is The format of the MPREFIX64 should be compatible with what is
specified in [RFC3306] and [RFC3956] if corresponding mechanisms are specified in [RFC3306] and [RFC3956] if corresponding mechanisms are
used. used.
ASM Mode: ASM Mode:
| 8 | 4 | 4 | 4 | 76 | 32 | | 8 | 4 | 4 | 4 | 76 | 32 |
+--------+----+----+----+------------------------------+----------+ +--------+----+----+----+------------------------------+----------+
|11111111|flgs|scop|64IX| sub-group-id |v4 address| |11111111|flgs|scop|64IX| sub-group-id |v4 address|
skipping to change at page 12, line 29 skipping to change at page 8, line 29
| 8 | 4 | 4 | 16 | 4 | 60 | 32 | | 8 | 4 | 4 | 16 | 4 | 60 | 32 |
+--------+----+----+-----------+----+------------------+----------+ +--------+----+----+-----------+----+------------------+----------+
|11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address| |11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address|
+--------+----+----+-----------+----+------------------+----------+ +--------+----+----+-----------+----+------------------+----------+
| | | | | |
v v v v v v
+------------------------------------------------------+----------+ +------------------------------------------------------+----------+
| SSM_MPREFIX64 |v4 address| | SSM_MPREFIX64 |v4 address|
+------------------------------------------------------+----------+ +------------------------------------------------------+----------+
Figure 4: MPREFIX64 Figure 3: MPREFIX64
11. Source IPv4 Address in the IPv6 Ream 7. Source IPv4 Address in the IPv6 Ream
An IPv4 source is represented in the IPv6 realm with its IPv4- An IPv4 source is represented in the IPv6 realm with its IPv4-
converted IPv6 address [RFC6052]. converted IPv6 address [RFC6052].
12. IANA Considerations 8. IANA Considerations
TBC. TBC.
13. Security Considerations 9. Security Considerations
This document defined an address format to embed an IPv4 multicast This document defined an address format to embed an IPv4 multicast
address in an IPv6 multicast address. The same security address in an IPv6 multicast address. The same security
considerations as those discussed in [RFC6052] are to be taken into considerations as those discussed in [RFC6052] are to be taken into
consideration. consideration.
14. Acknowledgements 10. Acknowledgements
Many thanks to B. Sarikaya and P. Savola for their comments. Many thanks to B. Sarikaya, P. Savola and T. Tsou for their comments.
15. References 11. References
15.1. Normative References 11.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.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, October 2002.
skipping to change at page 13, line 47 skipping to change at page 9, line 47
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006. Protocol Specification (Revised)", RFC 4601, August 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.
15.2. Informative References 11.2. Informative References
[I-D.boucadair-mmusic-altc] [I-D.boucadair-mmusic-altc]
Boucadair, M., Kaplan, H., Gilman, R., and S. Boucadair, M., Kaplan, H., Gilman, R., and S.
Veikkolainen, "Session Description Protocol (SDP) Veikkolainen, "Session Description Protocol (SDP)
Alternate Connectivity (ALTC) Attribute", Alternate Connectivity (ALTC) Attribute",
draft-boucadair-mmusic-altc-02 (work in progress), draft-boucadair-mmusic-altc-03 (work in progress),
March 2011. September 2011.
[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-00 (work in draft-ietf-behave-nat64-learn-analysis-01 (work in
progress), May 2011. progress), October 2011.
[I-D.ietf-softwire-dslite-multicast]
Wang, Q., Qin, J., Boucadair, M., Jacquenet, C., and Y.
Lee, "Multicast Extensions to DS-Lite Technique in
Broadband Deployments",
draft-ietf-softwire-dslite-multicast-00 (work in
progress), September 2011.
[I-D.ietf-softwire-mesh-multicast]
Xu, M., Cui, Y., Yang, S., Wu, J., Metz, C., and G.
Shepherd, "Softwire Mesh Multicast",
draft-ietf-softwire-mesh-multicast-00 (work in progress),
September 2011.
[I-D.jaclee-behave-v4v6-mcast-ps] [I-D.jaclee-behave-v4v6-mcast-ps]
Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T. Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., and T.
ZOU), "IPv4-IPv6 Multicast: Problem Statement and Use ZOU), "IPv4-IPv6 Multicast: Problem Statement and Use
Cases", draft-jaclee-behave-v4v6-mcast-ps-02 (work in Cases", draft-jaclee-behave-v4v6-mcast-ps-02 (work in
progress), June 2011. progress), June 2011.
[I-D.qin-softwire-dslite-multicast]
Wang, Q., Qin, J., Boucadair, M., Jacquenet, C., and Y.
Lee, "Multicast Extensions to DS-Lite Technique in
Broadband Deployments",
draft-qin-softwire-dslite-multicast-04 (work in progress),
June 2011.
[I-D.sarikaya-behave-mext-nat64-dsmip] [I-D.sarikaya-behave-mext-nat64-dsmip]
Sarikaya, B. and F. Xia, "NAT64 for Dual Stack Mobile Sarikaya, B. and F. Xia, "NAT64 for Dual Stack Mobile
IPv6", draft-sarikaya-behave-mext-nat64-dsmip-02 (work in IPv6", draft-sarikaya-behave-mext-nat64-dsmip-02 (work in
progress), January 2011. progress), January 2011.
[I-D.sarikaya-behave-netext-nat64-pmip] [I-D.sarikaya-behave-netext-nat64-pmip]
Sarikaya, B. and F. Xia, "NAT64 for Proxy Mobile IPv6", Sarikaya, B. and F. Xia, "NAT64 for Proxy Mobile IPv6",
draft-sarikaya-behave-netext-nat64-pmip-01 (work in draft-sarikaya-behave-netext-nat64-pmip-01 (work in
progress), January 2011. progress), January 2011.
[I-D.venaas-behave-v4v6mc-framework] [I-D.venaas-behave-v4v6mc-framework]
Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6
Multicast Translation", Multicast Translation",
draft-venaas-behave-v4v6mc-framework-03 (work in draft-venaas-behave-v4v6mc-framework-03 (work in
progress), June 2011. progress), June 2011.
[I-D.xu-softwire-mesh-multicast] Appendix A. Design Choices
Xu, M., Cui, Y., Yang, S., Metz, C., and G. Shepherd,
"Softwire Mesh Multicast", A.1. Why Identifying an IPv4-Embedded IPv6 Multicast Address is
draft-xu-softwire-mesh-multicast-01 (work in progress), Required?
March 2011.
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.
Two use cases to illustrate this behavior are provided below:
1. 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 using for instance the ALTC
SDP attribute [I-D.boucadair-mmusic-altc]. 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.
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
multicast address using for instance the ALTC SDP attribute. 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.
Reserving an M-bit in the IPv6 multicast address for IPv4-IPv6
interconnection purposes mitigates the issues discussed in
[I-D.ietf-behave-nat64-learn-analysis] in a multicast context.
A.2. Why an Address Format is Needed for Multicast IPv4-IPv6
Interconnection?
Arguments why an IPv6 address format is needed to embed multicast
IPv4 address are quite similar to those of [RFC6052]. Concretely,
the definition of a multicast address format embedding a multicast
IPv4 address allows:
o Stateless IPv4-IPv6 header translation of multicast flows;
o Stateless IPv4-IPv6 PIM interworking function;
o Stateless IGMP-MLD interworking function (e.g., required for an
IPv4 receiver to access to IPv4 multicast content via an IPv6
network);
o Stateless (local) synthesis of IPv6 address when IPv4 multicast
address are embedded in application payload (e.g., SDP [RFC4566]);
o 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;
o Minimal operational constraints on the multicast address
management: IPv6 multicast addresses can be constructed using what
has been deployed for IPv4 delivery mode.
A.3. Location of the IPv4 Address
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.
This choice is also motivated by the need to be compliant with
[RFC3306] and [RFC3956].
A.4. Location of the M-bit
Figure 4 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 4: 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. Blow 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 Mohamed Boucadair
France Telecom France Telecom
Rennes, 35000 Rennes, 35000
France France
Email: mohamed.boucadair@orange-ftgroup.com Email: mohamed.boucadair@orange.com
Jacni Qin Jacni Qin
ZTE ZTE
Shanghai Shanghai
China China
Email: jacniq@gmail.com Email: jacniq@gmail.com
Yiu L. Lee Yiu L. Lee
Comcast Comcast
U.S.A
Email: yiu_lee@cable.comcast.com Email: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Stig Venaas Stig Venaas
Cisco Systems Cisco Systems
Tasman Drive Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
USA USA
Email: stig@cisco.com Email: stig@cisco.com
Xing Li Xing Li
CERNET Center/Tsinghua University CERNET Center/Tsinghua University
Room 225, Main Building, Tsinghua University Room 225, Main Building, Tsinghua University
Beijing, 100084 Beijing, 100084
P.R. China P.R. China
Phone: +86 10-62785983 Phone: +86 10-62785983
Fax:
Email: xing@cernet.edu.cn Email: xing@cernet.edu.cn
URI:
Mingwei Xu Mingwei Xu
Tsinghua University Tsinghua University
Department of Computer Science, Tsinghua University Department of Computer Science, Tsinghua University
Beijing, 100084 Beijing, 100084
P.R.China P.R.China
Phone: +86-10-6278-5822 Phone: +86-10-6278-5822
Email: xmw@cernet.edu.cn Email: xmw@cernet.edu.cn
 End of changes. 52 change blocks. 
292 lines changed or deleted 247 lines changed or added

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