Network Working Group D. Thaler Internet-Draft M. Talwar Intended status: Standards Track A. Aggarwal Expires: January 12, 2012 Microsoft Corporation L. Vicisano Qualcomm Inc. T. Pusateri !j T. Morin France Telecom - Orange July 11, 2011 Automatic IP Multicast Tunneling draft-ietf-mboned-auto-multicast-11 Abstract Automatic IP Multicast Tunneling (AMT) allows multicast reception by isolated multicast-enabled sites or hosts, attached to a network which has no native multicast support. It enables them to receive multicast traffic from the native multicast infrastructure without requiring any manual configuration. AMT uses an encapsulation interface so that no changes to a host stack or applications are required, all protocols (not just UDP) are handled, and there is no additional overhead in core routers. Status of this Memo 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 January 12, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Thaler, et al. Expires January 12, 2012 [Page 1] Internet-Draft AMT July 2011 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Thaler, et al. Expires January 12, 2012 [Page 2] Internet-Draft AMT July 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 7 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 8 4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. AMT Relay . . . . . . . . . . . . . . . . . . . . . . . . 8 4.5. AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 9 4.6. AMT Relay Anycast Address . . . . . . . . . . . . . . . . 9 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Scalability Considerations . . . . . . . . . . . . . . . . 11 5.2. Spoofing Considerations . . . . . . . . . . . . . . . . . 11 5.3. Protocol Sequence . . . . . . . . . . . . . . . . . . . . 12 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 15 6.1. Use of UDP . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 15 6.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 15 6.3. AMT Relay Advertisement . . . . . . . . . . . . . . . . . 16 6.3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.3.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 16 6.3.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 16 6.3.4. Relay Address . . . . . . . . . . . . . . . . . . . . 16 6.4. AMT Request . . . . . . . . . . . . . . . . . . . . . . . 16 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17 6.4.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 17 6.4.3. Request Nonce . . . . . . . . . . . . . . . . . . . . 17 6.5. AMT Membership Query . . . . . . . . . . . . . . . . . . . 17 6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.5.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 18 6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 19 6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 19 6.5.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 19 6.5.6. Gateway information fields . . . . . . . . . . . . . . 19 6.6. AMT Membership Update . . . . . . . . . . . . . . . . . . 19 6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20 6.6.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20 6.6.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 21 6.6.5. IGMP/MLD Message (including IP Header) . . . . . . . . 21 6.7. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 21 6.7.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 22 6.7.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22 6.7.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 22 Thaler, et al. Expires January 12, 2012 [Page 3] Internet-Draft AMT July 2011 6.8. AMT Teardown . . . . . . . . . . . . . . . . . . . . . . . 22 6.8.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.8.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 23 6.8.3. Original Response MAC . . . . . . . . . . . . . . . . 23 6.8.4. Original Request Nonce . . . . . . . . . . . . . . . . 23 6.8.5. Original Source Port . . . . . . . . . . . . . . . . . 23 6.8.6. Original Source Address . . . . . . . . . . . . . . . 23 7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 25 7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 25 7.2. Gateway identification . . . . . . . . . . . . . . . . . . 25 7.3. Joining Multicast Groups . . . . . . . . . . . . . . . . . 26 7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 26 8. AMT Relay Details . . . . . . . . . . . . . . . . . . . . . . 27 8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 27 8.2. Receiving Relay Discovery messages sent to the Anycast Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.3. Receiving Membership Updates from AMT Gateways . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 29 9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29 9.2. UDP Port number . . . . . . . . . . . . . . . . . . . . . 29 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 13.1. Normative References . . . . . . . . . . . . . . . . . . . 33 13.2. Informative References . . . . . . . . . . . . . . . . . . 33 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Thaler, et al. Expires January 12, 2012 [Page 4] Internet-Draft AMT July 2011 1. Introduction The primary goal of this document is to foster the deployment of native IP multicast by enabling a potentially large number of nodes to connect to the already present multicast infrastructure. Therefore, the techniques discussed here should be viewed as an interim solution to help in the various stages of the transition to a native multicast network. To allow fast deployment, the solution presented here only requires small and concentrated changes to the network infrastructure, and no changes at all to user applications or to the socket API of end- nodes' operating systems. The protocol introduced in this specification can be deployed in a few strategically-placed network nodes and in user-installable software modules (pseudo device drivers and/or user-mode daemons) that reside underneath the socket API of end-nodes' operating systems. This mechanism is very similar to that used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6 connectivity. Effectively, AMT treats the unicast-only inter-network as a large non-broadcast multi-access (NBMA) link layer, over which we require the ability to multicast. To do this, multicast packets being sent to site must be encapsulated in unicast packets. If the group has members in multiple sites, AMT encapsulation of the same multicast packet will take place multiple times by necessity. A previous of this solution was previously "Automatic IP Multicast without explicit Tunnels", to highlight the fact that the tunneling used is lightweight and does not require statically configured tunnels used as point to point interfaces. Thaler, et al. Expires January 12, 2012 [Page 5] Internet-Draft AMT July 2011 2. Applicability AMT is not a substitute for native multicast or a statically configured multicast tunnel for high traffic flow. Unicast replication is required to reach multiple receivers that are not part of the native multicast infrastructure. However, this is no worse than regular unicast distribution of streams and in most cases much better. This document specifies procedures allowing isolated sites to receive both general Any Source Multicast (ASM, [RFC1112]), and Specific Source Multicast (SSM, [RFC4607]). Earlier versions of this document were describing how to use AMT to allow isolated non-NAT sites/hosts to transmit SSM multicast ; the specifications for these functionalities have been left off the current document for the following reasons: the drawback that these specifications required a source site Gateway to replicate traffic to many Relays in the multicast-enabled part of the network, lack of contributors to document alternative proposals based on AMT, existence of ways to offer similar functionality using Tunnel Broker approaches [RFC3053], or at the application layer. Implementers should be aware that site administrators may have configured administratively scoped multicast boundaries and a remote gateway may provide a means to circumvent administrative boundaries. Therefore, implementations should allow for the configuration of such boundaries on relays and gateways and perform filtering as needed. Thaler, et al. Expires January 12, 2012 [Page 6] Internet-Draft AMT July 2011 3. 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]. Thaler, et al. Expires January 12, 2012 [Page 7] Internet-Draft AMT July 2011 4. Definitions +---------------+ Internet +---------------+ | AMT Site | | Native MCast | | | | | | +------+----+ AMT +----+----+ | | |AMT Gateway| Anycast |AMT Relay| | | | +-----+-+ Prefix +-+-----+ | | | | |AMT IF | <------------|AMT IF | | | | | +-----+-+ +-+-----+ | | | +------+----+ +----+----+ | | | | | +---------------+ +---------------+ 4.1. AMT Pseudo-Interface AMT encapsulation of multicast packets inside unicast packets occurs at a point that is logically equivalent to an interface, with the link layer being the unicast-only network. This point is referred to as a pseudo-interface. Some implementations may treat it exactly like any other interface and others may treat it like a tunnel end- point. 4.2. AMT Gateway A host, or a site gateway router, supporting an AMT Pseudo-Interface. It does not have native multicast connectivity to the native multicast backbone infrastructure. It is simply referred to in this document as a "gateway". 4.3. AMT Site A multicast-enabled network not connected to the multicast backbone served by an AMT Gateway. It could also be a stand-alone AMT Gateway. 4.4. AMT Relay A multicast router configured to support transit routing between AMT Sites and the native multicast backbone infrastructure. The relay router has one or more interfaces connected to the native multicast infrastructure, zero or more interfaces connected to the non- multicast capable inter-network, and an AMT pseudo-interface. It is simply referred to in this document as a "relay". As with [RFC3056], we assume that normal multicast routers do not want to be tunnel endpoints (especially if this results in high fan out). Instead, we assume that special-purpose routers will be Thaler, et al. Expires January 12, 2012 [Page 8] Internet-Draft AMT July 2011 deployed that are suitable for serving as relays. 4.5. AMT Relay Anycast Prefix A well-known address prefix used to advertise (into the unicast routing infrastructure) a route to an available AMT Relay Router. This could also be private (i.e., not well-known) for a private relay. Prefixes for both IPv4 and IPv6 will be assigned in a future version of this draft. 4.6. AMT Relay Anycast Address An anycast address which is used to reach the nearest AMT Relay Router. This address corresponds to the setting the low-order octet of the AMT Relay Anycast Prefix to 1 (for both IPv4 and IPv6). Thaler, et al. Expires January 12, 2012 [Page 9] Internet-Draft AMT July 2011 5. Overview Internet +---------------+ +---------------+ | AMT Site | 2. 3-way Membership | Native MCast | | | Handshake | | | 1. Join +---+---+ =================> +---+---+ | | +---->|Gateway| | Relay | | | | +---+---+ <================= +---+---+ | | R-+ | 3. Receive Data | | +---------------+ +---------------+ Receiving Multicast in an AMT Site AMT relays and gateways cooperate to transmit multicast traffic sourced within the native multicast infrastructure to AMT sites: relays receive the traffic natively and unicast-encapsulate it to gateways; gateways decapsulate the traffic and possibly forward it into the AMT site. Each gateway has an AMT pseudo-interface that serves as a default multicast route. Requests to join a multicast session are sent to this interface and encapsulated to a particular relay reachable across the unicast-only infrastructure. Each relay has an AMT pseudo-interface too. Multicast traffic sent on this interface is encapsulated to zero or more gateways that have joined to the relay. The AMT recipient-list is determined for each multicast session. This requires the relay to keep state for each gateway which has joined a particular group or (source, group) pair. Multicast packets from the native infrastructure behind the relay will be sent to each gateway which has requested them. All multicast packets (data and control) are encapsulated in unicast packets. UDP encapsulation is used for all AMT control and data packets using the IANA reserved UDP port number for AMT. Each relay, plus the set of all gateways using the relay, together are thought of as being on a separate logical NBMA link. This implies that the AMT recipient-list is a list of "link layer" addresses which are (IP address, UDP port) pairs. Since the number of gateways using a relay can be quite large, and we expect that most sites will not want to receive most groups, an explicit-joining protocol is required for gateways to communicate group membership information to a relay. The two most likely candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the PIM-Sparse Mode protocol [RFC4601]. Since an AMT gateway may be a Thaler, et al. Expires January 12, 2012 [Page 10] Internet-Draft AMT July 2011 host, and hosts typically do not implement routing protocols, gateways will use IGMP/MLD as described in Section 7 below. This allows a host kernel (or a pseudo device driver) to easily implement AMT gateway behavior, and obviates the relay from the need to know whether a given gateway is a host or a router. From the relay's perspective, all gateways are indistinguishable from hosts on an NBMA leaf network. 5.1. Scalability Considerations It is possible that millions of hosts will enable AMT gateway functionality and so an important design goal is not to create gateway state in each relay until the gateway joins a multicast group. But even the requirement that a relay keep group state per gateway that has joined a group introduces potential scalability concerns. Scalability of AMT can be achieved by adding more relays, and using an appropriate relay discovery mechanism for gateways to discover relays. The solution we adopt is to assign addresses in anycast fashion to relays [RFC1546], [RFC4291]. However, simply sending periodic membership reports to an anycast address can cause duplicates. Specifically, if routing changes such that a different relay receives a periodic membership report, both the new and old relays will encapsulate data to the AMT site until the old relay's state times out. This is obviously undesirable. Instead, we use the anycast address merely to find the unicast address of a relay to which membership reports are sent. This approach allows the gateways to be spread out among more relays so as to keep the number of gateways per relay at a reasonable level. 5.2. Spoofing Considerations An attacker could affect the group state in the relay by spoofing the source address in AMT Update messages containing join or leave reports. This can be used to launch reflection or denial of service attacks on the target Relay. Such attacks can be mitigated by using a three way handshake between the gateway and the relay for each multicast membership report or leave. When a gateway wants to send a membership report, it first sends an AMT Request with a request nonce in it. The Relay can calculate a message authentication code (MAC) based on (for example)the source IP address of the Request, the source UDP port, the request nonce, and a secret key known only to the Relay. The algorithm does not have to be standardized since the Relay generates and verifies the MAC and the Gateway simply echoes it back, but an algorithm such as Thaler, et al. Expires January 12, 2012 [Page 11] Internet-Draft AMT July 2011 HMAC-MD5-48 [RFC2104] SHOULD be used at a minimum. An AMT Membership Query is sent back to the gateway having originated the Request, including the request nonce and the MAC. The gateway then sends the IGMP/MLD Membership/Listener Report or Leave/Done (including the IP Header) along with the request nonce and the received MAC back to the relay, finalizing the 3-way handshake. Upon reception, the relay can recalculate the MAC based on the source IP address, the source UDP port, the request nonce, and the local secret. The IGMP/MLD message is only accepted if the received MAC matches the calculated MAC. A relay MUST NOT create state for a gateway before successful validation of a MAC of an AMT Update from this gateway; a relay SHOULD delete all states for a gateway after a small timer after it stops having any AMT forwarding state for a Gateway (i.e. the Gateway left all multicast groups it had joined). The local secret never has to be shared with the other side. It is only used to verify return routability of the originator. Since the same Request Nonce and source IP address can be re-used, the relay SHOULD change its secret key at least once per hour. However, AMT Membership updates received with the previous secret MUST be accepted for up to the IGMP/MLD Query Interval. The condition might occur where the gateway that initially sent the AMT Request dynamically changes its IP address. This might occur due to a change in wireless networks, a DHCP assignment, or another network failure. When this occurs, it is no longer possible to verify the MAC using the source address and source port. Though, in order to reduce state, it is desirable to tear down the state that was created with the old source address. A Teardown message with special considerations for calculating the MAC is described below to perform this function. 5.3. Protocol Sequence This description assumes the Gateway can be a host joining as a receiver or a network device acting as a Gateway when a directly connected host joins as a receiver. Protocol sequence for a multicast SSM channel (S1,G1): o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1). Thaler, et al. Expires January 12, 2012 [Page 12] Internet-Draft AMT July 2011 o Gateway receives report. If it has no tunnel state with a Relay, it originates an AMT Relay Discovery message addressed to the Anycast Relay IP address. The AMT Relay Discovery message can be sent on demand if no relay is known at this time or at startup and be periodically refreshed. o The closest Relay topologically receives the AMT Relay Discovery message and returns the nonce from the Discovery in an AMT Relay Advertisement message so the Gateway can learn of the Relay's unique IP address. o When the Gateway receives the AMT Relay Advertisement message, it now has an address to use for all subsequent (S,G) entries it will join on behalf of attached receivers (or itself). o If the gateway has a valid Response MAC from a previous AMT Query message, it can send an AMT Membership Update message as described below. Otherwise, the Gateway sends an AMT Request message to the Relay's unique IP address to begin the process of joining the (S,G). The gateway also SHOULD initialize a timer used to send periodic Requests to a random value from the interval [0, [Query Interval]] before sending the first periodic report, in order to prevent startup synchronization. o The Relay responds to the AMT Request message by returning the nonce from the Request in a AMT Query message. The Query message contains an IGMP/MLD QUERY indicating how often the Gateway should repeat AMT Request messages so the (S,G) state can stay refreshed in the Relay. The Query message also includes an opaque security code which is generated locally (with no external coordination). o When the Gateway receives the AMT Query message it responds by copying the security code from the AMT Query message into a AMT Membership Update message. The Update message contains (S1,G1) in an IGMPv3/MLDv2 formatted packet with an IP header. The nonce from the AMT Request is also included in the AMT Membership Update message. o When the Relay receives the AMT Membership Update, it will add the tunnel to the Gateway in it's outgoing interface list for it's (S1,G1) entry stored in the multicast routing table. If the (S1,G1) entry was created do to this interaction, the multicast routing protocol running on the Relay will trigger a Join message towards source S1 to build a native multicast tree in the native multicast infrastructure. o As packets are sent from the host S1, they will travel natively down the multicast tree associated with (S1,G1) in the native Thaler, et al. Expires January 12, 2012 [Page 13] Internet-Draft AMT July 2011 multicast infrastructure to the Relay. The Relay will replicate to all interfaces in it's outgoing interface list as well as the tunnel outgoing interface, which is encapsulated in a unicast AMT Multicast Data message. o When the Gateway receives the AMT Multicast Data message, it will accept the packet since it was received over the pseudo-interface associated with the tunnel to the Relay it had attached to, and forward the packet to the outgoing interfaces joined by any attached receiver hosts (or deliver the packet to the application when the Gateway is the receiver). o If later (S2,G2) is joined by a receiver, a 3-way handshake of Request/ Query/Update occurs for this entry. The Discovery/ Advertisement exchange is not required. o To keep the state for (S1,G1) and (S2,G2) alive in the Relay, the Gateway will send periodic AMT Membership Updates. The Membership Update can be sent directly if the sender has a valid nonce from a previous Request. If not, an AMT Request messages should be sent to solicit a Query Message. When sending a periodic state refresh, all joined state in the Gateway is packed in the fewest number of AMT Membership Update messages. o When the Gateway leaves all (S,G) entries, the Relay can free resources associated with the tunnel. It is assumed that when the Gateway would want to join an (S,G) again, it would start the Discovery/Advertisement tunnel establishment process over again. This same procedure would be used for receivers who operate in Any- Source Multicast (ASM) mode. Thaler, et al. Expires January 12, 2012 [Page 14] Internet-Draft AMT July 2011 6. Message Formats 6.1. Use of UDP All AMT messages are UDP packets. Messages sent to the Relay are sent to the IANA reserved AMT port number (Section 9), from a source port uniquely selected by the host operating system of the Gateway. Messages sent by the Relay are sent from the IANA reserved AMT port number. The UDP checksum MUST be valid in all AMT control messages (Relay Discovery, Relay Advertisement, Membership Request, Membership Query, Membership Update). Section 6.7 specifies the behavior with reference to the UDP checksums of AMT IP Multicast Data messages. 6.2. AMT Relay Discovery The AMT Relay Discovery message is sent from the AMT gateway unicast address to the AMT Relay Anycast address to discover the unicast address of an AMT relay. The payload of the UDP packet contains the following fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discovery Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AMT Relay Discovery 6.2.1. Type The type of the message. 6.2.2. Reserved A 24-bit reserved field. Sent as 0, ignored on receipt. 6.2.3. Discovery Nonce A 32-bit random value generated by the gateway and replayed by the relay. Thaler, et al. Expires January 12, 2012 [Page 15] Internet-Draft AMT July 2011 6.3. AMT Relay Advertisement The AMT Relay Advertisement message sent from the AMT relay anycast address to the source of the discovery message. The UDP source port is the IANA reserved AMT port number and the UDP destination port is the source port received in the Discovery message. The payload of the UDP packet contains the following fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x2 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Discovery Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Relay Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AMT Relay Advertisement 6.3.1. Type The type of the message. 6.3.2. Reserved A 24-bit reserved field. Sent as 0, ignored on receipt. 6.3.3. Discovery Nonce A 32-bit random value generated by the gateway and replayed by the relay. 6.3.4. Relay Address The unicast IPv4 or IPv6 address of the AMT relay. The family can be determined by the length of the Advertisement. 6.4. AMT Request A Request packet is sent by a Gateway to a Relay to begin a 3-way handshake for sending an IGMP/MLD Membership/Listener Report or Leave/Done. It is sent from the Gateway address to the Relay's unique unicast Thaler, et al. Expires January 12, 2012 [Page 16] Internet-Draft AMT July 2011 address. The UDP source port is uniquely selected by the local host operating system. It can be different from the source port used in Discovery messages but does not have to be. The UDP source port must be consistent across Request and Update messages (see also Section 7.2). The UDP destination port is the IANA reserved 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x3 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AMT Request 6.4.1. Type The type of the message. 6.4.2. Reserved A 24-bit reserved field. Sent as 0, ignored on receipt. 6.4.3. Request Nonce A 32-bit identifier used to distinguish this request. 6.5. AMT Membership Query An AMT Membership Query packet is sent from the Relay back to the Gateway to solicit an AMT Membership Update while confirming the source of the original request. It contains a relay Message Authentication Code (MAC) that is a cryptographic hash of a private secret, the originators address, and the request nonce. It is sent from the destination address received in the Request to the source address of the Request, i.e. the Relay Address advertised in the Relay Advertisement message. The UDP source port is the IANA reserved AMT port number and the UDP destination port is the source port received in the Request message. Thaler, et al. Expires January 12, 2012 [Page 17] Internet-Draft AMT July 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x4 | Flags | Response MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response MAC (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IGMP Membership Query or MLD Listener Query | | (including IP Header) | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Gateway Port Number | Gateway Address ... | ? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ? | ... Gateway Address (ctd) ... | ? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ? | ... Gateway Address (ctd) ... | ? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ? | ... Gateway Address (ctd) ... | ? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ? | ... Gateway Address (ctd) | ? +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AMT Membership Query 6.5.1. Type The type of the message. 6.5.2. Flags An 8-bit flags field having the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ | Reserved |G| +-+-+-+-+-+-+-+-+ The "G" flag is set to 1 if Gateway information fields are present in the Query message (see below Section 6.5.6), and to zero if they are not. Other flags are currently unused and reserved: they are sent as zero and their value is ignored on receipt. Thaler, et al. Expires January 12, 2012 [Page 18] Internet-Draft AMT July 2011 6.5.3. Response MAC A 48-bit hash generated by the Relay and sent to the Gateway for inclusion in the AMT Membership Update (see Section 5.2). 6.5.4. Request Nonce A 32-bit identifier echoed back to the originator to used to identify the corresponding request (see Section 5.2). 6.5.5. IGMP/MLD Query (including IP Header) The message contains either an IGMP Query or an MLD Multicast Listener Query. The IGMP or MLD version sent should default to IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1. The IGMP/MLD Query includes a full IP Header. The IP source address of the query would match the anycast address on the pseudo interface. The TTL of the outer IP header should be sufficient to reach the tunnel endpoint and not mimic the inner IP header TTL which is typically 1 for IGMP/MLD messages. 6.5.6. Gateway information fields The "Gateway Port Number" and "Gateway Address" fields are present in the Query message if, and only if, the "G" flag is set in the Flags field. 6.5.6.1. Gateway Port Number A 16-bit field containing a UDP port value. The Relay sets this field to the value of the UDP source port of the Request message that triggered the Query message. 6.5.6.2. Gateway Address A 16-byte field containing the IP source address of the Request message that triggered this Query message. The field contains an IPv4-compatible IPv6 address ([RFC4291], section 2.5.5.1) if the address is an IPv4 address (i.e. the IPv4 address prefixed with 96 bits set to zero), or an IPv6 address. 6.6. AMT Membership Update An AMT Membership Update is sent to report a membership after a valid Response MAC has been received. It contains the original IGMP/MLD Membership/Listener Report or Leave/Done received over the AMT pseudo-interface including the original IP header. It echoes the Thaler, et al. Expires January 12, 2012 [Page 19] Internet-Draft AMT July 2011 Response MAC received in the AMT Membership Query so the respondent can verify return routability to the originator. It is sent from the destination address received in the Query to the source address received in the Query which should both be the same as the original Request. The UDP source and destination port numbers should be the same ones sent in the original Request. The UDP destination port is the IANA reserved AMT port number and the UDP source port is the source port used for the Request message. The Relay is not required to use the IP source address of the IGMP Membership Report for any particular purpose. The same Request Nonce and Response MAC can be used across multiple AMT Membership Update messages without having to send individual AMT Membership Query messages. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x5 | Reserved | Response MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Response MAC (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Request Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IGMP or MLD Message (including IP header) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AMT Membership Update 6.6.1. Type The type of the message. 6.6.2. Reserved A 8-bit reserved field. Sent as 0, ignored on receipt. 6.6.3. Response MAC The 48-bit MAC received in the Membership Query and echoed back in the Membership Update (see Section 5.2). Thaler, et al. Expires January 12, 2012 [Page 20] Internet-Draft AMT July 2011 6.6.4. Request Nonce A 32-bit identifier matching the nonce in the AMT Request (see Section 5.2). 6.6.5. IGMP/MLD Message (including IP Header) The message contains either an IGMP Membership Report, an IGMP Membership Leave, an MLD Multicast Listener Report, or an MLD Listener Done. The IGMP or MLD version sent should be in function of the version of the query received in the AMT Membership Query. The IGMP/MLD Message includes a full IP Header. 6.7. AMT IP Multicast Data The AMT Data message is a UDP packet encapsulating the IP Multicast data requested by the originator based on a previous AMT Membership Update message. It is sent from the Relay's unique unicast address (destination address of the Membership update) to the Gateway's unicast address (source address of the Membership Update). The UDP source port is the IANA reserved AMT port number and the destination port should be the same as the source port of the Membership Update that resulted in the creation of forwarding state for the encapsulated IP packet. The UDP checksum SHOULD be zero for AMT IP Multicast Data messages carried over IPv4, and MAY be zero for AMT IP Multicast Data messages carried over IPv6 [I-D.ietf-6man-udpchecksums]. The payload of the UDP packet contains the following fields. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x6 | Reserved | IP Multicast Data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AMT IP Multicast Data Thaler, et al. Expires January 12, 2012 [Page 21] Internet-Draft AMT July 2011 6.7.1. Type The type of the message. 6.7.2. Reserved An 8-bit reserved field. Sent as 0, ignored on receipt. 6.7.3. IP Multicast Data The original IP Multicast data packet that is being replicated by the Relay to the Gateway, including the original IP header. 6.8. AMT Teardown An AMT Teardown is sent by a Gateway after a valid Response MAC has been received and after the source address that was used to generate the Response MAC is no longer available for sending packets. It is sent to the source address received in the original Query which should be the same as the original Request. The UDP destination port number should be the same one sent in the original Request. An AMT Teardown from the original source address and source port is NOT valid and should be discarded if received. Use an AMT Membership Update instead. In order for the Relay to verify the Teardown message, this message must contain the original source address and source port in addition to the Original Request Nonce and Original Response MAC. In situations where NAT is used, this information can be known by the Gateway thanks to the optional Gateway information fields in the Query message (Section 6.5.6). Hence, a Relay supporting the Teardown mechanism SHOULD include the Gateway information fields in the Query messages it sends. On reception of a valid Teardown message, a Relay should remove all state corresponding to the gateway identified by the (original source address, original source port) tuple, and stop forwarding all traffic to this destination. Thaler, et al. Expires January 12, 2012 [Page 22] Internet-Draft AMT July 2011 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=0x7 | Reserved | Original Response MAC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Response MAC (continued) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Request Nonce | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Source Port | Original Source Address ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Original Source Address (ctd) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Original Source Address (ctd) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Original Source Address (ctd) ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... Original Src Addr. (ctd) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ AMT Membership Teardown 6.8.1. Type The type of the message. 6.8.2. Reserved A 8-bit reserved field. Sent as 0, ignored on receipt. 6.8.3. Original Response MAC The 48-bit MAC received in the Membership Query. 6.8.4. Original Request Nonce A 32-bit identifier corresponding to the original Request. 6.8.5. Original Source Port The 16-bit port number used in the original AMT Request message that was used to generate the Original Response MAC. 6.8.6. Original Source Address A 16-byte field containing the IP source address used in the original AMT Request message that was used to generate the Original Response MAC of the Request message that triggered this Query message. The Thaler, et al. Expires January 12, 2012 [Page 23] Internet-Draft AMT July 2011 field contains an IPv4-compatible IPv6 address ([RFC4291], section 2.5.5.1) if the address is an IPv4 address (i.e. the IPv4 address prefixed with 96 bits set to zero), or an IPv6 address. Thaler, et al. Expires January 12, 2012 [Page 24] Internet-Draft AMT July 2011 7. AMT Gateway Details This section details the behavior of an AMT Gateway, which may be a router serving an AMT site, or the site may consist of a single host, serving as its own gateway. 7.1. At Startup Time At startup time, the AMT gateway will bring up an AMT pseudo- interface to be used for encapsulation. The gateway needs to discover an AMT Relay to send Membership Requests. It can send an AMT Relay Discovery at startup time or wait until it has a group membership to report. The AMT Relay Discovery message is sent to the AMT Relay Anycast Address. A unicast address (which is treated as a link-layer address to the encapsulation interface) is received in the AMT Relay Advertisement message. The discovery process SHOULD be done periodically (e.g., once a day) to re-resolve the unicast address of a close relay. To prevent startup synchronization, the timer SHOULD use at least 10 percent jitter. If the gateway is serving as a local router, it SHOULD also function as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD host-mode interface being the AMT pseudo-interface. This enables it to translate group memberships on its downstream interfaces into IGMP/MLD Reports. Hosts receiving multicast packets through an AMT gateway acting as a proxy should ensure that their M-RIB accepts multicast packets from the AMT gateway for the sources it is joining. 7.2. Gateway identification From the point of view of a Relay, a Gateway is identified by the (IP source address, UDP source port) tuple in Membership Update messages. If an implementation of Gateway procedure was to use a different UDP source port and/or IP source address to join or leave different multicast groups, it would appear to the Relay as distinct Gateways. For instance, a Relay having forwarding state resulting in the forwarding of (S,G) to a said gateway identified by a (IP source address, UDP source port) tuple, will not remove this state if it receives an AMT Membership Update message from a different (IP source address, UDP source port) tuple. It results that a Gateway has to use the same UDP source port for AMT Request and AMT Update messages related to a same (S,G). A said Gateway instance is typically expected to use the same UDP source port and IP source address for all Request and Updates messages for all multicast groups. Thaler, et al. Expires January 12, 2012 [Page 25] Internet-Draft AMT July 2011 7.3. Joining Multicast Groups The IGMP/MLD protocol usually operates by having the Querier multicast an IGMP/MLD Query message on the link. This behavior does not work on NBMA links which do not support multicast. Since the set of gateways is typically unknown to the relay (and potentially quite large), unicasting the queries is also impractical. The following behavior is used instead. Applications residing in a gateway should join groups on the AMT pseudo-interface, causing IGMP/MLD Membership/Listener Reports to be sent over that interface. When UDP encapsulating the membership reports (and in fact any other messages, unless specified otherwise in this document), the destination address in the outer IP header is the relay's unicast address. Robustness is provided by the underlying IGMP/MLD protocol messages sent on the AMT pseudo- interface. In other words, the gateway does not need to retransmit IGMP/MLD Membership/Listener Reports and Leave/Done messages received on the pseudo-interface since IGMP/MLD will already do this. The gateway simply needs to encapsulate each IGMP/MLD Membership/Listener Report and Leave/Done message it receives. However, since periodic IGMP/MLD Membership/Listener Reports are sent in response to IGMP/MLD Queries, a mechanism to trigger periodic Membership/Listener Reports and Leave/Done messages is necessary. The gateway should use a timer to trigger periodic AMT Membership Updates. If the gateway is behind a firewall device, the firewall may require the gateway to periodically refresh the UDP state in the firewall at a shorter interval than the standard IGMP/MLD Query interval. AMT Requests can be sent periodically to solicit IGMP/MLD Queries. The interval at which the AMT Requests are sent should be configurable to ensure the firewall does not revert to blocking the UDP encapsulated IP Multicast data packets. When the AMT Query is received, it can be ignored unless it is time for a periodic AMT Membership Update. The relay can use the Querier's Robustness Variable (QRV) defined in [RFC3376] and [RFC3810] to adjust the number of Membership/Listener Reports that are sent by the host joining the group. 7.4. Responding to Relay Changes When a gateway determines that its current relay is unreachable (e.g., upon receipt of an ICMP Unreachable message [RFC0792] for the relay's unicast address), it may need to repeat relay address discovery. However, care should be taken not to abandon the current relay too quickly due to transient network conditions. Thaler, et al. Expires January 12, 2012 [Page 26] Internet-Draft AMT July 2011 8. AMT Relay Details 8.1. At Startup time At startup time, the relay router will bring up an NBMA-style AMT pseudo-interface. It shall also add the AMT Relay Anycast Address on some interface. The relay router shall then advertise the AMT Relay Anycast Prefix into the unicast-only Internet, as if it were a connection to an external network. When the advertisement is done using BGP, the AS path leading to the AMT Relay Anycast Prefix shall include the identifier of the local AS. The relay router shall also enable IGMPv3/MLDv2 on the AMT pseudo- interface, except that it shall not multicast Queries (this might be done, for example, by having the AMT pseudo-device drop them, or by having the IGMP/MLD module not send them in the first place). 8.2. Receiving Relay Discovery messages sent to the Anycast Address When a relay receives an AMT Relay Discovery message directed to the AMT Relay Anycast Address, it should respond with an AMT Relay Advertisement containing its unicast address. The source and destination addresses of the advertisement should be the same as the destination and source addresses of the discovery message respectively. Further, the nonce in the discovery message MUST be copied into the advertisement message. 8.3. Receiving Membership Updates from AMT Gateways The relay operates passively, sending no periodic IGMP/MLD Queries but simply tracking membership information according to AMT Request/ Query/Membership Update tuples received. As noted in Section 7.2, the Relay tracks Gateways based on the (IP source address, UDP source port) tuple. In addition, the relay must also do explicit membership tracking, as to which gateways on the AMT pseudo-interface have joined which groups. Once an AMT Membership Update has been successfully received, it updates the forwarding state for the appropriate group and source (if provided). When data arrives for that group, the traffic must be encapsulated, once to each (address, port) of each gateway which has joined that group or (S,G). The explicit membership tracking and unicast replication may be done in any implementation-specific manner. Some examples are: Thaler, et al. Expires January 12, 2012 [Page 27] Internet-Draft AMT July 2011 1. The AMT pseudo-device driver might track the group information and perform the replication at the "link-layer", with no changes to a pre-existing IGMP/MLD module. 2. The IGMP/MLD module might have native support for explicit membership tracking, especially if it supports other NBMA-style interfaces. If a relay wants to affect the rate at which the AMT Requests are originated from a gateway, it can tune the membership timeout by adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/ MLD Query contained within the AMT Membership Query message. The QQIC field is defined in [RFC3376] and [RFC3810]. However, since the gateway may need to send AMT Requests frequently enough to prevent firewall state from timing out, the relay may be limited in its ability to spread out Requests coming from a gateway by adjusting the QQIC field. Thaler, et al. Expires January 12, 2012 [Page 28] Internet-Draft AMT July 2011 9. IANA Considerations 9.1. IPv4 and IPv6 Anycast Prefix Allocation The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated to the public AMT Relays to advertise to the native multicast backbone. The prefix length should be determined by the IANA; the prefix should be large enough to guarantee advertisement in the default-free BGP networks. 9.1.1. IPv4 A prefix length of 16 will meet this requirement. 9.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. 9.2. UDP Port number IANA has previously allocated UDP reserved port number 2268 for AMT encapsulation. Thaler, et al. Expires January 12, 2012 [Page 29] Internet-Draft AMT July 2011 10. Security Considerations The anycast technique introduces a risk that a rogue router or a rogue AS could introduce a bogus route to the AMT Relay Anycast prefix, and thus divert the traffic. Network managers have to guarantee the integrity of their routing to the AMT Relay Anycast prefix in much the same way that they guarantee the integrity of all other routes. Gateways will accept and decapsulate multicast traffic from any source from which regular unicast traffic is accepted. If this is, for any reason, felt to be a security risk, then additional source address based packet filtering MUST be applied: a gateway MUST discard encapsulated multicast packets if the source address in the outer header is not the address of the Relay to which the encapsulated join message was sent. AMT Gateways MUST also drop non- multicast traffic incoming on an AMT pseudo-interface. AMT Relays MUST NOT process AMT Data messages. AMT Relays and Gateways MUST drop IP messages encapsulated in AMT Query and Update messages that are not IGMP/MLD messages. Even though a Relay does not need to maintain any state before completion of the three-way handshake (Section 5.2), if no mitigation is in place, it is still possible for one host to instantiate a large amount of Gateways instances that would each join one or more multicast groups to a Relay, thus resulting in a large amount of resources being used on the Relay. Thus, AMT Relays MUST be implemented so as to allow the mitigation of risks of denial of service attacks on their resources. A Relay SHOULD NOT allow the instantiation of an unbounded number of AMT pseudo-interfaces for a said gateway IP address. For instance, an implementation may provide a way to set a configurable limit on the maximum number of pseudo- interfaces to a same gateway IP address, with a default value for this limit being low enough to provide protection, and high enough to cope with the possibility of an address being shared by multiple devices. In the case where a Relay is reaching the situation where it would stop accepting to instantiate new pseudo-interfaces, it MAY stop advertising the AMT Relay Anycast address; thanks to the AMT discovery procedures, this will allow legitimate AMT Gateways to fall back on another Relay. Thaler, et al. Expires January 12, 2012 [Page 30] Internet-Draft AMT July 2011 11. Contributors The following people provided significant contributions to earlier versions of these specifications: Dirk Ooms OneSparrow Belegstraat 13; 2018 Antwerp; Belgium EMail: dirk@onesparrow.com Thaler, et al. Expires January 12, 2012 [Page 31] Internet-Draft AMT July 2011 12. Acknowledgments Most of the mechanisms described in this document are based on similar work done by the NGTrans WG for obtaining automatic IPv6 connectivity without explicit tunnels ("6to4"). Tony Ballardie provided helpful discussion that inspired this document. In addition, extensive comments were received from Pekka Savola, Greg Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John Zwiebel, Lenny Giuliano and Greg Bumgardner. Juniper Networks was instrumental in funding several versions of this draft as well as an open source implementation. Greg Shepherd suggested the inclusion of the AMT Membership Teardown message based on field experience. Contributors from AT&T provided useful inputs and ideas that were integrated into these specifications: Mark Altom, Andy Huang, Tom Imburgia, Patricia McCrink, Han Nguyen, Doug Nortz and Robert Sayko. Thaler, et al. Expires January 12, 2012 [Page 32] Internet-Draft AMT July 2011 13. References 13.1. Normative References [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002. [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [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. [I-D.ietf-6man-udpchecksums] Eubanks, M., "UDP Checksums for Tunneled Packets", draft-ietf-6man-udpchecksums-00 (work in progress), March 2011. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. 13.2. Informative References [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001. Thaler, et al. Expires January 12, 2012 [Page 33] Internet-Draft AMT July 2011 [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. [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. Thaler, et al. Expires January 12, 2012 [Page 34] Internet-Draft AMT July 2011 Authors' Addresses Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA Phone: +1 425 703 8835 Email: dthaler@microsoft.com Mohit Talwar Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA Phone: +1 425 705 3131 Email: mohitt@microsoft.com Amit Aggarwal Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA Phone: +1 425 706 0593 Email: amitag@microsoft.com Lorenzo Vicisano Qualcomm Inc. 3165 Kifer Road Santa Clara, CA 95051 USA Email: vicisano@qualcomm.com Thaler, et al. Expires January 12, 2012 [Page 35] Internet-Draft AMT July 2011 Tom Pusateri !j 2109 Mountain High Rd. Wake Forest, NC 27587 USA Email: pusateri@bangj.com Thomas Morin France Telecom - Orange 2, avenue Pierre Marzin Lannion 22300 France Phone: +33 2 96 05 3734 Email: thomas.morin@orange-ftgroup.com Thaler, et al. Expires January 12, 2012 [Page 36]