One document matched: draft-boucadair-behave-64-multicast-address-format-00.txt
Network Working Group M. Boucadair
Internet-Draft France Telecom
Updates: 4192 (if approved) J. Qin
Intended status: Standards Track ZTE
Expires: July 4, 2011 Y. Lee
Comcast
December 31, 2010
IPv4-Embedded IPv6 Multicast Address Format
draft-boucadair-behave-64-multicast-address-format-00
Abstract
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.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 4, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Boucadair, et al. Expires July 4, 2011 [Page 1]
Internet-Draft 64 Multicast Address Format December 2010
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. IPv4-Embedded IPv6 Multicast Address Format . . . . . . . . . . 4
4.1. Role of the S-bit . . . . . . . . . . . . . . . . . . . . . 6
4.2. Textual Representation . . . . . . . . . . . . . . . . . . 6
4.3. Lifetime of the IPv4-Embeded IPv6 Multicast Address . . . . 6
4.4. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.5. SSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5. Multicast PREFIX64 . . . . . . . . . . . . . . . . . . . . . . 6
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Boucadair, et al. Expires July 4, 2011 [Page 2]
Internet-Draft 64 Multicast Address Format December 2010
1. Introduction
This document 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
such as building unicast prefix-based multicast IPv6 address
[RFC3306] or embedding the rendez-vous point [RFC3956]. This is left
to the taste of operators. In particular, the extension defined in
this document can be used in a context where [RFC3306] and [RFC3956]
are not implemented.
This document updates [RFC6052] which focuses exclusively on IPv4-
embeded IPv6 unicast addresses.
1.1. Scope
The address format defined in this document applies for both IPv4-
IPv6 translation and encapsulation schemes.
It is out of scope of this document to define the overall procedure
for the delivery of IPv4-embeded IPv6 multicast to the requesting
receivers. Practical details about the procedure is defined in
specific documents such as [I-D.venaas-behave-v4v6mc-framework] and
[I-D.qin-softwire-dslite-multicast].
2. Terminology
This document makes use of the following terms:
o IPv4-embeded IPv6 multicast address: denotes a multicast IPv6
address which includes in 32 bits an IPv4 address. The format to
build such address is defined in Section 4.
o IPv4-IPv6 Interconnection Function: refers to a function which is
enabled in a node interconnecting an IPv4-enabled domain with an
IPv6-enabled one. An IPv4-IPv6 Interconnection Function can be
implemented using encapsulation or translation techniques. t can
be located in various places of the multicast network, and that is
the 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
is a translation of IGMP in the semantics of IPv6 and PIM has been
designed to accommodate both IPv4 and IPv6, no extra functionality
is needed to be defined but to follow the address format specified
Boucadair, et al. Expires July 4, 2011 [Page 3]
Internet-Draft 64 Multicast Address Format December 2010
in Section 4. 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
multicast prefix to be used to construct IPv4-embedded IPv6
multicast addresses.
o ASM_MPREFIX64: denotes an MPREFIX64 used in ASM mode.
o SSM_MPREFIX64: denotes an MPREFIX64 used in SSM mode.
3. Motivations
Recently various solutions (e.g.,
[I-D.venaas-behave-v4v6mc-framework],
[I-D.xu-softwire-mesh-multicast] or
[I-D.qin-softwire-dslite-multicast]) 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 various use cases, they
all make use of specific IPv6 multicast addresses to embed an IPv4
multicast address. Particularly, the IPv4-embeded IPv6 multicast
address is used as a destination IPv6 address of multicast flows
received from the IPv4-enabled domain and injected by the IPv4-IPv6
Interconnection Function into the IPv6-enabled domain. It is also
used to build the 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-embeded
IPv6 address format.
4. IPv4-Embedded IPv6 Multicast Address Format
This document specifies a modification to the IPv6 multicast address
format [RFC4291] by defining the first higher bit of the "flags"
field.
Boucadair, et al. Expires July 4, 2011 [Page 4]
Internet-Draft 64 Multicast Address Format December 2010
| 8 | 4 | 4 | 4 | 76 | 32 |
+--------+----+----+----+------------------------------+----------+
|11111111|flgs|scop|sche| sub-group-id |v4 address|
+--------+----+----+----+-----------------------------------------+
+-+-+-+-+
flgs is a set of four flags: |M|R|P|T|
+-+-+-+-+
+-+-+-+-+
IPv4-IPv6 interconnection scheme bits: |r|r|r|S|
+-+-+-+-+
Figure 1: IPv4-Embedded IPv6 Multicast Address Format
The description of the fields is as follows:
o Binary 11111111 at the start of the address identifies the address
as being a multicast address.
o Flags
* "T-bit" is defined in [RFC4291].
* "P-bit" is defined in [RFC3306].
* "R-bit" is defined in [RFC3956].
* "M-bit" when set to 1 indicates that an IPv4 address is
embedded in the last 32 bits of the multicast IPv6 address
o Scope is defined in [RFC4291]. Allowed values are 8 for
Organization-Local scope or E for Global scope.
o Reserved bits: the 5th higher bit "S-bit" indicates the scheme
used to carry IPv6 multicast flows in the IPv6 domain. When set
to 0, it indicates flows are transported using IPv4-in-IPv6
encapsulation scheme (i.e., IPv4-IPv6 Interconnection Function is
an IPv4-IPv6 encapsulator). When set to 1, it indicates the
multicast flows are to be transported in native IPv6 (i.e., IPv4-
IPv6 Interconnection Function is an IPv4-IPv6 translator). All
remaining bits SHOULD be set to 0 by default. This bit is only
used by the IPv4-IPv6 Interconnection Function. See Section 4.1.
o sub-group-id: This field is configurable according to local
policies of the entity managing the IPv4-IPv6 Interconnection
Function. The default value is all zeros.
[[NOTE: 64??]]
Boucadair, et al. Expires July 4, 2011 [Page 5]
Internet-Draft 64 Multicast Address Format December 2010
o The last 32 bits MUST include an IPv4 multicast address.
[[Discussion note: Below is provided an alternative proposal for the
location of the bits]]
+-+-+-+-+
flgs is a set of four flags: |0|R|P|T|
+-+-+-+-+
+-+-+-+-+
IPv4-IPv6 interconnection scheme bits: |r|r|M|S|
+-+-+-+-+
4.1. Role of the S-bit
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; the "S-bit" is used
for that purpose.
4.2. Textual Representation
The embedded IPv4 address is included in the last 32 bits; therefore
dotted decimal notation can be used.
4.3. Lifetime of the IPv4-Embeded IPv6 Multicast Address
TBC.
4.4. Scope
Fixed or let it be configurable.
4.5. SSM
Further elaboration on SSM [RFC4607].
5. Multicast PREFIX64
For the delivery of the IPv4-IPv6 multicast interconnection services,
a dedicated multicast prefix denoted as MPREFIX64 should be
provisioned 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.
The structure of the MPREFIX64 follows the guidelines specified in
Boucadair, et al. Expires July 4, 2011 [Page 6]
Internet-Draft 64 Multicast Address Format December 2010
Section 4.
MPREFIX64 MAY be of any length from /32 to /96; /96 being the
RECOMMENDED prefix length as shown in Figure 3). The format of the
MPREFIX64 should be compatible with what proposed in [RFC3306] and
[RFC3956] if corresponding mechanisms are used.
| 8 | 4 | 4 | 4 | 76 | 32 |
+--------+----+----+----+-----------------------------+----------+
|11111111|flgs|scop|sche| sub-group-id |v4 address|
+--------+----+----+----+-----------------------------+----------+
| | |
v v |
+-----------------------------------------------------+----------+
| MPREFIX64 |v4 address|
+-----------------------------------------------------+----------+
Figure 3: MPREFIX64
6. Examples
To be added: encapsulation or and translation.
7. IANA Considerations
TBC.
8. Security Considerations
This document defined an address format to embed an IPv4 multicast
address in an IPv6 multicast address. The same security
considerations as those discussed in [RFC6052] are to be taken into
consideration.
9. Acknowledgements
TBC.
10. References
Boucadair, et al. Expires July 4, 2011 [Page 7]
Internet-Draft 64 Multicast Address Format December 2010
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6
Multicast Addresses", RFC 3306, August 2002.
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous
Point (RP) Address in an IPv6 Multicast Address",
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
IP", RFC 4607, August 2006.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
10.2. Informative References
[I-D.qin-softwire-dslite-multicast]
Wang, Q., Qin, J., Sun, P., Boucadair, M., and C.
Jacquenet, "Multicast Extensions to DS-Lite in Broadband
Deployments", draft-qin-softwire-dslite-multicast-01 (work
in progress), October 2010.
[I-D.venaas-behave-v4v6mc-framework]
Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6
Multicast Translation",
draft-venaas-behave-v4v6mc-framework-02 (work in
progress), December 2010.
[I-D.xu-softwire-mesh-multicast]
Xu, M., Cui, Y., Yang, S., Metz, C., and G. Shepherd,
"Softwire Mesh Multicast",
draft-xu-softwire-mesh-multicast-00 (work in progress),
October 2010.
Boucadair, et al. Expires July 4, 2011 [Page 8]
Internet-Draft 64 Multicast Address Format December 2010
Authors' Addresses
Mohamed Boucadair
France Telecom
Rennes, 35000
France
Email: mohamed.boucadair@orange-ftgroup.com
Jacni Qin
ZTE
Shanghai
China
Email: jacniq@gmail.com
Yiu L. Lee
Comcast
Email: yiu_lee@cable.comcast.com
URI: http://www.comcast.com
Boucadair, et al. Expires July 4, 2011 [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-24 04:48:31 |