--- 1/draft-ietf-mboned-auto-multicast-15.txt 2013-10-21 12:14:48.558195522 -0700 +++ 2/draft-ietf-mboned-auto-multicast-16.txt 2013-10-21 12:14:48.722199396 -0700 @@ -1,18 +1,18 @@ Network Working Group G. Bumgardner Internet-Draft -Intended status: Standards Track July 15, 2013 -Expires: January 16, 2014 +Intended status: Standards Track October 21, 2013 +Expires: April 24, 2014 Automatic Multicast Tunneling - draft-ietf-mboned-auto-multicast-15 + draft-ietf-mboned-auto-multicast-16 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,21 +26,21 @@ 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 January 16, 2014. + This Internet-Draft will expire on April 24, 2014. Copyright Notice Copyright (c) 2013 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 @@ -103,25 +103,25 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . 75 + 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 76 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 10.1. Normative References . . . . . . . . . . . . . . . . . . 77 - 10.2. Informative References . . . . . . . . . . . . . . . . . 77 + 10.2. Informative References . . . . . . . . . . . . . . . . . 78 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 79 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 81 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 @@ -499,21 +499,21 @@ Figure 5: AMT Relay Pseudo-Interface (Router-Based) The pseudo-interface is conceptually a network interface on which the relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2 protocols. Relays do not send unsolicited IGMPv3/MLDv2 query messages to gateways so relays must consume or discard any local queries normally generated by IGMPv3 or MLDv2. Note that the protocol mandates the use of IGMPv3 and MLDv2 for query messages. The AMT protocol is primarily intended for use in SSM applications - and relies on several values provided by IGMPv2/MLDv2 to control + and relies on several values provided by IGMPv3/MLDv2 to control gateway behavior. A relay maintains group membership state for each gateway connected through the pseudo-interface as well as for the entire pseudo- interface (if multiple gateways are managed via a single interface). Multicast packets received on upstream interfaces on the relay are routed to the pseudo-interface where they are replicated, encapsulated and sent to interested gateways. Changes in the pseudo- interface group membership state may trigger the transmission of multicast protocol requests upstream towards a given source or @@ -998,21 +998,21 @@ messages for each protocol (IPv4/IGMP and IPv6/MLD). 4.2.1.3. Teardown Sequence A gateway sends a Teardown message to a relay to request that it stop delivering Multicast Data messages to a tunnel endpoint created by an earlier Membership Update message. This message is intended to be used following a gateway address change (See Section 4.2.2.1) to stop the transmission of undeliverable or duplicate multicast data messages. Gateway support for the Teardown message is optional - - gateways are not required to send them and may instead relay on group + gateways are not required to send them and may instead rely on group membership to expire on the relay. Gateway Relay ------- ----- : Request : [1] | N | |---------------------->| | Membership Query | [2] | N,MAC,gADDR,gPORT | |<======================| @@ -2893,21 +2893,21 @@ A relay MUST set the Querier's Robustness Variable (QRV) field in the general query to a non-zero value. This value SHOULD be greater than one. If a gateway retransmits membership state change messages, it will retransmit them (robustness variable - 1) times. The QRV field is defined in Section 4.1.6 in [RFC3376] and Section 5.1.8 in [RFC3810]. A relay SHOULD set the Maximum Response Code field in the general query to a value of 1 to trigger an immediate response from the gateway (some host IGMP/MLD implementations may not accept a value of - zero). A relay SHOULD NOT use the IGMPv2/MLDv2 Query Response + zero). A relay SHOULD NOT use the IGMPv3/MLDv2 Query Response Interval variable, if available, to generate the Maximum Response Code field value as the Query Response Interval variable is used in setting the duration of group state timers and must not be set to such a small value. The Maximum Response Code field is defined in Section 4.1.1 in [RFC3376] and Section 5.1.3 in [RFC3810]. See Section 5.3.3.7. 5.3.3.4. Handling a Membership Update Message This section describes relay requirements related to the membership @@ -3137,29 +3137,29 @@ receives a multicast datagram whose size is greater than the Tunnel MTU of the tunnel or tunnels through which it must be delivered. 5.3.3.6.2.1. IPv4 Multicast IP Datagrams If the DF bit in the multicast datagram header is set to 1 (Don't Fragment), the relay MUST discard the packet and, if the datagram originated from an SSM source, send an ICMPv4 [RFC0792] Destination Unreachable message to the source, with type equal to 4 (fragmentation needed and DF set). The ICMP Destination Unreachable - message MUST contain an next-hop MTU (as specified by [RFC1191] and - [RFC1191]) and the relay MUST set the next-hop MTU to the TMTU - associated with the tunnel or tunnels. If the DF bit in the - multicast datagram header is set to 0 (May Fragment), the relay MUST - fragment the datagram and encapsulate each fragment within Multicast - Data messages for transmission through the tunnel or tunnels. This - ensures that gateways will receive complete, non-fragmented Multicast - Data messages, containing fragmented multicast datagram payloads. - The relay SHOULD avoid generating a separate ICMP message for each + message MUST contain an next-hop MTU (as specified by [RFC1191]) and + the relay MUST set the next-hop MTU to the TMTU associated with the + tunnel or tunnels. If the DF bit in the multicast datagram header is + set to 0 (May Fragment), the relay MUST fragment the datagram and + encapsulate each fragment within Multicast Data messages for + transmission through the tunnel or tunnels. This ensures that + gateways will receive complete, non-fragmented Multicast Data + messages, containing fragmented multicast datagram payloads. The + relay SHOULD avoid generating a separate ICMP message for each tunnel, but instead send a single ICMP message with a Next-hop MTU equal to the smallest TMTU of all tunnels to which the datagram was to be forwarded. 5.3.3.6.2.2. IPv6 Multicast IP Datagrams The relay MUST discard the packet and, if the datagram originated from an SSM source, send an ICMPv6 [RFC4443] Packet Too Big message to the payload source. The MTU specified in the Packet Too Big message MUST be equal to the TMTU associated with the tunnel or @@ -3207,21 +3207,21 @@ message datagram containing an IPv6 fragment header. 5.3.3.6.4. Handling Destination Unreachable Messages If a relay receives a sequence of ICMP or ICMPv6 messages of type "Destination Unreachable" in response to transmission of a sequence of AMT Multicast Data messages to a gateway, the relay SHOULD discontinue sending messages to that gateway and shutdown the tunnel for that gateway (Handling of ICMP "Destination Unreachable" messages with code 4, "fragmentation required" is covered in - Section 5.3.3.6.1). If a relay provides this capability, it MUTST + Section 5.3.3.6.1). If a relay provides this capability, it MUST provide a configuration option that indicates what number of sequential "Destination Unreachable" messages can be received and ignored before the relay will automatically shutdown a tunnel. 5.3.3.7. State Timers A relay MUST maintain a timer or timers whose expiration will trigger the removal of any group subscriptions and forwarding state previously created for a gateway endpoint should the gateway fail to refresh the group membership state within a specified time interval. @@ -3293,21 +3293,21 @@ required. 5.3.5. Response MAC Generation A Response MAC is produced by a hash digest computation. A Response MAC computation is required in the following situations: o To generate a Response MAC value from a Request message for inclusion in a Membership Query message. - o Tp generate a Response MAC value from a Membership Update message + o To generate a Response MAC value from a Membership Update message for use in authenticating the Response MAC carried within that message. o To generate a Response MAC value from a Teardown message to authenticate the Response MAC carried within that message. Gateways treat the Response MAC field as an opaque value, so a relay implementation may generate the MAC using any method available to it. The hash function RECOMMENDED for use in computing the Response MAC is the MD5 hash digest [RFC1321], though hash functions or keyed-hash @@ -3408,21 +3408,21 @@ specific administrative routing domains. This will isolate such attacks to a single domain. The Path and Tunnel MTU adjustment (discovery) procedure described in Section 5.3.3.6.1 is vulnerable to two denial of service attacks (see Section 8 of [RFC1191] for details). Both attacks are based upon on a malicious party sending forged ICMPv4 Destination Unreachable or ICMPv6 Packet Too Big messages to a host. In the first attack, the forged message indicates an inordinately small Path MTU. In the second attack, the forged message indicates an inordinately large - Path MTU. In both cases, throughput is adversely affected. On order + Path MTU. In both cases, throughput is adversely affected. In order to mitigate such attacks, relay implementations MUST include a configuration option to disable Path MTU adjustments on AMT tunnels. 6.2. Gateways A passive eavesdropper may launch a denial-of-service attack on a gateway by capturing a Membership Query or Membership Update message and using the request nonce and message authentication code carried by the captured message to send a spoofed a Membership Update or Teardown message to the relay. The spoofed messages may be used to @@ -3467,77 +3467,86 @@ Properly implemented gateways and relays will also filter encapsulated IP packets that appear corrupted or truncated by verifying packet length and checksums. 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 as - described in Section 4.1.4. + 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. 7.1.2. IPv6 IANA has assigned 2001:0003::/32 for IPv6 relays. 7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses IANA has assigned 154.7.1/24 as a prefix for IGMP source addresses. 7.3. UDP Port Number - IANA has assigned UDP port number 2268 for AMT. + 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 + 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 + Redmond, WA 98052-6399 + USA + Email: amitag@microsoft.com + Thomas Morin - France Telecom - Orange + Orange 2, avenue Pierre Marzin Lannion 22300 France Email: thomas.morin@orange.com Dirk Ooms OneSparrow - Belegstraat 13; 2018 Antwerp; + Robert Molsstraat 11; 2018 Antwerp Belgium EMail: dirk@onesparrow.com Tom Pusateri !j - 2109 Mountain High Rd. - Wake Forest, NC 27587 + Wake Forest, NC USA Email: pusateri@bangj.com Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA Email: dthaler@microsoft.com 9. Acknowledgments The authors would like to thank the following individuals for their suggestions, comments, and corrections: - Amit Aggarwal Mark Altom Toerless Eckert Marshall Eubanks Gorry Fairhurst Dino Farinacci Lenny Giuliano Andy Huang Tom Imburgia Patricia McCrink Han Nguyen