idnits 2.17.1 draft-ietf-mboned-auto-multicast-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 15, 2013) is 3931 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1014 -- Looks like a reference, but probably isn't: '2' on line 1016 -- Looks like a reference, but probably isn't: '3' on line 1019 -- Looks like a reference, but probably isn't: '4' on line 1033 -- Looks like a reference, but probably isn't: '5' on line 1035 -- Looks like a reference, but probably isn't: '6' on line 1038 -- Looks like a reference, but probably isn't: '7' on line 1042 == Missing Reference: '16-bits' is mentioned on line 3746, but not defined == Missing Reference: '128-bits' is mentioned on line 3746, but not defined -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Bumgardner 3 Internet-Draft 4 Intended status: Standards Track July 15, 2013 5 Expires: January 16, 2014 7 Automatic Multicast Tunneling 8 draft-ietf-mboned-auto-multicast-15 10 Abstract 12 This document describes Automatic Multicast Tunneling (AMT), a 13 protocol for delivering multicast traffic from sources in a 14 multicast-enabled network to receivers that lack multicast 15 connectivity to the source network. The protocol uses UDP 16 encapsulation and unicast replication to provide this functionality. 18 The AMT protocol is specifically designed to support rapid deployment 19 by requiring minimal changes to existing network infrastructure. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 16, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4 71 3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 4 72 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 73 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 74 4.1. General Architecture . . . . . . . . . . . . . . . . . . 6 75 4.1.1. Relationship to IGMP and MLD Protocols . . . . . . . 7 76 4.1.2. Gateways . . . . . . . . . . . . . . . . . . . . . . 8 77 4.1.3. Relays . . . . . . . . . . . . . . . . . . . . . . . 11 78 4.1.4. Deployment . . . . . . . . . . . . . . . . . . . . . 13 79 4.1.5. Discovery . . . . . . . . . . . . . . . . . . . . . . 15 80 4.2. General Operation . . . . . . . . . . . . . . . . . . . . 16 81 4.2.1. Message Sequences . . . . . . . . . . . . . . . . . . 16 82 4.2.2. Tunneling . . . . . . . . . . . . . . . . . . . . . . 25 83 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 30 84 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 30 85 5.1.1. Relay Discovery . . . . . . . . . . . . . . . . . . . 30 86 5.1.2. Relay Advertisement . . . . . . . . . . . . . . . . . 32 87 5.1.3. Request . . . . . . . . . . . . . . . . . . . . . . . 33 88 5.1.4. Membership Query . . . . . . . . . . . . . . . . . . 34 89 5.1.5. Membership Update . . . . . . . . . . . . . . . . . . 38 90 5.1.6. Multicast Data . . . . . . . . . . . . . . . . . . . 40 91 5.1.7. Teardown . . . . . . . . . . . . . . . . . . . . . . 42 92 5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 44 93 5.2.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 44 94 5.2.2. Pseudo-Interface Configuration . . . . . . . . . . . 46 95 5.2.3. Gateway Service . . . . . . . . . . . . . . . . . . . 47 96 5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 59 97 5.3.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 59 98 5.3.2. Startup . . . . . . . . . . . . . . . . . . . . . . . 60 99 5.3.3. Running . . . . . . . . . . . . . . . . . . . . . . . 60 100 5.3.4. Shutdown . . . . . . . . . . . . . . . . . . . . . . 71 101 5.3.5. Response MAC Generation . . . . . . . . . . . . . . . 71 102 5.3.6. Private Secret Generation . . . . . . . . . . . . . . 72 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 72 104 6.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . . 73 105 6.2. Gateways . . . . . . . . . . . . . . . . . . . . . . . . 74 106 6.3. Encapsulated IP Packets . . . . . . . . . . . . . . . . . 75 107 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 108 7.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 75 109 7.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 75 110 7.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 75 111 7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses 75 112 7.3. UDP Port Number . . . . . . . . . . . . . . . . . . . . . 75 113 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 75 114 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 76 115 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 116 10.1. Normative References . . . . . . . . . . . . . . . . . . 77 117 10.2. Informative References . . . . . . . . . . . . . . . . . 77 118 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 79 119 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 81 121 1. Introduction 123 The advantages and benefits provided by multicast technologies are 124 well known. There are a number of application areas that are ideal 125 candidates for the use of multicast, including media broadcasting, 126 video conferencing, collaboration, real-time data feeds, data 127 replication, and software updates. Unfortunately, many of these 128 applications lack multicast connectivity to networks that carry 129 traffic generated by multicast sources. The reasons for the lack of 130 connectivity vary, but are primarily the result of service provider 131 policies and network limitations. 133 Automatic Multicast Tunneling (AMT) is a protocol that uses UDP-based 134 encapsulation to overcome the aforementioned lack of multicast 135 connectivity. AMT enables sites, hosts or applications that do not 136 have native multicast access to a network with multicast connectivity 137 to a source, to request and receive SSM [RFC4607] and ASM [RFC1112] 138 traffic from a network that does provide multicast connectivity to 139 that source. 141 2. Applicability 143 This document describes a protocol that may be used to deliver 144 multicast traffic from a multicast enabled network to sites that lack 145 multicast connectivity to the source network. This document does not 146 describe any methods for sourcing multicast traffic from isolated 147 sites as this topic is out of scope. 149 AMT is not intended to be used as a substitute for native multicast, 150 especially in conditions or environments requiring high traffic flow. 151 AMT uses unicast replication to reach multiple receivers and the 152 bandwidth cost for this replication will be higher than that required 153 if the receivers were reachable via native multicast. 155 AMT is designed to be deployed at the border of networks possessing 156 native multicast capabilities where access and provisioning can be 157 managed by the AMT service provider. 159 3. Terminology 161 3.1. Requirements Notation 163 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 164 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 165 document are to be interpreted as described in [RFC2119]. 167 3.2. Definitions 169 This document adopts the following definitions for use in describing 170 the protocol: 172 Downstream: 173 A downstream interface or connection that faces away from the 174 multicast distribution root or towards multicast receivers. 176 Upstream: 177 An upstream interface or connection that faces a multicast 178 distribution root or source. 180 Non-Broadcast Multi-Access (NMBA): 181 A non-broadcast multiple-access (NBMA) network or interface is one 182 to which multiple network nodes (hosts or routers) are attached, 183 but where packets are transmitted directly from one node to 184 another node over a virtual circuit or physical link. NBMA 185 networks do not support multicast or broadcast traffic - a node 186 that sources multicast traffic must replicate the multicast 187 packets for separate transmission to each node that has requested 188 the multicast traffic. 190 Multicast Receiver: 191 An entity that requests and receives multicast traffic. A 192 receiver may be a router, host, application, or application 193 component. The method by which a receiver transmits group 194 membership requests and receives multicast traffic varies 195 according to receiver type. 197 Group Membership Database: 198 A group membership database describes the current multicast 199 subscription state for an interface or system. See Section 3 in 200 [RFC3376] for a detailed definition. 202 Reception State: 203 The multicast subscription state of a pseudo, virtual or physical 204 network interface. Often synonymous with group membership 205 database. 207 Subscription: 208 A group or state entry in a group membership database or reception 209 state table. The presence of a subscription entry indicates 210 membership in an IP multicast group. 212 Group Membership Protocol: 213 The term "group membership protocol" is used as a generic 214 reference to the Internet Group Management (IGMP) ([RFC1112], 215 [RFC2236], [RFC3376]) or Multicast Listener Discovery ([RFC2710], 216 [RFC3810]) protocols. 218 Multicast Protocol: 219 The term "multicast protocol" is used as a generic reference to 220 multicast routing protocols used to join or leave multicast 221 distribution trees such as PIM-SM [RFC4601]. 223 Network Address Translation (NAT): 224 Network Address Translation is the process of modifying the source 225 IP address and port numbers carried by an IP packet while 226 transiting a network node (See [RFC2663]). Intervening NAT 227 devices may change the source address and port carried by messages 228 sent from an AMT gateway to an AMT relay, possibly producing 229 changes in protocol state and behavior. 231 Anycast: 232 A network addressing and routing method in which packets from a 233 single sender are routed to the topologically nearest node in a 234 group of potential receivers all identified by the same 235 destination address. See [RFC4786]. 237 3.3. Abbreviations 239 AMT - Automatic Multicast Tunneling Protocol. 241 ASM - Any-Source Multicast. 243 DoS - Denial-of-Service (attack) and DDoS for distributed-DoS. 245 IGMP - Internet Group Management Protocol (v1, v2 and v3). 247 IP - Internet Protocol (v4 and v6). 249 MAC - Message Authentication Code (or Cookie). 251 MLD - Multicast Listener Discovery protocol (v1 and v2). 253 NAT - Network Address Translation (or translation node). 255 NBMA - Non-Broadcast Multi-Access (network, interface or mode) 257 SSM - Source-Specific Multicast. 259 PIM - Protocol Independent Multicast. 261 4. Protocol Overview 263 This section provides an informative description of the protocol. A 264 normative description of the protocol and implementation requirements 265 may be found in section Section 5. 267 4.1. General Architecture 269 Isolated Site | Unicast Network | Native Multicast 270 | (Internet) | 271 | | 272 | | 273 | Group Membership | 274 +-------+ =========================> +-------+ Multicast +------+ 275 |Gateway| | | | Relay |<----//----|Source| 276 +-------+ <========================= +-------+ +------+ 277 | Multicast Data | 278 | | 279 | | 281 Figure 1: Basic AMT Architecture 283 The AMT protocol employs a client-server model in which a "gateway" 284 sends requests to receive specific multicast traffic to a "relay" 285 which responds by delivering the requested multicast traffic back to 286 the gateway. 288 Gateways are generally deployed within networks that lack multicast 289 support or lack connectivity to a multicast-enabled network 290 containing multicast sources of interest. 292 Relays are deployed within multicast-enabled networks that contain, 293 or have connectivity to, multicast sources. 295 4.1.1. Relationship to IGMP and MLD Protocols 297 AMT relies on the Internet Group Management (IGMP) [RFC3376] and 298 Multicast Listener Discovery (MLD) [RFC3810] protocols to provide the 299 functionality required to manage, communicate, and act on changes in 300 multicast group membership. A gateway or relay implementation does 301 not necessarily require a fully-functional, conforming implementation 302 of IGMP or MLD to adhere to this specification, but the protocol 303 description that appears in this document assumes that this is the 304 case. The minimum functional and behavioral requirements for the 305 IGMP and MLD protocols are described in Section 5.2.1 and 306 Section 5.3.1. 308 Gateway Relay 310 General _____ _____ 311 ___________ Query | | | | Query ___________ 312 | |<------| | | |<------| | 313 | Host Mode | | AMT | | AMT | |Router Mode| 314 | IGMP/MLD | | | UDP | | | IGMP/MLD | 315 |___________|------>| |<----->| |------>|___________| 316 Report | | | | Report 317 Leave/Done | | | | Leave/Done 318 | | | | 319 IP Multicast <------| | | |<------ IP Multicast 320 |_____| |_____| 322 Figure 2: Multicast Reception State Managed By IGMP/MLD 324 A gateway runs the host portion of the IGMP and MLD protocols to 325 generate group membership updates that are sent via AMT messages to a 326 relay. A relay runs the router portion of the IGMP and MLD protocols 327 to process the group membership updates to produce the required 328 changes in multicast forwarding state. A relay uses AMT messages to 329 send incoming multicast IP datagrams to gateways according to their 330 current group membership state. 332 The primary function of AMT is to provide the handshaking, 333 encapsulation and decapsulation required to transport the IGMP and 334 MLD messages and multicast IP datagrams between the gateways and 335 relays. The IGMP and MLD messages that are exchanged between 336 gateways and relays are encapsulated as complete IP datagrams within 337 AMT control messages. Multicast IP datagrams are replicated and 338 encapsulated in AMT data messages. All AMT messages are sent via 339 unicast UDP/IP. 341 4.1.2. Gateways 343 The downstream side of a gateway services one or more receivers - the 344 gateway accepts group membership requests from receivers and forwards 345 requested multicast traffic back to those receivers. The gateway 346 functionality may be directly implemented in the host requesting the 347 multicast service or within an application running on a host. 349 The upstream side of a gateway connects to relays. A gateway sends 350 encapsulated IGMP and MLD messages to a relay to indicate an interest 351 in receiving specific multicast traffic. 353 4.1.2.1. Architecture 355 Each gateway possesses a logical pseudo-interface: 357 join/leave ---+ +----------+ 358 | | | 359 V IGMPv3/MLDv2 | | 360 +---------+ General Query| | AMT 361 |IGMP/MLD |<-------------| AMT | Messages +------+ 362 |Host Mode| | Gateway |<-------->|UDP/IP| 363 |Protocol |------------->|Pseudo I/F| +------+ 364 +---------+ IGMP/MLD | | ^ 365 Report | | | 366 Leave/Done | | V 367 IP Multicast <---------------------| | +---+ 368 +----------+ |I/F| 369 +---+ 371 Figure 3: AMT Gateway Pseudo-Interface 373 The pseudo-interface is conceptually a network interface on which the 374 gateway executes the host portion of the IPv4/IGMP (v2 or v3) and 375 IPv6/MLD (v1 or v2) protocols. The multicast reception state of the 376 pseudo-interface is manipulated using the IGMP or MLD service 377 interface. The IGMP and MLD host protocols produce IP datagrams 378 containing group membership messages that the gateway will send to 379 the relay. The IGMP and MLD protocols also supply the retransmission 380 and timing behavior required for protocol robustness. 382 All AMT encapsulation, decapsulation and relay interaction is assumed 383 to occur within the pseudo-interface. 385 A gateway host or application may create separate interfaces for IPv4 386 /IGMP and IPv6/MLD. A gateway host or application may also require 387 additional pseudo-interfaces for each source or domain-specific relay 388 address. 390 Within this document, the term "gateway" may be used as a generic 391 reference to an entity executing the gateway protocol, a gateway 392 pseudo-interface, or a gateway device that has one or more interfaces 393 connected to a unicast inter-network and one or more AMT gateway 394 pseudo-interfaces. 396 The following diagram illustrates how an existing host IP stack 397 implementation might be used to provide AMT gateway functionality to 398 a multicast application: 400 +-----------------------------------------------------+ 401 |Host | 402 | ______________________________________ | 403 | | | | 404 | | ___________________________ | | 405 | | | | | | 406 | | | v | | 407 | | | +-----------+ +--------------+ | 408 | | | |Application| | AMT Daemon | | 409 | | | +-----------+ +--------------+ | 410 | | | join/leave | ^ data ^ AMT | 411 | | | | | | | 412 | | | +----|---|-------------|-+ | 413 | | | | __| |_________ | | | 414 | | | | | | | | | 415 | | | | | Sockets | | | | 416 | | | +-|------+-------+-|---|-+ | 417 | | | | | IGMP | TCP | |UDP| | | 418 | | | +-|------+-------+-|---|-+ | 419 | | | | | ^ IP | | | | 420 | | | | | | ____________| | | | 421 | | | | | | | | | | 422 | | | +-|-|-|----------------|-+ | 423 | | | | | | | | 424 | | | IP(IGMP)| | |IP(UDP(data)) |IP(UDP(AMT)) | 425 | | | v | | v | 426 | | | +-----------+ +---+ | 427 | | | |Virtual I/F| |I/F| | 428 | | | +-----------+ +---+ | 429 | | | | ^ ^ | 430 | | | IP(IGMP)| |IP(UDP(data)) | | 431 | | |_________| |IP(IGMP) | | 432 | | | | | 433 | |_________________| | | 434 | | | 435 +--------------------------------------|--------------+ 436 v 437 AMT Relay 439 Figure 4: Virtual Interface Implementation Example 441 In this example, the host IP stack uses a virtual network interface 442 to interact with a gateway pseudo-interface implementation. 444 4.1.2.2. Use-Cases 446 Use-cases for gateway functionality include: 448 IGMP/MLD Proxy 449 An IGMP/MLD proxy that runs AMT on an upstream interface and 450 router-mode IGMP/MLD on downstream interfaces to provide host 451 access to multicast traffic via the IGMP and MLD protocols. 453 Virtual Network Interface 454 A virtual network interface or pseudo network device driver that 455 runs AMT on a physical network interface to provide socket layer 456 access to multicast traffic via the IGMP/MLD service interface 457 provided by the host IP stack. 459 Application 460 An application or application component that implements and 461 executes IGMP/MLD and AMT internally to gain access to multicast 462 traffic. 464 4.1.3. Relays 466 The downstream side of a relay services gateways - the relay accepts 467 encapsulated IGMP and MLD group membership messages from gateways and 468 encapsulates and forwards the requested multicast traffic back to 469 those gateways. 471 The upstream side of a relay communicates with a native multicast 472 infrastructure - the relay sends join and prune/leave requests 473 towards multicast sources and accepts requested multicast traffic 474 from those sources. 476 4.1.3.1. Architecture 478 Each relay possesses a logical pseudo-interface: 480 +------------------------------+ 481 +--------+ | Multicast Control Plane | 482 | |IGMP/MLD| | 483 | | Query* | +------------+ +----------+ | 484 | |<---//----|IGMPv3/MLDv2| |Multicast | | 485 AMT | | | |Router Mode |->|Routing |<-> 486 +------+ Messages | AMT |----//--->|Protocol | |Protocol | | 487 |UDP/IP|<-------->| Relay |IGMP/MLD| +------------+ +----------+ | 488 +------+ | Pseudo | Report | | | | 489 ^ | I/F | Leave/ +------|---------------|-------+ 490 | | | Done | | 491 | | | v | 492 V | | IP +-----------+ | 493 +---+ | | Multicast |Multicast |<------+ 494 |I/F| | |<---//-----|Forwarding | 495 +---+ +--------+ |Plane |<--- IP Multicast 496 +-----------+ 498 * Queries, if generated, are consumed by the pseudo-interface. 500 Figure 5: AMT Relay Pseudo-Interface (Router-Based) 502 The pseudo-interface is conceptually a network interface on which the 503 relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2 504 protocols. Relays do not send unsolicited IGMPv3/MLDv2 query 505 messages to gateways so relays must consume or discard any local 506 queries normally generated by IGMPv3 or MLDv2. Note that the 507 protocol mandates the use of IGMPv3 and MLDv2 for query messages. 508 The AMT protocol is primarily intended for use in SSM applications 509 and relies on several values provided by IGMPv2/MLDv2 to control 510 gateway behavior. 512 A relay maintains group membership state for each gateway connected 513 through the pseudo-interface as well as for the entire pseudo- 514 interface (if multiple gateways are managed via a single interface). 515 Multicast packets received on upstream interfaces on the relay are 516 routed to the pseudo-interface where they are replicated, 517 encapsulated and sent to interested gateways. Changes in the pseudo- 518 interface group membership state may trigger the transmission of 519 multicast protocol requests upstream towards a given source or 520 rendezvous point and cause changes in internal routing/forwarding 521 state. 523 The relay pseudo-interface is a architectural abstraction used to 524 describe AMT protocol operation. For the purposes of this document, 525 the pseudo-interface is most easily viewed as an interface to a 526 single gateway - encapsulation, decapsulation, and other AMT-specific 527 processing occurs "within" the pseudo-interface while forwarding and 528 replication occur outside of it. 530 An alternative view is to treat the pseudo-interface as a non- 531 broadcast multi-access (NBMA) network interface whose link layer is 532 the unicast-only network over which AMT messages are exchanged with 533 gateways. Individual gateways are conceptually treated as logical 534 NBMA links on the interface. In this architectural model, group 535 membership tracking, replication and forwarding functions occur in 536 the pseudo-interface. 538 This document does not specify any particular architectural solution 539 - a relay developer may choose to implement and distribute protocol 540 functionality as required to take advantage of existing relay 541 platform services and architecture. 543 Within this document, the term "relay" may be used as a generic 544 reference to an entity executing the relay protocol, a relay pseudo- 545 interface, or a relay device that has one or more network interfaces 546 with multicast connectivity to a native multicast infrastructure, 547 zero or more interfaces connected to a unicast inter-network, and one 548 or more relay pseudo-interfaces. 550 4.1.3.2. Use-Cases 552 Use-cases for relay functionality include: 554 Multicast Router 555 A multicast router that runs AMT on a downstream interface to 556 provide gateway access to multicast traffic. A "relay router" 557 uses a multicast routing protocol (e.g. PIM-SM RFC4601 [RFC4601]) 558 to construct a forwarding path for multicast traffic by sending 559 join and prune messages to neighboring routers to join or leave 560 multicast distribution trees for a given SSM source or ASM 561 rendezvous point. 563 IGMP/MLD Proxy Router 564 An IGMP/MLD proxy that runs AMT on a downstream interface and 565 host-mode IGMPv3/MLDv2 on a upstream interface. This "relay 566 proxy" sends group membership reports to a local, multicast- 567 enabled router to join and leave specific SSM or ASM groups. 569 4.1.4. Deployment 570 The AMT protocol calls for a relay deployment model that uses anycast 571 addressing [RFC1546][RFC4291] to pair gateways with relays. 573 Under this approach, one or more relays advertise a route for the 574 same IP address prefix. To find a relay with which to communicate, a 575 gateway sends a message to an anycast IP address within that prefix. 576 This message is routed to the topologically-nearest relay that has 577 advertised the prefix. The relay that receives the message responds 578 by sending its unicast address back to the gateway. The gateway uses 579 this address as the destination address for any messages it 580 subsequently sends to the relay. 582 The use of anycast addressing provides the following benefits: 584 o Relays may be deployed at multiple locations within a single 585 multicast-enabled network. Relays might be installed "near" 586 gateways to reduce bandwidth requirements, latency and limit the 587 number of gateways that might be serviced by a single relay. 589 o Relays may be added or removed at any time thereby allowing staged 590 deployment, scaling and hot-swapping - the relay discovery process 591 will always return the nearest operational relay. 593 o Relays may take themselves offline when they exhaust resources 594 required to service additional gateways. Existing gateway 595 connections may be preserved, but new gateway requests would be 596 routed to the next-nearest relay. 598 4.1.4.1. Public Versus Private 600 Ideally, the AMT protocol would provide a universal solution for 601 connecting receivers to multicast sources - that any gateway could be 602 used to access any globally advertised multicast source via publicly- 603 accessible, widely-deployed relays. Unfortunately, today's Internet 604 does not yet allow this, because many relays will lack native 605 multicast access to sources even though they may be globally 606 accessible via unicast. 608 In these cases, a provider may deploy relays within their own source 609 network to allow for multicast distribution within that network. 610 Gateways that use these relays must use a provider-specific relay 611 discovery mechanism or a private anycast address to obtain access to 612 these relays. 614 4.1.4.2. Congestion Considerations 616 AMT relies on UDP to provide best-effort delivery of multicast data 617 to gateways. Neither AMT or the UDP protocol provide the congestion 618 control mechanisms required to regulate the flow of data messages 619 passing through a network. While congestion remediation might be 620 provided by multicast receiver applications via multicast group 621 selection or upstream reporting mechanisms, there are no means by 622 which to ensure such mechanisms are employed. To limit the possible 623 congestion across a network or wider Internet, AMT service providers 624 are expected to deploy AMT relays near the provider's network border 625 and its interface with edge routers. The provider must limit relay 626 address advertisements to those edges to prevent distant gateways 627 from being able to access a relay and potentially generate flows that 628 consume or exceed the capacity of intervening links. 630 4.1.5. Discovery 632 To execute the gateway portion of the protocol, a gateway requires a 633 unicast IP address of an operational relay. This address may be 634 obtained using a number of methods - it may be statically assigned or 635 dynamically chosen via some form of relay discovery process. 637 As described in the previous section, the AMT protocol provides a 638 relay discovery method that relies on anycast addressing. Gateways 639 are not required to use AMT relay discovery, but all relay 640 implementations must support it. 642 The AMT protocol uses the following terminology when describing the 643 discovery process: 645 Relay Discovery Address Prefix: 646 The anycast address prefix used to route discovery messages to a 647 relay. 649 Relay Discovery Address: 650 The anycast destination address used when sending discovery 651 messages. 653 Relay Address: 654 The unicast IP address obtained as a result of the discovery 655 process. 657 4.1.5.1. Relay Discovery Address Selection 659 The selection of an anycast Relay Discovery Address may be source- 660 dependent, as a relay located via relay discovery must have multicast 661 connectivity to a desired source. 663 Similarly, the selection of a unicast Relay Address may be source- 664 dependent, as a relay contacted by a gateway to supply multicast 665 traffic must have native multicast connectivity to the traffic source 666 Methods that might be used to perform source-specific or group- 667 specific relay selection are highly implementation-dependent and are 668 not further addressed by this document. Possible approaches include 669 the use of static lookup tables, DNS-based queries, or a provision of 670 a service interface that accepts join requests on (S,G,relay- 671 discovery-address) or (S,G,relay-address) tuples. 673 4.1.5.2. IANA-Assigned Relay Discovery Address Prefix 675 IANA has assigned an address prefix for use in advertising and 676 discovering publicly accessible relays. 678 A relay discovery address is constructed from the address prefix by 679 setting the low-order octet of the prefix address to 1 (for both IPv4 680 and IPv6). 682 Public relays must advertise a route to the address prefix (e.g. via 683 BGP [RFC4271]) and configure an interface to respond to the relay 684 discovery address. 686 The IANA address assignments are discussed in Section 7. 688 4.2. General Operation 690 4.2.1. Message Sequences 692 The AMT protocol defines the following messages for control and 693 encapsulation. These messages are exchanged as UDP/IP datagrams, one 694 message per datagram. 696 Relay Discovery: 697 Sent by gateways to solicit a Relay Advertisement from any relay. 698 Used to find a relay with which to communicate. 700 Relay Advertisement: 701 Sent by relays as a response to a Relay Discovery message. Used 702 to deliver a relay address to a gateway. 704 Request: 705 Sent by gateways to solicit a Membership Query message from a 706 relay. 708 Membership Query: 709 Sent by relays as a response to a Request message. Used to 710 deliver an encapsulated IGMPv3 or MLDv2 query message to the 711 gateway. 713 Membership Update: 715 Sent by gateways to deliver an encapsulated IGMP or MLD report/ 716 leave/done message to a relay. 718 Multicast Data: 719 Sent by relays to deliver an encapsulated IP multicast datagram or 720 datagram fragment to a gateway. 722 Teardown: 723 Sent by gateways to stop the delivery of Multicast Data messages 724 requested in an earlier Membership Update message. 726 The following sections describe how these messages are exchanged to 727 execute the protocol. 729 4.2.1.1. Relay Discovery Sequence 731 Gateway Relay 732 ------- ----- 733 : : 734 | | 735 [1] |Relay Discovery | 736 |------------------->| 737 | | 738 | Relay Advertisement| [2] 739 |<-------------------| 740 [3] | | 741 : : 743 Figure 6: AMT Relay Discovery Sequence 745 The following sequence describes how the Relay Discovery and Relay 746 Advertisement messages are used to find a relay with which to 747 communicate: 749 1. The gateway sends a Relay Discovery message containing a random 750 nonce to the Relay Discovery Address. If the Relay Discovery 751 Address is an anycast address, the message is routed to 752 topologically-nearest network node that advertises that address. 754 2. The node receiving the Relay Discovery message sends a Relay 755 Advertisement message back to the source of the Relay Discovery 756 message. The message carries a copy of the nonce contained in 757 the Relay Discovery message and the unicast IP address of a 758 relay. 760 3. When the gateway receives the Relay Advertisement message it 761 verifies that the nonce matches the one sent in the Relay 762 Discovery message, and if it does, uses the relay address carried 763 by the Relay Advertisement as the destination address for 764 subsequent AMT messages. 766 Note that the responder need not be a relay - the responder may 767 obtain a relay address by some other means and return the result in 768 the Relay Advertisement (i.e., the responder is a load-balancer or 769 broker). 771 4.2.1.2. Membership Update Sequence 773 There exists a significant difference between normal IGMP and MLD 774 behavior and that required by AMT. An IGMP/MLD router acting as a 775 querier normally transmits query messages on a network interface to 776 construct and refresh group membership state for the connected 777 network. These query messages are multicast to all IGMP/MLD enabled 778 hosts on the network. Each host responds by multicasting report 779 messages that describe their current multicast reception state. 781 However, AMT does not allow relays to send unsolicited query messages 782 to gateways, as the set of active gateways may be unknown to the 783 relay and potentially quite large. Instead, AMT requires each 784 gateway to periodically send a message to a relay to solicit a 785 general-query response. A gateway accomplishes this by sending a 786 Request message to a relay. The relay responds by sending Membership 787 Query message back to the gateway. The Membership Query message 788 carries an encapsulated general query that is processed by the IGMP 789 or MLD protocol implementation on the gateway to produce a membership 790 /listener report. Each time the gateway receives a Membership Query 791 message it starts a timer whose expiration will trigger the start of 792 a new Request->Membership Query message exchange. This timer-driven 793 sequence is used to mimic the transmission of a periodic general 794 query by an IGMP/MLD router. This query cycle may continue 795 indefinitely once started by sending the initial Request message. 797 A membership update occurs when an IGMP or MLD report, leave or done 798 message is passed to the gateway pseudo-interface. These messages 799 may be produced as a result of the aforementioned general-query 800 processing or as a result of receiver interaction with the IGMP/MLD 801 service interface. Each report is encapsulated and sent to the relay 802 after the gateway has successfully established communication with the 803 relay via a Request and Membership Query message exchange. If a 804 report is passed to the pseudo-interface before the gateway has 805 received a Membership Query message from the relay, the gateway may 806 discard the report or queue the report for delivery after a 807 Membership Query is received. Subsequent IGMP/MLD report/leave/done 808 messages that are passed to the pseudo-interface are immediately 809 encapsulated and transmitted to the relay. 811 IGMP/MLD Pseudo-I/F Relay 812 -------- ---------- ----- 813 : : : 814 | | Request | 815 | 1|-------------------->| 816 | | Membership Query |2 817 Query | | Q(0,{}) | 818 Timer | Start 3|<--------------------| 819 (QT)<--------------------------| | 820 | Q(0,{}) | | 821 |<--------------------| | 822 4| R({}) | Membership Update | 823 |-------------------->|5 R({}) | 824 | |====================>|6a 825 Join(S,G) : : : 826 ()-------->|7 R({G:ALLOW({S})}) | Membership Update | 827 |-------------------->|8 R({G:ALLOW({S})}) | 828 | |====================>|9a Join(S,G) 829 | | |---------->() 830 : : : 831 | ------------|---------------------|------------ 832 | | | | | 833 | | | Multicast Data | IP(S,G) | 834 | | | IP(S,G) 10|<--------() | 835 | | IP(S,G) 11|<====================| | 836 | | ()<--------| | | 837 | | | | | 838 : ------------:---------------------:------------ 839 | Expired | | 840 (QT)-------------------------->|12 Request | 841 | 1|-------------------->| 842 | | Membership Query |2 843 | | Q(0,{}) | 844 | Start 3|<--------------------| 845 (QT)<--------------------------| | 846 | Q(0,{}) | | 847 |<--------------------| | 848 4| R({G:INCLUDE({S})}) | Membership Update | 849 |-------------------->|5 R({G:INCLUDE({S})})| 850 | |====================>|6b 851 Leave(S,G) : : : 852 ()-------->|7 R({G:BLOCK({S})}) | Membership Update | 853 |-------------------->|8 R({G:BLOCK({S})}) | 854 | |====================>|9b Prune(S,G) 855 | | |---------->() 856 : : : 858 Figure 7: Membership Update Sequence (IGMPv3/MLDv2 Example) 860 The following sequence describes how the Request, Membership Query, 861 and Membership Update messages are used to report current group 862 membership state or changes in group membership state: 864 1. A gateway sends a Request message to the relay that contains a 865 random nonce and a flag indicating whether the relay should 866 return an IGMPv3 or MLDv2 general query. 868 2. When the relay receives a Request message, it generates a 869 message authentication code (MAC) by computing a hash value from 870 message source IP address, source UDP port, request nonce and a 871 private secret. The relay then sends a Membership Query message 872 to the gateway that contains the request nonce, the MAC, and an 873 IGMPv3 or MLDv2 general query. 875 3. When the gateway receives a Membership Query message, it 876 verifies that the request nonce matches the one sent in the last 877 Request, and if it does, the gateway saves the request nonce and 878 MAC for use in sending subsequent Membership Update messages. 879 The gateway starts a timer whose expiration will trigger the 880 transmission of a new Request message and extracts the 881 encapsulated general query message for processing by the IGMP or 882 MLD protocol. The query timer duration is specified by the 883 relay in the Querier's Query Interval Code (QQIC) field in the 884 IGMPv3 or MLDv2 general query. The QQIC field is defined in 885 Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810]). 887 4. The gateway's IGMP or MLD protocol implementation processes the 888 general query to produce a current-state report. 890 5. When an IGMP or MLD report is passed to the pseudo-interface, 891 the gateway encapsulates the report in a Membership Update 892 message and sends it to the relay. The request nonce and MAC 893 fields in the Membership Update are assigned the values from the 894 last Membership Query message received for the corresponding 895 group membership protocol (IGMPv3 or MLDv2). 897 6. When the relay receives a Membership Update message, it computes 898 a MAC from the message source IP address, source UDP port, 899 request nonce and a private secret. The relay accepts the 900 Membership Update message if the received MAC matches the 901 computed MAC, otherwise the message is ignored. If the message 902 is accepted, the relay may proceed to allocate, refresh, or 903 modify tunnel state. This includes making any group membership, 904 routing and forwarding state changes and issuing any upstream 905 protocol requests required to satisfy the state change. The 906 diagram illustrates two scenarios: 908 a. The gateway has not previously reported any group 909 subscriptions and the report does not contain any group 910 subscriptions, so the relay takes no action. 912 b. The gateway has previously reported a group subscription so 913 the current-state report lists all current subscriptions. 914 The relay responds by refreshing tunnel or group state and 915 resetting any related timers. 917 7. A receiver indicates to the gateway that it wishes to join 918 (allow) or leave (block) specific multicast traffic. This 919 request is typically made using some form IGMP/MLD service 920 interface (as described in Section 2 of [RFC3376] or Section 3 921 of [RFC3810]). The IGMP/MLD protocol responds by generating an 922 IGMP or MLD state-change message. 924 8. When an IGMP or MLD report/leave/done message is passed to the 925 pseudo-interface, the gateway encapsulates the message in a 926 Membership Update message and sends it to the relay. The 927 request nonce and MAC fields in the Membership Update are 928 assigned the values from the last Membership Query message 929 received for the corresponding group membership protocol (IGMP 930 or MLD). 932 The IGMP and MLD protocols may generate multiple messages to 933 provide robustness against packet loss - each of these must be 934 encapsulated in a new Membership Update message and sent to the 935 relay. The Querier Robustness Variable (QRV) field in the last 936 IGMP/MLD query delivered to the IGMP/MLD protocol is typically 937 used to specify the number of repetitions (i.e., the host adopts 938 the QRV value as its own Robustness Variable value). The QRV 939 field is defined in Section 4.1.6 in [RFC3376] and Section 5.1.8 940 in [RFC3810]. 942 9. When the relay receives a Membership Update message, it again 943 computes a MAC from the message source IP address, source UDP 944 port, request nonce and a private secret. The relay accepts the 945 Membership Update message if the received MAC matches the 946 computed MAC, otherwise the message is ignored. If the message 947 is accepted, the relay processes the encapsulated IGMP/MLD and 948 allocates, modifies or deletes tunnel state accordingly. This 949 includes making any group membership, routing and forwarding 950 state changes and issuing any upstream protocol requests 951 required to satisfy the state change. The diagram illustrates 952 two scenarios: 954 a. The gateway wishes to add a group subscription. 956 b. The gateway wishes to delete a previously reported group 957 subscription. 959 10. Multicast datagrams transmitted from a source travel through the 960 native multicast infrastructure to the relay. When the relay 961 receives a multicast IP datagram that carries a source and 962 destination address for which a gateway has expressed an 963 interest in receiving (via the Membership Update message), it 964 encapsulates the datagram into a Multicast Data message and 965 sends it to the gateway using the source IP address and UDP port 966 carried by the Membership Update message as the destination 967 address. 969 11. When the gateway receives a Multicast Data message, it extracts 970 the multicast packet from the message and passes it on to the 971 appropriate receivers. 973 12. When the query timer expires the gateway sends a new Request 974 message to the relay to start a new membership update cycle. 976 The MAC-based source-authentication mechanism described above 977 provides a simple defense against malicious attempts to exhaust relay 978 resources via source-address spoofing. Flooding a relay with spoofed 979 Request or Membership Update messages may consume computational 980 resources and network bandwidth, but will not result in the 981 allocation of state because the Request message is stateless and 982 spoofed Membership Update messages will fail source-authentication 983 and be rejected by the relay. 985 A relay will only allocate new tunnel state if the IGMP/MLD report 986 carried by the Membership Update message creates one or more group 987 subscriptions. 989 A relay deallocates tunnel state after one of the following events; 990 the gateway sends a Membership Update message containing a report 991 that results in the deletion of all remaining group subscriptions, 992 the IGMP/MLD state expires (due to lack of refresh by the gateway), 993 or the relay receives a valid Teardown message from the gateway (See 994 Section 4.2.1.3). 996 A gateway that accepts or reports group subscriptions for both IPv4 997 and IPv6 addresses will send separate Request and Membership Update 998 messages for each protocol (IPv4/IGMP and IPv6/MLD). 1000 4.2.1.3. Teardown Sequence 1002 A gateway sends a Teardown message to a relay to request that it stop 1003 delivering Multicast Data messages to a tunnel endpoint created by an 1004 earlier Membership Update message. This message is intended to be 1005 used following a gateway address change (See Section 4.2.2.1) to stop 1006 the transmission of undeliverable or duplicate multicast data 1007 messages. Gateway support for the Teardown message is optional - 1008 gateways are not required to send them and may instead relay on group 1009 membership to expire on the relay. 1011 Gateway Relay 1012 ------- ----- 1013 : Request : 1014 [1] | N | 1015 |---------------------->| 1016 | Membership Query | [2] 1017 | N,MAC,gADDR,gPORT | 1018 |<======================| 1019 [3] | Membership Update | 1020 | ({G:INCLUDE({S})}) | 1021 |======================>| 1022 | | 1023 ---------------------:-----------------------:--------------------- 1024 | | | | 1025 | | *Multicast Data | *IP Packet(S,G) | 1026 | | gADDR,gPORT |<-----------------() | 1027 | *IP Packet(S,G) |<======================| | 1028 | ()<-----------------| | | 1029 | | | | 1030 ---------------------:-----------------------:--------------------- 1031 ~ ~ 1032 ~ Request ~ 1033 [4] | N' | 1034 |---------------------->| 1035 | Membership Query | [5] 1036 | N',MAC',gADDR',gPORT' | 1037 |<======================| 1038 [6] | | 1039 | Teardown | 1040 | N,MAC,gADDR,gPORT | 1041 |---------------------->| 1042 | | [7] 1043 | Membership Update | 1044 | ({G:INCLUDE({S})}) | 1045 |======================>| 1046 | | 1047 ---------------------:-----------------------:--------------------- 1048 | | | | 1049 | | *Multicast Data | *IP Packet(S,G) | 1050 | | gADDR',gPORT' |<-----------------() | 1051 | *IP Packet (S,G) |<======================| | 1052 | ()<-----------------| | | 1053 | | | | 1054 ---------------------:-----------------------:--------------------- 1055 | | 1056 : : 1058 Figure 8: Teardown Message Sequence (IGMPv3/MLDv2 Example) 1060 The following sequence describes how the Membership Query and 1061 Teardown message are used to detect an address change and stop the 1062 delivery of Multicast Data messages to an address: 1064 1. A gateway sends a Request message containing a random nonce to 1065 the relay. 1067 2. The relay sends a Membership Query message to the gateway that 1068 contains the source IP address (gADDR) and source UDP port 1069 (gPORT) values from the Request message. These values will be 1070 used to identify the tunnel should one be created by a subsequent 1071 Membership Update message. 1073 3. When the gateway receives a Membership Query message that carries 1074 the gateway address fields, it compares the gateway IP address 1075 and port number values with those received in the previous 1076 Membership Query (if any). If these values do not match, this 1077 indicates that the Request message arrived at the relay carrying 1078 a different source address than the one sent previously. At this 1079 point in the sequence, no change in source address or port has 1080 occurred. 1082 4. The gateway sends a new Request message to the relay. However, 1083 this Request message arrives at the relay carrying a different 1084 source address than that of the previous Request due to some 1085 change in network interface, address assignment, network topology 1086 or NAT mapping. 1088 5. The relay again responds by sending a Membership Query message to 1089 the gateway that contains the new source IP address (gADDR') and 1090 source UDP port (gPORT') values from the Request message. 1092 6. When the gateway receives the Membership Query message, it 1093 compares the gateway address and port number values against those 1094 returned in the previous Membership Query message. 1096 7. If the reported address or port has changed, the gateway sends a 1097 Teardown message to the relay that contains the request nonce, 1098 MAC, gateway IP address and gateway port number returned in the 1099 earlier Membership Query message. The gateway may send the 1100 Teardown message multiple times where the number of repetitions 1101 is governed by the Querier Robustness Variable (QRV) value 1102 contained in the IGMPv3/MLDv2 general query carried by the 1103 original Membership Query (See Section 4.1.6 in [RFC3376] and 1104 Section 5.1.8 in [RFC3810]). The gateway continues to process 1105 the new Membership Query message as usual. 1107 8. When the relay receives a Teardown message, it computes a MAC 1108 from the message source IP address, source UDP port, request 1109 nonce and a private secret. The relay accepts the Teardown 1110 message if the received MAC matches the computed MAC, otherwise 1111 the message is ignored. If the message is accepted, the relay 1112 makes any group membership, routing and forwarding state changes 1113 required to stop the transmission of Multicast Data messages to 1114 that address. 1116 4.2.1.4. Timeout and Retransmission 1118 The AMT protocol does not establish any requirements regarding what 1119 actions a gateway should take if it fails to receive a response from 1120 a relay. A gateway implementation may wait for an indefinite period 1121 of time to receive a response, may set a time limit on how long to 1122 wait for a response, may retransmit messages should the time limit be 1123 reached, may limit the number of retransmissions, or may simply 1124 report an error. 1126 For example, a gateway may retransmit a Request message if it fails 1127 to receive a Membership Query or expected Multicast Data messages 1128 within some time period. If the gateway fails to receive any 1129 response to a Request after several retransmissions or within some 1130 maximum period of time, it may reenter the relay discovery phase in 1131 an attempt to find a new relay. This topic is addressed in more 1132 detail in Section 5.2. 1134 4.2.2. Tunneling 1136 From the standpoint of a relay, an AMT "tunnel" is identified by the 1137 IP address and UDP port pair used as the destination address for 1138 sending encapsulated multicast IP datagrams to a gateway. This 1139 address is referred here as the tunnel endpoint address. 1141 A gateway sends a Membership Update message to a relay to add or 1142 remove group subscriptions to a tunnel endpoint. The tunnel endpoint 1143 is identified by the source IP address and source UDP port carried by 1144 the Membership Update message when it arrives at a relay (this 1145 address may differ from that carried by the message when it exited 1146 the gateway as a result of network address translation). 1148 The Membership Update messages sent by a single gateway host may 1149 originate from several source addresses or ports - each unique 1150 combination represents a unique tunnel endpoint. A single gateway 1151 host may legitimately create and accept traffic on multiple tunnel 1152 endpoints, e.g., the gateway may use separate ports for the IPv4/IGMP 1153 and IPv6/MLD protocols. 1155 A tunnel is "created" when a gateway sends a Membership Update 1156 message containing an IGMP or MLD membership report that creates one 1157 or more group subscriptions when none currently existed for that 1158 tunnel endpoint address. 1160 A tunnel ceases to exist when all group subscriptions for a tunnel 1161 endpoint are deleted. This may occur as a result of the following 1162 events: 1164 o The gateway sends an IGMP or MLD report, leave or done message to 1165 the relay that deletes the last group subscription linked to the 1166 tunnel endpoint. 1168 o The gateway sends a Teardown message to the relay that causes it 1169 to delete any and all subscriptions bound to the tunnel endpoint. 1171 o The relay stops receiving updates from the gateway until such time 1172 that per-group or per-tunnel timers expire, causing the relay to 1173 delete the subscriptions. 1175 The tunneling approach described above conceptually transforms a 1176 unicast-only inter-network into an NBMA link layer, over which 1177 multicast traffic may be delivered. Each relay, plus the set of all 1178 gateways using the relay, together may be thought of as being on a 1179 separate logical NBMA link, where the "link layer" address is a UDP/ 1180 IP address-port pair provided by the Membership Update message. 1182 4.2.2.1. Address Roaming 1184 As described above, each time a relay receives a Membership Update 1185 message from a new source address-port pair, the group subscriptions 1186 described by that message apply to the tunnel endpoint identified by 1187 that address. 1189 This can cause problems for a gateway if the address carried by the 1190 messages it sends to a relay changes unexpectedly. These changes may 1191 cause the relay to transmit duplicate, undeliverable or unrequested 1192 traffic back towards the gateway or an intermediate device. This may 1193 create congestion and have negative consequences for the gateway, its 1194 network, or multicast receivers, and in some cases, may also produce 1195 a significant amount of ICMP traffic directed back towards the relay 1196 by a NAT, router or gateway host. 1198 There are several scenarios in which the address carried by messages 1199 sent by a gateway may change without that gateway's knowledge, as for 1200 example, when: 1202 o The message originates from a different interface on a gateway 1203 that possesses multiple interfaces. 1205 o The DHCP assignment for a gateway interface changes. 1207 o The gateway roams to a different wireless network. 1209 o The address mapping applied by an intervening network-translation- 1210 device (NAT) changes as a result of mapping expiration or routing 1211 changes in a multi-homed network. 1213 In the case where the address change occurs between the transmission 1214 of a Request message and subsequent Membership Update messages, the 1215 relay will simply ignore any Membership Update messages from the new 1216 address because MAC authentication will fail (see Section 4.2.1.2). 1217 The relay may continue to transmit previously requested traffic, but 1218 no duplication will occur, i.e., the possibility for the delivery of 1219 duplicate traffic does not arise until a Request message is received 1220 from the new address. 1222 The protocol provides a method for a gateway to detect an address 1223 change and explicitly request that the relay stop sending traffic to 1224 a previous address. This process involves the Membership Query and 1225 Teardown messages and is described in Section 4.2.1.3. 1227 4.2.2.2. Network Address Translation 1228 The messages sent by a gateway to a relay may be subject to network 1229 address translation (NAT) - the source IP address and UDP port 1230 carried by an IP packet sent by the gateway may be modified multiple 1231 times before arriving at the relay. In the most restrictive form of 1232 NAT, the NAT device will create a new mapping for each combination of 1233 source and destination IP address and UDP port. In this case, bi- 1234 directional communication can only be conducted by sending outgoing 1235 packets to the source address and port carried by the last incoming 1236 packet. 1238 Membership Update Membership Update 1239 src: iADDR:iPORT src: eADDR:ePORT 1240 dst: rADDR:rPORT dst: rADDR:rPORT 1241 +---------+ 1242 | NAT | 1243 +---------+ +-----------+ +---------+ 1244 | |---------->| |--------->| | 1245 | Gateway | | Mapping | | Relay | 1246 | |<----------| |<---------| | 1247 +---------+ +-----------+ +---------+ 1248 | | 1249 +---------+ 1250 Multicast Data Multicast Data 1251 src: rADDR:rPORT src: rADDR:rPORT 1252 dst: iADDR:iPORT dst: eADDR:ePORT 1254 Figure 9: Network Address Translation in AMT 1256 AMT provides automatic NAT traversal by using the source IP address 1257 and UDP port carried by the Membership Update message as received at 1258 the relay as the destination address for any Multicast Data messages 1259 the relay sends back as a result. 1261 The NAT mapping created by a Membership Update message will 1262 eventually expire unless it is refreshed by a passing message. This 1263 refresh will occur each time the gateway performs the periodic update 1264 required to refresh group state within the relay (See 1265 Section 4.2.1.2). 1267 4.2.2.3. UDP Encapsulation 1269 Gateway Relay 1271 IP:IGMP IP:IGMP 1272 | AMT:IP:IGMP AMT:IP:IGMP | 1273 | | | | 1274 | | IP:UDP:AMT:IP:IGMP | | 1275 _______ | ___ | ______ | ______ | ___ | _______ 1277 |IGMP|IP| v |AMT| v |UDP|IP| v |IP|UDP| v |AMT| v |IP|IGMP| 1278 | | | | | | | | | | | | | | | | 1279 | |<------------------------------------------------------->| | 1280 |____| | | | | | | | | | | | | |____| 1281 | |<--------------------------------------------------| | 1282 |_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______| 1283 | | | | | 1284 IP AMT:IP IP:UDP:AMT:IP AMT:IP IP 1286 Figure 10: AMT Encapsulation 1288 The IGMP and MLD messages used in AMT are exchanged as complete IP 1289 datagrams. These IP datagrams are encapsulated in AMT messages that 1290 are transmitted using UDP. The same holds true for multicast traffic 1291 - each multicast IP datagram or datagram fragment that arrives at the 1292 relay is encapsulated in an AMT message and transmitted to one or 1293 more gateways via UDP. 1295 The IP protocol of the encapsulated packets need not match the IP 1296 protocol used to send the AMT messages. AMT messages sent via IPv4 1297 may carry IPv6/MLD packets and AMT messages sent via IPv6 may carry 1298 IPv4/IGMP packets. 1300 The checksum field contained in the UDP header of the messages 1301 requires special consideration. Of primary concern is the cost of 1302 computing a checksum on each replicated multicast packet after it is 1303 encapsulated for delivery to a gateway. Many routing/forwarding 1304 platforms do not possess the capability to compute checksums on UDP 1305 encapsulated packets as they may not have access to the entire 1306 datagram. 1308 To avoid placing an undue burden on the relay platform, the protocol 1309 specifically allows zero-valued UDP checksums on the multicast data 1310 messages. This is not an issue in UDP over IPv4 as the UDP checksum 1311 field may be set to zero. However, this is a problem for UDP over 1312 IPv6 as that protocol requires a valid, non-zero checksum in UDP 1313 datagrams [RFC2460]. Messages sent over IPv6 with a UDP checksum of 1314 zero may fail to reach the gateway. This is a well known issue for 1315 UDP-based tunneling protocols that is described [RFC6936]. A 1316 recommended solution is described in [RFC6935]. 1318 4.2.2.4. UDP Fragmentation 1320 Naive encapsulation of a multicast IP datagrams within an AMT data 1321 messages may produce UDP datagrams that might require fragmentation 1322 if their size exceeds the MTU of network path between the relay and a 1323 gateway. Many multicast applications, especially those related to 1324 media streaming, are designed to deliver independent data samples in 1325 separate packets, without fragmentation, to ensure some number of 1326 complete samples can be delivered even in the presence of packet 1327 loss. To prevent or reduce undesirable fragmentation, the AMT 1328 protocol describes specific procedures for handling multicast 1329 datagrams whose encapsulation might exceed the path MTU. These 1330 procedures are described in Section 5.3.3.6. 1332 5. Protocol Description 1334 This section provides a normative description of the AMT protocol. 1336 5.1. Protocol Messages 1338 The AMT protocol defines seven message types for control and 1339 encapsulation. These messages are assigned the following names and 1340 numeric identifiers: 1342 +--------------+---------------------+ 1343 | Message Type | Message Name | 1344 +--------------+---------------------+ 1345 | 1 | Relay Discovery | 1346 | | | 1347 | 2 | Relay Advertisement | 1348 | | | 1349 | 3 | Request | 1350 | | | 1351 | 4 | Membership Query | 1352 | | | 1353 | 5 | Membership Update | 1354 | | | 1355 | 6 | Multicast Data | 1356 | | | 1357 | 7 | Teardown | 1358 +--------------+---------------------+ 1360 These messages are exchanged as IPv4 or IPv6 UDP datagrams. 1362 5.1.1. Relay Discovery 1364 A Relay Discovery message is used to solicit a response from a relay 1365 in the form of a Relay Advertisement message. 1367 The UDP/IP datagram containing this message MUST carry a valid, non- 1368 zero UDP checksum and carry the following IP address and UDP port 1369 values: 1371 Source IP Address - The IP address of the gateway interface on which 1372 the gateway will listen for a relay response. Note: The value of 1373 this field may be changed as a result of network address 1374 translation before arriving at the relay. 1376 Source UDP Port - The UDP port number on which the gateway will 1377 listen for a relay response. Note: The value of this field may be 1378 changed as a result of network address translation before arriving 1379 at the relay. 1381 Destination IP Address - An anycast or unicast IP address, i.e., the 1382 Relay Discovery Address advertised by a relay. 1384 Destination UDP Port - The IANA-assigned AMT port number (See 1385 Section 7.3). 1387 0 1 2 3 1388 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 1389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1390 | V=0 |Type=1 | Reserved | 1391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 | Discovery Nonce | 1393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 Figure 11: Relay Discovery Message Format 1397 5.1.1.1. Version (V) 1399 The protocol version number for this message is 0. 1401 5.1.1.2. Type 1403 The type number for this message is 1. 1405 5.1.1.3. Reserved 1407 Reserved bits that MUST be set to zero by the gateway and ignored by 1408 the relay. 1410 5.1.1.4. Discovery Nonce 1412 A 32-bit random value generated by the gateway and echoed by the 1413 relay in a Relay Advertisement message. This value is used by the 1414 gateway to correlate Relay Advertisement messages with Relay 1415 Discovery messages. Discovery nonce generation is described in 1416 Section 5.2.3.4.5. 1418 5.1.2. Relay Advertisement 1420 The Relay Advertisement message is used to supply a gateway with a 1421 unicast IP address of a relay. A relay sends this message to a 1422 gateway when it receives a Relay Discovery message from that gateway. 1424 The UDP/IP datagram containing this message MUST carry a valid, non- 1425 zero UDP checksum and carry the following IP address and UDP port 1426 values: 1428 Source IP Address - The destination IP address carried by the Relay 1429 Discovery message (i.e., the Relay Discovery Address advertised by 1430 the relay). 1432 Source UDP Port - The destination UDP port carried by the Relay 1433 Discovery message (i.e., the IANA-assigned AMT port number). 1435 Destination IP Address - The source IP address carried by the Relay 1436 Discovery message. Note: The value of this field may be changed 1437 as a result of network address translation before arriving at the 1438 gateway. 1440 Destination UDP Port - The source UDP port carried by the Relay 1441 Discovery message. Note: The value of this field may be changed 1442 as a result of network address translation before arriving at the 1443 gateway. 1445 0 1 2 3 1446 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 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | V=0 |Type=2 | Reserved | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | Discovery Nonce | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1452 | | 1453 ~ Relay Address (IPv4 or IPv6) ~ 1454 | | 1455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1457 Figure 12: Relay Advertisement Message Format 1459 5.1.2.1. Version (V) 1461 The protocol version number for this message is 0. 1463 5.1.2.2. Type 1465 The type number for this message is 2. 1467 5.1.2.3. Reserved 1469 Reserved bits that MUST be set to zero by the relay and ignored by 1470 the gateway. 1472 5.1.2.4. Discovery Nonce 1474 A 32-bit value copied from the Discovery Nonce field 1475 (Section 5.1.1.4) contained in the Relay Discovery message. The 1476 gateway uses this value to match a Relay Advertisement to a Relay 1477 Discovery message. 1479 5.1.2.5. Relay Address 1481 The unicast IPv4 or IPv6 address of the relay. A gateway uses the 1482 length of the UDP datagram containing the Relay Advertisement message 1483 to determine the address family; i.e., length - 8 = 4 (IPv4) or 16 1484 (IPv6). The relay returns an IP address for the protocol used to 1485 send the Relay Discovery message, i.e., an IPv4 relay address for an 1486 IPv4 discovery address or an IPv6 relay address for an IPv6 discovery 1487 address. 1489 5.1.3. Request 1491 A gateway sends a Request message to a relay to solicit a Membership 1492 Query response. 1494 The successful delivery of this message marks the start of the first 1495 stage in the three-way handshake used to create or update state 1496 within a relay. 1498 The UDP/IP datagram containing this message MUST carry a valid, non- 1499 zero UDP checksum and carry the following IP address and UDP port 1500 values: 1502 Source IP Address - The IP address of the gateway interface on which 1503 the gateway will listen for a response from the relay. Note: The 1504 value of this field may be changed as a result of network address 1505 translation before arriving at the relay. 1507 Source UDP Port - The UDP port number on which the gateway will 1508 listen for a response from the relay. Note: The value of this 1509 field may be changed as a result of network address translation 1510 before arriving at the relay. 1512 Destination IP Address - The unicast IP address of the relay. 1514 Destination UDP Port - The IANA-assigned AMT port number. 1516 0 1 2 3 1517 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 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | V=0 |Type=3 | Reserved |P| Reserved | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 | Request Nonce | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1524 Figure 13: Request Message Format 1526 5.1.3.1. Version (V) 1528 The protocol version number for this message is 0. 1530 5.1.3.2. Type 1532 The type number for this message is 3. 1534 5.1.3.3. Reserved 1536 Reserved bits that MUST be set to zero by the gateway and ignored by 1537 the relay. 1539 5.1.3.4. P Flag 1541 The "P" flag is set to indicate which group membership protocol the 1542 gateway wishes the relay to use in the Membership Query response: 1544 Value Meaning 1546 0 The relay MUST respond with a Membership Query message that 1547 contains an IPv4 packet carrying an IGMPv3 general query 1548 message. 1549 1 The relay MUST respond with a Membership Query message that 1550 contains an IPv6 packet carrying an MLDv2 general query 1551 message. 1553 5.1.3.5. Request Nonce 1555 A 32-bit random value generated by the gateway and echoed by the 1556 relay in a Membership Query message. This value is used by the relay 1557 to compute the Response MAC value and is used by the gateway to 1558 correlate Membership Query messages with Request messages. Request 1559 nonce generation is described in Section 5.2.3.5.6. 1561 5.1.4. Membership Query 1562 A relay sends a Membership Query message to a gateway to solicit a 1563 Membership Update response, but only after receiving a Request 1564 message from the gateway. 1566 The successful delivery of this message to a gateway marks the start 1567 of the second-stage in the three-way handshake used to create or 1568 update tunnel state within a relay. 1570 The UDP/IP datagram containing this message MUST carry a valid, non- 1571 zero UDP checksum and carry the following IP address and UDP port 1572 values: 1574 Source IP Address - The destination IP address carried by the 1575 Request message (i.e., the unicast IP address of the relay). 1577 Source UDP Port - The destination UDP port carried by the Request 1578 message (i.e., the IANA-assigned AMT port number). 1580 Destination IP Address - The source IP address carried by the 1581 Request message. Note: The value of this field may be changed as 1582 a result of network address translation before arriving at the 1583 gateway. 1585 Destination UDP Port - The source UDP port carried by the Request 1586 message. Note: The value of this field may be changed as a result 1587 of network address translation before arriving at the gateway. 1589 0 1 2 3 1590 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 1591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 | V=0 |Type=4 | Reserved |L|G| Response MAC | 1593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1594 | | 1595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1596 | Request Nonce | 1597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1598 | | 1599 | Encapsulated General Query Message | 1600 ~ IPv4:IGMPv3(Membership Query) ~ 1601 | IPv6:MLDv2(Listener Query) | 1602 | | 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | Gateway Port Number | | 1605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1606 | | 1607 + + 1608 | Gateway IP Address (IPv4 or IPv6) | 1609 + + 1610 | | 1611 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1612 | | 1613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 Figure 14: Membership Query Message Format 1617 5.1.4.1. Version (V) 1619 The protocol version number for this message is 0. 1621 5.1.4.2. Type 1623 The type number for this message is 4. 1625 5.1.4.3. Reserved 1627 Reserved bits that MUST be set to zero by the relay and ignored by 1628 the gateway. 1630 5.1.4.4. Limit (L) Flag 1632 A 1-bit flag set to 1 to indicate that the relay is NOT accepting 1633 Membership Update messages from new gateway tunnel endpoints and that 1634 it will ignore any that are. A value of 0 has no special 1635 significance - the relay may or may not be accepting Membership 1636 Update messages from new gateway tunnel endpoints. A gateway checks 1637 this flag before attempting to create new group subscription state on 1638 the relay to determine whether it should restart relay discovery. A 1639 gateway that has already created group subscriptions on the relay may 1640 ignore this flag. Support for this flag is RECOMMENDED. 1642 5.1.4.5. Gateway Address (G) Flag 1644 A 1-bit flag set to 0 to indicate that the message does NOT carry the 1645 Gateway Port and Gateway IP Address fields, and 1 to indicate that it 1646 does. A relay implementation that supports the optional teardown 1647 procedure (See Section 5.3.3.5) SHOULD set this flag and the Gateway 1648 Address field values. If a relay sets this flag, it MUST also 1649 include the Gateway Address fields in the message. A gateway 1650 implementation that does not support the optional teardown procedure 1651 (See Section 5.2.3.7) MAY ignore this flag and the Gateway Address 1652 fields if they are present. 1654 5.1.4.6. Response MAC 1656 A 48-bit source authentication hash generated by the relay as 1657 described in Section 5.3.5. The gateway echoes this value in 1658 subsequent Membership Update messages to allow the relay to verify 1659 that the sender of a Membership Update message was the intended 1660 receiver of a Membership Query sent by the relay. 1662 5.1.4.7. Request Nonce 1664 A 32-bit value copied from the Request Nonce field (Section 5.1.3.5) 1665 carried by a Request message. The relay will have included this 1666 value in the Response MAC hash computation. The gateway echoes this 1667 value in subsequent Membership Update messages. The gateway also 1668 uses this value to match a Membership Query to a Request message. 1670 5.1.4.8. Encapsulated General Query Message 1672 An IP-encapsulated IGMP or MLD message generated by the relay. This 1673 field will contain one of the following IP datagrams: 1675 IPv4:IGMPv3 Membership Query 1677 IPv6:MLDv2 Listener Query 1679 The source address carried by the query message should be set as 1680 described in Section 5.3.3.3. 1682 The Querier's Query Interval Code (QQIC) field in the general query 1683 is used by a relay to specify the time offset a gateway should use to 1684 schedule a new three-way handshake to refresh the group membership 1685 state within the relay (current time + Query Interval). The QQIC 1686 field is defined in Section 4.1.7 in [RFC3376] and Section 5.1.9 in 1687 [RFC3810]. 1689 The Querier's Robustness Variable (QRV) field in the general query is 1690 used by a relay to specify the number of times a gateway should 1691 retransmit unsolicited membership reports, encapsulated within 1692 Membership Update messages, and optionally, the number of times to 1693 send a Teardown message. The QRV field is defined in Section 4.1.6 1694 in [RFC3376] and Section 5.1.8 in [RFC3810]. 1696 5.1.4.9. Gateway Address Fields 1698 The Gateway Port Number and Gateway Address fields are present in the 1699 Membership Query message if, and only if, the "G" flag is set. 1701 A gateway need not parse the encapsulated IP datagram to determine 1702 the position of these fields within the UDP datagram containing the 1703 Membership Query message - if the G-flag is set, the gateway may 1704 simply subtract the total length of the fields (18 bytes) from the 1705 total length of the UDP datagram to obtain the offset. 1707 5.1.4.9.1. Gateway Port Number 1709 A 16-bit UDP port containing a UDP port value. 1711 The Relay sets this field to the value of the UDP source port of the 1712 Request message that triggered the Query message. 1714 5.1.4.9.2. Gateway IP Address 1716 A 16-byte IP address that, when combined with the value contained in 1717 the Gateway Port Number field, forms the gateway endpoint address 1718 that the relay will use to identify the tunnel instance, if any, 1719 created by a subsequent Membership Update message. This field may 1720 contain an IPv6 address or an IPv4 address stored as an 1721 IPv4-compatible IPv6 address, where the IPv4 address is prefixed with 1722 96 bits set to zero (See [RFC4291]). This address must match that 1723 used by the relay to compute the value stored in the Response MAC 1724 field. 1726 5.1.5. Membership Update 1728 A gateway sends a Membership Update message to a relay to report a 1729 change in group membership state, or to report the current group 1730 membership state in response to receiving a Membership Query message. 1731 The gateway encapsulates the IGMP or MLD message as an IP datagram 1732 within a Membership Update message and sends it to the relay, where 1733 it may (see below) be decapsulated and processed by the relay to 1734 update group membership and forwarding state. 1736 A gateway cannot send a Membership Update message until a receives a 1737 Membership Query from a relay because the gateway must copy the 1738 Request Nonce and Response MAC values carried by a Membership Query 1739 into any subsequent Membership Update messages it sends back to that 1740 relay. These values are used by the relay to verify that the sender 1741 of the Membership Update message was the recipient of the Membership 1742 Query message from which these values were copied. 1744 The successful delivery of this message to the relay marks the start 1745 of the final stage in the three-way handshake. This stage concludes 1746 when the relay successfully verifies that sender of the Membership 1747 Update message was the recipient of a Membership Query message sent 1748 earlier. At this point, the relay may proceed to process the 1749 encapsulated IGMP or MLD message to create or update group membership 1750 and forwarding state on behalf of the gateway. 1752 The UDP/IP datagram containing this message MUST carry a valid, non- 1753 zero UDP checksum and carry the following IP address and UDP port 1754 values: 1756 Source IP Address - The IP address of the gateway interface on which 1757 the gateway will listen for Multicast Data messages from the 1758 relay. The address must be the same address used to send the 1759 initial Request message or the message will be ignored. Note: The 1760 value of this field may be changed as a result of network address 1761 translation before arriving at the relay. 1763 Source UDP Port - The UDP port number on which the gateway will 1764 listen for Multicast Data messages from the relay. This port must 1765 be the same port used to send the initial Request message or the 1766 message will be ignored. Note: The value of this field may be 1767 changed as a result of network address translation before arriving 1768 at the relay. 1770 Destination IP Address - The unicast IP address of the relay. 1772 Destination UDP Port - The IANA-assigned AMT port number. 1774 0 1 2 3 1775 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 1776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1777 | V=0 |Type=5 | Reserved | Response MAC | 1778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1779 | | 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | Request Nonce | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1783 | | 1784 | Encapsulated Group Membership Update Message | 1785 ~ IPv4:IGMP(Membership Report|Leave Group) ~ 1786 | IPv6:MLD(Listener Report|Listener Done) | 1787 | | 1788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 Figure 15: Membership Update Message Format 1792 5.1.5.1. Version (V) 1794 The protocol version number for this message is 0. 1796 5.1.5.2. Type 1798 The type number for this message is 5. 1800 5.1.5.3. Reserved 1802 Reserved bits that MUST be set to zero by the gateway and ignored by 1803 the relay. 1805 5.1.5.4. Response MAC 1807 A 48-bit value copied from the Response MAC field (Section 5.1.4.6) 1808 in a Membership Query message. Used by the relay to perform source 1809 authentication. 1811 5.1.5.5. Request Nonce 1813 A 32-bit value copied from the Request Nonce field in a Request or 1814 Membership Query message. Used by the relay to perform source 1815 authentication. 1817 5.1.5.6. Encapsulated Group Membership Update Message 1819 An IP-encapsulated IGMP or MLD message produced by the host-mode IGMP 1820 or MLD protocol running on a gateway pseudo-interface. This field 1821 will contain of one of the following IP datagrams: 1823 IPv4:IGMPv2 Membership Report 1825 IPv4:IGMPv2 Leave Group 1827 IPv4:IGMPv3 Membership Report 1829 IPv6:MLDv1 Multicast Listener Report 1831 IPv6:MLDv1 Multicast Listener Done 1833 IPv6:MLDv2 Multicast Listener Report 1835 The source address carried by the message should be set as described 1836 in Section 5.2.1. 1838 5.1.6. Multicast Data 1840 A relay sends a Multicast Data message to deliver an multicast IP 1841 datagram or datagram fragment to a gateway. 1843 The checksum field in the UDP header of this message MAY contain a 1844 value of zero when sent over IPv4 but SHOULD, if possible, contain a 1845 valid, non-zero value when sent over IPv6 (See Section 4.2.2.3). 1847 The UDP/IP datagram containing this message MUST carry the following 1848 IP address and UDP port values: 1850 Source IP Address - The unicast IP address of the relay. 1852 Source UDP Port - The IANA-assigned AMT port number. 1854 Destination IP Address - A tunnel endpoint IP address, i.e., the 1855 source IP address carried by the Membership Update message sent by 1856 a gateway to indicate an interest in receiving the multicast 1857 packet. Note: The value of this field may be changed as a result 1858 of network address translation before arriving at the gateway. 1860 Destination UDP Port - A tunnel endpoint UDP port, i.e., the source 1861 UDP port carried by the Membership Update message sent by a 1862 gateway to indicate an interest in receiving the multicast packet. 1863 Note: The value of this field may be changed as a result of 1864 network address translation before arriving at the gateway. 1866 0 1 2 3 1867 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 1868 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 | V=0 |Type=6 | Reserved | | 1870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1871 | | 1872 ~ IP Multicast Packet ~ 1873 | | 1874 + - - - - - - - - - - - - - - - - - - - - - - - -+ 1875 | : : : : 1876 +-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - - 1878 Figure 16: Multicast Data Message Format 1880 5.1.6.1. Version (V) 1882 The protocol version number for this message is 0. 1884 5.1.6.2. Type 1886 The type number for this message is 6. 1888 5.1.6.3. Reserved 1890 Bits that MUST be set to zero by the relay and ignored by the 1891 gateway. 1893 5.1.6.4. IP Multicast Data 1895 A complete IPv4 or IPv6 multicast datagram or datagram fragment. 1897 5.1.7. Teardown 1899 A gateway sends a Teardown message to a relay to request that it stop 1900 sending Multicast Data messages to a tunnel endpoint created by an 1901 earlier Membership Update message. A gateway sends this message when 1902 it detects that a Request message sent to the relay carries an 1903 address that differs from that carried by a previous Request message. 1904 The gateway uses the Gateway IP Address and Gateway Port Number 1905 Fields in the Membership Query message to detect these address 1906 changes. 1908 To provide backwards compatibility with early implementations of the 1909 AMT protocol, support for this message and associated procedures is 1910 considered OPTIONAL - gateways are not required to send this message 1911 and relays are not required to act upon it. 1913 The UDP/IP datagram containing this message MUST carry a valid, non- 1914 zero UDP checksum and carry the following IP address and UDP port 1915 values: 1917 Source IP Address - The IP address of the gateway interface used to 1918 send the message. This address may differ from that used to send 1919 earlier messages. Note: The value of this field may be changed as 1920 a result of network address translation before arriving at the 1921 relay. 1923 Source UDP Port - The UDP port number. This port number may differ 1924 from that used to send earlier messages. Note: The value of this 1925 field may be changed as a result of network address translation 1926 before arriving at the relay. 1928 Destination IP Address - The unicast IP address of the relay. 1930 Destination UDP Port - The IANA-assigned AMT port number. 1932 0 1 2 3 1933 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 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 | V=0 |Type=7 | Reserved | Response MAC | 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1937 | | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 | Request Nonce | 1940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 | Gateway Port Number | | 1942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1943 | | 1944 + + 1945 | Gateway IP Address (IPv4 or IPv6) | 1946 + + 1947 | | 1948 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 | | 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 Figure 17: Membership Teardown Message Format 1954 5.1.7.1. Version (V) 1956 The protocol version number for this message is 0. 1958 5.1.7.2. Type 1960 The type number for this message is 7. 1962 5.1.7.3. Reserved 1964 Reserved bits that MUST be set to zero by the gateway and ignored by 1965 the relay. 1967 5.1.7.4. Response MAC 1969 A 48-bit value copied from the Response MAC field (Section 5.1.4.6) 1970 in the last Membership Query message the relay sent to the gateway 1971 endpoint address of the tunnel to be torn down. The gateway endpoint 1972 address is provided by the Gateway IP Address and Gateway Port Number 1973 fields carried by the Membership Query message. The relay validates 1974 the Teardown message by comparing this value with one computed from 1975 the Gateway IP Address, Gateway Port Number, Request Nonce fields and 1976 a private secret (just as it does in the Membership Update message). 1978 5.1.7.5. Request Nonce 1980 A 32-bit value copied from the Request Nonce field (Section 5.1.4.7) 1981 in the last Membership Query message the relay sent to the gateway 1982 endpoint address of the tunnel to be torn down. The gateway endpoint 1983 address is provided by the Gateway IP Address and Gateway Port Number 1984 fields carried by the Membership Query message. This value must 1985 match that used by the relay to compute the value stored in the 1986 Response MAC field. 1988 5.1.7.6. Gateway Port Number 1990 A 16-bit UDP port number that, when combined with the value contained 1991 in the Gateway IP Address field, forms the tunnel endpoint address 1992 that the relay will use to identify the tunnel instance to tear down. 1993 The relay provides this value to the gateway using the Gateway Port 1994 Number field (Section 5.1.4.9.1) in a Membership Query message. This 1995 port number must match that used by the relay to compute the value 1996 stored in the Response MAC field. 1998 5.1.7.7. Gateway IP Address 2000 A 16-byte IP address that, when combined with the value contained in 2001 the Gateway Port Number field, forms the tunnel endpoint address that 2002 the relay will used to identify the tunnel instance to tear down. 2003 The relay provides this value to the gateway using the Gateway IP 2004 Address field (Section 5.1.4.9.2) in a Membership Query message. 2005 This field may contain an IPv6 address or an IPv4 address stored as 2006 an IPv4-compatible IPv6 address, where the IPv4 address is prefixed 2007 with 96 bits set to zero (See [RFC4291]). This address must match 2008 that used by the relay to compute the value stored in the Response 2009 MAC field. 2011 5.2. Gateway Operation 2013 The following sections describe gateway implementation requirements. 2014 A non-normative discussion of gateway operation may be found in 2015 Section 4.2. 2017 5.2.1. IP/IGMP/MLD Protocol Requirements 2019 Gateway operation requires a subset of host mode IPv4/IGMP and IPv6/ 2020 MLD functionality to provide group membership tracking, general query 2021 processing, and report generation. A gateway MAY use IGMPv2 (ASM), 2022 IGMPv3 (ASM and SSM), MLDv1 (ASM) or MLDv2 (ASM and SSM). 2024 An application with embedded gateway functionality must provide its 2025 own implementation of this subset of the IPv4/IGMP and IPv6/MLD 2026 protocols. The service interface used to manipulate group membership 2027 state need not match that described in the IGMP and MLD 2028 specifications, but the actions taken as a result SHOULD be similar 2029 to those described in Section 5.1 of [RFC3376] and Section 6.1 of 2030 [RFC3810]. The gateway application will likely need to implement 2031 many of the same functions as a host IP stack, including checksum 2032 verification, dispatching, datagram filtering and forwarding, and IP 2033 encapsulation/decapsulation. 2035 The IP-encapsulated IGMP messages generated by the gateway IPv4/IGMP 2036 implementation MUST conform to the description found in Section 4 of 2037 [RFC3376]. These datagrams MUST possess the IP headers, header 2038 options and header values called for in [RFC3376], with the following 2039 exception; the source IP address for an IGMP report datagram MAY be 2040 set to the "unspecified" address (all octets are zero ) but SHOULD be 2041 set to an address in the address range specifically assigned by IANA 2042 for use in the IGMP messages sent from a gateway to a relay (i.e. 2043 154.7.1.2 through 154.7.1.254 as described in Section 7). This 2044 exception is made because the gateway pseudo-interface might not 2045 possess an assigned address, and even if such an address exists, that 2046 address would not be a valid link-local source address on any relay 2047 interface. The rationale for using the aforementioned source 2048 addresses is primarily one of convenience - a relay will accept an 2049 IGMP report carried by a Membership Update message regardless of the 2050 source address it carries. See Section 5.3.1. 2052 The IP-encapsulated MLD messages generated by the gateway IPv6/MLD 2053 implementation MUST conform to the description found in Section 5 of 2054 [RFC3810]. These datagrams MUST possess the IP headers, header 2055 options and header values called for in [RFC3810], with the following 2056 exception; the source IP address for an MLD report datagram MAY be 2057 set to the "unspecified" address (all octets are zero ) but SHOULD be 2058 set to an IPv6 link-local address in the range FE80::/64 excluding 2059 FE80::1 and FE80::2. This exception is made because the gateway 2060 pseudo-interface might not possess a valid IPv6 address. As with 2061 IGMP, a relay will accept an MLD report carried by a Membership 2062 Update message regardless of the source address it carries. See 2063 Section 5.3.1. 2065 The gateway IGMP/MLD implementation SHOULD retransmit unsolicited 2066 membership state-change reports and merge new state change reports 2067 with pending reports as described in Section 5.1 of [RFC3376] and 2068 Section 6.1 of [RFC3810]. The number of retransmissions is specified 2069 by the relay in the Querier's Robustness Variable (QRV) field in the 2070 last general query forwarded by the pseudo-interface. See 2071 Section 4.1.6 in [RFC3376] and Section 5.1.8 in [RFC3810]. 2073 The gateway IGMP/MLD implementation SHOULD handle general query 2074 messages as described in Section 5.2 of [RFC3376] and Section 6.2 of 2075 [RFC3810], but MAY ignore the Max Resp Code field value and generate 2076 a current state report without any delay. 2078 An IPv4 gateway implementation MUST accept IPv4 datagrams that carry 2079 the general query variant of the IGMPv3 Membership Query message, as 2080 described in Section 4 of [RFC3376]. The gateway MUST accept the 2081 IGMP datagram regardless of the IP source address carried by that 2082 datagram. 2084 An IPv6 gateway implementation MUST accept IPv6 datagrams that carry 2085 the general query variant of the MLDv2 Multicast Listener Query 2086 message, as described in Section 5 of [RFC3810]. The gateway MUST 2087 accept the MLD datagram regardless of the IP source address carried 2088 by that datagram. 2090 5.2.2. Pseudo-Interface Configuration 2092 A gateway host may possess or create multiple gateway pseudo- 2093 interfaces, each with a unique configuration that describes a binding 2094 to a specific IP protocol, relay address, relay discovery address or 2095 upstream network interface. 2097 5.2.2.1. Relay Discovery Address 2099 If a gateway implementation uses AMT relay discovery to obtain a 2100 relay address, it must first be supplied with a relay discovery 2101 address. The relay discovery address may be an anycast or unicast 2102 address. A gateway implementation may rely on a static address 2103 assignment or some form of dynamic address discovery. This 2104 specification does not require that a gateway implementation use any 2105 particular method to obtain a relay discovery address - an 2106 implementation may employ any method that returns a suitable relay 2107 discovery address. 2109 5.2.2.2. Relay Address 2111 Before a gateway implementation can execute the AMT protocol to 2112 request and receive multicast traffic, it must be supplied with a 2113 unicast relay address. A gateway implementation may rely on static 2114 address assignment or support some form of dynamic address discovery. 2115 This specification does not require the use of any particular method 2116 to obtain a relay address - an implementation may employ any method 2117 that returns a suitable relay address. 2119 5.2.2.3. Upstream Interface Selection 2121 A gateway host that possesses multiple network interfaces or 2122 addresses may allow for an explicit selection of the interface to use 2123 when communicating with a relay. The selection might be made to 2124 satisfy connectivity, tunneling or IP protocol requirements. 2126 5.2.2.4. Optional Retransmission Parameters 2128 A gateway implementation that supports retransmission MAY require the 2129 following information: 2131 Discovery Timeout 2132 Initial time to wait for a response to a Relay Discovery message. 2134 Maximum Relay Discovery Retransmission Count 2135 Maximum number of Relay Discovery retransmissions to allow before 2136 terminating relay discovery and reporting an error. 2138 Request Timeout 2139 Initial time to wait for a response to a Request message. 2141 Maximum Request Retransmission Count 2142 Maximum number of Request retransmissions to allow before 2143 abandoning a relay and restarting relay discovery or reporting an 2144 error. 2146 Maximum Retries Count For "Destination Unreachable" 2147 The maximum number of times a gateway should attempt to send the 2148 same Request or Membership Update message after receiving an ICMP 2149 "Destination Unreachable". 2151 5.2.3. Gateway Service 2153 In the following descriptions, a gateway pseudo interface is treated 2154 as a passive entity managed by a gateway service. The gateway 2155 pseudo-interface provides the state and the gateway service provides 2156 the processing. The term "gateway" is used when describing service 2157 behavior with respect to a single pseudo-interface. 2159 5.2.3.1. Startup 2161 When a gateway pseudo-interface is started, the gateway service 2162 begins listening for AMT messages sent to the UDP endpoint(s) 2163 associated with the pseudo-interface and for any locally-generated 2164 IGMP/MLD messages passed to the pseudo-interface. The handling of 2165 these messages is described below. 2167 When the pseudo-interface is enabled, the gateway service MAY: 2169 o Optionally execute the relay discovery procedure described in 2170 Section 5.2.3.4. 2172 o Optionally execute the membership query procedure described in 2173 Section 5.2.3.5 to start the periodic membership update cycle. 2175 5.2.3.2. Handling AMT Messages 2177 A gateway MUST ignore any datagram it receives that cannot be 2178 interpreted as a Relay Advertisement, Membership Query, or Multicast 2179 Data message. The handling of Relay Advertisement, Membership Query, 2180 and Multicast Data messages is addressed in the sections that follow. 2182 A gateway that conforms to this specification MUST ignore any message 2183 with a Version field value other than zero. 2185 While listening for AMT messages, a gateway may be notified that an 2186 ICMP Destination Unreachable message was received as a result of an 2187 AMT message transmission. Handling of ICMP Destination Unreachable 2188 messages is described in Section 5.2.3.9. 2190 5.2.3.3. Handling Multicast Data Messages 2192 A gateway may receive Multicast Data messages after it sends a 2193 Membership Update message to a relay that adds a group subscription. 2194 The gateway may continue to receive Multicast Data messages long 2195 after the gateway sends a Membership Update message that deletes 2196 existing group subscriptions. The gateway MUST be prepared to 2197 receive these messages at any time, but MAY ignore them or discard 2198 their contents if the gateway no longer has any interest in receiving 2199 the multicast datagrams contained within them. 2201 A gateway MUST ignore a Multicast Data message if it fails to satisfy 2202 any of the following requirements: 2204 o The source IP address and UDP port carried by the Multicast Data 2205 message MUST be equal to the destination IP address and UDP port 2206 carried by the matching Membership Update message (i.e., the 2207 current relay address). 2209 o The destination address carried by the encapsulated IP datagram 2210 MUST fall within the multicast address allocation assigned to the 2211 relevant IP protocol, i.e., 224.0.0.0/4 for IPv4 and FF00::/8 for 2212 IPv6. 2214 The gateway extracts the encapsulated IP datagram and forwards it to 2215 the local IP protocol implementation for checksum verification, 2216 fragmented datagram reassembly, source and group filtering, and 2217 transport-layer protocol processing. 2219 Because AMT uses UDP encapsulation to deliver multicast datagrams to 2220 gateways, it qualifies as a tunneling protocol subject to the 2221 limitations described in [RFC6936]. If supported, a gateway SHOULD 2222 employ the solution described in [RFC6936] to ensure that the local 2223 IP stack does not discard IPv6 datagrams with zero checksums. If 2224 Multicast Data message datagrams are processed directly within the 2225 gateway (instead of the host IP stack), the gateway MUST NOT discard 2226 any of these datagrams because they carry a UDP checksum of zero. 2228 5.2.3.4. Relay Discovery Procedure 2230 This section describes gateway requirements related to the relay 2231 discovery message sequence described in Section 4.2.1.1. 2233 5.2.3.4.1. Starting Relay Discovery 2235 A gateway may start or restart the relay discovery procedure in 2236 response to the following events: 2238 o When a gateway pseudo-interface is started (enabled). 2240 o When the gateway wishes to report a group subscription when none 2241 currently exist. 2243 o Before sending the next Request message in a membership update 2244 cycle, i.e., each time the query timer expires (see below). 2246 o After the gateway fails to receive a response to a Request 2247 message. 2249 o After the gateway receives a Membership Query message with the 2250 L-flag set to 1. 2252 5.2.3.4.2. Sending a Relay Discovery Message 2254 A gateway sends a Relay Discovery message to a relay to start the 2255 relay discovery process. 2257 The gateway MUST send the Relay Discovery message using the current 2258 Relay Discovery Address and IANA-assigned AMT port number as the 2259 destination. The Discovery Nonce value in the Relay Discovery 2260 message MUST be computed as described in Section 5.2.3.4.5. 2262 The gateway MUST save a copy of Relay Discovery message or save the 2263 Discovery Nonce value for possible retransmission and verification of 2264 a Relay Advertisement response. 2266 When a gateway sends a Relay Discovery message, it may be notified 2267 that an ICMP Destination Unreachable message was received as a result 2268 of an earlier AMT message transmission. Handling of ICMP Destination 2269 Unreachable messages is described in Section 5.2.3.9. 2271 5.2.3.4.3. Waiting for a Relay Advertisement Message 2273 A gateway MAY retransmit a Relay Discovery message if it does not 2274 receive a matching Relay Advertisement message within some timeout 2275 period. If the gateway retransmits the message multiple times, the 2276 timeout period SHOULD be adjusted to provide an random exponential 2277 back-off. The RECOMMENDED timeout is a random value in the range 2278 [initial_timeout, MIN(initial_timeout * 2^retry_count, 2279 maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and 2280 a RECOMMENDED maximum_timeout of 120 seconds (which is the 2281 recommended minimum NAT mapping timeout described in [RFC4787]). 2283 5.2.3.4.4. Handling a Relay Advertisement Message 2285 When a gateway receives a Relay Advertisement message it must first 2286 determine whether it should accept or ignore the message. A gateway 2287 MUST ignore a Relay Advertisement message if it fails to satisfy any 2288 of the following requirements: 2290 o The gateway MUST be waiting for a Relay Advertisement message. 2292 o The Discovery Nonce value contained in the Relay Advertisement 2293 message MUST equal to the Discovery Nonce value contained in the 2294 Relay Discovery message. 2296 o The source IP address and UDP port of the Relay Advertisement 2297 message MUST equal to the destination IP address and UDP port of 2298 the matching Relay Discovery message. 2300 Once a gateway receives a Relay Advertisement response to a Relay 2301 Discovery message, it SHOULD ignore any other Relay Advertisements 2302 that arrive on the AMT interface until it sends a new Relay Discovery 2303 message. 2305 If a gateway executes the relay discovery procedure at the start of 2306 each membership update cycle and the relay address returned in the 2307 latest Relay Advertisement message differs from the address returned 2308 in a previous Relay Advertisement message, then the gateway SHOULD 2309 send a Teardown message (if supported) to the old relay address, 2310 using information from the last Membership Query message received 2311 from that relay, as described in Section 5.2.3.7. This behavior is 2312 illustrated in the following diagram. 2314 Gateway Relay-1 2315 ------- ------- 2316 : : 2317 Query Expired | | 2318 Timer (QT)-------->| | 2319 | Relay Discovery | 2320 |------------------->| 2321 | | 2322 | Relay Advertisement| 2323 |<-------------------| 2324 | | 2325 | Request | 2326 |------------------->| 2327 | | 2328 | Membership Query | 2329 |<===================| 2330 Start | | 2331 (QT)<--------| Membership Update | 2332 |===================>| 2333 | | 2334 ~ ~ Relay-2 2335 Expired | | ------- 2336 (QT)-------->| | : 2337 | Relay Discovery | | 2338 |------------------------------------>| 2339 | | | 2340 | Relay Advertisement| | 2341 |<------------------------------------| 2342 | | | 2343 | Teardown | | 2344 |------------------->| | 2345 | | | 2346 | Request | | 2347 |------------------------------------>| 2348 | | | 2349 | Membership Query | | 2350 |<====================================| 2351 Start | | | 2352 (QT)<--------| Membership Update | | 2353 |====================================>| 2354 | | | 2355 : : : 2357 Figure 18: Teardown After Relay Address Change 2359 5.2.3.4.5. Discovery Nonce Generation 2361 The discovery nonce MUST be a random, non-zero, 32-bit value, and if 2362 possible, SHOULD be computed using a cryptographically secure pseudo 2363 random number generator. A new nonce SHOULD be generated each time 2364 the gateway restarts the relay discovery process. The same nonce 2365 SHOULD be used when retransmitting a Relay Discovery message. 2367 5.2.3.5. Membership Query Procedure 2369 This section describes gateway requirements related to the membership 2370 update message sequence described in Section 4.2.1.2. 2372 5.2.3.5.1. Starting the Membership Update Cycle 2374 A gateway may send a Request message to start a membership update 2375 cycle (following the optional relay discovery procedure) in response 2376 to the following events: 2378 o When the gateway pseudo-interface is activated. 2380 o When the gateway wishes to report a group subscription when none 2381 currently exist. 2383 Starting the membership update cycle when a gateway pseudo-interface 2384 is started provides several benefits: 2386 o Better performance by allowing state-change reports to be sent as 2387 they are generated, thus minimizing the time to join. 2389 o More robustness by relying on unsolicited state-change reports to 2390 update group membership state rather than the current-state 2391 reports generated by the membership update cycle. Unsolicited 2392 state-change reports are typically retransmitted multiple times 2393 while current-state reports are not. 2395 o Simplified implementation by eliminating any need to queue IGMP/ 2396 MLD messages for delivery after a Membership Query is received, 2397 since the IGMP/MLD state-change messages may be sent as they are 2398 generated. 2400 However, this approach places an additional load on relays as a 2401 gateway will send periodic requests even when it has no multicast 2402 subscriptions. To reduce load on a relay, a gateway SHOULD only send 2403 a Membership Update message while it has active group subscriptions. 2404 A relay will still need to compute a Response MAC for each Request, 2405 but will not be required to recompute it a second time to 2406 authenticate a Membership Update message that contains no 2407 subscriptions. 2409 5.2.3.5.2. Sending a Request Message 2411 A gateway sends a Request message to a relay to solicit a Membership 2412 Query response and start the membership update cycle. 2414 A gateway constructs a Request message containing a Request Nonce 2415 value computed as described in Section 5.2.3.5.6. The gateway MUST 2416 set the "P" flag in the Request message to identify the protocol the 2417 gateway wishes the relay to use for the general query response. 2419 A gateway MUST send a Request message using the current Relay Address 2420 and IANA-assigned AMT port number as the destination. 2422 A gateway MUST save a copy of the Request message or save the Request 2423 Nonce and P-flag values for possible retransmission and verification 2424 of a Membership Query response. 2426 When a gateway sends a Request message, it may be notified that an 2427 ICMP Destination Unreachable message was received as a result of an 2428 earlier AMT message transmission. Handling of ICMP Destination 2429 Unreachable messages is described in Section 5.2.3.9. 2431 5.2.3.5.3. Waiting for a Membership Query Message 2433 A gateway MAY retransmit a Request message if it does not receive a 2434 matching Membership Query message within some timeout period. If the 2435 gateway retransmits the message multiple times, the timeout period 2436 SHOULD be adjusted to provide an random exponential back-off. The 2437 RECOMMENDED timeout is a random value in the range [initial_timeout, 2438 MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a 2439 RECOMMENDED initial_timeout of 1 second and a RECOMMENDED 2440 maximum_timeout of 120 seconds (which is the recommended minimum NAT 2441 mapping timeout described in [RFC4787]). 2443 If a gateway that uses relay discovery does not receive a Membership 2444 Query within a specified time period or after a specified number of 2445 retries, the gateway SHOULD stop waiting for a Membership Query 2446 message and restart relay discovery to locate another relay. 2448 5.2.3.5.4. Handling a Membership Query Message 2450 When a gateway receives a Membership Query message it must first 2451 determine whether it should accept or ignore the message. A gateway 2452 MUST ignore a Membership Query message, or the encapsulated IP 2453 datagram within it, if the message fails to satisfy any of the 2454 following requirements: 2456 o The gateway MUST be waiting for a Membership Query message. 2458 o The Request Nonce value contained in the Membership Query MUST 2459 equal the Request Nonce value contained in the Request message. 2461 o The source IP address and UDP port of the Membership Query MUST 2462 equal the destination IP address and UDP port of the matching 2463 Request message (i.e., the current relay address). 2465 o The encapsulated IP datagram MUST carry an IGMPv3 or MLDv2 2466 message. The protocol MUST match the protocol identified by the 2467 "P" flag in the Request message. 2469 o The IGMPv3 or MLDv2 message MUST be a general query message. 2471 o The total length of the encapsulated IP datagram as computed from 2472 the lengths contained in the datagram header(s) MUST NOT exceed 2473 the available field length within the Membership Query message. 2475 Once a gateway receives a Membership Query response to a Request 2476 message, it SHOULD ignore any other Membership Query messages that 2477 arrive on the AMT interface until it sends a new Request message. 2479 The gateway MUST save the Membership Query message, or the Request 2480 Nonce, Response MAC, Gateway IP Address and Gateway Port Number 2481 fields for use in sending subsequent Membership Update and Teardown 2482 messages. 2484 The gateway extracts the encapsulated IP datagram and forwards it to 2485 the local IP protocol implementation for checksum verification and 2486 dispatching to the IGMP or MLD implementation running on the pseudo- 2487 interface. The gateway MUST NOT forward any octets that might exist 2488 between the encapsulated IP datagram and the end of the message or 2489 Gateway Address fields. 2491 The MLD protocol specification indicates that senders should use a 2492 link-local source IP address in message datagrams. This requirement 2493 must be relaxed for AMT because gateways and relays do not normally 2494 share a common subnet. For this reason, a gateway implementation 2495 MUST accept MLD (and IGMP) query message datagrams regardless of the 2496 source IP address they carry. This may require additional processing 2497 on the part of the gateway that might be avoided if the relay and 2498 gateway use the IPv4 and IPv6 addresses allocated for use in AMT 2499 encapsulated control packets as described in Section 5.2.1. 2501 The gateway MUST start a timer that will trigger the next iteration 2502 of the membership update cycle by executing the membership query 2503 procedure. The gateway SHOULD compute the timer duration from the 2504 Querier's Query Interval Code carried by the general-query. A 2505 gateway MAY use a smaller timer duration if required to refresh a NAT 2506 mapping that would otherwise timeout. A gateway MAY use a larger 2507 timer duration if it has no group subscriptions to report. 2509 If the gateway supports the Teardown message and the G-flag is set in 2510 the Membership Query message, the gateway MUST compare the Gateway IP 2511 Address and Gateway Port Number on the new Membership Query message 2512 with the values carried by the previous Membership Query message. If 2513 either value has changed the gateway MUST send a Teardown message to 2514 the relay as described in Section 5.2.3.7. 2516 If the L-flag is set in the Membership Query message, the relay is 2517 reporting that it is NOT accepting Membership Update messages that 2518 create new tunnel endpoints and will simply ignore any that do. If 2519 the L-flag is set and the gateway is not currently reporting any 2520 group subscriptions to the relay, the gateway SHOULD stop sending 2521 periodic Request messages and restart the relay discovery procedure 2522 (if discovery is enabled) to find a new relay with which to 2523 communicate. The gateway MAY continue to send updates even if the 2524 L-flag is set, if it has previously reported group subscriptions to 2525 the relay, one or more subscriptions still exist and the gateway 2526 endpoint address has not changed since the last Membership Query was 2527 received (see previous paragraph). 2529 5.2.3.5.5. Handling Query Timer Expiration 2531 When the query timer (started in the previous step) expires, the 2532 gateway should execute the membership query procedure again to 2533 continue the membership update cycle. 2535 5.2.3.5.6. Request Nonce Generation 2537 The request nonce MUST be a random value, and if possible, SHOULD be 2538 computed using a cryptographically secure pseudo random number 2539 generator. A new nonce MUST be generated each time the gateway 2540 starts the membership query process. The same nonce SHOULD be used 2541 when retransmitting a Request message. 2543 5.2.3.6. Membership Update Procedure 2545 This section describes gateway requirements related to the membership 2546 update message sequence described in Section 4.2.1.2. 2548 The membership update process is primarily driven by the host-mode 2549 IGMP or MLD protocol implementation running on the gateway pseudo- 2550 interface. The IGMP and MLD protocols produce current-state reports 2551 in response to general queries generated by the pseudo-interface via 2552 AMT and produce state-change reports in response to receiver requests 2553 made using the IGMP or MLD service interface. 2555 5.2.3.6.1. Handling an IGMP/MLD IP Datagram 2556 The gateway pseudo-interface MUST accept the following IP datagrams 2557 from the IPv4/IGMP and IPv6/MLD protocols running on the pseudo- 2558 interface: 2560 o IPv4 datagrams that carry an IGMPv2, or IGMPv3 Membership Report 2561 or an IGMPv2 Leave Group message as described in Section 4 of 2562 [RFC3376]. 2564 o IPv6 datagrams that carry an MLDv1 or MLDv2 Multicast Listener 2565 Report or an MLDv1 Multicast Listener Done message as described in 2566 Section 5 of [RFC3810]. 2568 The gateway must be prepared to receive these messages any time the 2569 pseudo-interface is running. The gateway MUST ignore any datagrams 2570 not listed above. 2572 A gateway that waits to start a membership update cycle until after 2573 it receives a datagram containing an IGMP/MLD state-change message 2574 MAY: 2576 o Discard IGMP or MLD datagrams until it receives a Membership Query 2577 message, at which time it processes the Membership Query message 2578 as normal to eventually produce a current-state report on the 2579 pseudo-interface which describes the end state (RECOMMENDED). 2581 o Insert IGMP or MLD datagrams into a queue for transmission after 2582 it receives a Membership Query message. 2584 If and when a gateway receives a Membership Query message (for IGMP 2585 or MLD) it sends any queued or incoming IGMP or MLD datagrams to the 2586 relay as described in the next section. 2588 5.2.3.6.2. Sending a Membership Update Message 2590 A gateway cannot send a Membership Update message to a relay until it 2591 has received a Membership Query message from a relay. If the gateway 2592 has not yet located a relay with which to communicate, it MUST first 2593 execute the relay discovery procedure described in Section 5.2.3.4 to 2594 obtain a relay address. If the gateway has a relay address, but has 2595 not yet received a Membership Query message, it MUST first execute 2596 the membership query procedure described in Section 5.2.3.5 to obtain 2597 a Request Nonce and Response MAC that can be used to send a 2598 Membership Update message. 2600 Once a gateway possesses a valid Relay Address, Request Nonce and 2601 Response MAC, it may encapsulate the IP datagram containing the IGMP/ 2602 MLD message into a Membership Update message. The gateway MUST copy 2603 the Request Nonce and Response MAC values from the last Membership 2604 Query received from the relay into the corresponding fields in the 2605 Membership Update. The gateway MUST send the Membership Update 2606 message using the Relay Address and IANA-assigned AMT port number as 2607 the destination. 2609 When a gateway sends a Membership Update message, it may be notified 2610 that an ICMP Destination Unreachable message was received as a result 2611 of an earlier AMT message transmission. Handling of ICMP Destination 2612 Unreachable messages is described in Section 5.2.3.9. 2614 5.2.3.7. Teardown Procedure 2616 This section describes gateway requirements related to the teardown 2617 message sequence described in Section 4.2.1.3. 2619 Gateway support for the Teardown message is RECOMMENDED. 2621 A gateway that supports Teardown SHOULD make use of Teardown 2622 functionality if it receives a Membership Query message from a relay 2623 that has the "G" flag set to indicate that it contains valid gateway 2624 address fields. 2626 5.2.3.7.1. Handling a Membership Query Message 2628 As described in Section 5.2.3.5.4, if a gateway supports the Teardown 2629 message, has reported active group subscriptions, and receives a 2630 Membership Query message with the "G" flag set, the gateway MUST 2631 compare the Gateway IP Address and Gateway Port Number on the new 2632 Membership Query message with the values carried by the previous 2633 Membership Query message. If either value has changed the gateway 2634 MUST send a Teardown message as described in the next section. 2636 5.2.3.7.2. Sending a Teardown Message 2638 A gateway sends a Teardown message to a relay to request that it stop 2639 delivering Multicast Data messages to the gateway and delete any 2640 group memberships created by the gateway. 2642 When a gateway constructs a Teardown message, it MUST copy the 2643 Request Nonce, Response MAC, Gateway IP Address and Gateway Port 2644 Number fields from the Membership Query message that provided the 2645 Response MAC for the last Membership Update message sent, into the 2646 corresponding fields of the Teardown message. 2648 A gateway MUST send the Teardown message using the Relay Address and 2649 IANA-assigned AMT port number as the destination. A gateway MAY send 2650 the Teardown message multiple times for robustness. The gateway 2651 SHOULD use the Querier's Robustness Variable (QRV) field contained in 2652 the query encapsulated within the last Membership Query to set the 2653 limit on the number of retransmissions (See Section 4.1.6 in 2654 [RFC3376] and Section 5.1.7 in [RFC3810]). If the gateway sends the 2655 Teardown message multiple times, it SHOULD insert a delay between 2656 each transmission using the timing algorithm employed in IGMP/MLD for 2657 transmitting unsolicited state-change reports. The RECOMMENDED 2658 default delay value is 1 second. 2660 When a gateway sends a Teardown message, it may be notified that an 2661 ICMP Destination Unreachable message was received as a result of an 2662 earlier AMT message transmission. Handling of ICMP Destination 2663 Unreachable messages is described in Section 5.2.3.9. 2665 5.2.3.8. Shutdown 2667 When a gateway pseudo-interface is stopped and the gateway has 2668 existing group subscriptions, the gateway SHOULD either: 2670 o Send a Teardown message to the relay as described in 2671 Section 5.2.3.7, but only if the gateway supports the Teardown 2672 message, and the current relay is returning gateway address fields 2673 in Membership Query messages, or 2675 o Send a Membership Update message to the relay that will delete 2676 existing group subscriptions. 2678 5.2.3.9. Handling ICMP Destination Unreachable Responses 2680 A gateway may receive an ICMP "Destination Unreachable" message 2681 [RFC0792] after sending an AMT message. Whether the gateway is 2682 notified that an ICMP message was received is highly dependent on 2683 firewall and gateway IP stack behavior and gateway implementation. 2685 If the reception of an ICMP Destination Unreachable message is 2686 reported to the gateway while waiting to receive an AMT message, the 2687 gateway may respond as follows, depending on platform capabilities 2688 and which outgoing message triggered the ICMP response: 2690 1. The gateway MAY simply abandon the current relay and restart 2691 relay discovery (if used). This is the least desirable approach 2692 as it does not allow for transient network changes. 2694 2. If the last message sent was a Relay Discovery or Request 2695 message, the gateway MAY simply ignore the ICMP response and 2696 continue waiting for incoming AMT messages. If the gateway is 2697 configured to retransmit Relay Discovery or Request messages, the 2698 normal retransmission behavior for those messages is preserved to 2699 prevent the gateway from prematurely abandoning a relay. 2701 3. If the last message sent was a Membership Update message, the 2702 gateway MAY start a new membership update and associated Request 2703 retransmission cycle. 2705 If the reception of an ICMP Destination Unreachable message is 2706 reported to the gateway when attempting to transmit a new AMT 2707 message, the gateway may respond as follows, depending on platform 2708 capabilities and which outgoing message triggered the ICMP response: 2710 1. The gateway MAY simply abandon the current relay and restart 2711 relay discovery (if used). This is the least desirable approach 2712 as it does not allow for transient network changes. 2714 2. If the last message sent was a Relay Discovery, Request or 2715 Teardown message, the gateway MAY attempt to transmit the new 2716 message. If the gateway is configured to retransmit Relay 2717 Discovery, Request or Teardown messages, the normal 2718 retransmission behavior for those messages is preserved to 2719 prevent the gateway from prematurely abandoning a relay. 2721 3. If the last message sent was a Membership Update message, the 2722 gateway SHOULD start a new membership update and associated 2723 Request retransmission cycle. 2725 5.3. Relay Operation 2727 The following sections describe relay implementation requirements. A 2728 non-normative discussion of relay operation may be found in 2729 Section 4.2. 2731 5.3.1. IP/IGMP/MLD Protocol Requirements 2733 A relay requires a subset of router-mode IGMP and MLD functionality 2734 to provide group membership tracking and report processing. 2736 A relay accessible via IPv4 MUST support IPv4/IGMPv3 and MAY support 2737 IPv6/MLDv2. A relay accessible via IPv6 MUST support IPv6/MLDv2 and 2738 MAY support IPv4/IGMPv3. 2740 A relay MUST apply the forwarding rules described in Section 6.3 of 2741 [RFC3376] and Section 7.3 of [RFC3810]. 2743 A relay MUST handle incoming reports as described in Section 6.4 of 2744 [RFC3376] and Section 7.4 of [RFC3810] with the exception that 2745 actions that lead to queries MAY be modified to eliminate query 2746 generation. A relay MUST accept IGMP and MLD report datagrams 2747 regardless of the IP source address carried by those datagrams. 2749 All other aspects of IGMP/MLD router behavior, such as the handling 2750 of queries, querier election, etc., are not used or required for 2751 relay operation. 2753 5.3.2. Startup 2755 If a relay is deployed for anycast discovery, the relay MUST 2756 advertise an anycast Relay Discovery Address Prefix into the unicast 2757 routing system of the anycast domain. An address within that prefix, 2758 i.e., a Relay Discovery Address, MUST be assigned to a relay 2759 interface. 2761 A unicast IPv4 and/or IPv6 address MUST be assigned to the relay 2762 interface that will be used to send and receive AMT control and data 2763 messages. This address or addresses are returned in Relay 2764 Advertisement messages. 2766 The remaining details of relay "startup" are highly implementation- 2767 dependent and are not addressed in this document. 2769 5.3.3. Running 2771 When a relay is started, it begins listening for AMT messages on the 2772 interface to which the unicast Relay Address(es) has been assigned, 2773 i.e., the address returned in Relay Advertisement messages. 2775 5.3.3.1. Handling AMT Messages 2777 A relay MUST ignore any message other than a Relay Discovery, 2778 Request, Membership Update or Teardown message. The handling of 2779 Relay Discovery, Request, Membership Update, and Teardown messages is 2780 addressed in the sections that follow. 2782 Support for the Teardown message is OPTIONAL. If a relay does not 2783 support the Teardown message, it MUST also ignore this message. 2785 A relay that conforms to this specification MUST ignore any message 2786 with a Version field value other than zero. 2788 5.3.3.2. Handling a Relay Discovery Message 2790 This section describes relay requirements related to the relay 2791 discovery message sequence described in Section 4.2.1.1. 2793 A relay MUST accept and respond to Relay Discovery messages sent to 2794 an anycast relay discovery address or the unicast relay address. If 2795 a relay receives a Relay Discovery message sent to its unicast 2796 address, it MUST respond just as it would if the message had been 2797 sent to its anycast discovery address. 2799 When a relay receives a Relay Discovery message it responds by 2800 sending a Relay Advertisement message back to the source of the Relay 2801 Discovery message. The relay MUST use the source IP address and UDP 2802 port of the Relay Discovery message as the destination IP address and 2803 UDP port. The relay MUST use the destination IP address and UDP port 2804 of the Relay Discovery as the source IP address and UDP port to 2805 ensure successful NAT traversal. 2807 The relay MUST copy the value contained in the Discovery Nonce field 2808 of the Relay Discovery message into the Discovery Nonce field in the 2809 Relay Advertisement message. 2811 If the Relay Discovery message was received as an IPv4 datagram, the 2812 relay MUST return an IPv4 address in the Relay Address field of the 2813 Relay Advertisement message. If the Relay Discovery message was 2814 received as an IPv6 datagram, the relay MUST return an IPv6 address 2815 in the Relay Address field. 2817 5.3.3.3. Handling a Request Message 2819 This section describes relay requirements related to the membership 2820 query portion of the message sequence described in Section 4.2.1.2. 2822 When a relay receives a Request message it responds by sending a 2823 Membership Query message back to the source of the Request message. 2825 The relay MUST use the source IP address and UDP port of the Request 2826 message as the destination IP address and UDP port for the Membership 2827 Query message. The source IP address and UDP port carried by the 2828 Membership Query MUST match the destination IP address and UDP port 2829 of the Request to ensure successful NAT traversal. 2831 The relay MUST return the value contained in the Request Nonce field 2832 of the Request message in the Request Nonce field of the Membership 2833 Query message. The relay MUST compute a MAC value, as described in 2834 Section 5.3.5, and return that value in the Response MAC field of the 2835 Membership Query message. 2837 If a relay supports the Teardown message, it MUST set the G-flag in 2838 the Membership Query message and return the source IP address and UDP 2839 port carried by the Request message in the corresponding Gateway IP 2840 Address and Gateway Port Number fields. If the relay does not 2841 support the Teardown message it SHOULD NOT set these fields as this 2842 may cause the gateway to generate unnecessary Teardown messages. 2844 If the P-flag in the Request message is 0, the relay MUST return an 2845 IPv4-encapsulated IGMPv3 general query in the Membership Query 2846 message. If the P-flag is 1, the relay MUST return an 2847 IPv6-encapsulated MLDv2 general query in the Membership Query 2848 message. 2850 If the relay is not accepting Membership Update messages that create 2851 new tunnel endpoints due to resource limitations, it SHOULD set the 2852 L-flag in the Membership Query message to notify the gateway of this 2853 state. Support for the L-flag is OPTIONAL. See Section 5.3.3.8. 2855 The IGMPv3 general query datagram that a relay encapsulates within a 2856 Membership Query message MUST conform to the descriptions found in 2857 Section 4.1 of [RFC3376]. These datagrams MUST possess the IP 2858 headers, header options and header values called for in [RFC3376], 2859 with the following exception; the source IP address for an IGMP 2860 general query datagram MAY be set to the "unspecified" address (all 2861 octets are zero) but SHOULD be set to an address in the address range 2862 specifically assigned by IANA for use in the IGMP messages sent from 2863 a relay to a gateway (i.e. 154.7.1.1 as described in Section 7). 2864 This exception is made because the source address that a relay might 2865 normally send may not be a valid source address on any gateway 2866 interface. The rationale for using the aforementioned source 2867 addresses is primary one of convenience - a gateway will accept an 2868 IGMP query regardless of the source address it carries. See 2869 Section 5.2.1. 2871 The MLDv2 general query datagram that a relay encapsulates within a 2872 Membership Query message MUST conform to the descriptions found in 2873 Section 5.1 of [RFC3810]. These datagrams MUST possess the IP 2874 headers, header options and header values called for in [RFC3810], 2875 with the following exception; the source IP address for an MLD 2876 general query datagram MAY be set to the "unspecified" address (all 2877 octets are zero) but SHOULD be set to an IPv6 link-local address in 2878 the range FE80::/64. A relay may use a dynamically-generated link- 2879 local address or the fixed address FE80::2. As with IGMP, a gateway 2880 will accept an MLD query regardless of the source address it carries. 2881 See Section 5.2.1. 2883 A relay MUST set the Querier's Query Interval Code (QQIC) field in 2884 the general query to supply the gateway with a suggested time 2885 duration to use for the membership query timer. The QQIC field is 2886 defined in Section 4.1.7 in [RFC3376] and Section 5.1.9 in [RFC3810]. 2887 A relay MAY adjust this value to affect the rate at which the Request 2888 messages are sent from a gateway. However, a gateway is allowed to 2889 use a shorter duration than specified in the QQIC field, so a relay 2890 may be limited in its ability to spread out Requests coming from a 2891 gateway. 2893 A relay MUST set the Querier's Robustness Variable (QRV) field in the 2894 general query to a non-zero value. This value SHOULD be greater than 2895 one. If a gateway retransmits membership state change messages, it 2896 will retransmit them (robustness variable - 1) times. The QRV field 2897 is defined in Section 4.1.6 in [RFC3376] and Section 5.1.8 in 2898 [RFC3810]. 2900 A relay SHOULD set the Maximum Response Code field in the general 2901 query to a value of 1 to trigger an immediate response from the 2902 gateway (some host IGMP/MLD implementations may not accept a value of 2903 zero). A relay SHOULD NOT use the IGMPv2/MLDv2 Query Response 2904 Interval variable, if available, to generate the Maximum Response 2905 Code field value as the Query Response Interval variable is used in 2906 setting the duration of group state timers and must not be set to 2907 such a small value. The Maximum Response Code field is defined in 2908 Section 4.1.1 in [RFC3376] and Section 5.1.3 in [RFC3810]. See 2909 Section 5.3.3.7. 2911 5.3.3.4. Handling a Membership Update Message 2913 This section describes relay requirements related to the membership 2914 update portion of the message sequence described in Section 4.2.1.2. 2916 When a relay receives a Membership Update message it must first 2917 determine whether it should accept or ignore the message. A relay 2918 MUST NOT make any changes to group membership and forwarding state if 2919 the message fails to satisfy any of the following requirements: 2921 o The IP datagram encapsulated within the message MUST be one of the 2922 following: 2924 * IPv4 datagram carrying an IGMPv2 or IGMPv3 Membership Report 2925 message. 2927 * IPv4 datagram carrying an IGMPv2 Leave Group message. 2929 * IPv6 datagram carrying an MLDv1 or MLDv2 Multicast Listener 2930 Report message. 2932 * IPv6 datagram carrying MLDv1 Multicast Listener Done message. 2934 o The encapsulated IP datagram MUST satisfy the IP header 2935 requirements for the IGMP or MLD message type as described in 2936 Section 4 of [RFC3376], Section 2 of [RFC2236], Section 5 of 2938 [RFC3810], and Section 3 of [RFC2710], with the following 2939 exception - a relay MUST accept an IGMP or MLD message regardless 2940 of the IP source address carried by the datagram. 2942 o The total length of the encapsulated IP datagram as computed from 2943 the lengths contained in the datagram header(s) MUST NOT exceed 2944 the available field length within the Membership Update message. 2946 o The computed checksums for the encapsulated IP datagram and its 2947 payload MUST match the values contained therein. Checksum 2948 computation and verification varies by protocol; See [RFC0791] for 2949 IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6). 2951 o If processing of the encapsulated IGMP or MLD message would result 2952 in an allocation of new state or a modification of existing state, 2953 the relay MUST authenticate the source of the Membership message 2954 by verifying that the value contained in the Response MAC field 2955 equals the MAC value computed from the fields in the Membership 2956 Update message datagram. Because the private secret used to 2957 compute Response MAC values may change over time, the relay MUST 2958 retain the previous version of the private secret to use in 2959 authenticating Membership Updates sent during the subsequent query 2960 interval. If the first attempt at Response MAC authentication 2961 fails, the relay MUST attempt to authenticate the Response MAC 2962 using the previous private secret value unless 2*query_interval 2963 time has elapsed since the private secret change. See 2964 Section 5.3.5. An alternative approach to Response MAC generation 2965 that avoids repeated Response MAC computations may be found in 2966 Appendix A.1. 2968 A relay MAY skip source authentication to reduce the computational 2969 cost of handling Membership Update messages if the relay can make a 2970 trivial determination that the IGMP/MLD message carried by the 2971 Membership Update message will produce no changes in group membership 2972 or forwarding state. The relay does not need to compute and compare 2973 MAC values if it finds there are no group subscriptions for the 2974 source of the Membership Update message and either of the following 2975 is true: 2977 o The encapsulated IP datagram is an IGMPv3 Membership Report or 2978 MLDv2 Multicast Listener Report message that contains no group 2979 records. This may often be the case for gateways that 2980 continuously repeat the membership update cycle even though they 2981 have no group subscriptions to report. 2983 o The encapsulated IP datagram is an IGMPv2 Leave Group or MLDv1 2984 Multicast Listener Done message. 2986 The IGMP and MLD protocol specifications indicate that senders SHOULD 2987 use a link-local source IP address in message datagrams. This 2988 requirement must be relaxed for AMT because gateways and relays do 2989 not share a common subnet. For this reason, a relay implementation 2990 MUST accept IGMP and MLD datagrams regardless of the source IP 2991 address they carry. 2993 Once a relay has determined that the Membership Update message is 2994 valid, it processes the encapsulated IGMP or MLD membership message 2995 to update group membership state and communicates with the multicast 2996 protocol to update forwarding state and possibly send multicast 2997 protocol messages towards upstream routers. The relay MUST ignore 2998 any octets that might exist between the encapsulated IP datagram and 2999 the end of the Membership Update message. 3001 As described in Section 4.2.2, a relay uses the source IP address and 3002 source UDP port carried by a Membership Update messages to identify a 3003 tunnel endpoint. A relay uses the tunnel endpoint as the destination 3004 address for any Multicast Data messages it sends as a result of the 3005 group membership and forwarding state created by processing the IGMP/ 3006 MLD messages contained in Membership Update messages received from 3007 the endpoint. 3009 If a Membership Update message originates from a new endpoint, the 3010 relay MUST determine whether it can accept updates from a new 3011 endpoint. If a relay has been configured with a limit on the total 3012 number of endpoints, or a limit on the total number of endpoints for 3013 a given source address, then the relay MAY ignore the Membership 3014 Update message and possibly withdraw any Relay Discovery Address 3015 Prefix announcement that it might have made. See Section 5.3.3.8. 3017 A relay MUST maintain some form of group membership database for each 3018 endpoint. The per-endpoint databases are used update a forwarding 3019 table containing entries that map an (*,G) or (S,G) subscription to a 3020 list of tunnel endpoints. 3022 A relay MUST maintain some form of group membership database 3023 representing a merger of the group membership databases of all 3024 endpoints. The merged group membership database is used to update 3025 upstream multicast forwarding state. 3027 A relay MUST maintain a forwarding table that maps each unique (*,G) 3028 and (S,G) subscription to a list of tunnel endpoints. A relay uses 3029 this forwarding table to provide the destination address when 3030 performing UDP/IP encapsulation of the incoming multicast IP 3031 datagrams to form Multicast Data messages. 3033 If a group filter mode for a group entry on a tunnel endpoint is 3034 EXCLUDE, the relay SHOULD NOT forward datagrams that originate from 3035 sources in the filter source list unless the relay architecture does 3036 not readily support source filtering. A relay MAY ignore the source 3037 list if necessary because gateways are expected to do their own 3038 source filtering. 3040 5.3.3.5. Handling a Teardown Message 3042 This section describes relay requirements related to the teardown 3043 message sequence described in Section 4.2.1.3. 3045 When a relay (that supports the Teardown message) receives a Teardown 3046 message, it MUST first authenticate the source of the Teardown 3047 message by verifying that the Response MAC carried by the Teardown 3048 message is equal to a MAC value computed from the fields carried by 3049 the Teardown message. The method used to compute the MAC differs 3050 from that used to generate and validate the Membership Query and 3051 Membership Update messages in that the source IP address and source 3052 UDP port number used to compute the MAC are taken from the Gateway IP 3053 Address and Gateway Port Number field in the Teardown message rather 3054 than from the IP and UDP headers in the datagram that carries the 3055 Teardown message. The MAC computation is described Section 5.3.5. A 3056 relay MUST ignore a Teardown message If the computed MAC does not 3057 equal the value of the Response MAC field. 3059 If a relay determines that a Teardown message is authentic, it MUST 3060 immediately stop transmitting Multicast Data messages to the endpoint 3061 identified by the Gateway IP Address and Gateway Port Number fields 3062 in the message. The relay MUST eventually delete any group 3063 membership and forwarding state associated with the endpoint, but MAY 3064 delay doing so to allow a gateway to recreate group membership state 3065 on a new endpoint and thereby avoid making unnecessary (temporary) 3066 changes in upstream routing/forwarding state. 3068 The state changes made by a relay when processing a Teardown message 3069 MUST be identical to those that would be made as if the relay had 3070 received an IGMP/MLD report that would cause the IGMP or MLD protocol 3071 to delete all existing group records in the group membership database 3072 associated with the endpoint. The processing of the Teardown message 3073 should trigger or mimic the normal interaction between IGMP or MLD 3074 and a multicast protocol to produce required changes in forwarding 3075 state and possibly send prune/leave messages towards upstream 3076 routers. 3078 5.3.3.6. Handling Multicast IP Datagrams 3079 When a multicast IP datagram is forwarded to the relay pseudo- 3080 interface, the relay MUST, for each gateway that has expressed an 3081 interest in receiving the datagram, encapsulate the IP datagram into 3082 a Multicast Data message or messages and send that message or 3083 messages to the gateway. This process is highly implementation 3084 dependent, but conceptually requires the following steps: 3086 o Use the IP datagram source and destination address to look up the 3087 appropriate (*,G) or (S,G) entry in the endpoint forwarding table 3088 created for the pseudo-interface as a result of IGMP/MLD 3089 processing. 3091 o Possibly replicate the datagram for each gateway endpoint listed 3092 for that (*,G) or (S,G) entry. 3094 o If the multicast IP datagram size exceeds the Tunnel MTU as 3095 determined according to the procedure described in 3096 Section 5.3.3.6.1, the relay must execute the procedure described 3097 in Section 5.3.3.6.2. 3099 o Encapsulate and transmit the IP datagram according to the 3100 procedure described in Section 5.3.3.6.3. 3102 The relay pseudo-interface MUST ignore any other IP datagrams 3103 forwarded to the pseudo-interface. 3105 5.3.3.6.1. Path and Tunnel MTU 3107 A relay MUST compute a Tunnel MTU (TMTU) value for each AMT tunnel 3108 that originates on the relay. A relay will use the TMTU value to 3109 determine whether an incoming multicast IP datagram can be delivered 3110 downstream in a Membership Data message without fragmentation. A 3111 relay MUST compute the TMTU by subtracting the size of the Membership 3112 Data message headers (IP, UDP, and AMT) from the current Path MTU 3113 (PMTU) associated with each AMT tunnel. The relay MUST maintain a 3114 PMTU value on a per-tunnel or per-relay basis. A relay MUST support 3115 one or both of the following methods for determining the PMTU value: 3117 o The relay MAY provide a configuration option that establishes a 3118 fixed PMTU that will be applied to all AMT tunnels originating at 3119 the relay. 3121 o The relay MAY dynamically adjust PMTU value(s) in response to 3122 receipt of ICMP/ICMPv6 "Datagram Too Big" messages as described in 3123 [RFC1191] and [RFC1981]. 3125 If a relay supports dynamic adjustment of per-tunnel or per-relay 3126 PMTU values in response to ICMP messages, the relay MUST provide a 3127 configuration option that disables this feature and also provide a 3128 configuration option that establishes a minimum PMTU for all tunnels. 3129 These configuration options may be used to mitigate certain types of 3130 denial of service attacks (See (Section 6)). When dynamic PMTU 3131 adjustments are disabled, the PMTU for all tunnels MUST default to 3132 the Link MTU (first-hop) on the downstream interface. 3134 5.3.3.6.2. MTU Filtering Procedure 3136 This section defines procedures that a relay must execute when it 3137 receives a multicast datagram whose size is greater than the Tunnel 3138 MTU of the tunnel or tunnels through which it must be delivered. 3140 5.3.3.6.2.1. IPv4 Multicast IP Datagrams 3142 If the DF bit in the multicast datagram header is set to 1 (Don't 3143 Fragment), the relay MUST discard the packet and, if the datagram 3144 originated from an SSM source, send an ICMPv4 [RFC0792] Destination 3145 Unreachable message to the source, with type equal to 4 3146 (fragmentation needed and DF set). The ICMP Destination Unreachable 3147 message MUST contain an next-hop MTU (as specified by [RFC1191] and 3148 [RFC1191]) and the relay MUST set the next-hop MTU to the TMTU 3149 associated with the tunnel or tunnels. If the DF bit in the 3150 multicast datagram header is set to 0 (May Fragment), the relay MUST 3151 fragment the datagram and encapsulate each fragment within Multicast 3152 Data messages for transmission through the tunnel or tunnels. This 3153 ensures that gateways will receive complete, non-fragmented Multicast 3154 Data messages, containing fragmented multicast datagram payloads. 3155 The relay SHOULD avoid generating a separate ICMP message for each 3156 tunnel, but instead send a single ICMP message with a Next-hop MTU 3157 equal to the smallest TMTU of all tunnels to which the datagram was 3158 to be forwarded. 3160 5.3.3.6.2.2. IPv6 Multicast IP Datagrams 3162 The relay MUST discard the packet and, if the datagram originated 3163 from an SSM source, send an ICMPv6 [RFC4443] Packet Too Big message 3164 to the payload source. The MTU specified in the Packet Too Big 3165 message MUST be equal to the TMTU associated with the tunnel or 3166 tunnels. The relay SHOULD avoid generating a separate ICMPv6 message 3167 for each tunnel, but instead send a single ICMPv6 message with a 3168 Next-hop MTU equal to the smallest TMTU of all tunnels to which the 3169 datagram was to be forwarded. 3171 5.3.3.6.3. Encapsulation Procedure 3173 A relay encapsulates a multicast IP datagram in a UDP/IP Membership 3174 Data message, using the tunnel endpoint UDP/IP address as the 3175 destination address and the unicast relay address and IANA-assigned 3176 AMT port number as the source UDP/IP address. To ensure successful 3177 NAT traversal, the source address and port MUST match the destination 3178 address and port carried by the Membership Update message sent by the 3179 gateway to create the forwarding table entry. 3181 If possible, the relay SHOULD compute a valid, non-zero checksum for 3182 the UDP datagram carrying the Multicast Data message. See 3183 Section 4.2.2.3. 3185 The following sections describe additional requirements related to 3186 the IP protocol of the tunnel and that of the multicast IP datagram. 3188 5.3.3.6.3.1. Tunneling over IPv4 3190 When a relay delivers an IPv4 payload over an IPv4 tunnel, and the DF 3191 Bit in the payload header is set to 1 (Don't Fragment), the relay 3192 MUST set the DF bit in the Multicast Data IP header to 1. When a 3193 relay delivers an IPv4 payload over an IPv4 tunnel, and the DF Bit in 3194 the payload header is set to 0 (May Fragment), by default, the relay 3195 MUST set the DF bit in the Multicast Data IP header to 1. However, a 3196 relay MAY provide a configuration option that allows the DF bit to be 3197 copied from the payload header to the Multicast Data IP header to 3198 allow downstream fragmentation of the Multicast Data message. When a 3199 relay delivers an IPv6 payload over an IPv4 tunnel, the relay MUST 3200 set the DF bit in the Multicast Data IP header to 1. The relay MUST 3201 NOT transmit a Multicast Data message with an IP header in which the 3202 MF (More Fragments) bit is set to 1. 3204 5.3.3.6.3.2. Tunneling over IPv6 3206 When a tunneling over IPv6, a relay MUST NOT emit a Multicast Data 3207 message datagram containing an IPv6 fragment header. 3209 5.3.3.6.4. Handling Destination Unreachable Messages 3211 If a relay receives a sequence of ICMP or ICMPv6 messages of type 3212 "Destination Unreachable" in response to transmission of a sequence 3213 of AMT Multicast Data messages to a gateway, the relay SHOULD 3214 discontinue sending messages to that gateway and shutdown the tunnel 3215 for that gateway (Handling of ICMP "Destination Unreachable" messages 3216 with code 4, "fragmentation required" is covered in 3217 Section 5.3.3.6.1). If a relay provides this capability, it MUTST 3218 provide a configuration option that indicates what number of 3219 sequential "Destination Unreachable" messages can be received and 3220 ignored before the relay will automatically shutdown a tunnel. 3222 5.3.3.7. State Timers 3224 A relay MUST maintain a timer or timers whose expiration will trigger 3225 the removal of any group subscriptions and forwarding state 3226 previously created for a gateway endpoint should the gateway fail to 3227 refresh the group membership state within a specified time interval. 3229 A relay MAY use a variant of the IGMPv3/MLDv2 state management 3230 protocol described in Section 6 of [RFC3376] or Section 7 of 3231 [RFC3810], or may maintain a per-endpoint timer to trigger the 3232 deletion of group membership state. 3234 If a per-endpoint timer is used, the relay MUST restart this timer 3235 each time it receives a new Membership Update message from the 3236 gateway endpoint. 3238 The endpoint timer duration MAY be computed from tunable IGMP/MLD 3239 variables as follows: 3241 ((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval 3243 If IGMP/MLD default values are used for these variables, the gateway 3244 will timeout after 125s * 2 + 10s = 260s. The timer duration MUST be 3245 greater than the query interval suggested in the last Membership 3246 Query message sent to the gateway endpoint. 3248 Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the 3249 Query_Response_Interval value SHOULD be greater than or equal to 10s 3250 to allow for packet loss and round-trip time in the Request/ 3251 Membership Query message exchange. 3253 5.3.3.8. Relay Resource Management 3255 A relay may be configured with various service limits to ensure a 3256 minimum level of performance for gateways that connect to it. 3258 If a relay has determined that it has reached or exceeded maximum 3259 allowable capacity or has otherwise exhausted resources required to 3260 support additional gateways, it SHOULD withdraw any Relay Discovery 3261 Address Prefix it has advertised into the unicast internetwork and 3262 SHOULD set the L-flag in any Membership Query messages it returns to 3263 gateways while in this state. 3265 If the relay receives an update from a gateway that adds group 3266 membership or forwarding state for an endpoint that has already 3267 reached maximum allowable state entries, the relay SHOULD continue to 3268 accept updates from the gateway but ignore any group membership/ 3269 forwarding state additions requested by that gateway. 3271 If the relay receives an update from a gateway that would create a 3272 new tunnel endpoint for a source IP address that has already reached 3273 the maximum allowable number of endpoints (maximum UDP ports), it 3274 should simply ignore the Membership Update. 3276 5.3.4. Shutdown 3278 The following steps should be treated as an abstract description of 3279 the shutdown procedure for a relay: 3281 o Withdraw the Relay Discovery Address Prefix advertisement (if 3282 used). 3284 o Stop listening for Relay Discovery messages. 3286 o Stop listening for control messages from gateways. 3288 o Stop sending data messages to gateways. 3290 o Delete all AMT group membership and forwarding state created on 3291 the relay, coordinating with the multicast routing protocol to 3292 update the group membership state on upstream interfaces as 3293 required. 3295 5.3.5. Response MAC Generation 3297 A Response MAC is produced by a hash digest computation. A Response 3298 MAC computation is required in the following situations: 3300 o To generate a Response MAC value from a Request message for 3301 inclusion in a Membership Query message. 3303 o Tp generate a Response MAC value from a Membership Update message 3304 for use in authenticating the Response MAC carried within that 3305 message. 3307 o To generate a Response MAC value from a Teardown message to 3308 authenticate the Response MAC carried within that message. 3310 Gateways treat the Response MAC field as an opaque value, so a relay 3311 implementation may generate the MAC using any method available to it. 3312 The hash function RECOMMENDED for use in computing the Response MAC 3313 is the MD5 hash digest [RFC1321], though hash functions or keyed-hash 3314 functions of greater cryptographic strength may be used. 3316 The digest MUST be computed over the following values: 3318 o The Source IP address of the message (or Teardown Gateway IP 3319 Address field) 3321 o The Source UDP port of the message (or Teardown Gateway Port 3322 Number field) 3324 o The Request Nonce contained in the message. 3326 o A private secret known only to the relay 3328 An Response MAC generation solution that satisfies these requirements 3329 is described in Appendix A.1. 3331 5.3.6. Private Secret Generation 3333 The private secret, or hash-key, is a random value that the relay 3334 includes in the Response MAC hash digest computation. A relay SHOULD 3335 periodically compute a new private secret. The RECOMMENDED maximum 3336 interval is 2 hours. A relay MUST retain the prior secret for use in 3337 verifying MAC values that were sent to gateways just prior to the use 3338 of the new secret. 3340 The private secret SHOULD be computed using a cryptographically- 3341 secure pseudo-random number generator. The private secret width 3342 SHOULD equal that of the hash function used to compute the Response 3343 MAC, e.g., 128-bits for an MD5 hash. 3345 6. Security Considerations 3347 AMT is not intended to be a strongly secured protocol. In general, 3348 the protocol provides the same level of security and robustness as is 3349 provided by the UDP, IGMP and MLD protocols on which it relies. The 3350 lack of strong security features can largely be attributed to the 3351 desire to make the protocol light-weight by minimizing the state and 3352 computation required to service a single gateway, thereby allowing a 3353 relay to service a larger number of gateways. 3355 Many of the threats and vectors described in [RFC3552] may be 3356 employed against the protocol to launch various types of denial-of- 3357 service attacks that can affect the functioning of gateways or their 3358 ability to locate and communicate with a relay. These scenarios are 3359 described below. 3361 As is the case for UDP, IGMP and MLD, the AMT protocol provides no 3362 mechanisms for ensuring message delivery or integrity. The protocol 3363 does not provide confidentiality - multicast groups, sources and 3364 streams requested by a gateway are sent in the clear. 3366 The protocol does use a three-way handshake to provide trivial source 3367 authentication for state allocation and updates (see below). The 3368 protocol also requires gateways and relays to ignore malformed 3369 messages and those messages that do not carry expected address values 3370 or protocol payload types or content. 3372 6.1. Relays 3374 The three-way handshake provided by the membership update message 3375 sequence (See (Section 4.2.1.2)) provides a defense against source- 3376 spoofing-based resource-exhaustion attacks on a relay by requiring 3377 source authentication before state allocation. However, attackers 3378 may still attempt to flood a relay with Request and Membership Update 3379 messages to force the relay to make the hash computations in an 3380 effort to consume computational resources. Implementations may 3381 choose to limit the frequency with which a relay responds to Request 3382 messages sent from a single IP address or IP address and UDP port 3383 pair, but support for this functionality is not required. The three- 3384 way handshake provides no defense against an eavesdropping or man-in- 3385 the-middle attacker. 3387 Attackers that execute the gateway protocol may consume relay 3388 resources by instantiating a large number of tunnels or joining a 3389 large number of multicast streams. A relay implementation should 3390 provide a mechanism for limiting the number of tunnels (Multicast 3391 Data message destinations) that can be created for a single gateway 3392 source address. Relays should also provide a means for limiting the 3393 number of joins per tunnel instance as a defense against these 3394 attacks. 3396 Relays may withdraw their AMT anycast prefix advertisement when they 3397 reach configured maximum capacity or exhaust required resources. 3398 This behavior allows gateways to use the relay discovery process to 3399 find the next topologically-nearest relay that has advertised the 3400 prefix. This behavior also allows a successful resource exhaustion 3401 attack to propagate from one relay to the next until all relays 3402 reachable using the anycast address have effectively been taken 3403 offline. This behavior may also be used to acquire the unicast 3404 addresses for individual relays which can then be used to launch a 3405 DDoS attack on all of the relays without using the relay discovery 3406 process. To prevent wider disruption of AMT-based distribution 3407 network, relay anycast address advertisements can be limited to 3408 specific administrative routing domains. This will isolate such 3409 attacks to a single domain. 3411 The Path and Tunnel MTU adjustment (discovery) procedure described in 3412 Section 5.3.3.6.1 is vulnerable to two denial of service attacks (see 3413 Section 8 of [RFC1191] for details). Both attacks are based upon on 3414 a malicious party sending forged ICMPv4 Destination Unreachable or 3415 ICMPv6 Packet Too Big messages to a host. In the first attack, the 3416 forged message indicates an inordinately small Path MTU. In the 3417 second attack, the forged message indicates an inordinately large 3418 Path MTU. In both cases, throughput is adversely affected. On order 3419 to mitigate such attacks, relay implementations MUST include a 3420 configuration option to disable Path MTU adjustments on AMT tunnels. 3422 6.2. Gateways 3424 A passive eavesdropper may launch a denial-of-service attack on a 3425 gateway by capturing a Membership Query or Membership Update message 3426 and using the request nonce and message authentication code carried 3427 by the captured message to send a spoofed a Membership Update or 3428 Teardown message to the relay. The spoofed messages may be used to 3429 modify or destroy group membership state associated with the gateway, 3430 thereby changing or interrupting the multicast traffic flows. 3432 A passive eavesdropper may also spoof Multicast Data messages in an 3433 attempt to overload the gateway or disrupt or supplant existing 3434 traffic flows. A properly implemented gateway will filter Multicast 3435 Data messages that do not originate from the expected relay address 3436 and should filter non-multicast packets and multicast IP packets 3437 whose group or source addresses are not included in the current 3438 reception state for the gateway pseudo-interface. 3440 An active eavesdropper may launch a man-in-the-middle attack in which 3441 messages normally exchanged between a gateway and relay are 3442 intercepted, modified, spoofed or discarded by the attacker. The 3443 attacker may deny access to, modify or replace requested multicast 3444 traffic. The AMT protocol provides no means for detecting or 3445 defending against a man-in-the-middle attack - any such functionality 3446 must be provided by multicast receiver applications through 3447 independent detection and validation of incoming multicast datagrams. 3449 The anycast discovery technique for finding relays (see 3450 Section 4.1.4) introduces a risk that a rogue router or a rogue AS 3451 could introduce a bogus route to a specific Relay Discovery Address 3452 prefix, and thus divert or absorb Relay Discovery messages sent by 3453 gateways. Network managers must guarantee the integrity of their 3454 routing to a particular Relay Discovery Address prefix in much the 3455 same way that they guarantee the integrity of all other routes. 3457 6.3. Encapsulated IP Packets 3459 An attacker forging or modifying a Membership Query or Membership 3460 Update message may attempt to embed something other than an IGMP or 3461 MLD message within the encapsulated IP packet carried by these 3462 messages in an effort to introduce these into the recipient's IP 3463 stack. A properly implemented gateway or relay will ignore any such 3464 messages - and may further choose to ignore Membership Query messages 3465 that do not contain a IGMP/MLD general queries or Membership Update 3466 messages that do not contain IGMP/MLD membership reports. 3468 Properly implemented gateways and relays will also filter 3469 encapsulated IP packets that appear corrupted or truncated by 3470 verifying packet length and checksums. 3472 7. IANA Considerations 3474 7.1. IPv4 and IPv6 Anycast Prefix Allocation 3476 The following unicast prefixes have been assigned to provide anycast 3477 routing of relay discovery messages to public AMT Relays as as 3478 described in Section 4.1.4. 3480 7.1.1. IPv4 3482 IANA has assigned 154.7.0/24 for IPv4 relays. 3484 7.1.2. IPv6 3486 IANA has assigned 2001:0003::/32 for IPv6 relays. 3488 7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses 3490 IANA has assigned 154.7.1/24 as a prefix for IGMP source addresses. 3492 7.3. UDP Port Number 3494 IANA has assigned UDP port number 2268 for AMT. 3496 8. Contributors 3498 The following people provided significant contributions to the design 3499 of the protocol and earlier versions of this specification: 3501 Thomas Morin 3502 France Telecom - Orange 3503 2, avenue Pierre Marzin 3504 Lannion 22300 3505 France 3506 Email: thomas.morin@orange.com 3508 Dirk Ooms 3509 OneSparrow 3510 Belegstraat 13; 2018 Antwerp; 3511 Belgium 3512 EMail: dirk@onesparrow.com 3514 Tom Pusateri 3515 !j 3516 2109 Mountain High Rd. 3517 Wake Forest, NC 27587 3518 USA 3519 Email: pusateri@bangj.com 3521 Dave Thaler 3522 Microsoft Corporation 3523 One Microsoft Way 3524 Redmond, WA 98052-6399 3525 USA 3526 Email: dthaler@microsoft.com 3528 9. Acknowledgments 3530 The authors would like to thank the following individuals for their 3531 suggestions, comments, and corrections: 3533 Amit Aggarwal 3534 Mark Altom 3535 Toerless Eckert 3536 Marshall Eubanks 3537 Gorry Fairhurst 3538 Dino Farinacci 3539 Lenny Giuliano 3540 Andy Huang 3541 Tom Imburgia 3542 Patricia McCrink 3543 Han Nguyen 3544 Doug Nortz 3545 Pekka Savola 3546 Robert Sayko 3547 Greg Shepherd 3548 Steve Simlo 3549 Mohit Talwar 3550 Lorenzo Vicisano 3551 Kurt Windisch 3552 John Zwiebel 3554 The anycast discovery mechanism described in this document is based 3555 on similar work done by the NGTrans WG for obtaining automatic IPv6 3556 connectivity without explicit tunnels ("6to4"). Tony Ballardie 3557 provided helpful discussion that inspired this document. 3559 Juniper Networks was instrumental in funding several versions of this 3560 draft as well as an open source implementation. 3562 10. References 3564 10.1. Normative References 3566 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3567 RFC 792, September 1981. 3569 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 3570 Thyagarajan, "Internet Group Management Protocol, Version 3571 3", RFC 3376, October 2002. 3573 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 3574 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 3576 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3577 Architecture", RFC 4291, February 2006. 3579 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 3580 IP", RFC 4607, August 2006. 3582 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 3583 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 3584 RFC 4787, January 2007. 3586 10.2. Informative References 3588 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 3589 1981. 3591 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3592 RFC 792, September 1981. 3594 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 3595 RFC 1112, August 1989. 3597 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 3598 November 1990. 3600 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 3601 April 1992. 3603 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 3604 Anycasting Service", RFC 1546, November 1993. 3606 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 3607 for IP version 6", RFC 1981, August 1996. 3609 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3610 Requirement Levels", BCP 14, RFC 2119, March 1997. 3612 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 3613 2", RFC 2236, November 1997. 3615 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3616 (IPv6) Specification", RFC 2460, December 1998. 3618 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 3619 Translator (NAT) Terminology and Considerations", RFC 3620 2663, August 1999. 3622 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 3623 Listener Discovery (MLD) for IPv6", RFC 2710, October 3624 1999. 3626 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 3627 Text on Security Considerations", BCP 72, RFC 3552, July 3628 2003. 3630 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 3631 Protocol 4 (BGP-4)", RFC 4271, January 2006. 3633 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 3634 Message Protocol (ICMPv6) for the Internet Protocol 3635 Version 6 (IPv6) Specification", RFC 4443, March 2006. 3637 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 3638 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 3639 Protocol Specification (Revised)", RFC 4601, August 2006. 3641 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 3642 Services", BCP 126, RFC 4786, December 2006. 3644 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 3645 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 3647 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 3648 for the Use of IPv6 UDP Datagrams with Zero Checksums", 3649 RFC 6936, April 2013. 3651 Appendix A. Implementation Notes 3653 A.1. Response MAC Generation and Keying 3655 This specification does not require relays to use any particular 3656 method to compute the Response MAC field value - only that it contain 3657 a hash of the source IP address, source UDP port, request nonce, and 3658 a private secret known only to the relay. This allows the relay 3659 implementor a significant amount of leeway in the computation and 3660 structure of the value stored in the Response MAC field. 3662 Section Section 5.3.6 states that a relay should periodically compute 3663 a new private secret (or hash-key) for MAC generation. To prevent 3664 the relay from rejecting Membership Update messages that contain 3665 Response MAC values computed from an old secret, the relay is 3666 required to retain the previous secret so that it can re-attempt 3667 authentication using the old secret, should authentication fail after 3668 recomputing the MAC using the new secret. However, this approach 3669 requires a relay to do at least two hash computations for every 3670 Membership Update message that carries an old or a invalid MAC. A 3671 better approach would be to include information within the message 3672 that the relay could use to choose a single secret for authentication 3673 rather relying on sequential authentication failures to test all 3674 possible secrets. 3676 The solution proposed here is to compute and exchange an 3677 "authentication cookie" rather than a simple hash value in the 3678 Response MAC field. The authentication cookie would combine a 3679 timestamp with a hash value. The timestamp is used to calculate the 3680 age of the cookie, allowing the relay to reject a message if the 3681 cookie's age is greater than some maximum allowable value. If the 3682 cookie has not expired, the relay uses the timestamp to lookup the 3683 secret that was in use at that time and then compute and compare the 3684 hash portion of the cookie to authenticate the message source. 3686 A second purpose served by including the timestamp in the MAC field 3687 is that it allows the relay to contribute an unpredictable value to 3688 the authentication hash. This contribution provides a defense 3689 against attempts to use a hash reversal algorithm to determine the 3690 relay's private secret as the hash result will change over time even 3691 if the nonce carried by the Request message does not. 3693 0 1 2 3 3694 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 3695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3696 | V=0 |4 or 5| Reserved | | Response MAC | 3697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 3698 | | 3699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3700 | Request Nonce | 3701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3702 : : 3704 Figure 19: The Opaque Response MAC Field 3706 A relay may use the opaque Response MAC field to store a cookie as 3707 follows: 3709 0 1 2 3 3710 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 3711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3712 | V=0 |4 or 5| Reserved | | Timestamp | 3713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3714 | MD5(Secret,Timestamp,IP_ADDR,IP_PORT,Request-Nonce) | 3715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3716 | Request Nonce | 3717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3718 : : 3720 Figure 20: Using The Response MAC Field To Carry An Authentication 3721 Cookie 3723 The timestamp is an unsigned integer measured relative to the start 3724 time of relay. The age of the MAC is computed by subtracting the MAC 3725 timestamp from the current system timestamp. The operands must be 3726 unsigned 16-bit integers and the subtraction must use unsigned 3727 arithmetic to allow for timestamp wrap-around. The timestamp 3728 resolution must provide range sufficient to handle the maximum 3729 allowable age for a MAC, e.g., a resolution of 1 second allows a 3730 maximum age of 18 hours. The timestamp should start at a random 3731 value by adding a random offset, computed at startup, to the current 3732 system time. 3734 +-------------------------+--------------/ /-----------------+ 3735 -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] | 3736 | +-------------------------+--------------/ /-----------------+ 3737 |___________________________________________________________________ 3738 | 3739 +-------------------------+--------------/ /-----------------+ | 3740 -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |-- 3742 | +-------------------------+--------------/ /-----------------+ 3743 |___________________________________________________________________ 3744 | 3745 +-------------------------+--------------/ /-----------------+ | 3746 -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |-- 3747 | +-------------------------+--------------/ /-----------------+ 3748 | 3749 |__ Current 3750 Secret 3752 Figure 21: Private Secret Queue 3754 The timestamp is not only used to compute the age of the MAC, but is 3755 also used to lookup the private secret used to generate the MAC. 3756 Each time a new private secret is computed, the value and the time at 3757 which the value was computed is pushed into a fixed-length queue of 3758 recent values (typically only 2-deep). The relay uses the timestamp 3759 contained in the MAC field to lookup the appropriate secret. The 3760 relay iterates over the list of secrets, starting with the newest 3761 entry, until it finds the first secret with a timestamp that is older 3762 than that contained in the MAC field. The relay then uses that 3763 secret to compute the MAC that will be compared with that carried by 3764 the message. 3766 Author's Address 3768 Gregory Bumgardner 3770 Phone: +1 541 343 6790 3771 Email: gbumgard@gmail.com