Network Working Group B. Sarikaya Internet-Draft Huawei USA Intended status: Standards Track August 25, 2012 Expires: February 26, 2013 IPv6 RA Options for Translation Multicast Prefixes draft-sarikaya-softwire-6man-raoptions-00 Abstract This draft defines new Router Advertisement options for configuring multicast prefixes for IGMP to MLD translation and unicast prefixes for multicast source addresses. These prefixes are used in various translation multicast technologies. Each option is defined together with definitions of host and router behaviors. 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 February 26, 2013. Copyright Notice Copyright (c) 2012 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. Sarikaya Expires February 26, 2013 [Page 1] Internet-Draft New RA Options August 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Multicast Translation Prefixes Configuration . . . . . . . . . 3 4. Architectures of Usage . . . . . . . . . . . . . . . . . . . . 4 4.1. Stateful NAT64 . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Mapping of Address and Port and 4rd . . . . . . . . . . . 5 4.3. Other Cases . . . . . . . . . . . . . . . . . . . . . . . 6 5. Multicast Translation Prefix Options . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 9.1. Normative References . . . . . . . . . . . . . . . . . . . 10 9.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Sarikaya Expires February 26, 2013 [Page 2] Internet-Draft New RA Options August 2012 1. Introduction IPv6 Neighbor Discovery and IPv6 Stateless Address Autoconfiguration protocols can be used to configure fixed and mobile nodes with various parameters related to addressing and routing [RFC4861], [RFC4862], and [RFC4191]. DNS Recursive Server Addresses and Domain Name Search Lists are additional parameters that can be configured using router advertisements [RFC6106]. In some unicast IPv4 to IPv6 transition technologies, IPv4 to IPv6 translation is used such as NAT64 [RFC6145], Mapping of Address and Port Translation mode, or MAP-T [I-D.ietf-softwire-map], and to some extend in IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd) [I-D.ietf-softwire-4rd]. Translation multicast technologies are emerging aimed to complement these unicast solutions for multicast IPv4 to IPv6 transition. In IPv4 to IPv6 translation multicast, specific IPv6 addresses are used in which IPv4 addresses are embedded [RFC6180]. Some of these addresses are multicast IPv6 addresses and some are unicast. Both multicast and unicast addresses can be generated from the corresponding multicast and unicast prefixes. These prefixes must be provisioned on the hosts that are involved in translation. 2. Terminology 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 [RFC2119]. 3. Multicast Translation Prefixes Configuration A host wishing to join a source-specific multicast (SSM) group sends an IGMP Membership Report message and includes the group address in Multicast Address field of Group Record field in IPv4 [RFC3376]. Multicast group address MUST be a multicast group address in SSM range. In the IPv4 to IPv6 transition scenarios that are based on translation multicast, IGMP Membership Report message must be translated into MLD Membership Report message [RFC3810], usually at the IGMP/MLD proxy entity [RFC4605]. SSM group is identified with a group and source address in (S,G) form. The source address is specified in Source Address field of Group Record field in IGMP Membership Report message. There could be more than one source addresses associated with one Multicast Address. IGMP to MLD translation entity must be configured with an IPv6 Sarikaya Expires February 26, 2013 [Page 3] Internet-Draft New RA Options August 2012 multicast group prefix that is in SSM range. [I-D.ietf-mboned-64-multicast-address-format] defines multicast prefixes (MPREFIX64) for IPv4-embedded IPv6 multicast address based on an IPv4 multicast address of two types: ASM_MPREFIX64 for any- source multicast (ASM) and SSM_MPREFIX64 for source-specific multicast (SSM). IGMP to MLD translation entity can be configured with SSM_MPREFIX64 by its default router if the default router includes in its Router Advertisements a Multicast SSM Translation Prefix option defined in Figure 1. SSM_MPREFIX64 is of type ff3x:0:8000/96. Prefix length MAY be set to 96. x stands for the scope bits [RFC3306]. IGMP to MLD translation entity can be configured with ASM_MPREFIX64 by its default router if the default router includes in its Router Advertisements a Multicast ASM Translation Prefix option defined in Figure 2. ASM_MPREFIX64 is of type ffxx:8000::/20. Prefix length MAY be set to 20. The first x stands for the flags and the second x stands for the scope bits [RFC3306]. SSM groups have one or more sources, S in (S,G). The source address is specified by the joining host in IGMP Membership Report message's Source Address field of Group Record. IPv4 source address in IGMP Membership Report message needs to be translated into an IPv6 source address in the translated MLD message. IGMP to MLD translation entity can be configured with U_PREFIX64 by its default router if the default router includes in its Router Advertisements a Multicast Translation Unicast Prefix option defined in Figure 3. U_PREFIX64 could be assigned to 64:ff9b::/96 which is known as the well-known prefix or to some operator specific value. Prefix length MAY be set to 96. IPv4-Embedded IPv6 Unicast Addresses MUST be formed using the rules defined in [RFC6052]. U_PREFIX64 MUST also be used in translating IPv4 multicast data packets from SSM sources, S of (S,G) into IPv6 multicast data packets. In this case the translation entity is connected to IPv4 network at the border of an IPv6 network, e.g. Border Router (BR). Border Router MUST also be configured with U_PREFIX64 by its default router. The default router includes in its Router Advertisements a Multicast Translation Unicast Prefix option defined in Figure 3. 4. Architectures of Usage Sarikaya Expires February 26, 2013 [Page 4] Internet-Draft New RA Options August 2012 4.1. Stateful NAT64 In NAT64 [RFC6145], IGMP to MLD translation entity is the host. The default router of the host MUST be configured to send SSM_PREFIX64 and ASM_PREFIX64 in its router advertisements. In some configurations NAT64 box could be the default router then NAT64 box MUST be configured to send these RAs. This includes the case where NAT64 is located in Broadband Network Gateway (BNG) in broadband networks and Packet Data Network Gateway (PDN Gateway) in LTE networks. The hosts will receive the RAs Multicast ASM Translation Prefix option and Multicast SSM Translation Prefix option and use the prefix (SSM_PREFIX64 or ASM_PREFIX64) in translating IGMP messages to MLD messages and vice versa. In NAT64, Border Router which receives IPv4 multicast data is NAT64 box. The default router of NAT64 box MUST be configured to send Multicast Translation Unicast Prefix option in its router advertisements. This will configure NAT64 box with U_PREFIX64. NAT64 box can use this to translate IPv4 multicast data coming from SSM sources to IPv6 multicast data. In case SSM is supported, the default router for the hosts MUST be configured to send Multicast Translation Unicast Prefix option in its router advertisements. The hosts can use U_PREFIX64 in translating IGMPv3 messages to MLDv2 messages and in translating IPv6 multicast data to IPv4 multicast data. 4.2. Mapping of Address and Port and 4rd In MAP/4rd [I-D.ietf-softwire-map], [I-D.ietf-softwire-4rd], IGMP to MLD translation entity is the Customer Edge (CE). The default router of CE MUST be configured to send SSM_PREFIX64 and ASM_PREFIX64 in its router advertisements. The CEs will receive the RAs with Multicast ASM Translation Prefix option and Multicast SSM Translation Prefix option and use the prefix (SSM_PREFIX64 or ASM_PREFIX64) in translating IGMP messages to MLD messages and vice versa. In MAP/4rd, the router which receives IPv4 multicast data is the Border Router (BR) box. The default router of BR box MUST be configured to send Multicast Translation Unicast Prefix option in its router advertisements. This will configure BR with U_PREFIX64. BR can use this to translate IPv4 multicast data coming from SSM sources to IPv6 multicast data. Sarikaya Expires February 26, 2013 [Page 5] Internet-Draft New RA Options August 2012 In case SSM is supported, the default router for the CE MUST be configured to send Multicast Translation Unicast Prefix option in its router advertisements. The CE can use U_PREFIX64 in translating IGMPv3 messages to MLDv2 messages and in translating IPv6 multicast data to IPv4 multicast data. 4.3. Other Cases TBD. 5. Multicast Translation Prefix Options In this section we define three prefix options that are related to the translation of IGMP messages into MLD or vice versa. Figure 1 defines Source Specific Multicast translation prefix option commonly known as SSM_PREFIX64. It is an IPv6 prefix belonging to source specific multicast (ssm) range with a value similar to ff3x:0: 8000/33. It is used in embedding IPv4 SSM range multicast addresses. The values MUST conform to [I-D.ietf-mboned-64-multicast-address-format]. Figure 2 defines Any Source Multicast translation prefix option commonly known as ASM_PREFIX64. It is an IPv6 prefix belonging to any source multicast (asm) range with a value similar to ffxx: 8000/17. It is used in embedding IPv4 ASM range multicast addresses. The values MUST conform to [I-D.ietf-mboned-64-multicast-address-format] Figure 3 defines Multicast Translation Unicast prefix option commonly known as U_PREFIX64. It is an IPv6 unicast prefix It is used in translating IPv4 source addresses into IPv6 source address or vice versa for source specific multicast sources. [RFC6052] defines two types for U_PREFIX_64, well known prefix of 64:ff9b::/96 or the network specific prefix and the mapping rules from IPv4 to IPv6 address and vice versa. Sarikaya Expires February 26, 2013 [Page 6] Internet-Draft New RA Options August 2012 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Prefix Length | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SSM_MPREFIX64 Prefix | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Multicast SSM Translation Prefix option Fields: Type: TBD. Length: The length of the option (including the type and length fields) in units of 8 octets. For example, the length for an IPv6 address is 3. Prefix Length: 8-bit unsigned integer. The number of leading bits in the Prefix that are valid. The value ranges from 0 to 128. Reserved1 8-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Reserved2 32-bit unused field. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. Prefix: A prefix of type source specific multicast. The Prefix Length field contains the number of valid leading bits in the prefix. The bits in the prefix after the prefix length are reserved and MUST be initialized to zero by the sender and ignored by the receiver. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Prefix Length | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ASM_MPREFIX64 Prefix | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sarikaya Expires February 26, 2013 [Page 7] Internet-Draft New RA Options August 2012 Figure 2: Multicast ASM Translation Prefix option Fields: Type: TBD. Length and other fields are as defined above. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |Prefix Length | Reserved1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | U_PREFIX64 Prefix | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Multicast Translation Unicast Prefix option Fields: Type: TBD. Length and other fields are as defined above. 6. Security Considerations Neighbor Discovery is subject to attacks that cause IP packets to flow to unexpected places. Because of this, neighbor discovery messages MUST be secured, possibly using Secure Neighbor Discovery (SEND) protocol [RFC3971]. 7. IANA Considerations Authors of this document request IANA to assign three new RA options: Sarikaya Expires February 26, 2013 [Page 8] Internet-Draft New RA Options August 2012 +---------------------------------------------+------+ | Option Name | Type | +---------------------------------------------+------+ | Multicast SSM Translation Prefix option | | | Multicast ASM Translation Prefix option | | | Multicast Translation Unicast Prefix option | | +---------------------------------------------+------+ Table 1: 8. Acknowledgements TBD. Sarikaya Expires February 26, 2013 [Page 9] Internet-Draft New RA Options August 2012 9. References 9.1. Normative References [I-D.ietf-mboned-64-multicast-address-format] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, "IPv6 Multicast Address With Embedded IPv4 Multicast Address", draft-ietf-mboned-64-multicast-address-format-04 (work in progress), August 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [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. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005. [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. Sarikaya Expires February 26, 2013 [Page 10] Internet-Draft New RA Options August 2012 9.2. Informative References [I-D.ietf-softwire-4rd] Despres, R., Penno, R., Lee, Y., Chen, G., Jiang, S., and M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd)", draft-ietf-softwire-4rd-03 (work in progress), July 2012. [I-D.ietf-softwire-map] Troan, O., Dec, W., Li, X., Bao, C., Zhai, Y., Matsushima, S., and T. Murakami, "Mapping of Address and Port (MAP)", draft-ietf-softwire-map-01 (work in progress), June 2012. [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [RFC6180] Arkko, J. and F. Baker, "Guidelines for Using IPv6 Transition Mechanisms during IPv6 Deployment", RFC 6180, May 2011. Sarikaya Expires February 26, 2013 [Page 11] Internet-Draft New RA Options August 2012 Author's Address Behcet Sarikaya Huawei USA Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Sarikaya Expires February 26, 2013 [Page 12]