--- 1/draft-ietf-mboned-auto-multicast-14.txt 2013-07-15 15:14:27.545083096 -0700 +++ 2/draft-ietf-mboned-auto-multicast-15.txt 2013-07-15 15:14:27.705087244 -0700 @@ -1,50 +1,50 @@ Network Working Group G. Bumgardner -Internet-Draft Cisco -Intended status: Standards Track June 12, 2012 -Expires: December 14, 2012 +Internet-Draft +Intended status: Standards Track July 15, 2013 +Expires: January 16, 2014 Automatic Multicast Tunneling - draft-ietf-mboned-auto-multicast-14 + draft-ietf-mboned-auto-multicast-15 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 by requiring minimal changes to existing network infrastructure. -Status of this Memo +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 December 14, 2012. + This Internet-Draft will expire on January 16, 2014. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + 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 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 @@ -57,44 +57,73 @@ 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 - 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 - 3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 - 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 - 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 - 4.1. General Architecture . . . . . . . . . . . . . . . . . . . 8 - 4.2. General Operation . . . . . . . . . . . . . . . . . . . . 17 - 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 32 - 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 32 - 5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 47 - 5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 62 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 73 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 - 7.2. IPv4 Address Prefix Allocation for IGMP Source - Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 - 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 77 - 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 - 10.1. Normative References . . . . . . . . . . . . . . . . . . . 79 - 10.2. Informative References . . . . . . . . . . . . . . . . . . 79 - Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 82 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 85 + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 + 3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 + 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 + 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 . . . . . . . . . . . . . . . . . . . . . . . . 75 + 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 + 10.1. Normative References . . . . . . . . . . . . . . . . . . 77 + 10.2. Informative References . . . . . . . . . . . . . . . . . 77 + 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 applications lack multicast connectivity to networks that carry traffic generated by multicast sources. The reasons for the lack of @@ -116,20 +145,24 @@ multicast connectivity to the source network. This document does not describe any methods for sourcing multicast traffic from isolated sites as this topic is out of scope. AMT is not intended to be used as a substitute for native multicast, especially in conditions or environments requiring high traffic flow. AMT uses unicast replication to reach multiple receivers and the bandwidth cost for this replication will be higher than that required if the receivers were reachable via native multicast. + AMT is designed to be deployed at the border of networks possessing + native multicast capabilities where access and provisioning can be + managed by the AMT service provider. + 3. Terminology 3.1. Requirements Notation 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 [RFC2119]. 3.2. Definitions @@ -156,29 +189,32 @@ Multicast Receiver: An entity that requests and receives multicast traffic. A receiver may be a router, host, application, or application component. The method by which a receiver transmits group membership requests and receives multicast traffic varies according to receiver type. Group Membership Database: A group membership database describes the current multicast - subscription/reception sate for an interface or system. + subscription state for an interface or system. See Section 3 in + [RFC3376] for a detailed definition. Reception State: The multicast subscription state of a pseudo, virtual or physical - network interface. See group membership database. + network interface. Often synonymous with group membership + database. Subscription: A group or state entry in a group membership database or reception - state table. + state table. The presence of a subscription entry indicates + membership in an IP multicast group. Group Membership Protocol: The term "group membership protocol" is used as a generic reference to the Internet Group Management (IGMP) ([RFC1112], [RFC2236], [RFC3376]) or Multicast Listener Discovery ([RFC2710], [RFC3810]) protocols. Multicast Protocol: The term "multicast protocol" is used as a generic reference to multicast routing protocols used to join or leave multicast @@ -228,23 +264,23 @@ normative description of the protocol and implementation requirements may be found in section Section 5. 4.1. General Architecture Isolated Site | Unicast Network | Native Multicast | (Internet) | | | | | | Group Membership | - +-------+ ===========================> +-------+ Multicast +------+ + +-------+ =========================> +-------+ Multicast +------+ |Gateway| | | | Relay |<----//----|Source| - +-------+ <=========================== +-------+ +------+ + +-------+ <========================= +-------+ +------+ | Multicast Data | | | | | Figure 1: Basic AMT Architecture The AMT protocol employs a client-server model in which a "gateway" sends requests to receive specific multicast traffic to a "relay" which responds by delivering the requested multicast traffic back to the gateway. @@ -276,21 +312,21 @@ | |<------| | | |<------| | | Host Mode | | AMT | | AMT | |Router Mode| | IGMP/MLD | | | UDP | | | IGMP/MLD | |___________|------>| |<----->| |------>|___________| Report | | | | Report Leave/Done | | | | Leave/Done | | | | IP Multicast <------| | | |<------ IP Multicast |_____| |_____| - Multicast Reception State Managed By IGMP/MLD + Figure 2: Multicast Reception State Managed By IGMP/MLD A gateway runs the host portion of the IGMP and MLD protocols to generate group membership updates that are sent via AMT messages to a relay. A relay runs the router portion of the IGMP and MLD protocols to process the group membership updates to produce the required changes in multicast forwarding state. A relay uses AMT messages to send incoming multicast IP datagrams to gateways according to their current group membership state. The primary function of AMT is to provide the handshaking, @@ -299,62 +335,64 @@ relays. The IGMP and MLD messages that are exchanged between gateways and relays are encapsulated as complete IP datagrams within AMT control messages. Multicast IP datagrams are replicated and encapsulated in AMT data messages. All AMT messages are sent via unicast UDP/IP. 4.1.2. Gateways The downstream side of a gateway services one or more receivers - the gateway accepts group membership requests from receivers and forwards - requested multicast traffic back to those receivers. + requested multicast traffic back to those receivers. The gateway + functionality may be directly implemented in the host requesting the + multicast service or within an application running on a host. The upstream side of a gateway connects to relays. A gateway sends encapsulated IGMP and MLD messages to a relay to indicate an interest in receiving specific multicast traffic. 4.1.2.1. Architecture Each gateway possesses a logical pseudo-interface: join/leave ---+ +----------+ | | | V IGMPv3/MLDv2 | | +---------+ General Query| | AMT |IGMP/MLD |<-------------| AMT | Messages +------+ - |Host Mode| | Gateway |<-------->|UPD/IP| + |Host Mode| | Gateway |<-------->|UDP/IP| |Protocol |------------->|Pseudo I/F| +------+ +---------+ IGMP/MLD | | ^ Report | | | Leave/Done | | V IP Multicast <---------------------| | +---+ +----------+ |I/F| +---+ - Figure 2: AMT Gateway Pseudo-Interface + Figure 3: AMT Gateway Pseudo-Interface The pseudo-interface is conceptually a network interface on which the gateway executes the host portion of the IPv4/IGMP (v2 or v3) and IPv6/MLD (v1 or v2) protocols. The multicast reception state of the pseudo-interface is manipulated using the IGMP or MLD service interface. The IGMP and MLD host protocols produce IP datagrams containing group membership messages that the gateway will send to the relay. The IGMP and MLD protocols also supply the retransmission and timing behavior required for protocol robustness. All AMT encapsulation, decapsulation and relay interaction is assumed to occur within the pseudo-interface. - A gateway host or application may create separate interfaces for - IPv4/IGMP and IPv6/MLD. A gateway host or application may also - require additional pseudo-interfaces for each source or domain- - specific relay address. + A gateway host or application may create separate interfaces for IPv4 + /IGMP and IPv6/MLD. A gateway host or application may also require + additional pseudo-interfaces for each source or domain-specific relay + address. Within this document, the term "gateway" may be used as a generic reference to an entity executing the gateway protocol, a gateway pseudo-interface, or a gateway device that has one or more interfaces connected to a unicast inter-network and one or more AMT gateway pseudo-interfaces. The following diagram illustrates how an existing host IP stack implementation might be used to provide AMT gateway functionality to a multicast application: @@ -391,21 +429,21 @@ | | | | ^ ^ | | | | IP(IGMP)| |IP(UDP(data)) | | | | |_________| |IP(IGMP) | | | | | | | | |_________________| | | | | | +--------------------------------------|--------------+ v AMT Relay - Virtual Interface Implementation Example + Figure 4: Virtual Interface Implementation Example In this example, the host IP stack uses a virtual network interface to interact with a gateway pseudo-interface implementation. 4.1.2.2. Use-Cases Use-cases for gateway functionality include: IGMP/MLD Proxy An IGMP/MLD proxy that runs AMT on an upstream interface and @@ -436,43 +474,47 @@ from those sources. 4.1.3.1. Architecture Each relay possesses a logical pseudo-interface: +------------------------------+ +--------+ | Multicast Control Plane | | |IGMP/MLD| | | | Query* | +------------+ +----------+ | - | |<---//----|IGMPv3/MLDv2| | | | - AMT | | | |Router Mode |->| PIM-SM |<--> - +------+ Messages | AMT |----//--->|Protocol | | | | + | |<---//----|IGMPv3/MLDv2| |Multicast | | + AMT | | | |Router Mode |->|Routing |<-> + +------+ Messages | AMT |----//--->|Protocol | |Protocol | | |UDP/IP|<-------->| Relay |IGMP/MLD| +------------+ +----------+ | +------+ | Pseudo | Report | | | | ^ | I/F | Leave/ +------|---------------|-------+ | | | Done | | | | | v | V | | IP +-----------+ | +---+ | | Multicast |Multicast |<------+ |I/F| | |<---//-----|Forwarding | +---+ +--------+ |Plane |<--- IP Multicast +-----------+ * Queries, if generated, are consumed by the pseudo-interface. - AMT Relay Pseudo-Interface (Router-Based) + 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. + 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 + 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 rendezvous point and cause changes in internal routing/forwarding @@ -563,20 +604,36 @@ does not yet allow this, because many relays will lack native multicast access to sources even though they may be globally accessible via unicast. In these cases, a provider may deploy relays within their own source network to allow for multicast distribution within that network. Gateways that use these relays must use a provider-specific relay discovery mechanism or a private anycast address to obtain access to these relays. +4.1.4.2. Congestion Considerations + + AMT relies on UDP to provide best-effort delivery of multicast data + to gateways. Neither AMT or the UDP protocol provide the congestion + control mechanisms required to regulate the flow of data messages + passing through a network. While congestion remediation might be + provided by multicast receiver applications via multicast group + selection or upstream reporting mechanisms, there are no means by + which to ensure such mechanisms are employed. To limit the possible + congestion across a network or wider Internet, AMT service providers + are expected to deploy AMT relays near the provider's network border + and its interface with edge routers. The provider must limit relay + address advertisements to those edges to prevent distant gateways + from being able to access a relay and potentially generate flows that + consume or exceed the capacity of intervening links. + 4.1.5. Discovery To execute the gateway portion of the protocol, a gateway requires a unicast IP address of an operational relay. This address may be obtained using a number of methods - it may be statically assigned or dynamically chosen via some form of relay discovery process. As described in the previous section, the AMT protocol provides a relay discovery method that relies on anycast addressing. Gateways are not required to use AMT relay discovery, but all relay @@ -596,42 +653,42 @@ Relay Address: The unicast IP address obtained as a result of the discovery process. 4.1.5.1. Relay Discovery Address Selection The selection of an anycast Relay Discovery Address may be source- dependent, as a relay located via relay discovery must have multicast connectivity to a desired source. - Similarly, the selection of a unicast Relay address may be source- + Similarly, the selection of a unicast Relay Address may be source- dependent, as a relay contacted by a gateway to supply multicast traffic must have native multicast connectivity to the traffic source - Methods that might be used to perform source-specific or group- specific relay selection are highly implementation-dependent and are not further addressed by this document. Possible approaches include the use of static lookup tables, DNS-based queries, or a provision of a service interface that accepts join requests on (S,G,relay- discovery-address) or (S,G,relay-address) tuples. 4.1.5.2. IANA-Assigned Relay Discovery Address Prefix - This document calls for IANA to allocate an anycast address prefix - for use in advertising and discovering publicly accessible relays. + IANA has assigned an address prefix for use in advertising and + discovering publicly accessible relays. - A relay discovery address is constructed from the anycast address - prefix by setting the low-order octet of the prefix address to 1 (for - both IPv4 and IPv6). + A relay discovery address is constructed from the address prefix by + setting the low-order octet of the prefix address to 1 (for both IPv4 + and IPv6). - Public relays must advertise a route to the anycast address prefix - and configure an interface to respond to the relay discovery address. + Public relays must advertise a route to the address prefix (e.g. via + BGP [RFC4271]) and configure an interface to respond to the relay + discovery address. The IANA address assignments are discussed in Section 7. 4.2. General Operation 4.2.1. Message Sequences The AMT protocol defines the following messages for control and encapsulation. These messages are exchanged as UDP/IP datagrams, one message per datagram. @@ -675,21 +733,21 @@ : : | | [1] |Relay Discovery | |------------------->| | | | Relay Advertisement| [2] |<-------------------| [3] | | : : - AMT Relay Discovery Sequence + Figure 6: AMT Relay Discovery Sequence The following sequence describes how the Relay Discovery and Relay Advertisement messages are used to find a relay with which to communicate: 1. The gateway sends a Relay Discovery message containing a random nonce to the Relay Discovery Address. If the Relay Discovery Address is an anycast address, the message is routed to topologically-nearest network node that advertises that address. @@ -721,28 +779,27 @@ messages that describe their current multicast reception state. However, AMT does not allow relays to send unsolicited query messages to gateways, as the set of active gateways may be unknown to the relay and potentially quite large. Instead, AMT requires each gateway to periodically send a message to a relay to solicit a general-query response. A gateway accomplishes this by sending a Request message to a relay. The relay responds by sending Membership Query message back to the gateway. The Membership Query message carries an encapsulated general query that is processed by the IGMP - or MLD protocol implementation on the gateway to produce a - membership/listener report. Each time the gateway receives a - Membership Query message it starts a timer whose expiration will - trigger the start of a new Request->Membership Query message - exchange. This timer-driven sequence is used to mimic the - transmission of a periodic general query by an IGMP/MLD router. This - query cycle may continue indefinitely once started by sending the - initial Request message. + or MLD protocol implementation on the gateway to produce a membership + /listener report. Each time the gateway receives a Membership Query + message it starts a timer whose expiration will trigger the start of + a new Request->Membership Query message exchange. This timer-driven + sequence is used to mimic the transmission of a periodic general + query by an IGMP/MLD router. This query cycle may continue + indefinitely once started by sending the initial Request message. A membership update occurs when an IGMP or MLD report, leave or done message is passed to the gateway pseudo-interface. These messages may be produced as a result of the aforementioned general-query processing or as a result of receiver interaction with the IGMP/MLD service interface. Each report is encapsulated and sent to the relay after the gateway has successfully established communication with the relay via a Request and Membership Query message exchange. If a report is passed to the pseudo-interface before the gateway has received a Membership Query message from the relay, the gateway may @@ -759,21 +816,21 @@ | | Membership Query |2 Query | | Q(0,{}) | Timer | Start 3|<--------------------| (QT)<--------------------------| | | Q(0,{}) | | |<--------------------| | 4| R({}) | Membership Update | |-------------------->|5 R({}) | | |====================>|6a Join(S,G) : : : - ()--------->|7 R({G:ALLOW({S})}) | Membership Update | + ()-------->|7 R({G:ALLOW({S})}) | Membership Update | |-------------------->|8 R({G:ALLOW({S})}) | | |====================>|9a Join(S,G) | | |---------->() : : : | ------------|---------------------|------------ | | | | | | | | Multicast Data | IP(S,G) | | | | IP(S,G) 10|<--------() | | | IP(S,G) 11|<====================| | | | ()<--------| | | @@ -785,79 +842,81 @@ | | Membership Query |2 | | Q(0,{}) | | Start 3|<--------------------| (QT)<--------------------------| | | Q(0,{}) | | |<--------------------| | 4| R({G:INCLUDE({S})}) | Membership Update | |-------------------->|5 R({G:INCLUDE({S})})| | |====================>|6b Leave(S,G) : : : - ()--------->|7 R({G:BLOCK({S})}) | Membership Update | + ()-------->|7 R({G:BLOCK({S})}) | Membership Update | |-------------------->|8 R({G:BLOCK({S})}) | | |====================>|9b Prune(S,G) | | |---------->() : : : - Membership Update Sequence (IGMPv3/MLDv2 Example) + Figure 7: Membership Update Sequence (IGMPv3/MLDv2 Example) The following sequence describes how the Request, Membership Query, and Membership Update messages are used to report current group membership state or changes in group membership state: 1. A gateway sends a Request message to the relay that contains a random nonce and a flag indicating whether the relay should return an IGMPv3 or MLDv2 general query. 2. When the relay receives a Request message, it generates a message authentication code (MAC) by computing a hash value from - a private secret and the nonce, source IP address, and source - UDP port carried by the Request message. The relay then sends a - Membership Query message to the gateway that contains the - request nonce, the MAC, and an IGMPv3 or MLDv2 general query. + message source IP address, source UDP port, request nonce and a + private secret. The relay then sends a Membership Query message + to the gateway that contains the request nonce, the MAC, and an + IGMPv3 or MLDv2 general query. 3. When the gateway receives a Membership Query message, it verifies that the request nonce matches the one sent in the last Request, and if it does, the gateway saves the request nonce and MAC for use in sending subsequent Membership Update messages. The gateway starts a timer whose expiration will trigger the transmission of a new Request message and extracts the encapsulated general query message for processing by the IGMP or MLD protocol. The query timer duration is specified by the - relay in the QQIC field in the IGMPv3 or MLDv2 general query. + relay in the Querier's Query Interval Code (QQIC) field in the + IGMPv3 or MLDv2 general query. The QQIC field is defined in + Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810]). 4. The gateway's IGMP or MLD protocol implementation processes the general query to produce a current-state report. 5. When an IGMP or MLD report is passed to the pseudo-interface, the gateway encapsulates the report in a Membership Update message and sends it to the relay. The request nonce and MAC fields in the Membership Update are assigned the values from the last Membership Query message received for the corresponding group membership protocol (IGMPv3 or MLDv2). 6. When the relay receives a Membership Update message, it computes - a MAC from a private secret and the request nonce, source IP - address, and source UDP port carried by the message. 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 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. @@ -869,37 +928,39 @@ assigned the values from the last Membership Query message received for the corresponding group membership protocol (IGMP or MLD). The IGMP and MLD protocols may generate multiple messages to provide robustness against packet loss - each of these must be encapsulated in a new Membership Update message and sent to the relay. The Querier Robustness Variable (QRV) field in the last IGMP/MLD query delivered to the IGMP/MLD protocol is typically used to specify the number of repetitions (i.e., the host adopts - the QRV value as its own Robustness Variable value). + the QRV value as its own Robustness Variable value). The QRV + field is defined in Section 4.1.6 in [RFC3376] and Section 5.1.8 + in [RFC3810]. 9. When the relay receives a Membership Update message, it again - computes a MAC from a private secret and the request nonce, - source IP address, and source UDP port carried by the message. - 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: + computes 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 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 @@ -922,85 +983,86 @@ and be rejected by the relay. A relay will only allocate new tunnel state if the IGMP/MLD report carried by the Membership Update message creates one or more group subscriptions. A relay deallocates tunnel state after one of the following events; the gateway sends a Membership Update message containing a report that results in the deletion of all remaining group subscriptions, the IGMP/MLD state expires (due to lack of refresh by the gateway), - or the relay receives a valid Teardown message from the gateway. + or the relay receives a valid Teardown message from the gateway (See + Section 4.2.1.3). A gateway that accepts or reports group subscriptions for both IPv4 and IPv6 addresses will send separate Request and Membership Update 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. Support for the Teardown message is optional - gateways - are not required to send them and relays are not required to act upon - them. + messages. Gateway support for the Teardown message is optional - + gateways are not required to send them and may instead relay on group + membership to expire on the relay. Gateway Relay ------- ----- : Request : [1] | N | |---------------------->| | Membership Query | [2] | N,MAC,gADDR,gPORT | |<======================| [3] | Membership Update | | ({G:INCLUDE({S})}) | |======================>| | | - ----------------------:-----------------------:---------------------- + ---------------------:-----------------------:--------------------- | | | | | | *Multicast Data | *IP Packet(S,G) | - | | gADDR,gPORT |<------------------() | + | | gADDR,gPORT |<-----------------() | | *IP Packet(S,G) |<======================| | - | ()<------------------| | | + | ()<-----------------| | | | | | | - ----------------------:-----------------------:---------------------- - ~ | - ~ Request | + ---------------------:-----------------------:--------------------- + ~ ~ + ~ Request ~ [4] | N' | |---------------------->| | Membership Query | [5] | N',MAC',gADDR',gPORT' | |<======================| [6] | | | Teardown | | N,MAC,gADDR,gPORT | |---------------------->| | | [7] | Membership Update | | ({G:INCLUDE({S})}) | |======================>| | | - ----------------------:-----------------------:---------------------- + ---------------------:-----------------------:--------------------- | | | | | | *Multicast Data | *IP Packet(S,G) | - | | gADDR',gPORT' |<------------------() | + | | gADDR',gPORT' |<-----------------() | | *IP Packet (S,G) |<======================| | - | ()<------------------| | | + | ()<-----------------| | | | | | | - ----------------------:-----------------------:---------------------- + ---------------------:-----------------------:--------------------- | | : : - Figure 3: Teardown Message Sequence (IGMPv3/MLDv2 Example) + Figure 8: Teardown Message Sequence (IGMPv3/MLDv2 Example) The following sequence describes how the Membership Query and Teardown message are used to detect an address change and stop the delivery of Multicast Data messages to an address: 1. A gateway sends a Request message containing a random nonce to the relay. 2. The relay sends a Membership Query message to the gateway that contains the source IP address (gADDR) and source UDP port @@ -1031,31 +1093,32 @@ compares the gateway address and port number values against those returned in the previous Membership Query message. 7. If the reported address or port has changed, the gateway sends a Teardown message to the relay that contains the request nonce, MAC, gateway IP address and gateway port number returned in the earlier Membership Query message. The gateway may send the Teardown message multiple times where the number of repetitions is governed by the Querier Robustness Variable (QRV) value contained in the IGMPv3/MLDv2 general query carried by the - original Membership Query. The gateway continues to process the - new Membership Query message as usual. + original Membership Query (See Section 4.1.6 in [RFC3376] and + Section 5.1.8 in [RFC3810]). The gateway continues to process + the new Membership Query message as usual. 8. When the relay receives a Teardown message, it computes a MAC - from a private secret and the request nonce, gateway IP address, - and gateway port number carried by the Teardown message. The - relay accepts the Teardown message if the received MAC matches - the computed MAC, otherwise the message is ignored. If the - message is accepted, the relay makes any group membership, - routing and forwarding state changes required to stop the - transmission of Multicast Data messages to that address. + from the message source IP address, source UDP port, request + nonce and a private secret. The relay accepts the Teardown + message if the received MAC matches the computed MAC, otherwise + the message is ignored. If the message is accepted, the relay + makes any group membership, routing and forwarding state changes + required to stop the transmission of Multicast Data messages to + that address. 4.2.1.4. Timeout and Retransmission The AMT protocol does not establish any requirements regarding what actions a gateway should take if it fails to receive a response from a relay. A gateway implementation may wait for an indefinite period of time to receive a response, may set a time limit on how long to wait for a response, may retransmit messages should the time limit be reached, may limit the number of retransmissions, or may simply report an error. @@ -1106,22 +1169,22 @@ to delete any and all subscriptions bound to the tunnel endpoint. o The relay stops receiving updates from the gateway until such time that per-group or per-tunnel timers expire, causing the relay to delete the subscriptions. The tunneling approach described above conceptually transforms a unicast-only inter-network into an NBMA link layer, over which multicast traffic may be delivered. Each relay, plus the set of all gateways using the relay, together may be thought of as being on a - separate logical NBMA link, where the "link layer" address is a - UDP/IP address-port pair provided by the Membership Update message. + separate logical NBMA link, where the "link layer" address is a UDP/ + IP address-port pair provided by the Membership Update message. 4.2.2.1. Address Roaming As described above, each time a relay receives a Membership Update message from a new source address-port pair, the group subscriptions described by that message apply to the tunnel endpoint identified by that address. This can cause problems for a gateway if the address carried by the messages it sends to a relay changes unexpectedly. These changes may @@ -1182,21 +1244,21 @@ | |---------->| |--------->| | | Gateway | | Mapping | | Relay | | |<----------| |<---------| | +---------+ +-----------+ +---------+ | | +---------+ Multicast Data Multicast Data src: rADDR:rPORT src: rADDR:rPORT dst: iADDR:iPORT dst: eADDR:ePORT - Network Address Translation in AMT + Figure 9: Network Address Translation in AMT AMT provides automatic NAT traversal by using the source IP address and UDP port carried by the Membership Update message as received at the relay as the destination address for any Multicast Data messages the relay sends back as a result. The NAT mapping created by a Membership Update message will eventually expire unless it is refreshed by a passing message. This refresh will occur each time the gateway performs the periodic update required to refresh group state within the relay (See @@ -1204,30 +1266,31 @@ 4.2.2.3. UDP Encapsulation Gateway Relay IP:IGMP IP:IGMP | AMT:IP:IGMP AMT:IP:IGMP | | | | | | | IP:UDP:AMT:IP:IGMP | | _______ | ___ | ______ | ______ | ___ | _______ + |IGMP|IP| v |AMT| v |UDP|IP| v |IP|UDP| v |AMT| v |IP|IGMP| | | | | | | | | | | | | | | | | | |<------------------------------------------------------->| | |____| | | | | | | | | | | | | |____| | |<--------------------------------------------------| | |_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______| | | | | | IP AMT:IP IP:UDP:AMT:IP AMT:IP IP - AMT Encapsulation + Figure 10: AMT Encapsulation The IGMP and MLD messages used in AMT are exchanged as complete IP datagrams. These IP datagrams are encapsulated in AMT messages that are transmitted using UDP. The same holds true for multicast traffic - each multicast IP datagram or datagram fragment that arrives at the relay is encapsulated in an AMT message and transmitted to one or more gateways via UDP. The IP protocol of the encapsulated packets need not match the IP protocol used to send the AMT messages. AMT messages sent via IPv4 @@ -1242,23 +1305,36 @@ encapsulated packets as they may not have access to the entire datagram. To avoid placing an undue burden on the relay platform, the protocol specifically allows zero-valued UDP checksums on the multicast data messages. This is not an issue in UDP over IPv4 as the UDP checksum field may be set to zero. However, this is a problem for UDP over IPv6 as that protocol requires a valid, non-zero checksum in UDP datagrams [RFC2460]. Messages sent over IPv6 with a UDP checksum of zero may fail to reach the gateway. This is a well known issue for - UDP-based tunneling protocols that is described - [I-D.ietf-6man-udpzero]. A recommended solution is described in - [I-D.ietf-6man-udpchecksums]. + UDP-based tunneling protocols that is described [RFC6936]. A + recommended solution is described in [RFC6935]. + +4.2.2.4. UDP Fragmentation + + Naive encapsulation of a multicast IP datagrams within an AMT data + messages may produce UDP datagrams that might require fragmentation + if their size exceeds the MTU of network path between the relay and a + gateway. Many multicast applications, especially those related to + media streaming, are designed to deliver independent data samples in + separate packets, without fragmentation, to ensure some number of + complete samples can be delivered even in the presence of packet + loss. To prevent or reduce undesirable fragmentation, the AMT + protocol describes specific procedures for handling multicast + datagrams whose encapsulation might exceed the path MTU. These + procedures are described in Section 5.3.3.6. 5. Protocol Description This section provides a normative description of the AMT protocol. 5.1. Protocol Messages The AMT protocol defines seven message types for control and encapsulation. These messages are assigned the following names and numeric identifiers: @@ -1298,31 +1374,32 @@ translation before arriving at the relay. 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. + Destination UDP Port - The IANA-assigned AMT port number (See + Section 7.3). 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Relay Discovery Message Format + Figure 11: Relay Discovery Message Format 5.1.1.1. Version (V) The protocol version number for this message is 0. 5.1.1.2. Type The type number for this message is 1. 5.1.1.3. Reserved @@ -1370,21 +1447,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=0 |Type=2 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discovery Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ Relay Address (IPv4 or IPv6) ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Relay Advertisement Message Format + Figure 12: Relay Advertisement Message Format 5.1.2.1. Version (V) The protocol version number for this message is 0. 5.1.2.2. Type The type number for this message is 2. 5.1.2.3. Reserved @@ -1437,21 +1514,21 @@ Destination UDP Port - The IANA-assigned AMT port number. 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=3 | Reserved |P| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Request Message Format + Figure 13: Request Message Format 5.1.3.1. Version (V) The protocol version number for this message is 0. 5.1.3.2. Type The type number for this message is 3. 5.1.3.3. Reserved @@ -1530,21 +1605,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | Gateway IP Address (IPv4 or IPv6) | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Membership Query Message Format + Figure 14: Membership Query Message Format 5.1.4.1. Version (V) The protocol version number for this message is 0. 5.1.4.2. Type The type number for this message is 4. 5.1.4.3. Reserved @@ -1600,27 +1675,30 @@ IPv4:IGMPv3 Membership Query IPv6:MLDv2 Listener Query The source address carried by the query message should be set as described in Section 5.3.3.3. The Querier's Query Interval Code (QQIC) field in the general query is used by a relay to specify the time offset a gateway should use to schedule a new three-way handshake to refresh the group membership - state within the relay (current time + Query Interval). + state within the relay (current time + Query Interval). The QQIC + field is defined in Section 4.1.7 in [RFC3376] and Section 5.1.9 in + [RFC3810]. The Querier's Robustness Variable (QRV) field in the general query is used by a relay to specify the number of times a gateway should retransmit unsolicited membership reports, encapsulated within Membership Update messages, and optionally, the number of times to - send a Teardown message. + send a Teardown message. The QRV field is defined in Section 4.1.6 + in [RFC3376] and Section 5.1.8 in [RFC3810]. 5.1.4.9. Gateway Address Fields The Gateway Port Number and Gateway Address fields are present in the Membership Query message if, and only if, the "G" flag is set. A gateway need not parse the encapsulated IP datagram to determine the position of these fields within the UDP datagram containing the Membership Query message - if the G-flag is set, the gateway may simply subtract the total length of the fields (18 bytes) from the @@ -1632,24 +1710,25 @@ The Relay sets this field to the value of the UDP source port of the Request message that triggered the Query message. 5.1.4.9.2. Gateway IP Address A 16-byte IP address that, when combined with the value contained in the Gateway Port Number field, forms the gateway endpoint address that the relay will use to identify the tunnel instance, if any, created by a subsequent Membership Update message. This field may - contain an IPv6 address or an IPv4 address stored as an IPv4- - compatible IPv6 address, where the IPv4 address is prefixed with 96 - bits set to zero (See [RFC4291]). This address must match that used - by the relay to compute the value stored in the Response MAC field. + contain an IPv6 address or an IPv4 address stored as an + IPv4-compatible IPv6 address, where the IPv4 address is prefixed with + 96 bits set to zero (See [RFC4291]). This address must match that + used by the relay to compute the value stored in the Response MAC + field. 5.1.5. Membership Update A gateway sends a Membership Update message to a relay to report a change in group membership state, or to report the current group membership state in response to receiving a Membership Query message. The gateway encapsulates the IGMP or MLD message as an IP datagram within a Membership Update message and sends it to the relay, where it may (see below) be decapsulated and processed by the relay to update group membership and forwarding state. @@ -1683,39 +1762,39 @@ Source UDP Port - The UDP port number on which the gateway will listen for Multicast Data messages from the relay. This port must be the same port used to send the initial Request message or the message will be ignored. Note: The value of this field may be changed as a result of network address translation before arriving at the relay. Destination IP Address - The unicast IP address of the relay. - Destination UDP Port - The IANA-assigned AMT UDP port number. + Destination UDP Port - The IANA-assigned AMT port number. 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=5 | Reserved | Response MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Encapsulated Group Membership Update Message | ~ IPv4:IGMP(Membership Report|Leave Group) ~ | IPv6:MLD(Listener Report|Listener Done) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Membership Update Message Format + Figure 15: Membership Update Message Format 5.1.5.1. Version (V) The protocol version number for this message is 0. 5.1.5.2. Type The type number for this message is 5. 5.1.5.3. Reserved @@ -1789,21 +1868,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=0 |Type=6 | Reserved | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | ~ IP Multicast Packet ~ | | + - - - - - - - - - - - - - - - - - - - - - - - -+ | : : : : +-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - - - Multicast Data Message Format + Figure 16: Multicast Data Message Format 5.1.6.1. Version (V) The protocol version number for this message is 0. 5.1.6.2. Type The type number for this message is 6. 5.1.6.3. Reserved @@ -1863,21 +1942,21 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + | Gateway IP Address (IPv4 or IPv6) | + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - Membership Teardown Message Format + Figure 17: Membership Teardown Message Format 5.1.7.1. Version (V) The protocol version number for this message is 0. 5.1.7.2. Type The type number for this message is 7. 5.1.7.3. Reserved @@ -1886,22 +1965,22 @@ the relay. 5.1.7.4. Response MAC A 48-bit value copied from the Response MAC field (Section 5.1.4.6) in the last Membership Query message the relay sent to the gateway endpoint address of the tunnel to be torn down. The gateway endpoint address is provided by the Gateway IP Address and Gateway Port Number fields carried by the Membership Query message. The relay validates the Teardown message by comparing this value with one computed from - the Request Nonce, Gateway Port Number and Gateway IP Address fields - (just as it does in the Membership Update message). + the Gateway IP Address, Gateway Port Number, Request Nonce fields and + a private secret (just as it does in the Membership Update message). 5.1.7.5. Request Nonce A 32-bit value copied from the Request Nonce field (Section 5.1.4.7) in the last Membership Query message the relay sent to the gateway endpoint address of the tunnel to be torn down. The gateway endpoint address is provided by the Gateway IP Address and Gateway Port Number fields carried by the Membership Query message. This value must match that used by the relay to compute the value stored in the Response MAC field. @@ -1981,21 +2060,22 @@ 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 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. + 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 messages as described in Section 5.2 of [RFC3376] and Section 6.2 of [RFC3810], but MAY ignore the Max Resp Code field value and generate a current state report without any delay. An IPv4 gateway implementation MUST accept IPv4 datagrams that carry the general query variant of the IGMPv3 Membership Query message, as described in Section 4 of [RFC3376]. The gateway MUST accept the IGMP datagram regardless of the IP source address carried by that @@ -2092,20 +2172,23 @@ o Optionally execute the membership query procedure described in Section 5.2.3.5 to start the periodic membership update cycle. 5.2.3.2. Handling AMT Messages A gateway MUST ignore any datagram it receives that cannot be interpreted as a Relay Advertisement, Membership Query, or Multicast Data message. The handling of Relay Advertisement, Membership Query, and Multicast Data messages is addressed in the sections that follow. + A gateway that conforms to this specification MUST ignore any message + with a Version field value other than zero. + While listening for AMT messages, a gateway may be notified that an ICMP Destination Unreachable message was received as a result of an AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9. 5.2.3.3. Handling Multicast Data Messages A gateway may receive Multicast Data messages after it sends a Membership Update message to a relay that adds a group subscription. The gateway may continue to receive Multicast Data messages long @@ -2128,27 +2211,26 @@ relevant IP protocol, i.e., 224.0.0.0/4 for IPv4 and FF00::/8 for IPv6. The gateway extracts the encapsulated IP datagram and forwards it to the local IP protocol implementation for checksum verification, fragmented datagram reassembly, source and group filtering, and transport-layer protocol processing. Because AMT uses UDP encapsulation to deliver multicast datagrams to gateways, it qualifies as a tunneling protocol subject to the - limitations described in [I-D.ietf-6man-udpzero]. If supported, a - gateway SHOULD employ the solution described in - [I-D.ietf-6man-udpchecksums] to ensure that the local IP stack does - not discard IPv6 datagrams with zero checksums. If Multicast Data - message datagrams are processed directly within the gateway (instead - of the host IP stack), the gateway MUST NOT discard any of these - datagrams because they carry a UDP checksum of zero. + limitations described in [RFC6936]. If supported, a gateway SHOULD + employ the solution described in [RFC6936] to ensure that the local + IP stack does not discard IPv6 datagrams with zero checksums. If + Multicast Data message datagrams are processed directly within the + gateway (instead of the host IP stack), the gateway MUST NOT discard + any of these datagrams because they carry a UDP checksum of zero. 5.2.3.4. Relay Discovery Procedure This section describes gateway requirements related to the relay discovery message sequence described in Section 4.2.1.1. 5.2.3.4.1. Starting Relay Discovery A gateway may start or restart the relay discovery procedure in response to the following events: @@ -2166,21 +2248,21 @@ o After the gateway receives a Membership Query message with the L-flag set to 1. 5.2.3.4.2. Sending a Relay Discovery Message A gateway sends a Relay Discovery message to a relay to start the relay discovery process. The gateway MUST send the Relay Discovery message using the current - Relay Discovery Address and IANA-assigned UDP port number as the + Relay Discovery Address and IANA-assigned AMT port number as the destination. The Discovery Nonce value in the Relay Discovery message MUST be computed as described in Section 5.2.3.4.5. The gateway MUST save a copy of Relay Discovery message or save the Discovery Nonce value for possible retransmission and verification of a Relay Advertisement response. When a gateway sends a Relay Discovery message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination @@ -2265,21 +2347,21 @@ |------------------------------------>| | | | | Membership Query | | |<====================================| Start | | | (QT)<--------| Membership Update | | |====================================>| | | | : : : - Teardown After Relay Address Change + Figure 18: Teardown After Relay Address Change 5.2.3.4.5. Discovery Nonce Generation The discovery nonce MUST be a random, non-zero, 32-bit value, and if possible, SHOULD be computed using a cryptographically secure pseudo random number generator. A new nonce SHOULD be generated each time the gateway restarts the relay discovery process. The same nonce SHOULD be used when retransmitting a Relay Discovery message. 5.2.3.5. Membership Query Procedure @@ -2528,21 +2609,21 @@ When a gateway sends a Membership Update message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9. 5.2.3.7. Teardown Procedure This section describes gateway requirements related to the teardown message sequence described in Section 4.2.1.3. - Gateway support for the Teardown message is OPTIONAL but RECOMMENDED. + Gateway support for the Teardown message is RECOMMENDED. A gateway that supports Teardown SHOULD make use of Teardown functionality if it receives a Membership Query message from a relay that has the "G" flag set to indicate that it contains valid gateway address fields. 5.2.3.7.1. Handling a Membership Query Message As described in Section 5.2.3.5.4, if a gateway supports the Teardown message, has reported active group subscriptions, and receives a @@ -2562,21 +2643,22 @@ Request Nonce, Response MAC, Gateway IP Address and Gateway Port Number fields from the Membership Query message that provided the Response MAC for the last Membership Update message sent, into the corresponding fields of the Teardown message. A gateway MUST send the Teardown message using the Relay Address and IANA-assigned AMT port number as the destination. A gateway MAY send the Teardown message multiple times for robustness. The gateway SHOULD use the Querier's Robustness Variable (QRV) field contained in the query encapsulated within the last Membership Query to set the - limit on the number of retransmissions. If the gateway sends the + limit on the number of retransmissions (See Section 4.1.6 in + [RFC3376] and Section 5.1.7 in [RFC3810]). If the gateway sends the Teardown message multiple times, it SHOULD insert a delay between each transmission using the timing algorithm employed in IGMP/MLD for transmitting unsolicited state-change reports. The RECOMMENDED default delay value is 1 second. When a gateway sends a Teardown message, it may be notified that an ICMP Destination Unreachable message was received as a result of an earlier AMT message transmission. Handling of ICMP Destination Unreachable messages is described in Section 5.2.3.9. @@ -2590,22 +2672,22 @@ message, and the current relay is returning gateway address fields in Membership Query messages, or o Send a Membership Update message to the relay that will delete existing group subscriptions. 5.2.3.9. Handling ICMP Destination Unreachable Responses A gateway may receive an ICMP "Destination Unreachable" message [RFC0792] after sending an AMT message. Whether the gateway is - notified that an ICMP message was received is highly dependent the - gateway IP stack behavior and gateway implementation. + notified that an ICMP message was received is highly dependent on + firewall and gateway IP stack behavior and gateway implementation. If the reception of an ICMP Destination Unreachable message is reported to the gateway while waiting to receive an AMT message, the gateway may respond as follows, depending on platform capabilities and which outgoing message triggered the ICMP response: 1. The gateway MAY simply abandon the current relay and restart relay discovery (if used). This is the least desirable approach as it does not allow for transient network changes. @@ -2754,22 +2836,23 @@ If a relay supports the Teardown message, it MUST set the G-flag in the Membership Query message and return the source IP address and UDP port carried by the Request message in the corresponding Gateway IP Address and Gateway Port Number fields. If the relay does not support the Teardown message it SHOULD NOT set these fields as this may cause the gateway to generate unnecessary Teardown messages. If the P-flag in the Request message is 0, the relay MUST return an 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. + 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], @@ -2793,39 +2876,43 @@ 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. 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.1 in [RFC3376] and Section 5.1.3 in [RFC3810]. + 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. 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. + 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 Max Resp 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 Interval - variable, if available, to generate the Max Resp 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. See + 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 + 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 update portion of the message sequence described in Section 4.2.1.2. When a relay receives a Membership Update message it must first determine whether it should accept or ignore the message. A relay MUST NOT make any changes to group membership and forwarding state if @@ -2981,53 +3069,163 @@ MUST be identical to those that would be made as if the relay had received an IGMP/MLD report that would cause the IGMP or MLD protocol to delete all existing group records in the group membership database associated with the endpoint. The processing of the Teardown message should trigger or mimic the normal interaction between IGMP or MLD and a multicast protocol to produce required changes in forwarding state and possibly send prune/leave messages towards upstream routers. 5.3.3.6. Handling Multicast IP Datagrams - When a multicast IP datagram is forwarded to the relay pseudo- interface, the relay MUST, for each gateway that has expressed an interest in receiving the datagram, encapsulate the IP datagram into - a Multicast Data message and send that message to the gateway. This - process is highly implementation dependent, but conceptually requires - the following steps: + a Multicast Data message or messages and send that message or + messages to the gateway. This process is highly implementation + dependent, but conceptually requires the following steps: o Use the IP datagram source and destination address to look up the appropriate (*,G) or (S,G) entry in the endpoint forwarding table created for the pseudo-interface as a result of IGMP/MLD processing. o Possibly replicate the datagram for each gateway endpoint listed for that (*,G) or (S,G) entry. - o Encapsulate the IP datagram in a UDP/IP Membership Data message, - using the endpoint UDP/IP address as the destination address and - the unicast relay address and IANA-assigned port as the source - UDP/IP address. To ensure successful NAT traversal, the source - address and port MUST match the destination address and port - carried by the Membership Update message sent by the gateway to - create the forwarding table entry. - - o If possible, the relay SHOULD compute a valid, non-zero checksum - for the UDP datagram carrying the Membership Data message. See - Section 4.2.2.3. + o If the multicast IP datagram size exceeds the Tunnel MTU as + determined according to the procedure described in + Section 5.3.3.6.1, the relay must execute the procedure described + in Section 5.3.3.6.2. - o Send the message to the gateway. + o Encapsulate and transmit the IP datagram according to the + procedure described in Section 5.3.3.6.3. The relay pseudo-interface MUST ignore any other IP datagrams forwarded to the pseudo-interface. +5.3.3.6.1. Path and Tunnel MTU + + A relay MUST compute a Tunnel MTU (TMTU) value for each AMT tunnel + that originates on the relay. A relay will use the TMTU value to + determine whether an incoming multicast IP datagram can be delivered + downstream in a Membership Data message without fragmentation. A + relay MUST compute the TMTU by subtracting the size of the Membership + Data message headers (IP, UDP, and AMT) from the current Path MTU + (PMTU) associated with each AMT tunnel. The relay MUST maintain a + PMTU value on a per-tunnel or per-relay basis. A relay MUST support + one or both of the following methods for determining the PMTU value: + + o The relay MAY provide a configuration option that establishes a + fixed PMTU that will be applied to all AMT tunnels originating at + the relay. + + o The relay MAY dynamically adjust PMTU value(s) in response to + receipt of ICMP/ICMPv6 "Datagram Too Big" messages as described in + [RFC1191] and [RFC1981]. + + If a relay supports dynamic adjustment of per-tunnel or per-relay + PMTU values in response to ICMP messages, the relay MUST provide a + configuration option that disables this feature and also provide a + configuration option that establishes a minimum PMTU for all tunnels. + These configuration options may be used to mitigate certain types of + denial of service attacks (See (Section 6)). When dynamic PMTU + adjustments are disabled, the PMTU for all tunnels MUST default to + the Link MTU (first-hop) on the downstream interface. + +5.3.3.6.2. MTU Filtering Procedure + + This section defines procedures that a relay must execute when it + 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 + 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 + tunnels. The relay SHOULD avoid generating a separate ICMPv6 message + for each tunnel, but instead send a single ICMPv6 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.3. Encapsulation Procedure + + A relay encapsulates a multicast IP datagram in a UDP/IP Membership + Data message, using the tunnel endpoint UDP/IP address as the + destination address and the unicast relay address and IANA-assigned + AMT port number as the source UDP/IP address. To ensure successful + NAT traversal, the source address and port MUST match the destination + address and port carried by the Membership Update message sent by the + gateway to create the forwarding table entry. + + If possible, the relay SHOULD compute a valid, non-zero checksum for + the UDP datagram carrying the Multicast Data message. See + Section 4.2.2.3. + + The following sections describe additional requirements related to + the IP protocol of the tunnel and that of the multicast IP datagram. + +5.3.3.6.3.1. Tunneling over IPv4 + + When a relay delivers an IPv4 payload over an IPv4 tunnel, and the DF + Bit in the payload header is set to 1 (Don't Fragment), the relay + MUST set the DF bit in the Multicast Data IP header to 1. When a + relay delivers an IPv4 payload over an IPv4 tunnel, and the DF Bit in + the payload header is set to 0 (May Fragment), by default, the relay + MUST set the DF bit in the Multicast Data IP header to 1. However, a + relay MAY provide a configuration option that allows the DF bit to be + copied from the payload header to the Multicast Data IP header to + allow downstream fragmentation of the Multicast Data message. When a + relay delivers an IPv6 payload over an IPv4 tunnel, the relay MUST + set the DF bit in the Multicast Data IP header to 1. The relay MUST + NOT transmit a Multicast Data message with an IP header in which the + MF (More Fragments) bit is set to 1. + +5.3.3.6.3.2. Tunneling over IPv6 + + When a tunneling over IPv6, a relay MUST NOT emit a Multicast Data + 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 + 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. A relay MAY use a variant of the IGMPv3/MLDv2 state management protocol described in Section 6 of [RFC3376] or Section 7 of [RFC3810], or may maintain a per-endpoint timer to trigger the @@ -3090,25 +3288,31 @@ o Stop sending data messages to gateways. o Delete all AMT group membership and forwarding state created on the relay, coordinating with the multicast routing protocol to update the group membership state on upstream interfaces as required. 5.3.5. Response MAC Generation A Response MAC is produced by a hash digest computation. A Response - MAC value is computed from a Request message for inclusion in a - Membership Query message, is computed from a Membership Update - message to authenticate the Response MAC carried within that message, - and is computed from fields in a Teardown message to authenticate the - Response MAC carried within that message. + 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 + 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 functions of greater cryptographic strength may be used. The digest MUST be computed over the following values: o The Source IP address of the message (or Teardown Gateway IP @@ -3197,20 +3401,31 @@ attack to propagate from one relay to the next until all relays reachable using the anycast address have effectively been taken offline. This behavior may also be used to acquire the unicast addresses for individual relays which can then be used to launch a DDoS attack on all of the relays without using the relay discovery process. To prevent wider disruption of AMT-based distribution network, relay anycast address advertisements can be limited to 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 + 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 modify or destroy group membership state associated with the gateway, thereby changing or interrupting the multicast traffic flows. @@ -3251,54 +3466,39 @@ messages that do not contain IGMP/MLD membership reports. 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 - IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated to - the public AMT Relays to advertise to the native multicast backbone - (as described in Section 4.1.4). The prefix length should be - determined by the IANA; the prefix should be large enough to - guarantee advertisement in the default-free BGP networks. + 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. 7.1.1. IPv4 - A prefix length of 24 will meet this requirement. - - Internet Systems Consortium (ISC) has offered 154.7.0/24 for this - purpose. + IANA has assigned 154.7.0/24 for IPv4 relays. 7.1.2. IPv6 - A prefix length of 32 will meet this requirement. IANA has - previously set aside the range 2001::/16 for allocating prefixes for - this purpose. + IANA has assigned 2001:0003::/32 for IPv6 relays. 7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses - IANA should allocate an IPv4 prefix dedicated for use in IGMP - messages exchanged between gateways and relays. This address range - is intended for use within tunnels constructed between a gateway and - relay, and as such, is not intended to be globally routable. - - A prefix length of 24 will meet this requirement. - - Internet Systems Consortium (ISC) has offered 154.7.1/24 for this - purpose. + IANA has assigned 154.7.1/24 as a prefix for IGMP source addresses. -7.3. UDP Port number +7.3. UDP Port Number - IANA has reserved UDP port number 2268 for AMT. + IANA has assigned UDP port number 2268 for AMT. 8. Contributors The following people provided significant contributions to the design of the protocol and earlier versions of this specification: Thomas Morin France Telecom - Orange 2, avenue Pierre Marzin Lannion 22300 @@ -3356,125 +3556,105 @@ 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 - [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, - August 1980. - [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. - [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, - April 1992. - [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. - [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. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. 10.2. Informative References - [I-D.ietf-6man-udpchecksums] - Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled - Packets", draft-ietf-6man-udpchecksums-02 (work in - progress), March 2012. - - [I-D.ietf-6man-udpzero] - Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum - Considerations", draft-ietf-6man-udpzero-05 (work in - progress), December 2011. + [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September + 1981. - [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, - September 1981. + [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, + RFC 792, September 1981. [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. + [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, + November 1990. + + [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, + April 1992. + [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. + [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery + for IP version 6", RFC 1981, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, November 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address - Translator (NAT) Terminology and Considerations", - RFC 2663, August 1999. + Translator (NAT) Terminology and Considerations", RFC + 2663, August 1999. [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast - Listener Discovery (MLD) for IPv6", RFC 2710, - October 1999. - - [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 - Tunnel Broker", RFC 3053, January 2001. - - [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains - via IPv4 Clouds", RFC 3056, February 2001. - - [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", - RFC 3068, June 2001. + Listener Discovery (MLD) for IPv6", RFC 2710, October + 1999. [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC - Text on Security Considerations", BCP 72, RFC 3552, - July 2003. + Text on Security Considerations", BCP 72, RFC 3552, July + 2003. - [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol - Independent Multicast - Dense Mode (PIM-DM): Protocol - Specification (Revised)", RFC 3973, January 2005. + [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway + Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 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. - [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006. + [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and + UDP Checksums for Tunneled Packets", RFC 6935, April 2013. + + [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement + for the Use of IPv6 UDP Datagrams with Zero Checksums", + RFC 6936, April 2013. + Appendix A. Implementation Notes A.1. Response MAC Generation and Keying This specification does not require relays to use any particular method to compute the Response MAC field value - only that it contain a hash of the source IP address, source UDP port, request nonce, and a private secret known only to the relay. This allows the relay implementor a significant amount of leeway in the computation and structure of the value stored in the Response MAC field. @@ -3514,80 +3694,78 @@ 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 |4 or 5| Reserved | | Response MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : - The Opaque Response MAC Field + Figure 19: The Opaque Response MAC Field A relay may use the opaque Response MAC field to store a cookie as follows: 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 |4 or 5| Reserved | | Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MD5(Secret,Timestamp,IP_ADDR,IP_PORT,Request-Nonce) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : : - Using The Response MAC Field To Carry An Authentication Cookie + Figure 20: Using The Response MAC Field To Carry An Authentication + Cookie The timestamp is an unsigned integer measured relative to the start time of relay. The age of the MAC is computed by subtracting the MAC timestamp from the current system timestamp. The operands must be unsigned 16-bit integers and the subtraction must use unsigned arithmetic to allow for timestamp wrap-around. The timestamp resolution must provide range sufficient to handle the maximum allowable age for a MAC, e.g., a resolution of 1 second allows a maximum age of 18 hours. The timestamp should start at a random value by adding a random offset, computed at startup, to the current system time. - +-------------------------+----------------/ /-----------------+ + +-------------------------+--------------/ /-----------------+ -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] | - | +-------------------------+----------------/ /-----------------+ - |_____________________________________________________________________ + | +-------------------------+--------------/ /-----------------+ + |___________________________________________________________________ | - +-------------------------+----------------/ /-----------------+ | + +-------------------------+--------------/ /-----------------+ | -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |-- - | +-------------------------+----------------/ /-----------------+ - |_____________________________________________________________________ + + | +-------------------------+--------------/ /-----------------+ + |___________________________________________________________________ | - +-------------------------+----------------/ /-----------------+ | + +-------------------------+--------------/ /-----------------+ | -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |-- - | +-------------------------+----------------/ /-----------------+ + | +-------------------------+--------------/ /-----------------+ | |__ Current Secret - Private Secret Queue + Figure 21: Private Secret Queue The timestamp is not only used to compute the age of the MAC, but is also used to lookup the private secret used to generate the MAC. Each time a new private secret is computed, the value and the time at which the value was computed is pushed into a fixed-length queue of recent values (typically only 2-deep). The relay uses the timestamp contained in the MAC field to lookup the appropriate secret. The relay iterates over the list of secrets, starting with the newest entry, until it finds the first secret with a timestamp that is older than that contained in the MAC field. The relay then uses that secret to compute the MAC that will be compared with that carried by the message. Author's Address Gregory Bumgardner - Cisco - 3700 Cisco Way - San Jose, CA 95134 - USA - Phone: +1 408 853 4993 - Email: gbumgard@cisco.com + Phone: +1 541 343 6790 + Email: gbumgard@gmail.com