idnits 2.17.1 draft-ietf-mboned-auto-multicast-18.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 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 (December 1, 2014) is 3405 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 1013 -- Looks like a reference, but probably isn't: '2' on line 1015 -- Looks like a reference, but probably isn't: '3' on line 1018 -- Looks like a reference, but probably isn't: '4' on line 1032 -- Looks like a reference, but probably isn't: '5' on line 1034 -- Looks like a reference, but probably isn't: '6' on line 1037 -- Looks like a reference, but probably isn't: '7' on line 1041 == Missing Reference: 'TBD' is mentioned on line 3492, 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 (~~), 4 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 December 1, 2014 5 Expires: June 4, 2015 7 Automatic Multicast Tunneling 8 draft-ietf-mboned-auto-multicast-18 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 June 4, 2015. 38 Copyright Notice 40 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . 26 83 5. Protocol Description . . . . . . . . . . . . . . . . . . . . 31 84 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 31 85 5.1.1. Relay Discovery . . . . . . . . . . . . . . . . . . . 31 86 5.1.2. Relay Advertisement . . . . . . . . . . . . . . . . . 32 87 5.1.3. Request . . . . . . . . . . . . . . . . . . . . . . . 34 88 5.1.4. Membership Query . . . . . . . . . . . . . . . . . . 36 89 5.1.5. Membership Update . . . . . . . . . . . . . . . . . . 39 90 5.1.6. Multicast Data . . . . . . . . . . . . . . . . . . . 42 91 5.1.7. Teardown . . . . . . . . . . . . . . . . . . . . . . 43 92 5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 46 93 5.2.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 46 94 5.2.2. Pseudo-Interface Configuration . . . . . . . . . . . 47 95 5.2.3. Gateway Service . . . . . . . . . . . . . . . . . . . 49 96 5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 61 97 5.3.1. IP/IGMP/MLD Protocol Requirements . . . . . . . . . . 61 98 5.3.2. Startup . . . . . . . . . . . . . . . . . . . . . . . 62 99 5.3.3. Running . . . . . . . . . . . . . . . . . . . . . . . 62 100 5.3.4. Shutdown . . . . . . . . . . . . . . . . . . . . . . 73 101 5.3.5. Response MAC Generation . . . . . . . . . . . . . . . 73 102 5.3.6. Private Secret Generation . . . . . . . . . . . . . . 74 103 6. Security Considerations . . . . . . . . . . . . . . . . . . . 74 104 6.1. Relays . . . . . . . . . . . . . . . . . . . . . . . . . 75 105 6.2. Gateways . . . . . . . . . . . . . . . . . . . . . . . . 76 106 6.3. Encapsulated IP Packets . . . . . . . . . . . . . . . . . 76 107 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 108 7.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 77 109 7.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . 77 110 7.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . 77 111 7.2. UDP Port Number . . . . . . . . . . . . . . . . . . . . . 78 112 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 78 113 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 79 114 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 80 115 10.1. Normative References . . . . . . . . . . . . . . . . . . 80 116 10.2. Informative References . . . . . . . . . . . . . . . . . 81 117 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 82 119 1. Introduction 121 The advantages and benefits provided by multicast technologies are 122 well known. There are a number of application areas that are ideal 123 candidates for the use of multicast, including media broadcasting, 124 video conferencing, collaboration, real-time data feeds, data 125 replication, and software updates. Unfortunately, many of these 126 applications lack multicast connectivity to networks that carry 127 traffic generated by multicast sources. The reasons for the lack of 128 connectivity vary, but are primarily the result of service provider 129 policies and network limitations. 131 Automatic Multicast Tunneling (AMT) is a protocol that uses UDP-based 132 encapsulation to overcome the aforementioned lack of multicast 133 connectivity. AMT enables sites, hosts or applications that do not 134 have native multicast access to a network with multicast connectivity 135 to a source, to request and receive SSM [RFC4607] and ASM [RFC1112] 136 traffic from a network that does provide multicast connectivity to 137 that source. 139 2. Applicability 141 This document describes a protocol that may be used to deliver 142 multicast traffic from a multicast enabled network to sites that lack 143 multicast connectivity to the source network. This document does not 144 describe any methods for sourcing multicast traffic from isolated 145 sites as this topic is out of scope. 147 AMT is not intended to be used as a substitute for native multicast, 148 especially in conditions or environments requiring high traffic flow. 149 AMT uses unicast replication to reach multiple receivers and the 150 bandwidth cost for this replication will be higher than that required 151 if the receivers were reachable via native multicast. 153 AMT is designed to be deployed at the border of networks possessing 154 native multicast capabilities where access and provisioning can be 155 managed by the AMT service provider. 157 3. Terminology 159 3.1. Requirements Notation 161 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 162 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 163 document are to be interpreted as described in [RFC2119]. 165 3.2. Definitions 167 This document adopts the following definitions for use in describing 168 the protocol: 170 Downstream: 171 A downstream interface or connection that faces away from the 172 multicast distribution root or towards multicast receivers. 174 Upstream: 175 An upstream interface or connection that faces a multicast 176 distribution root or source. 178 Non-Broadcast Multi-Access (NMBA): 179 A non-broadcast multiple-access (NBMA) network or interface is one 180 to which multiple network nodes (hosts or routers) are attached, 181 but where packets are transmitted directly from one node to 182 another node over a virtual circuit or physical link. NBMA 183 networks do not support multicast or broadcast traffic - a node 184 that sources multicast traffic must replicate the multicast 185 packets for separate transmission to each node that has requested 186 the multicast traffic. 188 Multicast Receiver: 189 An entity that requests and receives multicast traffic. A 190 receiver may be a router, host, application, or application 191 component. The method by which a receiver transmits group 192 membership requests and receives multicast traffic varies 193 according to receiver type. 195 Group Membership Database: 196 A group membership database describes the current multicast 197 subscription state for an interface or system. See Section 3 in 198 [RFC3376] for a detailed definition. 200 Reception State: 201 The multicast subscription state of a pseudo, virtual or physical 202 network interface. Often synonymous with group membership 203 database. 205 Subscription: 206 A group or state entry in a group membership database or reception 207 state table. The presence of a subscription entry indicates 208 membership in an IP multicast group. 210 Group Membership Protocol: 211 The term "group membership protocol" is used as a generic 212 reference to the Internet Group Management (IGMP) ([RFC1112], 213 [RFC2236], [RFC3376]) or Multicast Listener Discovery ([RFC2710], 214 [RFC3810]) protocols. 216 Multicast Protocol: 217 The term "multicast protocol" is used as a generic reference to 218 multicast routing protocols used to join or leave multicast 219 distribution trees such as PIM-SM [RFC4601]. 221 Network Address Translation (NAT): 222 Network Address Translation is the process of modifying the source 223 IP address and port numbers carried by an IP packet while 224 transiting a network node (See [RFC2663]). Intervening NAT 225 devices may change the source address and port carried by messages 226 sent from an AMT gateway to an AMT relay, possibly producing 227 changes in protocol state and behavior. 229 Anycast: 230 A network addressing and routing method in which packets from a 231 single sender are routed to the topologically nearest node in a 232 group of potential receivers all identified by the same 233 destination address. See [RFC4786]. 235 3.3. Abbreviations 237 AMT - Automatic Multicast Tunneling Protocol. 239 ASM - Any-Source Multicast. 241 DoS - Denial-of-Service (attack) and DDoS for distributed-DoS. 243 IGMP - Internet Group Management Protocol (v1, v2 and v3). 245 IP - Internet Protocol (v4 and v6). 247 MAC - Message Authentication Code (or Cookie). 249 MLD - Multicast Listener Discovery protocol (v1 and v2). 251 NAT - Network Address Translation (or translation node). 253 NBMA - Non-Broadcast Multi-Access (network, interface or mode) 255 SSM - Source-Specific Multicast. 257 PIM - Protocol Independent Multicast. 259 4. Protocol Overview 261 This section provides an informative description of the protocol. A 262 normative description of the protocol and implementation requirements 263 may be found in section Section 5. 265 4.1. General Architecture 267 Isolated Site | Unicast Network | Native Multicast 268 | (Internet) | 269 | | 270 | | 271 | Group Membership | 272 +-------+ =========================> +-------+ Multicast +------+ 273 |Gateway| | | | Relay |<----//----|Source| 274 +-------+ <========================= +-------+ +------+ 275 | Multicast Data | 276 | | 277 | | 279 Figure 1: Basic AMT Architecture 281 The AMT protocol employs a client-server model in which a "gateway" 282 sends requests to receive specific multicast traffic to a "relay" 283 which responds by delivering the requested multicast traffic back to 284 the gateway. 286 Gateways are generally deployed within networks that lack multicast 287 support or lack connectivity to a multicast-enabled network 288 containing multicast sources of interest. 290 Relays are deployed within multicast-enabled networks that contain, 291 or have connectivity to, multicast sources. 293 4.1.1. Relationship to IGMP and MLD Protocols 295 AMT relies on the Internet Group Management (IGMP) [RFC3376] and 296 Multicast Listener Discovery (MLD) [RFC3810] protocols to provide the 297 functionality required to manage, communicate, and act on changes in 298 multicast group membership. A gateway or relay implementation does 299 not necessarily require a fully-functional, conforming implementation 300 of IGMP or MLD to adhere to this specification, but the protocol 301 description that appears in this document assumes that this is the 302 case. The minimum functional and behavioral requirements for the 303 IGMP and MLD protocols are described in Section 5.2.1 and 304 Section 5.3.1. 306 Gateway Relay 308 General _____ _____ 309 ___________ Query | | | | Query ___________ 310 | |<------| | | |<------| | 311 | Host Mode | | AMT | | AMT | |Router Mode| 312 | IGMP/MLD | | | UDP | | | IGMP/MLD | 313 |___________|------>| |<----->| |------>|___________| 314 Report | | | | Report 315 Leave/Done | | | | Leave/Done 316 | | | | 317 IP Multicast <------| | | |<------ IP Multicast 318 |_____| |_____| 320 Figure 2: Multicast Reception State Managed By IGMP/MLD 322 A gateway runs the host portion of the IGMP and MLD protocols to 323 generate group membership updates that are sent via AMT messages to a 324 relay. A relay runs the router portion of the IGMP and MLD protocols 325 to process the group membership updates to produce the required 326 changes in multicast forwarding state. A relay uses AMT messages to 327 send incoming multicast IP datagrams to gateways according to their 328 current group membership state. 330 The primary function of AMT is to provide the handshaking, 331 encapsulation and decapsulation required to transport the IGMP and 332 MLD messages and multicast IP datagrams between the gateways and 333 relays. The IGMP and MLD messages that are exchanged between 334 gateways and relays are encapsulated as complete IP datagrams within 335 AMT control messages. Multicast IP datagrams are replicated and 336 encapsulated in AMT data messages. All AMT messages are sent via 337 unicast UDP/IP. 339 4.1.2. Gateways 341 The downstream side of a gateway services one or more receivers - the 342 gateway accepts group membership requests from receivers and forwards 343 requested multicast traffic back to those receivers. The gateway 344 functionality may be directly implemented in the host requesting the 345 multicast service or within an application running on a host. 347 The upstream side of a gateway connects to relays. A gateway sends 348 encapsulated IGMP and MLD messages to a relay to indicate an interest 349 in receiving specific multicast traffic. 351 4.1.2.1. Architecture 353 Each gateway possesses a logical pseudo-interface: 355 join/leave ---+ +----------+ 356 | | | 357 V IGMPv3/MLDv2 | | 358 +---------+ General Query| | AMT 359 |IGMP/MLD |<-------------| AMT | Messages +------+ 360 |Host Mode| | Gateway |<-------->|UDP/IP| 361 |Protocol |------------->|Pseudo I/F| +------+ 362 +---------+ IGMP/MLD | | ^ 363 Report | | | 364 Leave/Done | | V 365 IP Multicast <---------------------| | +---+ 366 +----------+ |I/F| 367 +---+ 369 Figure 3: AMT Gateway Pseudo-Interface 371 The pseudo-interface is conceptually a network interface on which the 372 gateway executes the host portion of the IPv4/IGMP (v2 or v3) and 373 IPv6/MLD (v1 or v2) protocols. The multicast reception state of the 374 pseudo-interface is manipulated using the IGMP or MLD service 375 interface. The IGMP and MLD host protocols produce IP datagrams 376 containing group membership messages that the gateway will send to 377 the relay. The IGMP and MLD protocols also supply the retransmission 378 and timing behavior required for protocol robustness. 380 All AMT encapsulation, decapsulation and relay interaction is assumed 381 to occur within the pseudo-interface. 383 A gateway host or application may create separate interfaces for 384 IPv4/IGMP and IPv6/MLD. A gateway host or application may also 385 require additional pseudo-interfaces for each source or domain- 386 specific relay address. 388 Within this document, the term "gateway" may be used as a generic 389 reference to an entity executing the gateway protocol, a gateway 390 pseudo-interface, or a gateway device that has one or more interfaces 391 connected to a unicast inter-network and one or more AMT gateway 392 pseudo-interfaces. 394 The following diagram illustrates how an existing host IP stack 395 implementation might be used to provide AMT gateway functionality to 396 a multicast application: 398 +-----------------------------------------------------+ 399 |Host | 400 | ______________________________________ | 401 | | | | 402 | | ___________________________ | | 403 | | | | | | 404 | | | v | | 405 | | | +-----------+ +--------------+ | 406 | | | |Application| | AMT Daemon | | 407 | | | +-----------+ +--------------+ | 408 | | | join/leave | ^ data ^ AMT | 409 | | | | | | | 410 | | | +----|---|-------------|-+ | 411 | | | | __| |_________ | | | 412 | | | | | | | | | 413 | | | | | Sockets | | | | 414 | | | +-|------+-------+-|---|-+ | 415 | | | | | IGMP | TCP | |UDP| | | 416 | | | +-|------+-------+-|---|-+ | 417 | | | | | ^ IP | | | | 418 | | | | | | ____________| | | | 419 | | | | | | | | | | 420 | | | +-|-|-|----------------|-+ | 421 | | | | | | | | 422 | | | IP(IGMP)| | |IP(UDP(data)) |IP(UDP(AMT)) | 423 | | | v | | v | 424 | | | +-----------+ +---+ | 425 | | | |Virtual I/F| |I/F| | 426 | | | +-----------+ +---+ | 427 | | | | ^ ^ | 428 | | | IP(IGMP)| |IP(UDP(data)) | | 429 | | |_________| |IP(IGMP) | | 430 | | | | | 431 | |_________________| | | 432 | | | 433 +--------------------------------------|--------------+ 434 v 435 AMT Relay 437 Figure 4: Virtual Interface Implementation Example 439 In this example, the host IP stack uses a virtual network interface 440 to interact with a gateway pseudo-interface implementation. 442 4.1.2.2. Use-Cases 444 Use-cases for gateway functionality include: 446 IGMP/MLD Proxy 447 An IGMP/MLD proxy that runs AMT on an upstream interface and 448 router-mode IGMP/MLD on downstream interfaces to provide host 449 access to multicast traffic via the IGMP and MLD protocols. 451 Virtual Network Interface 452 A virtual network interface or pseudo network device driver that 453 runs AMT on a physical network interface to provide socket layer 454 access to multicast traffic via the IGMP/MLD service interface 455 provided by the host IP stack. 457 Application 458 An application or application component that implements and 459 executes IGMP/MLD and AMT internally to gain access to multicast 460 traffic. 462 4.1.3. Relays 464 The downstream side of a relay services gateways - the relay accepts 465 encapsulated IGMP and MLD group membership messages from gateways and 466 encapsulates and forwards the requested multicast traffic back to 467 those gateways. 469 The upstream side of a relay communicates with a native multicast 470 infrastructure - the relay sends join and prune/leave requests 471 towards multicast sources and accepts requested multicast traffic 472 from those sources. 474 4.1.3.1. Architecture 475 Each relay possesses a logical pseudo-interface: 477 +------------------------------+ 478 +--------+ | Multicast Control Plane | 479 | |IGMP/MLD| | 480 | | Query* | +------------+ +----------+ | 481 | |<---//----|IGMPv3/MLDv2| |Multicast | | 482 AMT | | | |Router Mode |->|Routing |<-> 483 +------+ Messages | AMT |----//--->|Protocol | |Protocol | | 484 |UDP/IP|<-------->| Relay |IGMP/MLD| +------------+ +----------+ | 485 +------+ | Pseudo | Report | | | | 486 ^ | I/F | Leave/ +------|---------------|-------+ 487 | | | Done | | 488 | | | v | 489 V | | IP +-----------+ | 490 +---+ | | Multicast |Multicast |<------+ 491 |I/F| | |<---//-----|Forwarding | 492 +---+ +--------+ |Plane |<--- IP Multicast 493 +-----------+ 495 * Queries, if generated, are consumed by the pseudo-interface. 497 Figure 5: AMT Relay Pseudo-Interface (Router-Based) 499 The pseudo-interface is conceptually a network interface on which the 500 relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2 501 protocols. Relays do not send unsolicited IGMPv3/MLDv2 query 502 messages to gateways so relays must consume or discard any local 503 queries normally generated by IGMPv3 or MLDv2. Note that the 504 protocol mandates the use of IGMPv3 and MLDv2 for query messages. 505 The AMT protocol is primarily intended for use in SSM applications 506 and relies on several values provided by IGMPv3/MLDv2 to control 507 gateway behavior. 509 A relay maintains group membership state for each gateway connected 510 through the pseudo-interface as well as for the entire pseudo- 511 interface (if multiple gateways are managed via a single interface). 512 Multicast packets received on upstream interfaces on the relay are 513 routed to the pseudo-interface where they are replicated, 514 encapsulated and sent to interested gateways. Changes in the pseudo- 515 interface group membership state may trigger the transmission of 516 multicast protocol requests upstream towards a given source or 517 rendezvous point and cause changes in internal routing/forwarding 518 state. 520 The relay pseudo-interface is a architectural abstraction used to 521 describe AMT protocol operation. For the purposes of this document, 522 the pseudo-interface is most easily viewed as an interface to a 523 single gateway - encapsulation, decapsulation, and other AMT-specific 524 processing occurs "within" the pseudo-interface while forwarding and 525 replication occur outside of it. 527 An alternative view is to treat the pseudo-interface as a non- 528 broadcast multi-access (NBMA) network interface whose link layer is 529 the unicast-only network over which AMT messages are exchanged with 530 gateways. Individual gateways are conceptually treated as logical 531 NBMA links on the interface. In this architectural model, group 532 membership tracking, replication and forwarding functions occur in 533 the pseudo-interface. 535 This document does not specify any particular architectural solution 536 - a relay developer may choose to implement and distribute protocol 537 functionality as required to take advantage of existing relay 538 platform services and architecture. 540 Within this document, the term "relay" may be used as a generic 541 reference to an entity executing the relay protocol, a relay pseudo- 542 interface, or a relay device that has one or more network interfaces 543 with multicast connectivity to a native multicast infrastructure, 544 zero or more interfaces connected to a unicast inter-network, and one 545 or more relay pseudo-interfaces. 547 4.1.3.2. Use-Cases 549 Use-cases for relay functionality include: 551 Multicast Router 552 A multicast router that runs AMT on a downstream interface to 553 provide gateway access to multicast traffic. A "relay router" 554 uses a multicast routing protocol (e.g. PIM-SM RFC4601 [RFC4601]) 555 to construct a forwarding path for multicast traffic by sending 556 join and prune messages to neighboring routers to join or leave 557 multicast distribution trees for a given SSM source or ASM 558 rendezvous point. 560 IGMP/MLD Proxy Router 561 An IGMP/MLD proxy that runs AMT on a downstream interface and 562 host-mode IGMPv3/MLDv2 on a upstream interface. This "relay 563 proxy" sends group membership reports to a local, multicast- 564 enabled router to join and leave specific SSM or ASM groups. 566 4.1.4. Deployment 568 The AMT protocol calls for a relay deployment model that uses anycast 569 addressing [RFC1546][RFC4291] to pair gateways with relays. 571 Under this approach, one or more relays advertise a route for the 572 same IP address prefix. To find a relay with which to communicate, a 573 gateway sends a message to an anycast IP address within that prefix. 574 This message is routed to the topologically-nearest relay that has 575 advertised the prefix. The relay that receives the message responds 576 by sending its unicast address back to the gateway. The gateway uses 577 this address as the destination address for any messages it 578 subsequently sends to the relay. 580 The use of anycast addressing provides the following benefits: 582 o Relays may be deployed at multiple locations within a single 583 multicast-enabled network. Relays might be installed "near" 584 gateways to reduce bandwidth requirements, latency and limit the 585 number of gateways that might be serviced by a single relay. 587 o Relays may be added or removed at any time thereby allowing staged 588 deployment, scaling and hot-swapping - the relay discovery process 589 will always return the nearest operational relay. 591 o Relays may take themselves offline when they exhaust resources 592 required to service additional gateways. Existing gateway 593 connections may be preserved, but new gateway requests would be 594 routed to the next-nearest relay. 596 4.1.4.1. Public Versus Private 598 Ideally, the AMT protocol would provide a universal solution for 599 connecting receivers to multicast sources - that any gateway could be 600 used to access any globally advertised multicast source via publicly- 601 accessible, widely-deployed relays. Unfortunately, today's Internet 602 does not yet allow this, because many relays will lack native 603 multicast access to sources even though they may be globally 604 accessible via unicast. 606 In these cases, a provider may deploy relays within their own source 607 network to allow for multicast distribution within that network. 608 Gateways that use these relays must use a provider-specific relay 609 discovery mechanism or a private anycast address to obtain access to 610 these relays. 612 4.1.4.2. Congestion Considerations 614 AMT relies on UDP to provide best-effort delivery of multicast data 615 to gateways. Neither AMT or the UDP protocol provide the congestion 616 control mechanisms required to regulate the flow of data messages 617 passing through a network. While congestion remediation might be 618 provided by multicast receiver applications via multicast group 619 selection or upstream reporting mechanisms, there are no means by 620 which to ensure such mechanisms are employed. To limit the possible 621 congestion across a network or wider Internet, AMT service providers 622 are expected to deploy AMT relays near the provider's network border 623 and its interface with edge routers. The provider must limit relay 624 address advertisements to those edges to prevent distant gateways 625 from being able to access a relay and potentially generate flows that 626 consume or exceed the capacity of intervening links. 628 4.1.5. Discovery 630 To execute the gateway portion of the protocol, a gateway requires a 631 unicast IP address of an operational relay. This address may be 632 obtained using a number of methods - it may be statically assigned or 633 dynamically chosen via some form of relay discovery process. 635 As described in the previous section, the AMT protocol provides a 636 relay discovery method that relies on anycast addressing. Gateways 637 are not required to use AMT relay discovery, but all relay 638 implementations must support it. 640 The AMT protocol uses the following terminology when describing the 641 discovery process: 643 Relay Discovery Address Prefix: 644 The anycast address prefix used to route discovery messages to a 645 relay. 647 Relay Discovery Address: 648 The anycast destination address used when sending discovery 649 messages. 651 Relay Address: 652 The unicast IP address obtained as a result of the discovery 653 process. 655 4.1.5.1. Relay Discovery Address Selection 657 The selection of an anycast Relay Discovery Address may be source- 658 dependent, as a relay located via relay discovery must have multicast 659 connectivity to a desired source. 661 Similarly, the selection of a unicast Relay Address may be source- 662 dependent, as a relay contacted by a gateway to supply multicast 663 traffic must have native multicast connectivity to the traffic source 665 Methods that might be used to perform source-specific or group- 666 specific relay selection are highly implementation-dependent and are 667 not further addressed by this document. Possible approaches include 668 the use of static lookup tables, DNS-based queries, or a provision of 669 a service interface that accepts join requests on (S,G,relay- 670 discovery-address) or (S,G,relay-address) tuples. 672 4.1.5.2. IANA-Assigned Relay Discovery Address Prefix 674 IANA has assigned an address prefix for use in advertising and 675 discovering publicly accessible relays. 677 A relay discovery address is constructed from the address prefix by 678 setting the low-order octet of the prefix address to 1 (for both IPv4 679 and IPv6). 681 Public relays must advertise a route to the address prefix (e.g. via 682 BGP [RFC4271]) and configure an interface to respond to the relay 683 discovery address. 685 The IANA address assignments are discussed in Section 7. 687 4.2. General Operation 689 4.2.1. Message Sequences 691 The AMT protocol defines the following messages for control and 692 encapsulation. These messages are exchanged as UDP/IP datagrams, one 693 message per datagram. 695 Relay Discovery: 696 Sent by gateways to solicit a Relay Advertisement from any relay. 697 Used to find a relay with which to communicate. 699 Relay Advertisement: 700 Sent by relays as a response to a Relay Discovery message. Used 701 to deliver a relay address to a gateway. 703 Request: 704 Sent by gateways to solicit a Membership Query message from a 705 relay. 707 Membership Query: 708 Sent by relays as a response to a Request message. Used to 709 deliver an encapsulated IGMPv3 or MLDv2 query message to the 710 gateway. 712 Membership Update: 713 Sent by gateways to deliver an encapsulated IGMP or MLD 714 report/leave/done message to a relay. 716 Multicast Data: 717 Sent by relays to deliver an encapsulated IP multicast datagram or 718 datagram fragment to a gateway. 720 Teardown: 721 Sent by gateways to stop the delivery of Multicast Data messages 722 requested in an earlier Membership Update message. 724 The following sections describe how these messages are exchanged to 725 execute the protocol. 727 4.2.1.1. Relay Discovery Sequence 729 Gateway Relay 730 ------- ----- 731 : : 732 | | 733 [1] |Relay Discovery | 734 |------------------->| 735 | | 736 | Relay Advertisement| [2] 737 |<-------------------| 738 [3] | | 739 : : 741 Figure 6: AMT Relay Discovery Sequence 743 The following sequence describes how the Relay Discovery and Relay 744 Advertisement messages are used to find a relay with which to 745 communicate: 747 1. The gateway sends a Relay Discovery message containing a random 748 nonce to the Relay Discovery Address. If the Relay Discovery 749 Address is an anycast address, the message is routed to 750 topologically-nearest network node that advertises that address. 752 2. The node receiving the Relay Discovery message sends a Relay 753 Advertisement message back to the source of the Relay Discovery 754 message. The message carries a copy of the nonce contained in 755 the Relay Discovery message and the unicast IP address of a 756 relay. 758 3. When the gateway receives the Relay Advertisement message it 759 verifies that the nonce matches the one sent in the Relay 760 Discovery message, and if it does, uses the relay address carried 761 by the Relay Advertisement as the destination address for 762 subsequent AMT messages. 764 Note that the responder need not be a relay - the responder may 765 obtain a relay address by some other means and return the result in 766 the Relay Advertisement (i.e., the responder is a load-balancer or 767 broker). 769 4.2.1.2. Membership Update Sequence 771 There exists a significant difference between normal IGMP and MLD 772 behavior and that required by AMT. An IGMP/MLD router acting as a 773 querier normally transmits query messages on a network interface to 774 construct and refresh group membership state for the connected 775 network. These query messages are multicast to all IGMP/MLD enabled 776 hosts on the network. Each host responds by multicasting report 777 messages that describe their current multicast reception state. 779 However, AMT does not allow relays to send unsolicited query messages 780 to gateways, as the set of active gateways may be unknown to the 781 relay and potentially quite large. Instead, AMT requires each 782 gateway to periodically send a message to a relay to solicit a 783 general-query response. A gateway accomplishes this by sending a 784 Request message to a relay. The relay responds by sending Membership 785 Query message back to the gateway. The Membership Query message 786 carries an encapsulated general query that is processed by the IGMP 787 or MLD protocol implementation on the gateway to produce a 788 membership/listener report. Each time the gateway receives a 789 Membership Query message it starts a timer whose expiration will 790 trigger the start of a new Request->Membership Query message 791 exchange. This timer-driven sequence is used to mimic the 792 transmission of a periodic general query by an IGMP/MLD router. This 793 query cycle may continue indefinitely once started by sending the 794 initial Request message. 796 A membership update occurs when an IGMP or MLD report, leave or done 797 message is passed to the gateway pseudo-interface. These messages 798 may be produced as a result of the aforementioned general-query 799 processing or as a result of receiver interaction with the IGMP/MLD 800 service interface. Each report is encapsulated and sent to the relay 801 after the gateway has successfully established communication with the 802 relay via a Request and Membership Query message exchange. If a 803 report is passed to the pseudo-interface before the gateway has 804 received a Membership Query message from the relay, the gateway may 805 discard the report or queue the report for delivery after a 806 Membership Query is received. Subsequent IGMP/MLD report/leave/done 807 messages that are passed to the pseudo-interface are immediately 808 encapsulated and transmitted to the relay. 810 IGMP/MLD Pseudo-I/F Relay 811 -------- ---------- ----- 812 : : : 813 | | Request | 814 | 1|-------------------->| 815 | | Membership Query |2 816 Query | | Q(0,{}) | 817 Timer | Start 3|<--------------------| 818 (QT)<--------------------------| | 819 | Q(0,{}) | | 820 |<--------------------| | 821 4| R({}) | Membership Update | 822 |-------------------->|5 R({}) | 823 | |====================>|6a 824 Join(S,G) : : : 825 ()-------->|7 R({G:ALLOW({S})}) | Membership Update | 826 |-------------------->|8 R({G:ALLOW({S})}) | 827 | |====================>|9a Join(S,G) 828 | | |---------->() 829 : : : 830 | ------------|---------------------|------------ 831 | | | | | 832 | | | Multicast Data | IP(S,G) | 833 | | | IP(S,G) 10|<--------() | 834 | | IP(S,G) 11|<====================| | 835 | | ()<--------| | | 836 | | | | | 837 : ------------:---------------------:------------ 838 | Expired | | 839 (QT)-------------------------->|12 Request | 840 | 1|-------------------->| 841 | | Membership Query |2 842 | | Q(0,{}) | 843 | Start 3|<--------------------| 844 (QT)<--------------------------| | 845 | Q(0,{}) | | 846 |<--------------------| | 847 4| R({G:INCLUDE({S})}) | Membership Update | 848 |-------------------->|5 R({G:INCLUDE({S})})| 849 | |====================>|6b 850 Leave(S,G) : : : 851 ()-------->|7 R({G:BLOCK({S})}) | Membership Update | 852 |-------------------->|8 R({G:BLOCK({S})}) | 853 | |====================>|9b Prune(S,G) 854 | | |---------->() 855 : : : 857 Figure 7: Membership Update Sequence (IGMPv3/MLDv2 Example) 859 The following sequence describes how the Request, Membership Query, 860 and Membership Update messages are used to report current group 861 membership state or changes in group membership state: 863 1. A gateway sends a Request message to the relay that contains a 864 random nonce and a flag indicating whether the relay should 865 return an IGMPv3 or MLDv2 general query. 867 2. When the relay receives a Request message, it generates a 868 message authentication code (MAC), typically, by computing a 869 hash digest from message source IP address, source UDP port, 870 request nonce and a private secret. The relay then sends a 871 Membership Query message to the gateway that contains the 872 request nonce, the MAC, and an IGMPv3 or MLDv2 general query. 874 3. When the gateway receives a Membership Query message, it 875 verifies that the request nonce matches the one sent in the last 876 Request, and if it does, the gateway saves the request nonce and 877 MAC for use in sending subsequent Membership Update messages. 878 The gateway starts a timer whose expiration will trigger the 879 transmission of a new Request message and extracts the 880 encapsulated general query message for processing by the IGMP or 881 MLD protocol. The query timer duration is specified by the 882 relay in the Querier's Query Interval Code (QQIC) field in the 883 IGMPv3 or MLDv2 general query. The QQIC field is defined in 884 Section 4.1.7 of [RFC3376] and Section 5.1.9 of [RFC3810]). 886 4. The gateway's IGMP or MLD protocol implementation processes the 887 general query to produce a current-state report. 889 5. When an IGMP or MLD report is passed to the pseudo-interface, 890 the gateway encapsulates the report in a Membership Update 891 message and sends it to the relay. The request nonce and MAC 892 fields in the Membership Update are assigned the values from the 893 last Membership Query message received for the corresponding 894 group membership protocol (IGMPv3 or MLDv2). 896 6. When the relay receives a Membership Update message, it computes 897 a MAC from the message source IP address, source UDP port, 898 request nonce and a private secret. The relay accepts the 899 Membership Update message if the received MAC matches the 900 computed MAC, otherwise the message is ignored. If the message 901 is accepted, the relay may proceed to allocate, refresh, or 902 modify tunnel state. This includes making any group membership, 903 routing and forwarding state changes and issuing any upstream 904 protocol requests required to satisfy the state change. The 905 diagram illustrates two scenarios: 907 A. The gateway has not previously reported any group 908 subscriptions and the report does not contain any group 909 subscriptions, so the relay takes no action. 911 B. The gateway has previously reported a group subscription so 912 the current-state report lists all current subscriptions. 913 The relay responds by refreshing tunnel or group state and 914 resetting any related timers. 916 7. A receiver indicates to the gateway that it wishes to join 917 (allow) or leave (block) specific multicast traffic. This 918 request is typically made using some form IGMP/MLD service 919 interface (as described in Section 2 of [RFC3376] or Section 3 920 of [RFC3810]). The IGMP/MLD protocol responds by generating an 921 IGMP or MLD state-change message. 923 8. When an IGMP or MLD report/leave/done message is passed to the 924 pseudo-interface, the gateway encapsulates the message in a 925 Membership Update message and sends it to the relay. The 926 request nonce and MAC fields in the Membership Update are 927 assigned the values from the last Membership Query message 928 received for the corresponding group membership protocol (IGMP 929 or MLD). 931 The IGMP and MLD protocols may generate multiple messages to 932 provide robustness against packet loss - each of these must be 933 encapsulated in a new Membership Update message and sent to the 934 relay. The Querier Robustness Variable (QRV) field in the last 935 IGMP/MLD query delivered to the IGMP/MLD protocol is typically 936 used to specify the number of repetitions (i.e., the host adopts 937 the QRV value as its own Robustness Variable value). The QRV 938 field is defined in Section 4.1.6 in [RFC3376] and Section 5.1.8 939 in [RFC3810]. 941 9. When the relay receives a Membership Update message, it again 942 computes a MAC from the message source IP address, source UDP 943 port, request nonce and a private secret. The relay accepts the 944 Membership Update message if the received MAC matches the 945 computed MAC, otherwise the message is ignored. If the message 946 is accepted, the relay processes the encapsulated IGMP/MLD and 947 allocates, modifies or deletes tunnel state accordingly. This 948 includes making any group membership, routing and forwarding 949 state changes and issuing any upstream protocol requests 950 required to satisfy the state change. The diagram illustrates 951 two scenarios: 953 A. The gateway wishes to add a group subscription. 955 B. The gateway wishes to delete a previously reported group 956 subscription. 958 10. Multicast datagrams transmitted from a source travel through the 959 native multicast infrastructure to the relay. When the relay 960 receives a multicast IP datagram that carries a source and 961 destination address for which a gateway has expressed an 962 interest in receiving (via the Membership Update message), it 963 encapsulates the datagram into a Multicast Data message and 964 sends it to the gateway using the source IP address and UDP port 965 carried by the Membership Update message as the destination 966 address. 968 11. When the gateway receives a Multicast Data message, it extracts 969 the multicast packet from the message and passes it on to the 970 appropriate receivers. 972 12. When the query timer expires the gateway sends a new Request 973 message to the relay to start a new membership update cycle. 975 The MAC-based source-authentication mechanism described above 976 provides a simple defense against malicious attempts to exhaust relay 977 resources via source-address spoofing. Flooding a relay with spoofed 978 Request or Membership Update messages may consume computational 979 resources and network bandwidth, but will not result in the 980 allocation of state because the Request message is stateless and 981 spoofed Membership Update messages will fail source-authentication 982 and be rejected by the relay. 984 A relay will only allocate new tunnel state if the IGMP/MLD report 985 carried by the Membership Update message creates one or more group 986 subscriptions. 988 A relay deallocates tunnel state after one of the following events; 989 the gateway sends a Membership Update message containing a report 990 that results in the deletion of all remaining group subscriptions, 991 the IGMP/MLD state expires (due to lack of refresh by the gateway), 992 or the relay receives a valid Teardown message from the gateway (See 993 Section 4.2.1.3). 995 A gateway that accepts or reports group subscriptions for both IPv4 996 and IPv6 addresses will send separate Request and Membership Update 997 messages for each protocol (IPv4/IGMP and IPv6/MLD). 999 4.2.1.3. Teardown Sequence 1001 A gateway sends a Teardown message to a relay to request that it stop 1002 delivering Multicast Data messages to a tunnel endpoint created by an 1003 earlier Membership Update message. This message is intended to be 1004 used following a gateway address change (See Section 4.2.2.1) to stop 1005 the transmission of undeliverable or duplicate multicast data 1006 messages. Gateway support for the Teardown message is optional - 1007 gateways are not required to send them and may instead rely on group 1008 membership to expire on the relay. 1010 Gateway Relay 1011 ------- ----- 1012 : Request : 1013 [1] | N | 1014 |---------------------->| 1015 | Membership Query | [2] 1016 | N,MAC,gADDR,gPORT | 1017 |<======================| 1018 [3] | Membership Update | 1019 | ({G:INCLUDE({S})}) | 1020 |======================>| 1021 | | 1022 ---------------------:-----------------------:--------------------- 1023 | | | | 1024 | | *Multicast Data | *IP Packet(S,G) | 1025 | | gADDR,gPORT |<-----------------() | 1026 | *IP Packet(S,G) |<======================| | 1027 | ()<-----------------| | | 1028 | | | | 1029 ---------------------:-----------------------:--------------------- 1030 ~ ~ 1031 ~ Request ~ 1032 [4] | N' | 1033 |---------------------->| 1034 | Membership Query | [5] 1035 | N',MAC',gADDR',gPORT' | 1036 |<======================| 1037 [6] | | 1038 | Teardown | 1039 | N,MAC,gADDR,gPORT | 1040 |---------------------->| 1041 | | [7] 1042 | Membership Update | 1043 | ({G:INCLUDE({S})}) | 1044 |======================>| 1045 | | 1046 ---------------------:-----------------------:--------------------- 1047 | | | | 1048 | | *Multicast Data | *IP Packet(S,G) | 1049 | | gADDR',gPORT' |<-----------------() | 1050 | *IP Packet (S,G) |<======================| | 1051 | ()<-----------------| | | 1052 | | | | 1053 ---------------------:-----------------------:--------------------- 1054 | | 1055 : : 1057 Figure 8: Teardown Message Sequence (IGMPv3/MLDv2 Example) 1059 The following sequence describes how the Membership Query and 1060 Teardown message are used to detect an address change and stop the 1061 delivery of Multicast Data messages to an address: 1063 1. A gateway sends a Request message containing a random nonce to 1064 the relay. 1066 2. The relay sends a Membership Query message to the gateway that 1067 contains the source IP address (gADDR) and source UDP port 1068 (gPORT) values from the Request message. These values will be 1069 used to identify the tunnel should one be created by a subsequent 1070 Membership Update message. 1072 3. When the gateway receives a Membership Query message that carries 1073 the gateway address fields, it compares the gateway IP address 1074 and port number values with those received in the previous 1075 Membership Query (if any). If these values do not match, this 1076 indicates that the Request message arrived at the relay carrying 1077 a different source address than the one sent previously. At this 1078 point in the sequence, no change in source address or port has 1079 occurred. 1081 4. The gateway sends a new Request message to the relay. However, 1082 this Request message arrives at the relay carrying a different 1083 source address than that of the previous Request due to some 1084 change in network interface, address assignment, network topology 1085 or NAT mapping. 1087 5. The relay again responds by sending a Membership Query message to 1088 the gateway that contains the new source IP address (gADDR') and 1089 source UDP port (gPORT') values from the Request message. 1091 6. When the gateway receives the Membership Query message, it 1092 compares the gateway address and port number values against those 1093 returned in the previous Membership Query message. 1095 7. If the reported address or port has changed, the gateway sends a 1096 Teardown message to the relay that contains the request nonce, 1097 MAC, gateway IP address and gateway port number returned in the 1098 earlier Membership Query message. The gateway may send the 1099 Teardown message multiple times where the number of repetitions 1100 is governed by the Querier Robustness Variable (QRV) value 1101 contained in the IGMPv3/MLDv2 general query carried by the 1102 original Membership Query (See Section 4.1.6 in [RFC3376] and 1103 Section 5.1.8 in [RFC3810]). The gateway continues to process 1104 the new Membership Query message as usual. 1106 8. When the relay receives a Teardown message, it computes a MAC 1107 from the message source IP address, source UDP port, request 1108 nonce and a private secret. The relay accepts the Teardown 1109 message if the received MAC matches the computed MAC, otherwise 1110 the message is ignored. If the message is accepted, the relay 1111 makes any group membership, routing and forwarding state changes 1112 required to stop the transmission of Multicast Data messages to 1113 that address. 1115 4.2.1.4. Timeout and Retransmission 1117 The AMT protocol does not establish any requirements regarding what 1118 actions a gateway should take if it fails to receive a response from 1119 a relay. A gateway implementation may wait for an indefinite period 1120 of time to receive a response, may set a time limit on how long to 1121 wait for a response, may retransmit messages should the time limit be 1122 reached, may limit the number of retransmissions, or may simply 1123 report an error. 1125 For example, a gateway may retransmit a Request message if it fails 1126 to receive a Membership Query or expected Multicast Data messages 1127 within some time period. If the gateway fails to receive any 1128 response to a Request after several retransmissions or within some 1129 maximum period of time, it may reenter the relay discovery phase in 1130 an attempt to find a new relay. This topic is addressed in more 1131 detail in Section 5.2. 1133 4.2.2. Tunneling 1135 From the standpoint of a relay, an AMT "tunnel" is identified by the 1136 IP address and UDP port pair used as the destination address for 1137 sending encapsulated multicast IP datagrams to a gateway. This 1138 address is referred here as the tunnel endpoint address. 1140 A gateway sends a Membership Update message to a relay to add or 1141 remove group subscriptions to a tunnel endpoint. The tunnel endpoint 1142 is identified by the source IP address and source UDP port carried by 1143 the Membership Update message when it arrives at a relay (this 1144 address may differ from that carried by the message when it exited 1145 the gateway as a result of network address translation). 1147 The Membership Update messages sent by a single gateway host may 1148 originate from several source addresses or ports - each unique 1149 combination represents a unique tunnel endpoint. A single gateway 1150 host may legitimately create and accept traffic on multiple tunnel 1151 endpoints, e.g., the gateway may use separate ports for the IPv4/IGMP 1152 and IPv6/MLD protocols. 1154 A tunnel is "created" when a gateway sends a Membership Update 1155 message containing an IGMP or MLD membership report that creates one 1156 or more group subscriptions when none currently existed for that 1157 tunnel endpoint address. 1159 A tunnel ceases to exist when all group subscriptions for a tunnel 1160 endpoint are deleted. This may occur as a result of the following 1161 events: 1163 o The gateway sends an IGMP or MLD report, leave or done message to 1164 the relay that deletes the last group subscription linked to the 1165 tunnel endpoint. 1167 o The gateway sends a Teardown message to the relay that causes it 1168 to delete any and all subscriptions bound to the tunnel endpoint. 1170 o The relay stops receiving updates from the gateway until such time 1171 that per-group or per-tunnel timers expire, causing the relay to 1172 delete the subscriptions. 1174 The tunneling approach described above conceptually transforms a 1175 unicast-only inter-network into an NBMA link layer, over which 1176 multicast traffic may be delivered. Each relay, plus the set of all 1177 gateways using the relay, together may be thought of as being on a 1178 separate logical NBMA link, where the "link layer" address is a UDP/ 1179 IP address-port pair provided by the Membership Update message. 1181 4.2.2.1. Address Roaming 1183 As described above, each time a relay receives a Membership Update 1184 message from a new source address-port pair, the group subscriptions 1185 described by that message apply to the tunnel endpoint identified by 1186 that address. 1188 This can cause problems for a gateway if the address carried by the 1189 messages it sends to a relay changes unexpectedly. These changes may 1190 cause the relay to transmit duplicate, undeliverable or unrequested 1191 traffic back towards the gateway or an intermediate device. This may 1192 create congestion and have negative consequences for the gateway, its 1193 network, or multicast receivers, and in some cases, may also produce 1194 a significant amount of ICMP traffic directed back towards the relay 1195 by a NAT, router or gateway host. 1197 There are several scenarios in which the address carried by messages 1198 sent by a gateway may change without that gateway's knowledge, as for 1199 example, when: 1201 o The message originates from a different interface on a gateway 1202 that possesses multiple interfaces. 1204 o The DHCP assignment for a gateway interface changes. 1206 o The gateway roams to a different wireless network. 1208 o The address mapping applied by an intervening network-translation- 1209 device (NAT) changes as a result of mapping expiration or routing 1210 changes in a multi-homed network. 1212 In the case where the address change occurs between the transmission 1213 of a Request message and subsequent Membership Update messages, the 1214 relay will simply ignore any Membership Update messages from the new 1215 address because MAC authentication will fail (see Section 4.2.1.2). 1216 The relay may continue to transmit previously requested traffic, but 1217 no duplication will occur, i.e., the possibility for the delivery of 1218 duplicate traffic does not arise until a Request message is received 1219 from the new address. 1221 The protocol provides a method for a gateway to detect an address 1222 change and explicitly request that the relay stop sending traffic to 1223 a previous address. This process involves the Membership Query and 1224 Teardown messages and is described in Section 4.2.1.3. 1226 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 _______ | ___ | ______ | ______ | ___ | _______ 1276 |IGMP|IP| v |AMT| v |UDP|IP| v |IP|UDP| v |AMT| v |IP|IGMP| 1277 | | | | | | | | | | | | | | | | 1278 | |<------------------------------------------------------->| | 1279 |____| | | | | | | | | | | | | |____| 1280 | |<--------------------------------------------------| | 1281 |_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______| 1282 | | | | | 1283 IP AMT:IP IP:UDP:AMT:IP AMT:IP IP 1285 Figure 10: AMT Encapsulation 1287 The IGMP and MLD messages used in AMT are exchanged as complete IP 1288 datagrams. These IP datagrams are encapsulated in AMT messages that 1289 are transmitted using UDP. The same holds true for multicast traffic 1290 - each multicast IP datagram or datagram fragment that arrives at the 1291 relay is encapsulated in an AMT message and transmitted to one or 1292 more gateways via UDP. 1294 The IP protocol of the encapsulated packets need not match the IP 1295 protocol used to send the AMT messages. AMT messages sent via IPv4 1296 may carry IPv6/MLD packets and AMT messages sent via IPv6 may carry 1297 IPv4/IGMP packets. 1299 The checksum field contained in the UDP header of the messages 1300 requires special consideration. Of primary concern is the cost of 1301 computing a checksum on each replicated multicast packet after it is 1302 encapsulated for delivery to a gateway. Many routing/forwarding 1303 platforms do not possess the capability to compute checksums on UDP 1304 encapsulated packets as they may not have access to the entire 1305 datagram. 1307 To avoid placing an undue burden on the relay platform, the protocol 1308 specifically allows zero-valued UDP checksums on the multicast data 1309 messages. This is not an issue in UDP over IPv4 as the UDP checksum 1310 field may be set to zero. However, this is a problem for UDP over 1311 IPv6 as that protocol requires a valid, non-zero checksum in UDP 1312 datagrams [RFC2460]. Messages sent over IPv6 with a UDP checksum of 1313 zero may fail to reach the gateway. This is a well known issue for 1314 UDP-based tunneling protocols that is described [RFC6936]. A 1315 recommended solution is described in [RFC6935]. 1317 4.2.2.4. UDP Fragmentation 1319 Naive encapsulation of a multicast IP datagrams within an AMT data 1320 messages may produce UDP datagrams that might require fragmentation 1321 if their size exceeds the MTU of network path between the relay and a 1322 gateway. Many multicast applications, especially those related to 1323 media streaming, are designed to deliver independent data samples in 1324 separate packets, without fragmentation, to ensure some number of 1325 complete samples can be delivered even in the presence of packet 1326 loss. To prevent or reduce undesirable fragmentation, the AMT 1327 protocol describes specific procedures for handling multicast 1328 datagrams whose encapsulation might exceed the path MTU. These 1329 procedures are described in Section 5.3.3.6. 1331 5. Protocol Description 1333 This section provides a normative description of the AMT protocol. 1335 5.1. Protocol Messages 1337 The AMT protocol defines seven message types for control and 1338 encapsulation. These messages are assigned the following names and 1339 numeric identifiers: 1341 +--------------+---------------------+ 1342 | Message Type | Message Name | 1343 +--------------+---------------------+ 1344 | 1 | Relay Discovery | 1345 | | | 1346 | 2 | Relay Advertisement | 1347 | | | 1348 | 3 | Request | 1349 | | | 1350 | 4 | Membership Query | 1351 | | | 1352 | 5 | Membership Update | 1353 | | | 1354 | 6 | Multicast Data | 1355 | | | 1356 | 7 | Teardown | 1357 +--------------+---------------------+ 1359 These messages are exchanged as IPv4 or IPv6 UDP datagrams. 1361 5.1.1. Relay Discovery 1363 A Relay Discovery message is used to solicit a response from a relay 1364 in the form of a Relay Advertisement message. 1366 The UDP/IP datagram containing this message MUST carry a valid, non- 1367 zero UDP checksum and carry the following IP address and UDP port 1368 values: 1370 Source IP Address - The IP address of the gateway interface on which 1371 the gateway will listen for a relay response. Note: The value of 1372 this field may be changed as a result of network address 1373 translation before arriving at the relay. 1375 Source UDP Port - The UDP port number on which the gateway will 1376 listen for a relay response. Note: The value of this field may be 1377 changed as a result of network address translation before arriving 1378 at the relay. 1380 Destination IP Address - An anycast or unicast IP address, i.e., the 1381 Relay Discovery Address advertised by a relay. 1383 Destination UDP Port - The IANA-assigned AMT port number (See 1384 Section 7.2). 1386 0 1 2 3 1387 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 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | V=0 |Type=1 | Reserved | 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | Discovery Nonce | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 Figure 11: Relay Discovery Message Format 1396 5.1.1.1. Version (V) 1398 The protocol version number for this message is 0. 1400 5.1.1.2. Type 1402 The type number for this message is 1. 1404 5.1.1.3. Reserved 1406 Reserved bits that MUST be set to zero by the gateway and ignored by 1407 the relay. 1409 5.1.1.4. Discovery Nonce 1411 A 32-bit random value generated by the gateway and echoed by the 1412 relay in a Relay Advertisement message. This value is used by the 1413 gateway to correlate Relay Advertisement messages with Relay 1414 Discovery messages. Discovery nonce generation is described in 1415 Section 5.2.3.4.5. 1417 5.1.2. Relay Advertisement 1419 The Relay Advertisement message is used to supply a gateway with a 1420 unicast IP address of a relay. A relay sends this message to a 1421 gateway when it receives a Relay Discovery message from that gateway. 1423 The UDP/IP datagram containing this message MUST carry a valid, non- 1424 zero UDP checksum and carry the following IP address and UDP port 1425 values: 1427 Source IP Address - The destination IP address carried by the Relay 1428 Discovery message (i.e., the Relay Discovery Address advertised by 1429 the relay). 1431 Source UDP Port - The destination UDP port carried by the Relay 1432 Discovery message (i.e., the IANA-assigned AMT port number). 1434 Destination IP Address - The source IP address carried by the Relay 1435 Discovery message. Note: The value of this field may be changed 1436 as a result of network address translation before arriving at the 1437 gateway. 1439 Destination UDP Port - The source UDP port carried by the Relay 1440 Discovery message. Note: The value of this field may be changed 1441 as a result of network address translation before arriving at the 1442 gateway. 1444 0 1 2 3 1445 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 1446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 | V=0 |Type=2 | Reserved | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Discovery Nonce | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | | 1452 ~ Relay Address (IPv4 or IPv6) ~ 1453 | | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1456 Figure 12: Relay Advertisement Message Format 1458 5.1.2.1. Version (V) 1460 The protocol version number for this message is 0. 1462 5.1.2.2. Type 1464 The type number for this message is 2. 1466 5.1.2.3. Reserved 1468 Reserved bits that MUST be set to zero by the relay and ignored by 1469 the gateway. 1471 5.1.2.4. Discovery Nonce 1473 A 32-bit value copied from the Discovery Nonce field 1474 (Section 5.1.1.4) contained in the Relay Discovery message. The 1475 gateway uses this value to match a Relay Advertisement to a Relay 1476 Discovery message. 1478 5.1.2.5. Relay Address 1480 The unicast IPv4 or IPv6 address of the relay. A gateway uses the 1481 length of the UDP datagram containing the Relay Advertisement message 1482 to determine the address family; i.e., length - 8 = 4 (IPv4) or 16 1483 (IPv6). The relay returns an IP address for the protocol used to 1484 send the Relay Discovery message, i.e., an IPv4 relay address for an 1485 IPv4 discovery address or an IPv6 relay address for an IPv6 discovery 1486 address. 1488 5.1.3. Request 1490 A gateway sends a Request message to a relay to solicit a Membership 1491 Query response. 1493 The successful delivery of this message marks the start of the first 1494 stage in the three-way handshake used to create or update state 1495 within a relay. 1497 The UDP/IP datagram containing this message MUST carry a valid, non- 1498 zero UDP checksum and carry the following IP address and UDP port 1499 values: 1501 Source IP Address - The IP address of the gateway interface on which 1502 the gateway will listen for a response from the relay. Note: The 1503 value of this field may be changed as a result of network address 1504 translation before arriving at the relay. 1506 Source UDP Port - The UDP port number on which the gateway will 1507 listen for a response from the relay. Note: The value of this 1508 field may be changed as a result of network address translation 1509 before arriving at the relay. 1511 Destination IP Address - The unicast IP address of the relay. 1513 Destination UDP Port - The IANA-assigned AMT port number. 1515 0 1 2 3 1516 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 1517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1518 | V=0 |Type=3 | Reserved |P| Reserved | 1519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1520 | Request Nonce | 1521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 Figure 13: Request Message Format 1525 5.1.3.1. Version (V) 1527 The protocol version number for this message is 0. 1529 5.1.3.2. Type 1531 The type number for this message is 3. 1533 5.1.3.3. Reserved 1535 Reserved bits that MUST be set to zero by the gateway and ignored by 1536 the relay. 1538 5.1.3.4. P Flag 1540 The "P" flag is set to indicate which group membership protocol the 1541 gateway wishes the relay to use in the Membership Query response: 1543 Value Meaning 1545 0 The relay MUST respond with a Membership Query message that 1546 contains an IPv4 packet carrying an IGMPv3 general query 1547 message. 1548 1 The relay MUST respond with a Membership Query message that 1549 contains an IPv6 packet carrying an MLDv2 general query 1550 message. 1552 5.1.3.5. Request Nonce 1554 A 32-bit random value generated by the gateway and echoed by the 1555 relay in a Membership Query message. This value is used by the relay 1556 to compute the Response MAC value and is used by the gateway to 1557 correlate Membership Query messages with Request messages. Request 1558 nonce generation is described in Section 5.2.3.5.6. 1560 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 value 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 computation. The gateway echoes this value 1667 in subsequent Membership Update messages. The gateway also uses this 1668 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 encapsulated IGMP datagrams generated by a gateway MUST conform 2036 to the descriptions found in Section 4 of [RFC3376]. These datagrams 2037 MUST possess the IP headers, header options and header values called 2038 for in [RFC3376], with the following exception; a gateway MAY use any 2039 source address value in an IGMP report datagram including the 2040 "unspecified" address (all octets are zero ). This exception is made 2041 because a gateway pseudo-interface might not possess a valid IPv4 2042 address, and even if an address has been assigned to the interface, 2043 that address might not be a valid link-local source address on any 2044 relay interface. It is for this reason that a relay must accept 2045 encapsulated IGMP reports regardless of the source address they 2046 carry. See Section 5.3.1. 2048 The encapsulated MLD messages generated by a gateway MUST conform to 2049 the description found in Section 5 of [RFC3810]. These datagrams 2050 MUST possess the IP headers, header options and header values called 2051 for in [RFC3810], with the following exception; a gateway MAY use any 2052 source address value in an MLD report datagram including the 2053 "unspecified" address (all octets are zero ). This exception is made 2054 because a gateway pseudo-interface might not possess a valid IPv6 2055 address, and even if an address has been assigned to the interface, 2056 that address might not be a valid link-local source address on any 2057 relay interface. As with IGMP, it is for this reason that a relay 2058 must accept encapsulated MLD reports regardless of the source address 2059 they carry. See Section 5.3.1. 2061 The gateway IGMP/MLD implementation SHOULD retransmit unsolicited 2062 membership state-change reports and merge new state change reports 2063 with pending reports as described in Section 5.1 of [RFC3376] and 2064 Section 6.1 of [RFC3810]. The number of retransmissions is specified 2065 by the relay in the Querier's Robustness Variable (QRV) field in the 2066 last general query forwarded by the pseudo-interface. See 2067 Section 4.1.6 in [RFC3376] and Section 5.1.8 in [RFC3810]. 2069 The gateway IGMP/MLD implementation SHOULD handle general query 2070 messages as described in Section 5.2 of [RFC3376] and Section 6.2 of 2071 [RFC3810], but MAY ignore the Max Resp Code field value and generate 2072 a current state report without any delay. 2074 An IPv4 gateway implementation MUST accept IPv4 datagrams that carry 2075 the general query variant of the IGMPv3 Membership Query message, as 2076 described in Section 4 of [RFC3376]. The gateway MUST accept the 2077 IGMP datagram regardless of the IP source address carried by that 2078 datagram. 2080 An IPv6 gateway implementation MUST accept IPv6 datagrams that carry 2081 the general query variant of the MLDv2 Multicast Listener Query 2082 message, as described in Section 5 of [RFC3810]. The gateway MUST 2083 accept the MLD datagram regardless of the IP source address carried 2084 by that datagram. 2086 5.2.2. Pseudo-Interface Configuration 2088 A gateway host may possess or create multiple gateway pseudo- 2089 interfaces, each with a unique configuration that describes a binding 2090 to a specific IP protocol, relay address, relay discovery address or 2091 upstream network interface. 2093 5.2.2.1. Relay Discovery Address 2095 If a gateway implementation uses AMT relay discovery to obtain a 2096 relay address, it must first be supplied with a relay discovery 2097 address. The relay discovery address may be an anycast or unicast 2098 address. A gateway implementation may rely on a static address 2099 assignment or some form of dynamic address discovery. This 2100 specification does not require that a gateway implementation use any 2101 particular method to obtain a relay discovery address - an 2102 implementation may employ any method that returns a suitable relay 2103 discovery address. 2105 5.2.2.2. Relay Address 2107 Before a gateway implementation can execute the AMT protocol to 2108 request and receive multicast traffic, it must be supplied with a 2109 unicast relay address. A gateway implementation may rely on static 2110 address assignment or support some form of dynamic address discovery. 2111 This specification does not require the use of any particular method 2112 to obtain a relay address - an implementation may employ any method 2113 that returns a suitable relay address. 2115 5.2.2.3. Upstream Interface Selection 2117 A gateway host that possesses multiple network interfaces or 2118 addresses may allow for an explicit selection of the interface to use 2119 when communicating with a relay. The selection might be made to 2120 satisfy connectivity, tunneling or IP protocol requirements. 2122 5.2.2.4. Optional Retransmission Parameters 2124 A gateway implementation that supports retransmission MAY require the 2125 following information: 2127 Discovery Timeout 2128 Initial time to wait for a response to a Relay Discovery message. 2130 Maximum Relay Discovery Retransmission Count 2131 Maximum number of Relay Discovery retransmissions to allow before 2132 terminating relay discovery and reporting an error. 2134 Request Timeout 2135 Initial time to wait for a response to a Request message. 2137 Maximum Request Retransmission Count 2138 Maximum number of Request retransmissions to allow before 2139 abandoning a relay and restarting relay discovery or reporting an 2140 error. 2142 Maximum Retries Count For "Destination Unreachable" 2143 The maximum number of times a gateway should attempt to send the 2144 same Request or Membership Update message after receiving an ICMP 2145 "Destination Unreachable". 2147 5.2.3. Gateway Service 2149 In the following descriptions, a gateway pseudo interface is treated 2150 as a passive entity managed by a gateway service. The gateway 2151 pseudo-interface provides the state and the gateway service provides 2152 the processing. The term "gateway" is used when describing service 2153 behavior with respect to a single pseudo-interface. 2155 5.2.3.1. Startup 2157 When a gateway pseudo-interface is started, the gateway service 2158 begins listening for AMT messages sent to the UDP endpoint(s) 2159 associated with the pseudo-interface and for any locally-generated 2160 IGMP/MLD messages passed to the pseudo-interface. The handling of 2161 these messages is described below. 2163 When the pseudo-interface is enabled, the gateway service MAY: 2165 o Optionally execute the relay discovery procedure described in 2166 Section 5.2.3.4. 2168 o Optionally execute the membership query procedure described in 2169 Section 5.2.3.5 to start the periodic membership update cycle. 2171 5.2.3.2. Handling AMT Messages 2173 A gateway MUST ignore any datagram it receives that cannot be 2174 interpreted as a Relay Advertisement, Membership Query, or Multicast 2175 Data message. The handling of Relay Advertisement, Membership Query, 2176 and Multicast Data messages is addressed in the sections that follow. 2178 A gateway that conforms to this specification MUST ignore any message 2179 with a Version field value other than zero. 2181 While listening for AMT messages, a gateway may be notified that an 2182 ICMP Destination Unreachable message was received as a result of an 2183 AMT message transmission. Handling of ICMP Destination Unreachable 2184 messages is described in Section 5.2.3.9. 2186 5.2.3.3. Handling Multicast Data Messages 2188 A gateway may receive Multicast Data messages after it sends a 2189 Membership Update message to a relay that adds a group subscription. 2190 The gateway may continue to receive Multicast Data messages long 2191 after the gateway sends a Membership Update message that deletes 2192 existing group subscriptions. The gateway MUST be prepared to 2193 receive these messages at any time, but MAY ignore them or discard 2194 their contents if the gateway no longer has any interest in receiving 2195 the multicast datagrams contained within them. 2197 A gateway MUST ignore a Multicast Data message if it fails to satisfy 2198 any of the following requirements: 2200 o The source IP address and UDP port carried by the Multicast Data 2201 message MUST be equal to the destination IP address and UDP port 2202 carried by the matching Membership Update message (i.e., the 2203 current relay address). 2205 o The destination address carried by the encapsulated IP datagram 2206 MUST fall within the multicast address allocation assigned to the 2207 relevant IP protocol, i.e., 224.0.0.0/4 for IPv4 and FF00::/8 for 2208 IPv6. 2210 The gateway extracts the encapsulated IP datagram and forwards it to 2211 the local IP protocol implementation for checksum verification, 2212 fragmented datagram reassembly, source and group filtering, and 2213 transport-layer protocol processing. 2215 Because AMT uses UDP encapsulation to deliver multicast datagrams to 2216 gateways, it qualifies as a tunneling protocol subject to the 2217 limitations described in [RFC6936]. If supported, a gateway SHOULD 2218 employ the solution described in [RFC6936] to ensure that the local 2219 IP stack does not discard IPv6 datagrams with zero checksums. If 2220 Multicast Data message datagrams are processed directly within the 2221 gateway (instead of the host IP stack), the gateway MUST NOT discard 2222 any of these datagrams because they carry a UDP checksum of zero. 2224 5.2.3.4. Relay Discovery Procedure 2226 This section describes gateway requirements related to the relay 2227 discovery message sequence described in Section 4.2.1.1. 2229 5.2.3.4.1. Starting Relay Discovery 2231 A gateway may start or restart the relay discovery procedure in 2232 response to the following events: 2234 o When a gateway pseudo-interface is started (enabled). 2236 o When the gateway wishes to report a group subscription when none 2237 currently exist. 2239 o Before sending the next Request message in a membership update 2240 cycle, i.e., each time the query timer expires (see below). 2242 o After the gateway fails to receive a response to a Request 2243 message. 2245 o After the gateway receives a Membership Query message with the 2246 L-flag set to 1. 2248 5.2.3.4.2. Sending a Relay Discovery Message 2250 A gateway sends a Relay Discovery message to a relay to start the 2251 relay discovery process. 2253 The gateway MUST send the Relay Discovery message using the current 2254 Relay Discovery Address and IANA-assigned AMT port number as the 2255 destination. The Discovery Nonce value in the Relay Discovery 2256 message MUST be computed as described in Section 5.2.3.4.5. 2258 The gateway MUST save a copy of Relay Discovery message or save the 2259 Discovery Nonce value for possible retransmission and verification of 2260 a Relay Advertisement response. 2262 When a gateway sends a Relay Discovery message, it may be notified 2263 that an ICMP Destination Unreachable message was received as a result 2264 of an earlier AMT message transmission. Handling of ICMP Destination 2265 Unreachable messages is described in Section 5.2.3.9. 2267 5.2.3.4.3. Waiting for a Relay Advertisement Message 2269 A gateway MAY retransmit a Relay Discovery message if it does not 2270 receive a matching Relay Advertisement message within some timeout 2271 period. If the gateway retransmits the message multiple times, the 2272 timeout period SHOULD be adjusted to provide an random exponential 2273 back-off. The RECOMMENDED timeout is a random value in the range 2274 [initial_timeout, MIN(initial_timeout * 2^retry_count, 2275 maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and 2276 a RECOMMENDED maximum_timeout of 120 seconds (which is the 2277 recommended minimum NAT mapping timeout described in [RFC4787]). 2279 5.2.3.4.4. Handling a Relay Advertisement Message 2281 When a gateway receives a Relay Advertisement message it must first 2282 determine whether it should accept or ignore the message. A gateway 2283 MUST ignore a Relay Advertisement message if it fails to satisfy any 2284 of the following requirements: 2286 o The gateway MUST be waiting for a Relay Advertisement message. 2288 o The Discovery Nonce value contained in the Relay Advertisement 2289 message MUST equal to the Discovery Nonce value contained in the 2290 Relay Discovery message. 2292 o The source IP address and UDP port of the Relay Advertisement 2293 message MUST equal to the destination IP address and UDP port of 2294 the matching Relay Discovery message. 2296 Once a gateway receives a Relay Advertisement response to a Relay 2297 Discovery message, it SHOULD ignore any other Relay Advertisements 2298 that arrive on the AMT interface until it sends a new Relay Discovery 2299 message. 2301 If a gateway executes the relay discovery procedure at the start of 2302 each membership update cycle and the relay address returned in the 2303 latest Relay Advertisement message differs from the address returned 2304 in a previous Relay Advertisement message, then the gateway SHOULD 2305 send a Teardown message (if supported) to the old relay address, 2306 using information from the last Membership Query message received 2307 from that relay, as described in Section 5.2.3.7. This behavior is 2308 illustrated in the following diagram. 2310 Gateway Relay-1 2311 ------- ------- 2312 : : 2313 Query Expired | | 2314 Timer (QT)-------->| | 2315 | Relay Discovery | 2316 |------------------->| 2317 | | 2318 | Relay Advertisement| 2319 |<-------------------| 2320 | | 2321 | Request | 2322 |------------------->| 2323 | | 2324 | Membership Query | 2325 |<===================| 2326 Start | | 2327 (QT)<--------| Membership Update | 2328 |===================>| 2329 | | 2330 ~ ~ Relay-2 2331 Expired | | ------- 2332 (QT)-------->| | : 2333 | Relay Discovery | | 2334 |------------------------------------>| 2335 | | | 2336 | Relay Advertisement| | 2337 |<------------------------------------| 2338 | | | 2339 | Teardown | | 2340 |------------------->| | 2341 | | | 2342 | Request | | 2343 |------------------------------------>| 2344 | | | 2345 | Membership Query | | 2346 |<====================================| 2347 Start | | | 2348 (QT)<--------| Membership Update | | 2349 |====================================>| 2350 | | | 2351 : : : 2353 Figure 18: Teardown After Relay Address Change 2355 5.2.3.4.5. Discovery Nonce Generation 2357 The discovery nonce MUST be a random, non-zero, 32-bit value, and if 2358 possible, SHOULD be computed using a cryptographically secure pseudo 2359 random number generator. A new nonce SHOULD be generated each time 2360 the gateway restarts the relay discovery process. The same nonce 2361 SHOULD be used when retransmitting a Relay Discovery message. 2363 5.2.3.5. Membership Query Procedure 2365 This section describes gateway requirements related to the membership 2366 update message sequence described in Section 4.2.1.2. 2368 5.2.3.5.1. Starting the Membership Update Cycle 2370 A gateway may send a Request message to start a membership update 2371 cycle (following the optional relay discovery procedure) in response 2372 to the following events: 2374 o When the gateway pseudo-interface is activated. 2376 o When the gateway wishes to report a group subscription when none 2377 currently exist. 2379 Starting the membership update cycle when a gateway pseudo-interface 2380 is started provides several benefits: 2382 o Better performance by allowing state-change reports to be sent as 2383 they are generated, thus minimizing the time to join. 2385 o More robustness by relying on unsolicited state-change reports to 2386 update group membership state rather than the current-state 2387 reports generated by the membership update cycle. Unsolicited 2388 state-change reports are typically retransmitted multiple times 2389 while current-state reports are not. 2391 o Simplified implementation by eliminating any need to queue IGMP/ 2392 MLD messages for delivery after a Membership Query is received, 2393 since the IGMP/MLD state-change messages may be sent as they are 2394 generated. 2396 However, this approach places an additional load on relays as a 2397 gateway will send periodic requests even when it has no multicast 2398 subscriptions. To reduce load on a relay, a gateway SHOULD only send 2399 a Membership Update message while it has active group subscriptions. 2400 A relay will still need to compute a Response MAC for each Request, 2401 but will not be required to recompute it a second time to 2402 authenticate a Membership Update message that contains no 2403 subscriptions. 2405 5.2.3.5.2. Sending a Request Message 2407 A gateway sends a Request message to a relay to solicit a Membership 2408 Query response and start the membership update cycle. 2410 A gateway constructs a Request message containing a Request Nonce 2411 value computed as described in Section 5.2.3.5.6. The gateway MUST 2412 set the "P" flag in the Request message to identify the protocol the 2413 gateway wishes the relay to use for the general query response. 2415 A gateway MUST send a Request message using the current Relay Address 2416 and IANA-assigned AMT port number as the destination. 2418 A gateway MUST save a copy of the Request message or save the Request 2419 Nonce and P-flag values for possible retransmission and verification 2420 of a Membership Query response. 2422 When a gateway sends a Request message, it may be notified that an 2423 ICMP Destination Unreachable message was received as a result of an 2424 earlier AMT message transmission. Handling of ICMP Destination 2425 Unreachable messages is described in Section 5.2.3.9. 2427 5.2.3.5.3. Waiting for a Membership Query Message 2429 A gateway MAY retransmit a Request message if it does not receive a 2430 matching Membership Query message within some timeout period. If the 2431 gateway retransmits the message multiple times, the timeout period 2432 SHOULD be adjusted to provide an random exponential back-off. The 2433 RECOMMENDED timeout is a random value in the range [initial_timeout, 2434 MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a 2435 RECOMMENDED initial_timeout of 1 second and a RECOMMENDED 2436 maximum_timeout of 120 seconds (which is the recommended minimum NAT 2437 mapping timeout described in [RFC4787]). 2439 If a gateway that uses relay discovery does not receive a Membership 2440 Query within a specified time period or after a specified number of 2441 retries, the gateway SHOULD stop waiting for a Membership Query 2442 message and restart relay discovery to locate another relay. 2444 5.2.3.5.4. Handling a Membership Query Message 2446 When a gateway receives a Membership Query message it must first 2447 determine whether it should accept or ignore the message. A gateway 2448 MUST ignore a Membership Query message, or the encapsulated IP 2449 datagram within it, if the message fails to satisfy any of the 2450 following requirements: 2452 o The gateway MUST be waiting for a Membership Query message. 2454 o The Request Nonce value contained in the Membership Query MUST 2455 equal the Request Nonce value contained in the Request message. 2457 o The source IP address and UDP port of the Membership Query MUST 2458 equal the destination IP address and UDP port of the matching 2459 Request message (i.e., the current relay address). 2461 o The encapsulated IP datagram MUST carry an IGMPv3 or MLDv2 2462 message. The protocol MUST match the protocol identified by the 2463 "P" flag in the Request message. 2465 o The IGMPv3 or MLDv2 message MUST be a general query message. 2467 o The total length of the encapsulated IP datagram as computed from 2468 the lengths contained in the datagram header(s) MUST NOT exceed 2469 the available field length within the Membership Query message. 2471 Once a gateway receives a Membership Query response to a Request 2472 message, it SHOULD ignore any other Membership Query messages that 2473 arrive on the AMT interface until it sends a new Request message. 2475 The gateway MUST save the Membership Query message, or the Request 2476 Nonce, Response MAC, Gateway IP Address and Gateway Port Number 2477 fields for use in sending subsequent Membership Update and Teardown 2478 messages. 2480 The gateway extracts the encapsulated IP datagram and forwards it to 2481 the local IP protocol implementation for checksum verification and 2482 dispatching to the IGMP or MLD implementation running on the pseudo- 2483 interface. The gateway MUST NOT forward any octets that might exist 2484 between the encapsulated IP datagram and the end of the message or 2485 Gateway Address fields. 2487 The MLD protocol specification indicates that senders should use a 2488 link-local source IP address in message datagrams. This requirement 2489 must be relaxed for AMT because gateways and relays do not normally 2490 share a common subnet. For this reason, a gateway implementation 2491 MUST accept MLD (and IGMP) query message datagrams regardless of the 2492 source IP address they carry. This may require additional processing 2493 on the part of the gateway that might be avoided if the relay and 2494 gateway use the IPv4 and IPv6 addresses allocated for use in AMT 2495 encapsulated control packets as described in Section 5.2.1. 2497 The gateway MUST start a timer that will trigger the next iteration 2498 of the membership update cycle by executing the membership query 2499 procedure. The gateway SHOULD compute the timer duration from the 2500 Querier's Query Interval Code carried by the general-query. A 2501 gateway MAY use a smaller timer duration if required to refresh a NAT 2502 mapping that would otherwise timeout. A gateway MAY use a larger 2503 timer duration if it has no group subscriptions to report. 2505 If the gateway supports the Teardown message and the G-flag is set in 2506 the Membership Query message, the gateway MUST compare the Gateway IP 2507 Address and Gateway Port Number on the new Membership Query message 2508 with the values carried by the previous Membership Query message. If 2509 either value has changed the gateway MUST send a Teardown message to 2510 the relay as described in Section 5.2.3.7. 2512 If the L-flag is set in the Membership Query message, the relay is 2513 reporting that it is NOT accepting Membership Update messages that 2514 create new tunnel endpoints and will simply ignore any that do. If 2515 the L-flag is set and the gateway is not currently reporting any 2516 group subscriptions to the relay, the gateway SHOULD stop sending 2517 periodic Request messages and restart the relay discovery procedure 2518 (if discovery is enabled) to find a new relay with which to 2519 communicate. The gateway MAY continue to send updates even if the 2520 L-flag is set, if it has previously reported group subscriptions to 2521 the relay, one or more subscriptions still exist and the gateway 2522 endpoint address has not changed since the last Membership Query was 2523 received (see previous paragraph). 2525 5.2.3.5.5. Handling Query Timer Expiration 2527 When the query timer (started in the previous step) expires, the 2528 gateway should execute the membership query procedure again to 2529 continue the membership update cycle. 2531 5.2.3.5.6. Request Nonce Generation 2533 The request nonce MUST be a random value, and if possible, SHOULD be 2534 computed using a cryptographically secure pseudo random number 2535 generator. A new nonce MUST be generated each time the gateway 2536 starts the membership query process. The same nonce SHOULD be used 2537 when retransmitting a Request message. 2539 5.2.3.6. Membership Update Procedure 2541 This section describes gateway requirements related to the membership 2542 update message sequence described in Section 4.2.1.2. 2544 The membership update process is primarily driven by the host-mode 2545 IGMP or MLD protocol implementation running on the gateway pseudo- 2546 interface. The IGMP and MLD protocols produce current-state reports 2547 in response to general queries generated by the pseudo-interface via 2548 AMT and produce state-change reports in response to receiver requests 2549 made using the IGMP or MLD service interface. 2551 5.2.3.6.1. Handling an IGMP/MLD IP Datagram 2553 The gateway pseudo-interface MUST accept the following IP datagrams 2554 from the IPv4/IGMP and IPv6/MLD protocols running on the pseudo- 2555 interface: 2557 o IPv4 datagrams that carry an IGMPv2, or IGMPv3 Membership Report 2558 or an IGMPv2 Leave Group message as described in Section 4 of 2559 [RFC3376]. 2561 o IPv6 datagrams that carry an MLDv1 or MLDv2 Multicast Listener 2562 Report or an MLDv1 Multicast Listener Done message as described in 2563 Section 5 of [RFC3810]. 2565 The gateway must be prepared to receive these messages any time the 2566 pseudo-interface is running. The gateway MUST ignore any datagrams 2567 not listed above. 2569 A gateway that waits to start a membership update cycle until after 2570 it receives a datagram containing an IGMP/MLD state-change message 2571 MAY: 2573 o Discard IGMP or MLD datagrams until it receives a Membership Query 2574 message, at which time it processes the Membership Query message 2575 as normal to eventually produce a current-state report on the 2576 pseudo-interface which describes the end state (RECOMMENDED). 2578 o Insert IGMP or MLD datagrams into a queue for transmission after 2579 it receives a Membership Query message. 2581 If and when a gateway receives a Membership Query message (for IGMP 2582 or MLD) it sends any queued or incoming IGMP or MLD datagrams to the 2583 relay as described in the next section. 2585 5.2.3.6.2. Sending a Membership Update Message 2587 A gateway cannot send a Membership Update message to a relay until it 2588 has received a Membership Query message from a relay. If the gateway 2589 has not yet located a relay with which to communicate, it MUST first 2590 execute the relay discovery procedure described in Section 5.2.3.4 to 2591 obtain a relay address. If the gateway has a relay address, but has 2592 not yet received a Membership Query message, it MUST first execute 2593 the membership query procedure described in Section 5.2.3.5 to obtain 2594 a Request Nonce and Response MAC that can be used to send a 2595 Membership Update message. 2597 Once a gateway possesses a valid Relay Address, Request Nonce and 2598 Response MAC, it may encapsulate the IP datagram containing the IGMP/ 2599 MLD message into a Membership Update message. The gateway MUST copy 2600 the Request Nonce and Response MAC values from the last Membership 2601 Query received from the relay into the corresponding fields in the 2602 Membership Update. The gateway MUST send the Membership Update 2603 message using the Relay Address and IANA-assigned AMT port number as 2604 the destination. 2606 When a gateway sends a Membership Update message, it may be notified 2607 that an ICMP Destination Unreachable message was received as a result 2608 of an earlier AMT message transmission. Handling of ICMP Destination 2609 Unreachable messages is described in Section 5.2.3.9. 2611 5.2.3.7. Teardown Procedure 2613 This section describes gateway requirements related to the teardown 2614 message sequence described in Section 4.2.1.3. 2616 Gateway support for the Teardown message is RECOMMENDED. 2618 A gateway that supports Teardown SHOULD make use of Teardown 2619 functionality if it receives a Membership Query message from a relay 2620 that has the "G" flag set to indicate that it contains valid gateway 2621 address fields. 2623 5.2.3.7.1. Handling a Membership Query Message 2625 As described in Section 5.2.3.5.4, if a gateway supports the Teardown 2626 message, has reported active group subscriptions, and receives a 2627 Membership Query message with the "G" flag set, the gateway MUST 2628 compare the Gateway IP Address and Gateway Port Number on the new 2629 Membership Query message with the values carried by the previous 2630 Membership Query message. If either value has changed the gateway 2631 MUST send a Teardown message as described in the next section. 2633 5.2.3.7.2. Sending a Teardown Message 2635 A gateway sends a Teardown message to a relay to request that it stop 2636 delivering Multicast Data messages to the gateway and delete any 2637 group memberships created by the gateway. 2639 When a gateway constructs a Teardown message, it MUST copy the 2640 Request Nonce, Response MAC, Gateway IP Address and Gateway Port 2641 Number fields from the Membership Query message that provided the 2642 Response MAC for the last Membership Update message sent, into the 2643 corresponding fields of the Teardown message. 2645 A gateway MUST send the Teardown message using the Relay Address and 2646 IANA-assigned AMT port number as the destination. A gateway MAY send 2647 the Teardown message multiple times for robustness. The gateway 2648 SHOULD use the Querier's Robustness Variable (QRV) field contained in 2649 the query encapsulated within the last Membership Query to set the 2650 limit on the number of retransmissions (See Section 4.1.6 in 2651 [RFC3376] and Section 5.1.7 in [RFC3810]). If the gateway sends the 2652 Teardown message multiple times, it SHOULD insert a delay between 2653 each transmission using the timing algorithm employed in IGMP/MLD for 2654 transmitting unsolicited state-change reports. The RECOMMENDED 2655 default delay value is 1 second. 2657 When a gateway sends a Teardown message, it may be notified that an 2658 ICMP Destination Unreachable message was received as a result of an 2659 earlier AMT message transmission. Handling of ICMP Destination 2660 Unreachable messages is described in Section 5.2.3.9. 2662 5.2.3.8. Shutdown 2664 When a gateway pseudo-interface is stopped and the gateway has 2665 existing group subscriptions, the gateway SHOULD either: 2667 o Send a Teardown message to the relay as described in 2668 Section 5.2.3.7, but only if the gateway supports the Teardown 2669 message, and the current relay is returning gateway address fields 2670 in Membership Query messages, or 2672 o Send a Membership Update message to the relay that will delete 2673 existing group subscriptions. 2675 5.2.3.9. Handling ICMP Destination Unreachable Responses 2677 A gateway may receive an ICMP "Destination Unreachable" message 2678 [RFC0792] after sending an AMT message. Whether the gateway is 2679 notified that an ICMP message was received is highly dependent on 2680 firewall and gateway IP stack behavior and gateway implementation. 2682 If the reception of an ICMP Destination Unreachable message is 2683 reported to the gateway while waiting to receive an AMT message, the 2684 gateway may respond as follows, depending on platform capabilities 2685 and which outgoing message triggered the ICMP response: 2687 1. The gateway MAY simply abandon the current relay and restart 2688 relay discovery (if used). This is the least desirable approach 2689 as it does not allow for transient network changes. 2691 2. If the last message sent was a Relay Discovery or Request 2692 message, the gateway MAY simply ignore the ICMP response and 2693 continue waiting for incoming AMT messages. If the gateway is 2694 configured to retransmit Relay Discovery or Request messages, the 2695 normal retransmission behavior for those messages is preserved to 2696 prevent the gateway from prematurely abandoning a relay. 2698 3. If the last message sent was a Membership Update message, the 2699 gateway MAY start a new membership update and associated Request 2700 retransmission cycle. 2702 If the reception of an ICMP Destination Unreachable message is 2703 reported to the gateway when attempting to transmit a new AMT 2704 message, the gateway may respond as follows, depending on platform 2705 capabilities and which outgoing message triggered the ICMP response: 2707 1. The gateway MAY simply abandon the current relay and restart 2708 relay discovery (if used). This is the least desirable approach 2709 as it does not allow for transient network changes. 2711 2. If the last message sent was a Relay Discovery, Request or 2712 Teardown message, the gateway MAY attempt to transmit the new 2713 message. If the gateway is configured to retransmit Relay 2714 Discovery, Request or Teardown messages, the normal 2715 retransmission behavior for those messages is preserved to 2716 prevent the gateway from prematurely abandoning a relay. 2718 3. If the last message sent was a Membership Update message, the 2719 gateway SHOULD start a new membership update and associated 2720 Request retransmission cycle. 2722 5.3. Relay Operation 2724 The following sections describe relay implementation requirements. A 2725 non-normative discussion of relay operation may be found in 2726 Section 4.2. 2728 5.3.1. IP/IGMP/MLD Protocol Requirements 2730 A relay requires a subset of router-mode IGMP and MLD functionality 2731 to provide group membership tracking and report processing. 2733 A relay accessible via IPv4 MUST support IPv4/IGMPv3 and MAY support 2734 IPv6/MLDv2. A relay accessible via IPv6 MUST support IPv6/MLDv2 and 2735 MAY support IPv4/IGMPv3. 2737 A relay MUST apply the forwarding rules described in Section 6.3 of 2738 [RFC3376] and Section 7.3 of [RFC3810]. 2740 A relay MUST handle incoming reports as described in Section 6.4 of 2741 [RFC3376] and Section 7.4 of [RFC3810] with the exception that 2742 actions that lead to queries MAY be modified to eliminate query 2743 generation. A relay MUST accept IGMP and MLD report datagrams 2744 regardless of the IP source address carried by those datagrams. 2746 All other aspects of IGMP/MLD router behavior, such as the handling 2747 of queries, querier election, etc., are not used or required for 2748 relay operation. 2750 5.3.2. Startup 2752 If a relay is deployed for anycast discovery, the relay MUST 2753 advertise an anycast Relay Discovery Address Prefix into the unicast 2754 routing system of the anycast domain. An address within that prefix, 2755 i.e., a Relay Discovery Address, MUST be assigned to a relay 2756 interface. 2758 A unicast IPv4 and/or IPv6 address MUST be assigned to the relay 2759 interface that will be used to send and receive AMT control and data 2760 messages. This address or addresses are returned in Relay 2761 Advertisement messages. 2763 The remaining details of relay "startup" are highly implementation- 2764 dependent and are not addressed in this document. 2766 5.3.3. Running 2768 When a relay is started, it begins listening for AMT messages on the 2769 interface to which the unicast Relay Address(es) has been assigned, 2770 i.e., the address returned in Relay Advertisement messages. 2772 5.3.3.1. Handling AMT Messages 2774 A relay MUST ignore any message other than a Relay Discovery, 2775 Request, Membership Update or Teardown message. The handling of 2776 Relay Discovery, Request, Membership Update, and Teardown messages is 2777 addressed in the sections that follow. 2779 Support for the Teardown message is OPTIONAL. If a relay does not 2780 support the Teardown message, it MUST also ignore this message. 2782 A relay that conforms to this specification MUST ignore any message 2783 with a Version field value other than zero. 2785 5.3.3.2. Handling a Relay Discovery Message 2787 This section describes relay requirements related to the relay 2788 discovery message sequence described in Section 4.2.1.1. 2790 A relay MUST accept and respond to Relay Discovery messages sent to 2791 an anycast relay discovery address or the unicast relay address. If 2792 a relay receives a Relay Discovery message sent to its unicast 2793 address, it MUST respond just as it would if the message had been 2794 sent to its anycast discovery address. 2796 When a relay receives a Relay Discovery message it responds by 2797 sending a Relay Advertisement message back to the source of the Relay 2798 Discovery message. The relay MUST use the source IP address and UDP 2799 port of the Relay Discovery message as the destination IP address and 2800 UDP port. The relay MUST use the destination IP address and UDP port 2801 of the Relay Discovery as the source IP address and UDP port to 2802 ensure successful NAT traversal. 2804 The relay MUST copy the value contained in the Discovery Nonce field 2805 of the Relay Discovery message into the Discovery Nonce field in the 2806 Relay Advertisement message. 2808 If the Relay Discovery message was received as an IPv4 datagram, the 2809 relay MUST return an IPv4 address in the Relay Address field of the 2810 Relay Advertisement message. If the Relay Discovery message was 2811 received as an IPv6 datagram, the relay MUST return an IPv6 address 2812 in the Relay Address field. 2814 5.3.3.3. Handling a Request Message 2816 This section describes relay requirements related to the membership 2817 query portion of the message sequence described in Section 4.2.1.2. 2819 When a relay receives a Request message it responds by sending a 2820 Membership Query message back to the source of the Request message. 2822 The relay MUST use the source IP address and UDP port of the Request 2823 message as the destination IP address and UDP port for the Membership 2824 Query message. The source IP address and UDP port carried by the 2825 Membership Query MUST match the destination IP address and UDP port 2826 of the Request to ensure successful NAT traversal. 2828 The relay MUST return the value contained in the Request Nonce field 2829 of the Request message in the Request Nonce field of the Membership 2830 Query message. The relay MUST compute a MAC value, as described in 2831 Section 5.3.5, and return that value in the Response MAC field of the 2832 Membership Query message. 2834 If a relay supports the Teardown message, it MUST set the G-flag in 2835 the Membership Query message and return the source IP address and UDP 2836 port carried by the Request message in the corresponding Gateway IP 2837 Address and Gateway Port Number fields. If the relay does not 2838 support the Teardown message it SHOULD NOT set these fields as this 2839 may cause the gateway to generate unnecessary Teardown messages. 2841 If the P-flag in the Request message is 0, the relay MUST return an 2842 IPv4-encapsulated IGMPv3 general query in the Membership Query 2843 message. If the P-flag is 1, the relay MUST return an 2844 IPv6-encapsulated MLDv2 general query in the Membership Query 2845 message. 2847 If the relay is not accepting Membership Update messages that create 2848 new tunnel endpoints due to resource limitations, it SHOULD set the 2849 L-flag in the Membership Query message to notify the gateway of this 2850 state. Support for the L-flag is OPTIONAL. See Section 5.3.3.8. 2852 The encapsulated IGMPv3 general query datagrams generated by a relay 2853 MUST conform to the descriptions found in Section 4.1 of [RFC3376]. 2854 These datagrams MUST possess the IP headers, header options and 2855 header values called for in [RFC3376], with the following exception; 2856 a relay MAY use any source IP address for an IGMP general query 2857 datagram including the "unspecified" address (all octets are zero). 2858 This exception is made because any source address that a relay might 2859 normally send may not be a valid link-local address on any gateway 2860 interface. It is for this reason that a gateway must accept 2861 encapsulated IGMP queries regardless of the source address they 2862 carry. See Section 5.2.1. 2864 The encapsulated MLDv2 general query datagrams generated by a relay 2865 MUST conform to the descriptions found in Section 5.1 of [RFC3810]. 2866 These datagrams MUST possess the IP headers, header options and 2867 header values called for in [RFC3810], with the following exception; 2868 a relay MAY use any source IP address for an MLD general query 2869 datagram including the "unspecified" address (all octets are zero). 2870 This exception is made because any source address that a relay might 2871 normally send may not be a valid link-local address on any gateway 2872 interface. As with IGMP, it is for this reason that a gateway must 2873 accept encapsulated MLD queries regardless of the source address they 2874 carry. See Section 5.2.1. 2876 A relay MUST set the Querier's Query Interval Code (QQIC) field in 2877 the general query to supply the gateway with a suggested time 2878 duration to use for the membership query timer. The QQIC field is 2879 defined in Section 4.1.7 in [RFC3376] and Section 5.1.9 in [RFC3810]. 2880 A relay MAY adjust this value to affect the rate at which the Request 2881 messages are sent from a gateway. However, a gateway is allowed to 2882 use a shorter duration than specified in the QQIC field, so a relay 2883 may be limited in its ability to spread out Requests coming from a 2884 gateway. 2886 A relay MUST set the Querier's Robustness Variable (QRV) field in the 2887 general query to a non-zero value. This value SHOULD be greater than 2888 one. If a gateway retransmits membership state change messages, it 2889 will retransmit them (robustness variable - 1) times. The QRV field 2890 is defined in Section 4.1.6 in [RFC3376] and Section 5.1.8 in 2891 [RFC3810]. 2893 A relay SHOULD set the Maximum Response Code field in the general 2894 query to a value of 1 to trigger an immediate response from the 2895 gateway (some host IGMP/MLD implementations may not accept a value of 2896 zero). A relay SHOULD NOT use the IGMPv3/MLDv2 Query Response 2897 Interval variable, if available, to generate the Maximum Response 2898 Code field value as the Query Response Interval variable is used in 2899 setting the duration of group state timers and must not be set to 2900 such a small value. The Maximum Response Code field is defined in 2901 Section 4.1.1 in [RFC3376] and Section 5.1.3 in [RFC3810]. See 2902 Section 5.3.3.7. 2904 5.3.3.4. Handling a Membership Update Message 2906 This section describes relay requirements related to the membership 2907 update portion of the message sequence described in Section 4.2.1.2. 2909 When a relay receives a Membership Update message it must first 2910 determine whether it should accept or ignore the message. A relay 2911 MUST NOT make any changes to group membership and forwarding state if 2912 the message fails to satisfy any of the following requirements: 2914 o The IP datagram encapsulated within the message MUST be one of the 2915 following: 2917 * IPv4 datagram carrying an IGMPv2 or IGMPv3 Membership Report 2918 message. 2920 * IPv4 datagram carrying an IGMPv2 Leave Group message. 2922 * IPv6 datagram carrying an MLDv1 or MLDv2 Multicast Listener 2923 Report message. 2925 * IPv6 datagram carrying MLDv1 Multicast Listener Done message. 2927 o The encapsulated IP datagram MUST satisfy the IP header 2928 requirements for the IGMP or MLD message type as described in 2929 Section 4 of [RFC3376], Section 2 of [RFC2236], Section 5 of 2930 [RFC3810], and Section 3 of [RFC2710], with the following 2931 exception - a relay MUST accept an IGMP or MLD message regardless 2932 of the IP source address carried by the datagram. 2934 o The total length of the encapsulated IP datagram as computed from 2935 the lengths contained in the datagram header(s) MUST NOT exceed 2936 the available field length within the Membership Update message. 2938 o The computed checksums for the encapsulated IP datagram and its 2939 payload MUST match the values contained therein. Checksum 2940 computation and verification varies by protocol; See [RFC0791] for 2941 IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6). 2943 o If processing of the encapsulated IGMP or MLD message would result 2944 in an allocation of new state or a modification of existing state, 2945 the relay MUST authenticate the source of the Membership message 2946 by verifying that the value contained in the Response MAC field 2947 equals the MAC value computed from the fields in the Membership 2948 Update message datagram. If a time-varying private secret is used 2949 in the computation of a Response MAC, the relay MUST retain the 2950 previous version of the private secret for use in authenticating 2951 Membership Updates sent during the subsequent query interval. If 2952 the first attempt at Response MAC authentication fails, the relay 2953 MUST attempt to authenticate the Response MAC using the previous 2954 private secret value unless 2*query_interval time has elapsed 2955 since the private secret change. See Section 5.3.5. 2957 A relay MAY skip source authentication to reduce the computational 2958 cost of handling Membership Update messages if the relay can make a 2959 trivial determination that the IGMP/MLD message carried by the 2960 Membership Update message will produce no changes in group membership 2961 or forwarding state. The relay does not need to compute and compare 2962 MAC values if it finds there are no group subscriptions for the 2963 source of the Membership Update message and either of the following 2964 is true: 2966 o The encapsulated IP datagram is an IGMPv3 Membership Report or 2967 MLDv2 Multicast Listener Report message that contains no group 2968 records. This may often be the case for gateways that 2969 continuously repeat the membership update cycle even though they 2970 have no group subscriptions to report. 2972 o The encapsulated IP datagram is an IGMPv2 Leave Group or MLDv1 2973 Multicast Listener Done message. 2975 The IGMP and MLD protocol specifications indicate that senders SHOULD 2976 use a link-local source IP address in message datagrams. This 2977 requirement must be relaxed for AMT because gateways and relays do 2978 not share a common subnet. For this reason, a relay implementation 2979 MUST accept IGMP and MLD datagrams regardless of the source IP 2980 address they carry. 2982 Once a relay has determined that the Membership Update message is 2983 valid, it processes the encapsulated IGMP or MLD membership message 2984 to update group membership state and communicates with the multicast 2985 protocol to update forwarding state and possibly send multicast 2986 protocol messages towards upstream routers. The relay MUST ignore 2987 any octets that might exist between the encapsulated IP datagram and 2988 the end of the Membership Update message. 2990 As described in Section 4.2.2, a relay uses the source IP address and 2991 source UDP port carried by a Membership Update messages to identify a 2992 tunnel endpoint. A relay uses the tunnel endpoint as the destination 2993 address for any Multicast Data messages it sends as a result of the 2994 group membership and forwarding state created by processing the IGMP/ 2995 MLD messages contained in Membership Update messages received from 2996 the endpoint. 2998 If a Membership Update message originates from a new endpoint, the 2999 relay MUST determine whether it can accept updates from a new 3000 endpoint. If a relay has been configured with a limit on the total 3001 number of endpoints, or a limit on the total number of endpoints for 3002 a given source address, then the relay MAY ignore the Membership 3003 Update message and possibly withdraw any Relay Discovery Address 3004 Prefix announcement that it might have made. See Section 5.3.3.8. 3006 A relay MUST maintain some form of group membership database for each 3007 endpoint. The per-endpoint databases are used update a forwarding 3008 table containing entries that map an (*,G) or (S,G) subscription to a 3009 list of tunnel endpoints. 3011 A relay MUST maintain some form of group membership database 3012 representing a merger of the group membership databases of all 3013 endpoints. The merged group membership database is used to update 3014 upstream multicast forwarding state. 3016 A relay MUST maintain a forwarding table that maps each unique (*,G) 3017 and (S,G) subscription to a list of tunnel endpoints. A relay uses 3018 this forwarding table to provide the destination address when 3019 performing UDP/IP encapsulation of the incoming multicast IP 3020 datagrams to form Multicast Data messages. 3022 If a group filter mode for a group entry on a tunnel endpoint is 3023 EXCLUDE, the relay SHOULD NOT forward datagrams that originate from 3024 sources in the filter source list unless the relay architecture does 3025 not readily support source filtering. A relay MAY ignore the source 3026 list if necessary because gateways are expected to do their own 3027 source filtering. 3029 5.3.3.5. Handling a Teardown Message 3031 This section describes relay requirements related to the teardown 3032 message sequence described in Section 4.2.1.3. 3034 When a relay (that supports the Teardown message) receives a Teardown 3035 message, it MUST first authenticate the source of the Teardown 3036 message by verifying that the Response MAC carried by the Teardown 3037 message is equal to a MAC value computed from the fields carried by 3038 the Teardown message. The method used to compute the MAC differs 3039 from that used to generate and validate the Membership Query and 3040 Membership Update messages in that the source IP address and source 3041 UDP port number used to compute the MAC are taken from the Gateway IP 3042 Address and Gateway Port Number field in the Teardown message rather 3043 than from the IP and UDP headers in the datagram that carries the 3044 Teardown message. The MAC computation is described Section 5.3.5. A 3045 relay MUST ignore a Teardown message If the computed MAC does not 3046 equal the value of the Response MAC field. 3048 If a relay determines that a Teardown message is authentic, it MUST 3049 immediately stop transmitting Multicast Data messages to the endpoint 3050 identified by the Gateway IP Address and Gateway Port Number fields 3051 in the message. The relay MUST eventually delete any group 3052 membership and forwarding state associated with the endpoint, but MAY 3053 delay doing so to allow a gateway to recreate group membership state 3054 on a new endpoint and thereby avoid making unnecessary (temporary) 3055 changes in upstream routing/forwarding state. 3057 The state changes made by a relay when processing a Teardown message 3058 MUST be identical to those that would be made as if the relay had 3059 received an IGMP/MLD report that would cause the IGMP or MLD protocol 3060 to delete all existing group records in the group membership database 3061 associated with the endpoint. The processing of the Teardown message 3062 should trigger or mimic the normal interaction between IGMP or MLD 3063 and a multicast protocol to produce required changes in forwarding 3064 state and possibly send prune/leave messages towards upstream 3065 routers. 3067 5.3.3.6. Handling Multicast IP Datagrams 3069 When a multicast IP datagram is forwarded to the relay pseudo- 3070 interface, the relay MUST, for each gateway that has expressed an 3071 interest in receiving the datagram, encapsulate the IP datagram into 3072 a Multicast Data message or messages and send that message or 3073 messages to the gateway. This process is highly implementation 3074 dependent, but conceptually requires the following steps: 3076 o Use the IP datagram source and destination address to look up the 3077 appropriate (*,G) or (S,G) entry in the endpoint forwarding table 3078 created for the pseudo-interface as a result of IGMP/MLD 3079 processing. 3081 o Possibly replicate the datagram for each gateway endpoint listed 3082 for that (*,G) or (S,G) entry. 3084 o If the multicast IP datagram size exceeds the Tunnel MTU as 3085 determined according to the procedure described in 3086 Section 5.3.3.6.1, the relay must execute the procedure described 3087 in Section 5.3.3.6.2. 3089 o Encapsulate and transmit the IP datagram according to the 3090 procedure described in Section 5.3.3.6.3. 3092 The relay pseudo-interface MUST ignore any other IP datagrams 3093 forwarded to the pseudo-interface. 3095 5.3.3.6.1. Path and Tunnel MTU 3097 A relay MUST compute a Tunnel MTU (TMTU) value for each AMT tunnel 3098 that originates on the relay. A relay will use the TMTU value to 3099 determine whether an incoming multicast IP datagram can be delivered 3100 downstream in a Membership Data message without fragmentation. A 3101 relay MUST compute the TMTU by subtracting the size of the Membership 3102 Data message headers (IP, UDP, and AMT) from the current Path MTU 3103 (PMTU) associated with each AMT tunnel. The relay MUST maintain a 3104 PMTU value on a per-tunnel or per-relay basis. A relay MUST support 3105 one or both of the following methods for determining the PMTU value: 3107 o The relay MAY provide a configuration option that establishes a 3108 fixed PMTU that will be applied to all AMT tunnels originating at 3109 the relay. 3111 o The relay MAY dynamically adjust PMTU value(s) in response to 3112 receipt of ICMP/ICMPv6 "Datagram Too Big" messages as described in 3113 [RFC1191] and [RFC1981]. 3115 If a relay supports dynamic adjustment of per-tunnel or per-relay 3116 PMTU values in response to ICMP messages, the relay MUST provide a 3117 configuration option that disables this feature and also provide a 3118 configuration option that establishes a minimum PMTU for all tunnels. 3119 These configuration options may be used to mitigate certain types of 3120 denial of service attacks (See (Section 6)). When dynamic PMTU 3121 adjustments are disabled, the PMTU for all tunnels MUST default to 3122 the Link MTU (first-hop) on the downstream interface. 3124 5.3.3.6.2. MTU Filtering Procedure 3126 This section defines procedures that a relay must execute when it 3127 receives a multicast datagram whose size is greater than the Tunnel 3128 MTU of the tunnel or tunnels through which it must be delivered. 3130 5.3.3.6.2.1. IPv4 Multicast IP Datagrams 3132 If the DF bit in the multicast datagram header is set to 1 (Don't 3133 Fragment), the relay MUST discard the packet and, if the datagram 3134 originated from an SSM source, send an ICMPv4 [RFC0792] Destination 3135 Unreachable message to the source, with type equal to 4 3136 (fragmentation needed and DF set). The ICMP Destination Unreachable 3137 message MUST contain an next-hop MTU (as specified by [RFC1191]) and 3138 the relay MUST set the next-hop MTU to the TMTU associated with the 3139 tunnel or tunnels. If the DF bit in the multicast datagram header is 3140 set to 0 (May Fragment), the relay MUST fragment the datagram and 3141 encapsulate each fragment within Multicast Data messages for 3142 transmission through the tunnel or tunnels. This ensures that 3143 gateways will receive complete, non-fragmented Multicast Data 3144 messages, containing fragmented multicast datagram payloads. The 3145 relay SHOULD avoid generating a separate ICMP message for each 3146 tunnel, but instead send a single ICMP message with a Next-hop MTU 3147 equal to the smallest TMTU of all tunnels to which the datagram was 3148 to be forwarded. 3150 5.3.3.6.2.2. IPv6 Multicast IP Datagrams 3152 The relay MUST discard the packet and, if the datagram originated 3153 from an SSM source, send an ICMPv6 [RFC4443] Packet Too Big message 3154 to the payload source. The MTU specified in the Packet Too Big 3155 message MUST be equal to the TMTU associated with the tunnel or 3156 tunnels. The relay SHOULD avoid generating a separate ICMPv6 message 3157 for each tunnel, but instead send a single ICMPv6 message with a 3158 Next-hop MTU equal to the smallest TMTU of all tunnels to which the 3159 datagram was to be forwarded. 3161 5.3.3.6.3. Encapsulation Procedure 3163 A relay encapsulates a multicast IP datagram in a UDP/IP Membership 3164 Data message, using the tunnel endpoint UDP/IP address as the 3165 destination address and the unicast relay address and IANA-assigned 3166 AMT port number as the source UDP/IP address. To ensure successful 3167 NAT traversal, the source address and port MUST match the destination 3168 address and port carried by the Membership Update message sent by the 3169 gateway to create the forwarding table entry. 3171 If possible, the relay SHOULD compute a valid, non-zero checksum for 3172 the UDP datagram carrying the Multicast Data message. See 3173 Section 4.2.2.3. 3175 The following sections describe additional requirements related to 3176 the IP protocol of the tunnel and that of the multicast IP datagram. 3178 5.3.3.6.3.1. Tunneling over IPv4 3180 When a relay delivers an IPv4 payload over an IPv4 tunnel, and the DF 3181 Bit in the payload header is set to 1 (Don't Fragment), the relay 3182 MUST set the DF bit in the Multicast Data IP header to 1. When a 3183 relay delivers an IPv4 payload over an IPv4 tunnel, and the DF Bit in 3184 the payload header is set to 0 (May Fragment), by default, the relay 3185 MUST set the DF bit in the Multicast Data IP header to 1. However, a 3186 relay MAY provide a configuration option that allows the DF bit to be 3187 copied from the payload header to the Multicast Data IP header to 3188 allow downstream fragmentation of the Multicast Data message. When a 3189 relay delivers an IPv6 payload over an IPv4 tunnel, the relay MUST 3190 set the DF bit in the Multicast Data IP header to 1. The relay MUST 3191 NOT transmit a Multicast Data message with an IP header in which the 3192 MF (More Fragments) bit is set to 1. 3194 5.3.3.6.3.2. Tunneling over IPv6 3196 When a tunneling over IPv6, a relay MUST NOT emit a Multicast Data 3197 message datagram containing an IPv6 fragment header. 3199 5.3.3.6.4. Handling Destination Unreachable Messages 3201 If a relay receives a sequence of ICMP or ICMPv6 messages of type 3202 "Destination Unreachable" in response to transmission of a sequence 3203 of AMT Multicast Data messages to a gateway, the relay SHOULD 3204 discontinue sending messages to that gateway and shutdown the tunnel 3205 for that gateway (Handling of ICMP "Destination Unreachable" messages 3206 with code 4, "fragmentation required" is covered in 3207 Section 5.3.3.6.1). If a relay provides this capability, it MUST 3208 provide a configuration option that indicates what number of 3209 sequential "Destination Unreachable" messages can be received and 3210 ignored before the relay will automatically shutdown a tunnel. 3212 5.3.3.7. State Timers 3214 A relay MUST maintain a timer or timers whose expiration will trigger 3215 the removal of any group subscriptions and forwarding state 3216 previously created for a gateway endpoint should the gateway fail to 3217 refresh the group membership state within a specified time interval. 3219 A relay MAY use a variant of the IGMPv3/MLDv2 state management 3220 protocol described in Section 6 of [RFC3376] or Section 7 of 3221 [RFC3810], or may maintain a per-endpoint timer to trigger the 3222 deletion of group membership state. 3224 If a per-endpoint timer is used, the relay MUST restart this timer 3225 each time it receives a new Membership Update message from the 3226 gateway endpoint. 3228 The endpoint timer duration MAY be computed from tunable IGMP/MLD 3229 variables as follows: 3231 ((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval 3233 If IGMP/MLD default values are used for these variables, the gateway 3234 will timeout after 125s * 2 + 10s = 260s. The timer duration MUST be 3235 greater than the query interval suggested in the last Membership 3236 Query message sent to the gateway endpoint. 3238 Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the 3239 Query_Response_Interval value SHOULD be greater than or equal to 10s 3240 to allow for packet loss and round-trip time in the Request/ 3241 Membership Query message exchange. 3243 5.3.3.8. Relay Resource Management 3245 A relay may be configured with various service limits to ensure a 3246 minimum level of performance for gateways that connect to it. 3248 If a relay has determined that it has reached or exceeded maximum 3249 allowable capacity or has otherwise exhausted resources required to 3250 support additional gateways, it SHOULD withdraw any Relay Discovery 3251 Address Prefix it has advertised into the unicast internetwork and 3252 SHOULD set the L-flag in any Membership Query messages it returns to 3253 gateways while in this state. 3255 If the relay receives an update from a gateway that adds group 3256 membership or forwarding state for an endpoint that has already 3257 reached maximum allowable state entries, the relay SHOULD continue to 3258 accept updates from the gateway but ignore any group membership/ 3259 forwarding state additions requested by that gateway. 3261 If the relay receives an update from a gateway that would create a 3262 new tunnel endpoint for a source IP address that has already reached 3263 the maximum allowable number of endpoints (maximum UDP ports), it 3264 should simply ignore the Membership Update. 3266 5.3.4. Shutdown 3268 The following steps should be treated as an abstract description of 3269 the shutdown procedure for a relay: 3271 o Withdraw the Relay Discovery Address Prefix advertisement (if 3272 used). 3274 o Stop listening for Relay Discovery messages. 3276 o Stop listening for control messages from gateways. 3278 o Stop sending data messages to gateways. 3280 o Delete all AMT group membership and forwarding state created on 3281 the relay, coordinating with the multicast routing protocol to 3282 update the group membership state on upstream interfaces as 3283 required. 3285 5.3.5. Response MAC Generation 3287 A Response MAC value is computed by the relay. A Response MAC 3288 computation is required in the following situations: 3290 o To generate a Response MAC value from a Request message for 3291 inclusion in a Membership Query message. 3293 o To generate a Response MAC value from a Membership Update message 3294 for use in authenticating the Response MAC carried within that 3295 message. 3297 o To generate a Response MAC value from a Teardown message to 3298 authenticate the Response MAC carried within that message. 3300 Gateways treat the Response MAC field as an opaque value, so a relay 3301 implementation may generate the MAC using any method available to it. 3302 The RECOMMENDED method for computing the Response MAC is to compute a 3303 cryptographically-secure hash or keyed-hash digest from the following 3304 values: 3306 o The Source IP address of the message (or Teardown Gateway IP 3307 Address field) 3309 o The Source UDP port of the message (or Teardown Gateway Port 3310 Number field) 3312 o The Request Nonce contained in the message. 3314 o A private secret or key known only to the relay. 3316 5.3.6. Private Secret Generation 3318 If the relay implementation uses a private secret (or key) to compute 3319 the Response MAC value, the relay SHOULD periodically compute a new 3320 private secret. The RECOMMENDED maximum interval is 2 hours. A 3321 relay MUST retain the prior secret for use in verifying MAC values 3322 that were sent to gateways just prior to the use of the new secret. 3324 6. Security Considerations 3326 AMT is not intended to be a strongly secured protocol. In general, 3327 the protocol provides the same level of security and robustness as is 3328 provided by the UDP, IGMP and MLD protocols on which it relies. The 3329 lack of strong security features can largely be attributed to the 3330 desire to make the protocol light-weight by minimizing the state and 3331 computation required to service a single gateway, thereby allowing a 3332 relay to service a larger number of gateways. 3334 Many of the threats and vectors described in [RFC3552] may be 3335 employed against the protocol to launch various types of denial-of- 3336 service attacks that can affect the functioning of gateways or their 3337 ability to locate and communicate with a relay. These scenarios are 3338 described below. 3340 As is the case for UDP, IGMP and MLD, the AMT protocol provides no 3341 mechanisms for ensuring message delivery or integrity. The protocol 3342 does not provide confidentiality - multicast groups, sources and 3343 streams requested by a gateway are sent in the clear. 3345 The protocol does use a three-way handshake to provide trivial source 3346 authentication for state allocation and updates (see below). The 3347 protocol also requires gateways and relays to ignore malformed 3348 messages and those messages that do not carry expected address values 3349 or protocol payload types or content. 3351 6.1. Relays 3353 The three-way handshake provided by the membership update message 3354 sequence (See (Section 4.2.1.2)) provides a defense against source- 3355 spoofing-based resource-exhaustion attacks on a relay by requiring 3356 source authentication before state allocation. However, attackers 3357 may still attempt to flood a relay with Request and Membership Update 3358 messages to force the relay to make the MAC authentication 3359 computations in an effort to consume computational resources. 3360 Implementations may choose to limit the frequency with which a relay 3361 responds to Request messages sent from a single IP address or IP 3362 address and UDP port pair, but support for this functionality is not 3363 required. The three-way handshake provides no defense against an 3364 eavesdropping or man-in-the-middle attacker. 3366 Attackers that execute the gateway protocol may consume relay 3367 resources by instantiating a large number of tunnels or joining a 3368 large number of multicast streams. A relay implementation should 3369 provide a mechanism for limiting the number of tunnels (Multicast 3370 Data message destinations) that can be created for a single gateway 3371 source address. Relays should also provide a means for limiting the 3372 number of joins per tunnel instance as a defense against these 3373 attacks. 3375 Relays may withdraw their AMT anycast prefix advertisement when they 3376 reach configured maximum capacity or exhaust required resources. 3377 This behavior allows gateways to use the relay discovery process to 3378 find the next topologically-nearest relay that has advertised the 3379 prefix. This behavior also allows a successful resource exhaustion 3380 attack to propagate from one relay to the next until all relays 3381 reachable using the anycast address have effectively been taken 3382 offline. This behavior may also be used to acquire the unicast 3383 addresses for individual relays which can then be used to launch a 3384 DDoS attack on all of the relays without using the relay discovery 3385 process. To prevent wider disruption of AMT-based distribution 3386 network, relay anycast address advertisements can be limited to 3387 specific administrative routing domains. This will isolate such 3388 attacks to a single domain. 3390 The Path and Tunnel MTU adjustment (discovery) procedure described in 3391 Section 5.3.3.6.1 is vulnerable to two denial of service attacks (see 3392 Section 8 of [RFC1191] for details). Both attacks are based upon on 3393 a malicious party sending forged ICMPv4 Destination Unreachable or 3394 ICMPv6 Packet Too Big messages to a host. In the first attack, the 3395 forged message indicates an inordinately small Path MTU. In the 3396 second attack, the forged message indicates an inordinately large 3397 Path MTU. In both cases, throughput is adversely affected. In order 3398 to mitigate such attacks, relay implementations MUST include a 3399 configuration option to disable Path MTU adjustments on AMT tunnels. 3401 6.2. Gateways 3403 A passive eavesdropper may launch a denial-of-service attack on a 3404 gateway by capturing a Membership Query or Membership Update message 3405 and using the request nonce and message authentication code carried 3406 by the captured message to send a spoofed a Membership Update or 3407 Teardown message to the relay. The spoofed messages may be used to 3408 modify or destroy group membership state associated with the gateway, 3409 thereby changing or interrupting the multicast traffic flows. 3411 A passive eavesdropper may also spoof Multicast Data messages in an 3412 attempt to overload the gateway or disrupt or supplant existing 3413 traffic flows. A properly implemented gateway will filter Multicast 3414 Data messages that do not originate from the expected relay address 3415 and should filter non-multicast packets and multicast IP packets 3416 whose group or source addresses are not included in the current 3417 reception state for the gateway pseudo-interface. 3419 An active eavesdropper may launch a man-in-the-middle attack in which 3420 messages normally exchanged between a gateway and relay are 3421 intercepted, modified, spoofed or discarded by the attacker. The 3422 attacker may deny access to, modify or replace requested multicast 3423 traffic. The AMT protocol provides no means for detecting or 3424 defending against a man-in-the-middle attack - any such functionality 3425 must be provided by multicast receiver applications through 3426 independent detection and validation of incoming multicast datagrams. 3428 The anycast discovery technique for finding relays (see 3429 Section 4.1.4) introduces a risk that a rogue router or a rogue AS 3430 could introduce a bogus route to a specific Relay Discovery Address 3431 prefix, and thus divert or absorb Relay Discovery messages sent by 3432 gateways. Network managers must guarantee the integrity of their 3433 routing to a particular Relay Discovery Address prefix in much the 3434 same way that they guarantee the integrity of all other routes. 3436 6.3. Encapsulated IP Packets 3438 An attacker forging or modifying a Membership Query or Membership 3439 Update message may attempt to embed something other than an IGMP or 3440 MLD message within the encapsulated IP packet carried by these 3441 messages in an effort to introduce these into the recipient's IP 3442 stack. A properly implemented gateway or relay will ignore any such 3443 messages - and may further choose to ignore Membership Query messages 3444 that do not contain a IGMP/MLD general queries or Membership Update 3445 messages that do not contain IGMP/MLD membership reports. 3447 Properly implemented gateways and relays will also filter 3448 encapsulated IP packets that appear corrupted or truncated by 3449 verifying packet length and checksums. 3451 7. IANA Considerations 3453 7.1. IPv4 and IPv6 Anycast Prefix Allocation 3455 The following unicast prefixes have been assigned to provide anycast 3456 routing of relay discovery messages to public AMT Relays as described 3457 in Section 4.1.4. 3459 7.1.1. IPv4 3461 We suggest that IANA assign an x.x.x.x/24 from the IPv4 Recovered 3462 Address Space Registry, but any /24 which has been unassigned and 3463 unadvertised for at least twelve months is acceptable. The block 3464 should be registered as follows: 3466 +----------------------+----------------+ 3467 | Attribute | Value | 3468 +----------------------+----------------+ 3469 | Address Block | x.x.x.x./24 | 3470 | Name | AMT | 3471 | RFC | [TBD] | 3472 | Allocation Date | [TBD] | 3473 | Termination Date | N/A | 3474 | Source | True | 3475 | Destination | True | 3476 | Forwardable | True | 3477 | Global | True | 3478 | Reserved-by-Protocol | False | 3479 +----------------------+----------------+ 3481 7.1.2. IPv6 3483 IANA should register the following special-purpose address block for 3484 IPv6 anycast AMT relay discovery. 3486 +----------------------+----------------+ 3487 | Attribute | Value | 3488 +----------------------+----------------+ 3489 | Address Block | 2001:0003::/32 | 3490 | Name | AMT | 3491 | RFC | [TBD] | 3492 | Allocation Date | [TBD] | 3493 | Termination Date | N/A | 3494 | Source | True | 3495 | Destination | True | 3496 | Forwardable | True | 3497 | Global | True | 3498 | Reserved-by-Protocol | False | 3499 +----------------------+----------------+ 3501 7.2. UDP Port Number 3503 The UDP port number 2268 has been reserved with IANA for use in the 3504 implementation and deployment of AMT. The protocol described by this 3505 document continues to use this port number according to the intent of 3506 the original request. IANA should assign this port number to AMT 3507 upon acceptance of this I-D. 3509 8. Contributors 3511 The following people provided significant contributions to the design 3512 of the protocol and earlier versions of this specification: 3514 Amit Aggarwal 3515 Microsoft Corporation 3516 One Microsoft Way 3517 Redmond, WA 98052-6399 3518 USA 3519 Email: amitag@microsoft.com 3521 Thomas Morin 3522 Orange 3523 2, avenue Pierre Marzin 3524 Lannion 22300 3525 France 3526 Email: thomas.morin@orange.com 3528 Dirk Ooms 3529 OneSparrow 3530 Robert Molsstraat 11; 2018 Antwerp 3531 Belgium 3532 EMail: dirk@onesparrow.com 3534 Tom Pusateri 3535 !j 3536 Wake Forest, NC 3537 USA 3538 Email: pusateri@bangj.com 3540 Dave Thaler 3541 Microsoft Corporation 3542 One Microsoft Way 3543 Redmond, WA 98052-6399 3544 USA 3545 Email: dthaler@microsoft.com 3547 9. Acknowledgments 3549 The authors would like to thank the following individuals for their 3550 suggestions, comments, and corrections: 3552 Mark Altom 3553 Toerless Eckert 3554 Marshall Eubanks 3555 Gorry Fairhurst 3556 Dino Farinacci 3557 Lenny Giuliano 3558 Andy Huang 3559 Tom Imburgia 3560 Patricia McCrink 3561 Han Nguyen 3562 Doug Nortz 3563 Pekka Savola 3564 Robert Sayko 3565 Greg Shepherd 3566 Steve Simlo 3567 Mohit Talwar 3568 Lorenzo Vicisano 3569 Kurt Windisch 3570 John Zwiebel 3572 The anycast discovery mechanism described in this document is based 3573 on similar work done by the NGTrans WG for obtaining automatic IPv6 3574 connectivity without explicit tunnels ("6to4"). Tony Ballardie 3575 provided helpful discussion that inspired this document. 3577 Juniper Networks was instrumental in funding several versions of this 3578 draft as well as an open source implementation. 3580 10. References 3582 10.1. Normative References 3584 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 3585 Thyagarajan, "Internet Group Management Protocol, Version 3586 3", RFC 3376, October 2002. 3588 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 3589 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 3591 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3592 Architecture", RFC 4291, February 2006. 3594 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 3595 IP", RFC 4607, August 2006. 3597 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 3598 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 3599 RFC 4787, January 2007. 3601 10.2. Informative References 3603 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 3604 1981. 3606 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3607 RFC 792, September 1981. 3609 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 3610 RFC 1112, August 1989. 3612 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 3613 November 1990. 3615 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 3616 Anycasting Service", RFC 1546, November 1993. 3618 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 3619 for IP version 6", RFC 1981, August 1996. 3621 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3622 Requirement Levels", BCP 14, RFC 2119, March 1997. 3624 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 3625 2", RFC 2236, November 1997. 3627 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3628 (IPv6) Specification", RFC 2460, December 1998. 3630 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 3631 Translator (NAT) Terminology and Considerations", RFC 3632 2663, August 1999. 3634 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 3635 Listener Discovery (MLD) for IPv6", RFC 2710, October 3636 1999. 3638 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 3639 Text on Security Considerations", BCP 72, RFC 3552, July 3640 2003. 3642 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 3643 Protocol 4 (BGP-4)", RFC 4271, January 2006. 3645 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 3646 Message Protocol (ICMPv6) for the Internet Protocol 3647 Version 6 (IPv6) Specification", RFC 4443, March 2006. 3649 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 3650 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 3651 Protocol Specification (Revised)", RFC 4601, August 2006. 3653 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 3654 Services", BCP 126, RFC 4786, December 2006. 3656 [RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and 3657 UDP Checksums for Tunneled Packets", RFC 6935, April 2013. 3659 [RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement 3660 for the Use of IPv6 UDP Datagrams with Zero Checksums", 3661 RFC 6936, April 2013. 3663 Author's Address 3665 Gregory Bumgardner 3667 Phone: +1 541 343 6790 3668 Email: gbumgard@gmail.com