idnits 2.17.1 draft-ietf-mboned-auto-multicast-13.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 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 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 (April 23, 2012) is 4384 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 952 -- Looks like a reference, but probably isn't: '2' on line 954 -- Looks like a reference, but probably isn't: '3' on line 957 -- Looks like a reference, but probably isn't: '4' on line 971 -- Looks like a reference, but probably isn't: '5' on line 973 -- Looks like a reference, but probably isn't: '6' on line 976 -- Looks like a reference, but probably isn't: '7' on line 980 == Missing Reference: '16-bits' is mentioned on line 3544, but not defined == Missing Reference: '128-bits' is mentioned on line 3544, but not defined == Unused Reference: 'RFC0768' is defined on line 3346, but no explicit reference was found in the text == Unused Reference: 'RFC4605' is defined on line 3365, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 3398, but no explicit reference was found in the text == Unused Reference: 'RFC3053' is defined on line 3419, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 3422, but no explicit reference was found in the text == Unused Reference: 'RFC3068' is defined on line 3425, but no explicit reference was found in the text == Unused Reference: 'RFC3973' is defined on line 3432, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 3444, 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-02 == 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 (~~), 15 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 April 23, 2012 5 Expires: October 25, 2012 7 Automatic Multicast Tunneling 8 draft-ietf-mboned-auto-multicast-13 10 Abstract 12 This document describes Automatic Multicast Tunneling (AMT), a 13 protocol for delivering multicast traffic from sources in a 14 multicast-enabled network to receivers that lack multicast 15 connectivity to the source network. The protocol uses UDP 16 encapsulation and unicast replication to provide this functionality. 18 The AMT protocol is specifically designed to support rapid deployment 19 by requiring minimal changes to existing network infrastructure. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on October 25, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 71 3.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 72 3.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 6 73 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1. General Architecture . . . . . . . . . . . . . . . . . . . 8 75 4.2. General Operation . . . . . . . . . . . . . . . . . . . . 17 76 5. Protocol Description . . . . . . . . . . . . . . . . . . . . . 32 77 5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 32 78 5.2. Gateway Operation . . . . . . . . . . . . . . . . . . . . 46 79 5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 61 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 72 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 75 82 7.2. IPv4 Address Prefix Allocation for IGMP Source 83 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 75 84 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 76 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 77 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 78 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 78 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 78 89 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 81 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 84 92 1. Introduction 94 The advantages and benefits provided by multicast technologies are 95 well known. There are a number of application areas that are ideal 96 candidates for the use of multicast, including media broadcasting, 97 video conferencing, collaboration, real-time data feeds, data 98 replication, and software updates. Unfortunately, many of these 99 applications lack multicast connectivity to networks that carry 100 traffic generated by multicast 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 network with multicast connectivity 108 to a source, to request and receive SSM [RFC4607] and ASM [RFC1112] 109 traffic from a network that does provide multicast connectivity to 110 that source. 112 2. Applicability 114 This document describes a protocol that may be used to deliver 115 multicast traffic from a multicast enabled network to sites that lack 116 multicast connectivity to the source network. This document does not 117 describe any methods for sourcing multicast traffic from isolated 118 sites as this topic is out of scope. 120 AMT is not intended to be used as a substitute for native multicast, 121 especially in conditions or environments requiring high traffic flow. 122 AMT uses unicast replication to reach multiple receivers and the 123 bandwidth cost for this replication will be higher than that required 124 if the receivers were reachable via native multicast. 126 3. Terminology 128 3.1. Requirements Notation 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 3.2. Definitions 136 This document adopts the following definitions for use in describing 137 the protocol: 139 Downstream: 140 A downstream interface or connection that faces away from the 141 multicast distribution root or towards multicast receivers. 143 Upstream: 144 An upstream interface or connection that faces a multicast 145 distribution root or source. 147 Non-Broadcast Multi-Access (NMBA): 148 A non-broadcast multiple-access (NBMA) network or interface is one 149 to which multiple network nodes (hosts or routers) are attached, 150 but where packets are transmitted directly from one node to 151 another node over a virtual circuit or physical link. NBMA 152 networks do not support multicast or broadcast traffic - a node 153 that sources multicast traffic must replicate the multicast 154 packets for separate transmission to each node that has requested 155 the multicast traffic. 157 Multicast Receiver: 158 An entity that requests and receives multicast traffic. A 159 receiver may be a router, host, application, or application 160 component. The method by which a receiver transmits group 161 membership requests and receives multicast traffic varies 162 according to receiver type. 164 Group Membership Database: 165 A group membership database describes the current multicast 166 subscription/reception sate for an interface or system. 168 Reception State: 169 The multicast subscription state of a pseudo, virtual or physical 170 network interface. See group membership database. 172 Subscription: 173 A group or state entry in a group membership database or reception 174 state table. 176 Group Membership Protocol: 177 The term "group membership protocol" is used as a generic 178 reference to the Internet Group Management (IGMP) ([RFC1112], 179 [RFC2236], [RFC3376]) or Multicast Listener Discovery ([RFC2710], 180 [RFC3810]) protocols. 182 Multicast Protocol: 183 The term "multicast protocol" is used as a generic reference to 184 multicast routing protocols used to join or leave multicast 185 distribution trees such as PIM-SM [RFC4601]. 187 Network Address Translation (NAT): 188 Network Address Translation is the process of modifying the source 189 IP address and port numbers carried by an IP packet while 190 transiting a network node (See [RFC2663]). Intervening NAT 191 devices may change the source address and port carried by messages 192 sent from an AMT gateway to an AMT relay, possibly producing 193 changes in protocol state and behavior. 195 Anycast: 196 A network addressing and routing method in which packets from a 197 single sender are routed to the topologically nearest node in a 198 group of potential receivers all identified by the same 199 destination address. See [RFC4786]. 201 3.3. Abbreviations 203 AMT - Automatic Multicast Tunneling Protocol. 205 ASM - Any-Source Multicast. 207 DoS - Denial-of-Service (attack) and DDoS for distributed-DoS. 209 IGMP - Internet Group Management Protocol (v1, v2 and v3). 211 IP - Internet Protocol (v4 and v6). 213 MAC - Message Authentication Code (or Cookie). 215 MLD - Multicast Listener Discovery protocol (v1 and v2). 217 NAT - Network Address Translation (or translation node). 219 NBMA - Non-Broadcast Multi-Access (network, interface or mode) 221 SSM - Source-Specific Multicast. 223 PIM - Protocol Independent Multicast. 225 4. Protocol Overview 227 This section provides an informative description of the protocol. A 228 normative description of the protocol and implementation requirements 229 may be found in section Section 5. 231 4.1. General Architecture 233 Isolated Site | Unicast Network | Native Multicast 234 | (Internet) | 235 | | 236 | | 237 | Group Membership | 238 +-------+ ===========================> +-------+ Multicast +------+ 239 |Gateway| | | | Relay |<----//----|Source| 240 +-------+ <=========================== +-------+ +------+ 241 | Multicast Data | 242 | | 243 | | 245 Figure 1: Basic AMT Architecture 247 The AMT protocol employs a client-server model in which a "gateway" 248 sends requests to receive specific multicast traffic to a "relay" 249 which responds by delivering the requested multicast traffic back to 250 the gateway. 252 Gateways are generally deployed within networks that lack multicast 253 support or lack connectivity to a multicast-enabled network 254 containing multicast sources of interest. 256 Relays are deployed within multicast-enabled networks that contain, 257 or have connectivity to, multicast sources. 259 4.1.1. Relationship to IGMP and MLD Protocols 261 AMT relies on the Internet Group Management (IGMP) [RFC3376] and 262 Multicast Listener Discovery (MLD) [RFC3810] protocols to provide the 263 functionality required to manage, communicate, and act on changes in 264 multicast group membership. A gateway or relay implementation does 265 not necessarily require a fully-functional, conforming implementation 266 of IGMP or MLD to adhere to this specification, but the protocol 267 description that appears in this document assumes that this is the 268 case. The minimum functional and behavioral requirements for the 269 IGMP and MLD protocols are described in Section 5.2.1 and 270 Section 5.3.1. 272 Gateway Relay 274 General _____ _____ 275 ___________ Query | | | | Query ___________ 276 | |<------| | | |<------| | 277 | Host Mode | | AMT | | AMT | |Router Mode| 278 | IGMP/MLD | | | UDP | | | IGMP/MLD | 279 |___________|------>| |<----->| |------>|___________| 280 Report | | | | Report 281 Leave/Done | | | | Leave/Done 282 | | | | 283 IP Multicast <------| | | |<------ IP Multicast 284 |_____| |_____| 286 Multicast Reception State Managed By IGMP/MLD 288 A gateway runs the host portion of the IGMP and MLD protocols to 289 generate group membership updates that are sent via AMT messages to a 290 relay. A relay runs the router portion of the IGMP and MLD protocols 291 to process the group membership updates to produce the required 292 changes in multicast forwarding state. A relay uses AMT messages to 293 send incoming multicast IP datagrams to gateways according to their 294 current group membership state. 296 The primary function of AMT is to provide the handshaking, 297 encapsulation and decapsulation required to transport the IGMP and 298 MLD messages and multicast IP datagrams between the gateways and 299 relays. The IGMP and MLD messages that are exchanged between 300 gateways and relays are encapsulated as complete IP datagrams within 301 AMT control messages. Multicast IP datagrams are replicated and 302 encapsulated in AMT data messages. All AMT messages are sent via 303 unicast UDP/IP. 305 4.1.2. Gateways 307 The downstream side of a gateway services one or more receivers - the 308 gateway accepts group membership requests from receivers and forwards 309 requested multicast traffic back to those receivers. 311 The upstream side of a gateway connects to relays. A gateway sends 312 encapsulated IGMP and MLD messages to a relay to indicate an interest 313 in receiving specific multicast traffic. 315 4.1.2.1. Architecture 317 Each gateway possesses a logical pseudo-interface: 319 join/leave ---+ +----------+ 320 | | | 321 V IGMPv3/MLDv2 | | 322 +---------+ General Query| | AMT 323 |IGMP/MLD |<-------------| AMT | Messages +------+ 324 |Host Mode| | Gateway |<-------->|UPD/IP| 325 |Protocol |------------->|Pseudo I/F| +------+ 326 +---------+ IGMP/MLD | | ^ 327 Report | | | 328 Leave/Done | | V 329 IP Multicast <---------------------| | +---+ 330 +----------+ |I/F| 331 +---+ 333 Figure 2: AMT Gateway Pseudo-Interface 335 The pseudo-interface is conceptually a network interface on which the 336 gateway executes the host portion of the IPv4/IGMP (v2 or v3) and 337 IPv6/MLD (v1 or v2) protocols. The multicast reception state of the 338 pseudo-interface is manipulated using the IGMP or MLD service 339 interface. The IGMP and MLD host protocols produce IP datagrams 340 containing group membership messages that the gateway will send to 341 the relay. The IGMP and MLD protocols also supply the retransmission 342 and timing behavior required for protocol robustness. 344 All AMT encapsulation, decapsulation and relay interaction is assumed 345 to occur within the pseudo-interface. 347 A gateway host or application may create separate interfaces for 348 IPv4/IGMP and IPv6/MLD. A gateway host or application may also 349 require additional pseudo-interfaces for each source or domain- 350 specific relay address. 352 Within this document, the term "gateway" may be used as a generic 353 reference to an entity executing the gateway protocol, a gateway 354 pseudo-interface, or a gateway device that has one or more interfaces 355 connected to a unicast inter-network and one or more AMT gateway 356 pseudo-interfaces. 358 The following diagram illustrates how an existing host IP stack 359 implementation might be used to provide AMT gateway functionality to 360 a multicast application: 362 +-----------------------------------------------------+ 363 |Host | 364 | ______________________________________ | 365 | | | | 366 | | ___________________________ | | 367 | | | | | | 368 | | | v | | 369 | | | +-----------+ +--------------+ | 370 | | | |Application| | AMT Daemon | | 371 | | | +-----------+ +--------------+ | 372 | | | join/leave | ^ data ^ AMT | 373 | | | | | | | 374 | | | +----|---|-------------|-+ | 375 | | | | __| |_________ | | | 376 | | | | | | | | | 377 | | | | | Sockets | | | | 378 | | | +-|------+-------+-|---|-+ | 379 | | | | | IGMP | TCP | |UDP| | | 380 | | | +-|------+-------+-|---|-+ | 381 | | | | | ^ IP | | | | 382 | | | | | | ____________| | | | 383 | | | | | | | | | | 384 | | | +-|-|-|----------------|-+ | 385 | | | | | | | | 386 | | | IP(IGMP)| | |IP(UDP(data)) |IP(UDP(AMT)) | 387 | | | v | | v | 388 | | | +-----------+ +---+ | 389 | | | |Virtual I/F| |I/F| | 390 | | | +-----------+ +---+ | 391 | | | | ^ ^ | 392 | | | IP(IGMP)| |IP(UDP(data)) | | 393 | | |_________| |IP(IGMP) | | 394 | | | | | 395 | |_________________| | | 396 | | | 397 +--------------------------------------|--------------+ 398 v 399 AMT Relay 401 Virtual Interface Implementation Example 403 In this example, the host IP stack uses a virtual network interface 404 to interact with a gateway pseudo-interface implementation. 406 4.1.2.2. Use-Cases 408 Use-cases for gateway functionality include: 410 IGMP/MLD Proxy 411 An IGMP/MLD proxy that runs AMT on an upstream interface and 412 router-mode IGMP/MLD on downstream interfaces to provide host 413 access to multicast traffic via the IGMP and MLD protocols. 415 Virtual Network Interface 416 A virtual network interface or pseudo network device driver that 417 runs AMT on a physical network interface to provide socket layer 418 access to multicast traffic via the IGMP/MLD service interface 419 provided by the host IP stack. 421 Application 422 An application or application component that implements and 423 executes IGMP/MLD and AMT internally to gain access to multicast 424 traffic. 426 4.1.3. Relays 428 The downstream side of a relay services gateways - the relay accepts 429 encapsulated IGMP and MLD group membership messages from gateways and 430 encapsulates and forwards the requested multicast traffic back to 431 those gateways. 433 The upstream side of a relay communicates with a native multicast 434 infrastructure - the relay sends join and prune/leave requests 435 towards multicast sources and accepts requested multicast traffic 436 from those sources. 438 4.1.3.1. Architecture 440 Each relay possesses a logical pseudo-interface: 442 +------------------------------+ 443 +--------+ | Multicast Control Plane | 444 | |IGMP/MLD| | 445 | | Query* | +------------+ +----------+ | 446 | |<---//----|IGMPv3/MLDv2| | | | 447 AMT | | | |Router Mode |->| PIM-SM |<--> 448 +------+ Messages | AMT |----//--->|Protocol | | | | 449 |UDP/IP|<-------->| Relay |IGMP/MLD| +------------+ +----------+ | 450 +------+ | Pseudo | Report | | | | 451 ^ | I/F | Leave/ +------|---------------|-------+ 452 | | | Done | | 453 | | | v | 454 V | | IP +-----------+ | 455 +---+ | | Multicast |Multicast |<------+ 456 |I/F| | |<---//-----|Forwarding | 457 +---+ +--------+ |Plane |<--- IP Multicast 458 +-----------+ 460 * Queries, if generated, are consumed by the pseudo-interface. 462 AMT Relay Pseudo-Interface (Router-Based) 464 The pseudo-interface is conceptually a network interface on which the 465 relay runs the router portion of the IPv4/IGMPv3 and IPv6/MLDv2 466 protocols. Relays do not send unsolicited IGMPv3/MLDv2 query 467 messages to gateways so relays must consume or discard any local 468 queries normally generated by IGMPv3 or MLDv2. 470 A relay maintains group membership state for each gateway connected 471 through the pseudo-interface as well as for the entire pseudo- 472 interface (if multiple gateways are managed via a single interface). 473 Multicast packets received on upstream interfaces on the relay are 474 routed to the pseudo-interface where they are replicated, 475 encapsulated and sent to interested gateways. Changes in the pseudo- 476 interface group membership state may trigger the transmission of 477 multicast protocol requests upstream towards a given source or 478 rendezvous point and cause changes in internal routing/forwarding 479 state. 481 The relay pseudo-interface is a architectural abstraction used to 482 describe AMT protocol operation. For the purposes of this document, 483 the pseudo-interface is most easily viewed as an interface to a 484 single gateway - encapsulation, decapsulation, and other AMT-specific 485 processing occurs "within" the pseudo-interface while forwarding and 486 replication occur outside of it. 488 An alternative view is to treat the pseudo-interface as a non- 489 broadcast multi-access (NBMA) network interface whose link layer is 490 the unicast-only network over which AMT messages are exchanged with 491 gateways. Individual gateways are conceptually treated as logical 492 NBMA links on the interface. In this architectural model, group 493 membership tracking, replication and forwarding functions occur in 494 the pseudo-interface. 496 This document does not specify any particular architectural solution 497 - a relay developer may choose to implement and distribute protocol 498 functionality as required to take advantage of existing relay 499 platform services and architecture. 501 Within this document, the term "relay" may be used as a generic 502 reference to an entity executing the relay protocol, a relay pseudo- 503 interface, or a relay device that has one or more network interfaces 504 with multicast connectivity to a native multicast infrastructure, 505 zero or more interfaces connected to a unicast inter-network, and one 506 or more relay pseudo-interfaces. 508 4.1.3.2. Use-Cases 510 Use-cases for relay functionality include: 512 Multicast Router 513 A multicast router that runs AMT on a downstream interface to 514 provide gateway access to multicast traffic. A "relay router" 515 uses a multicast routing protocol (e.g. PIM-SM RFC4601 [RFC4601]) 516 to construct a forwarding path for multicast traffic by sending 517 join and prune messages to neighboring routers to join or leave 518 multicast distribution trees for a given SSM source or ASM 519 rendezvous point. 521 IGMP/MLD Proxy Router 522 An IGMP/MLD proxy that runs AMT on a downstream interface and 523 host-mode IGMPv3/MLDv2 on a upstream interface. This "relay 524 proxy" sends group membership reports to a local, multicast- 525 enabled router to join and leave specific SSM or ASM groups. 527 4.1.4. Deployment 529 The AMT protocol calls for a relay deployment model that uses anycast 530 addressing [RFC1546][RFC4291] to pair gateways with relays. 532 Under this approach, one or more relays advertise a route for the 533 same IP address prefix. To find a relay with which to communicate, a 534 gateway sends a message to an anycast IP address within that prefix. 535 This message is routed to the topologically-nearest relay that has 536 advertised the prefix. The relay that receives the message responds 537 by sending its unicast address back to the gateway. The gateway uses 538 this address as the destination address for any messages it 539 subsequently sends to the relay. 541 The use of anycast addressing provides the following benefits: 543 o Relays may be deployed at multiple locations within a single 544 multicast-enabled network. Relays might be installed "near" 545 gateways to reduce bandwidth requirements, latency and limit the 546 number of gateways that might be serviced by a single relay. 548 o Relays may be added or removed at any time thereby allowing staged 549 deployment, scaling and hot-swapping - the relay discovery process 550 will always return the nearest operational relay. 552 o Relays may take themselves offline when they exhaust resources 553 required to service additional gateways. Existing gateway 554 connections may be preserved, but new gateway requests would be 555 routed to the next-nearest relay. 557 4.1.4.1. Public Versus Private 559 Ideally, the AMT protocol would provide a universal solution for 560 connecting receivers to multicast sources - that any gateway could be 561 used to access any globally advertised multicast source via publicly- 562 accessible, widely-deployed relays. Unfortunately, today's internet 563 does not yet allow this, because many relays will lack native 564 multicast access to sources even though they may be globally 565 accessible via unicast. 567 In these cases, a provider may deploy relays within their own source 568 network to allow for multicast distribution within that network. 569 Gateways that use these relays must use a provider-specific relay 570 discovery mechanism or a private anycast address to obtain access to 571 these relays. 573 4.1.5. Discovery 575 To execute the gateway portion of the protocol, a gateway requires a 576 unicast IP address of an operational relay. This address may be 577 obtained using a number of methods - it may be statically assigned or 578 dynamically chosen via some form of relay discovery process. 580 As described in the previous section, the AMT protocol provides a 581 relay discovery method that relies on anycast addressing. Gateways 582 are not required to use AMT relay discovery, but all relay 583 implementations must support it. 585 The AMT protocol uses the following terminology when describing the 586 discovery process: 588 Relay Discovery Address Prefix: 589 The anycast address prefix used to route discovery messages to a 590 relay. 592 Relay Discovery Address: 593 The anycast destination address used when sending discovery 594 messages. 596 Relay Address: 597 The unicast IP address obtained as a result of the discovery 598 process. 600 4.1.5.1. Relay Discovery Address Selection 602 The selection of an anycast Relay Discovery Address may be source- 603 dependent, as a relay located via relay discovery must have multicast 604 connectivity to a desired source. 606 Similarly, the selection of a unicast Relay address may be source- 607 dependent, as a relay contacted by a gateway to supply multicast 608 traffic must have native multicast connectivity to the traffic source 610 Methods that might be used to perform source-specific or group- 611 specific relay selection are highly implementation-dependent and are 612 not further addressed by this document. Possible approaches include 613 the use of static lookup tables, DNS-based queries, or a provision of 614 a service interface that accepts join requests on (S,G,relay- 615 discovery-address) or (S,G,relay-address) tuples. 617 4.1.5.2. IANA-Assigned Relay Discovery Address Prefix 619 This document calls for IANA to allocate an anycast address prefix 620 for use in advertising and discovering publicly accessible relays. 622 A relay discovery address is constructed from the anycast address 623 prefix by setting the low-order octet of the prefix address to 1 (for 624 both IPv4 and IPv6). 626 Public relays must advertise a route to the anycast address prefix 627 and configure an interface to respond to the relay discovery address. 629 The IANA address assignments are discussed in Section 7. 631 4.2. General Operation 633 4.2.1. Message Sequences 635 The AMT protocol defines the following messages for control and 636 encapsulation. These messages are exchanged as UDP/IP datagrams, one 637 message per datagram. 639 Relay Discovery: 640 Sent by gateways to solicit a Relay Advertisement from any relay. 641 Used to find a relay with which to communicate. 643 Relay Advertisement: 644 Sent by relays as a response to a Relay Discovery message. Used 645 to deliver a relay address to a gateway. 647 Request: 648 Sent by gateways to solicit a Membership Query message from a 649 relay. 651 Membership Query: 652 Sent by relays as a response to a Request message. Used to 653 deliver an encapsulated IGMPv3 or MLDv2 query message to the 654 gateway. 656 Membership Update: 657 Sent by gateways to deliver an encapsulated IGMP or MLD report/ 658 leave/done message to a relay. 660 Multicast Data: 661 Sent by relays to deliver an encapsulated IP multicast datagram to 662 a gateway. 664 Teardown: 665 Sent by gateways to stop the delivery of Multicast Data messages 666 requested in an earlier Membership Update message. 668 The following sections describe how these messages are exchanged to 669 execute the protocol. 671 4.2.1.1. Relay Discovery Sequence 673 Gateway Relay 674 ------- ----- 675 : : 676 | | 677 [1] |Relay Discovery | 678 |------------------->| 679 | | 680 | Relay Advertisement| [2] 681 |<-------------------| 682 [3] | | 683 : : 685 AMT Relay Discovery Sequence 687 The following sequence describes how the Relay Discovery and Relay 688 Advertisement messages are used to find a relay with which to 689 communicate: 691 1. The gateway sends a Relay Discovery message containing a random 692 nonce to the Relay Discovery Address. If the Relay Discovery 693 Address is an anycast address, the message is routed to 694 topologically-nearest network node that advertises that address. 696 2. The node receiving the Relay Discovery message sends a Relay 697 Advertisement message back to the source of the Relay Discovery 698 message. The message carries a copy of the nonce contained in 699 the Relay Discovery message and the unicast IP address of a 700 relay. 702 3. When the gateway receives the Relay Advertisement message it 703 verifies that the nonce matches the one sent in the Relay 704 Discovery message, and if it does, uses the relay address carried 705 by the Relay Advertisement as the destination address for 706 subsequent AMT messages. 708 Note that the responder need not be a relay - the responder may 709 obtain a relay address by some other means and return the result in 710 the Relay Advertisement (i.e. the responder is a load-balancer or 711 broker). 713 4.2.1.2. Membership Update Sequence 715 There exists a significant difference between normal IGMP and MLD 716 behavior and that required by AMT. An IGMP/MLD router acting as a 717 querier normally transmits query messages on a network interface to 718 construct and refresh group membership state for the connected 719 network. These query messages are multicast to all IGMP/MLD enabled 720 hosts on the network. Each host responds by multicasting report 721 messages that describe their current multicast reception state. 723 However, AMT does not allow relays to send unsolicited query messages 724 to gateways, as the set of active gateways may be unknown to the 725 relay and potentially quite large. Instead, AMT requires each 726 gateway to periodically send a message to a relay to solicit a 727 general-query response. A gateway accomplishes this by sending a 728 Request message to a relay. The relay responds by sending Membership 729 Query message back to the gateway. The Membership Query message 730 carries an encapsulated general query that is processed by the IGMP 731 or MLD protocol implementation on the gateway to produce a 732 membership/listener report. Each time the gateway receives a 733 Membership Query message it starts a timer whose expiration will 734 trigger the start of a new Request->Membership Query message 735 exchange. This timer-driven sequence is used to mimic the 736 transmission of a periodic general query by an IGMP/MLD router. This 737 query cycle may continue indefinitely once started by sending the 738 initial Request message. 740 A membership update occurs when an IGMP or MLD report, leave or done 741 message is passed to the gateway pseudo-interface. These messages 742 may be produced as a result of the aforementioned general-query 743 processing or as a result of receiver interaction with the IGMP/MLD 744 service interface. Each report is encapsulated and sent to the relay 745 after the gateway has successfully established communication with the 746 relay via a Request and Membership Query message exchange. If a 747 report is passed to the pseudo-interface before the gateway has 748 received a Membership Query message from the relay, the gateway may 749 discard the report or queue the report for delivery after a 750 Membership Query is received. Subsequent IGMP/MLD report/leave/done 751 messages that are passed to the pseudo-interface are immediately 752 encapsulated and transmitted to the relay. 754 IGMP/MLD Pseudo-I/F Relay 755 -------- ---------- ----- 756 : : : 757 | | Request | 758 | 1|-------------------->| 759 | | Membership Query |2 760 Query | | Q(0,{}) | 761 Timer | Start 3|<--------------------| 762 (QT)<--------------------------| | 763 | Q(0,{}) | | 764 |<--------------------| | 765 4| R({}) | Membership Update | 766 |-------------------->|5 R({}) | 767 | |====================>|6a 768 Join(S,G) : : : 769 ()--------->|7 R({G:ALLOW({S})}) | Membership Update | 770 |-------------------->|8 R({G:ALLOW({S})}) | 771 | |====================>|9a Join(S,G) 772 | | |---------->() 773 : : : 774 | ------------|---------------------|------------ 775 | | | | | 776 | | | Multicast Data | IP(S,G) | 777 | | | IP(S,G) 10|<--------() | 778 | | IP(S,G) 11|<====================| | 779 | | ()<--------| | | 780 | | | | | 781 : ------------:---------------------:------------ 782 | Expired | | 783 (QT)-------------------------->|12 Request | 784 | 1|-------------------->| 785 | | Membership Query |2 786 | | Q(0,{}) | 787 | Start 3|<--------------------| 788 (QT)<--------------------------| | 789 | Q(0,{}) | | 790 |<--------------------| | 791 4| R({G:INCLUDE({S})}) | Membership Update | 792 |-------------------->|5 R({G:INCLUDE({S})})| 793 | |====================>|6b 794 Leave(S,G) : : : 795 ()--------->|7 R({G:BLOCK({S})}) | Membership Update | 796 |-------------------->|8 R({G:BLOCK({S})}) | 797 | |====================>|9b Prune(S,G) 798 | | |---------->() 799 : : : 801 Membership Update Sequence (IGMPv3/MLDv2 Example) 803 The following sequence describes how the Request, Membership Query, 804 and Membership Update messages are used to report current group 805 membership state or changes in group membership state: 807 1. A gateway sends a Request message to the relay that contains a 808 random nonce and a flag indicating whether the relay should 809 return an IGMPv3 or MLDv2 general query. 811 2. When the relay receives a Request message, it generates a 812 message authentication code (MAC) by computing a hash value from 813 a private secret and the nonce, source IP address, and source 814 UDP port carried by the Request message. The relay then sends a 815 Membership Query message to the gateway that contains the 816 request nonce, the MAC, and an IGMPv3 or MLDv2 general query. 818 3. When the gateway receives a Membership Query message, it 819 verifies that the request nonce matches the one sent in the last 820 Request, and if it does, the gateway saves the request nonce and 821 MAC for use in sending subsequent Membership Update messages. 822 The gateway starts a timer whose expiration will trigger the 823 transmission of a new Request message and extracts the 824 encapsulated general query message for processing by the IGMP or 825 MLD protocol. The query timer duration is specified by the 826 relay in the QQIC field in the IGMPv3 or MLDv2 general query. 828 4. The gateway's IGMP or MLD protocol implementation processes the 829 general query to produce a current-state report. 831 5. When an IGMP or MLD report is passed to the pseudo-interface, 832 the gateway encapsulates the report in a Membership Update 833 message and sends it to the relay. The request nonce and MAC 834 fields in the Membership Update are assigned the values from the 835 last Membership Query message received for the corresponding 836 group membership protocol (IGMPv3 or MLDv2). 838 6. When the relay receives a Membership Update message, it computes 839 a MAC from a private secret and the request nonce, source IP 840 address, and source UDP port carried by the message. The relay 841 accepts the Membership Update message if the received MAC 842 matches the computed MAC, otherwise the message is ignored. If 843 the message is accepted, the relay may proceed to allocate, 844 refresh, or modify tunnel state. This includes making any group 845 membership, routing and forwarding state changes and issuing any 846 upstream protocol requests required to satisfy the state change. 847 The diagram illustrates two scenarios: 849 A. The gateway has not previously reported any group 850 subscriptions and the report does not contain any group 851 subscriptions, so the relay takes no action. 853 B. The gateway has previously reported a group subscription so 854 the current-state report lists all current subscriptions. 855 The relay responds by refreshing tunnel or group state and 856 resetting any related timers. 858 7. A receiver indicates to the gateway that it wishes to join 859 (allow) or leave (block) specific multicast traffic. This 860 request is typically made using some form IGMP/MLD service 861 interface (as described in Section 2 of [RFC3376] or Section 3 862 of [RFC3810]). The IGMP/MLD protocol responds by generating an 863 IGMP or MLD state-change message. 865 8. When an IGMP or MLD report/leave/done message is passed to the 866 pseudo-interface, the gateway encapsulates the message in a 867 Membership Update message and sends it to the relay. The 868 request nonce and MAC fields in the Membership Update are 869 assigned the values from the last Membership Query message 870 received for the corresponding group membership protocol (IGMP 871 or MLD). 873 The IGMP and MLD protocols may generate multiple messages to 874 provide robustness against packet loss - each of these must be 875 encapsulated in a new Membership Update message and sent to the 876 relay. The Querier Robustness Variable (QRV) field in the last 877 IGMP/MLD query delivered to the IGMP/MLD protocol is typically 878 used to specify the number of repetitions (i.e., the host adopts 879 the QRV value as its own Robustness Variable value). 881 9. When the relay receives a Membership Update message, it again 882 computes a MAC from a private secret and the request nonce, 883 source IP address, and source UDP port carried by the message. 884 The relay accepts the Membership Update message if the received 885 MAC matches the computed MAC, otherwise the message is ignored. 886 If the message is accepted, the relay processes the encapsulated 887 IGMP/MLD and allocates, modifies or deletes tunnel state 888 accordingly. This includes making any group membership, routing 889 and forwarding state changes and issuing any upstream protocol 890 requests required to satisfy the state change. The diagram 891 illustrates two scenarios: 893 A. The gateway wishes to add a group subscription. 895 B. The gateway wishes to delete a previously reported group 896 subscription. 898 10. Multicast datagrams transmitted from a source travel through the 899 native multicast infrastructure to the relay. When the relay 900 receives a multicast IP datagram that carries a source and 901 destination address for which a gateway has expressed an 902 interest in receiving (via the Membership Update message), it 903 encapsulates the datagram into a Multicast Data message and 904 sends it to the gateway using the source IP address and UDP port 905 carried by the Membership Update message as the destination 906 address. 908 11. When the gateway receives a Multicast Data message, it extracts 909 the multicast packet from the message and passes it on to the 910 appropriate receivers. 912 12. When the query timer expires the gateway sends a new Request 913 message to the relay to start a new membership update cycle. 915 The MAC-based source-authentication mechanism described above 916 provides a simple defense against malicious attempts to exhaust relay 917 resources via source-address spoofing. Flooding a relay with spoofed 918 Request or Membership Update messages may consume computational 919 resources and network bandwidth, but will not result in the 920 allocation of state because the Request message is stateless and 921 spoofed Membership Update messages will fail source-authentication 922 and be rejected by the relay. 924 A relay will only allocate new tunnel state if the IGMP/MLD report 925 carried by the Membership Update message creates one or more group 926 subscriptions. 928 A relay deallocates tunnel state after one of the following events; 929 the gateway sends a Membership Update message containing a report 930 that results in the deletion of all remaining group subscriptions, 931 the IGMP/MLD state expires (due to lack of refresh by the gateway), 932 or the relay receives a valid Teardown message from the gateway. 934 A gateway that accepts or reports group subscriptions for both IPv4 935 and IPv6 addresses will send separate Request and Membership Update 936 messages for each protocol (IPv4/IGMP and IPv6/MLD). 938 4.2.1.3. Teardown Sequence 940 A gateway sends a Teardown message to a relay to request that it stop 941 delivering Multicast Data messages to a tunnel endpoint created by an 942 earlier Membership Update message. This message is intended to be 943 used following a gateway address change (See Section 4.2.2.1) to stop 944 the transmission of undeliverable or duplicate multicast data 945 messages. Support for the Teardown message is optional - gateways 946 are not required to send them and relays are not required to act upon 947 them. 949 Gateway Relay 950 ------- ----- 951 : Request : 952 [1] | N | 953 |---------------------->| 954 | Membership Query | [2] 955 | N,MAC,gADDR,gPORT | 956 |<======================| 957 [3] | Membership Update | 958 | ({G:INCLUDE({S})}) | 959 |======================>| 960 | | 961 ----------------------:-----------------------:---------------------- 962 | | | | 963 | | *Multicast Data | *IP Packet(S,G) | 964 | | gADDR,gPORT |<------------------() | 965 | *IP Packet(S,G) |<======================| | 966 | ()<------------------| | | 967 | | | | 968 ----------------------:-----------------------:---------------------- 969 ~ | 970 ~ Request | 971 [4] | N' | 972 |---------------------->| 973 | Membership Query | [5] 974 | N',MAC',gADDR',gPORT' | 975 |<======================| 976 [6] | | 977 | Teardown | 978 | N,MAC,gADDR,gPORT | 979 |---------------------->| 980 | | [7] 981 | Membership Update | 982 | ({G:INCLUDE({S})}) | 983 |======================>| 984 | | 985 ----------------------:-----------------------:---------------------- 986 | | | | 987 | | *Multicast Data | *IP Packet(S,G) | 988 | | gADDR',gPORT' |<------------------() | 989 | *IP Packet (S,G) |<======================| | 990 | ()<------------------| | | 991 | | | | 992 ----------------------:-----------------------:---------------------- 993 | | 994 : : 996 Figure 3: Teardown Message Sequence (IGMPv3/MLDv2 Example) 998 The following sequence describes how the Membership Query and 999 Teardown message are used to detect an address change and stop the 1000 delivery of Multicast Data messages to an address: 1002 1. A gateway sends a Request message containing a random nonce to 1003 the relay. 1005 2. The relay sends a Membership Query message to the gateway that 1006 contains the source IP address (gADDR) and source UDP port 1007 (gPORT) values from the Request message. These values will be 1008 used to identify the tunnel should one be created by a subsequent 1009 Membership Update message. 1011 3. When the gateway receives a Membership Query message that carries 1012 the gateway address fields, it compares the gateway IP address 1013 and port number values with those received in the previous 1014 Membership Query (if any). If these values do not match, this 1015 indicates that the Request message arrived at the relay carrying 1016 a different source address than the one sent previously. At this 1017 point in the sequence, no change in source address or port has 1018 occurred. 1020 4. The gateway sends a new Request message to the relay. However, 1021 this Request message arrives at the relay carrying a different 1022 source address than that of the previous Request due to some 1023 change in network interface, address assignment, network topology 1024 or NAT mapping. 1026 5. The relay again responds by sending a Membership Query message to 1027 the gateway that contains the new source IP address (gADDR') and 1028 source UDP port (gPORT') values from the Request message. 1030 6. When the gateway receives the Membership Query message, it 1031 compares the gateway address and port number values against those 1032 returned in the previous Membership Query message. 1034 7. If the reported address or port has changed, the gateway sends a 1035 Teardown message to the relay that contains the request nonce, 1036 MAC, gateway IP address and gateway port number returned in the 1037 earlier Membership Query message. The gateway may send the 1038 Teardown message multiple times where the number of repetitions 1039 is governed by the Querier Robustness Variable (QRV) value 1040 contained in the IGMPv3/MLDv2 general query carried by the 1041 original Membership Query. The gateway continues to process the 1042 new Membership Query message as usual. 1044 8. When the relay receives a Teardown message, it computes a MAC 1045 from a private secret and the request nonce, gateway IP address, 1046 and gateway port number carried by the Teardown message. The 1047 relay accepts the Teardown message if the received MAC matches 1048 the computed MAC, otherwise the message is ignored. If the 1049 message is accepted, the relay makes any group membership, 1050 routing and forwarding state changes required to stop the 1051 transmission of Multicast Data messages to that address. 1053 4.2.1.4. Timeout and Retransmission 1055 The AMT protocol does not establish any requirements regarding what 1056 actions a gateway should take if it fails to receive a response from 1057 a relay. A gateway implementation may wait for an indefinite period 1058 of time to receive a response, may set a time limit on how long to 1059 wait for a response, may retransmit messages should the time limit be 1060 reached, may limit the number of retransmissions, or may simply 1061 report an error. 1063 For example, a gateway may retransmit a Request message if it fails 1064 to receive a Membership Query or expected Multicast Data messages 1065 within some time period. If the gateway fails to receive any 1066 response to a Request after several retransmissions or within some 1067 maximum period of time, it may reenter the relay discovery phase in 1068 an attempt to find a new relay. This topic is addressed in more 1069 detail in Section 5.2. 1071 4.2.2. Tunneling 1073 From the standpoint of a relay, an AMT "tunnel" is identified by the 1074 IP address and UDP port pair used as the destination address for 1075 sending encapsulated multicast IP datagrams to a gateway. This 1076 address is referred here as the tunnel endpoint address. 1078 A gateway sends a Membership Update message to a relay to add or 1079 remove group subscriptions to a tunnel endpoint. The tunnel endpoint 1080 is identified by the source IP address and source UDP port carried by 1081 the Membership Update message when it arrives at a relay (this 1082 address may differ from that carried by the message when it exited 1083 the gateway as a result of network address translation). 1085 The Membership Update messages sent by a single gateway host may 1086 originate from several source addresses or ports - each unique 1087 combination represents a unique tunnel endpoint. A single gateway 1088 host may legitimately create and accept traffic on multiple tunnel 1089 endpoints, e.g., the gateway may use separate ports for the IPv4/IGMP 1090 and IPv6/MLD protocols. 1092 A tunnel is "created" when a gateway sends a Membership Update 1093 message containing an IGMP or MLD membership report that creates one 1094 or more group subscriptions when none currently existed for that 1095 tunnel endpoint address. 1097 A tunnel ceases to exist when all group subscriptions for a tunnel 1098 endpoint are deleted. This may occur as a result of the following 1099 events: 1101 o The gateway sends an IGMP or MLD report, leave or done message to 1102 the relay that deletes the last group subscription linked to the 1103 tunnel endpoint. 1105 o The gateway sends a Teardown message to the relay that causes it 1106 to delete any and all subscriptions bound to the tunnel endpoint. 1108 o The relay stops receiving updates from the gateway until such time 1109 that per-group or per-tunnel timers expire, causing the relay to 1110 delete the subscriptions. 1112 The tunneling approach described above conceptually transforms a 1113 unicast-only inter-network into an NBMA link layer, over which 1114 multicast traffic may be delivered. Each relay, plus the set of all 1115 gateways using the relay, together may be thought of as being on a 1116 separate logical NBMA link, where the "link layer" address is a 1117 UDP/IP address-port pair provided by the Membership Update message. 1119 4.2.2.1. Address Roaming 1121 As described above, each time a relay receives a Membership Update 1122 message from a new source address-port pair, the group subscriptions 1123 described by that message apply to the tunnel endpoint identified by 1124 that address. 1126 This can cause problems for a gateway if the address carried by the 1127 messages it sends to a relay change unexpectedly. These changes may 1128 cause the relay to transmit duplicate, undeliverable or unrequested 1129 traffic back towards the gateway or an intermediate device. This may 1130 create congestion and have negative consequences for the gateway, its 1131 network, or multicast receivers, and in some cases, may also produce 1132 a significant amount of ICMP traffic directed back towards the relay 1133 by a NAT, router or gateway host. 1135 There are several scenarios in which the address carried by messages 1136 sent by a gateway may change without that gateway's knowledge, as for 1137 example, when: 1139 o The message originates from a different interface on a gateway 1140 that possesses multiple interfaces. 1142 o The DHCP assignment for a gateway interface changes. 1144 o The gateway roams to a different wireless network. 1146 o The address mapping applied by an intervening network-translation- 1147 device (NAT) changes as a result of mapping expiration or routing 1148 changes in a multi-homed network. 1150 In the case where the address change occurs between the transmission 1151 of a Request message and subsequent Membership Update messages, the 1152 relay will simply ignore any Membership Update messages from the new 1153 address because MAC authentication will fail (see Section 4.2.1.2). 1154 The relay may continue to transmit previously requested traffic, but 1155 no duplication will occur, i.e., the possibility for the delivery of 1156 duplicate traffic does not arise until a Request message is received 1157 from the new address. 1159 The protocol provides a method for a gateway to detect an address 1160 change and explicitly request that the relay stop sending traffic to 1161 a previous address. This process involves the Membership Query and 1162 Teardown messages and is described in Section 4.2.1.3. 1164 4.2.2.2. Network Address Translation 1166 The messages sent by a gateway to a relay may be subject to network 1167 address translation (NAT) - the source IP address and UDP port 1168 carried by an IP packet sent by the gateway may be modified multiple 1169 times before arriving at the relay. In the most restrictive form of 1170 NAT, the NAT device will create a new mapping for each combination of 1171 source and destination IP address and UDP port. In this case, bi- 1172 directional communication can only be conducted by sending outgoing 1173 packets to the source address and port carried by the last incoming 1174 packet. 1176 Membership Update Membership Update 1177 src: iADDR:iPORT src: eADDR:ePORT 1178 dst: rADDR:rPORT dst: rADDR:rPORT 1179 +---------+ 1180 | NAT | 1181 +---------+ +-----------+ +---------+ 1182 | |---------->| |--------->| | 1183 | Gateway | | Mapping | | Relay | 1184 | |<----------| |<---------| | 1185 +---------+ +-----------+ +---------+ 1186 | | 1187 +---------+ 1188 Multicast Data Multicast Data 1189 src: rADDR:rPORT src: rADDR:rPORT 1190 dst: iADDR:iPORT dst: eADDR:ePORT 1192 Network Address Translation in AMT 1194 AMT provides automatic NAT traversal by using the source IP address 1195 and UDP port carried by the Membership Update message as received at 1196 the relay as the destination address for any Multicast Data messages 1197 the relay sends back as a result. 1199 The NAT mapping created by a Membership Update message will 1200 eventually expire unless it is refreshed by a passing message. This 1201 refresh will occur each time the gateway performs the periodic update 1202 required to refresh group state within the relay (See 1203 Section 4.2.1.2). 1205 4.2.2.3. UDP Encapsulation 1207 Gateway Relay 1209 IP:IGMP IP:IGMP 1210 | AMT:IP:IGMP AMT:IP:IGMP | 1211 | | | | 1212 | | IP:UDP:AMT:IP:IGMP | | 1213 _______ | ___ | ______ | ______ | ___ | _______ 1214 |IGMP|IP| v |AMT| v |UDP|IP| v |IP|UDP| v |AMT| v |IP|IGMP| 1215 | | | | | | | | | | | | | | | | 1216 | |<------------------------------------------------------->| | 1217 |____| | | | | | | | | | | | | |____| 1218 | |<--------------------------------------------------| | 1219 |_______| ^ |___| ^ |___|__| ^ |__|___| ^ |___| ^ |_______| 1220 | | | | | 1221 IP AMT:IP IP:UDP:AMT:IP AMT:IP IP 1223 AMT Encapsulation 1225 The IGMP and MLD messages used in AMT are exchanged as complete IP 1226 datagrams. These IP datagrams are encapsulated in AMT messages that 1227 are transmitted using UDP. The same holds true for multicast traffic 1228 - each multicast IP datagram that arrives at the relay is 1229 encapsulated in an AMT message and transmitted to one or more 1230 gateways via UDP. 1232 The IP protocol of the encapsulated packets need not match the IP 1233 protocol used to send the AMT messages. AMT messages sent via IPv4 1234 may carry IPv6/MLD packets and AMT messages sent via IPv6 may carry 1235 IPv4/IGMP packets. 1237 The checksum field contained in the UDP header of the messages 1238 requires special consideration. Of primary concern is the cost of 1239 computing a checksum on each replicated multicast packet after it is 1240 encapsulated for delivery to a gateway. Many routing/forwarding 1241 platforms do not possess the capability to compute checksums on UDP 1242 encapsulated packets as they may not have access to the entire 1243 datagram. 1245 To avoid placing an undue burden on the relay platform, the protocol 1246 specifically allows zero-valued UDP checksums on the multicast data 1247 messages. This is not an issue in UDP over IPv4 as the UDP checksum 1248 field may be set to zero. However, this is a problem for UDP over 1249 IPv6 as that protocol requires a valid, non-zero checksum in UDP 1250 datagrams [RFC2460]. Messages sent over IPv6 with a UDP checksum of 1251 zero may fail to reach the gateway. This is a well known issue for 1252 UDP-based tunneling protocols that is described 1253 [I-D.ietf-6man-udpzero]. A recommended solution is described in 1254 [I-D.ietf-6man-udpchecksums]. 1256 5. Protocol Description 1258 This section provides a normative description of the AMT protocol. 1260 5.1. Protocol Messages 1262 The AMT protocol defines seven message types for control and 1263 encapsulation. These messages are assigned the following names and 1264 numeric identifiers: 1266 +--------------+---------------------+ 1267 | Message Type | Message Name | 1268 +--------------+---------------------+ 1269 | 1 | Relay Discovery | 1270 | | | 1271 | 2 | Relay Advertisement | 1272 | | | 1273 | 3 | Request | 1274 | | | 1275 | 4 | Membership Query | 1276 | | | 1277 | 5 | Membership Update | 1278 | | | 1279 | 6 | Multicast Data | 1280 | | | 1281 | 7 | Teardown | 1282 +--------------+---------------------+ 1284 These messages are exchanged as IPv4 or IPv6 UDP datagrams. 1286 5.1.1. Relay Discovery 1288 A Relay Discovery message is used to solicit a response from a relay 1289 in the form of a Relay Advertisement message. 1291 The UDP/IP datagram containing this message MUST carry a valid, non- 1292 zero UDP checksum and carry the following IP address and UDP port 1293 values: 1295 Source IP Address - The IP address of the gateway interface on which 1296 the gateway will listen for a relay response. Note: The value of 1297 this field may be changed as a result of network address 1298 translation before arriving at the relay. 1300 Source UDP Port - The UDP port number on which the gateway will 1301 listen for a relay response. Note: The value of this field may be 1302 changed as a result of network address translation before arriving 1303 at the relay. 1305 Destination IP Address - An anycast or unicast IP address, i.e. the 1306 Relay Discovery Address advertised by a relay. 1308 Destination UDP Port - The IANA-assigned AMT port number. 1310 0 1 2 3 1311 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 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | V=0 |Type=1 | Reserved | 1314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1315 | Discovery Nonce | 1316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 Relay Discovery Message Format 1320 5.1.1.1. Version (V) 1322 The protocol version number for this message is 0. 1324 5.1.1.2. Type 1326 The type number for this message is 1. 1328 5.1.1.3. Reserved 1330 Reserved bits that MUST be set to zero by the gateway and ignored by 1331 the relay. 1333 5.1.1.4. Discovery Nonce 1335 A 32-bit random value generated by the gateway and echoed by the 1336 relay in a Relay Advertisement message. This value is used by the 1337 gateway to correlate Relay Advertisement messages with Relay 1338 Discovery messages. Discovery nonce generation is described in 1339 Section 5.2.3.4.5. 1341 5.1.2. Relay Advertisement 1343 The Relay Advertisement message is used to supply a gateway with a 1344 unicast IP address of a relay. A relay sends this message to a 1345 gateway when it receives a Relay Discovery message from that gateway. 1347 The UDP/IP datagram containing this message MUST carry a valid, non- 1348 zero UDP checksum and carry the following IP address and UDP port 1349 values: 1351 Source IP Address - The destination IP address carried by the Relay 1352 Discovery message (i.e. the Relay Discovery Address advertised by 1353 the relay). 1355 Source UDP Port - The destination UDP port carried by the Relay 1356 Discovery message (i.e. the IANA-assigned AMT port number). 1358 Destination IP Address - The source IP address carried by the Relay 1359 Discovery message. Note: The value of this field may be changed 1360 as a result of network address translation before arriving at the 1361 gateway. 1363 Destination UDP Port - The source UDP port carried by the Relay 1364 Discovery message. Note: The value of this field may be changed 1365 as a result of network address translation before arriving at the 1366 gateway. 1368 0 1 2 3 1369 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 1370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1371 | V=0 |Type=2 | Reserved | 1372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1373 | Discovery Nonce | 1374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1375 | | 1376 ~ Relay Address (IPv4 or IPv6) ~ 1377 | | 1378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1380 Relay Advertisement Message Format 1382 5.1.2.1. Version (V) 1384 The protocol version number for this message is 0. 1386 5.1.2.2. Type 1388 The type number for this message is 2. 1390 5.1.2.3. Reserved 1392 Reserved bits that MUST be set to zero by the relay and ignored by 1393 the gateway. 1395 5.1.2.4. Discovery Nonce 1397 A 32-bit value copied from the Discovery Nonce field 1398 (Section 5.1.1.4) contained in the Relay Discovery message. The 1399 gateway uses this value to match a Relay Advertisement to a Relay 1400 Discovery message. 1402 5.1.2.5. Relay Address 1404 The unicast IPv4 or IPv6 address of the relay. A gateway uses the 1405 length of the UDP datagram containing the Relay Advertisement message 1406 to determine the address family; i.e. length - 8 = 4 (IPv4) or 16 1407 (IPv6). 1409 5.1.3. Request 1411 A gateway sends a Request message to a relay to solicit a Membership 1412 Query response. 1414 The successful delivery of this message marks the start of the first 1415 stage in the three-way handshake used to create or update state 1416 within a relay. 1418 The UDP/IP datagram containing this message MUST carry a valid, non- 1419 zero UDP checksum and carry the following IP address and UDP port 1420 values: 1422 Source IP Address - The IP address of the gateway interface on which 1423 the gateway will listen for a response from the relay. Note: The 1424 value of this field may be changed as a result of network address 1425 translation before arriving at the relay. 1427 Source UDP Port - The UDP port number on which the gateway will 1428 listen for a response from the relay. Note: The value of this 1429 field may be changed as a result of network address translation 1430 before arriving at the relay. 1432 Destination IP Address - The unicast IP address of the relay. 1434 Destination UDP Port - The IANA-assigned AMT port number. 1436 0 1 2 3 1437 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 1438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1439 | V=0 |Type=3 | Reserved |P| Reserved | 1440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1441 | Request Nonce | 1442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1443 Request Message Format 1445 5.1.3.1. Version (V) 1447 The protocol version number for this message is 0. 1449 5.1.3.2. Type 1451 The type number for this message is 3. 1453 5.1.3.3. Reserved 1455 Reserved bits that MUST be set to zero by the gateway and ignored by 1456 the relay. 1458 5.1.3.4. P Flag 1460 The "P" flag is set to indicate which group membership protocol the 1461 gateway wishes the relay to use in the Membership Query response: 1463 Value Meaning 1465 0 The relay MUST respond with a Membership Query message that 1466 contains an IPv4 packet carrying an IGMPv3 general query 1467 message. 1469 1 The relay MUST respond with a Membership Query message that 1470 contains an IPv6 packet carrying an MLDv2 general query 1471 message. 1473 5.1.3.5. Request Nonce 1475 A 32-bit random value generated by the gateway and echoed by the 1476 relay in a Membership Query message. This value is used by the relay 1477 to compute the Response MAC value and is used by the gateway to 1478 correlate Membership Query messages with Request messages. Request 1479 nonce generation is described in Section 5.2.3.5.6. 1481 5.1.4. Membership Query 1483 A relay sends a Membership Query message to a gateway to solicit a 1484 Membership Update response, but only after receiving a Request 1485 message from the gateway. 1487 The successful delivery of this message to a gateway marks the start 1488 of the second-stage in the three-way handshake used to create or 1489 update tunnel state within a relay. 1491 The UDP/IP datagram containing this message MUST carry a valid, non- 1492 zero UDP checksum and carry the following IP address and UDP port 1493 values: 1495 Source IP Address - The destination IP address carried by the 1496 Request message (i.e. the unicast IP address of the relay). 1498 Source UDP Port - The destination UDP port carried by the Request 1499 message (i.e. the IANA-assigned AMT port number). 1501 Destination IP Address - The source IP address carried by the 1502 Request message. Note: The value of this field may be changed as 1503 a result of network address translation before arriving at the 1504 gateway. 1506 Destination UDP Port - The source UDP port carried by the Request 1507 message. Note: The value of this field may be changed as a result 1508 of network address translation before arriving at the gateway. 1510 0 1 2 3 1511 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 1512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1513 | V=0 |Type=4 | Reserved |L|G| Response MAC | 1514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1515 | | 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | Request Nonce | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1519 | | 1520 | Encapsulated General Query Message | 1521 ~ IPv4:IGMPv3(Membership Query) ~ 1522 | IPv6:MLDv2(Listener Query) | 1523 | | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 | Gateway Port Number | | 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1527 | | 1528 + + 1529 | Gateway IP Address (IPv4 or IPv6) | 1530 + + 1531 | | 1532 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1536 Membership Query Message Format 1538 5.1.4.1. Version (V) 1540 The protocol version number for this message is 0. 1542 5.1.4.2. Type 1544 The type number for this message is 4. 1546 5.1.4.3. Reserved 1548 Reserved bits that MUST be set to zero by the relay and ignored by 1549 the gateway. 1551 5.1.4.4. Limit (L) Flag 1553 A 1-bit flag set to 1 to indicate that the relay is NOT accepting 1554 Membership Update messages from new gateway tunnel endpoints and that 1555 it will ignore any that are. A value of 0 has no special 1556 significance - the relay may or may not be accepting Membership 1557 Update messages from new gateway tunnel endpoints. A gateway checks 1558 this flag before attempting to create new group subscription state on 1559 the relay to determine whether it should restart relay discovery. A 1560 gateway that has already created group subscriptions on the relay may 1561 ignore this flag. Support for this flag is RECOMMENDED. 1563 5.1.4.5. Gateway Address (G) Flag 1565 A 1-bit flag set to 0 to indicate that the message does NOT carry the 1566 Gateway Port and Gateway IP Address fields, and 1 to indicate that it 1567 does. A relay implementation that supports the optional teardown 1568 procedure (See Section 5.3.3.5) SHOULD set this flag and and the 1569 Gateway Address field values. If a relay sets this flag, it MUST 1570 also include the Gateway Address fields in the message. A gateway 1571 implementation that does not support the optional teardown procedure 1572 (See Section 5.2.3.7) MAY ignore this flag and the Gateway Address 1573 fields if they are present. 1575 5.1.4.6. Response MAC 1577 A 48-bit source authentication hash generated by the relay as 1578 described in Section 5.3.5. The gateway echoes this value in 1579 subsequent Membership Update messages to allow the relay to verify 1580 that the sender of a Membership Update message was the intended 1581 receiver of a Membership Query sent by the relay. 1583 5.1.4.7. Request Nonce 1585 A 32-bit value copied from the Request Nonce field (Section 5.1.3.5) 1586 carried by a Request message. The relay will have included this 1587 value in the Response MAC hash computation. The gateway echoes this 1588 value in subsequent Membership Update messages. The gateway also 1589 uses this value to match a Membership Query to a Request message. 1591 5.1.4.8. Encapsulated General Query Message 1593 An IP-encapsulated IGMP or MLD message generated by the relay. This 1594 field will contain one of the following IP datagrams: 1596 IPv4:IGMPv3 Membership Query 1598 IPv6:MLDv2 Listener Query 1600 The source address carried by the query message should be set as 1601 described in Section 5.3.3.3. 1603 The Querier's Query Interval Code (QQIC) field in the general query 1604 is used by a relay to specify the time offset a gateway should use to 1605 schedule a new three-way handshake to refresh the group membership 1606 state within the relay (current time + Query Interval). 1608 The Querier's Robustness Variable (QRV) field in the general query is 1609 used by a relay to specify the number of times a gateway should 1610 retransmit unsolicited membership reports, encapsulated within 1611 Membership Update messages, and optionally, the number of times to 1612 send a Teardown message. 1614 5.1.4.9. Gateway Address Fields 1616 The Gateway Port Number and Gateway Address fields are present in the 1617 Membership Query message if, and only if, the "G" flag is set. 1619 A gateway need not parse the encapsulated IP datagram to determine 1620 the position of these fields within the UDP datagram containing the 1621 Membership Query messsage - if the G-flag is set, the gateway may 1622 simply subtract the total length of the fields (18 bytes) from the 1623 total length of the UDP datagram to obtain the offset. 1625 5.1.4.9.1. Gateway Port Number 1627 A 16-bit UDP port containing a UDP port value. 1629 The Relay sets this field to the value of the UDP source port of the 1630 Request message that triggered the Query message. 1632 5.1.4.9.2. Gateway IP Address 1634 A 16-byte IP address that, when combined with the value contained in 1635 the Gateway Port Number field, forms the gateway endpoint address 1636 that the relay will use to identify the tunnel instance, if any, 1637 created by a subsequent Membership Update message. This field may 1638 contain an IPv6 address or an IPv4 address stored as an IPv4- 1639 compatible IPv6 address, where the IPv4 address is prefixed with 96 1640 bits set to zero (See [RFC4291]). This address must match that used 1641 by the relay to compute the value stored in the Response MAC field. 1643 5.1.5. Membership Update 1645 A gateway sends a Membership Update message to a relay to report a 1646 change in group membership state, or to report the current group 1647 membership state in response to receiving a Membership Query message. 1648 The gateway encapsulates the IGMP or MLD message as an IP datagram 1649 within a Membership Update message and sends it to the relay, where 1650 it may (see below) be decapsulated and processed by the relay to 1651 update group membership and forwarding state. 1653 A gateway cannot send a Membership Update message until a receives a 1654 Membership Query from a relay because the gateway must copy the 1655 Request Nonce and Response MAC values carried by a Membership Query 1656 into any subsequent Membership Update messages it sends back to that 1657 relay. These values are used by the relay to verify that the sender 1658 of the Membership Update message was the recipient of the Membership 1659 Query message from which these values were copied. 1661 The successful delivery of this message to the relay marks the start 1662 of the final stage in the three-way handshake. This stage concludes 1663 when the relay successfully verifies that sender of the Message 1664 Update message was the recipient of a Membership Query message sent 1665 earlier. At this point, the relay may proceed to process the 1666 encapsulated IGMP or MLD message to create or update group membership 1667 and forwarding state on behalf of the gateway. 1669 The UDP/IP datagram containing this message MUST carry a valid, non- 1670 zero UDP checksum and carry the following IP address and UDP port 1671 values: 1673 Source IP Address - The IP address of the gateway interface on which 1674 the gateway will listen for Multicast Data messages from the 1675 relay. The address must be the same address used to send the 1676 initial Request message or the message will be ignored. Note: The 1677 value of this field may be changed as a result of network address 1678 translation before arriving at the relay. 1680 Source UDP Port - The UDP port number on which the gateway will 1681 listen for Multicast Data messages from the relay. This port must 1682 be the same port used to send the initial Request message or the 1683 message will be ignored. Note: The value of this field may be 1684 changed as a result of network address translation before arriving 1685 at the relay. 1687 Destination IP Address - The unicast IP address of the relay. 1689 Destination UDP Port - The IANA-assigned AMT UDP port number. 1691 0 1 2 3 1692 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 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | V=0 |Type=5 | Reserved | Response MAC | 1695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1696 | | 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | Request Nonce | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 | | 1701 | Encapsulated Group Membership Update Message | 1702 ~ IPv4:IGMP(Membership Report|Leave Group) ~ 1703 | IPv6:MLD(Listener Report|Listener Done) | 1704 | | 1705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 Membership Update Message Format 1709 5.1.5.1. Version (V) 1711 The protocol version number for this message is 0. 1713 5.1.5.2. Type 1715 The type number for this message is 5. 1717 5.1.5.3. Reserved 1719 Reserved bits that MUST be set to zero by the gateway and ignored by 1720 the relay. 1722 5.1.5.4. Response MAC 1724 A 48-bit value copied from the Response MAC field (Section 5.1.4.6) 1725 in a Membership Query message. Used by the relay to perform source 1726 authentication. 1728 5.1.5.5. Request Nonce 1730 A 32-bit value copied from the Request Nonce field in a Request or 1731 Membership Query message. Used by the relay to perform source 1732 authentication. 1734 5.1.5.6. Encapsulated Group Membership Update Message 1736 An IP-encapsulated IGMP or MLD message produced by the host-mode IGMP 1737 or MLD protocol running on a gateway pseudo-interface. This field 1738 will contain of one of the following IP datagrams: 1740 IPv4:IGMPv2 Membership Report 1742 IPv4:IGMPv2 Leave Group 1744 IPv4:IGMPv3 Membership Report 1746 IPv6:MLDv1 Multicast Listener Report 1748 IPv6:MLDv1 Multicast Listener Done 1750 IPv6:MLDv2 Multicast Listener Report 1752 The source address carried by the message should be set as described 1753 in Section 5.2.1. 1755 5.1.6. Multicast Data 1757 A relay sends a Multicast Data message to deliver an IP multicast 1758 packet to a gateway. 1760 The checksum field in the UDP header of this message MAY contain a 1761 value of zero when sent over IPv4 but SHOULD, if possible, contain a 1762 valid, non-zero value when sent over IPv6 (See Section 4.2.2.3). 1764 The UDP/IP datagram containing this message MUST carry the following 1765 IP address and UDP port values: 1767 Source IP Address - The unicast IP address of the relay. 1769 Source UDP Port - The IANA-assigned AMT port number. 1771 Destination IP Address - A tunnel endpoint IP address, i.e. the 1772 source IP address carried by the Membership Update message sent by 1773 a gateway to indicate an interest in receiving the multicast 1774 packet. Note: The value of this field may be changed as a result 1775 of network address translation before arriving at the gateway. 1777 Destination UDP Port - A tunnel endpoint UDP port, i.e. the source 1778 UDP port carried by the Membership Update message sent by a 1779 gateway to indicate an interest in receiving the multicast packet. 1780 Note: The value of this field may be changed as a result of 1781 network address translation before arriving at the gateway. 1783 0 1 2 3 1784 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 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | V=0 |Type=6 | Reserved | | 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1788 | | 1789 ~ IP Multicast Packet ~ 1790 | | 1791 + - - - - - - - - - - - - - - - - - - - - - - - -+ 1792 | : : : : 1793 +-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - - 1795 Multicast Data Message Format 1797 5.1.6.1. Version (V) 1799 The protocol version number for this message is 0. 1801 5.1.6.2. Type 1803 The type number for this message is 6. 1805 5.1.6.3. Reserved 1807 Bits that MUST be set to zero by the relay and ignored by the 1808 gateway. 1810 5.1.6.4. IP Multicast Data 1812 A complete IPv4 or IPv6 Multicast datagram. 1814 5.1.7. Teardown 1816 A gateway sends a Teardown message to a relay to request that it stop 1817 sending Multicast Data messages to a tunnel endpoint created by an 1818 earlier Membership Update message. A gateway sends this message when 1819 it detects that a Request message sent to the relay carries an 1820 address that differs from that carried by a previous Request message. 1821 The gateway uses the Gateway IP Address and Gateway Port Number 1822 Fields in the Membership Query message to detect these address 1823 changes. 1825 To provide backwards compatibility with early implementations of the 1826 AMT protocol, support for this message and associated procedures is 1827 considered OPTIONAL - gateways are not required to send this message 1828 and relays are not required to act upon it. 1830 The UDP/IP datagram containing this message MUST carry a valid, non- 1831 zero UDP checksum and carry the following IP address and UDP port 1832 values: 1834 Source IP Address - The IP address of the gateway interface used to 1835 send the message. This address may differ from that used to send 1836 earlier messages. Note: The value of this field may be changed as 1837 a result of network address translation before arriving at the 1838 relay. 1840 Source UDP Port - The UDP port number. This port number may differ 1841 from that used to send earlier messages. Note: The value of this 1842 field may be changed as a result of network address translation 1843 before arriving at the relay. 1845 Destination IP Address - The unicast IP address of the relay. 1847 Destination UDP Port - The IANA-assigned AMT port number. 1849 0 1 2 3 1850 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 1851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1852 | V=0 |Type=7 | Reserved | Response MAC | 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1854 | | 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 | Request Nonce | 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1858 | Gateway Port Number | | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1860 | | 1861 + + 1862 | Gateway IP Address (IPv4 or IPv6) | 1863 + + 1864 | | 1865 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1866 | | 1867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1869 Membership Teardown Message Format 1871 5.1.7.1. Version (V) 1873 The protocol version number for this message is 0. 1875 5.1.7.2. Type 1877 The type number for this message is 7. 1879 5.1.7.3. Reserved 1881 Reserved bits that MUST be set to zero by the gateway and ignored by 1882 the relay. 1884 5.1.7.4. Response MAC 1886 A 48-bit value copied from the Response MAC field (Section 5.1.4.6) 1887 in the last Membership Query message the relay sent to the gateway 1888 endpoint address of the tunnel to be torn down. The gateway endpoint 1889 address is provided by the Gateway IP Address and Gateway Port Number 1890 fields carried by the Membership Query message. 1892 5.1.7.5. Request Nonce 1894 A 32-bit value copied from the Request Nonce field (Section 5.1.4.7) 1895 in the last Membership Query message the relay sent to the gateway 1896 endpoint address of the tunnel to be torn down. The gateway endpoint 1897 address is provided by the Gateway IP Address and Gateway Port Number 1898 fields carried by the Membership Query message. This value must 1899 match that used by the relay to compute the value stored in the 1900 Response MAC field. 1902 5.1.7.6. Gateway Port Number 1904 A 16-bit UDP port number that, when combined with the value contained 1905 in the Gateway IP Address field, forms the tunnel endpoint address 1906 that the relay will use to identify the tunnel instance to tear down. 1907 The relay provides this value to the gateway using the Gateway Port 1908 Number field (Section 5.1.4.9.1) in a Membership Query message. This 1909 port number must match that used by the relay to compute the value 1910 stored in the Response MAC field. 1912 5.1.7.7. Gateway IP Address 1914 A 16-byte IP address that, when combined with the value contained in 1915 the Gateway Port Number field, forms the tunnel endpoint address that 1916 the relay will used to identify the tunnel instance to tear down. 1917 The relay provides this value to the gateway using the Gateway IP 1918 Address field (Section 5.1.4.9.2) in a Membership Query message. 1920 This field may contain an IPv6 address or an IPv4 address stored as 1921 an IPv4-compatible IPv6 address, where the IPv4 address is prefixed 1922 with 96 bits set to zero (See [RFC4291]). This address must match 1923 that used by the relay to compute the value stored in the Response 1924 MAC field. 1926 5.2. Gateway Operation 1928 The following sections describe gateway implementation requirements. 1929 A non-normative discussion of gateway operation may be found in 1930 Section 4.2. 1932 5.2.1. IP/IGMP/MLD Protocol Requirements 1934 Gateway operation requires a subset of host mode IPv4/IGMP and IPv6/ 1935 MLD functionality to provide group membership tracking, general query 1936 processing, and report generation. A gateway MAY use IGMPv2 (ASM), 1937 IGMPv3 (ASM and SSM), MLDv1 (ASM) or MLDv2 (ASM and SSM). 1939 An application with embedded gateway functionality must provide its 1940 own implementation of this subset of the IPv4/IGMP and IPv6/MLD 1941 protocols. The service interface used to manipulate group membership 1942 state need not match that described in the IGMP and MLD 1943 specifications, but the actions taken as a result SHOULD be similar 1944 to those described in Section 5.1 of [RFC3376] and Section 6.1 of 1945 [RFC3810]. The gateway application will likely need to implement 1946 many of the same functions as a host IP stack, including checksum 1947 verification, dispatching, datagram filtering and forwarding, and IP 1948 encapsulation/decapsulation. 1950 The IP-encapsulated IGMP messages generated by the gateway IPv4/IGMP 1951 implementation MUST conform to the description found in Section 4 of 1952 [RFC3376]. These datagrams MUST possess the IP headers, header 1953 options and header values called for in [RFC3376], with the following 1954 exception; the source IP address for an IGMP report datagram MAY be 1955 set to the "unspecified" address (all octets are zero ) but SHOULD be 1956 set to an address in the address range specifically assigned by IANA 1957 for use in the IGMP messages sent from a gateway to a relay (i.e. 1958 154.7.1.2 through 154.7.1.254 as described in Section 7). This 1959 exception is made because the gateway pseudo-interface might not 1960 possess an assigned address, and even if such an address exists, that 1961 address would not be a valid link-local source address on any relay 1962 interface. The rationale for using the aforementioned source 1963 addresses is primary one of convenience - a relay will accept an IGMP 1964 report carried by a Membership Update message regardless of the 1965 source address it carries. See Section 5.3.1. 1967 The IP-encapsulated MLD messages generated by the gateway IPv6/MLD 1968 implementation MUST conform to the description found in Section 5 of 1969 [RFC3810]. These datagrams MUST possess the IP headers, header 1970 options and header values called for in [RFC3810], with the following 1971 exception; the source IP address for an MLD report datagram MAY be 1972 set to the "unspecified" address (all octets are zero ) but SHOULD be 1973 set to an IPv6 link-local address in the range FE80::/64 excluding 1974 FE80::1 and FE80::2. This exception is made because the gateway 1975 pseudo-interface might not possess a valid IPv6 address. As with 1976 IGMP, a relay will accept an MLD report carried by a Membership 1977 Update message regardless of the source address it carries. See 1978 Section 5.3.1. 1980 The gateway IGMP/MLD implementation SHOULD retransmit unsolicited 1981 membership state-change reports and merge new state change reports 1982 with pending reports as described in Section 5.1 of [RFC3376] and 1983 Section 6.1 of [RFC3810]. The number of retransmissions is specified 1984 by the relay in the Querier's Robustness Variable (QRV) field in the 1985 last general query forwarded by the pseudo-interface. 1987 The gateway IGMP/MLD implementation SHOULD handle general query 1988 messages as described in Section 5.2 of [RFC3376] and Section 6.2 of 1989 [RFC3810], but MAY ignore the Max Resp Code field value and generate 1990 a current state report without any delay. 1992 An IPv4 gateway implementation MUST accept IPv4 datagrams that carry 1993 the general query variant of the IGMPv3 Membership Query message, as 1994 described in Section 4 of [RFC3376]. The gateway MUST accept the 1995 IGMP datagram regardless of the IP source address carried by that 1996 datagram. 1998 An IPv6 gateway implementation MUST accept IPv6 datagrams that carry 1999 the general query variant of the MLDv2 Multicast Listener Query 2000 message, as described in Section 5 of [RFC3810]. The gateway MUST 2001 accept the MLD datagram regardless of the IP source address carried 2002 by that datagram. 2004 5.2.2. Pseudo-Interface Configuration 2006 A gateway host may possess or create multiple gateway pseudo- 2007 interfaces, each with a unique configuration that describes a binding 2008 to a specific IP protocol, relay address, relay discovery address or 2009 upstream network interface. 2011 5.2.2.1. Static Relay Address 2013 Before a gateway implementation can execute the AMT protocol to 2014 request and receive multicast traffic, it must be supplied with a 2015 unicast relay address. A gateway implementation may rely on static 2016 address assignment or support some form of dynamic address discovery. 2017 This specification does not require the use of any particular method 2018 to obtain a relay address - an implementation may employ any method 2019 that returns a suitable relay address. 2021 5.2.2.2. Static Relay Discovery Address 2023 If a gateway implementation uses AMT relay discovery to obtain a 2024 relay address, it must first be supplied with a relay discovery 2025 address. The relay discovery address may be an anycast or unicast 2026 address. A gateway implementation may rely on a static address 2027 assignment or some form of dynamic address discovery. This 2028 specification does not require that a gateway implementation use any 2029 particular method to obtain a relay discovery address - an 2030 implementation may employ any method that returns a suitable relay 2031 discovery address. 2033 5.2.2.3. Upstream Interface Selection 2035 A gateway host that possesses multiple network interfaces or 2036 addresses may allow for an explicit selection of the interface to use 2037 when communicating with a relay. The selection might be made to 2038 satisfy connectivity, tunneling or IP protocol requirements. 2040 5.2.2.4. Optional Retransmission Parameters 2042 A gateway implementation that supports retransmission MAY require the 2043 following information: 2045 Discovery Timeout 2046 Initial time to wait for a response to a Relay Discovery message. 2048 Maximum Relay Discovery Retransmission Count 2049 Maximum number of Relay Discovery retransmissions to allow before 2050 terminating relay discovery and reporting an error. 2052 Request Timeout 2053 Initial time to wait for a response to a Request message. 2055 Maximum Request Retransmission Count 2056 Maximum number of Request retransmissions to allow before 2057 abandoning a relay and restarting relay discovery or reporting an 2058 error. 2060 Maximum Retries Count For "Destination Unreachable" 2061 The maximum number of times a gateway should attempt to send the 2062 same Request or Membership Update message after receiving an ICMP 2063 "Destination Unreachable". 2065 5.2.3. Gateway Service 2067 In the following descriptions, a gateway pseudo interface is treated 2068 as a passive entity managed by a gateway service. The gateway 2069 pseudo-interface provides the state and the gateway service provides 2070 the processing. The term "gateway" is used when describing service 2071 behavior with respect to a single pseudo-interface. 2073 5.2.3.1. Startup 2075 When a gateway pseudo-interface is started, the gateway service 2076 begins listening for AMT messages sent to the UDP endpoint(s) 2077 associated with the pseudo-interface and for any locally-generated 2078 IGMP/MLD messages passed to the pseudo-interface. The handling of 2079 these messages is described below. 2081 When the pseudo-interface is enabled, the gateway service MAY: 2083 o Optionally execute the relay discovery procedure described in 2084 Section 5.2.3.4. 2086 o Optionally execute the membership query procedure described in 2087 Section 5.2.3.5 to start the periodic membership update cycle. 2089 5.2.3.2. Handling AMT Messages 2091 A gateway MUST ignore any datagram it receives that cannot be 2092 interpreted as a Relay Advertisement, Membership Query, or Multicast 2093 Data message. The handling of Relay Advertisement, Membership Query, 2094 and Multicast Data messages is addressed in the sections that follow. 2096 While listening for AMT messages, a gateway may be notified that an 2097 ICMP Destination Unreachable message was received as a result of an 2098 AMT message transmission. Handling of ICMP Destination Unreachable 2099 messages is described in Section 5.2.3.9. 2101 5.2.3.3. Handling Multicast Data Messages 2103 A gateway may receive Multicast Data messages after it sends a 2104 Membership Update message to a relay that adds a group subscription. 2105 The gateway may continue to receive Multicast Data messages long 2106 after the gateway sends a Membership Update message that deletes 2107 existing group subscriptions. The gateway MUST be prepared to 2108 receive these messages at any time, but MAY ignore them or discard 2109 their contents if the gateway no longer has any interest in receiving 2110 the multicast datagrams contained within them. 2112 A gateway MUST ignore a Multicast Data message if it fails to satisfy 2113 any of the following requirements: 2115 o The source IP address and UDP port carried by the Multicast Data 2116 message MUST be equal to the destination IP address and UDP port 2117 carried by the matching Membership Update message (i.e., the 2118 current relay address). 2120 o The destination address carried by the encapsulated IP datagram 2121 MUST fall within the multicast address allocation assigned to the 2122 relavent IP protocol, i.e., 224.0.0.0/4 for IPv4 and FF00::/8 for 2123 IPv6. 2125 The gateway extracts the encapsulated IP datagram and forwards it to 2126 the local IP protocol implementation for checksum verification, 2127 fragmented datagram reassembly, source and group filtering, and 2128 transport-layer protocol processing. 2130 Because AMT uses UDP encapsulation to deliver multicast datagrams to 2131 gateways, it qualifies as a tunneling protocol subject to the 2132 limitations described in [I-D.ietf-6man-udpzero]. If supported, a 2133 gateway SHOULD employ the solution described in 2134 [I-D.ietf-6man-udpchecksums] to ensure that the local IP stack does 2135 not discard IPv6 datagrams with zero checksums. If Multicast Data 2136 message datagrams are processed directly within the gateway (instead 2137 of the host IP stack), the gateway MUST NOT discard any of these 2138 datagrams because they carry a UDP checksum of zero. 2140 5.2.3.4. Relay Discovery Procedure 2142 This section describes gateway requirements related to the relay 2143 discovery message sequence described in Section 4.2.1.1. 2145 5.2.3.4.1. Starting Relay Discovery 2147 A gateway may start or restart the relay discovery procedure in 2148 response to the following events: 2150 o When a gateway pseudo-interface is started (enabled). 2152 o When the gateway wishes to report a group subscription when none 2153 currently exist. 2155 o Before sending the next Request message in a membership update 2156 cycle, i.e. each time the query timer expires (see below). 2158 o After the gateway fails to receive a response to a Request 2159 message. 2161 o After the gateway receives a Membership Query message with the 2162 L-flag set to 1. 2164 5.2.3.4.2. Sending a Relay Discovery Message 2166 A gateway sends a Relay Discovery message to a relay to start the 2167 relay discovery process. 2169 The gateway MUST send the Relay Discovery message using the current 2170 Relay Discovery Address and IANA-assigned UDP port number as the 2171 destination. The Discovery Nonce value in the Relay Discovery 2172 message MUST be computed as described in Section 5.2.3.4.5. 2174 The gateway MUST save a copy of Relay Discovery message or save the 2175 Discovery Nonce value for possible retransmission and verification of 2176 a Relay Advertisement response. 2178 When a gateway sends a Relay Discovery message, it may be notified 2179 that an ICMP Destination Unreachable message was received as a result 2180 of an earlier AMT message transmission. Handling of ICMP Destination 2181 Unreachable messages is described in Section 5.2.3.9. 2183 5.2.3.4.3. Waiting for a Relay Advertisement Message 2185 A gateway MAY retransmit a Relay Discovery message if it does not 2186 receive a matching Relay Advertisement message within some timeout 2187 period. If the gateway retransmits the message multiple times, the 2188 timeout period SHOULD be adjusted to provide an random exponential 2189 back-off. The RECOMMENDED timeout is a random value in the range 2190 [initial_timeout, MIN(initial_timeout * 2^retry_count, 2191 maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and 2192 a RECOMMENDED maximum_timeout of 120 seconds (which is the 2193 recommended minimum NAT mapping timeout described in [RFC4787]). 2195 5.2.3.4.4. Handling a Relay Advertisement Message 2197 When a gateway receives a Relay Advertisement message it must first 2198 determine whether it should accept or ignore the message. A gateway 2199 MUST ignore a Relay Advertisement message if it fails to satisfy any 2200 of the following requirements: 2202 o The gateway MUST be waiting for a Relay Advertisement message. 2204 o The Discovery Nonce value contained in the Relay Advertisement 2205 message MUST equal to the Discovery Nonce value contained in the 2206 Relay Discovery message. 2208 o The source IP address and UDP port of the Relay Advertisement 2209 message MUST equal to the destination IP address and UDP port of 2210 the matching Relay Discovery message. 2212 Once a gateway receives a Relay Advertisement response to a Relay 2213 Discovery message, it SHOULD ignore any other Relay Advertisements 2214 that arrive on the AMT interface until it sends a new Relay Discovery 2215 message. 2217 If a gateway executes the relay discovery procedure at the start of 2218 each membership update cycle and the relay address returned in the 2219 latest Relay Advertisement message differs from the address returned 2220 in a previous Relay Advertisement message, then the gateway SHOULD 2221 send a Teardown message (if supported) to the old relay address, 2222 using information from the last Membership Query message received 2223 from that relay, as described in Section 5.2.3.7. This behavior is 2224 illustrated in the following diagram. 2226 Gateway Relay-1 2227 ------- ------- 2228 : : 2229 Query Expired | | 2230 Timer (QT)-------->| | 2231 | Relay Discovery | 2232 |------------------->| 2233 | | 2234 | Relay Advertisement| 2235 |<-------------------| 2236 | | 2237 | Request | 2238 |------------------->| 2239 | | 2240 | Membership Query | 2241 |<===================| 2242 Start | | 2243 (QT)<--------| Membership Update | 2244 |===================>| 2245 | | 2246 ~ ~ Relay-2 2247 Expired | | ------- 2248 (QT)-------->| | : 2249 | Relay Discovery | | 2250 |------------------------------------>| 2251 | | | 2252 | Relay Advertisement| | 2253 |<------------------------------------| 2254 | | | 2255 | Teardown | | 2256 |------------------->| | 2257 | | | 2258 | Request | | 2259 |------------------------------------>| 2260 | | | 2261 | Membership Query | | 2262 |<====================================| 2263 Start | | | 2264 (QT)<--------| Membership Update | | 2265 |====================================>| 2266 | | | 2267 : : : 2269 Teardown After Relay Address Change 2271 5.2.3.4.5. Discovery Nonce Generation 2273 The discovery nonce MUST be a random, non-zero, 32-bit value, and if 2274 possible, SHOULD be computed using a cryptographically secure pseudo 2275 random number generator. A new nonce SHOULD be generated each time 2276 the gateway restarts the relay discovery process. The same nonce 2277 SHOULD be used when retransmitting a Relay Discovery message. 2279 5.2.3.5. Membership Query Procedure 2281 This section describes gateway requirements related to the membership 2282 update message sequence described in Section 4.2.1.2. 2284 5.2.3.5.1. Starting the Membership Update Cycle 2286 A gateway may send a Request message to start a membership update 2287 cycle (following the optional relay discovery procedure) in response 2288 to the following events: 2290 o When the gateway pseudo-interface is activated. 2292 o When the gateway wishes to report a group subscription when none 2293 currently exist. 2295 Starting the membership update cycle when a gateway pseudo-interface 2296 is started provides several benefits: 2298 o Better performance by allowing state-change reports to be sent as 2299 they are generated, thus minimizing the time to join. 2301 o More robustness by relying on unsolicited state-change reports to 2302 update group membership state rather than the current-state 2303 reports generated by the membership update cycle. Unsolicited 2304 state-change reports are typically retransmitted multiple times 2305 while current-state reports are not. 2307 o Simplified implementation by eliminating any need to queue IGMP/ 2308 MLD messages for delivery after a Membership Query is received, 2309 since the IGMP/MLD state-change messages may be sent as they are 2310 generated. 2312 However, this approach places an additional load on relays as a 2313 gateway will send periodic requests even when it has no multicast 2314 subscriptions. To reduce load on a relay, a gateway SHOULD only send 2315 a Membership Update message while it has active group subscriptions. 2316 A relay will still need to compute a Response MAC for each Request, 2317 but will not be required to recompute it a second time to 2318 authenticate a Membership Update message that contains no 2319 subscriptions. 2321 5.2.3.5.2. Sending a Request Message 2323 A gateway sends a Request message to a relay to solicit a Membership 2324 Query response and start the membership update cycle. 2326 A gateway constructs a Request message containing a Request Nonce 2327 value computed as described in Section 5.2.3.5.6. The gateway MUST 2328 set the "P" flag in the Request message to identify the protocol the 2329 gateway wishes the relay to use for the general query response. 2331 A gateway MUST send a Request message using the current Relay Address 2332 and IANA-assigned AMT port number as the destination. 2334 A gateway MUST save a copy of the Request message or save the Request 2335 Nonce and P-flag values for possible retransmission and verification 2336 of a Membership Query response. 2338 When a gateway sends a Request message, it may be notified that an 2339 ICMP Destination Unreachable message was received as a result of an 2340 earlier AMT message transmission. Handling of ICMP Destination 2341 Unreachable messages is described in Section 5.2.3.9. 2343 5.2.3.5.3. Waiting for a Membership Query Message 2345 A gateway MAY retransmit a Request message if it does not receive a 2346 matching Membership Query message within some timeout period. If the 2347 gateway retransmits the message multiple times, the timeout period 2348 SHOULD be adjusted to provide an random exponential back-off. The 2349 RECOMMENDED timeout is a random value in the range [initial_timeout, 2350 MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a 2351 RECOMMENDED initial_timeout of 1 second and a RECOMMENDED 2352 maximum_timeout of 120 seconds (which is the recommended minimum NAT 2353 mapping timeout described in [RFC4787]). 2355 If a gateway that uses relay discovery does not receive a Membership 2356 Query within a specified time period or after a specified number of 2357 retries, the gateway SHOULD stop waiting for a Membership Query 2358 message and restart relay discovery to locate another relay. 2360 5.2.3.5.4. Handling a Membership Query Message 2362 When a gateway receives a Membership Query message it must first 2363 determine whether it should accept or ignore the message. A gateway 2364 MUST ignore a Membership Query message, or the encapsulated IP 2365 datagram within it, if the message fails to satisfy any of the 2366 following requirements: 2368 o The gateway MUST be waiting for a Membership Query message. 2370 o The Request Nonce value contained in the Membership Query MUST 2371 equal the Request Nonce value contained in the Request message. 2373 o The source IP address and UDP port of the Membership Query MUST 2374 equal the destination IP address and UDP port of the matching 2375 Request message (i.e. the current relay address). 2377 o The encapsulated IP datagram MUST carry an IGMPv3 or MLDv2 2378 message. The protocol MUST match the protocol identified by the 2379 "P" flag in the Request message. 2381 o The IGMPv3 or MLDv2 message MUST be a general query message. 2383 o The total length of the encapsulated IP datagram as computed from 2384 the lengths contained in the datagram header(s) MUST NOT exceed 2385 the available field length within the Membership Query message. 2387 Once a gateway receives a Membership Query response to a Request 2388 message, it SHOULD ignore any other Membership Query messages that 2389 arrive on the AMT interface until it sends a new Request message. 2391 The gateway MUST save the Membership Query message, or the Request 2392 Nonce, Response MAC, Gateway IP Address and Gateway Port Number 2393 fields for use in sending subsequent Membership Update and Teardown 2394 messages. 2396 The gateway extracts the encapsulated IP datagram and forwards it to 2397 the local IP protocol implementation for checksum verification and 2398 dispatching to the IGMP or MLD implementation running on the pseudo- 2399 interface. The gateway MUST NOT forward any octets that might exist 2400 between the encapsulated IP datagram and the end of the message or 2401 Gateway Address fields. 2403 The IGMP and MLD protocol specifications indicate that senders should 2404 use a link-local source IP address in message datagrams. This 2405 requirement must be relaxed for AMT because gateways and relays do 2406 not share a common subnet. For this reason, a gateway implementation 2407 MUST accept IGMP and MLD query message datagrams regardless of the 2408 source IP address they carry. 2410 The gateway MUST start a timer that will trigger the next iteration 2411 of the membership update cycle by executing the membership query 2412 procedure. The gateway SHOULD compute the timer duration from the 2413 Querier's Query Interval Code carried by the general-query. A 2414 gateway MAY use a smaller timer duration if required to refresh a NAT 2415 mapping that would otherwise timeout. A gateway MAY use a larger 2416 timer duration if it has no group subscriptions to report. 2418 If the gateway supports the Teardown message and the G-flag is set in 2419 the Membership Query message, the gateway MUST compare the Gateway IP 2420 Address and Gateway Port Number on the new Membership Query message 2421 with the values carried by the previous Membership Query message. If 2422 either value has changed the gateway MUST send a Teardown message to 2423 the relay as described in Section 5.2.3.7. 2425 If the L-flag is set in the Membership Query message, the relay is 2426 reporting that it is NOT accepting Membership Update messages that 2427 create new tunnel endpoints and will simply ignore any that do. If 2428 the L-flag is set and the gateway is not currently reporting any 2429 group subscriptions to the relay, the gateway SHOULD stop sending 2430 periodic Request messages and restart the relay discovery procedure 2431 (if discovery is enabled) to find a new relay with which to 2432 communicate. The gateway MAY continue to send updates even if the 2433 L-flag is set, if it has previously reported group subscriptions to 2434 the relay, one or more subscriptions still exist and the gateway 2435 endpoint address has not changed since the last Membership Query was 2436 received (see previous paragraph). 2438 5.2.3.5.5. Handling Query Timer Expiration 2440 When the query timer (started in the previous step) expires, the 2441 gateway should execute the membership query procedure again to 2442 continue the membership update cycle. 2444 5.2.3.5.6. Request Nonce Generation 2446 The request nonce MUST be a random value, and if possible, SHOULD be 2447 computed using a cryptographically secure pseudo random number 2448 generator. A new nonce MUST be generated each time the gateway 2449 starts the membership query process. The same nonce SHOULD be used 2450 when retransmitting a Request message. 2452 5.2.3.6. Membership Update Procedure 2454 This section describes gateway requirements related to the membership 2455 update message sequence described in Section 4.2.1.2. 2457 The membership update process is primarily driven by the host-mode 2458 IGMP or MLD protocol implementation running on the gateway pseudo- 2459 interface. The IGMP and MLD protocols produce current-state reports 2460 in response to general queries generated by the pseudo-interface via 2461 AMT and produce state-change reports in response to receiver requests 2462 made using the IGMP or MLD service interface. 2464 5.2.3.6.1. Handling an IGMP/MLD IP Datagram 2466 The gateway pseudo-interface MUST accept the following IP datagrams 2467 from the IPv4/IGMP and IPv6/MLD protocols running on the pseudo- 2468 interface: 2470 o IPv4 datagrams that carry an IGMPv2, or IGMPv3 Membership Report 2471 or an IGMPv2 Leave Group message as described in Section 4 of 2472 [RFC3376]. 2474 o IPv6 datagrams that carry an MLDv1 or MLDv2 Multicast Listener 2475 Report or an MLDv1 Multicast Listener Done message as described in 2476 Section 5 of [RFC3810]. 2478 The gateway must be prepared to receive these messages any time the 2479 pseudo-interface is running. The gateway MUST ignore any datagrams 2480 not listed above. 2482 A gateway that waits to start a membership update cycle until after 2483 it receives an IGMP/MLD state-change message MAY: 2485 o Discard datagrams containing IGMP/MLD messages until it receives a 2486 Membership Query message, at which time it processes the 2487 Membership Query message as normal to eventually produce a 2488 current-state report on the pseudo-interface which describes the 2489 end state (RECOMMENDED). 2491 o Insert IGMP/MLD messages into a queue for transmission after it 2492 receives a Membership Query message. 2494 If the datagram contains a valid IGMP or MLD message, the gateway 2495 sends it to the relay as described in the next section. 2497 5.2.3.6.2. Sending a Membership Update Message 2499 A gateway cannot send a Membership Update message to a relay until it 2500 has received a Membership Query message from a relay. If the gateway 2501 has not yet located a relay with which to communicate, it MUST first 2502 execute the relay discovery procedure described in Section 5.2.3.4 to 2503 obtain a relay address. If the gateway has a relay address, but has 2504 not yet received a Membership Query message, it MUST first execute 2505 the membership query procedure described in Section 5.2.3.5 to obtain 2506 a Request Nonce and Response MAC that can be used to send a 2507 Membership Update message. 2509 Once a gateway possesses a valid Relay Address, Request Nonce and 2510 Response MAC, it may encapsulate the IP datagram containing the IGMP/ 2511 MLD message into a Membership Update message. The gateway MUST copy 2512 the Request Nonce and Response MAC values from the last Membership 2513 Query received from the relay into the corresponding fields in the 2514 Membership Update. The gateway MUST send the Membership Update 2515 message using the Relay Address and IANA-assigned AMT port number as 2516 the destination. 2518 When a gateway sends a Membership Update message, it may be notified 2519 that an ICMP Destination Unreachable message was received as a result 2520 of an earlier AMT message transmission. Handling of ICMP Destination 2521 Unreachable messages is described in Section 5.2.3.9. 2523 5.2.3.7. Teardown Procedure 2525 This section describes gateway requirements related to the teardown 2526 message sequence described in Section 4.2.1.3. 2528 Gateway support for the Teardown message is OPTIONAL but RECOMMENDED. 2530 A gateway that supports Teardown SHOULD make use of Teardown 2531 functionality if it receives a Membership Query message from a relay 2532 that has the "G" flag set to indicate that it contains valid gateway 2533 address fields. 2535 5.2.3.7.1. Handling a Membership Query Message 2537 As described in Section 5.2.3.5.4, if a gateway supports the Teardown 2538 message, has reported active group subscriptions, and receives a 2539 Membership Query message with the "G" flag set, the gateway MUST 2540 compare the Gateway IP Address and Gateway Port Number on the new 2541 Membership Query message with the values carried by the previous 2542 Membership Query message. If either value has changed the gateway 2543 MUST send a Teardown message as described in the next section. 2545 5.2.3.7.2. Sending a Teardown Message 2547 A gateway sends a Teardown message to a relay to request that it stop 2548 delivering Multicast Data messages to the gateway and delete any 2549 group memberships created by the gateway. 2551 When a gateway constructs a Teardown message, it MUST copy the 2552 Request Nonce, Response MAC, Gateway IP Address and Gateway Port 2553 Number fields from the Membership Query message that provided the 2554 Response MAC for the last Membership Update message sent, into the 2555 corresponding fields of the Teardown message. 2557 A gateway MUST send the Teardown message using the Relay Address and 2558 IANA-assigned AMT port number as the destination. A gateway MAY send 2559 the the Teardown message multiple times for robustness. The gateway 2560 SHOULD use the Querier's Robustness Variable (QRV) field contained in 2561 the query encapsulated within the last Membership Query to set the 2562 limit on the number of retransmissions. If the gateway sends the 2563 Teardown message multiple times, it SHOULD insert a delay between 2564 each transmission using the timing algorithm employed in IGMP/MLD for 2565 transmitting unsolicited state-change reports. The RECOMMENDED 2566 default delay value is 1 second. 2568 When a gateway sends a Teardown message, it may be notified that an 2569 ICMP Destination Unreachable message was received as a result of an 2570 earlier AMT message transmission. Handling of ICMP Destination 2571 Unreachable messages is described in Section 5.2.3.9. 2573 5.2.3.8. Shutdown 2575 When a gateway pseudo-interface is stopped and the gateway has 2576 existing group subscriptions, the gateway SHOULD either: 2578 o Send a Teardown message to the relay as described in 2579 Section 5.2.3.7, but only if the gateway supports the Teardown 2580 message, and the current relay is returning gateway address fields 2581 in Membership Query messages, or 2583 o Send a Membership Update message to the relay that will delete 2584 existing group subscriptions. 2586 5.2.3.9. Handling ICMP Destination Unreachable Responses 2588 A gateway may receive an ICMP "Destination Unreachable" message 2589 [RFC0792] after sending an AMT message. Whether the gateway is 2590 notified that an ICMP message was received is highly dependent the 2591 gateway IP stack behavior and gateway implementation. 2593 If the reception of an ICMP Destination Unreachable message is 2594 reported to the gateway while waiting to receive an AMT message, the 2595 gateway may respond as follows, depending on platform capabilities 2596 and which outgoing message triggered the ICMP response: 2598 1. The gateway MAY simply abandon the current relay and restart 2599 relay discovery (if used). This is the least desirable approach 2600 as it does not allow for transient network changes. 2602 2. If the last message sent was a Relay Discovery or Request 2603 message, the gateway MAY simply ignore the ICMP response and 2604 continue waiting for incoming AMT messages. If the gateway is 2605 configured to retransmit Relay Discovery or Request messages, the 2606 normal retransmission behavior for those messages is preserved to 2607 prevent the gateway from prematurely abandoning a relay. 2609 3. If the last message sent was a Membership Update message, the 2610 gateway MAY start a new membership update and associated Request 2611 retransmission cycle. 2613 If the reception of an ICMP Destination Unreachable message is 2614 reported to the gateway when attempting to transmit a new AMT 2615 message, the gateway may respond as follows, depending on platform 2616 capabilities and which outgoing message triggered the ICMP response: 2618 1. The gateway MAY simply abandon the current relay and restart 2619 relay discovery (if used). This is the least desirable approach 2620 as it does not allow for transient network changes. 2622 2. If the last message sent was a Relay Discovery, Request or 2623 Teardown message, the gateway MAY attempt to transmit the new 2624 message. If the gateway is configured to retransmit Relay 2625 Discovery, Request or Teardown messages, the normal 2626 retransmission behavior for those messages is preserved to 2627 prevent the gateway from prematurely abandoning a relay. 2629 3. If the last message sent was a Membership Update message, the 2630 gateway SHOULD start a new membership update and associated 2631 Request retransmission cycle. 2633 5.3. Relay Operation 2635 The following sections describe relay implementation requirements. A 2636 non-normative discussion of relay operation may be found in 2637 Section 4.2. 2639 5.3.1. IP/IGMP/MLD Protocol Requirements 2641 A relay requires a subset of router-mode IGMP and MLD functionality 2642 to provide group membership tracking and report processing. 2644 A relay accessible via IPv4 MUST support IPv4/IGMPv3 and MAY support 2645 IPv6/MLDv2. A relay accessible via IPv6 MUST support IPv6/MLDv2 and 2646 MAY support IPv4/IGMPv3. 2648 A relay MUST apply the forwarding rules described in Section 6.3 of 2649 [RFC3376] and Section 7.3 of [RFC3810]. 2651 A relay MUST handle incoming reports as described ,Section 6.4 of 2652 [RFC3376] and Section 7.4 of [RFC3810] with the exception that 2653 actions that lead to queries MAY be modified to eliminate query 2654 generation. A relay MUST accept IGMP and MLD report datagrams 2655 regardless of the IP source address carried by those datagrams. 2657 All other aspects of IGMP/MLD router behavior, such as the handling 2658 of queries, querier election, etc., are not used or required for 2659 relay operation. 2661 5.3.2. Startup 2663 If a relay is deployed for anycast discovery, the relay MUST 2664 advertise an anycast Relay Discovery Address Prefix into the unicast 2665 routing system of the anycast domain. An address within that prefix, 2666 i.e., a Relay Discovery Address, MUST be assigned to a relay 2667 interface. 2669 A unicast IPv4 and/or IPv6 address MUST be assigned to the relay 2670 interface that will be used to send and receive AMT control and data 2671 messages. This address or addresses are returned in Relay 2672 Advertisement messages. 2674 The remaining details of relay "startup" are highly implementation- 2675 dependent and are not addressed in this document. 2677 5.3.3. Running 2679 When a relay is started, it begins listening for AMT messages on the 2680 interface to which the unicast Relay Address(es) has been assigned, 2681 i.e., the address returned in Relay Advertisement messages. 2683 5.3.3.1. Handling AMT Messages 2685 A relay MUST ignore any message other than a Relay Discovery, 2686 Request, Membership Update or Teardown message. The handling of 2687 Relay Discovery, Request, Membership Update, and Teardown messages is 2688 addressed in the sections that follow. 2690 Support for the Teardown message is OPTIONAL. If a relay does not 2691 support the Teardown message, it MUST also ignore this message. 2693 A relay that conforms to this specification MUST ignore any message 2694 with a Version field value other than zero. 2696 5.3.3.2. Handling a Relay Discovery Message 2698 This section describes relay requirements related to the relay 2699 discovery message sequence described in Section 4.2.1.1. 2701 A relay MUST accept and respond to Relay Discovery messages sent to 2702 an anycast relay discovery address or the unicast relay address. If 2703 a relay receives a Relay Discovery message sent to its unicast 2704 address, it MUST respond just as it would if the message had been 2705 sent to its anycast discovery address. 2707 When a relay receives a Relay Discovery message it responds by 2708 sending a Relay Advertisement message back to the source of the Relay 2709 Discovery message. The relay MUST use the source IP address and UDP 2710 port of the Relay Discovery message as the destination IP address and 2711 UDP port. The relay MUST use the destination IP address and UDP port 2712 of the Relay Discovery as the source IP address and UDP port to 2713 ensure successful NAT traversal. 2715 The relay MUST copy the value contained in the Discovery Nonce field 2716 of the Relay Discovery message into the Discovery Nonce field in the 2717 the Relay Advertisement message. 2719 If the Relay Discovery message was received as an IPv4 datagram, the 2720 relay MUST return an IPv4 address in the Relay Address field of the 2721 Relay Advertisement message. If the Relay Discovery message was 2722 received as an IPv6 datagram, the relay may return an IPv4 or IPv6 2723 address in the Relay Address field. 2725 5.3.3.3. Handling a Request Message 2727 This section describes relay requirements related to the membership 2728 query portion of the message sequence described in Section 4.2.1.2. 2730 When a relay receives a Request message it responds by sending a 2731 Membership Query message back to the source of the Request message. 2733 The relay MUST use the source IP address and UDP port of the Request 2734 message as the destination IP address and UDP port for the Membership 2735 Query message. The source IP address and UDP port carried by the 2736 Membership Query MUST match the destination IP address and UDP port 2737 of the Request to ensure successful NAT traversal. 2739 The relay MUST return the value contained in the Request Nonce field 2740 of the Request message in the Request Nonce field of the Membership 2741 Query message. The relay MUST compute a MAC value, as described in 2742 Section 5.3.5, and return that value in the Response MAC field of the 2743 Membership Query message. 2745 If a relay supports the Teardown message, it MUST set the G-flag in 2746 the Membership Query message and return the source IP address and UDP 2747 port carried by the Request message in the corresponding Gateway IP 2748 Address and Gateway Port Number fields. If the relay does not 2749 support the Teardown message it SHOULD NOT set these fields as this 2750 may cause the gateway to generate unnecessary Teardown messages. 2752 If the P-flag in the Request message is 0, the relay MUST return an 2753 IPv4-encapsulated IGMPv3 general query in the Membership Query 2754 message. If the P-flag is 1, the relay MUST return an IPv6- 2755 encapsulated MLDv2 general query in the Membership Query message. 2757 If the relay is not accepting Membership Update messages that create 2758 new tunnel endpoints due to resource limitations, it SHOULD set the 2759 L-flag in the Membership Query message to notify the gateway of this 2760 state. Support for the L-flag is OPTIONAL. See Section 5.3.3.8. 2762 An IGMPv3 general query datagram that a relay encapsulates within a 2763 Membership Query message MUST conform to the descriptions found in 2764 Section 4.1 of [RFC3376]. These datagrams MUST possess the IP 2765 headers, header options and header values called for in [RFC3376], 2766 with the following exception; the source IP address for an IGMP 2767 general query datagram MAY be set to the "unspecified" address (all 2768 octets are zero) but SHOULD be set to an address in the address range 2769 specifically assigned by IANA for use in the IGMP messages sent from 2770 a relay to a gateway (i.e. 154.7.1.1 as described in Section 7). 2771 This exception is made because any address that a relay might may not 2772 be a valid source address on any gateway interface. The rationale 2773 for using the aforementioned source addresses is primary one of 2774 convenience - a gateway will accept an IGMP query regardless of the 2775 source address it carries. See Section 5.2.1. 2777 An MLDv2 general query datagram that a relay encapsulates within a 2778 Membership Query message MUST conform to the descriptions found in 2779 Section 5.1 of [RFC3810]. These datagrams MUST possess the IP 2780 headers, header options and header values called for in [RFC3810], 2781 with the following exception; the source IP address for an MLD 2782 general query datagram MAY be set to the "unspecified" address (all 2783 octets are zero) but SHOULD be set to an IPv6 link-local address in 2784 the range FE80::/64. A relay may use a dynamically-generated link- 2785 local address or the fixed address FE80::2. As with IGMP, a gateway 2786 will accept an MLD query regardless of the source address it carries. 2787 See Section 5.2.1. 2789 A relay MUST set the Querier's Query Interval Code (QQIC) field in 2790 the general query to supply the gateway with a suggested time 2791 duration to use for the membership query timer. The QQIC field is 2792 defined in Section 4.1.1 in [RFC3376] and Section 5.1.3 in [RFC3810]. 2793 A relay MAY adjust this value to affect the rate at which the Request 2794 messages are sent from a gateway. However, a gateway is allowed to 2795 use a shorter duration than specified in the QQIC field, so a relay 2796 may be limited in its ability to spread out Requests coming from a 2797 gateway. 2799 A relay MUST set the Querier's Robustness Variable (QRV) field in the 2800 general query to a non-zero value. This value SHOULD be greater than 2801 one. If a gateway retransmits a membership state change messages, it 2802 will retransmit them (robustness variable - 1) times. 2804 A relay SHOULD set the Max Resp Code field in the general query to a 2805 value of 1 to trigger an immediate response from the gateway (some 2806 host IGMP/MLD implementations may not accept a value of zero). A 2807 relay SHOULD NOT use the IGMPv2/MLDv2 Query Response Interval 2808 variable, if available, to generate the Max Resp Code field value as 2809 the Query Response Interval variable is used in setting the duration 2810 of group state timers and must not be set to such a small value. See 2811 Section 5.3.3.7. 2813 5.3.3.4. Handling a Membership Update Message 2815 This section describes relay requirements related to the membership 2816 update portion of the message sequence described in Section 4.2.1.2. 2818 When a relay receives a Membership Update message it must first 2819 determine whether it should accept or ignore the message. A relay 2820 MUST NOT make any changes to group membership and forwarding state if 2821 the message fails to satisfy any of the following requirements: 2823 o The IP datagram encapsulated within the message MUST be one of the 2824 following: 2826 * IPv4 datagram carrying an IGMPv2 or IGMPv3 Membership Report 2827 message. 2829 * IPv4 datagram carrying an IGMPv2 Leave Group message. 2831 * IPv6 datagram carrying an MLDv1 or MLDv2 Multicast Listener 2832 Report message. 2834 * IPv6 datagram carrying MLDv1 Multicast Listener Done message. 2836 o The encapsulated IP datagram MUST satisfy the IP header 2837 requirements for the IGMP or MLD message type as described in 2838 Section 4 of [RFC3376], Section 2 of [RFC2236], Section 5 of 2839 [RFC3810], and Section 3 of [RFC2710], with the following 2840 exception - a relay MUST accept an IGMP or MLD message regardless 2841 of the IP source address carried by the datagram. 2843 o The total length of the encapsulated IP datagram as computed from 2844 the lengths contained in the datagram header(s) MUST NOT exceed 2845 the available field length within the Membership Update message. 2847 o The computed checksums for the encapsulated IP datagram and its 2848 payload MUST match the values contained therein. Checksum 2849 computation and verification varies by protocol; See [RFC0791] for 2850 IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6). 2852 o If processing of the encapsulated IGMP or MLD message would result 2853 in an allocation of new state or a modification of existing state, 2854 the relay MUST authenticate the source of the Membership message 2855 by verifying that the value contained in the Response MAC field 2856 equals the MAC value computed from the fields in the Membership 2857 Update message datagram. Because the private secret used to 2858 compute Response MAC values may change over time, the relay MUST 2859 retain the previous version of the private secret to use in 2860 authenticating Membership Updates sent during the subsequent query 2861 interval. If the first attempt at Response MAC authentication 2862 fails, the relay MUST attempt to authenticate the Response MAC 2863 using the previous private secret value unless 2*query_interval 2864 time has elapsed since the private secret change. See 2865 Section 5.3.5. An alternative approach to Response MAC generation 2866 that avoids repeated Response MAC computations may be found in 2867 Appendix A.1. 2869 A relay MAY skip source authentication to reduce the computational 2870 cost of handling Membership Update messages if the relay can make a 2871 trivial determination that the IGMP/MLD message carried by the 2872 Membership Update message will produce no changes in group membership 2873 or forwarding state. The relay does not need to compute and compare 2874 MAC values if it finds there are no group subscriptions for the 2875 source of the Membership Update message and either of the following 2876 is true: 2878 o The encapsulated IP datagram is an IGMPv3 Membership Report or 2879 MLDv2 Multicast Listener Report message that contains no group 2880 records. This may often be the case for gateways that 2881 continuously repeat the membership update cycle even though they 2882 have no group subscriptions to report. 2884 o The encapsulated IP datagram is an IGMPv2 Leave Group or MLDv1 2885 Multicast Listener Done message. 2887 The IGMP and MLD protocol specifications indicate that senders SHOULD 2888 use a link-local source IP address in message datagrams. This 2889 requirement must be relaxed for AMT because gateways and relays do 2890 not share a common subnet. For this reason, a relay implementation 2891 MUST accept IGMP and MLD datagrams regardless of the source IP 2892 address they carry. 2894 Once a relay has determined that the Membership Update message is 2895 valid, it processes the encapsulated IGMP or MLD membership message 2896 to update group membership state and communicates with the multicast 2897 protocol to update forwarding state and possibly send multicast 2898 protocol messages towards upstream routers. The relay MUST ignore 2899 any octets that might exist between the encapsulated IP datagram and 2900 the end of the Membership Update message. 2902 As described in Section 4.2.2, a relay uses the source IP address and 2903 source UDP port carried by a Membership Update messages to identify a 2904 tunnel endpoint. A relay uses the tunnel endpoint as the destination 2905 address for any Multicast Data messages it sends as a result of the 2906 group membership and forwarding state created by processing the IGMP/ 2907 MLD messages contained in Membership Update messages received from 2908 the endpoint. 2910 If a Membership Update message originates from a new endpoint, the 2911 relay MUST determine whether it can accept updates from a new 2912 endpoint. If a relay has been configured with a limit on the total 2913 number of endpoints, or a limit on the total number of endpoints for 2914 a given source address, then the relay MAY ignore the Membership 2915 Update message and possibly withdraw any Relay Discovery Address 2916 Prefix announcement that it might have made. See Section 5.3.3.8. 2918 A relay MUST maintain some form of group membership database for each 2919 endpoint. The per-endpoint databases are used update a forwarding 2920 table containing entries that map an (*,G) or (S,G) subscription to a 2921 list of tunnel endpoints. 2923 A relay MUST maintain some form group membership database 2924 representing a merger of the group membership databases of all 2925 endpoints. The merged group membership database is used to update 2926 upstream multicast forwarding state. 2928 A relay MUST maintain a forwarding table that maps each unique (*,G) 2929 and (S,G) subscription to a list of tunnel endpoints. A relay uses 2930 this forwarding table to provide the destination address when 2931 performing UDP/IP encapsulation of the incoming multicast IP 2932 datagrams to form Multicast Data messages. 2934 If a group filter mode for a group entry on a tunnel endpoint is 2935 EXCLUDE, the relay SHOULD NOT forward datagrams that originate from 2936 sources in the filter source list unless the relay architecture does 2937 not readily support source filtering. A relay MAY ignore the source 2938 list if necessary because gateways are expected to do their own 2939 source filtering. 2941 5.3.3.5. Handling a Teardown Message 2943 This section describes relay requirements related to the teardown 2944 message sequence described in Section 4.2.1.3. 2946 When a relay (that supports the Teardown message) receives a Teardown 2947 message, it MUST first authenticate the source of the Teardown 2948 message by verifying that the Response MAC carried by the Teardown 2949 message is equal to a MAC value computed from the fields carried by 2950 the Teardown message. The method used to compute the MAC differs 2951 from that used to generate and validate the Membership Query and 2952 Membership Update messages in that the source IP address and source 2953 UDP port number used to compute the MAC are taken from the Gateway IP 2954 Address and Gateway Port Number field in the Teardown message rather 2955 than from the IP and UDP headers in the datagram that carries the 2956 Teardown message. The MAC computation is described Section 5.3.5. A 2957 relay MUST ignore a Teardown message If the computed MAC does not 2958 equal the value of the Response MAC field. 2960 If a relay determines that a Teardown message is authentic, it MUST 2961 immediately stop transmitting Multicast Data messages to the endpoint 2962 identified by the Gateway IP Address and Gateway Port Number fields 2963 in the message. The relay MUST eventually delete any group 2964 membership and forwarding state associated with the endpoint, but MAY 2965 delay doing so to allow a gateway to recreate group membership state 2966 on a new endpoint and thereby avoid making unnecessary (temporary) 2967 changes in upstream routing/forwarding state. 2969 The state changes made by a relay when processing a Teardown message 2970 MUST be identical to those that would be made as if the relay had 2971 received an IGMP/MLD report that would cause the IGMP or MLD protocol 2972 to delete all existing group records in the group membership database 2973 associated with the endpoint. The processing of the Teardown message 2974 should trigger or mimic the normal interaction between IGMP or MLD 2975 and a multicast protocol to produce required changes in forwarding 2976 state and possibly send prune/leave messages towards upstream 2977 routers. 2979 5.3.3.6. Handling Multicast IP Datagrams 2981 When a multicast IP datagram is forwarded to the relay pseudo- 2982 interface, the relay MUST, for each gateway that has expressed an 2983 interest in receiving the datagram, encapsulate the IP datagram into 2984 a Multicast Data message and send that message to the gateway. This 2985 process is highly implementation dependent, but conceptually requires 2986 the follow steps: 2988 o Use the IP datagram source and destination address to look up the 2989 appropriate (*,G) or (S,G) entry in the endpoint forwarding table 2990 created for the pseudo-interface as a result of IGMP/MLD 2991 processing. 2993 o Possibly replicate the datagram for each gateway endpoint listed 2994 for that (*,G) or (S,G) entry. 2996 o Encapsulate the IP datagram in a UDP/IP Membership Data message, 2997 using the endpoint UDP/IP address as the destination address and 2998 the unicast relay address and IANA-assigned port as the source 2999 UDP/IP address. To ensure successful NAT traversal, the source 3000 address and port MUST match the destination address and port 3001 carried by the Membership Update message sent by the gateway to 3002 create the forwarding table entry. 3004 o If possible, the relay SHOULD compute a valid, non-zero checksum 3005 for the UDP datagram carrying the Membership Data message. See 3006 Section 4.2.2.3. 3008 o Send the message to the gateway. 3010 The relay pseudo-interface MUST ignore any other IP datagrams 3011 forwarded to the pseudo-interface. 3013 5.3.3.7. State Timers 3015 A relay MUST maintain a timer or timers whose expiration will trigger 3016 the removal of any group subscriptions and forwarding state 3017 previously created for a gateway endpoint should the gateway fail to 3018 refresh the group membership state within a specified time interval. 3020 A relay MAY use a variant of the IGMPv3/MLDv2 state management 3021 protocol described in Section 6 of [RFC3376] or Section 7 of 3022 [RFC3810], or may maintain a per-endpoint timer to trigger the 3023 deletion of group membership state. 3025 If a per-endpoint timer is used, the relay MUST restart this timer 3026 each time it receives a new Membership Update message from the 3027 gateway endpoint. 3029 The endpoint timer duration MAY be computed from tunable IGMP/MLD 3030 variables as follows: 3032 ((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval 3034 If IGMP/MLD default values are used for these variables, the gateway 3035 will timeout after 125s * 2 + 10s = 260s. The timer duration MUST be 3036 greater than the query interval suggested in the last Membership 3037 Query message sent to the gateway endpoint. 3039 Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the 3040 Query_Response_Interval value SHOULD be greater than or equal to 10s 3041 to allow for packet loss and round-trip time in the Request/ 3042 Membership Query message exchange. 3044 5.3.3.8. Relay Resource Management 3046 A relay may be configured with various service limits to ensure a 3047 minimum level of performance for gateways that connect to it. 3049 If a relay has determined that it has reached or exceeded maximum 3050 allowable capacity or has otherwise exhausted resources required to 3051 support additional gateways, it SHOULD withdraw any Relay Discovery 3052 Address Prefix it has advertised into the unicast internetwork and 3053 SHOULD set the L-flag in any Membership Query messages it returns to 3054 gateways while in this state. 3056 If the relay receives an update from a gateway that adds group 3057 membership or forwarding state for an endpoint that has already 3058 reached maximum allowable state entries, the relay SHOULD continue to 3059 accept updates from the gateway but ignore any group membership/ 3060 forwarding state additions requested by that gateway. 3062 If the relay receives an update from a gateway that would create a 3063 new tunnel endpoint for a source IP address that has already reach 3064 maximum allowable number of endpoints (maximum UDP ports), it should 3065 simply ignore the Membership Update. 3067 5.3.4. Shutdown 3069 The following steps should be treated as an abstract description of 3070 the shutdown procedure for a relay: 3072 o Withdraw the Relay Discovery Address Prefix advertisement (if 3073 used). 3075 o Stop listening for Relay Discovery messages. 3077 o Stop listening for control messages from gateways. 3079 o Stop sending data messages to gateways. 3081 o Delete all AMT group membership and forwarding state created on 3082 the relay, coordinating with the multicast routing protocol to 3083 update the group membership state on upstream interfaces as 3084 required. 3086 5.3.5. Response MAC Generation 3088 A Response MAC is produced by a hash digest computation. A Response 3089 MAC value is computed from a Request message for inclusion in a 3090 Membership Query message, is computed from a Membership Update 3091 message to authenticate the Response MAC carried within that message, 3092 and is computed from fields in a Teardown message to authenticate the 3093 Response MAC carried within that message. 3095 Gateways treat the Response MAC field as an opaque value, so a relay 3096 implementation may generate the MAC using any method available to it. 3097 The hash function RECOMMENDED for use in computing the Response MAC 3098 is the MD5 hash digest [RFC1321], though hash functions or keyed-hash 3099 functions of greater cryptographic strength may be used. 3101 The digest MUST be computed over the following values: 3103 o The Source IP address of the message (or Teardown Gateway IP 3104 Address field) 3106 o The Source UDP port of the message (or Teardown Gateway Port 3107 Number field) 3109 o The Request Nonce contained in the message. 3111 o A private secret known only to the relay 3113 An Response MAC generation solution that satisfies these requirements 3114 is described in Appendix A.1. 3116 5.3.6. Private Secret Generation 3118 The private secret, or hash-key, is a random value that the relay 3119 includes in the Response MAC hash digest computation. A relay SHOULD 3120 periodically compute a new private secret. The RECOMMENDED maximum 3121 interval is 2 hours. A relay MUST retain the prior secret for use in 3122 verifying MAC values that were sent to gateways just prior to the use 3123 of the new secret. 3125 The private secret SHOULD be computed using a cryptographically- 3126 secure pseudo-random number generator. The private secret width 3127 SHOULD equal that of the hash function used to compute the Response 3128 MAC, e.g., 128-bits for an MD5 hash. 3130 6. Security Considerations 3132 AMT is not intended to be a strongly secured protocol. In general, 3133 the protocol provides the same level of security and robustness as is 3134 provided by the UDP, IGMP and MLD protocols on which it relies. The 3135 lack of strong security features can largely be attributed to the 3136 desire to make the protocol light-weight by minimizing the state and 3137 computation required to service a single gateway, thereby allowing a 3138 relay to service a larger number of gateways. 3140 Many of the threats and vectors described in [RFC3552] may be 3141 employed against the protocol to launch various types of denial-of- 3142 service attacks that can affect the functioning of gateways or their 3143 ability to locate and communicate with a relay. These scenarios are 3144 described below. 3146 As is the case for UDP, IGMP and MLD, the AMT protocol provides no 3147 mechanisms for ensuring message delivery or integrity. The protocol 3148 does not provide confidentiality - multicast groups, sources and 3149 streams requested by a gateway are sent in the clear. 3151 The protocol does use a three-way handshake to provide trivial source 3152 authentication for state allocation and updates (see below). The 3153 protocol also requires gateways and relays to ignore malformed 3154 messages and those messages that do not carry expected address values 3155 or protocol payload types or content. 3157 6.1. Relays 3159 The three-way handshake provided by the membership update message 3160 sequence (See (Section 4.2.1.2)) provides a defense against source- 3161 spoofing-based resource-exhaustion attacks on a relay by requiring 3162 source authentication before state allocation. However, attackers 3163 may still attempt to flood a relay with Request and Membership Update 3164 messages to force the relay to make the hash computations in an 3165 effort to consume computational resources. Implementations may 3166 choose to limit the frequency with which a relay responds to Request 3167 messages sent from a single IP address or IP address and UDP port 3168 pair, but support for this functionality is not required. The three- 3169 way handshake provides no defense against an eavesdropping or man-in- 3170 the-middle attacker. 3172 Attackers that execute the gateway protocol may consume relay 3173 resources by instantiating a large number of tunnels or joining a 3174 large number of multicast streams. A relay implementation should 3175 provide a mechanism for limiting the number of tunnels (Multicast 3176 Data message destinations) that can be created for a single gateway 3177 source address. Relays should also provide a means for limiting the 3178 number of joins per tunnel instance as a defense against these 3179 attacks. 3181 Relays may withdraw their AMT anycast prefix advertisement when they 3182 reach configured maximum capacity or exhaust required resources. 3183 This behavior allows gateways to use the relay discovery process to 3184 find the next topologically-nearest relay that has advertised the 3185 prefix. This behavior also allows a successful resource exhaustion 3186 attack to propagate from one relay to the next until all relays 3187 reachable using the anycast address have effectively been taken 3188 offline. This behavior may also be used to acquire the unicast 3189 addresses for individual relays which can then be used to launch a 3190 DDoS attack on all of the relays without using the relay discovery 3191 process. To prevent wider disruption of AMT-based distribution 3192 network, relay anycast address advertisements can be limited to 3193 specific administrative routing domains. This will isolate such 3194 attacks to a single domain. 3196 6.2. Gateways 3198 A passive eavesdropper may launch a denial-of-service attack on a 3199 gateway by capturing a Membership Query or Membership Update message 3200 and using the request nonce and message authentication code carried 3201 by the captured message to send a spoofed a Membership Update or 3202 Teardown message to the relay. The spoofed messages may be used to 3203 modify or destroy group membership state associated with the gateway, 3204 thereby changing or interrupting the multicast traffic flows. 3206 A passive eavesdropper may also spoof Multicast Data messages in an 3207 attempt to overload the gateway or disrupt or supplant existing 3208 traffic flows. A properly implemented gateway will filter Multicast 3209 Data messages that do not originate from the expected relay address 3210 and should filter non-multicast packets and multicast IP packets 3211 whose group or source addresses are not included in the current 3212 reception state for the gateway pseudo-interface. 3214 The anycast discovery technique for finding relays (see 3215 Section 4.1.4) introduces a risk that a rogue router or a rogue AS 3216 could introduce a bogus route to a specific Relay Discovery Address 3217 prefix, and thus divert or absorb Relay Discovery messages sent by 3218 gateways. Network managers must guarantee the integrity of their 3219 routing to a particular Relay Discovery Address prefix in much the 3220 same way that they guarantee the integrity of all other routes. 3222 6.3. Encapsulated IP Packets 3224 An attacker forging or modifying a Membership Query or Membership 3225 Update message may attempt to embed something other than an IGMP or 3226 MLD message within the encapsulated IP packet carried by these 3227 messages in an effort to introduce these into the recipient's IP 3228 stack. A properly implemented gateway or relay will ignore any such 3229 messages - and may further choose ignore Membership Query messages 3230 that do not contain a IGMP/MLD general queries or Membership Update 3231 messages that do not contain IGMP/MLD membership reports. 3233 Properly implemented gateways and relays will also filter 3234 encapsulated IP packets that appear corrupted or truncated by 3235 verifying packet length and checksums. 3237 7. IANA Considerations 3239 7.1. IPv4 and IPv6 Anycast Prefix Allocation 3241 IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated to 3242 the public AMT Relays to advertise to the native multicast backbone 3243 (as described in Section 4.1.4). The prefix length should be 3244 determined by the IANA; the prefix should be large enough to 3245 guarantee advertisement in the default-free BGP networks. 3247 7.1.1. IPv4 3249 A prefix length of 24 will meet this requirement. 3251 Internet Systems Consortium (ISC) has offered154.7.0/24 for this 3252 purpose. 3254 7.1.2. IPv6 3256 A prefix length of 32 will meet this requirement. IANA has 3257 previously set aside the range 2001::/16 for allocating prefixes for 3258 this purpose. 3260 7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses 3262 IANA should allocate an IPv4 prefix dedicated for use in IGMP 3263 messages exchanged between gateways and relays. This address range 3264 is intended for use within tunnels constructed between a gateway and 3265 relay, and as such, is not intended to be globally routable. 3267 A prefix length of 24 will meet this requirement. 3269 Internet Systems Consortium (ISC) has offered 154.7.1/24 for this 3270 purpose. 3272 7.3. UDP Port number 3274 IANA has reserved UDP port number 2268 for AMT. 3276 8. Contributors 3278 The following people provided significant contributions to the design 3279 of the protocol and earlier versions of this specification: 3281 Thomas Morin 3282 France Telecom - Orange 3283 2, avenue Pierre Marzin 3284 Lannion 22300 3285 France 3286 Email: thomas.morin@orange.com 3288 Dirk Ooms 3289 OneSparrow 3290 Belegstraat 13; 2018 Antwerp; 3291 Belgium 3292 EMail: dirk@onesparrow.com 3294 Tom Pusateri 3295 !j 3296 2109 Mountain High Rd. 3297 Wake Forest, NC 27587 3298 USA 3299 Email: pusateri@bangj.com 3301 Dave Thaler 3302 Microsoft Corporation 3303 One Microsoft Way 3304 Redmond, WA 98052-6399 3305 USA 3306 Email: dthaler@microsoft.com 3308 9. Acknowledgments 3310 The authors would like to thank the following individuals for their 3311 suggestions, comments, and corrections: 3313 Amit Aggarwal 3314 Mark Altom 3315 Toerless Eckert 3316 Marshall Eubanks 3317 Gorry Fairhurst 3318 Dino Farinacci 3319 Lenny Giuliano 3320 Andy Huang 3321 Tom Imburgia 3322 Patricia McCrink 3323 Han Nguyen 3324 Doug Nortz 3325 Pekka Savola 3326 Robert Sayko 3327 Greg Shepherd 3328 Steve Simlo 3329 Mohit Talwar 3330 Lorenzo Vicisano 3331 Kurt Windisch 3332 John Zwiebel 3334 The anycast discovery mechanism described in this document is based 3335 on similar work done by the NGTrans WG for obtaining automatic IPv6 3336 connectivity without explicit tunnels ("6to4"). Tony Ballardie 3337 provided helpful discussion that inspired this document. 3339 Juniper Networks was instrumental in funding several versions of this 3340 draft as well as an open source implementation. 3342 10. References 3344 10.1. Normative References 3346 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3347 August 1980. 3349 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3350 RFC 792, September 1981. 3352 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 3353 April 1992. 3355 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 3356 Thyagarajan, "Internet Group Management Protocol, Version 3357 3", RFC 3376, October 2002. 3359 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 3360 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 3362 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3363 Architecture", RFC 4291, February 2006. 3365 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 3366 "Internet Group Management Protocol (IGMP) / Multicast 3367 Listener Discovery (MLD)-Based Multicast Forwarding 3368 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 3370 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 3371 IP", RFC 4607, August 2006. 3373 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 3374 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 3375 RFC 4787, January 2007. 3377 10.2. Informative References 3379 [I-D.ietf-6man-udpchecksums] 3380 Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled 3381 Packets", draft-ietf-6man-udpchecksums-02 (work in 3382 progress), March 2012. 3384 [I-D.ietf-6man-udpzero] 3385 Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum 3386 Considerations", draft-ietf-6man-udpzero-05 (work in 3387 progress), December 2011. 3389 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3390 September 1981. 3392 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 3393 RFC 1112, August 1989. 3395 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 3396 Anycasting Service", RFC 1546, November 1993. 3398 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 3399 Hashing for Message Authentication", RFC 2104, 3400 February 1997. 3402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3403 Requirement Levels", BCP 14, RFC 2119, March 1997. 3405 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 3406 2", RFC 2236, November 1997. 3408 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3409 (IPv6) Specification", RFC 2460, December 1998. 3411 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 3412 Translator (NAT) Terminology and Considerations", 3413 RFC 2663, August 1999. 3415 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 3416 Listener Discovery (MLD) for IPv6", RFC 2710, 3417 October 1999. 3419 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 3420 Tunnel Broker", RFC 3053, January 2001. 3422 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 3423 via IPv4 Clouds", RFC 3056, February 2001. 3425 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 3426 RFC 3068, June 2001. 3428 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 3429 Text on Security Considerations", BCP 72, RFC 3552, 3430 July 2003. 3432 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 3433 Independent Multicast - Dense Mode (PIM-DM): Protocol 3434 Specification (Revised)", RFC 3973, January 2005. 3436 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 3437 Message Protocol (ICMPv6) for the Internet Protocol 3438 Version 6 (IPv6) Specification", RFC 4443, March 2006. 3440 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 3441 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 3442 Protocol Specification (Revised)", RFC 4601, August 2006. 3444 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 3445 "Multiprotocol Extensions for BGP-4", RFC 4760, 3446 January 2007. 3448 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 3449 Services", BCP 126, RFC 4786, December 2006. 3451 Appendix A. Implementation Notes 3453 A.1. Response MAC Generation and Keying 3455 This specification does not require relays to use any particular 3456 method to compute the Response MAC field value - only that it contain 3457 a hash of the source IP address, source UDP port, request nonce, and 3458 a private secret known only to the relay. This allows the relay 3459 implementor a significant amount of leeway in the computation and 3460 structure of the value stored in the Response MAC field. 3462 Section Section 5.3.6 states that a relay should periodically compute 3463 a new private secret (or hash-key) for MAC generation. To prevent 3464 the relay from rejecting Membership Update messages that contain 3465 Response MAC values computed from an old secret, the relay is 3466 required to retain the previous secret so that it can re-attempt 3467 authentication using the old secret, should authentication fail after 3468 recomputing the MAC using the new secret. However, this approach 3469 requires a relay to do at least two hash computations for every 3470 Membership Update message that carries an old or a invalid MAC. A 3471 better approach would be to include information within the message 3472 that the relay could use to choose a single secret for authentication 3473 rather relying on sequential authentication failures to test all 3474 possible secrets. 3476 The solution proposed here is to compute and exchange an 3477 "authentication cookie" rather than a simple hash value in the 3478 Response MAC field. The authentication cookie would combine a 3479 timestamp with a hash value. The timestamp is used to calculate the 3480 age of the cookie, allowing the relay to reject a message if the 3481 cookie's age is greater than some maximum allowable value. If the 3482 cookie has not expired, the relay uses the timestamp to lookup the 3483 secret that was in use at that time and then compute and compare the 3484 hash portion of the cookie to authenticate the message source. 3486 A second purpose served by including the timestamp in the MAC field 3487 is that it allows the relay to contribute an unpredictable value to 3488 the authentication hash. This contribution provides a defense 3489 against attempts to use a hash reversal algorithm to determine the 3490 relay's private secret as the hash result will change over time even 3491 if the nonce carried by the Request message does not. 3493 0 1 2 3 3494 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 3495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3496 | V=0 |4 or 5| Reserved | | Response MAC | 3497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 3498 | | 3499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3500 | Request Nonce | 3501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3502 : : 3504 The Opaque Response MAC Field 3506 A relay may use the opaque Response MAC field to store a cookie as 3507 follows: 3509 0 1 2 3 3510 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 3511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3512 | V=0 |4 or 5| Reserved | | Timestamp | 3513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3514 | MD5(Secret,Timestamp,IP_ADDR,IP_PORT,Request-Nonce) | 3515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3516 | Request Nonce | 3517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3518 : : 3520 Using The Response MAC Field To Carry An Authentication Cookie 3522 The timestamp is an unsigned integer measured relative to the start 3523 time of relay. The age of the MAC is computed by subtracting the MAC 3524 timestamp from the current system timestamp. The operands must be 3525 unsigned 16-bit integers and the subtraction must use unsigned 3526 arithmetic to allow for timestamp wrap-around. The timestamp 3527 resolution must provide range sufficient to handle the maximum 3528 allowable age for a MAC, e.g., a resolution of 1 second allows a 3529 maximum age of 18 hours. The timestamp should start at a random 3530 value by adding a random offset, computed at startup, to the current 3531 system time. 3533 +-------------------------+----------------/ /-----------------+ 3534 -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] | 3535 | +-------------------------+----------------/ /-----------------+ 3536 |_____________________________________________________________________ 3537 | 3538 +-------------------------+----------------/ /-----------------+ | 3539 -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |-- 3540 | +-------------------------+----------------/ /-----------------+ 3541 |_____________________________________________________________________ 3542 | 3543 +-------------------------+----------------/ /-----------------+ | 3544 -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |-- 3545 | +-------------------------+----------------/ /-----------------+ 3546 | 3547 |__ Current 3548 Secret 3550 Private Secret Queue 3552 The timestamp is not only used to compute the age of the MAC, but is 3553 also used to lookup the private secret used to generate the MAC. 3554 Each time a new private secret is computed, the value and the time at 3555 which the value was computed is pushed into a fixed-length queue of 3556 recent values (typically only 2-deep). The relay uses the timestamp 3557 contained in the MAC field to lookup the appropriate secret. The 3558 relay iterates over the list of secrets, starting with the newest 3559 entry, until it finds the first secret with a timestamp that is older 3560 than that contained in the MAC field. The relay then uses that 3561 secret to compute the MAC that will be compared with that carried by 3562 the message. 3564 Author's Address 3566 Gregory Bumgardner 3567 Cisco 3568 3700 Cisco Way 3569 San Jose, CA 95134 3570 USA 3572 Phone: +1 408 853 4993 3573 Email: gbumgard@cisco.com