--- 1/draft-ietf-mboned-auto-multicast-16.txt 2014-04-24 11:14:40.938555834 -0700 +++ 2/draft-ietf-mboned-auto-multicast-17.txt 2014-04-24 11:14:41.106559885 -0700 @@ -1,18 +1,18 @@ Network Working Group G. Bumgardner Internet-Draft -Intended status: Standards Track October 21, 2013 -Expires: April 24, 2014 +Intended status: Standards Track April 24, 2014 +Expires: October 26, 2014 Automatic Multicast Tunneling - draft-ietf-mboned-auto-multicast-16 + draft-ietf-mboned-auto-multicast-17 Abstract This document describes Automatic Multicast Tunneling (AMT), a protocol for delivering multicast traffic from sources in a multicast-enabled network to receivers that lack multicast connectivity to the source network. The protocol uses UDP encapsulation and unicast replication to provide this functionality. The AMT protocol is specifically designed to support rapid deployment @@ -26,25 +26,25 @@ 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 April 24, 2014. + This Internet-Draft will expire on October 26, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + Copyright (c) 2014 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 @@ -72,58 +72,57 @@ 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 4.1. General Architecture . . . . . . . . . . . . . . . . . . 6 4.1.1. Relationship to IGMP and MLD Protocols . . . . . . . 7 4.1.2. Gateways . . . . . . . . . . . . . . . . . . . . . . 8 4.1.3. Relays . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.4. Deployment . . . . . . . . . . . . . . . . . . . . . 13 4.1.5. Discovery . . . . . . . . . . . . . . . . . . . . . . 15 4.2. General Operation . . . . . . . . . . . . . . . . . . . . 16 4.2.1. Message Sequences . . . . . . . . . . . . . . . . . . 16 - 4.2.2. Tunneling . . . . . . . . . . . . . . . . . . . . . . 25 - 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 30 - 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 30 - 5.1.1. Relay Discovery . . . . . . . . . . . . . . . . . . . 30 + 4.2.2. Tunneling . . . . . . . . . . . . . . . . . . . . . . 26 + 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 31 + 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 31 + 5.1.1. Relay Discovery . . . . . . . . . . . . . . . . . . . 31 5.1.2. Relay Advertisement . . . . . . . . . . . . . . . . . 32 - 5.1.3. Request . . . . . . . . . . . . . . . . . . . . . . . 33 - 5.1.4. Membership Query . . . . . . . . . . . . . . . . . . 34 - 5.1.5. Membership Update . . . . . . . . . . . . . . . . . . 38 - 5.1.6. Multicast Data . . . . . . . . . . . . . . . . . . . 40 - 5.1.7. Teardown . . . . . . . . . . . . . . . . . . . . . . 42 - 5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 44 - 5.2.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 44 - 5.2.2. Pseudo-Interface Configuration . . . . . . . . . . . 46 - 5.2.3. Gateway Service . . . . . . . . . . . . . . . . . . . 47 - 5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 59 - 5.3.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 59 - 5.3.2. Startup . . . . . . . . . . . . . . . . . . . . . . . 60 - 5.3.3. Running . . . . . . . . . . . . . . . . . . . . . . . 60 - 5.3.4. Shutdown . . . . . . . . . . . . . . . . . . . . . . 71 - 5.3.5. Response MAC Generation . . . . . . . . . . . . . . . 71 - 5.3.6. Private Secret Generation . . . . . . . . . . . . . . 72 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 72 - 6.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . . 73 - 6.2. Gateways . . . . . . . . . . . . . . . . . . . . . . . . 74 - 6.3. Encapsulated IP Packets . . . . . . . . . . . . . . . . . 75 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 - 7.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 75 - 7.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 75 - 7.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 75 - 7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses 75 - 7.3. UDP Port Number . . . . . . . . . . . . . . . . . . . . . 75 - 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 76 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 77 - 10.2. Informative References . . . . . . . . . . . . . . . . . 78 - Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 79 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 81 + 5.1.3. Request . . . . . . . . . . . . . . . . . . . . . . . 34 + 5.1.4. Membership Query . . . . . . . . . . . . . . . . . . 36 + 5.1.5. Membership Update . . . . . . . . . . . . . . . . . . 39 + 5.1.6. Multicast Data . . . . . . . . . . . . . . . . . . . 42 + 5.1.7. Teardown . . . . . . . . . . . . . . . . . . . . . . 43 + 5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 46 + 5.2.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 46 + 5.2.2. Pseudo-Interface Configuration . . . . . . . . . . . 47 + 5.2.3. Gateway Service . . . . . . . . . . . . . . . . . . . 49 + 5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 61 + 5.3.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 61 + 5.3.2. Startup . . . . . . . . . . . . . . . . . . . . . . . 62 + 5.3.3. Running . . . . . . . . . . . . . . . . . . . . . . . 62 + 5.3.4. Shutdown . . . . . . . . . . . . . . . . . . . . . . 73 + 5.3.5. Response MAC Generation . . . . . . . . . . . . . . . 73 + 5.3.6. Private Secret Generation . . . . . . . . . . . . . . 74 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 74 + 6.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . . 75 + 6.2. Gateways . . . . . . . . . . . . . . . . . . . . . . . . 76 + 6.3. Encapsulated IP Packets . . . . . . . . . . . . . . . . . 77 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 + 7.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 77 + 7.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 77 + 7.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 78 + 7.2. UDP Port Number . . . . . . . . . . . . . . . . . . . . . 78 + 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 78 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 80 + 10.2. Informative References . . . . . . . . . . . . . . . . . 81 + Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 82 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 84 1. Introduction The advantages and benefits provided by multicast technologies are well known. There are a number of application areas that are ideal candidates for the use of multicast, including media broadcasting, video conferencing, collaboration, real-time data feeds, data replication, and software updates. Unfortunately, many of these applications lack multicast connectivity to networks that carry traffic generated by multicast sources. The reasons for the lack of @@ -898,25 +897,25 @@ a MAC from the message source IP address, source UDP port, request nonce and a private secret. The relay accepts the Membership Update message if the received MAC matches the computed MAC, otherwise the message is ignored. If the message is accepted, the relay may proceed to allocate, refresh, or modify tunnel state. This includes making any group membership, routing and forwarding state changes and issuing any upstream protocol requests required to satisfy the state change. The diagram illustrates two scenarios: - a. The gateway has not previously reported any group + A. The gateway has not previously reported any group subscriptions and the report does not contain any group subscriptions, so the relay takes no action. - b. The gateway has previously reported a group subscription so + B. The gateway has previously reported a group subscription so the current-state report lists all current subscriptions. The relay responds by refreshing tunnel or group state and resetting any related timers. 7. A receiver indicates to the gateway that it wishes to join (allow) or leave (block) specific multicast traffic. This request is typically made using some form IGMP/MLD service interface (as described in Section 2 of [RFC3376] or Section 3 of [RFC3810]). The IGMP/MLD protocol responds by generating an IGMP or MLD state-change message. @@ -944,23 +943,23 @@ port, request nonce and a private secret. The relay accepts the Membership Update message if the received MAC matches the computed MAC, otherwise the message is ignored. If the message is accepted, the relay processes the encapsulated IGMP/MLD and allocates, modifies or deletes tunnel state accordingly. This includes making any group membership, routing and forwarding state changes and issuing any upstream protocol requests required to satisfy the state change. The diagram illustrates two scenarios: - a. The gateway wishes to add a group subscription. + A. The gateway wishes to add a group subscription. - b. The gateway wishes to delete a previously reported group + B. The gateway wishes to delete a previously reported group subscription. 10. Multicast datagrams transmitted from a source travel through the native multicast infrastructure to the relay. When the relay receives a multicast IP datagram that carries a source and destination address for which a gateway has expressed an interest in receiving (via the Membership Update message), it encapsulates the datagram into a Multicast Data message and sends it to the gateway using the source IP address and UDP port carried by the Membership Update message as the destination @@ -1375,21 +1374,21 @@ Source UDP Port - The UDP port number on which the gateway will listen for a relay response. Note: The value of this field may be changed as a result of network address translation before arriving at the relay. Destination IP Address - An anycast or unicast IP address, i.e., the Relay Discovery Address advertised by a relay. Destination UDP Port - The IANA-assigned AMT port number (See - Section 7.3). + Section 7.2). 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=0 |Type=1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discovery Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Relay Discovery Message Format @@ -2025,49 +2025,45 @@ own implementation of this subset of the IPv4/IGMP and IPv6/MLD protocols. The service interface used to manipulate group membership state need not match that described in the IGMP and MLD specifications, but the actions taken as a result SHOULD be similar to those described in Section 5.1 of [RFC3376] and Section 6.1 of [RFC3810]. The gateway application will likely need to implement many of the same functions as a host IP stack, including checksum verification, dispatching, datagram filtering and forwarding, and IP encapsulation/decapsulation. - The IP-encapsulated IGMP messages generated by the gateway IPv4/IGMP - implementation MUST conform to the description found in Section 4 of - [RFC3376]. These datagrams MUST possess the IP headers, header - options and header values called for in [RFC3376], with the following - exception; the source IP address for an IGMP report datagram MAY be - set to the "unspecified" address (all octets are zero ) but SHOULD be - set to an address in the address range specifically assigned by IANA - for use in the IGMP messages sent from a gateway to a relay (i.e. - 154.7.1.2 through 154.7.1.254 as described in Section 7). This - exception is made because the gateway pseudo-interface might not - possess an assigned address, and even if such an address exists, that - address would not be a valid link-local source address on any relay - interface. The rationale for using the aforementioned source - addresses is primarily one of convenience - a relay will accept an - IGMP report carried by a Membership Update message regardless of the - source address it carries. See Section 5.3.1. + The encapsulated IGMP datagrams generated by a gateway MUST conform + to the descriptions found in Section 4 of [RFC3376]. These datagrams + MUST possess the IP headers, header options and header values called + for in [RFC3376], with the following exception; a gateway MAY use any + source address value in an IGMP report datagram including the + "unspecified" address (all octets are zero ). This exception is made + because a gateway pseudo-interface might not possess a valid IPv4 + address, and even if an address has been assigned to the interface, + that address might not be a valid link-local source address on any + relay interface. It is for this reason that a relay must accept + encapsulated IGMP reports regardless of the source address they + carry. See Section 5.3.1. - The IP-encapsulated MLD messages generated by the gateway IPv6/MLD - implementation MUST conform to the description found in Section 5 of - [RFC3810]. These datagrams MUST possess the IP headers, header - options and header values called for in [RFC3810], with the following - exception; the source IP address for an MLD report datagram MAY be - set to the "unspecified" address (all octets are zero ) but SHOULD be - set to an IPv6 link-local address in the range FE80::/64 excluding - FE80::1 and FE80::2. This exception is made because the gateway - pseudo-interface might not possess a valid IPv6 address. As with - IGMP, a relay will accept an MLD report carried by a Membership - Update message regardless of the source address it carries. See - Section 5.3.1. + The encapsulated MLD messages generated by a gateway MUST conform to + the description found in Section 5 of [RFC3810]. These datagrams + MUST possess the IP headers, header options and header values called + for in [RFC3810], with the following exception; a gateway MAY use any + source address value in an MLD report datagram including the + "unspecified" address (all octets are zero ). This exception is made + because a gateway pseudo-interface might not possess a valid IPv6 + address, and even if an address has been assigned to the interface, + that address might not be a valid link-local source address on any + relay interface. As with IGMP, it is for this reason that a relay + must accept encapsulated MLD reports regardless of the source address + they carry. See Section 5.3.1. The gateway IGMP/MLD implementation SHOULD retransmit unsolicited membership state-change reports and merge new state change reports with pending reports as described in Section 5.1 of [RFC3376] and Section 6.1 of [RFC3810]. The number of retransmissions is specified by the relay in the Querier's Robustness Variable (QRV) field in the last general query forwarded by the pseudo-interface. See Section 4.1.6 in [RFC3376] and Section 5.1.8 in [RFC3810]. The gateway IGMP/MLD implementation SHOULD handle general query @@ -2845,47 +2842,43 @@ IPv4-encapsulated IGMPv3 general query in the Membership Query message. If the P-flag is 1, the relay MUST return an IPv6-encapsulated MLDv2 general query in the Membership Query message. If the relay is not accepting Membership Update messages that create new tunnel endpoints due to resource limitations, it SHOULD set the L-flag in the Membership Query message to notify the gateway of this state. Support for the L-flag is OPTIONAL. See Section 5.3.3.8. - The IGMPv3 general query datagram that a relay encapsulates within a - Membership Query message MUST conform to the descriptions found in - Section 4.1 of [RFC3376]. These datagrams MUST possess the IP - headers, header options and header values called for in [RFC3376], - with the following exception; the source IP address for an IGMP - general query datagram MAY be set to the "unspecified" address (all - octets are zero) but SHOULD be set to an address in the address range - specifically assigned by IANA for use in the IGMP messages sent from - a relay to a gateway (i.e. 154.7.1.1 as described in Section 7). - This exception is made because the source address that a relay might - normally send may not be a valid source address on any gateway - interface. The rationale for using the aforementioned source - addresses is primary one of convenience - a gateway will accept an - IGMP query regardless of the source address it carries. See - Section 5.2.1. + The encapsulated IGMPv3 general query datagrams generated by a relay + MUST conform to the descriptions found in Section 4.1 of [RFC3376]. + These datagrams MUST possess the IP headers, header options and + header values called for in [RFC3376], with the following exception; + a relay MAY use any source IP address for an IGMP general query + datagram including the "unspecified" address (all octets are zero). + This exception is made because any source address that a relay might + normally send may not be a valid link-local address on any gateway + interface. It is for this reason that a gateway must accept + encapsulated IGMP queries regardless of the source address they + carry. See Section 5.2.1. - The MLDv2 general query datagram that a relay encapsulates within a - Membership Query message MUST conform to the descriptions found in - Section 5.1 of [RFC3810]. These datagrams MUST possess the IP - headers, header options and header values called for in [RFC3810], - with the following exception; the source IP address for an MLD - general query datagram MAY be set to the "unspecified" address (all - octets are zero) but SHOULD be set to an IPv6 link-local address in - the range FE80::/64. A relay may use a dynamically-generated link- - local address or the fixed address FE80::2. As with IGMP, a gateway - will accept an MLD query regardless of the source address it carries. - See Section 5.2.1. + The encapsulated MLDv2 general query datagrams generated by a relay + MUST conform to the descriptions found in Section 5.1 of [RFC3810]. + These datagrams MUST possess the IP headers, header options and + header values called for in [RFC3810], with the following exception; + a relay MAY use any source IP address for an MLD general query + datagram including the "unspecified" address (all octets are zero). + This exception is made because any source address that a relay might + normally send may not be a valid link-local address on any gateway + interface. As with IGMP, it is for this reason that a gateway must + accept encapsulated MLD queries regardless of the source address they + carry. See Section 5.2.1. A relay MUST set the Querier's Query Interval Code (QQIC) field in the general query to supply the gateway with a suggested time duration to use for the membership query timer. The QQIC field is defined in Section 4.1.7 in [RFC3376] and Section 5.1.9 in [RFC3810]. A relay MAY adjust this value to affect the rate at which the Request messages are sent from a gateway. However, a gateway is allowed to use a shorter duration than specified in the QQIC field, so a relay may be limited in its ability to spread out Requests coming from a gateway. @@ -3472,36 +3465,66 @@ 7. IANA Considerations 7.1. IPv4 and IPv6 Anycast Prefix Allocation The following unicast prefixes have been assigned to provide anycast routing of relay discovery messages to public AMT Relays as described in Section 4.1.4. 7.1.1. IPv4 - IANA has assigned 154.7.0/24 for IPv4 relays. + We suggest that IANA assign an x.x.x.x/24 from the IPv4 Recovered + Address Space Registry, but any /24 which has been unassigned and + unadvertised for at least twelve months is acceptable. The block + should be registered as follows: -7.1.2. IPv6 + +----------------------+----------------+ + | Attribute | Value | + +----------------------+----------------+ + | Address Block | x.x.x.x./24 | + | Name | AMT | + | RFC | [TBD] | + | Allocation Date | [TBD] | + | Termination Date | N/A | + | Source | True | + | Destination | True | + | Forwardable | True | + | Global | True | + | Reserved-by-Protocol | False | + +----------------------+----------------+ - IANA has assigned 2001:0003::/32 for IPv6 relays. +7.1.2. IPv6 -7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses + IANA should register the following special-purpose address block for + IPv6 anycast AMT relay discovery. - IANA has assigned 154.7.1/24 as a prefix for IGMP source addresses. + +----------------------+----------------+ + | Attribute | Value | + +----------------------+----------------+ + | Address Block | 2001:0003::/32 | + | Name | AMT | + | RFC | [TBD] | + | Allocation Date | [TBD] | + | Termination Date | N/A | + | Source | True | + | Destination | True | + | Forwardable | True | + | Global | True | + | Reserved-by-Protocol | False | + +----------------------+----------------+ -7.3. UDP Port Number +7.2. UDP Port Number The UDP port number 2268 has been reserved with IANA for use in the implementation and deployment of AMT. The protocol described by this document continues to use this port number according to the intent of - the original request. This port number should be assigned to AMT + the original request. IANA should assign this port number to AMT upon acceptance of this I-D. 8. Contributors The following people provided significant contributions to the design of the protocol and earlier versions of this specification: Amit Aggarwal Microsoft Corporation One Microsoft Way @@ -3565,23 +3588,20 @@ connectivity without explicit tunnels ("6to4"). Tony Ballardie provided helpful discussion that inspired this document. Juniper Networks was instrumental in funding several versions of this draft as well as an open source implementation. 10. References 10.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. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.