BEHAVE WG M. Boucadair Internet-Draft France Telecom Updates: 4291, 6052 J. Qin (if approved) ZTE Intended status: Standards Track Y. Lee Expires: August 13, 2011 Comcast S. Venaas Cisco Systems X. Li CERNET Center/Tsinghua University M. Xu Tsinghua University February 09, 2011 IPv4-Embedded IPv6 Multicast Address Format draft-boucadair-behave-64-multicast-address-format-01 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 August 13, 2011. Boucadair, et al. Expires August 13, 2011 [Page 1] Internet-Draft 64 Multicast Address Format February 2011 Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. 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. Why an Address Format is Needed for Multicast IPv4-IPv6 Interconnection? . . . . . . . . . . . . . . . . . . . . . . . 4 5. Why Identifying an IPv4-Embedded IPv6 Multicast Address is Required? . . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Location of the IPv4 Address . . . . . . . . . . . . . . . 6 6.2. Location of the M-bit . . . . . . . . . . . . . . . . . . 6 6.3. Encapsulation vs. Translation . . . . . . . . . . . . . . 8 7. IPv4-Embedded IPv6 Multicast Address Format: ASM Mode . . . . 8 8. IPv4-Embedded IPv6 Multicast Address Format: SSM Mode . . . . 9 9. Textual Representation . . . . . . . . . . . . . . . . . . . . 10 10. Multicast PREFIX64 . . . . . . . . . . . . . . . . . . . . . . 10 11. Source IPv4 Address in the IPv6 Ream . . . . . . . . . . . . . 11 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 14. Security Considerations . . . . . . . . . . . . . . . . . . . 11 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 16.1. Normative References . . . . . . . . . . . . . . . . . . . 12 16.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Boucadair, et al. Expires August 13, 2011 [Page 2] Internet-Draft 64 Multicast Address Format February 2011 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 rendezvous point [RFC3956]. This document updates [RFC6052] which focuses exclusively on IPv4- embedded 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-embedded 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-embedded IPv6 multicast address: denotes a multicast IPv6 address which includes in 32 bits an IPv4 address. Two types of IPv6 addresses are defined that carry an IPv4 address in the low- order 32 bits of the address. The format to build such addresses is defined in Section 7 for ASM mode and Section 8 for SSM mode. 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. 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] Boucadair, et al. Expires August 13, 2011 [Page 3] Internet-Draft 64 Multicast Address Format February 2011 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 multicast prefix to be used to construct IPv4-embedded IPv6 multicast addresses. o ASM_MPREFIX64: denotes a multicast Prefix64 used in 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 Boucadair, et al. Expires August 13, 2011 [Page 4] Internet-Draft 64 Multicast Address Format February 2011 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 Boucadair, et al. Expires August 13, 2011 [Page 5] Internet-Draft 64 Multicast Address Format February 2011 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.korhonen-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]: Boucadair, et al. Expires August 13, 2011 [Page 6] Internet-Draft 64 Multicast Address Format February 2011 | 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; Boucadair, et al. Expires August 13, 2011 [Page 7] Internet-Draft 64 Multicast Address Format February 2011 (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 format is defined to enclose an IPv4 multicast address 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|r|r|r| +-+-+-+-+ Figure 2: 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 M-bit. When "M-bit" is set to 1, it indicates that an multicast Boucadair, et al. Expires August 13, 2011 [Page 8] Internet-Draft 64 Multicast Address Format February 2011 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 of the entity managing the IPv4-IPv6 Interconnection Function. This field must follow the recommendations specified in [RFC3306] if If unicast-based prefix is used or the recommendations specified in [RFC3306] 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. [[DISCUSSION NOTE: Restrict an IPv6 ASM address to embed only an ASM IPv4 address or relax it?]] 8. IPv4-Embedded IPv6 Multicast Address Format: 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 of the IPv6 multicast address to be used to enclose an IPv4 multicast address. | 8 | 4 | 4 | 16 | 4 | 60 | 32 | +--------+----+----+-----------+----+------------------+----------+ |11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address| +--------+----+----+-----------+----+------------------+----------+ +-+-+-+-+ IPv4-IPv6 Interconnection bits (64IX): |M|r|r|r| +-+-+-+-+ Figure 3: IPv4-Embedded IPv6 Multicast Address Format: SSM Mode The description of the fields is as follows: o Flags must be set to 0011. o "scop" is defined in [RFC4291]. o 64IX field (IPv4-IPv6 interconnection bits): Same meaning as Section 7. o sub-group-id: The default value is all zeros. Boucadair, et al. Expires August 13, 2011 [Page 9] Internet-Draft 64 Multicast Address Format February 2011 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]. 232.0.0.1-232.0.0.255 range is being reserved to IANA. [[DISCUSSION NOTE: Restrict an IPv6 SSM address to embed only an SSM IPv4 address?]] 9. Textual Representation The embedded IPv4 address in an IPv6 multicast address is included in the last 32 bits; therefore dotted decimal notation can be used. 10. 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. When both modes are used, two prefixes are required to be provisioned. The structure of the MPREFIX64 follows the guidelines specified in Section 7 for the ASM mode and Section 8 when SSM mode is used. MPREFIX64 MAY be of any length from /32 to /96; /96 being the RECOMMENDED prefix length as shown in Figure 4). The format of the MPREFIX64 should be compatible with what is specified in [RFC3306] and [RFC3956] if corresponding mechanisms are used. Boucadair, et al. Expires August 13, 2011 [Page 10] Internet-Draft 64 Multicast Address Format February 2011 ASM Mode: | 8 | 4 | 4 | 4 | 76 | 32 | +--------+----+----+----+------------------------------+----------+ |11111111|flgs|scop|64IX| sub-group-id |v4 address| +--------+----+----+----+------------------------------+----------+ | | | v v v +------------------------------------------------------+----------+ | ASM_MPREFIX64 |v4 address| +------------------------------------------------------+----------+ SSM Mode: | 8 | 4 | 4 | 16 | 4 | 60 | 32 | +--------+----+----+-----------+----+------------------+----------+ |11111111|0011|scop|00.......00|64IX| sub-group-id |v4 address| +--------+----+----+-----------+----+------------------+----------+ | | | v v v +------------------------------------------------------+----------+ | SSM_MPREFIX64 |v4 address| +------------------------------------------------------+----------+ Figure 4: MPREFIX64 11. Source IPv4 Address in the IPv6 Ream An IPv4 source is represented in the IPv6 realm with its IPv4- converted IPv6 address [RFC6052]. 12. Examples TBC. 13. IANA Considerations TBC. 14. Security Considerations This document defined an address format to embed an IPv4 multicast address in an IPv6 multicast address. The same security Boucadair, et al. Expires August 13, 2011 [Page 11] Internet-Draft 64 Multicast Address Format February 2011 considerations as those discussed in [RFC6052] are to be taken into consideration. 15. Acknowledgements Many thanks to B. Sarikaya and P. Savola for their comments. 16. References 16.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. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [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. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 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. Boucadair, et al. Expires August 13, 2011 [Page 12] Internet-Draft 64 Multicast Address Format February 2011 16.2. Informative References [I-D.boucadair-mmusic-altc] Boucadair, M., Kaplan, H., Gilman, R., and S. Veikkolainen, "Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute", draft-boucadair-mmusic-altc-01 (work in progress), September 2010. [I-D.korhonen-behave-nat64-learn-analysis] Korhonen, J. and T. Savolainen, "Analysis of solution proposals for hosts to learn NAT64 prefix", draft-korhonen-behave-nat64-learn-analysis-01 (work in progress), January 2011. [I-D.qin-softwire-dslite-multicast] Wang, Q., Qin, J., Sun, P., Boucadair, M., Jacquenet, C., and Y. Lee, "Multicast Extensions to DS-Lite Technique in Broadband Deployments", draft-qin-softwire-dslite-multicast-02 (work in progress), January 2011. [I-D.sarikaya-behave-mext-nat64-dsmip] Sarikaya, B. and F. Xia, "NAT64 for Dual Stack Mobile IPv6", draft-sarikaya-behave-mext-nat64-dsmip-02 (work in progress), January 2011. [I-D.sarikaya-behave-netext-nat64-pmip] Sarikaya, B. and F. Xia, "NAT64 for Proxy Mobile IPv6", draft-sarikaya-behave-netext-nat64-pmip-01 (work in progress), January 2011. [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 August 13, 2011 [Page 13] Internet-Draft 64 Multicast Address Format February 2011 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 Stig Venaas Cisco Systems Tasman Drive San Jose, CA 95134 USA Email: stig@cisco.com Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing, 100084 P.R. China Phone: +86 10-62785983 Fax: Email: xing@cernet.edu.cn URI: Boucadair, et al. Expires August 13, 2011 [Page 14] Internet-Draft 64 Multicast Address Format February 2011 Mingwei Xu Tsinghua University Department of Computer Science, Tsinghua University Beijing, 100084 P.R.China Phone: +86-10-6278-5822 Email: xmw@cernet.edu.cn Boucadair, et al. Expires August 13, 2011 [Page 15]