--- 1/draft-ietf-mboned-auto-multicast-09.txt 2010-03-08 06:11:04.000000000 +0100 +++ 2/draft-ietf-mboned-auto-multicast-10.txt 2010-03-08 06:11:04.000000000 +0100 @@ -1,59 +1,84 @@ Network Working Group D. Thaler Internet-Draft M. Talwar Intended status: Standards Track A. Aggarwal -Expires: December 29, 2008 Microsoft Corporation +Expires: September 8, 2010 Microsoft Corporation L. Vicisano - Cisco Systems + Qualcomm Inc. T. Pusateri !j - June 27, 2008 + March 7, 2010 Automatic IP Multicast Without Explicit Tunnels (AMT) - draft-ietf-mboned-auto-multicast-09 + draft-ietf-mboned-auto-multicast-10 + +Abstract + + Automatic Multicast Tunneling (AMT) allows multicast communication + amongst isolated multicast-enabled sites or hosts, attached to a + network which has no native multicast support. It also enables them + to exchange multicast traffic with the native multicast + infrastructure and does not require any manual configuration. AMT + uses an encapsulation interface so that no changes to a host stack or + applications are required, all protocols (not just UDP) are handled, + and there is no additional overhead in core routers. Status of this Memo - By submitting this Internet-Draft, each author represents that any - applicable patent or other IPR claims of which he or she is aware - have been or will be disclosed, and any of which he or she becomes - aware will be disclosed, in accordance with Section 6 of BCP 79. + This Internet-Draft is submitted to IETF 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 29, 2008. + This Internet-Draft will expire on September 8, 2010. -Abstract +Copyright Notice - Automatic Multicast Tunneling (AMT) allows multicast communication - amongst isolated multicast-enabled sites or hosts, attached to a - network which has no native multicast support. It also enables them - to exchange multicast traffic with the native multicast - infrastructure and does not require any manual configuration. AMT - uses an encapsulation interface so that no changes to a host stack or - applications are required, all protocols (not just UDP) are handled, - and there is no additional overhead in core routers. + Copyright (c) 2010 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 BSD License. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 7 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 8 4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 8 @@ -94,54 +119,61 @@ 6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 21 6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22 6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 22 6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 22 6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 22 6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 22 6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 23 6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 23 - 7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 24 - 7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 24 - 7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 24 - 7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 25 - 7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 26 - 7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 26 - 7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 27 - 7.6. Receiving AMT Membership Updates by the Gateway . . . . . 27 - 7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 27 - 8. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 28 - 8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 28 + 6.7. AMT Membership Teardown . . . . . . . . . . . . . . . . . 23 + 6.7.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 24 + 6.7.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 24 + 6.7.3. Original Response MAC . . . . . . . . . . . . . . . . 24 + 6.7.4. Original Request Nonce . . . . . . . . . . . . . . . . 24 + 6.7.5. Original Source Port . . . . . . . . . . . . . . . . . 24 + 6.7.6. Source AFI . . . . . . . . . . . . . . . . . . . . . . 24 + 6.7.7. Original Source Address . . . . . . . . . . . . . . . 25 + 6.7.8. IGMP/MLD Message (including IP Header) . . . . . . . . 25 + 7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 26 + 7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 26 + 7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 26 + 7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 28 + 7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 28 + 7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 29 + 7.6. Receiving AMT Membership Updates by the Gateway . . . . . 29 + 7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 29 + 8. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 30 + 8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 30 8.2. Receiving Relay Discovery messages sent to the Anycast - Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 - 8.3. Receiving Membership Updates from AMT Gateways . . . . . . 28 + Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 + 8.3. Receiving Membership Updates from AMT Gateways . . . . . . 30 8.4. Receiving (S,G) Joins from the Native Side, for AMT - Sources . . . . . . . . . . . . . . . . . . . . . . . . . 29 - 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 - 9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 30 - 9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation . . . . . . . . 30 - 9.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 9.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 9.3. UDP Port number . . . . . . . . . . . . . . . . . . . . . 30 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 - 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 - 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 - 13.2. Informative References . . . . . . . . . . . . . . . . . . 34 - - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 - Intellectual Property and Copyright Statements . . . . . . . . . . 38 + Sources . . . . . . . . . . . . . . . . . . . . . . . . . 31 + 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 + 9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 32 + 9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation . . . . . . . . 32 + 9.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 9.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32 + 9.3. UDP Port number . . . . . . . . . . . . . . . . . . . . . 32 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 + 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 + 13.1. Normative References . . . . . . . . . . . . . . . . . . . 36 + 13.2. Informative References . . . . . . . . . . . . . . . . . . 36 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 1. Introduction The primary goal of this document is to foster the deployment of native IP multicast by enabling a potentially large number of nodes to connect to the already present multicast infrastructure. Therefore, the techniques discussed here should be viewed as an interim solution to help in the various stages of the transition to a native multicast network. @@ -397,20 +429,30 @@ MAC matches the calculated MAC. The local secret never has to be shared with the other side. It is only used to verify return routability of the originator. Since the same Request Nonce and source IP address can be re-used, the receiver SHOULD change its secret key at least once per hour. However, AMT Membership updates received with the previous secret MUST be accepted for up to the IGMP/MLD Query Interval. + The condition might occur where the gateway or relay that initially + sent the AMT Request dynamically changes its IP address. This might + occur due to a change in wireless networks, a DHCP assignment, or + another network failure. When this occurs, it is no longer possible + to verify the MAC using the source address and source port. Though, + in order to reduce state, it is desirable to tear down the state that + was created with the old source address. A Teardown message with + special considerations for calculating the MAC is described below to + perform this function. + 5.1.3. Protocol Sequence for a Gateway Joining SSM Receivers to a Relay This description assumes the Gateway can be a host joining as a receiver or a network device acting as a Gateway when a directly connected host joins as a receiver. o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1). o Gateway receives report. If it has no tunnel state with a Relay, it originates an AMT Relay Discovery message addressed to the @@ -638,21 +680,21 @@ A 32-bit random value generated by the gateway and replayed by the relay. 6.2. AMT Relay Advertisement The AMT Relay Advertisement message is a UDP packet sent from the AMT relay anycast address to the source of the discovery message. The UDP source port is the IANA reserved AMT port number and the UDP destination port is the source port received in the Discovery - message. The UDP checksum MUST be valid in AMT control messages. + message. The UDP CHECKSUM MUST be valid in AMT control messages. The payload of the UDP packet contains the following fields. 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=0x2 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discovery Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -848,22 +890,22 @@ 6.6. AMT IP Multicast Data The AMT Data message is a UDP packet encapsulating the IP Multicast data requested by the originator based on a previous AMT Membership Update message. It is sent from the unicast destination address of the Membership update to the source address of the Membership Update. The UDP source and destination port numbers should be the same ones - sent in the original Query. The UDP checksum SHOULD be 0 in the AMT - IP Multicast Data message. + sent in the original Query. The UDP checksum MUST be valid in AMT + control messages. The payload of the UDP packet contains the following fields. 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=0x6 | Reserved | IP Multicast Data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -876,20 +918,113 @@ 6.6.2. Reserved An 8-bit reserved field. Sent as 0, ignored on receipt. 6.6.3. IP Multicast Data The original IP Multicast data packet that is being replicated by the relay to the gateways including the original IP header. +6.7. AMT Membership Teardown + + An AMT Membership Teardown is sent to report an IGMP Membership Leave + or MLD Listener Done after a valid Response MAC has been received and + after the source address that was used to generate the Response MAC + is no longer available for sourcing packets. + + An AMT Membership Teardown from the original source address and + source port is NOT valid and should be discarded if received. Use an + AMT Membership Update instead. + + An AMT Membership Teardown can only contain either an IGMP Membership + Leave or an MLD Listener Done message. The encapsulated IGMP/MLD + message will have to be fabricated by the sender of the AMT + Membership Teardown in the case where there wasn't an original IGMP/ + MLD message to be forwarded. + + In order for the receiver to verify the Membership Teardown message, + it must contain the original source address and source port in + addition to the Original Request Nonce and Original Response MAC. + + It is sent to the source address received in the original Query which + should be the same as the original Request. + + The UDP destination port number should be the same one sent in the + original Request. + + The relay is not required to use the IP source address of the IGMP + Membership Report for any particular purpose. + + 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=0x7 | Reserved | Original Response MAC | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Original Response MAC (continued) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Original Request Nonce | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Original Source Port | Source AFI | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Original Source Address | + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | IGMP Membership Leave or | + | MLD Listener Done (including IP header) | + | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + AMT Membership Teardown + +6.7.1. Type + + The type of the message. + +6.7.2. Reserved + + A 8-bit reserved field. Sent as 0, ignored on receipt. + +6.7.3. Original Response MAC + + The 48-bit MAC received in the Membership Query and echoed back in + the Membership Update. + +6.7.4. Original Request Nonce + + A 32-bit identifier used to distinguish this request. + +6.7.5. Original Source Port + + The 16-bit port number used in the original AMT Membership update + that was used to generate the Original Response MAC. + +6.7.6. Source AFI + + A 16-bit Address Family Identifier (AFI) [RFC4760] used to determine + the protocol address family of the following Original Source Address. + + Presently defined values for the Address Family Identifier field are + specified in IANA's Address Family Numbers registry [IANA.AFN] + +6.7.7. Original Source Address + + The source address used in the original AMT Membership update that + was used to generate the Original Response MAC. + +6.7.8. IGMP/MLD Message (including IP Header) + + The message contains either an IGMP Membership Leave or an MLD + Listener Done. The IGMP or MLD version sent should be in response + the version of the query received in the original AMT Membership + Query. The IGMP/MLD Message includes a full IP Header. + 7. AMT Gateway Details This section details the behavior of an AMT Gateway, which may be a router serving an AMT site, or the site may consist of a single host, serving as its own gateway. 7.1. At Startup Time At startup time, the AMT gateway will bring up an AMT pseudo- interface to be used for encapsulation. The gateway needs to @@ -1251,20 +1386,23 @@ connectivity without explicit tunnels ("6to4"). Tony Ballardie provided helpful discussion that inspired this document. In addition, extensive comments were received from Pekka Savola, Greg Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John Zwiebel, and Lenny Giuliano. Juniper Networks was instrumental in funding several versions of this draft as well as an open source implementation. + Greg Shepherd suggested the inclusion of the AMT Membership Teardown + message based on field experience. + 13. References 13.1. Normative References [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. @@ -1275,20 +1413,25 @@ [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. [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for IP", RFC 4607, August 2006. 13.2. Informative References + [IANA.AFN] + IANA, "Address Family Numbers", . + [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. @@ -1304,20 +1447,24 @@ [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 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. + [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, + "Multiprotocol Extensions for BGP-4", RFC 4760, + January 2007. + Authors' Addresses Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA Phone: +1 425 703 8835 Email: dthaler@microsoft.com @@ -1334,64 +1481,23 @@ Amit Aggarwal Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA Phone: +1 425 706 0593 Email: amitag@microsoft.com Lorenzo Vicisano - Cisco Systems - 170 West Tasman Dr. - San Jose, CA 95134 + Qualcomm Inc. + 3165 Kifer Road + Santa Clara, CA 95051 USA - Phone: +1 408 525 2530 - Email: lorenzo@cisco.com + Email: vicisano@qualcomm.com Tom Pusateri !j - 222 E. Jones Ave. + 2109 Mountain High Rd. Wake Forest, NC 27587 USA Email: pusateri@bangj.com - -Full Copyright Statement - - Copyright (C) The IETF Trust (2008). - - This document is subject to the rights, licenses and restrictions - contained in BCP 78, and except as set forth therein, the authors - retain all their rights. - - This document and the information contained herein are provided on an - "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS - OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND - THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS - OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF - THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED - WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. - -Intellectual Property - - The IETF takes no position regarding the validity or scope of any - Intellectual Property Rights or other rights that might be claimed to - pertain to the implementation or use of the technology described in - this document or the extent to which any license under such rights - might or might not be available; nor does it represent that it has - made any independent effort to identify any such rights. Information - on the procedures with respect to rights in RFC documents can be - found in BCP 78 and BCP 79. - - Copies of IPR disclosures made to the IETF Secretariat and any - assurances of licenses to be made available, or the result of an - attempt made to obtain a general license or permission for the use of - such proprietary rights by implementers or users of this - specification can be obtained from the IETF on-line IPR repository at - http://www.ietf.org/ipr. - - The IETF invites any interested party to bring to its attention any - copyrights, patents or patent applications, or other proprietary - rights that may cover technology that may be required to implement - this standard. Please address the information to the IETF at - ietf-ipr@ietf.org.