idnits 2.17.1 draft-ietf-mboned-auto-multicast-12.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 15 instances of too long lines in the document, the longest one being 1 character in excess of 72. == 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 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 (February 16, 2012) is 4446 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 951 -- Looks like a reference, but probably isn't: '2' on line 953 -- Looks like a reference, but probably isn't: '3' on line 956 -- Looks like a reference, but probably isn't: '4' on line 970 -- Looks like a reference, but probably isn't: '5' on line 972 -- Looks like a reference, but probably isn't: '6' on line 975 -- Looks like a reference, but probably isn't: '7' on line 979 == Missing Reference: '16-bits' is mentioned on line 3478, but not defined == Missing Reference: '128-bits' is mentioned on line 3478, but not defined == Unused Reference: 'RFC0768' is defined on line 3280, but no explicit reference was found in the text == Unused Reference: 'RFC4605' is defined on line 3299, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 3332, but no explicit reference was found in the text == Unused Reference: 'RFC3053' is defined on line 3353, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 3356, but no explicit reference was found in the text == Unused Reference: 'RFC3068' is defined on line 3359, but no explicit reference was found in the text == Unused Reference: 'RFC3973' is defined on line 3366, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 3378, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 == Outdated reference: A later version (-08) exists of draft-ietf-6man-udpchecksums-01 == Outdated reference: A later version (-12) exists of draft-ietf-6man-udpzero-05 -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 2 errors (**), 0 flaws (~~), 14 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 Cisco 4 Intended status: Standards Track T. Morin 5 Expires: August 19, 2012 France Telecom - Orange 6 February 16, 2012 8 Automatic Multicast Tunneling 9 draft-ietf-mboned-auto-multicast-12 11 Abstract 13 This document describes Automatic Multicast Tunneling (AMT), a 14 protocol for delivering multicast traffic from sources in a 15 multicast-enabled network to receivers that lack multicast 16 connectivity to the source network. The protocol uses UDP 17 encapsulation and unicast replication to provide this functionality. 19 The AMT protocol is specifically designed to support rapid deployment 20 by requiring minimal changes to existing network infrastructure. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 19, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3.1. Requirements Notation . . . . . . . . . . . . . . . . . . 6 72 3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 74 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1. General Architecture . . . . . . . . . . . . . . . . . . . 9 76 4.2. General Operation . . . . . . . . . . . . . . . . . . . . 18 77 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 33 78 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 33 79 5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 47 80 5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 61 81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 72 82 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 83 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 76 84 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77 85 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78 86 10.1. Normative References . . . . . . . . . . . . . . . . . . . 78 87 10.2. Informative References . . . . . . . . . . . . . . . . . . 78 88 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 81 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 84 91 1. Introduction 93 The advantages and benefits provided by multicast technologies are 94 well known. There are a number of application areas that are ideal 95 candidates for the use of multicast, including media broadcasting, 96 video conferencing, collaboration, real-time data feeds, data 97 replication, and software updates. Unfortunately, many of these 98 applications must currently rely on unicast replication at or near 99 sources because most clients lack multicast connectivity to the 100 network containing the sources. The reasons for the lack of 101 connectivity vary, but are primarily the result of service provider 102 policies and network limitations. 104 Automatic Multicast Tunneling (AMT) is a protocol that uses UDP-based 105 encapsulation to overcome the aforementioned lack of multicast 106 connectivity. AMT enables sites, hosts or applications that do not 107 have native multicast access to a multicast source network to request 108 and receive SSM [RFC4607] and ASM [RFC1112] multicast traffic from 109 sources in that network. 111 2. Applicability 113 This document describes a protocol that may be used to deliver 114 multicast traffic from sources in a multicast enabled network to 115 sites that lack multicast connectivity to the source network. This 116 document does not describe any methods for sourcing multicast traffic 117 from isolated sites as this topic is out of scope. 119 AMT is not intended to be used as a substitute for native multicast, 120 especially in conditions or environments requiring high traffic flow. 121 AMT uses unicast replication to reach multiple receivers and the 122 bandwidth cost for this replication will be higher than that required 123 if the receivers were reachable via native multicast. 125 3. Terminology 127 3.1. Requirements Notation 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3.2. Definitions 135 This document adopts the following definitions for use in describing 136 the protocol: 138 Downstream: 139 A downstream interface or connection that faces away from the 140 multicast distribution root or towards multicast receivers. 142 Upstream: 143 An upstream interface or connection that faces a multicast 144 distribution root or source. 146 Non-Broadcast Multi-Access (NMBA): 147 A non-broadcast multiple-access (NBMA) network or interface is one 148 to which multiple network nodes (hosts or routers) are attached, 149 but where packets are transmitted directly from one node to 150 another node over a virtual circuit or physical link. NBMA 151 networks do not support multicast or broadcast traffic - a node 152 that sources multicast traffic must replicate the multicast 153 packets for separate transmission to each node that has requested 154 the multicast traffic. 156 Multicast Receiver: 157 An entity that requests and receives multicast traffic. A 158 receiver may be a router, host, application, or application 159 component. The method by which a receiver transmits group 160 membership requests and receives multicast traffic varies 161 according to receiver type. 163 Group Membership Database: 164 A group membership database describes the current multicast 165 subscription/reception sate for an interface or system. 167 Reception State: 168 The multicast subscription state of a pseudo, virtual or physical 169 network interface. See group membership database. 171 Subscription: 172 A group or state entry in a group membership database or reception 173 state table. 175 Group Membership Protocol: 176 The term "group membership protocol" is used as a generic 177 reference to the Internet Group Management (IGMP) ([RFC1112], 178 [RFC2236], [RFC3376]) or Multicast Listener Discovery ([RFC2710], 179 [RFC3810]) protocols. 181 Multicast Protocol: 182 The term "multicast protocol" is used as a generic reference to 183 multicast routing protocols used to join or leave multicast 184 distribution trees such as PIM-SM [RFC4601]. 186 Network Address Translation (NAT): 187 Network Address Translation is the process of modifying the source 188 IP address and port numbers carried by an IP packet while 189 transiting a network node (See [RFC2663]). Intervening NAT 190 devices may change the source address and port carried by messages 191 sent from an AMT gateway to an AMT relay, possibly producing 192 changes in protocol state and behavior. 194 Anycast: 195 A network addressing and routing method in which packets from a 196 single sender are routed to the topologically nearest node in a 197 group of potential receivers all identified by the same 198 destination address. See [RFC4786]. 200 3.3. Abbreviations 202 AMT - Automatic Multicast Tunneling Protocol. 204 ASM - Any-Source Multicast. 206 DoS - Denial-of-Service (attack) and DDoS for distributed-DoS. 208 IGMP - Internet Group Management Protocol (v1, v2 and v3). 210 IP - Internet Protocol (v4 and v6). 212 MAC - Message Authentication Code (or Cookie). 214 MLD - Multicast Listener Discovery protocol (v1 and v2). 216 NAT - Network Address Translation (or translation node). 218 NBMA - Non-Broadcast Multi-Access (network, interface or mode) 220 SSM - Source-Specific Multicast. 222 PIM - Protocol Independent Multicast. 224 4. Protocol Overview 226 This section provides an informative description of the protocol. A 227 normative description of the protocol and implementation requirements 228 may be found in section Section 5. 230 4.1. General Architecture 232 Isolated Site | Unicast Network | Native Multicast 233 | (Internet) | 234 | | 235 | | 236 | Group Membership | 237 +-------+ ===========================> +-------+ Multicast +------+ 238 |Gateway| | | | Relay |<----//----|Source| 239 +-------+ <=========================== +-------+ +------+ 240 | Multicast Data | 241 | | 242 | | 244 Figure 1: Basic AMT Architecture 246 The AMT protocol employs a client-server model in which a "gateway" 247 sends requests to receive specific multicast traffic to a "relay" 248 which responds by delivering the requested multicast traffic back to 249 the gateway. 251 Gateways are generally deployed within networks that lack multicast 252 support or lack connectivity to a multicast-enabled network 253 containing multicast sources of interest. 255 Relays are deployed within multicast-enabled networks that contain, 256 or have connectivity to, multicast sources. 258 4.1.1. Relationship to IGMP and MLD Protocols 260 AMT relies on the Internet Group Management (IGMP) [RFC3376] and 261 Multicast Listener Discovery (MLD) [RFC3810] protocols to provide the 262 functionality required to manage, communicate, and act on changes in 263 multicast group membership. A gateway or relay implementation does 264 not necessarily require a fully-functional, conforming implementation 265 of IGMP or MLD to adhere to this specification, but the protocol 266 description that appears in this document assumes that this is the 267 case. The minimum functional and behavioral requirements for the 268 IGMP and MLD protocols are described in Section 5.2.1 and 269 Section 5.3.1. 271 Gateway Relay 273 General _____ _____ 274 ___________ Query | | | | Query ___________ 275 | |<------| | | |<------| | 276 | Host Mode | | AMT | | AMT | |Router Mode| 277 | IGMP/MLD | | | UDP | | | IGMP/MLD | 278 |___________|------>| |<----->| |------>|___________| 279 Report | | | | Report 280 Leave/Done | | | | Leave/Done 281 | | | | 282 IP Multicast <------| | | |<------ IP Multicast 283 |_____| |_____| 285 Multicast Reception State Managed By IGMP/MLD 287 A gateway runs the host portion of the IGMP and MLD protocols to 288 generate group membership updates that are sent via AMT messages to a 289 relay. A relay runs the router portion of the IGMP and MLD protocols 290 to process the group membership updates to produce the required 291 changes in multicast forwarding state. A relay uses AMT messages to 292 send incoming multicast IP datagrams to gateways according to their 293 current group membership state. 295 The primary function of AMT is to provide the handshaking, 296 encapsulation and decapsulation required to transport the IGMP and 297 MLD messages and multicast IP datagrams between the gateways and 298 relays. The IGMP and MLD messages that are exchanged between 299 gateways and relays are encapsulated as complete IP datagrams within 300 AMT control messages. Multicast IP datagrams are replicated and 301 encapsulated in AMT data messages. All AMT messages are sent via 302 unicast UDP/IP. 304 4.1.2. Gateways 306 The downstream side of a gateway services multicast receivers - the 307 gateway accepts group membership requests from receivers and forwards 308 requested multicast traffic back to those receivers. 310 The upstream side of a gateway connects to relays. A gateway sends 311 encapsulated IGMP and MLD messages to a relay to indicate an interest 312 in receiving specific multicast traffic. 314 4.1.2.1. Architecture 316 Each gateway possesses a logical pseudo-interface: 318 join/leave ---+ +----------+ 319 | | | 320 V IGMPv3/MLDv2 | | 321 +---------+ General Query| | AMT 322 |IGMP/MLD |<-------------| AMT | Messages +------+ 323 |Host Mode| | Gateway |<-------->|UPD/IP| 324 |Protocol |------------->|Pseudo I/F| +------+ 325 +---------+ IGMP/MLD | | ^ 326 Report | | | 327 Leave/Done | | V 328 IP Multicast <---------------------| | +---+ 329 +----------+ |I/F| 330 +---+ 332 Figure 2: AMT Gateway Pseudo-Interface 334 The pseudo-interface is conceptually a network interface on which the 335 gateway executes the host portion of the IPv4/IGMP (v2 or v3) and 336 IPv6/MLD (v1 or v2) protocols. The multicast reception state of the 337 pseudo-interface is manipulated using the IGMP or MLD service 338 interface. The IGMP and MLD host protocols produce IP datagrams 339 containing group membership messages that the gateway will send to 340 the relay. The IGMP and MLD protocols also supply the retransmission 341 and timing behavior required for protocol robustness. 343 All AMT encapsulation, decapsulation and relay interaction is assumed 344 to occur within the pseudo-interface. 346 A gateway host or application may create separate interfaces for 347 IPv4/IGMP and IPv6/MLD. A gateway host or application may also 348 require additional pseudo-interfaces for each source or domain- 349 specific relay address. 351 Within this document, the term "gateway" may be used as a generic 352 reference to an entity executing the gateway protocol, a gateway 353 pseudo-interface, or a gateway device that has one or more interfaces 354 connected to a unicast inter-network and one or more AMT gateway 355 pseudo-interfaces. 357 The following diagram illustrates how an existing host IP stack 358 implementation might be used to provide AMT gateway functionality to 359 a multicast application: 361 +-----------------------------------------------------+ 362 |Host | 363 | ______________________________________ | 364 | | | | 365 | | ___________________________ | | 366 | | | | | | 367 | | | v | | 368 | | | +-----------+ +--------------+ | 369 | | | |Application| | AMT Daemon | | 370 | | | +-----------+ +--------------+ | 371 | | | join/leave | ^ data ^ AMT | 372 | | | | | | | 373 | | | +----|---|-------------|-+ | 374 | | | | __| |_________ | | | 375 | | | | | | | | | 376 | | | | | Sockets | | | | 377 | | | +-|------+-------+-|---|-+ | 378 | | | | | IGMP | TCP | |UDP| | | 379 | | | +-|------+-------+-|---|-+ | 380 | | | | | ^ IP | | | | 381 | | | | | | ____________| | | | 382 | | | | | | | | | | 383 | | | +-|-|-|----------------|-+ | 384 | | | | | | | | 385 | | | IP(IGMP)| | |IP(UDP(data)) |IP(UDP(AMT)) | 386 | | | v | | v | 387 | | | +-----------+ +---+ | 388 | | | |Virtual I/F| |I/F| | 389 | | | +-----------+ +---+ | 390 | | | | ^ ^ | 391 | | | IP(IGMP)| |IP(UDP(data)) | | 392 | | |_________| |IP(IGMP) | | 393 | | | | | 394 | |_________________| | | 395 | | | 396 +--------------------------------------|--------------+ 397 v 398 AMT Relay 400 Virtual Interface Implementation Example 402 In this example, the host IP stack uses a virtual network interface 403 to interact with a gateway pseudo-interface implementation. 405 4.1.2.2. Use-Cases 407 Use-cases for gateway functionality include: 409 IGMP/MLD Proxy 410 An IGMP/MLD proxy that runs AMT on an upstream interface and 411 router-mode IGMP/MLD on downstream interfaces to provide host 412 access to multicast traffic via the IGMP and MLD protocols. 414 Virtual Network Interface 415 A virtual network interface or pseudo network device driver that 416 runs AMT on a physical network interface to provide socket layer 417 access to multicast traffic via the IGMP/MLD service interface 418 provided by the host IP stack. 420 Application 421 An application or application component that implements and 422 executes IGMP/MLD and AMT internally to gain access to multicast 423 traffic. 425 4.1.3. Relays 427 The downstream side of a relay services gateways - the relay accepts 428 encapsulated IGMP and MLD group membership messages from gateways and 429 encapsulates and forwards the requested multicast traffic back to 430 those gateways. 432 The upstream side of a relay communicates with a native multicast 433 infrastructure - the relay sends join and prune/leave requests 434 towards multicast sources and accepts requested multicast traffic 435 from those sources. 437 4.1.3.1. Architecture 439 Each relay possesses a logical pseudo-interface: 441 +------------------------------+ 442 +--------+ | Multicast Control Plane | 443 | |IGMP/MLD| | 444 | | Query* | +------------+ +----------+ | 445 | |<---//----|IGMPv3/MLDv2| | | | 446 AMT | | | |Router Mode |->| PIM-SM |<--> 447 +------+ Messages | AMT |----//--->|Protocol | | | | 448 |UDP/IP|<-------->| Relay |IGMP/MLD| +------------+ +----------+ | 449 +------+ | Pseudo | Report | | | | 450 ^ | I/F | Leave/ +------|---------------|-------+ 451 | | | Done | | 452 | | | v | 453 V | | IP +-----------+ | 454 +---+ | | Multicast |Multicast |<------+ 455 |I/F| | |<---//-----|Forwarding | 456 +---+ +--------+ |Plane |<--- IP Multicast 457 +-----------+ 459 * Queries, if generated, are consumed by the pseudo-interface. 461 AMT Relay Pseudo-Interface (Router-Based) 463 The pseudo-interface is conceptually a network interface on which the 464 relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2 465 protocols. Relays do not send unsolicited IGMPv3/MLDv2 query 466 messages to gateways so relays must consume or discard any local 467 queries normally generated by IGMPv3 or MLDv2. 469 A relay maintains group membership state for each gateway connected 470 through the pseudo-interface as well as for the entire pseudo- 471 interface (if multiple gateways are managed via a single interface). 472 Multicast packets received on upstream interfaces on the relay are 473 routed to the pseudo-interface where they are replicated, 474 encapsulated and sent to interested gateways. Changes in the pseudo- 475 interface group membership state may trigger the transmission of 476 multicast protocol requests upstream towards a given source or 477 rendezvous point and cause changes in internal routing/forwarding 478 state. 480 The relay pseudo-interface is a architectural abstraction used to 481 describe AMT protocol operation. For the purposes of this document, 482 the pseudo-interface is most easily viewed as an interface to a 483 single gateway - encapsulation, decapsulation, and other AMT-specific 484 processing occurs "within" the pseudo-interface while forwarding and 485 replication occur outside of it. 487 An alternative view is to treat the pseudo-interface as a non- 488 broadcast multi-access (NBMA) network interface whose link layer is 489 the unicast-only network over which AMT messages are exchanged with 490 gateways. Individual gateways are conceptually treated as logical 491 NBMA links on the interface. In this architectural model, group 492 membership tracking, replication and forwarding functions occur in 493 the pseudo-interface. 495 This document does not specify any particular architectural solution 496 - a relay developer may choose to implement and distribute protocol 497 functionality as required to take advantage of existing relay 498 platform services and architecture. 500 Within this document, the term "relay" may be used as a generic 501 reference to an entity executing the relay protocol, a relay pseudo- 502 interface, or a relay device that has one or more network interfaces 503 with multicast connectivity to a native multicast infrastructure, 504 zero or more interfaces connected to a unicast inter-network, and one 505 or more relay pseudo-interfaces. 507 4.1.3.2. Use-Cases 509 Use-cases for relay functionality include: 511 Multicast Router 512 A multicast router that runs AMT on a downstream interface to 513 provide gateway access to multicast traffic. A "relay router" 514 uses a multicast routing protocol (e.g. PIM-SM RFC4601 [RFC4601]) 515 to construct a forwarding path for multicast traffic by sending 516 join and prune messages to neighboring routers to join or leave 517 multicast distribution trees for a given SSM source or ASM 518 rendezvous point. 520 IGMP/MLD Proxy Router 521 An IGMP/MLD proxy that runs AMT on a downstream interface and 522 host-mode IGMPv3/MLDv2 on a upstream interface. This "relay 523 proxy" sends group membership reports to a local, multicast- 524 enabled router to join and leave specific SSM or ASM groups. 526 4.1.4. Deployment 528 The AMT protocol calls for a relay deployment model that uses anycast 529 addressing [RFC1546][RFC4291] to pair gateways with relays. 531 Under this approach, one or more relays advertise a route for the 532 same IP address prefix. To find a relay with which to communicate, a 533 gateway sends a message to an anycast IP address within that prefix. 534 This message is routed to the topologically-nearest relay that has 535 advertised the prefix. The relay that receives the message responds 536 by sending its unicast address back to the gateway. The gateway uses 537 this address as the destination address for any messages it 538 subsequently sends to the relay. 540 The use of anycast addressing provides the following benefits: 542 o Relays may be deployed at multiple locations within a single 543 multicast-enabled network. Relays might be installed "near" 544 gateways to reduce bandwidth requirements, latency and limit the 545 number of gateways that might be serviced by a single relay. 547 o Relays may be added or removed at any time thereby allowing staged 548 deployment, scaling and hot-swapping - the relay discovery process 549 will always return the nearest operational relay. 551 o Relays may take themselves offline when they exhaust resources 552 required to service additional gateways. Existing gateway 553 connections may be preserved, but new gateway requests would be 554 routed to the next-nearest relay. 556 4.1.4.1. Public Versus Private 558 Ideally, the AMT protocol would provide a universal solution for 559 connecting gateways to multicast sources - that any gateway would be 560 able to access any globally advertised multicast source via publicly- 561 accessible, widely-deployed relays. Unfortunately, today's internet 562 does not yet allow this, as many relays will lack native multicast 563 access to sources even though they may be globally accessible via 564 unicast. 566 In these cases, a provider may deploy relays within their own source 567 network to allow for multicast distribution within that network. 568 Gateways that use these relays must use a provider-specific relay 569 discovery mechanism or a private anycast address to obtain access to 570 these relays. 572 4.1.5. Discovery 574 To execute the gateway portion of the protocol, a gateway requires a 575 unicast IP address of an operational relay. This address may be 576 obtained using a number of methods - it may be statically assigned or 577 dynamically chosen via some form of relay discovery process. 579 As described in the previous section, the AMT protocol provides a 580 relay discovery method that relies on anycast addressing. Gateways 581 are not required to use AMT relay discovery, but all relay 582 implementations must support it. 584 The AMT protocol uses the following terminology when describing the 585 discovery process: 587 Relay Discovery Address Prefix: 588 The anycast address prefix used to route discovery messages to a 589 relay. 591 Relay Discovery Address: 592 The anycast destination address used when sending discovery 593 messages. 595 Relay Address: 596 The unicast IP address obtained as a result of the discovery 597 process. 599 4.1.5.1. Relay Discovery Address Selection 601 The selection of an anycast Relay Discovery Address may be source- 602 dependent, as a relay located via relay discovery must have multicast 603 connectivity to a desired source. 605 Similarly, the selection of a unicast Relay address may be source- 606 dependent, as a relay contacted by a gateway to supply multicast 607 traffic must have native multicast connectivity to the traffic source 609 Methods that might be used to perform source-specific or group- 610 specific relay selection are highly implementation-dependent and are 611 not further addressed by this document. Possible approaches include 612 the use of static lookup tables, DNS-based queries, or a provision of 613 a service interface that accepts join requests on (S,G,relay- 614 discovery-address) or (S,G,relay-address) tuples. 616 4.1.5.2. IANA-Assigned Relay Discovery Address Prefix 618 This document calls for IANA to allocate an anycast address prefix 619 for use in advertising and discovering publicly accessible relays. 621 A relay discovery address is constructed from the anycast address 622 prefix by setting the low-order octet of the prefix address to 1 (for 623 both IPv4 and IPv6). 625 Public relays must advertise a route to the anycast address prefix 626 and configure an interface to respond to the relay discovery address. 628 The IANA address assignments are discussed in Section 7. 630 4.2. General Operation 632 4.2.1. Message Sequences 634 The AMT protocol defines the following messages for control and 635 encapsulation. These messages are exchanged as UDP/IP datagrams, one 636 message per datagram. 638 Relay Discovery: 639 Sent by gateways to solicit a Relay Advertisement from any relay 640 in order to find a relay with which to communicate. 642 Relay Advertisement: 643 Sent by relays as a response to a Relay Discovery message. Used 644 to deliver a relay address to a gateway. 646 Request: 647 Sent by gateways to solicit a Membership Query message from a 648 relay. 650 Membership Query: 651 Sent by relays as a response to a Request message. Used to 652 deliver an encapsulated IGMPv3 or MLDv2 query message to the 653 gateway. 655 Membership Update: 656 Sent by gateways to deliver an encapsulated IGMP or MLD report/ 657 leave/done message to a relay. 659 Multicast Data: 660 Sent by relays to deliver an encapsulated IP multicast datagram to 661 a gateway. 663 Teardown: 664 Sent by gateways to stop the delivery of Multicast Data messages 665 requested in an earlier Membership Update message. 667 The following sections describe how these messages are exchanged to 668 execute the protocol. 670 4.2.1.1. Relay Discovery Sequence 672 Gateway Relay 673 ------- ----- 674 : : 675 | | 676 [1] |Relay Discovery | 677 |------------------->| 678 | | 679 | Relay Advertisement| [2] 680 |<-------------------| 681 [3] | | 682 : : 684 AMT Relay Discovery Sequence 686 The following sequence describes how the Relay Discovery and Relay 687 Advertisement messages are used to find a relay with which to 688 communicate: 690 1. The gateway sends a Relay Discovery message containing a random 691 nonce to the Relay Discovery Address. If the Relay Discovery 692 Address is an anycast address, the message is routed to 693 topologically-nearest network node that advertises that address. 695 2. The node receiving the Relay Discovery message sends a Relay 696 Advertisement message back to the source of the Relay Discovery 697 message. The message carries a copy of the nonce contained in 698 the Relay Discovery message and the unicast IP address of a 699 relay. 701 3. When the gateway receives the Relay Advertisement message it 702 verifies that the nonce matches the one sent in the Relay 703 Discovery message, and if it does, uses the relay address carried 704 by the Relay Advertisement as the destination address for 705 subsequent AMT messages. 707 Note that the responder need not be a relay - the responder may 708 obtain a relay address by some other means and return the result in 709 the Relay Advertisement (i.e. the responder is a load-balancer or 710 broker). 712 4.2.1.2. Membership Update Sequence 714 There exists a significant difference between normal IGMP and MLD 715 behavior and that required by AMT. An IGMP/MLD router acting as a 716 querier normally transmits query messages on a network interface to 717 construct and refresh group membership state for the connected 718 network. These query messages are multicast to all IGMP/MLD enabled 719 hosts on the network. Each host responds by multicasting report 720 messages that describe their current multicast reception state. 722 However, AMT does not allow relays to send unsolicited query messages 723 to gateways, as the set of active gateways may be unknown to the 724 relay and potentially quite large. Instead, AMT requires each 725 gateway to periodically send a message to a relay to solicit a 726 general-query response. A gateway accomplishes this by sending a 727 Request message to a relay. The relay responds by sending Membership 728 Query message back to the gateway. The Membership Query message 729 carries an encapsulated general query that is processed by the IGMP 730 or MLD protocol implementation on the gateway to produce a 731 membership/listener report. Each time the gateway receives a 732 Membership Query message it starts a timer whose expiration will 733 trigger the start of a new Request->Membership Query message 734 exchange. This timer-driven sequence is used to mimic the 735 transmission of a periodic general query by an IGMP/MLD router. This 736 query cycle may continue indefinitely once started by sending the 737 initial Request message. 739 A membership update occurs when an IGMP or MLD report, leave or done 740 message is passed to the gateway pseudo-interface. These messages 741 may be produced as a result of the aforementioned general-query 742 processing or as a result of receiver interaction with the IGMP/MLD 743 service interface. Each report is encapsulated and sent to the relay 744 after the gateway has successfully established communication with the 745 relay via a Request and Membership Query message exchange. If a 746 report is passed to the pseudo-interface before the gateway has 747 received a Membership Query message from the relay, the gateway may 748 discard the report or queue the report for delivery after a 749 Membership Query is received. Subsequent IGMP/MLD report/leave/done 750 messages that are passed to the pseudo-interface are immediately 751 encapsulated and transmitted to the relay. 753 IGMP/MLD Pseudo-I/F Relay 754 -------- ---------- ----- 755 : : : 756 | | Request | 757 | 1|-------------------->| 758 | | Membership Query |2 759 Query | | Q(0,{}) | 760 Timer | Start 3|<--------------------| 761 (QT)<--------------------------| | 762 | Q(0,{}) | | 763 |<--------------------| | 764 4| R({}) | Membership Update | 765 |-------------------->|5 R({}) | 766 | |====================>|6a 767 Join(S,G) : : : 768 ()--------->|7 R({G:ALLOW({S})}) | Membership Update | 769 |-------------------->|8 R({G:ALLOW({S})}) | 770 | |====================>|9a Join(S,G) 771 | | |---------->() 772 : : : 773 | ------------|---------------------|------------ 774 | | | | | 775 | | | Multicast Data | IP(S,G) | 776 | | | IP(S,G) 10|<--------() | 777 | | IP(S,G) 11|<====================| | 778 | | ()<--------| | | 779 | | | | | 780 : ------------:---------------------:------------ 781 | Expired | | 782 (QT)-------------------------->|12 Request | 783 | 1|-------------------->| 784 | | Membership Query |2 785 | | Q(0,{}) | 786 | Start 3|<--------------------| 787 (QT)<--------------------------| | 788 | Q(0,{}) | | 789 |<--------------------| | 790 4| R({G:INCLUDE({S})}) | Membership Update | 791 |-------------------->|5 R({G:INCLUDE({S})})| 792 | |====================>|6b 793 Leave(S,G) : : : 794 ()--------->|7 R({G:BLOCK({S})}) | Membership Update | 795 |-------------------->|8 R({G:BLOCK({S})}) | 796 | |====================>|9b Prune(S,G) 797 | | |---------->() 798 : : : 800 Membership Update Sequence (IGMPv3/MLDv2 Example) 802 The following sequence describes how the Request, Membership Query, 803 and Membership Update messages are used to report current group 804 membership state or changes in group membership state: 806 1. A gateway sends a Request message to the relay that contains a 807 random nonce and a flag indicating whether the relay should 808 return an IGMPv3 or MLDv2 general query. 810 2. When the relay receives a Request message, it generates a 811 message authentication code (MAC) by computing a hash value from 812 a private secret and the nonce, source IP address, and source 813 UDP port carried by the Request message. The relay then sends a 814 Membership Query message to the gateway that contains the 815 request nonce, the MAC, and an IGMPv3 or MLDv2 general query. 817 3. When the gateway receives a Membership Query message, it 818 verifies that the request nonce matches the one sent in the last 819 Request, and if it does, the gateway saves the request nonce and 820 MAC for use in sending subsequent Membership Update messages. 821 The gateway starts a timer whose expiration will trigger the 822 transmission of a new Request message and extracts the 823 encapsulated general query message for processing by the IGMP or 824 MLD protocol. The query timer duration is specified by the 825 relay in the QQIC field in the IGMPv3 or MLDv2 general query. 827 4. The gateway's IGMP or MLD protocol implementation processes the 828 general query to produce a current-state report. 830 5. When an IGMP or MLD report is passed to the pseudo-interface, 831 the gateway encapsulates the report in a Membership Update 832 message and sends it to the relay. The request nonce and MAC 833 fields in the Membership Update are assigned the values from the 834 last Membership Query message received for the corresponding 835 group membership protocol (IGMPv3 or MLDv2). 837 6. When the relay receives a Membership Update message, it computes 838 a MAC from a private secret and the request nonce, source IP 839 address, and source UDP port carried by the message. The relay 840 accepts the Membership Update message if the received MAC 841 matches the computed MAC, otherwise the message is ignored. If 842 the message is accepted, the relay may proceed to allocate, 843 refresh, or modify tunnel state. This includes making any group 844 membership, routing and forwarding state changes and issuing any 845 upstream protocol requests required to satisfy the state change. 846 The diagram illustrates two scenarios: 848 A. The gateway has not previously reported any group 849 subscriptions and the report does not contain any group 850 subscriptions, so the relay takes no action. 852 B. The gateway has previously reported a group subscription so 853 the current-state report lists all current subscriptions. 854 The relay responds by refreshing tunnel or group state and 855 resetting any related timers. 857 7. A receiver indicates to the gateway that it wishes to join 858 (allow) or leave (block) specific multicast traffic. This 859 request is typically made through some form IGMP/MLD service 860 interface (as described in Section 2 of [RFC3376] or Section 3 861 of [RFC3810]). The IGMP/MLD protocol responds by generating an 862 IGMP or MLD state-change message. 864 8. When an IGMP or MLD report/leave/done message is passed to the 865 pseudo-interface, the gateway encapsulates the message in a 866 Membership Update message and sends it to the relay. The 867 request nonce and MAC fields in the Membership Update are 868 assigned the values from the last Membership Query message 869 received for the corresponding group membership protocol (IGMP 870 or MLD). 872 The IGMP and MLD protocols may generate multiple messages to 873 provide robustness against packet loss - each of these must be 874 encapsulated in a new Membership Update message and sent to the 875 relay. The Querier Robustness Variable (QRV) field in the last 876 IGMP/MLD query delivered to the IGMP/MLD protocol is typically 877 used to specify the number of repetitions (i.e., the host adopts 878 the QRV value as its own Robustness Variable value). 880 9. When the relay receives a Membership Update message, it again 881 computes a MAC from a private secret and the request nonce, 882 source IP address, and source UDP port carried by the message. 883 The relay accepts the Membership Update message if the received 884 MAC matches the computed MAC, otherwise the message is ignored. 885 If the message is accepted, the relay processes the encapsulated 886 IGMP/MLD and allocates, modifies or deletes tunnel state 887 accordingly. This includes making any group membership, routing 888 and forwarding state changes and issuing any upstream protocol 889 requests required to satisfy the state change. The diagram 890 illustrates two scenarios: 892 A. The gateway wishes to add a group subscription. 894 B. The gateway wishes to delete a previously reported group 895 subscription. 897 10. Multicast datagrams transmitted by a source travel through the 898 native multicast infrastructure to the relay. When the relay 899 receives a multicast IP datagram that carries a source and 900 destination address for which a gateway has expressed an 901 interest in receiving (via the Membership Update message), it 902 encapsulates the datagram into a Multicast Data message and 903 sends it to the gateway using the source IP address and UDP port 904 carried by the Membership Update message as the destination 905 address. 907 11. When the gateway receives a Multicast Data message, it extracts 908 the multicast packet from the message and passes it on to the 909 appropriate receivers. 911 12. When the query timer expires the gateway sends a new Request 912 message to the relay to start a new membership update cycle. 914 The MAC-based source-authentication mechanism described above 915 provides a simple defense against malicious attempts to exhaust relay 916 resources via source-address spoofing. Flooding a relay with spoofed 917 Request or Membership Update messages may consume computational 918 resources and network bandwidth, but will not result in the 919 allocation of state because the Request message is stateless and 920 spoofed Membership Update messages will fail source-authentication 921 and be rejected by the relay. 923 A relay will only allocate new tunnel state if the IGMP/MLD report 924 carried by the Membership Update message creates one or more group 925 subscriptions. 927 A relay deallocates tunnel state after one of the following events; 928 the gateway sends a Membership Update message containing a report 929 that results in the deletion of all remaining group subscriptions, 930 the IGMP/MLD state expires (due to lack of refresh by the gateway), 931 or the relay receives a valid Teardown message from the gateway. 933 A gateway that accepts or reports group subscriptions for both IPv4 934 and IPv6 addresses will send separate Request and Membership Update 935 messages for each protocol (IPv4/IGMP and IPv6/MLD). 937 4.2.1.3. Teardown Sequence 939 A gateway sends a Teardown message to a relay to request that it stop 940 delivering Multicast Data messages to a tunnel endpoint created by an 941 earlier Membership Update message. This message is intended to be 942 used following a gateway address change (See Section 4.2.2.1) to stop 943 the transmission of undeliverable or duplicate multicast data 944 messages. Support for the Teardown message is optional - gateways 945 are not required to send them and relays are not required to act upon 946 them. 948 Gateway Relay 949 ------- ----- 950 : Request : 951 [1] | N | 952 |---------------------->| 953 | Membership Query | [2] 954 | N,MAC,gADDR,gPORT | 955 |<======================| 956 [3] | Membership Update | 957 | ({G:INCLUDE({S})}) | 958 |======================>| 959 | | 960 ----------------------:-----------------------:---------------------- 961 | | | | 962 | | *Multicast Data | *IP Packet(S,G) | 963 | | gADDR,gPORT |<------------------() | 964 | *IP Packet(S,G) |<======================| | 965 | ()<------------------| | | 966 | | | | 967 ----------------------:-----------------------:---------------------- 968 ~ | 969 ~ Request | 970 [4] | N' | 971 |---------------------->| 972 | Membership Query | [5] 973 | N',MAC',gADDR',gPORT' | 974 |<======================| 975 [6] | | 976 | Teardown | 977 | N,MAC,gADDR,gPORT | 978 |---------------------->| 979 | | [7] 980 | Membership Update | 981 | ({G:INCLUDE({S})}) | 982 |======================>| 983 | | 984 ----------------------:-----------------------:---------------------- 985 | | | | 986 | | *Multicast Data | *IP Packet(S,G) | 987 | | gADDR',gPORT' |<------------------() | 988 | *IP Packet (S,G) |<======================| | 989 | ()<------------------| | | 990 | | | | 991 ----------------------:-----------------------:---------------------- 992 | | 993 : : 995 Figure 3: Teardown Message Sequence (IGMPv3/MLDv2 Example) 997 The following sequence describes how the Membership Query and 998 Teardown message are used to detect an address change and stop the 999 delivery of Multicast Data messages to an address: 1001 1. A gateway sends a Request message containing a random nonce to 1002 the relay. 1004 2. The relay sends a Membership Query message to the gateway that 1005 contains the source IP address (gADDR) and source UDP port 1006 (gPORT) values from the Request message. These values will be 1007 used to identify the tunnel should one be created by a subsequent 1008 Membership Update message. 1010 3. When the gateway receives a Membership Query message that carries 1011 the gateway address fields, it compares the gateway IP address 1012 and port number values with those received in the previous 1013 Membership Query (if any). If these values do not match, this 1014 indicates that the Request message arrived at the relay carrying 1015 a different source address than the one sent previously. At this 1016 point in the sequence, no change in source address or port has 1017 occurred. 1019 4. The gateway sends a new Request message to the relay. However, 1020 this Request message arrives at the relay carrying a different 1021 source address than that of the previous Request due to some 1022 change in network interface, address assignment, network topology 1023 or NAT mapping. 1025 5. The relay again responds by sending a Membership Query message to 1026 the gateway that contains the new source IP address (gADDR') and 1027 source UDP port (gPORT') values from the Request message. 1029 6. When the gateway receives the Membership Query message, it 1030 compares the gateway address and port number values against those 1031 returned in the previous Membership Query message. 1033 7. If the reported address or port has changed, the gateway sends a 1034 Teardown message to the relay that contains the request nonce, 1035 MAC, gateway IP address and gateway port number returned in the 1036 earlier Membership Query message. The gateway may send the 1037 Teardown message multiple times where the number of repetitions 1038 is governed by the Querier Robustness Variable (QRV) value 1039 contained in the IGMPv3/MLDv2 general query carried by the 1040 original Membership Query. The gateway continues to process the 1041 new Membership Query message as usual. 1043 8. When the relay receives a Teardown message, it computes a MAC 1044 from a private secret and the request nonce, gateway IP address, 1045 and gateway port number carried by the Teardown message. The 1046 relay accepts the Teardown message if the received MAC matches 1047 the computed MAC, otherwise the message is ignored. If the 1048 message is accepted, the relay makes any group membership, 1049 routing and forwarding state changes required to stop the 1050 transmission of Multicast Data messages to that address. 1052 4.2.1.4. Timeout and Retransmission 1054 The AMT protocol does not establish any requirements regarding what 1055 actions a gateway should take if it fails to receive a response from 1056 a relay. A gateway implementation may wait for an indefinite period 1057 of time to receive a response, may set a time limit on how long to 1058 wait for a response, may retransmit messages should the time limit be 1059 reached, may limit the number of retransmissions, or may simply 1060 report an error. 1062 For example, a gateway may retransmit a Request message if it fails 1063 to receive a Membership Query or expected Multicast Data messages 1064 within some time period. If the gateway fails to receive any 1065 response to a Request after several retransmissions or within some 1066 maximum period of time, it may reenter the relay discovery phase in 1067 an attempt to find a new relay. This topic is addressed in more 1068 detail in Section 5.2. 1070 4.2.2. Tunneling 1072 From the standpoint of a relay, an AMT "tunnel" is identified by the 1073 IP address and UDP port pair used as the destination address for 1074 sending encapsulated multicast IP datagrams to a gateway. This 1075 address is referred here as the tunnel endpoint address. 1077 A gateway sends a Membership Update message to a relay to add or 1078 remove group subscriptions to a tunnel endpoint. The tunnel endpoint 1079 is identified by the source IP address and source UDP port carried by 1080 the Membership Update message when it arrives at a relay (this 1081 address may differ from that carried by the message when it exited 1082 the gateway as a result of network address translation). 1084 The Membership Update messages sent by a single gateway host may 1085 originate from several source addresses or ports - each unique 1086 combination represents a unique tunnel endpoint. A single gateway 1087 host may legitimately create and accept traffic on multiple tunnel 1088 endpoints, e.g., the gateway may use separate ports for the IPv4/IGMP 1089 and IPv6/MLD protocols. 1091 A tunnel is "created" when a gateway sends a Membership Update 1092 message containing an IGMP or MLD membership report that creates one 1093 or more group subscriptions when none currently existed for that 1094 tunnel endpoint address. 1096 A tunnel ceases to exist when all group subscriptions for a tunnel 1097 endpoint are deleted. This may occur as a result of the following 1098 events: 1100 o The gateway sends an IGMP or MLD report, leave or done message to 1101 the relay that deletes the last group subscription linked to the 1102 tunnel endpoint. 1104 o The gateway sends a Teardown message to the relay that causes it 1105 to delete any and all subscriptions bound to the tunnel endpoint. 1107 o The relay stops receiving updates from the gateway until such time 1108 that per-group or per-tunnel timers expire, causing the relay to 1109 delete the subscriptions. 1111 The tunneling approach described above conceptually transforms a 1112 unicast-only inter-network into an NBMA link layer, over which 1113 multicast traffic may be delivered. Each relay, plus the set of all 1114 gateways using the relay, together may be thought of as being on a 1115 separate logical NBMA link, where the "link layer" address is a 1116 UDP/IP address-port pair provided by the Membership Update message. 1118 4.2.2.1. Address Roaming 1120 As described above, each time a relay receives a Membership Update 1121 message from a new source address-port pair, the group subscriptions 1122 described by that message apply to the tunnel endpoint identified by 1123 that address. 1125 This can cause problems for a gateway if the address carried by the 1126 messages it sends to a relay change unexpectedly. These changes may 1127 cause the relay to transmit duplicate, undeliverable or unrequested 1128 traffic back towards the gateway or an intermediate device. This may 1129 create congestion and have negative consequences for the gateway, its 1130 network, or multicast receivers, and in some cases, may also produce 1131 a significant amount of ICMP traffic directed back towards the relay 1132 by a NAT, router or gateway host. 1134 There are several scenarios in which the address carried by messages 1135 sent by a gateway may change without that gateway's knowledge, as for 1136 example, when: 1138 o The message originates from a different interface on a gateway 1139 that possesses multiple interfaces. 1141 o The DHCP assignment for a gateway interface changes. 1143 o The gateway roams to a different wireless network. 1145 o The address mapping applied by an intervening network-translation- 1146 device (NAT) changes as a result of mapping expiration or routing 1147 changes in a multi-homed network. 1149 In the case where the address change occurs between the transmission 1150 of a Request message and subsequent Membership Update messages, the 1151 relay will simply ignore any Membership Update messages from the new 1152 address because MAC authentication will fail (see Section 4.2.1.2). 1153 The relay may continue to transmit previously requested traffic, but 1154 no duplication will occur, i.e., the possibility for the delivery of 1155 duplicate traffic does not arise until a Request message is received 1156 from the new address. 1158 The protocol provides a method for a gateway to detect an address 1159 change and explicitly request that the relay stop sending traffic to 1160 a previous address. This process involves the Membership Query and 1161 Teardown messages and is described in Section 4.2.1.3. 1163 4.2.2.2. Network Address Translation 1165 The messages sent by a gateway to a relay may be subject to network 1166 address translation (NAT) - the source IP address and UDP port 1167 carried by an IP packet sent by the gateway may be modified multiple 1168 times before arriving at the relay. In the most restrictive form of 1169 NAT, the NAT device will create a new mapping for each combination of 1170 source and destination IP address and UDP port. In this case, bi- 1171 directional communication can only be conducted by sending outgoing 1172 packets to the source address and port carried by the last incoming 1173 packet. 1175 Membership Update Membership Update 1176 src: iADDR:iPORT src: eADDR:ePORT 1177 dst: rADDR:rPORT dst: rADDR:rPORT 1178 +---------+ 1179 | NAT | 1180 +---------+ +-----------+ +---------+ 1181 | |---------->| |--------->| | 1182 | Gateway | | Mapping | | Relay | 1183 | |<----------| |<---------| | 1184 +---------+ +-----------+ +---------+ 1185 | | 1186 +---------+ 1187 Multicast Data Multicast Data 1188 src: rADDR:rPORT src: rADDR:rPORT 1189 dst: iADDR:iPORT dst: eADDR:ePORT 1191 Network Address Translation in AMT 1193 AMT provides automatic NAT traversal by using the source IP address 1194 and UDP port carried by the Membership Update message as received at 1195 the relay as the destination address for any Multicast Data messages 1196 the relay sends back as a result. 1198 The NAT mapping created by a Membership Update message will 1199 eventually expire unless it is refreshed by a passing message. This 1200 refresh will occur each time the gateway performs the periodic update 1201 required to refresh group state within the relay (See 1202 Section 4.2.1.2). 1204 4.2.2.3. UDP Encapsulation 1206 Gateway Relay 1208 IP:IGMP IP:IGMP 1209 | AMT:IP:IGMP AMT:IP:IGMP | 1210 | | | | 1211 | | IP:UDP:AMT:IP:IGMP | | 1212 _______ | ___ | ______ | ______ | ___ | _______ 1213 |IGMP|IP| v |AMT| v |UDP|IP| v |IP|UDP| v |AMT| v |IP|IGMP| 1214 | | | | | | | | | | | | | | | | 1215 | |<------------------------------------------------------->| | 1216 |____| | | | | | | | | | | | | |____| 1217 | |<--------------------------------------------------| | 1218 |_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______| 1219 | | | | | 1220 IP AMT:IP IP:UDP:AMT:IP AMT:IP IP 1222 AMT Encapsulation 1224 The IGMP and MLD messages used in AMT are exchanged as complete IP 1225 datagrams. These IP datagrams are encapsulated in AMT messages which 1226 are transmitted using UDP. The same holds true for multicast traffic 1227 - each multicast IP datagram that arrives at the relay is 1228 encapsulated in an AMT message and transmitted to one or more 1229 gateways via UDP. 1231 The IP protocol of the encapsulated packets need not match the IP 1232 protocol used to send the AMT messages. AMT messages sent via IPv4 1233 may carry IPv6/MLD packets and AMT messages sent via IPv6 may carry 1234 IPv4/IGMP packets. 1236 The checksum field contained in the UDP header of the messages 1237 requires special consideration. Of primary concern is the cost of 1238 computing a checksum on each replicated multicast packet after it is 1239 encapsulated for delivery to a gateway. Many routing/forwarding 1240 platforms do not possess the capability to compute checksums on UDP 1241 encapsulated packets as they may not have access to the entire 1242 datagram. 1244 To avoid placing an undue burden on the relay platform, the protocol 1245 specifically allows zero-valued UDP checksums on the multicast data 1246 messages. This is not an issue in UDP over IPv4 as the UDP checksum 1247 field may be set to zero. However, this is a problem for UDP over 1248 IPv6 as that protocol requires a valid, non-zero checksum in UDP 1249 datagrams [RFC2460]. Messages sent over IPv6 with a UDP checksum of 1250 zero may fail to reach the gateway. This is a well known issue for 1251 UDP-based tunneling protocols. See [I-D.ietf-6man-udpchecksums] and 1252 [I-D.ietf-6man-udpzero] for details. 1254 5. Protocol Description 1256 This section provides a normative description of the AMT protocol. 1258 5.1. Protocol Messages 1260 The AMT protocol defines seven message types for control and 1261 encapsulation. These messages are assigned the following names and 1262 numeric identifiers: 1264 +--------------+---------------------+ 1265 | Message Type | Message Name | 1266 +--------------+---------------------+ 1267 | 1 | Relay Discovery | 1268 | | | 1269 | 2 | Relay Advertisement | 1270 | | | 1271 | 3 | Request | 1272 | | | 1273 | 4 | Membership Query | 1274 | | | 1275 | 5 | Membership Update | 1276 | | | 1277 | 6 | Multicast Data | 1278 | | | 1279 | 7 | Teardown | 1280 +--------------+---------------------+ 1282 These messages are exchanged as IPv4 or IPv6 UDP datagrams. 1284 5.1.1. Relay Discovery 1286 A Relay Discovery message is used to solicit a response from a relay 1287 in the form of a Relay Advertisement message. 1289 The UDP/IP datagram containing this message MUST carry a valid, non- 1290 zero UDP checksum and carry the following IP address and UDP port 1291 values: 1293 Source IP Address - The IP address of the gateway interface on which 1294 the gateway will listen for a relay response. Note: The value of 1295 this field may be changed as a result of network address 1296 translation before arriving at the relay. 1298 Source UDP Port - The UDP port number on which the gateway will 1299 listen for a relay response. Note: The value of this field may be 1300 changed as a result of network address translation before arriving 1301 at the relay. 1303 Destination IP Address - An anycast or unicast IP address, i.e. the 1304 Relay Discovery Address advertised by a relay. 1306 Destination UDP Port - The IANA-assigned AMT port number. 1308 0 1 2 3 1309 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 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | V=0 |Type=1 | Reserved | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Discovery Nonce | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 Relay Discovery Message Format 1318 5.1.1.1. Version (V) 1320 The protocol version number for this message is 0. 1322 5.1.1.2. Type 1324 The type number for this message is 1. 1326 5.1.1.3. Reserved 1328 Reserved bits that MUST be set to zero by the gateway and ignored by 1329 the relay. 1331 5.1.1.4. Discovery Nonce 1333 A 32-bit random value generated by the gateway and echoed by the 1334 relay in a Relay Advertisement message. This value is used by the 1335 gateway to correlate Relay Advertisement messages with Relay 1336 Discovery messages. Discovery nonce generation is described in 1337 Section 5.2.3.4.5. 1339 5.1.2. Relay Advertisement 1341 The Relay Advertisement message is used to supply a gateway with a 1342 unicast IP address of a relay. A relay sends this message to a 1343 gateway when it receives a Relay Discovery message from that gateway. 1345 The UDP/IP datagram containing this message MUST carry a valid, non- 1346 zero UDP checksum and carry the following IP address and UDP port 1347 values: 1349 Source IP Address - The destination IP address carried by the Relay 1350 Discovery message (i.e. the Relay Discovery Address advertised by 1351 the relay). 1353 Source UDP Port - The destination UDP port carried by the Relay 1354 Discovery message (i.e. the IANA-assigned AMT port number). 1356 Destination IP Address - The source IP address carried by the Relay 1357 Discovery message. Note: The value of this field may be changed 1358 as a result of network address translation before arriving at the 1359 gateway. 1361 Destination UDP Port - The source UDP port carried by the Relay 1362 Discovery message. Note: The value of this field may be changed 1363 as a result of network address translation before arriving at the 1364 gateway. 1366 0 1 2 3 1367 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 1368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1369 | V=0 |Type=2 | Reserved | 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | Discovery Nonce | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | | 1374 ~ Relay Address (IPv4 or IPv6) ~ 1375 | | 1376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1378 Relay Advertisement Message Format 1380 5.1.2.1. Version (V) 1382 The protocol version number for this message is 0. 1384 5.1.2.2. Type 1386 The type number for this message is 2. 1388 5.1.2.3. Reserved 1390 Reserved bits that MUST be set to zero by the relay and ignored by 1391 the gateway. 1393 5.1.2.4. Discovery Nonce 1395 A 32-bit value copied from the Discovery Nonce field 1396 (Section 5.1.1.4) contained in the Relay Discovery message. The 1397 gateway uses this value to match a Relay Advertisement to a Relay 1398 Discovery message. 1400 5.1.2.5. Relay Address 1402 The unicast IPv4 or IPv6 address of the relay. A gateway uses the 1403 length of the UDP datagram containing the Relay Advertisement message 1404 to determine the address family; i.e. length - 8 = 4 (IPv4) or 16 1405 (IPv6). 1407 5.1.3. Request 1409 A gateway sends a Request message to a relay to solicit a Membership 1410 Query response. 1412 The successful delivery of this message marks the start of the first 1413 stage in the three-way handshake used to create or update state 1414 within a relay. 1416 The UDP/IP datagram containing this message MUST carry a valid, non- 1417 zero UDP checksum and carry the following IP address and UDP port 1418 values: 1420 Source IP Address - The IP address of the gateway interface on which 1421 the gateway will listen for a response from the relay. Note: The 1422 value of this field may be changed as a result of network address 1423 translation before arriving at the relay. 1425 Source UDP Port - The UDP port number on which the gateway will 1426 listen for a response from the relay. Note: The value of this 1427 field may be changed as a result of network address translation 1428 before arriving at the relay. 1430 Destination IP Address - The unicast IP address of the relay. 1432 Destination UDP Port - The IANA-assigned AMT port number. 1434 0 1 2 3 1435 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 1436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1437 | V=0 |Type=3 | Reserved |P| Reserved | 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | Request Nonce | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 Request Message Format 1443 5.1.3.1. Version (V) 1445 The protocol version number for this message is 0. 1447 5.1.3.2. Type 1449 The type number for this message is 3. 1451 5.1.3.3. Reserved 1453 Reserved bits that MUST be set to zero by the gateway and ignored by 1454 the relay. 1456 5.1.3.4. P Flag 1458 The "P" flag is set to indicate which group membership protocol the 1459 gateway wishes the relay to use in the Membership Query response: 1461 Value Meaning 1463 0 The relay MUST respond with a Membership Query message that 1464 contains an IPv4 packet carrying an IGMPv3 general query 1465 message. 1467 1 The relay MUST respond with a Membership Query message that 1468 contains an IPv6 packet carrying an MLDv2 general query 1469 message. 1471 5.1.3.5. Request Nonce 1473 A 32-bit random value generated by the gateway and echoed by the 1474 relay in a Membership Query message. This value is used by the relay 1475 to compute the Response MAC value and is used by the gateway to 1476 correlate Membership Query messages with Request messages. Request 1477 nonce generation is described in Section 5.2.3.5.6. 1479 5.1.4. Membership Query 1481 A relay sends a Membership Query message to a gateway to solicit a 1482 Membership Update response, but only after receiving a Request 1483 message from the gateway. 1485 The successful delivery of this message to a gateway marks the start 1486 of the second-stage in the three-way handshake used to create or 1487 update tunnel state within a relay. 1489 The UDP/IP datagram containing this message MUST carry a valid, non- 1490 zero UDP checksum and carry the following IP address and UDP port 1491 values: 1493 Source IP Address - The destination IP address carried by the 1494 Request message (i.e. the unicast IP address of the relay). 1496 Source UDP Port - The destination UDP port carried by the Request 1497 message (i.e. the IANA-assigned AMT port number). 1499 Destination IP Address - The source IP address carried by the 1500 Request message. Note: The value of this field may be changed as 1501 a result of network address translation before arriving at the 1502 gateway. 1504 Destination UDP Port - The source UDP port carried by the Request 1505 message. Note: The value of this field may be changed as a result 1506 of network address translation before arriving at the gateway. 1508 0 1 2 3 1509 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 1510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1511 | V=0 |Type=4 | Reserved |L|G| Response MAC | 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1513 | | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1515 | Request Nonce | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | | 1518 | Encapsulated General Query Message | 1519 ~ IPv4:IGMPv3(Membership Query) ~ 1520 | IPv6:MLDv2(Listener Query) | 1521 | | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | Gateway Port Number | | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1525 | | 1526 + + 1527 | Gateway IP Address (IPv4 or IPv6) | 1528 + + 1529 | | 1530 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1531 | | 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 Membership Query Message Format 1536 5.1.4.1. Version (V) 1538 The protocol version number for this message is 0. 1540 5.1.4.2. Type 1542 The type number for this message is 4. 1544 5.1.4.3. Reserved 1546 Reserved bits that MUST be set to zero by the relay and ignored by 1547 the gateway. 1549 5.1.4.4. Limit (L) Flag 1551 A 1-bit flag set to 1 to indicate that the relay is NOT accepting 1552 Membership Update messages from new gateway tunnel endpoints and that 1553 it will ignore any that are. A value of 0 has no special 1554 significance - the relay may or may not be accepting Membership 1555 Update messages from new gateway tunnel endpoints. A gateway checks 1556 this flag before attempting to create new group subscription state on 1557 the relay to determine whether it should restart relay discovery. A 1558 gateway that has already created group subscriptions on the relay may 1559 ignore this flag. Support for this flag is RECOMMENDED. 1561 5.1.4.5. Gateway Address (G) Flag 1563 A 1-bit flag set to 0 to indicate that the message does NOT carry the 1564 Gateway Port and Gateway IP Address fields, and 1 to indicate that it 1565 does. A relay implementation that supports the optional teardown 1566 procedure (See Section 5.3.3.5) SHOULD set this flag and and the 1567 Gateway Address field values. If a relay sets this flag, it MUST 1568 also include the Gateway Address fields in the message. A gateway 1569 implementation that does not support the optional teardown procedure 1570 (See Section 5.2.3.7) MAY ignore this flag and the Gateway Address 1571 fields if they are present. 1573 5.1.4.6. Response MAC 1575 A 48-bit source authentication hash generated by the relay as 1576 described in Section 5.3.5. The gateway echoes this value in 1577 subsequent Membership Update messages to allow the relay to verify 1578 that the sender of a Membership Update message was the intended 1579 receiver of a Membership Query sent by the relay. 1581 5.1.4.7. Request Nonce 1583 A 32-bit value copied from the Request Nonce field (Section 5.1.3.5) 1584 carried by a Request message. The relay will have included this 1585 value in the Response MAC hash computation. The gateway echoes this 1586 value in subsequent Membership Update messages. The gateway also 1587 uses this value to match a Membership Query to a Request message. 1589 5.1.4.8. Encapsulated General Query Message 1591 An IP-encapsulated IGMP or MLD message generated by the relay. This 1592 field will contain one of the following IP datagrams: 1594 IPv4:IGMPv3 Membership Query 1596 IPv6:MLDv2 Listener Query 1598 The source address carried by the query message SHOULD be set to zero 1599 to indicate that query originated from a non-querier. 1601 The Querier's Query Interval Code (QQIC) field in the general query 1602 is used by a relay to specify the time offset a gateway should use to 1603 schedule a new three-way handshake to refresh the group membership 1604 state within the relay (current time + Query Interval). 1606 The Querier's Robustness Variable (QRV) field in the general query is 1607 used by a relay to specify the number of times a gateway should 1608 retransmit unsolicited membership reports, encapsulated within 1609 Membership Update messages, and optionally, the number of times to 1610 send a Teardown message. 1612 5.1.4.9. Gateway Address Fields 1614 The Gateway Port Number and Gateway Address fields are present in the 1615 Membership Query message if, and only if, the "G" flag is set. 1617 A gateway need not parse the encapsulated IP datagram to determine 1618 the position of these fields within the UDP datagram containing the 1619 Membership Query messsage - if the G-flag is set, the gateway may 1620 simply subtract the total length of the fields (18 bytes) from the 1621 total length of the UDP datagram to obtain the offset. 1623 5.1.4.9.1. Gateway Port Number 1625 A 16-bit UDP port containing a UDP port value. 1627 The Relay sets this field to the value of the UDP source port of the 1628 Request message that triggered the Query message. 1630 5.1.4.9.2. Gateway IP Address 1632 A 16-byte IP address that, when combined with the value contained in 1633 the Gateway Port Number field, forms the gateway endpoint address 1634 that the relay will use to identify the tunnel instance, if any, 1635 created by a subsequent Membership Update message. This field may 1636 contain an IPv6 address or an IPv4 address stored as an IPv4- 1637 compatible IPv6 address, where the IPv4 address is prefixed with 96 1638 bits set to zero (See [RFC4291]). This address must match that used 1639 by the relay to compute the value stored in the Response MAC field. 1641 5.1.5. Membership Update 1643 A gateway sends a Membership Update message to a relay to report a 1644 change in group membership state, or to report the current group 1645 membership state in response to receiving a Membership Query message. 1646 The gateway encapsulates the IGMP or MLD message as an IP datagram 1647 within a Membership Update message and sends it to the relay, where 1648 it may (see below) be decapsulated and processed by the relay to 1649 update group membership and forwarding state. 1651 A gateway cannot send a Membership Update message until a receives a 1652 Membership Query from a relay because the gateway must copy the 1653 Request Nonce and Response MAC values carried by a Membership Query 1654 into any subsequent Membership Update messages it sends back to that 1655 relay. These values are used by the relay to verify that the sender 1656 of the Membership Update message was the recipient of the Membership 1657 Query message from which these values were copied. 1659 The successful delivery of this message to the relay marks the start 1660 of the final stage in the three-way handshake. This stage concludes 1661 when the relay successfully verifies that sender of the Message 1662 Update message was the recipient of a Membership Query message sent 1663 earlier. At this point, the relay may proceed to process the 1664 encapsulated IGMP or MLD message to create or update group membership 1665 and forwarding state on behalf of the gateway. 1667 The UDP/IP datagram containing this message MUST carry a valid, non- 1668 zero UDP checksum and carry the following IP address and UDP port 1669 values: 1671 Source IP Address - The IP address of the gateway interface on which 1672 the gateway will listen for Multicast Data messages from the 1673 relay. The address must be the same address used to send the 1674 initial Request message or the message will be ignored. Note: The 1675 value of this field may be changed as a result of network address 1676 translation before arriving at the relay. 1678 Source UDP Port - The UDP port number on which the gateway will 1679 listen for Multicast Data messages from the relay. This port must 1680 be the same port used to send the initial Request message or the 1681 message will be ignored. Note: The value of this field may be 1682 changed as a result of network address translation before arriving 1683 at the relay. 1685 Destination IP Address - The unicast IP address of the relay. 1687 Destination UDP Port - The IANA-assigned AMT UDP port number. 1689 0 1 2 3 1690 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 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | V=0 |Type=5 | Reserved | Response MAC | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1694 | | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1696 | Request Nonce | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | | 1699 | Encapsulated Group Membership Update Message | 1700 ~ IPv4:IGMP(Membership Report|Leave Group) ~ 1701 | IPv6:MLD(Listener Report|Listener Done) | 1702 | | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 Membership Update Message Format 1707 5.1.5.1. Version (V) 1709 The protocol version number for this message is 0. 1711 5.1.5.2. Type 1713 The type number for this message is 5. 1715 5.1.5.3. Reserved 1717 Reserved bits that MUST be set to zero by the gateway and ignored by 1718 the relay. 1720 5.1.5.4. Response MAC 1722 A 48-bit value copied from the Response MAC field (Section 5.1.4.6) 1723 in a Membership Query message. Used by the relay to perform source 1724 authentication. 1726 5.1.5.5. Request Nonce 1728 A 32-bit value copied from the Request Nonce field in a Request or 1729 Membership Query message. Used by the relay to perform source 1730 authentication. 1732 5.1.5.6. Encapsulated Group Membership Update Message 1734 An IP-encapsulated IGMP or MLD message produced by the host-mode IGMP 1735 or MLD protocol running on a gateway pseudo-interface. This field 1736 will contain of one of the following IP datagrams: 1738 IPv4:IGMPv2 Membership Report 1740 IPv4:IGMPv2 Leave Group 1742 IPv4:IGMPv3 Membership Report 1744 IPv6:MLDv1 Multicast Listener Report 1746 IPv6:MLDv1 Multicast Listener Done 1748 IPv6:MLDv2 Multicast Listener Report 1750 5.1.6. Multicast Data 1752 A relay sends a Multicast Data message to deliver an IP multicast 1753 packet to a gateway. 1755 The checksum field in the UDP header of this message MAY contain a 1756 value of zero when sent over IPv4 but SHOULD, if possible, contain a 1757 valid, non-zero value when sent over IPv6 (See Section 4.2.2.3). 1759 The UDP/IP datagram containing this message MUST carry the following 1760 IP address and UDP port values: 1762 Source IP Address - The unicast IP address of the relay. 1764 Source UDP Port - The IANA-assigned AMT port number. 1766 Destination IP Address - A tunnel endpoint IP address, i.e. the 1767 source IP address carried by the Membership Update message sent by 1768 a gateway to indicate an interest in receiving the multicast 1769 packet. Note: The value of this field may be changed as a result 1770 of network address translation before arriving at the gateway. 1772 Destination UDP Port - A tunnel endpoint UDP port, i.e. the source 1773 UDP port carried by the Membership Update message sent by a 1774 gateway to indicate an interest in receiving the multicast packet. 1775 Note: The value of this field may be changed as a result of 1776 network address translation before arriving at the gateway. 1778 0 1 2 3 1779 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 1780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1781 | V=0 |Type=6 | Reserved | | 1782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1783 | | 1784 ~ IP Multicast Packet ~ 1785 | | 1786 + - - - - - - - - - - - - - - - - - - - - - - - -+ 1787 | : : : : 1788 +-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - - 1790 Multicast Data Message Format 1792 5.1.6.1. Version (V) 1794 The protocol version number for this message is 0. 1796 5.1.6.2. Type 1798 The type number for this message is 6. 1800 5.1.6.3. Reserved 1802 Bits that MUST be set to zero by the relay and ignored by the 1803 gateway. 1805 5.1.6.4. IP Multicast Data 1807 A complete IPv4 or IPv6 Multicast datagram. 1809 5.1.7. Teardown 1811 A gateway sends a Teardown message to a relay to request that it stop 1812 sending Multicast Data messages to a tunnel endpoint created by an 1813 earlier Membership Update message. A gateway sends this message when 1814 it detects that a Request message sent to the relay carries an 1815 address that differs from that carried by a previous Request message. 1816 The gateway uses the Gateway IP Address and Gateway Port Number 1817 Fields in the Membership Query message to detect these address 1818 changes. 1820 To provide backwards compatibility with early implementations of the 1821 AMT protocol, support for this message and associated procedures is 1822 considered OPTIONAL - gateways are not required to send this message 1823 and relays are not required to act upon it. 1825 The UDP/IP datagram containing this message MUST carry a valid, non- 1826 zero UDP checksum and carry the following IP address and UDP port 1827 values: 1829 Source IP Address - The IP address of the gateway interface used to 1830 send the message. This address may differ from that used to send 1831 earlier messages. Note: The value of this field may be changed as 1832 a result of network address translation before arriving at the 1833 relay. 1835 Source UDP Port - The UDP port number. This port number may differ 1836 from that used to send earlier messages. Note: The value of this 1837 field may be changed as a result of network address translation 1838 before arriving at the relay. 1840 Destination IP Address - The unicast IP address of the relay. 1842 Destination UDP Port - The IANA-assigned AMT port number. 1844 0 1 2 3 1845 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 1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1847 | V=0 |Type=7 | Reserved | Response MAC | 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1849 | | 1850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 | Request Nonce | 1852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1853 | Gateway Port Number | | 1854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1855 | | 1856 + + 1857 | Gateway IP Address (IPv4 or IPv6) | 1858 + + 1859 | | 1860 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | | 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1864 Membership Teardown Message Format 1866 5.1.7.1. Version (V) 1868 The protocol version number for this message is 0. 1870 5.1.7.2. Type 1872 The type number for this message is 7. 1874 5.1.7.3. Reserved 1876 Reserved bits that MUST be set to zero by the gateway and ignored by 1877 the relay. 1879 5.1.7.4. Response MAC 1881 A 48-bit value copied from the Response MAC field (Section 5.1.4.6) 1882 in the last Membership Query message the relay sent to the gateway 1883 endpoint address of the tunnel to be torn down. The gateway endpoint 1884 address is provided by the Gateway IP Address and Gateway Port Number 1885 fields carried by the Membership Query message. 1887 5.1.7.5. Request Nonce 1889 A 32-bit value copied from the Request Nonce field (Section 5.1.4.7) 1890 in the last Membership Query message the relay sent to the gateway 1891 endpoint address of the tunnel to be torn down. The gateway endpoint 1892 address is provided by the Gateway IP Address and Gateway Port Number 1893 fields carried by the Membership Query message. This value must 1894 match that used by the relay to compute the value stored in the 1895 Response MAC field. 1897 5.1.7.6. Gateway Port Number 1899 A 16-bit UDP port number that, when combined with the value contained 1900 in the Gateway IP Address field, forms the tunnel endpoint address 1901 that the relay will use to identify the tunnel instance to tear down. 1902 The relay provides this value to the gateway using the Gateway Port 1903 Number field (Section 5.1.4.9.1) in a Membership Query message. This 1904 port number must match that used by the relay to compute the value 1905 stored in the Response MAC field. 1907 5.1.7.7. Gateway IP Address 1909 A 16-byte IP address that, when combined with the value contained in 1910 the Gateway Port Number field, forms the tunnel endpoint address that 1911 the relay will used to identify the tunnel instance to tear down. 1912 The relay provides this value to the gateway using the Gateway IP 1913 Address field (Section 5.1.4.9.2) in a Membership Query message. 1915 This field may contain an IPv6 address or an IPv4 address stored as 1916 an IPv4-compatible IPv6 address, where the IPv4 address is prefixed 1917 with 96 bits set to zero (See [RFC4291]). This address must match 1918 that used by the relay to compute the value stored in the Response 1919 MAC field. 1921 5.2. Gateway Operation 1923 The following sections describe gateway implementation requirements. 1924 A non-normative discussion of gateway operation may be found in 1925 Section 4.2. 1927 5.2.1. IP/IGMP/MLD Protocol Requirements 1929 Gateway operation requires a subset of host mode IPv4/IGMP and IPv6/ 1930 MLD functionality to provide group membership tracking, general query 1931 processing, and report generation. A gateway MAY use IGMPv2 (ASM), 1932 IGMPv3 (ASM and SSM), MLDv1 (ASM) or MLDv2 (ASM and SSM). 1934 An application with embedded gateway functionality must provide its 1935 own implementation of this subset of the IPv4/IGMP and IPv6/MLD 1936 protocols. The service interface used to manipulate group membership 1937 state need not match that described in the IGMP and MLD 1938 specifications, but the actions taken as a result SHOULD be similar 1939 to those described in Section 5.1 of [RFC3376] and Section 6.1 of 1940 [RFC3810]. The gateway application will likely need to implement 1941 many of the same functions as a host IP stack, including checksum 1942 verification, dispatching, datagram filtering and forwarding, and IP 1943 encapsulation/decapsulation. Applications that use AMT to join 1944 multicast UDP streams may also need to perform IP reassembly to 1945 reconstruct UDP datagrams that were fragmented prior to replication 1946 and encapsulation in the relay. 1948 The IP-encapsulated IGMP/MLD messages generated by the gateway IPv4/ 1949 IGMP or IPv6/MLD implementation MUST conform to the descriptions 1950 found in Section 4 of [RFC3376] and Section 5 of [RFC3810]. These 1951 datagrams MUST possess the IP headers, header options and header 1952 values called for in these RFCs, with the following exception; the 1953 source IP address for an IGMP/MLD report datagram MAY be set to the 1954 "unspecified" address (all octets are zero ). This exception is made 1955 because the gateway pseudo-interface might not possess an address, 1956 and even if such an address exists, that address would not be a valid 1957 source address on any relay interface. To allow for this exception, 1958 a relay must accept an IGMP or MLD report carried by a Membership 1959 Update message regardless of the source address it carries. See 1960 Section 5.3.1. 1962 The gateway IGMP/MLD implementation SHOULD retransmit unsolicited 1963 membership state-change reports and merge new state change reports 1964 with pending reports as described in Section 5.1 of [RFC3376] and 1965 Section 6.1 of [RFC3810]. The number of retransmissions is specified 1966 by the relay in the Querier's Robustness Variable (QRV) field in the 1967 last general query forwarded by the pseudo-interface. 1969 The gateway IGMP/MLD implementation SHOULD handle general query 1970 messages as described in Section 5.2 of [RFC3376] and Section 6.2 of 1971 [RFC3810], but MAY ignore the Max Resp Code field value and generate 1972 a current state report without any delay. 1974 A gateway IPv4 implementation MUST accept IPv4 datagrams that carry 1975 multicast data or the general query variant of the IGMPv3 Membership 1976 Query message, as described in Section 4 of [RFC3376]. 1978 A gateway IPv6 implementations MUST accept IPv6 datagrams that carry 1979 multicast data or the general query variant of the MLDv2 Multicast 1980 Listener Query message, as described in Section 5 of [RFC3810]. 1982 5.2.2. Pseudo-Interface Configuration 1984 A gateway host may possess or create multiple gateway pseudo- 1985 interfaces, each with a unique configuration that describes a binding 1986 to a specific IP protocol, relay address, relay discovery address or 1987 upstream network interface. 1989 5.2.2.1. Static Relay Address 1991 Before a gateway implementation can execute the AMT protocol to 1992 request and receive multicast traffic, it must be supplied with a 1993 unicast relay address. A gateway implementation may rely on static 1994 address assignment or support some form of dynamic address discovery. 1995 This specification does not require the use of any particular method 1996 to obtain a relay address - an implementation may employ any method 1997 that returns a suitable relay address. 1999 5.2.2.2. Static Relay Discovery Address 2001 If a gateway implementation uses AMT relay discovery to obtain a 2002 relay address, it must first be supplied with a relay discovery 2003 address. The relay discovery address may be an anycast or unicast 2004 address. A gateway implementation may rely on a static address 2005 assignment or some form of dynamic address discovery. This 2006 specification does not require that a gateway implementation use any 2007 particular method to obtain a relay discovery address - an 2008 implementation may employ any method that returns a suitable relay 2009 discovery address. 2011 5.2.2.3. Upstream Interface Selection 2013 A gateway host that possesses multiple network interfaces or 2014 addresses may allow for an explicit selection of the interface to use 2015 when communicating with a relay. The selection might be made to 2016 satisfy connectivity, tunneling or IP protocol requirements. 2018 5.2.2.4. Optional Retransmission Parameters 2020 A gateway implementation that supports retransmission MAY require the 2021 following information: 2023 Discovery Timeout 2024 Initial time to wait for a response to a Relay Discovery message. 2026 Maximum Relay Discovery Retransmission Count 2027 Maximum number of Relay Discovery retransmissions to allow before 2028 terminating relay discovery and reporting an error. 2030 Request Timeout 2031 Initial time to wait for a response to a Request message. 2033 Maximum Request Retransmission Count 2034 Maximum number of Request retransmissions to allow before 2035 abandoning a relay and restarting relay discovery or reporting an 2036 error. 2038 Maximum Retries Count For "Destination Unreachable" 2039 The maximum number of times a gateway should attempt to send the 2040 same Request or Membership Update message after receiving an ICMP 2041 "Destination Unreachable". 2043 5.2.3. Gateway Service 2045 In the following descriptions, a gateway pseudo interface is treated 2046 as a passive entity managed by a gateway service. The gateway 2047 pseudo-interface provides the state and the gateway service provides 2048 the processing. The term "gateway" is used when describing service 2049 behavior with respect to a single pseudo-interface. 2051 5.2.3.1. Startup 2053 When a gateway pseudo-interface is started, the gateway service 2054 begins listening for AMT messages sent to the UDP endpoint(s) 2055 associated with the pseudo-interface and for any locally-generated 2056 IGMP/MLD messages passed to the pseudo-interface. The handling of 2057 these messages is described below. 2059 When the pseudo-interface is enabled, the gateway service MAY: 2061 o Optionally execute the relay discovery procedure described in 2062 Section 5.2.3.4. 2064 o Optionally execute the membership query procedure described in 2065 Section 5.2.3.5 to start the periodic membership update cycle. 2067 5.2.3.2. Handling AMT Messages 2069 A gateway MUST ignore any datagram it receives that cannot be 2070 interpreted as a Relay Advertisement, Membership Query, or Multicast 2071 Data message. The handling of Relay Advertisement, Membership Query, 2072 and Multicast Data messages is addressed in the sections that follow. 2074 While listening for AMT messages, a gateway may be notified that an 2075 ICMP Destination Unreachable message was received as a result of an 2076 AMT message transmission. Handling of ICMP Destination Unreachable 2077 messages is described in Section 5.2.3.9. 2079 5.2.3.3. Handling Multicast Data Messages 2081 A gateway may receive Multicast Data messages after it sends a 2082 Membership Update message to a relay that adds a group subscription. 2083 The gateway may continue to receive Multicast Data messages long 2084 after the gateway sends a Membership Update message that deletes 2085 existing group subscriptions. The gateway MUST be prepared to 2086 receive these messages at any time, but MAY ignore them or discard 2087 their contents if the gateway no longer has any interest in receiving 2088 the multicast datagrams contained within them. 2090 A gateway MUST ignore a Multicast Data message if it fails to satisfy 2091 any of the following requirements: 2093 o The source IP address and UDP port carried by the Multicast Data 2094 message MUST be equal to the destination IP address and UDP port 2095 carried by the matching Membership Update message (i.e., the 2096 current relay address). 2098 o The destination address carried by the encapsulated IP datagram 2099 MUST fall within the multicast address allocation assigned to the 2100 relavent IP protocol, i.e., 224.0.0.0/4 for IPv4 and FF00::/8 for 2101 IPv6. 2103 The gateway extracts the encapsulated IP datagram and forwards it to 2104 the local IP protocol implementation for checksum verification, 2105 fragmented datagram reassembly, source and group filtering, and 2106 transport-layer protocol processing. 2108 5.2.3.4. Relay Discovery Procedure 2110 This section describes gateway requirements related to the relay 2111 discovery message sequence described in Section 4.2.1.1. 2113 5.2.3.4.1. Starting Relay Discovery 2115 A gateway may start or restart the relay discovery procedure in 2116 response to the following events: 2118 o When a gateway pseudo-interface is started (enabled). 2120 o When the gateway wishes to report a group subscription when none 2121 currently exist. 2123 o Before sending the next Request message in a membership update 2124 cycle, i.e. each time the query timer expires (see below). 2126 o After the gateway fails to receive a response to a Request 2127 message. 2129 o After the gateway receives a Membership Query message with the 2130 L-flag set to 1. 2132 5.2.3.4.2. Sending a Relay Discovery Message 2134 A gateway sends a Relay Discovery message to a relay to start the 2135 relay discovery process. 2137 The gateway MUST send the Relay Discovery message using the current 2138 Relay Discovery Address and IANA-assigned UDP port number as the 2139 destination. The Discovery Nonce value in the Relay Discovery 2140 message must be computed as described in Section 5.2.3.4.5. 2142 The gateway MUST save a copy of Relay Discovery message or save the 2143 Discovery Nonce value for possible retransmission and verification of 2144 a Relay Advertisement response. 2146 When a gateway sends a Relay Discovery message, it may be notified 2147 that an ICMP Destination Unreachable message was received as a result 2148 of an earlier AMT message transmission. Handling of ICMP Destination 2149 Unreachable messages is described in Section 5.2.3.9. 2151 5.2.3.4.3. Waiting for a Relay Advertisement Message 2153 A gateway MAY retransmit a Relay Discovery message if it does not 2154 receive a matching Relay Advertisement message within some timeout 2155 period. If the gateway retransmits the message multiple times, the 2156 timeout period SHOULD be adjusted to provide an random exponential 2157 back-off. The RECOMMENDED timeout is a random value in the range 2158 [initial_timeout, MIN(initial_timeout * 2^retry_count, 2159 maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and 2160 a RECOMMENDED maximum_timeout of 120 seconds (which is the 2161 recommended minimum NAT mapping timeout described in [RFC4787]). 2163 5.2.3.4.4. Handling a Relay Advertisement Message 2165 When a gateway receives a Relay Advertisement message it must first 2166 determine whether it should accept or ignore the message. A gateway 2167 MUST ignore a Relay Advertisement message if it fails to satisfy any 2168 of the following requirements: 2170 o The gateway MUST be waiting for a Relay Advertisement message. 2172 o The Discovery Nonce value contained in the Relay Advertisement 2173 message MUST equal to the Discovery Nonce value contained in the 2174 Relay Discovery message. 2176 o The source IP address and UDP port of the Relay Advertisement 2177 message MUST equal to the destination IP address and UDP port of 2178 the matching Relay Discovery message. 2180 Once a gateway receives a Relay Advertisement response to a Relay 2181 Discovery message, it SHOULD ignore any other Relay Advertisements 2182 that arrive on the AMT interface until it sends a new Relay Discovery 2183 message. 2185 If a gateway executes the relay discovery procedure at the start of 2186 each membership update cycle and the relay address returned in the 2187 latest Relay Advertisement message differs from the address returned 2188 in a previous Relay Advertisement message, then the gateway SHOULD 2189 send a Teardown message (if supported) to the old relay address, 2190 using information from the last Membership Query message received 2191 from that relay, as described in Section 5.2.3.7. This behavior is 2192 illustrated in the following diagram. 2194 Gateway Relay-1 2195 ------- ------- 2196 : : 2197 Query Expired | | 2198 Timer (QT)-------->| | 2199 | Relay Discovery | 2200 |------------------->| 2201 | | 2202 | Relay Advertisement| 2203 |<-------------------| 2204 | | 2205 | Request | 2206 |------------------->| 2207 | | 2208 | Membership Query | 2209 |<===================| 2210 Start | | 2211 (QT)<--------| Membership Update | 2212 |===================>| 2213 | | 2214 ~ ~ Relay-2 2215 Expired | | ------- 2216 (QT)-------->| | : 2217 | Relay Discovery | | 2218 |------------------------------------>| 2219 | | | 2220 | Relay Advertisement| | 2221 |<------------------------------------| 2222 | | | 2223 | Teardown | | 2224 |------------------->| | 2225 | | | 2226 | Request | | 2227 |------------------------------------>| 2228 | | | 2229 | Membership Query | | 2230 |<====================================| 2231 Start | | | 2232 (QT)<--------| Membership Update | | 2233 |====================================>| 2234 | | | 2235 : : : 2237 Teardown After Relay Address Change 2239 5.2.3.4.5. Discovery Nonce Generation 2241 The discovery nonce MUST be a random, non-zero, 32-bit value, and if 2242 possible, SHOULD be computed using a cryptographically secure pseudo 2243 random number generator. A new nonce SHOULD be generated each time 2244 the gateway restarts the relay discovery process. The same nonce 2245 SHOULD be used when retransmitting a Relay Discovery message. 2247 5.2.3.5. Membership Query Procedure 2249 This section describes gateway requirements related to the membership 2250 update message sequence described in Section 4.2.1.2. 2252 5.2.3.5.1. Starting the Membership Update Cycle 2254 A gateway may send a Request message to start a membership update 2255 cycle (following the optional relay discovery procedure) in response 2256 to the following events: 2258 o When the gateway pseudo-interface is activated. 2260 o When the gateway wishes to report a group subscription when none 2261 currently exist. 2263 Starting the membership update cycle when a gateway pseudo-interface 2264 is started provides several benefits: 2266 o Better performance by allowing state-change reports to be sent as 2267 they are generated, thus minimizing the time to join. 2269 o More robustness by relying on unsolicited state-change reports to 2270 update group membership state rather than the current-state 2271 reports generated by the membership update cycle. Unsolicited 2272 state-change reports are typically retransmitted multiple times 2273 while current-state reports are not. 2275 o Simplified implementation by eliminating any need to queue IGMP/ 2276 MLD messages for delivery after a Membership Query is received, 2277 since the IGMP/MLD state-change messages may be sent as they are 2278 generated. 2280 However, this approach places an additional load on relays as a 2281 gateway will send periodic requests even when it has no multicast 2282 subscriptions. To reduce load on a relay, a gateway SHOULD only send 2283 a Membership Update message while it has active group subscriptions. 2284 A relay will still need to compute a Response MAC for each Request, 2285 but will not be required to recompute it a second time to 2286 authenticate a Membership Update message that contains no 2287 subscriptions. 2289 5.2.3.5.2. Sending a Request Message 2291 A gateway sends a Request message to a relay to solicit a Membership 2292 Query response and start the membership update cycle. 2294 A gateway constructs a Request message containing a Request Nonce 2295 value computed as described in Section 5.2.3.5.6. The gateway MUST 2296 set the "P" flag in the Request message to identify the protocol the 2297 gateway wishes the relay to use for the general query response. 2299 A gateway MUST send a Request message using the current Relay Address 2300 and IANA-assigned AMT port number as the destination. 2302 A gateway MUST save a copy of the Request message or save the Request 2303 Nonce and P-flag values for possible retransmission and verification 2304 of a Membership Query response. 2306 When a gateway sends a Request message, it may be notified that an 2307 ICMP Destination Unreachable message was received as a result of an 2308 earlier AMT message transmission. Handling of ICMP Destination 2309 Unreachable messages is described in Section 5.2.3.9. 2311 5.2.3.5.3. Waiting for a Membership Query Message 2313 A gateway MAY retransmit a Request message if it does not receive a 2314 matching Membership Query message within some timeout period. If the 2315 gateway retransmits the message multiple times, the timeout period 2316 SHOULD be adjusted to provide an random exponential back-off. The 2317 RECOMMENDED timeout is a random value in the range [initial_timeout, 2318 MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a 2319 RECOMMENDED initial_timeout of 1 second and a RECOMMENDED 2320 maximum_timeout of 120 seconds (which is the recommended minimum NAT 2321 mapping timeout described in [RFC4787]). 2323 If a gateway that uses relay discovery does not receive a Membership 2324 Query within a specified time period or after a specified number of 2325 retries, the gateway SHOULD stop waiting for a Membership Query 2326 message and restart relay discovery to locate another relay. 2328 5.2.3.5.4. Handling a Membership Query Message 2330 When a gateway receives a Membership Query message it must first 2331 determine whether it should accept or ignore the message. A gateway 2332 MUST ignore a Membership Query message, or the encapsulated IP 2333 datagram within it, if the message fails to satisfy any of the 2334 following requirements: 2336 o The gateway MUST be waiting for a Membership Query message. 2338 o The Request Nonce value contained in the Membership Query MUST 2339 equal the Request Nonce value contained in the Request message. 2341 o The source IP address and UDP port of the Membership Query MUST 2342 equal the destination IP address and UDP port of the matching 2343 Request message (i.e. the current relay address). 2345 o The encapsulated IP datagram MUST carry an IGMPv3 or MLDv2 2346 message. The protocol MUST match the protocol identified by the 2347 "P" flag in the Request message. 2349 o The IGMPv3 or MLDv2 message MUST be a general query message. 2351 o The total length of the encapsulated IP datagram as computed from 2352 the lengths contained in the datagram header(s) MUST NOT exceed 2353 the available field length within the Membership Query message. 2355 Once a gateway receives a Membership Query response to a Request 2356 message, it SHOULD ignore any other Membership Query messages that 2357 arrive on the AMT interface until it sends a new Request message. 2359 The gateway MUST save the Membership Query message, or the Request 2360 Nonce, Response MAC, Gateway IP Address and Gateway Port Number 2361 fields for use in sending subsequent Membership Update and Teardown 2362 messages. 2364 The gateway extracts the encapsulated IP datagram and forwards it to 2365 the local IP protocol implementation for checksum verification and 2366 dispatching to the IGMP or MLD implementation running on the pseudo- 2367 interface. The gateway MUST NOT forward any octets that might exist 2368 between the encapsulated IP datagram and the end of the message or 2369 Gateway Address fields. 2371 An MLD datagram contained in a Membership Query message may require 2372 special handling. The encapsulated query generated by a relay will 2373 likely carry an unspecified or relay link-local source address. If a 2374 gateway relies on a standard host-mode MLD protocol implementation to 2375 process the query, that implementation will silently ignore the MLD 2376 query because it carries an unspecified or non-link-local source 2377 address - a gateway may need to construct its own query with a valid 2378 link-local address (e.g., a spoofed address in a virtual subnet 2379 defined by the address and netmask assigned to the gateway pseudo- 2380 interface) to ensure that the report will not be ignored by the MLD 2381 protocol implementation. 2383 The gateway must start a timer that will trigger the next iteration 2384 of the membership update cycle by executing the membership query 2385 procedure. The gateway SHOULD compute the timer duration from the 2386 Querier's Query Interval Code carried by the general-query. A 2387 gateway MAY use a smaller timer duration if required to refresh a NAT 2388 mapping that would otherwise timeout. A gateway MAY use a larger 2389 timer duration if it has no group subscriptions to report. 2391 If the gateway supports the Teardown message and the G-flag is set in 2392 the Membership Query message, the gateway MUST compare the Gateway IP 2393 Address and Gateway Port Number on the new Membership Query message 2394 with the values carried by the previous Membership Query message. If 2395 either value has changed the gateway MUST send a Teardown message to 2396 the relay as described in Section 5.2.3.7. 2398 If the L-flag is set in the Membership Query message, the relay is 2399 reporting that it is NOT accepting Membership Update messages that 2400 create new tunnel endpoints and will simply ignore any that do. If 2401 the L-flag is set and the gateway is not currently reporting any 2402 group subscriptions to the relay, the gateway SHOULD stop sending 2403 periodic Request messages and restart the relay discovery procedure 2404 (if discovery is enabled) to find a new relay with which to 2405 communicate. The gateway MAY continue to send updates even if the 2406 L-flag is set, if it has previously reported group subscriptions to 2407 the relay, one or more subscriptions still exist and the gateway 2408 endpoint address has not changed since the last Membership Query was 2409 received (see previous paragraph). 2411 5.2.3.5.5. Handling Query Timer Expiration 2413 When the query timer (started in the previous step) expires, the 2414 gateway should execute the membership query procedure again to 2415 continue the membership update cycle. 2417 5.2.3.5.6. Request Nonce Generation 2419 The request nonce MUST be a random value, and if possible, SHOULD be 2420 computed using a cryptographically secure pseudo random number 2421 generator. A new nonce MUST be generated each time the gateway 2422 starts the membership query process. The same nonce SHOULD be used 2423 when retransmitting a Request message. 2425 5.2.3.6. Membership Update Procedure 2427 This section describes gateway requirements related to the membership 2428 update message sequence described in Section 4.2.1.2. 2430 The membership update process is primarily driven by the host-mode 2431 IGMP or MLD protocol implementation running on the gateway pseudo- 2432 interface. The IGMP and MLD protocols produce current-state reports 2433 in response to general queries generated by the pseudo-interface via 2434 AMT and produce state-change reports in response to receiver requests 2435 made using the IGMP or MLD service interface. 2437 5.2.3.6.1. Handling an IGMP/MLD IP Datagram 2439 The gateway pseudo-interface MUST accept the following IP datagrams 2440 from the IPv4/IGMP and IPv6/MLD protocols running on the pseudo- 2441 interface: 2443 o IPv4 datagrams that carry an IGMPv2, or IGMPv3 Membership Report 2444 or an IGMPv2 Leave Group message as described in Section 4 of 2445 [RFC3376]. 2447 o IPv6 datagrams that carry an MLDv1 or MLDv2 Multicast Listener 2448 Report or an MLDv1 Multicast Listener Done message as described in 2449 Section 5 of [RFC3810]. 2451 The gateway must be prepared to receive these messages any time the 2452 pseudo-interface is running. The gateway MUST ignore any datagrams 2453 not listed above. 2455 A gateway that waits to start a membership update cycle until after 2456 it receives an IGMP/MLD state-change message MAY: 2458 o Discard datagrams containing IGMP/MLD messages until it receives a 2459 Membership Query message, at which time it processes the 2460 Membership Query message as normal to eventually produce a 2461 current-state report on the pseudo-interface which describes the 2462 end state (RECOMMENDED). 2464 o Insert IGMP/MLD messages into a queue for transmission after it 2465 receives a Membership Query message. 2467 If the datagram contains a valid IGMP or MLD message, the gateway 2468 sends it to the relay as described in the next section. 2470 5.2.3.6.2. Sending a Membership Update Message 2472 A gateway cannot send a Membership Update message to a relay until it 2473 has received a Membership Query message from a relay. If the gateway 2474 has not yet located a relay with which to communicate, it must first 2475 execute the relay discovery procedure described in Section 5.2.3.4 to 2476 obtain a relay address. If the gateway has a relay address, but has 2477 not yet received a Membership Query message, it must first execute 2478 the membership query procedure described in Section 5.2.3.5 to obtain 2479 a Request Nonce and Response MAC that can be used to send a 2480 Membership Update message. 2482 Once a gateway possesses a valid Relay Address, Request Nonce and 2483 Response MAC, it may encapsulate the IP datagram containing the IGMP/ 2484 MLD message into a Membership Update message. The gateway MUST copy 2485 the Request Nonce and Response MAC values from the last Membership 2486 Query received from the relay into the corresponding fields in the 2487 Membership Update. The gateway MUST send the Membership Update 2488 message using the Relay Address and IANA-assigned AMT port number as 2489 the destination. 2491 When a gateway sends a Membership Update message, it may be notified 2492 that an ICMP Destination Unreachable message was received as a result 2493 of an earlier AMT message transmission. Handling of ICMP Destination 2494 Unreachable messages is described in Section 5.2.3.9. 2496 5.2.3.7. Teardown Procedure 2498 This section describes gateway requirements related to the teardown 2499 message sequence described in Section 4.2.1.3. 2501 Gateway support for the Teardown message is OPTIONAL but RECOMMENDED. 2503 A gateway that supports Teardown SHOULD make use of Teardown 2504 functionality if it receives a Membership Query message from a relay 2505 that has the "G" flag set to indicate that it contains valid gateway 2506 address fields. 2508 5.2.3.7.1. Handling a Membership Query Message 2510 As described in Section 5.2.3.5.4, if a gateway supports the Teardown 2511 message, has reported active group subscriptions, and receives a 2512 Membership Query message with the "G" flag set, the gateway MUST 2513 compare the Gateway IP Address and Gateway Port Number on the new 2514 Membership Query message with the values carried by the previous 2515 Membership Query message. If either value has changed the gateway 2516 MUST send a Teardown message as described in the next section. 2518 5.2.3.7.2. Sending a Teardown Message 2520 A gateway sends a Teardown message to a relay to request that it stop 2521 delivering Multicast Data messages to the gateway and delete any 2522 group memberships created by the gateway. 2524 When a gateway constructs a Teardown message, it MUST copy the 2525 Request Nonce, Response MAC, Gateway IP Address and Gateway Port 2526 Number fields from the Membership Query message that provided the 2527 Response MAC for the last Membership Update message sent, into the 2528 corresponding fields of the Teardown message. 2530 A gateway MUST send the Teardown message using the Relay Address and 2531 IANA-assigned AMT port number as the destination. A gateway MAY send 2532 the the Teardown message multiple times for robustness. The gateway 2533 SHOULD use the Querier's Robustness Variable (QRV) field contained in 2534 the query encapsulated within the last Membership Query to set the 2535 limit on the number of retransmissions. If the gateway sends the 2536 Teardown message multiple times, it SHOULD insert a delay between 2537 each transmission using the timing algorithm employed in IGMP/MLD for 2538 transmitting unsolicited state-change reports. 2540 When a gateway sends a Teardown message, it may be notified that an 2541 ICMP Destination Unreachable message was received as a result of an 2542 earlier AMT message transmission. Handling of ICMP Destination 2543 Unreachable messages is described in Section 5.2.3.9. 2545 5.2.3.8. Shutdown 2547 When a gateway pseudo-interface is stopped and the gateway has 2548 existing group subscriptions, the gateway SHOULD either: 2550 o Send a Teardown message to the relay as described in 2551 Section 5.2.3.7, but only if the gateway supports the Teardown 2552 message, and the current relay is returning gateway address fields 2553 in Membership Query messages, or 2555 o Send a Membership Update message to the relay that will delete 2556 existing group subscriptions. 2558 5.2.3.9. Handling ICMP Destination Unreachable Responses 2560 A gateway may receive an ICMP "Destination Unreachable" message 2561 [RFC0792] after sending an AMT message. Whether the gateway is 2562 notified that an ICMP message was received is highly dependent the 2563 gateway IP stack behavior and gateway implementation. 2565 If the reception of an ICMP Destination Unreachable message is 2566 reported to the gateway while waiting to receive an AMT message, the 2567 gateway may respond as follows, depending on platform capabilities 2568 and which outgoing message triggered the ICMP response: 2570 1. The gateway MAY simply abandon the current relay and restart 2571 relay discovery (if used). This is the least desirable approach 2572 as it does not allow for transient network changes. 2574 2. If the last message sent was a Relay Discovery or Request 2575 message, the gateway MAY simply ignore the ICMP response and 2576 continue waiting for incoming AMT messages. If the gateway is 2577 configured to retransmit Relay Discovery or Request messages, the 2578 normal retransmission behavior for those messages is preserved to 2579 prevent the gateway from prematurely abandoning a relay. 2581 3. If the last message sent was a Membership Update message, the 2582 gateway MAY start a new membership update and associated Request 2583 retransmission cycle. 2585 If the reception of an ICMP Destination Unreachable message is 2586 reported to the gateway when attempting to transmit a new AMT 2587 message, the gateway may respond as follows, depending on platform 2588 capabilities and which outgoing message triggered the ICMP response: 2590 1. The gateway MAY simply abandon the current relay and restart 2591 relay discovery (if used). This is the least desirable approach 2592 as it does not allow for transient network changes. 2594 2. If the last message sent was a Relay Discovery, Request or 2595 Teardown message, the gateway MAY attempt to transmit the new 2596 message. If the gateway is configured to retransmit Relay 2597 Discovery, Request or Teardown messages, the normal 2598 retransmission behavior for those messages is preserved to 2599 prevent the gateway from prematurely abandoning a relay. 2601 3. If the last message sent was a Membership Update message, the 2602 gateway SHOULD start a new membership update and associated 2603 Request retransmission cycle. 2605 5.3. Relay Operation 2607 The following sections describe relay implementation requirements. A 2608 non-normative discussion of relay operation may be found in 2609 Section 4.2. 2611 5.3.1. IP/IGMP/MLD Protocol Requirements 2613 A relay requires a subset of router-mode IGMP and MLD functionality 2614 to provide group membership tracking and report processing. 2616 A relay accessible via IPv4 MUST support IPv4/IGMPv3 and MAY support 2617 IPv6/MLDv2. A relay accessible via IPv6 MUST support IPv6/MLDv2 and 2618 MAY support IPv4/IGMPv3. 2620 A relay MUST apply the forwarding rules described in Section 6.3 of 2621 [RFC3376] and Section 7.3 of [RFC3810]. 2623 A relay MUST handle incoming reports as described ,Section 6.4 of 2625 [RFC3376] and Section 7.4 of [RFC3810] with the exception that 2626 actions that lead to queries MAY be modified to eliminate query 2627 generation. 2629 All other aspects of IGMP/MLD router behavior, such as the handling 2630 of queries, querier election, etc., are not used or required for 2631 relay operation. 2633 5.3.2. Startup 2635 If a relay is deployed for anycast discovery, the relay MUST 2636 advertise an anycast Relay Discovery Address Prefix into the unicast 2637 routing system of the anycast domain. An address within that prefix, 2638 i.e., a Relay Discovery Address, MUST be assigned to a relay 2639 interface. 2641 A unicast IPv4 and/or IPv6 address MUST be assigned to the relay 2642 interface that will be used to send and receive AMT control and data 2643 messages. This address or addresses are returned in Relay 2644 Advertisement messages. 2646 The remaining details of relay "startup" are highly implementation- 2647 dependent and are not addressed in this document. 2649 5.3.3. Running 2651 When a relay is started, it begins listening for AMT messages on the 2652 interface to which the unicast Relay Address(es) has been assigned, 2653 i.e., the address returned in Relay Advertisement messages. 2655 5.3.3.1. Handling AMT Messages 2657 A relay MUST ignore any message other than a Relay Discovery, 2658 Request, Membership Update or Teardown message. The handling of 2659 Relay Discovery, Request, Membership Update, and Teardown messages is 2660 addressed in the sections that follow. 2662 Support for the Teardown message is OPTIONAL. If a relay does not 2663 support the Teardown message, it MUST also ignore this message. 2665 A relay that conforms to this specification MUST ignore any message 2666 with a Version field value other than zero. 2668 5.3.3.2. Handling a Relay Discovery Message 2670 This section describes relay requirements related to the relay 2671 discovery message sequence described in Section 4.2.1.1. 2673 A relay MUST accept and respond to Relay Discovery messages sent to 2674 an anycast relay discovery address or the unicast relay address. If 2675 a relay receives a Relay Discovery message sent to its unicast 2676 address, it must respond just as it would if the message had been 2677 sent to its anycast discovery address. 2679 When a relay receives a Relay Discovery message it responds by 2680 sending a Relay Advertisement message back to the source of the Relay 2681 Discovery message. The relay MUST use the source IP address and UDP 2682 port of the Relay Discovery message as the destination IP address and 2683 UDP port. The relay MUST use the destination IP address and UDP port 2684 of the Relay Discovery as the source IP address and UDP port to 2685 ensure successful NAT traversal. 2687 The relay MUST copy the value contained in the Discovery Nonce field 2688 of the Relay Discovery message into the Discovery Nonce field in the 2689 the Relay Advertisement message. 2691 If the Relay Discovery message was received as an IPv4 datagram, the 2692 relay MUST return an IPv4 address in the Relay Address field of the 2693 Relay Advertisement message. If the Relay Discovery message was 2694 received as an IPv6 datagram, the relay may return an IPv4 or IPv6 2695 address in the Relay Address field. 2697 5.3.3.3. Handling a Request Message 2699 This section describes relay requirements related to the membership 2700 query portion of the message sequence described in Section 4.2.1.2. 2702 When a relay receives a Request message it responds by sending a 2703 Membership Query message back to the source of the Request message. 2705 The relay MUST use the source IP address and UDP port of the Request 2706 message as the destination IP address and UDP port for the Membership 2707 Query message. The source IP address and UDP port carried by the 2708 Membership Query MUST match the destination IP address and UDP port 2709 of the Request to ensure successful NAT traversal. 2711 The relay MUST return the value contained in the Request Nonce field 2712 of the Request message in the Request Nonce field of the Membership 2713 Query message. The relay MUST compute a MAC value, as described in 2714 Section 5.3.5, and return that value in the Response MAC field of the 2715 Membership Query message. 2717 If a relay supports the Teardown message, it MUST set the G-flag in 2718 the Membership Query message and return the source IP address and UDP 2719 port carried by the Request message in the corresponding Gateway IP 2720 Address and Gateway Port Number fields. If the relay does not 2721 support the Teardown message it SHOULD NOT set these fields as this 2722 may cause the gateway to generate unnecessary Teardown messages. 2724 If the P-flag in the Request message is 0, the relay MUST return an 2725 IPv4-encapsulated IGMPv3 general query in the Membership Query 2726 message. If the P-flag is 1, the relay MUST return an IPv6- 2727 encapsulated MLDv2 general query in the Membership Query message. 2729 If the relay is not accepting Membership Update messages that create 2730 new tunnel endpoints due to resource limitations, it SHOULD set the 2731 L-flag in the Membership Query message to notify the gateway of this 2732 state. Support for the L-flag is OPTIONAL. See Section 5.3.3.8. 2734 The IGMPv3/MLDv2 general query datagram that a relay encapsulates 2735 within a Membership Query message MUST conform to the descriptions 2736 found in Section 4.1 of [RFC3376] and Section 5.1 of [RFC3810]. 2737 These datagrams MUST possess the IP headers, header options and 2738 header values called for in these RFCs, with the following exception; 2739 the source IP address for an IGMP/MLD general query datagram MAY be 2740 set to the "unspecified" address (all octets are zero). This 2741 exception is made because any address that a relay might use will not 2742 be a valid source address on any gateway interface. To allow for 2743 this exception, gateways must accept an IGMP or MLD query regardless 2744 of the source address it carries. See Section 5.2.1. 2746 A relay MUST set the Querier's Query Interval Code (QQIC) field in 2747 the general query to supply the gateway with a suggested time 2748 duration to use for the membership query timer. The QQIC field is 2749 defined in Section 4.1.1 in [RFC3376] and Section 5.1.3 in [RFC3810]. 2750 A relay MAY adjust this value to affect the rate at which the Request 2751 messages are sent from a gateway. However, a gateway is allowed to 2752 use a shorter duration than specified in the QQIC field, so a relay 2753 may be limited in its ability to spread out Requests coming from a 2754 gateway. 2756 A relay MUST set the Querier's Robustness Variable (QRV) field in the 2757 general query to a non-zero value. This value SHOULD be greater than 2758 one. If a gateway retransmits a membership state change messages, it 2759 will retransmit them (robustness variable - 1) times. 2761 A relay SHOULD set the Max Resp Code field in the general query to a 2762 value of 1 to trigger an immediate response from the gateway (some 2763 host IGMP/MLD implementations may not accept a value of zero). A 2764 relay SHOULD NOT use the IGMPv2/MLDv2 Query Response Interval 2765 variable, if available, to generate the Max Resp Code field value as 2766 the Query Response Interval variable is used in setting the duration 2767 of group state timers and must not be set to such a small value. See 2768 Section 5.3.3.7. 2770 5.3.3.4. Handling a Membership Update Message 2772 This section describes relay requirements related to the membership 2773 update portion of the message sequence described in Section 4.2.1.2. 2775 When a relay receives a Membership Update message it must first 2776 determine whether it should accept or ignore the message. A relay 2777 MUST NOT make any changes to group membership and forwarding state if 2778 the message fails to satisfy any of the following requirements: 2780 o The IP datagram encapsulated within the message MUST be one of the 2781 following: 2783 * IPv4 datagram carrying an IGMPv2 or IGMPv3 Membership Report 2784 message. 2786 * IPv4 datagram carrying an IGMPv2 Leave Group message. 2788 * IPv6 datagram carrying an MLDv1 or MLDv2 Multicast Listener 2789 Report message. 2791 * IPv6 datagram carrying MLDv1 Multicast Listener Done message. 2793 o The encapsulated IP datagram MUST satisfy the IP header 2794 requirements for the IGMP or MLD message type as described in 2795 Section 4 of [RFC3376], Section 2 of [RFC2236], Section 5 of 2796 [RFC3810], Section 3 of [RFC2710]. 2798 o The total length of the encapsulated IP datagram as computed from 2799 the lengths contained in the datagram header(s) MUST NOT exceed 2800 the available field length within the Membership Update message. 2802 o The computed checksums for the encapsulated IP datagram and its 2803 payload MUST match the values contained therein. Checksum 2804 computation and verification varies by protocol; See [RFC0791] for 2805 IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6). 2807 o If processing of the encapsulated IGMP or MLD message would result 2808 in an allocation of new state or a modification of existing state, 2809 the relay MUST authenticate the source of the Membership message 2810 by verifying that the value contained in the Response MAC field 2811 equals the MAC value computed from the fields in the Membership 2812 Update message datagram. Because the private secret used to 2813 compute Response MAC values may change over time, the relay MUST 2814 retain the previous version of the private secret to use in 2815 authenticating Membership Updates sent during the subsequent query 2816 interval. If the first attempt at Response MAC authentication 2817 fails, the relay MUST attempt to authenticate the Response MAC 2818 using the previous private secret value unless 2*query_interval 2819 time has elapsed since the private secret change. See 2820 Section 5.3.5. An alternative approach to Response MAC generation 2821 that avoids repeated Response MAC computations may be found in 2822 Appendix A.1. 2824 A relay MAY skip source authentication to reduce the computational 2825 cost of handling Membership Update messages if the relay can make a 2826 trivial determination that the IGMP/MLD message carried by the 2827 Membership Update message will produce no changes in group membership 2828 or forwarding state. The relay does not need to compute and compare 2829 MAC values if it finds there are no group subscriptions for the 2830 source of the Membership Update message and either of the following 2831 is true: 2833 o The encapsulated IP datagram is an IGMPv3 Membership Report or 2834 MLDv2 Multicast Listener Report message that contains no group 2835 records. This may often be the case for gateways that 2836 continuously repeat the membership update cycle even though they 2837 have no group subscriptions to report. 2839 o The encapsulated IP datagram is an IGMPv2 Leave Group or MLDv1 2840 Multicast Listener Done message. 2842 An MLD datagram contained in a Membership Update message may require 2843 special handling. The encapsulated datagram generated by a gateway 2844 will likely carry an unspecified or link-local source address. If 2845 the relay relies on a standard router-mode MLD protocol 2846 implementation to process these reports, that implementation may 2847 silently ignore the MLD report because it carries an unspecified or 2848 non-link-local source address - a relay may need to use the contents 2849 of the encapsulated datagram to construct a new datagram with a valid 2850 link-local source address (e.g., a spoofed address in a virtual 2851 subnet defined by the address and netmask assigned to the relay 2852 pseudo-interface) to ensure that the report will not be ignored by 2853 the MLD protocol implementation. 2855 Once a relay has determined that the Membership Update message is 2856 valid, it processes the encapsulated IGMP or MLD membership message 2857 to update group membership state and communicates with the multicast 2858 protocol to update forwarding state and possibly send multicast 2859 protocol messages towards upstream routers. The relay MUST ignore 2860 any octets that might exist between the encapsulated IP datagram and 2861 the end of the Membership Update message. 2863 As described in Section 4.2.2, a relay uses the source IP address and 2864 source UDP port carried by a Membership Update messages to identify a 2865 tunnel endpoint. A relay uses the tunnel endpoint as the destination 2866 address for any Multicast Data messages it sends as a result of the 2867 group membership and forwarding state created by processing the IGMP/ 2868 MLD messages contained in Membership Update messages received from 2869 the endpoint. 2871 If a Membership Update message originates from a new endpoint, the 2872 relay MUST determine whether it can accept updates from a new 2873 endpoint. If a relay has been configured with a limit on the total 2874 number of endpoints, or a limit on the total number of endpoints for 2875 a given source address, then the relay MAY ignore the Membership 2876 Update message and possibly withdraw any Relay Discovery Address 2877 Prefix announcement that it might have made. See Section 5.3.3.8. 2879 A relay MUST maintain some form of group membership database for each 2880 endpoint. The per-endpoint databases are used update a forwarding 2881 table containing entries that map an (*,G) or (S,G) subscription to a 2882 list of tunnel endpoints. 2884 A relay MUST maintain some form group membership database 2885 representing a merger of the group membership databases of all 2886 endpoints. The merged group membership database is used to update 2887 upstream multicast forwarding state. 2889 A relay MUST maintain a forwarding table that maps each unique (*,G) 2890 and (S,G) subscription to a list of tunnel endpoints. A relay uses 2891 this forwarding table to provide the destination address when 2892 performing UDP/IP encapsulation of the incoming multicast IP 2893 datagrams to form Multicast Data messages. 2895 If a group filter mode for a group entry on a tunnel endpoint is 2896 EXCLUDE, the relay SHOULD NOT forward datagrams that originate from 2897 sources in the filter source list unless the relay architecture does 2898 not readily support source filtering. A relay MAY ignore the source 2899 list if necessary because gateways are expected to do their own 2900 source filtering. 2902 5.3.3.5. Handling a Teardown Message 2904 This section describes relay requirements related to the teardown 2905 message sequence described in Section 4.2.1.3. 2907 When a relay (that supports the Teardown message) receives a Teardown 2908 message, it MUST first authenticate the source of the Teardown 2909 message by verifying that the Response MAC carried by the Teardown 2910 message is equal to a MAC value computed from the fields carried by 2911 the Teardown message. The method used to compute the MAC differs 2912 from that used to generate and validate the Membership Query and 2913 Membership Update messages in that the source IP address and source 2914 UDP port number used to compute the MAC are taken from the Gateway IP 2915 Address and Gateway Port Number field in the Teardown message rather 2916 than from the IP and UDP headers in the datagram that carries the 2917 Teardown message. The MAC computation is described Section 5.3.5. A 2918 relay MUST ignore a Teardown message If the computed MAC does not 2919 equal the value of the Response MAC field. 2921 If a relay determines that a Teardown message is authentic, it MUST 2922 immediately stop transmitting Multicast Data messages to the endpoint 2923 identified by the Gateway IP Address and Gateway Port Number fields 2924 in the message. The relay MUST eventually delete any group 2925 membership and forwarding state associated with the endpoint, but MAY 2926 delay doing so to allow a gateway to recreate group membership state 2927 on a new endpoint and thereby avoid making unnecessary (temporary) 2928 changes in upstream routing/forwarding state. 2930 The state changes made by a relay when processing a Teardown message 2931 MUST be identical to those that would be made as if the relay had 2932 received an IGMP/MLD report that would cause the IGMP or MLD protocol 2933 to delete all existing group records in the group membership database 2934 associated with the endpoint. The processing of the Teardown message 2935 should trigger or mimic the normal interaction between IGMP or MLD 2936 and a multicast protocol to produce required changes in forwarding 2937 state and possibly send prune/leave messages towards upstream 2938 routers. 2940 5.3.3.6. Handling Multicast IP Datagrams 2942 When a multicast IP datagram is forwarded to the relay pseudo- 2943 interface, the relay MUST, for each gateway that has expressed an 2944 interest in receiving the datagram, encapsulate the IP datagram into 2945 a Multicast Data message and send that message to the gateway. This 2946 process is highly implementation dependent, but conceptually requires 2947 the follow steps: 2949 o Use the IP datagram source and destination address to look up the 2950 appropriate (*,G) or (S,G) entry in the endpoint forwarding table 2951 created for the pseudo-interface as a result of IGMP/MLD 2952 processing. 2954 o Possibly replicate the datagram for each gateway endpoint listed 2955 for that (*,G) or (S,G) entry. 2957 o Encapsulate the IP datagram in a UDP/IP Membership Data message, 2958 using the endpoint UDP/IP address as the destination address and 2959 the unicast relay address and IANA-assigned port as the source 2960 UDP/IP address. To ensure successful NAT traversal, the source 2961 address and port MUST match the destination address and port 2962 carried by the Membership Update message sent by the gateway to 2963 create the forwarding table entry. 2965 o Send the message to the gateway. 2967 The relay pseudo-interface MUST ignore any other IP datagrams 2968 forwarded to the pseudo-interface. 2970 5.3.3.7. State Timers 2972 A relay MUST maintain a timer or timers whose expiration will trigger 2973 the removal of any group subscriptions and forwarding state 2974 previously created for a gateway endpoint should the gateway fail to 2975 refresh the group membership state within a specified time interval. 2977 A relay MAY use a variant of the IGMPv3/MLDv2 state management 2978 protocol described in Section 6 of [RFC3376] or Section 7 of 2979 [RFC3810], or may maintain a per-endpoint timer to trigger the 2980 deletion of group membership state. 2982 If a per-endpoint timer is used, the relay MUST restart this timer 2983 each time it receives a new Membership Update message from the 2984 gateway endpoint. 2986 The RECOMMENDED endpoint timer duration MAY be computed from tunable 2987 IGMP/MLD variables as follows: 2989 ((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval 2991 If IGMP/MLD default values are used for these variables, the gateway 2992 will timeout after 125s * 2 + 10s = 260s. The timer duration MUST be 2993 greater than the query interval suggested in the last Membership 2994 Query message sent to the gateway endpoint. 2996 Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the 2997 Query_Response_Interval value SHOULD be greater than or equal to 10s 2998 to allow for packet loss and round-trip time in the Request/ 2999 Membership Query message exchange. 3001 5.3.3.8. Relay Resource Management 3003 A relay may be configured with various service limits to ensure a 3004 minimum level of performance for gateways that connect to it. 3006 If a relay has determined that it has reached or exceeded maximum 3007 allowable capacity or has otherwise exhausted resources required to 3008 support additional gateways, it SHOULD withdraw any Relay Discovery 3009 Address Prefix it has advertised into the unicast internetwork and 3010 SHOULD set the L-flag in any Membership Query messages it returns to 3011 gateways while in this state. 3013 If the relay receives an update from a gateway that adds group 3014 membership or forwarding state for an endpoint that has already 3015 reached maximum allowable state entries, the relay SHOULD continue to 3016 accept updates from the gateway but ignore any group membership/ 3017 forwarding state additions requested by that gateway. 3019 If the relay receives an update from a gateway that would create a 3020 new tunnel endpoint for a source IP address that has already reach 3021 maximum allowable number of endpoints (maximum UDP ports), it should 3022 simply ignore the Membership Update. 3024 5.3.4. Shutdown 3026 The following steps should be treated as an abstract description of 3027 the shutdown procedure for a relay: 3029 o Withdraw the Relay Discovery Address Prefix advertisement (if 3030 used). 3032 o Stop listening for Relay Discovery messages. 3034 o Stop listening for control messages from gateways. 3036 o Stop sending data messages to gateways. 3038 o Delete all AMT group membership and forwarding state created on 3039 the relay, coordinating with the multicast routing protocol to 3040 update the group membership state on upstream interfaces as 3041 required. 3043 5.3.5. Response MAC Generation 3045 A Response MAC is produced by a hash digest computation. A Response 3046 MAC value is computed from a Request message for inclusion in a 3047 Membership Query message, is computed from a Membership Update 3048 message to authenticate the Response MAC carried within that message, 3049 and is computed from fields in a Teardown message to authenticate the 3050 Response MAC carried within that message. 3052 Gateways treat the Response MAC field as an opaque value, so a relay 3053 implementation may generate the MAC using any method available to it. 3054 The hash function RECOMMENDED for use in computing the Response MAC 3055 is the MD5 hash digest [RFC1321], though hash functions or keyed-hash 3056 functions of greater cryptographic strength may be used. 3058 The digest MUST be computed over the following values: 3060 o The Source IP address of the message (or Teardown Gateway IP 3061 Address field) 3063 o The Source UDP port of the message (or Teardown Gateway Port 3064 Number field) 3066 o The Request Nonce contained in the message. 3068 o A private secret known only to the relay 3070 An Response MAC generation solution that satisfies these requirements 3071 is described in Appendix A.1. 3073 5.3.6. Private Secret Generation 3075 The private secret, or hash-key, is a random value that the relay 3076 includes in the Response MAC hash digest computation. A relay SHOULD 3077 periodically compute a new private secret. The RECOMMENDED maximum 3078 interval is 2 hours. A relay MUST retain the prior secret for use in 3079 verifying MAC values that were sent to gateways just prior to the use 3080 of the new secret. 3082 The private secret SHOULD be computed using a cryptographically- 3083 secure pseudo-random number generator. The private secret width 3084 SHOULD equal that of the hash function used to compute the Response 3085 MAC, e.g., 128-bits for an MD5 hash. 3087 6. Security Considerations 3089 AMT is not intended to be a strongly secured protocol. In general, 3090 the protocol provides the same level of security and robustness as is 3091 provided by the UDP, IGMP and MLD protocols on which it relies. The 3092 lack of strong security features can largely be attributed to the 3093 desire to make the protocol light-weight by minimizing the state and 3094 computation required to service a single gateway, thereby allowing a 3095 relay to service a larger number of gateways. 3097 Many of the threats and vectors described in [RFC3552] may be 3098 employed against the protocol to launch various types of denial-of- 3099 service attacks that can affect the functioning of gateways or their 3100 ability to locate and communicate with a relay. These scenarios are 3101 described below. 3103 As is the case for UDP, IGMP and MLD, the AMT protocol provides no 3104 mechanisms for ensuring message delivery or integrity. The protocol 3105 does not provide confidentiality - multicast groups, sources and 3106 streams requested by a gateway are sent in the clear. 3108 The protocol does use a three-way handshake to provide trivial source 3109 authentication for state allocation and updates (see below). The 3110 protocol also requires gateways and relays to ignore malformed 3111 messages and those messages that do not carry expected address values 3112 or protocol payload types or content. 3114 6.1. Relays 3116 The three-way handshake provided by the membership update message 3117 sequence (See (Section 4.2.1.2)) provides a defense against source- 3118 spoofing-based resource-exhaustion attacks on a relay by requiring 3119 source authentication before state allocation. However, attackers 3120 may still attempt to flood a relay with Request and Membership Update 3121 messages to force the relay to make the hash computations in an 3122 effort to consume computational resources. Implementations may 3123 choose to limit the frequency with which a relay responds to Request 3124 messages sent from a single IP address or IP address and UDP port 3125 pair, but support for this functionality is not required. The three- 3126 way handshake provides no defense against an eavesdropping or man-in- 3127 the-middle attacker. 3129 Attackers that execute the gateway protocol may consume relay 3130 resources by instantiating a large number of tunnels or joining a 3131 large number of multicast streams. A relay implementation should 3132 provide a mechanism for limiting the number of tunnels (Multicast 3133 Data message destinations) that can be created for a single gateway 3134 source address. Relays should also provide a means for limiting the 3135 number of joins per tunnel instance as a defense against these 3136 attacks. 3138 Relays may withdraw their AMT anycast prefix advertisement when they 3139 reach configured maximum capacity or exhaust required resources. 3140 This behavior allows gateways to use the relay discovery process to 3141 find the next topologically-nearest relay that has advertised the 3142 prefix. This behavior also allows a successful resource exhaustion 3143 attack to propagate from one relay to the next until all relays 3144 reachable using the anycast address have effectively been taken 3145 offline. This behavior may also be used to acquire the unicast 3146 addresses for individual relays which can then be used to launch a 3147 DDoS attack on all of the relays without using the relay discovery 3148 process. To prevent wider disruption of AMT-based distribution 3149 network, relay anycast address advertisements can be limited to 3150 specific administrative routing domains. This will isolate such 3151 attacks to a single domain. 3153 6.2. Gateways 3155 A passive eavesdropper may launch a denial-of-service attack on a 3156 gateway by capturing a Membership Query or Membership Update message 3157 and using the request nonce and message authentication code carried 3158 by the captured message to send a spoofed a Membership Update or 3159 Teardown message to the relay. The spoofed messages may be used to 3160 modify or destroy group membership state associated with the gateway, 3161 thereby changing or interrupting the multicast traffic flows. 3163 A passive eavesdropper may also spoof Multicast Data messages in an 3164 attempt to overload the gateway or disrupt or supplant existing 3165 traffic flows. A properly implemented gateway will filter Multicast 3166 Data messages that do not originate from the expected relay address 3167 and should filter non-multicast packets and multicast IP packets 3168 whose group or source addresses are not included in the current 3169 reception state for the gateway pseudo-interface. 3171 The anycast discovery technique for finding relays (see 3172 Section 4.1.4) introduces a risk that a rogue router or a rogue AS 3173 could introduce a bogus route to a specific Relay Discovery Address 3174 prefix, and thus divert or absorb Relay Discovery messages sent by 3175 gateways. Network managers must guarantee the integrity of their 3176 routing to a particular Relay Discovery Address prefix in much the 3177 same way that they guarantee the integrity of all other routes. 3179 6.3. Encapsulated IP Packets 3181 An attacker forging or modifying a Membership Query or Membership 3182 Update message may attempt to embed something other than an IGMP or 3183 MLD message within the encapsulated IP packet carried by these 3184 messages in an effort to introduce these into the recipient's IP 3185 stack. A properly implemented gateway or relay will ignore any such 3186 messages - and may further choose ignore Membership Query messages 3187 that do not contain a IGMP/MLD general queries or Membership Update 3188 messages that do not contain IGMP/MLD membership reports. 3190 Property implemented gateways and relays will also filter 3191 encapsulated IP packets that appear corrupted or truncated by 3192 verifying packet length and checksums. 3194 7. IANA Considerations 3196 7.1. IPv4 and IPv6 Anycast Prefix Allocation 3198 The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated 3199 to the public AMT Relays to advertise to the native multicast 3200 backbone (as described in Section 4.1.4). The prefix length should 3201 be determined by the IANA; the prefix should be large enough to 3202 guarantee advertisement in the default-free BGP networks. 3204 7.1.1. IPv4 3206 A prefix length of 16 will meet this requirement. 3208 7.1.2. IPv6 3210 A prefix length of 32 will meet this requirement. IANA has 3211 previously set aside the range 2001::/16 for allocating prefixes for 3212 this purpose. 3214 7.2. UDP Port number 3216 IANA has reserved UDP port number 2268 for AMT. 3218 8. Contributors 3220 The following people provided significant contributions to earlier 3221 versions of this specification: 3223 Dirk Ooms 3224 OneSparrow 3225 Belegstraat 13; 2018 Antwerp; 3226 Belgium 3227 EMail: dirk@onesparrow.com 3229 Tom Pusateri 3230 !j 3231 2109 Mountain High Rd. 3232 Wake Forest, NC 27587 3233 USA 3234 Email: pusateri@bangj.com 3236 Dave Thaler 3237 Microsoft Corporation 3238 One Microsoft Way 3239 Redmond, WA 98052-6399 3240 USA 3241 Email: dthaler@microsoft.com 3243 9. Acknowledgments 3245 The authors would like to thank the following individuals for their 3246 suggestions, comments, and corrections: 3248 Amit Aggarwal 3249 Mark Altom 3250 Toerless Eckert 3251 Marshall Eubanks 3252 Dino Farinacci 3253 Lenny Giuliano 3254 Andy Huang 3255 Tom Imburgia 3256 Patricia McCrink 3257 Han Nguyen 3258 Doug Nortz 3259 Pekka Savola 3260 Robert Sayko 3261 Greg Shepherd 3262 Steve Simlo 3263 Mohit Talwar 3264 Lorenzo Vicisano 3265 Kurt Windisch 3266 John Zwiebel 3268 The anycast discovery mechanism described in this document is based 3269 on similar work done by the NGTrans WG for obtaining automatic IPv6 3270 connectivity without explicit tunnels ("6to4"). Tony Ballardie 3271 provided helpful discussion that inspired this document. 3273 Juniper Networks was instrumental in funding several versions of this 3274 draft as well as an open source implementation. 3276 10. References 3278 10.1. Normative References 3280 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3281 August 1980. 3283 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3284 RFC 792, September 1981. 3286 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 3287 April 1992. 3289 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 3290 Thyagarajan, "Internet Group Management Protocol, Version 3291 3", RFC 3376, October 2002. 3293 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 3294 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 3296 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3297 Architecture", RFC 4291, February 2006. 3299 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 3300 "Internet Group Management Protocol (IGMP) / Multicast 3301 Listener Discovery (MLD)-Based Multicast Forwarding 3302 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 3304 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 3305 IP", RFC 4607, August 2006. 3307 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 3308 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 3309 RFC 4787, January 2007. 3311 10.2. Informative References 3313 [I-D.ietf-6man-udpchecksums] 3314 Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled 3315 Packets", draft-ietf-6man-udpchecksums-01 (work in 3316 progress), October 2011. 3318 [I-D.ietf-6man-udpzero] 3319 Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum 3320 Considerations", draft-ietf-6man-udpzero-05 (work in 3321 progress), December 2011. 3323 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3324 September 1981. 3326 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 3327 RFC 1112, August 1989. 3329 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 3330 Anycasting Service", RFC 1546, November 1993. 3332 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 3333 Hashing for Message Authentication", RFC 2104, 3334 February 1997. 3336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3337 Requirement Levels", BCP 14, RFC 2119, March 1997. 3339 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 3340 2", RFC 2236, November 1997. 3342 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3343 (IPv6) Specification", RFC 2460, December 1998. 3345 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 3346 Translator (NAT) Terminology and Considerations", 3347 RFC 2663, August 1999. 3349 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 3350 Listener Discovery (MLD) for IPv6", RFC 2710, 3351 October 1999. 3353 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 3354 Tunnel Broker", RFC 3053, January 2001. 3356 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 3357 via IPv4 Clouds", RFC 3056, February 2001. 3359 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 3360 RFC 3068, June 2001. 3362 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 3363 Text on Security Considerations", BCP 72, RFC 3552, 3364 July 2003. 3366 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 3367 Independent Multicast - Dense Mode (PIM-DM): Protocol 3368 Specification (Revised)", RFC 3973, January 2005. 3370 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 3371 Message Protocol (ICMPv6) for the Internet Protocol 3372 Version 6 (IPv6) Specification", RFC 4443, March 2006. 3374 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 3375 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 3376 Protocol Specification (Revised)", RFC 4601, August 2006. 3378 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 3379 "Multiprotocol Extensions for BGP-4", RFC 4760, 3380 January 2007. 3382 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 3383 Services", BCP 126, RFC 4786, December 2006. 3385 Appendix A. Implementation Notes 3387 A.1. Response MAC Generation and Keying 3389 This specification does not require relays to use any particular 3390 method to compute the Response MAC field value - only that it contain 3391 a hash of the source IP address, source UDP port, request nonce, and 3392 a private secret known only to the relay. This allows the relay 3393 implementor a significant amount of leeway in the computation and 3394 structure of the value stored in the Response MAC field. 3396 Section Section 5.3.6 states that a relay should periodically compute 3397 a new private secret (or hash-key) for MAC generation. To prevent 3398 the relay from rejecting Membership Update messages that contain 3399 Response MAC values computed from an old secret, the relay is 3400 required to retain the previous secret so that it can re-attempt 3401 authentication using the old secret, should authentication fail after 3402 recomputing the MAC using the new secret. However, this approach 3403 requires a relay to do at least two hash computations for every 3404 Membership Update message that carries an old or a invalid MAC. A 3405 better approach would be to include information within the message 3406 that the relay could use to choose a single secret for authentication 3407 rather relying on sequential authentication failures to test all 3408 possible secrets. 3410 The solution proposed here is to compute and exchange an 3411 "authentication cookie" rather than a simple hash value in the 3412 Response MAC field. The authentication cookie would combine a 3413 timestamp with a hash value. The timestamp is used to calculate the 3414 age of the cookie, allowing the relay to reject a message if the 3415 cookie's age is greater than some maximum allowable value. If the 3416 cookie has not expired, the relay uses the timestamp to lookup the 3417 secret that was in use at that time and then compute and compare the 3418 hash portion of the cookie to authenticate the message source. 3420 A second purpose served by including the timestamp in the MAC field 3421 is that it allows the relay to contribute an unpredictable value to 3422 the authentication hash. This contribution provides a defense 3423 against attempts to use a hash reversal algorithm to determine the 3424 relay's private secret as the hash result will change over time even 3425 if the nonce carried by the Request message does not. 3427 0 1 2 3 3428 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 3429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3430 | V=0 |4 or 5| Reserved | | Response MAC | 3431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 3432 | | 3433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3434 | Request Nonce | 3435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3436 : : 3438 The Opaque Response MAC Field 3440 A relay may use the opaque Response MAC field to store a cookie as 3441 follows: 3443 0 1 2 3 3444 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 3445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3446 | V=0 |4 or 5| Reserved | | Timestamp | 3447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3448 | MD5(Secret,Timestamp,IP_ADDR,IP_PORT,Request-Nonce) | 3449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3450 | Request Nonce | 3451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3452 : : 3454 Using The Response MAC Field To Carry An Authentication Cookie 3456 The timestamp is an unsigned integer measured relative to the start 3457 time of relay. The age of the MAC is computed by subtracting the MAC 3458 timestamp from the current system timestamp. The operands must be 3459 unsigned 16-bit integers and the subtraction must use unsigned 3460 arithmetic to allow for timestamp wrap-around. The timestamp 3461 resolution must provide range sufficient to handle the maximum 3462 allowable age for a MAC, e.g., a resolution of 1 second allows a 3463 maximum age of 18 hours. The timestamp should start at a random 3464 value by adding a random offset, computed at startup, to the current 3465 system time. 3467 +-------------------------+----------------/ /-----------------+ 3468 -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] | 3469 | +-------------------------+----------------/ /-----------------+ 3470 |_____________________________________________________________________ 3471 | 3472 +-------------------------+----------------/ /-----------------+ | 3473 -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |-- 3474 | +-------------------------+----------------/ /-----------------+ 3475 |_____________________________________________________________________ 3476 | 3477 +-------------------------+----------------/ /-----------------+ | 3478 -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |-- 3479 | +-------------------------+----------------/ /-----------------+ 3480 | 3481 |__ Current 3482 Secret 3484 Private Secret Queue 3486 The timestamp is not only used to compute the age of the MAC, but is 3487 also used to lookup the private secret used to generate the MAC. 3488 Each time a new private secret is computed, the value and the time at 3489 which the value was computed is pushed into a fixed-length queue of 3490 recent values (typically only 2-deep). The relay uses the timestamp 3491 contained in the MAC field to lookup the appropriate secret. The 3492 relay iterates over the list of secrets, starting with the newest 3493 entry, until it finds the first secret with a timestamp that is older 3494 than that contained in the MAC field. The relay then uses that 3495 secret to compute the MAC that will be compared with that carried by 3496 the message. 3498 Authors' Addresses 3500 Gregory Bumgardner 3501 Cisco 3502 3700 Cisco Way 3503 San Jose, CA 95134 3504 USA 3506 Phone: +1 408 853 4993 3507 Email: gbumgard@cisco.com 3509 Thomas Morin 3510 France Telecom - Orange 3511 2, avenue Pierre Marzin 3512 Lannion 22300 3513 France 3515 Phone: +33 2 96 05 3734 3516 Email: thomas.morin@orange.com