Internet Engineering Task Force T. Taylor Internet-Draft C. Zhou Intended status: Informational Huawei Technologies Expires: June 23, 2012 December 21, 2011 Specification of an Adaptation Function Between Two Multicast Networks Supporting Different IP Versions draft-taylor-multrans-af2-specification-00 Abstract In some transitional multicast scenarios, the multicast signalling and content have to pass across network boundaries where one network supports IPv4, the other, IPv6. An adaptation function is required at the boundary to support such a scenario. This memo uses the term "Type 2 Adaptation Function" (AF2) for such a function. 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 June 23, 2012. 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 Taylor & Zhou Expires June 23, 2012 [Page 1] Internet-Draft Multicast AF2 Specification December 2011 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Signalling Operation . . . . . . . . . . . . . . . . . . . . . 3 3. Handling of Multicast Data Packets . . . . . . . . . . . . . . 3 4. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 9. Informative References . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 Taylor & Zhou Expires June 23, 2012 [Page 2] Internet-Draft Multicast AF2 Specification December 2011 1. Introduction Consider a multicast scenarion where the multicast source is served by a different network from the multicast receiver, so that two or more networks separate them. Now suppose that at some point along the path between, one network supports IPv4 while the other supports IPv6. Obviously, one network or the other needs to have a dual stack border router to make this work. This router needs to support additional functionality to provide continuity for PIM [RFC4601] operation across the boundary and to forward the packets of multicast content with appropriate source and destination addresses. This memo uses the term "Type 2 Adaptation Function" (AF2) for such functionality. 1.1. Requirements Language This document contains no requirements language. 2. Signalling Operation Processing of PIM messages across the AF2 is fairly straightforward. The AF2 examines each PIM message crossing the IP version boundary for contained addresses. Each address is remapped to a corresponding address in the IP version that is supported by the network it is entering. For the cases of immediate interest, it is likely that a stateless mapping can be used, for example, [I-D_boucadair-stateless-multicast] for the multicast group addresses and [RFC6052] for source addresses. Once the addresses are remapped and the messages reencoded, the messages are forwarded into the receiving network. Note that the PIM Hello message, which optionally contains a secondary address list ([RFC4601] section 4.3.4), does not technically cross the IP version boundary and therefore needs no remapping, since it is a single-hop message between interfaces sharing the same link. 3. Handling of Multicast Data Packets The AF2 either encapsulates or translates the headers of incoming multicast data packets before forwarding them across the IP version boundary. In either case, the source and group addresses are remapped to the other IP version. In the encapsulation case the remapped addresses are used as the source and destination addresses in the outer IP header. In the translation case they are used as the source and destination addresses in the translated header. The Taylor & Zhou Expires June 23, 2012 [Page 3] Internet-Draft Multicast AF2 Specification December 2011 mapping used is the inverse of the one used to modify the PIM messages forwarded in the opposite direction. That is, if a given address A in an incoming PIM message was mapped to A' in it outgoing counterpart, then the address A' appearing in the header of an incoming multicast data packet is mapped to A. This ensures that incoming data packets follow the multicast tree that PIM has set up for them in the downstream network. The choice of encapsulation versus translation is a complex topic. Some relevant discussion appears in a companion draft, [I-D_tsou-AF1-specification]. The key issues are that encapsulation requires administrative coordination to ensure that the necessary decapsulation function is available downstream, and that the evolution to pure IPv6 is awkward. It seems best to make header translation the default, with encapsulation a configurable option. 4. Open Issues The description given above is sufficent if only two networks separate the source from the receiver. However, if transit networks are involved, avoidance of routing loops becomes a concern. If a transit network (possibly also with directly attached receivers) receives a PIM request, the underlying routing tables that each multicast router uses to achieve reverse path forwarding have to be consistent with the ultimate source. The question of how to ensure that becomes a concern. Fundamentally, the addresses used to designate a given multicast flow in a given network have to provide the information needed to route the PIM Join requests to the right AF2 instance and provide the right remapping across the AF2. This information can be obtained through administrative coordination, or can somehow be contained in the addresses themselves. One case where the latter holds is if the source is IPv4 and every intervening IPv6 network uses an IPv4- embedded mapping such as the one defined by [I-D_boucadair-stateless-multicast]. Intervening IPv4 networks would use the native source network addresses. It does not matter if each IPv6 network remaps to use its own IPv6 prefix, since the source network addresses are always preserved intact. 5. Acknowledgements TBD. Taylor & Zhou Expires June 23, 2012 [Page 4] Internet-Draft Multicast AF2 Specification December 2011 6. Contributors Tina Tsou provided the framework within which these ideas were developed. 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations To come. 9. Informative References [I-D_boucadair-stateless-multicast] Boucadair, M., Qin, J., Lee, Y., Venaas, S., Li, X., and M. Xu, "IPv4-Embedded IPv6 Multicast Address Format (Work in progress)", October 2011. [I-D_tsou-AF1-specification] Zhou, C. and T. Taylor, "Specification of a Provider- Managed Adaptive Function Between a Multicast Receiver and a Provider Network Supporting a Different IP Version (Work in progress)", December 2011. [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. Authors' Addresses Tom Taylor Huawei Technologies 1852 Lorraine Ave. Ottawa, Ontario K1H 6Z8 Canada Email: tom.taylor.stds@gmail.com Taylor & Zhou Expires June 23, 2012 [Page 5] Internet-Draft Multicast AF2 Specification December 2011 Cathy Zhou Huawei Technologies Bantian, Longgang District Shenzhen 518129 P.R. China Phone: Email: cathy.zhou@huawei.com Taylor & Zhou Expires June 23, 2012 [Page 6]