MBONED Working Group N. Kumar Internet Draft S. Venaas Intended status: Standard Cisco Systems, Inc Expires: December 2012 June 28, 2012 PIM/MLD flags for IPv4-IPv6 Multicast Translation Procedure draft-kumar-mboned-64mcast-embedded-address-00.txt 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), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on December 28, 2012. 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 Kumar & Venaas Expires December 28, 2012 [Page 1] Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation Procedure June 2012 Provisions and are provided without warranty as described in the Simplified BSD License. Abstract This document discusses the procedure that helps to identify IPv4 embedded IPv6 Multicast address without any embedded flags in the address. This document specifies the usage of additional data or attribute in MLD and PIM that helps identify this address. This document is not conclusive and is open for discussion. Table of Contents 1. Introduction...................................................2 2. Conventions used in this document..............................3 3. Terminology....................................................4 4. Procedure......................................................4 4.1. 64I Join Attribute........................................5 4.2. 64I Auxiliary Data........................................5 5. Use Cases......................................................6 5.1. IPv4 Receiver and Source connected over IPv6-Only network........................................................6 5.2. IPv6 Receiver Connected to IPv4 Source through IPv4 multicast access network and IPv6 Multicast network............7 5.3. IPv6 Receiver and IPv4 Source.............................9 6. Security Considerations.......................................10 7. IANA Considerations...........................................10 8. References....................................................10 8.1. Normative References.....................................10 8.2. Informative References...................................10 9. Acknowledgments...............................................11 1. Introduction As part of IPv4 to IPv6 migration, there are multiple standards developed for smooth transition for Unicast. Section 3 of [I-D.ietf-mboned-v4v6-mcast-ps] specifies Kumar & Venaas Expires December 28, 2012 [Page 2] Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation Procedure June 2012 different possible scenarios for IPv4 to IPv6 multicast transition as below, 1. IPv4 Receiver and Source connected over IPv6-Only network 2. IPv6 Receiver Connected to IPv4 Source through IPv4 multicast access network and IPv6 Multicast network. 3. IPv6 Receiver and Source connected to IPv4-Only network. 4. IPv6 Receiver and IPv4 Source. 5. IPv4 Receiver and IPv6 Source. Section 3.6 of [I-D.ietf-mboned-v4v6-mcast-ps] identifies the use cases involving IPv4 source as highest priority. There are also various solutions proposed (ex., [I-D.ietf- softwire-mesh-multicast], [I-D.ietf-softwire-dslite- multicast]) addressing the above use cases requirement which requires to embed IPv4 multicast address into IPv6 address. This IPv4-embedded IPv6 multicast address will be used as group address within IPv6 cloud. Currently [I-D.ietf-mboned-64-multicast-address-format] defines a new bit in IPv6 Multicast address that signals any router that Ipv4 Multicast address is embedded as last 32 bits. This may create backward compatibility issue. This document defines a set of procedures, a new PIM join attribute [RFC 5384] and a new MLD Auxiliary Data that helps achieve the above without a need for any bit embedded within IPv6 Multicast address. 2. Conventions used in this document 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]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. Kumar & Venaas Expires December 28, 2012 [Page 3] Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation Procedure June 2012 3. Terminology (S4, G4)/(*, G4): (S, G) or (*, G) in IPv4 address format (S6, G6)/(*, G6): (S, G) or (*, G) in IPv6 address format 4. Procedure Any AFBR on receiving (S4, G4) or (*, G4) PIM join or IGMP Report message and if the S6 after translation is not IPv4 translatable address and if the upstream is IPv6 PIM neighbor MUST include transitive 64I JOIN ATTRIBUTE (Section 4.1) in IPv6 PIM Join and embed IPv4 group address in last 32 bits of IPv6 Multicast SSM range address. Any AFBR on receiving (S4, G4) or (*, G4) PIM join or IGMP Report message and if the S6 after translation is IPv4 translatable address and if the upstream is IPv6 PIM neighbor SHOULD include transitive 64I JOIN ATTRIBUTE in IPv6 PIM Join and embed IPv4 group address in last 32 bits of IPv6 Multicast SSM range address. Any AFBR on receiving (S4, G4) or (*, G4) PIM Join or IGMP Report message and if S6 after translation is not IPv4 translatable address and if upstream is IPv6 cloud without PIM neighbor MUST include 64I Auxiliary Data (Section 4.2) in MLDv2 Report Message. Any AFBR on receiving (S4, G4) or (*, G4) PIM Join or IGMP Report message and if S6 after translation is IPv4 translatable address and if upstream is IPv6 cloud without PIM neighbor SHOULD include 64I Auxillary Data in MLDv2 Report Message. Any AFBR on receiving IPv4 PIM Join with 64I JOIN ATTRIBUTE MUST carry forward the attribute in IPv6 PIM Join sent upstream. Any router on receiving IPv6 PIM Join with 64I JOIN ATTRIBUTE and if upstream is IPv6 cloud without PIM neighbor MUST include 64I Auxillary Data in MLDv2 Report message. Any AFBR on receiving (S6, G6) PIM Join for SSM range address without 64I JOIN ATTRIBUTE and if the IPv6 Source in Join is well known prefix (64:FF9B::/96) or IPv4 translatable IPv6 Kumar & Venaas Expires December 28, 2012 [Page 4] Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation Procedure June 2012 address [RFC 6052] and if the upstream is IPv4 PIM neighbor, MUST pull the last 32 bits to generate IPv4 group address. Any router on receiving (S6, G6) PIM Join from SSM range without 64I JOIN ATTRIBUTE and if Source address is well known prefix (64:FF9B::/96) or IPv4 translatable IPv6 address [RFC 6052] and if the upstream is IPv6 PIM neighbor, MUST include 64I JOIN ATTRIBUTE. Any router on receiving MLD Report with 64I Auxiliary Data MUST include 64I JOIN ATTRIBUTE in IPv6 PIM join sent Upstream for the group. While the above procedure is defined with SSM range address as an example, it is applicable for any (S6, G6) from ASM range. 4.1. 64I Join Attribute Below is the format of new PIM JOIN ATTRIBUTE specified in this document, 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |F|E| Attr Type | Length |T| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ F bit: 1, Transitive Attribute E bit: As mentioned in [RFC 5384] Attr Type: TBD Length: 2 T bit: 1 Reserved: Reserved field for future use. 4.2. 64I Auxiliary Data Below is the format of new Auxiliary Data specified in this document, Kumar & Venaas Expires December 28, 2012 [Page 5] Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation Procedure June 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 |T| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD Length: T Flag: 1 Reserved: Reserved bit for future use. 5. Use Cases In this document, we also specify the behavior of high priority scenarios with above procedure. 5.1. IPv4 Receiver and Source connected over IPv6-Only network This scenario simply known as 4-6-4 is shown below in Figure 1. +--------+ +--------+ | Host | | IPv4 | | Rcvr | | DR | | | | | +--------+ +--------+ | | IGMP/IPv4 PIM IGMP/IPv4 PIM | | | | +--------+ +--------+ +--------+ | | MLD | IPv6 | IPv6 | | | AFBR1 |----------| Only |----------| AFBR2 | | | IPv6 PIM | Rtr | PIM | | +--------+ +--------+ +--------+ Figure 1: 4-6-4 Scenario Kumar & Venaas Expires December 28, 2012 [Page 6] Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation Procedure June 2012 AFBR1 on receiving (S4, G4) or (*, G4) PIM Join or IGMP Report will perform the below, 1. If Upstream is IPv6 PIM neighbor, should embed the IPv4 multicast group into last 32 bits of IPv6 Multicast SSM range address and send (S6, G6) PIM join with 64I JOIN ATTRIBUTE. 2. If Upstream is IPv6 MLD router, should embed the IPv4 multicast group into last 32 bits of IPv6 Multicast SSM range address and send MLDv2 Report with 64I Auxillary Data. AFBR2 on receiving (S6, G6) PIM Join without 64I JOIN ATTRIBUTE and if upstream is IPv4 cloud can derive the IPv4 multicast group address from last 32 bits. Since F bit will be set in 64I JOIN ATTRIBUTE, it will be delivered to AFBR2 even if any router along the path doesn't understand the attribute. IPv6-only Rtr on receiving (S6, G6) PIM Join with 64I JOIN ATTRIBUTE will send across to AFBR2 with attribute. Since 64I JOIN ATTRIBUTE is transitive in nature, this behavior doesn't change even if IPv6-Only Rtr doesn't understand the attribute. IPv6-only Rtr on receiving (S6, G6) MLD Report with 64I Auxiliary Data will include 64I JOIN ATTRIBUTE in upstream PIM join for (S6, G6). AFBR2 on receiving (S6, G6) PIM Join with 64I JOIN ATTRIBUTE must derive the IPv4 multicast group address from the last 32 bits. 5.2. IPv6 Receiver Connected to IPv4 Source through IPv4 multicast access network and IPv6 Multicast network Kumar & Venaas Expires December 28, 2012 [Page 7] Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation Procedure June 2012 This scenario simply known as 6-4-6-4 is shown in Figure 2. +--------+ | Host | | Rcvr | | | +--------+ | MLD/IPv6 PIM | | +--------+ +--------+ +--------+ | | IGMP | IPv4 | IPv4 | | | AFBR1 |----------| Only |----------| AFBR2 | | | IPv4 PIM | NW | PIM | | +--------+ +--------+ +--------+ | MLD/IPv6 PIM | | +--------+ +--------+ +--------+ | IPv4 | IGMP | | IPv6 | IPv6 | | DR |----------| AFBR3 |----------| Only | | | IPv4 PIM | | PIM | NW | +--------+ +--------+ +--------+ Figure 2: 6-4-6-4 Scenario In Figure 2, AFBR3 will act as IP/ICMP translator and will advertise IPv4 prefixes into IPv6 cloud as either well known prefix (64:FF9B::/96) or IPv4 translatable IPv6 prefix. In this scenario, AFBR1 or the DR router MUST include 64I JOIN ATTRIBUTE or 64I Auxiliary Data if the source is well known prefix (64:FF9B::/96). AFBR1 or the DR router SHOULD include 64I JOIN ATTRIBUTE or 64I Auxiliary Data if the source is with IPv4 translatable IPv6 prefix. How AFBR1/DR will understand if S6 belongs to IPv4 translatable IPv6 prefix is outside the scope of this document. Various solutions are available by which AFBR1 will send the join towards AFBR2. This basically depends if multicast is enabled or disabled on IPv4 cloud. Depending on the solution, Kumar & Venaas Expires December 28, 2012 [Page 8] Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation Procedure June 2012 AFBR1 will either send IPv6 PIM Join encapsulated within IPv4 PIM join or IPv6 PIM Join over some tunnel. AFBR2 on receiving (S6, G6) PIM Join over tunnel or (S6, G6) PIM Join encapsulated within (S4, G4) will send 64I JOIN ATTRIBUTE or 64I Auxiliary Data upstreams towards AFBR3. AFBR3 on receiving (S6, G6) Join with 64I JOIN ATTRIBUTE MUST derive the IPv4 group address from last 32 bits. AFBR3 on receiving (S6, G6) PIM join without 64I JOIN ATTRIBUTE MUST check if S6 falls within well known prefix (64:FF9B::/96) or IPv4 translatable IPv6 Prefix. If S6 is within the above range, it MUST derive IPv4 group from the last 32 bits of G6. 5.3. IPv6 Receiver and IPv4 Source +--------+ | Host | | Rcvr | | | +--------+ | MLD/IPv6 PIM | | +--------+ +--------+ +--------+ | | IPv6 | IPv6 | IPv6 | | | DR1 |----------| Only |----------| AFBR1 | | | PIM | NW | PIM | | +--------+ +--------+ +--------+ | IGMP/IPv4 PIM | | +--------+ | | | DR2 | | | +--------+ Figure 3: 6-4 Scenario Kumar & Venaas Expires December 28, 2012 [Page 9] Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation Procedure June 2012 This scenario works similar to Section 5.2 except that IPv6 cloud is not partitioned by IPv4 cloud. 6. Security Considerations Security consideration specified in [RFC 5384] and [RFC 6052] are applicable here as well. 7. IANA Considerations TBD. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 5234] Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 5234, January 2008. 8.2. Informative References [I-D.ietf-mboned-v4v6-mcast-ps] Jacquenet, C., Boucadair, M., Lee, Y., Qin, J., Tsou, T., and Q. Sun, "IPv4-IPv6 Multicast: Problem Statement and Use Cases", draft-ietf-mboned-v4v6- mcast-ps-00 (work in progress), May 2012. [I-D.ietf-mboned-64-multicast-address-format] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X. and Xu, M, "IPv4-Embedded IPv6 Multicast Address Format", draft-ietf-mboned-64-multicast- address-format-02 (work in progress), February Kumar & Venaas Expires December 28, 2012 [Page 10] Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation Procedure June 2012 2012. [I-D.ietf-softwire-dslite-multicast] Qin, J., Boucadair, M., Jacquenet, C., Lee, Y., and Q. Wang, "Multicast Extension to DS-Lite Technique in Broadband Deployments", Draft-ietf-softwire-dslite-multicast-02 (work in progress), May 2012. [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-02 (work in progress), April 2012. [RFC 5384] Boers, A., Wijnands, I. and Rosen, E., "The Protocol Independent Multicast (PIM) Join Attribute Format", RFC 5384, Nov 2008. [RFC 4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC 4607] Holbrook, H. and B. Cain "Source-Specific Multicast for IP", RFC 4607, August 2006. [RFC 6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. 9. Acknowledgments This document was prepared using 2-Word-v2.0.template.dot. Authors' Addresses Stig Venaas Cisco Systems, Inc. Tasman Drive San Jose, CA 95134 USA Email: stig@cisco.com Kumar & Venaas Expires December 28, 2012 [Page 11] Internet-DraftPIM/MLD flags for IPv4-IPv6 Multicast Translation Procedure June 2012 Nagendra Kumar Cisco Systems Cessna Business Park, Sarjapura Marathalli Outer Ring Road Bangalore, KARNATAKA 560 087 India Email: naikumar@cisco.com Kumar & Venaas Expires December 28, 2012 [Page 12]