idnits 2.17.1 draft-ietf-mboned-auto-multicast-14.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 (June 12, 2012) is 4334 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 3564, but not defined == Missing Reference: '128-bits' is mentioned on line 3564, but not defined == Unused Reference: 'RFC0768' is defined on line 3366, but no explicit reference was found in the text == Unused Reference: 'RFC4605' is defined on line 3385, but no explicit reference was found in the text == Unused Reference: 'RFC2104' is defined on line 3418, but no explicit reference was found in the text == Unused Reference: 'RFC3053' is defined on line 3439, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 3442, but no explicit reference was found in the text == Unused Reference: 'RFC3068' is defined on line 3445, but no explicit reference was found in the text == Unused Reference: 'RFC3973' is defined on line 3452, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 3464, 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 June 12, 2012 5 Expires: December 14, 2012 7 Automatic Multicast Tunneling 8 draft-ietf-mboned-auto-multicast-14 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 December 14, 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 . . . . . . . . . . . . . . . . . . . . 47 79 5.3. Relay Operation . . . . . . . . . . . . . . . . . . . . . 62 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 73 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 82 7.2. IPv4 Address Prefix Allocation for IGMP Source 83 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 76 84 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 77 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 78 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 79 87 10.1. Normative References . . . . . . . . . . . . . . . . . . . 79 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 79 89 Appendix A. Implementation Notes . . . . . . . . . . . . . . . . 82 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 85 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 or 662 datagram fragment to 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 changes 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 or datagram fragment that arrives at the 1229 relay is encapsulated in an AMT message and transmitted to one or 1230 more 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). The relay returns an IP address for the protocol used to 1408 send the Relay Discovery message, i.e., an IPv4 relay address for an 1409 IPv4 discovery address or an IPv6 relay address for an IPv6 discovery 1410 address. 1412 5.1.3. Request 1414 A gateway sends a Request message to a relay to solicit a Membership 1415 Query response. 1417 The successful delivery of this message marks the start of the first 1418 stage in the three-way handshake used to create or update state 1419 within a relay. 1421 The UDP/IP datagram containing this message MUST carry a valid, non- 1422 zero UDP checksum and carry the following IP address and UDP port 1423 values: 1425 Source IP Address - The IP address of the gateway interface on which 1426 the gateway will listen for a response from the relay. Note: The 1427 value of this field may be changed as a result of network address 1428 translation before arriving at the relay. 1430 Source UDP Port - The UDP port number on which the gateway will 1431 listen for a response from the relay. Note: The value of this 1432 field may be changed as a result of network address translation 1433 before arriving at the relay. 1435 Destination IP Address - The unicast IP address of the relay. 1437 Destination UDP Port - The IANA-assigned AMT port number. 1439 0 1 2 3 1440 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 1441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1442 | V=0 |Type=3 | Reserved |P| Reserved | 1443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1444 | Request Nonce | 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1447 Request Message Format 1449 5.1.3.1. Version (V) 1451 The protocol version number for this message is 0. 1453 5.1.3.2. Type 1455 The type number for this message is 3. 1457 5.1.3.3. Reserved 1459 Reserved bits that MUST be set to zero by the gateway and ignored by 1460 the relay. 1462 5.1.3.4. P Flag 1464 The "P" flag is set to indicate which group membership protocol the 1465 gateway wishes the relay to use in the Membership Query response: 1467 Value Meaning 1469 0 The relay MUST respond with a Membership Query message that 1470 contains an IPv4 packet carrying an IGMPv3 general query 1471 message. 1473 1 The relay MUST respond with a Membership Query message that 1474 contains an IPv6 packet carrying an MLDv2 general query 1475 message. 1477 5.1.3.5. Request Nonce 1479 A 32-bit random value generated by the gateway and echoed by the 1480 relay in a Membership Query message. This value is used by the relay 1481 to compute the Response MAC value and is used by the gateway to 1482 correlate Membership Query messages with Request messages. Request 1483 nonce generation is described in Section 5.2.3.5.6. 1485 5.1.4. Membership Query 1487 A relay sends a Membership Query message to a gateway to solicit a 1488 Membership Update response, but only after receiving a Request 1489 message from the gateway. 1491 The successful delivery of this message to a gateway marks the start 1492 of the second-stage in the three-way handshake used to create or 1493 update tunnel state within a relay. 1495 The UDP/IP datagram containing this message MUST carry a valid, non- 1496 zero UDP checksum and carry the following IP address and UDP port 1497 values: 1499 Source IP Address - The destination IP address carried by the 1500 Request message (i.e., the unicast IP address of the relay). 1502 Source UDP Port - The destination UDP port carried by the Request 1503 message (i.e., the IANA-assigned AMT port number). 1505 Destination IP Address - The source IP address carried by the 1506 Request message. Note: The value of this field may be changed as 1507 a result of network address translation before arriving at the 1508 gateway. 1510 Destination UDP Port - The source UDP port carried by the Request 1511 message. Note: The value of this field may be changed as a result 1512 of network address translation before arriving at the gateway. 1514 0 1 2 3 1515 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 1516 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 | V=0 |Type=4 | Reserved |L|G| Response MAC | 1518 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1519 | | 1520 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1521 | Request Nonce | 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | | 1524 | Encapsulated General Query Message | 1525 ~ IPv4:IGMPv3(Membership Query) ~ 1526 | IPv6:MLDv2(Listener Query) | 1527 | | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | Gateway Port Number | | 1530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1531 | | 1532 + + 1533 | Gateway IP Address (IPv4 or IPv6) | 1534 + + 1535 | | 1536 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | | 1538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1540 Membership Query Message Format 1542 5.1.4.1. Version (V) 1544 The protocol version number for this message is 0. 1546 5.1.4.2. Type 1548 The type number for this message is 4. 1550 5.1.4.3. Reserved 1552 Reserved bits that MUST be set to zero by the relay and ignored by 1553 the gateway. 1555 5.1.4.4. Limit (L) Flag 1557 A 1-bit flag set to 1 to indicate that the relay is NOT accepting 1558 Membership Update messages from new gateway tunnel endpoints and that 1559 it will ignore any that are. A value of 0 has no special 1560 significance - the relay may or may not be accepting Membership 1561 Update messages from new gateway tunnel endpoints. A gateway checks 1562 this flag before attempting to create new group subscription state on 1563 the relay to determine whether it should restart relay discovery. A 1564 gateway that has already created group subscriptions on the relay may 1565 ignore this flag. Support for this flag is RECOMMENDED. 1567 5.1.4.5. Gateway Address (G) Flag 1569 A 1-bit flag set to 0 to indicate that the message does NOT carry the 1570 Gateway Port and Gateway IP Address fields, and 1 to indicate that it 1571 does. A relay implementation that supports the optional teardown 1572 procedure (See Section 5.3.3.5) SHOULD set this flag and the Gateway 1573 Address field values. If a relay sets this flag, it MUST also 1574 include the Gateway Address fields in the message. A gateway 1575 implementation that does not support the optional teardown procedure 1576 (See Section 5.2.3.7) MAY ignore this flag and the Gateway Address 1577 fields if they are present. 1579 5.1.4.6. Response MAC 1581 A 48-bit source authentication hash generated by the relay as 1582 described in Section 5.3.5. The gateway echoes this value in 1583 subsequent Membership Update messages to allow the relay to verify 1584 that the sender of a Membership Update message was the intended 1585 receiver of a Membership Query sent by the relay. 1587 5.1.4.7. Request Nonce 1589 A 32-bit value copied from the Request Nonce field (Section 5.1.3.5) 1590 carried by a Request message. The relay will have included this 1591 value in the Response MAC hash computation. The gateway echoes this 1592 value in subsequent Membership Update messages. The gateway also 1593 uses this value to match a Membership Query to a Request message. 1595 5.1.4.8. Encapsulated General Query Message 1597 An IP-encapsulated IGMP or MLD message generated by the relay. This 1598 field will contain one of the following IP datagrams: 1600 IPv4:IGMPv3 Membership Query 1602 IPv6:MLDv2 Listener Query 1604 The source address carried by the query message should be set as 1605 described in Section 5.3.3.3. 1607 The Querier's Query Interval Code (QQIC) field in the general query 1608 is used by a relay to specify the time offset a gateway should use to 1609 schedule a new three-way handshake to refresh the group membership 1610 state within the relay (current time + Query Interval). 1612 The Querier's Robustness Variable (QRV) field in the general query is 1613 used by a relay to specify the number of times a gateway should 1614 retransmit unsolicited membership reports, encapsulated within 1615 Membership Update messages, and optionally, the number of times to 1616 send a Teardown message. 1618 5.1.4.9. Gateway Address Fields 1620 The Gateway Port Number and Gateway Address fields are present in the 1621 Membership Query message if, and only if, the "G" flag is set. 1623 A gateway need not parse the encapsulated IP datagram to determine 1624 the position of these fields within the UDP datagram containing the 1625 Membership Query message - if the G-flag is set, the gateway may 1626 simply subtract the total length of the fields (18 bytes) from the 1627 total length of the UDP datagram to obtain the offset. 1629 5.1.4.9.1. Gateway Port Number 1631 A 16-bit UDP port containing a UDP port value. 1633 The Relay sets this field to the value of the UDP source port of the 1634 Request message that triggered the Query message. 1636 5.1.4.9.2. Gateway IP Address 1638 A 16-byte IP address that, when combined with the value contained in 1639 the Gateway Port Number field, forms the gateway endpoint address 1640 that the relay will use to identify the tunnel instance, if any, 1641 created by a subsequent Membership Update message. This field may 1642 contain an IPv6 address or an IPv4 address stored as an IPv4- 1643 compatible IPv6 address, where the IPv4 address is prefixed with 96 1644 bits set to zero (See [RFC4291]). This address must match that used 1645 by the relay to compute the value stored in the Response MAC field. 1647 5.1.5. Membership Update 1649 A gateway sends a Membership Update message to a relay to report a 1650 change in group membership state, or to report the current group 1651 membership state in response to receiving a Membership Query message. 1652 The gateway encapsulates the IGMP or MLD message as an IP datagram 1653 within a Membership Update message and sends it to the relay, where 1654 it may (see below) be decapsulated and processed by the relay to 1655 update group membership and forwarding state. 1657 A gateway cannot send a Membership Update message until a receives a 1658 Membership Query from a relay because the gateway must copy the 1659 Request Nonce and Response MAC values carried by a Membership Query 1660 into any subsequent Membership Update messages it sends back to that 1661 relay. These values are used by the relay to verify that the sender 1662 of the Membership Update message was the recipient of the Membership 1663 Query message from which these values were copied. 1665 The successful delivery of this message to the relay marks the start 1666 of the final stage in the three-way handshake. This stage concludes 1667 when the relay successfully verifies that sender of the Membership 1668 Update message was the recipient of a Membership Query message sent 1669 earlier. At this point, the relay may proceed to process the 1670 encapsulated IGMP or MLD message to create or update group membership 1671 and forwarding state on behalf of the gateway. 1673 The UDP/IP datagram containing this message MUST carry a valid, non- 1674 zero UDP checksum and carry the following IP address and UDP port 1675 values: 1677 Source IP Address - The IP address of the gateway interface on which 1678 the gateway will listen for Multicast Data messages from the 1679 relay. The address must be the same address used to send the 1680 initial Request message or the message will be ignored. Note: The 1681 value of this field may be changed as a result of network address 1682 translation before arriving at the relay. 1684 Source UDP Port - The UDP port number on which the gateway will 1685 listen for Multicast Data messages from the relay. This port must 1686 be the same port used to send the initial Request message or the 1687 message will be ignored. Note: The value of this field may be 1688 changed as a result of network address translation before arriving 1689 at the relay. 1691 Destination IP Address - The unicast IP address of the relay. 1693 Destination UDP Port - The IANA-assigned AMT UDP port number. 1695 0 1 2 3 1696 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 1697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1698 | V=0 |Type=5 | Reserved | Response MAC | 1699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1700 | | 1701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1702 | Request Nonce | 1703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1704 | | 1705 | Encapsulated Group Membership Update Message | 1706 ~ IPv4:IGMP(Membership Report|Leave Group) ~ 1707 | IPv6:MLD(Listener Report|Listener Done) | 1708 | | 1709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1711 Membership Update Message Format 1713 5.1.5.1. Version (V) 1715 The protocol version number for this message is 0. 1717 5.1.5.2. Type 1719 The type number for this message is 5. 1721 5.1.5.3. Reserved 1723 Reserved bits that MUST be set to zero by the gateway and ignored by 1724 the relay. 1726 5.1.5.4. Response MAC 1728 A 48-bit value copied from the Response MAC field (Section 5.1.4.6) 1729 in a Membership Query message. Used by the relay to perform source 1730 authentication. 1732 5.1.5.5. Request Nonce 1734 A 32-bit value copied from the Request Nonce field in a Request or 1735 Membership Query message. Used by the relay to perform source 1736 authentication. 1738 5.1.5.6. Encapsulated Group Membership Update Message 1740 An IP-encapsulated IGMP or MLD message produced by the host-mode IGMP 1741 or MLD protocol running on a gateway pseudo-interface. This field 1742 will contain of one of the following IP datagrams: 1744 IPv4:IGMPv2 Membership Report 1746 IPv4:IGMPv2 Leave Group 1748 IPv4:IGMPv3 Membership Report 1750 IPv6:MLDv1 Multicast Listener Report 1752 IPv6:MLDv1 Multicast Listener Done 1754 IPv6:MLDv2 Multicast Listener Report 1756 The source address carried by the message should be set as described 1757 in Section 5.2.1. 1759 5.1.6. Multicast Data 1761 A relay sends a Multicast Data message to deliver an multicast IP 1762 datagram or datagram fragment to a gateway. 1764 The checksum field in the UDP header of this message MAY contain a 1765 value of zero when sent over IPv4 but SHOULD, if possible, contain a 1766 valid, non-zero value when sent over IPv6 (See Section 4.2.2.3). 1768 The UDP/IP datagram containing this message MUST carry the following 1769 IP address and UDP port values: 1771 Source IP Address - The unicast IP address of the relay. 1773 Source UDP Port - The IANA-assigned AMT port number. 1775 Destination IP Address - A tunnel endpoint IP address, i.e., the 1776 source IP address carried by the Membership Update message sent by 1777 a gateway to indicate an interest in receiving the multicast 1778 packet. Note: The value of this field may be changed as a result 1779 of network address translation before arriving at the gateway. 1781 Destination UDP Port - A tunnel endpoint UDP port, i.e., the source 1782 UDP port carried by the Membership Update message sent by a 1783 gateway to indicate an interest in receiving the multicast packet. 1784 Note: The value of this field may be changed as a result of 1785 network address translation before arriving at the gateway. 1787 0 1 2 3 1788 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 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | V=0 |Type=6 | Reserved | | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1792 | | 1793 ~ IP Multicast Packet ~ 1794 | | 1795 + - - - - - - - - - - - - - - - - - - - - - - - -+ 1796 | : : : : 1797 +-+-+-+-+-+-+-+-+- - - - - - - - - - - - - - - - - - - - - - - - 1799 Multicast Data Message Format 1801 5.1.6.1. Version (V) 1803 The protocol version number for this message is 0. 1805 5.1.6.2. Type 1807 The type number for this message is 6. 1809 5.1.6.3. Reserved 1811 Bits that MUST be set to zero by the relay and ignored by the 1812 gateway. 1814 5.1.6.4. IP Multicast Data 1816 A complete IPv4 or IPv6 multicast datagram or datagram fragment. 1818 5.1.7. Teardown 1820 A gateway sends a Teardown message to a relay to request that it stop 1821 sending Multicast Data messages to a tunnel endpoint created by an 1822 earlier Membership Update message. A gateway sends this message when 1823 it detects that a Request message sent to the relay carries an 1824 address that differs from that carried by a previous Request message. 1825 The gateway uses the Gateway IP Address and Gateway Port Number 1826 Fields in the Membership Query message to detect these address 1827 changes. 1829 To provide backwards compatibility with early implementations of the 1830 AMT protocol, support for this message and associated procedures is 1831 considered OPTIONAL - gateways are not required to send this message 1832 and relays are not required to act upon it. 1834 The UDP/IP datagram containing this message MUST carry a valid, non- 1835 zero UDP checksum and carry the following IP address and UDP port 1836 values: 1838 Source IP Address - The IP address of the gateway interface used to 1839 send the message. This address may differ from that used to send 1840 earlier messages. Note: The value of this field may be changed as 1841 a result of network address translation before arriving at the 1842 relay. 1844 Source UDP Port - The UDP port number. This port number may differ 1845 from that used to send earlier messages. Note: The value of this 1846 field may be changed as a result of network address translation 1847 before arriving at the relay. 1849 Destination IP Address - The unicast IP address of the relay. 1851 Destination UDP Port - The IANA-assigned AMT port number. 1853 0 1 2 3 1854 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 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 | V=0 |Type=7 | Reserved | Response MAC | 1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1858 | | 1859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 | Request Nonce | 1861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1862 | Gateway Port Number | | 1863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 1864 | | 1865 + + 1866 | Gateway IP Address (IPv4 or IPv6) | 1867 + + 1868 | | 1869 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1870 | | 1871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1873 Membership Teardown Message Format 1875 5.1.7.1. Version (V) 1877 The protocol version number for this message is 0. 1879 5.1.7.2. Type 1881 The type number for this message is 7. 1883 5.1.7.3. Reserved 1885 Reserved bits that MUST be set to zero by the gateway and ignored by 1886 the relay. 1888 5.1.7.4. Response MAC 1890 A 48-bit value copied from the Response MAC field (Section 5.1.4.6) 1891 in the last Membership Query message the relay sent to the gateway 1892 endpoint address of the tunnel to be torn down. The gateway endpoint 1893 address is provided by the Gateway IP Address and Gateway Port Number 1894 fields carried by the Membership Query message. The relay validates 1895 the Teardown message by comparing this value with one computed from 1896 the Request Nonce, Gateway Port Number and Gateway IP Address fields 1897 (just as it does in the Membership Update message). 1899 5.1.7.5. Request Nonce 1901 A 32-bit value copied from the Request Nonce field (Section 5.1.4.7) 1902 in the last Membership Query message the relay sent to the gateway 1903 endpoint address of the tunnel to be torn down. The gateway endpoint 1904 address is provided by the Gateway IP Address and Gateway Port Number 1905 fields carried by the Membership Query message. This value must 1906 match that used by the relay to compute the value stored in the 1907 Response MAC field. 1909 5.1.7.6. Gateway Port Number 1911 A 16-bit UDP port number that, when combined with the value contained 1912 in the Gateway IP Address field, forms the tunnel endpoint address 1913 that the relay will use to identify the tunnel instance to tear down. 1914 The relay provides this value to the gateway using the Gateway Port 1915 Number field (Section 5.1.4.9.1) in a Membership Query message. This 1916 port number must match that used by the relay to compute the value 1917 stored in the Response MAC field. 1919 5.1.7.7. Gateway IP Address 1921 A 16-byte IP address that, when combined with the value contained in 1922 the Gateway Port Number field, forms the tunnel endpoint address that 1923 the relay will used to identify the tunnel instance to tear down. 1924 The relay provides this value to the gateway using the Gateway IP 1925 Address field (Section 5.1.4.9.2) in a Membership Query message. 1926 This field may contain an IPv6 address or an IPv4 address stored as 1927 an IPv4-compatible IPv6 address, where the IPv4 address is prefixed 1928 with 96 bits set to zero (See [RFC4291]). This address must match 1929 that used by the relay to compute the value stored in the Response 1930 MAC field. 1932 5.2. Gateway Operation 1934 The following sections describe gateway implementation requirements. 1935 A non-normative discussion of gateway operation may be found in 1936 Section 4.2. 1938 5.2.1. IP/IGMP/MLD Protocol Requirements 1940 Gateway operation requires a subset of host mode IPv4/IGMP and IPv6/ 1941 MLD functionality to provide group membership tracking, general query 1942 processing, and report generation. A gateway MAY use IGMPv2 (ASM), 1943 IGMPv3 (ASM and SSM), MLDv1 (ASM) or MLDv2 (ASM and SSM). 1945 An application with embedded gateway functionality must provide its 1946 own implementation of this subset of the IPv4/IGMP and IPv6/MLD 1947 protocols. The service interface used to manipulate group membership 1948 state need not match that described in the IGMP and MLD 1949 specifications, but the actions taken as a result SHOULD be similar 1950 to those described in Section 5.1 of [RFC3376] and Section 6.1 of 1951 [RFC3810]. The gateway application will likely need to implement 1952 many of the same functions as a host IP stack, including checksum 1953 verification, dispatching, datagram filtering and forwarding, and IP 1954 encapsulation/decapsulation. 1956 The IP-encapsulated IGMP messages generated by the gateway IPv4/IGMP 1957 implementation MUST conform to the description found in Section 4 of 1958 [RFC3376]. These datagrams MUST possess the IP headers, header 1959 options and header values called for in [RFC3376], with the following 1960 exception; the source IP address for an IGMP report datagram MAY be 1961 set to the "unspecified" address (all octets are zero ) but SHOULD be 1962 set to an address in the address range specifically assigned by IANA 1963 for use in the IGMP messages sent from a gateway to a relay (i.e. 1964 154.7.1.2 through 154.7.1.254 as described in Section 7). This 1965 exception is made because the gateway pseudo-interface might not 1966 possess an assigned address, and even if such an address exists, that 1967 address would not be a valid link-local source address on any relay 1968 interface. The rationale for using the aforementioned source 1969 addresses is primarily one of convenience - a relay will accept an 1970 IGMP report carried by a Membership Update message regardless of the 1971 source address it carries. See Section 5.3.1. 1973 The IP-encapsulated MLD messages generated by the gateway IPv6/MLD 1974 implementation MUST conform to the description found in Section 5 of 1975 [RFC3810]. These datagrams MUST possess the IP headers, header 1976 options and header values called for in [RFC3810], with the following 1977 exception; the source IP address for an MLD report datagram MAY be 1978 set to the "unspecified" address (all octets are zero ) but SHOULD be 1979 set to an IPv6 link-local address in the range FE80::/64 excluding 1980 FE80::1 and FE80::2. This exception is made because the gateway 1981 pseudo-interface might not possess a valid IPv6 address. As with 1982 IGMP, a relay will accept an MLD report carried by a Membership 1983 Update message regardless of the source address it carries. See 1984 Section 5.3.1. 1986 The gateway IGMP/MLD implementation SHOULD retransmit unsolicited 1987 membership state-change reports and merge new state change reports 1988 with pending reports as described in Section 5.1 of [RFC3376] and 1989 Section 6.1 of [RFC3810]. The number of retransmissions is specified 1990 by the relay in the Querier's Robustness Variable (QRV) field in the 1991 last general query forwarded by the pseudo-interface. 1993 The gateway IGMP/MLD implementation SHOULD handle general query 1994 messages as described in Section 5.2 of [RFC3376] and Section 6.2 of 1995 [RFC3810], but MAY ignore the Max Resp Code field value and generate 1996 a current state report without any delay. 1998 An IPv4 gateway implementation MUST accept IPv4 datagrams that carry 1999 the general query variant of the IGMPv3 Membership Query message, as 2000 described in Section 4 of [RFC3376]. The gateway MUST accept the 2001 IGMP datagram regardless of the IP source address carried by that 2002 datagram. 2004 An IPv6 gateway implementation MUST accept IPv6 datagrams that carry 2005 the general query variant of the MLDv2 Multicast Listener Query 2006 message, as described in Section 5 of [RFC3810]. The gateway MUST 2007 accept the MLD datagram regardless of the IP source address carried 2008 by that datagram. 2010 5.2.2. Pseudo-Interface Configuration 2012 A gateway host may possess or create multiple gateway pseudo- 2013 interfaces, each with a unique configuration that describes a binding 2014 to a specific IP protocol, relay address, relay discovery address or 2015 upstream network interface. 2017 5.2.2.1. Relay Discovery Address 2019 If a gateway implementation uses AMT relay discovery to obtain a 2020 relay address, it must first be supplied with a relay discovery 2021 address. The relay discovery address may be an anycast or unicast 2022 address. A gateway implementation may rely on a static address 2023 assignment or some form of dynamic address discovery. This 2024 specification does not require that a gateway implementation use any 2025 particular method to obtain a relay discovery address - an 2026 implementation may employ any method that returns a suitable relay 2027 discovery address. 2029 5.2.2.2. Relay Address 2031 Before a gateway implementation can execute the AMT protocol to 2032 request and receive multicast traffic, it must be supplied with a 2033 unicast relay address. A gateway implementation may rely on static 2034 address assignment or support some form of dynamic address discovery. 2035 This specification does not require the use of any particular method 2036 to obtain a relay address - an implementation may employ any method 2037 that returns a suitable relay address. 2039 5.2.2.3. Upstream Interface Selection 2041 A gateway host that possesses multiple network interfaces or 2042 addresses may allow for an explicit selection of the interface to use 2043 when communicating with a relay. The selection might be made to 2044 satisfy connectivity, tunneling or IP protocol requirements. 2046 5.2.2.4. Optional Retransmission Parameters 2048 A gateway implementation that supports retransmission MAY require the 2049 following information: 2051 Discovery Timeout 2052 Initial time to wait for a response to a Relay Discovery message. 2054 Maximum Relay Discovery Retransmission Count 2055 Maximum number of Relay Discovery retransmissions to allow before 2056 terminating relay discovery and reporting an error. 2058 Request Timeout 2059 Initial time to wait for a response to a Request message. 2061 Maximum Request Retransmission Count 2062 Maximum number of Request retransmissions to allow before 2063 abandoning a relay and restarting relay discovery or reporting an 2064 error. 2066 Maximum Retries Count For "Destination Unreachable" 2067 The maximum number of times a gateway should attempt to send the 2068 same Request or Membership Update message after receiving an ICMP 2069 "Destination Unreachable". 2071 5.2.3. Gateway Service 2073 In the following descriptions, a gateway pseudo interface is treated 2074 as a passive entity managed by a gateway service. The gateway 2075 pseudo-interface provides the state and the gateway service provides 2076 the processing. The term "gateway" is used when describing service 2077 behavior with respect to a single pseudo-interface. 2079 5.2.3.1. Startup 2081 When a gateway pseudo-interface is started, the gateway service 2082 begins listening for AMT messages sent to the UDP endpoint(s) 2083 associated with the pseudo-interface and for any locally-generated 2084 IGMP/MLD messages passed to the pseudo-interface. The handling of 2085 these messages is described below. 2087 When the pseudo-interface is enabled, the gateway service MAY: 2089 o Optionally execute the relay discovery procedure described in 2090 Section 5.2.3.4. 2092 o Optionally execute the membership query procedure described in 2093 Section 5.2.3.5 to start the periodic membership update cycle. 2095 5.2.3.2. Handling AMT Messages 2097 A gateway MUST ignore any datagram it receives that cannot be 2098 interpreted as a Relay Advertisement, Membership Query, or Multicast 2099 Data message. The handling of Relay Advertisement, Membership Query, 2100 and Multicast Data messages is addressed in the sections that follow. 2102 While listening for AMT messages, a gateway may be notified that an 2103 ICMP Destination Unreachable message was received as a result of an 2104 AMT message transmission. Handling of ICMP Destination Unreachable 2105 messages is described in Section 5.2.3.9. 2107 5.2.3.3. Handling Multicast Data Messages 2109 A gateway may receive Multicast Data messages after it sends a 2110 Membership Update message to a relay that adds a group subscription. 2111 The gateway may continue to receive Multicast Data messages long 2112 after the gateway sends a Membership Update message that deletes 2113 existing group subscriptions. The gateway MUST be prepared to 2114 receive these messages at any time, but MAY ignore them or discard 2115 their contents if the gateway no longer has any interest in receiving 2116 the multicast datagrams contained within them. 2118 A gateway MUST ignore a Multicast Data message if it fails to satisfy 2119 any of the following requirements: 2121 o The source IP address and UDP port carried by the Multicast Data 2122 message MUST be equal to the destination IP address and UDP port 2123 carried by the matching Membership Update message (i.e., the 2124 current relay address). 2126 o The destination address carried by the encapsulated IP datagram 2127 MUST fall within the multicast address allocation assigned to the 2128 relevant IP protocol, i.e., 224.0.0.0/4 for IPv4 and FF00::/8 for 2129 IPv6. 2131 The gateway extracts the encapsulated IP datagram and forwards it to 2132 the local IP protocol implementation for checksum verification, 2133 fragmented datagram reassembly, source and group filtering, and 2134 transport-layer protocol processing. 2136 Because AMT uses UDP encapsulation to deliver multicast datagrams to 2137 gateways, it qualifies as a tunneling protocol subject to the 2138 limitations described in [I-D.ietf-6man-udpzero]. If supported, a 2139 gateway SHOULD employ the solution described in 2140 [I-D.ietf-6man-udpchecksums] to ensure that the local IP stack does 2141 not discard IPv6 datagrams with zero checksums. If Multicast Data 2142 message datagrams are processed directly within the gateway (instead 2143 of the host IP stack), the gateway MUST NOT discard any of these 2144 datagrams because they carry a UDP checksum of zero. 2146 5.2.3.4. Relay Discovery Procedure 2148 This section describes gateway requirements related to the relay 2149 discovery message sequence described in Section 4.2.1.1. 2151 5.2.3.4.1. Starting Relay Discovery 2153 A gateway may start or restart the relay discovery procedure in 2154 response to the following events: 2156 o When a gateway pseudo-interface is started (enabled). 2158 o When the gateway wishes to report a group subscription when none 2159 currently exist. 2161 o Before sending the next Request message in a membership update 2162 cycle, i.e., each time the query timer expires (see below). 2164 o After the gateway fails to receive a response to a Request 2165 message. 2167 o After the gateway receives a Membership Query message with the 2168 L-flag set to 1. 2170 5.2.3.4.2. Sending a Relay Discovery Message 2172 A gateway sends a Relay Discovery message to a relay to start the 2173 relay discovery process. 2175 The gateway MUST send the Relay Discovery message using the current 2176 Relay Discovery Address and IANA-assigned UDP port number as the 2177 destination. The Discovery Nonce value in the Relay Discovery 2178 message MUST be computed as described in Section 5.2.3.4.5. 2180 The gateway MUST save a copy of Relay Discovery message or save the 2181 Discovery Nonce value for possible retransmission and verification of 2182 a Relay Advertisement response. 2184 When a gateway sends a Relay Discovery message, it may be notified 2185 that an ICMP Destination Unreachable message was received as a result 2186 of an earlier AMT message transmission. Handling of ICMP Destination 2187 Unreachable messages is described in Section 5.2.3.9. 2189 5.2.3.4.3. Waiting for a Relay Advertisement Message 2191 A gateway MAY retransmit a Relay Discovery message if it does not 2192 receive a matching Relay Advertisement message within some timeout 2193 period. If the gateway retransmits the message multiple times, the 2194 timeout period SHOULD be adjusted to provide an random exponential 2195 back-off. The RECOMMENDED timeout is a random value in the range 2196 [initial_timeout, MIN(initial_timeout * 2^retry_count, 2197 maximum_timeout)], with a RECOMMENDED initial_timeout of 1 second and 2198 a RECOMMENDED maximum_timeout of 120 seconds (which is the 2199 recommended minimum NAT mapping timeout described in [RFC4787]). 2201 5.2.3.4.4. Handling a Relay Advertisement Message 2203 When a gateway receives a Relay Advertisement message it must first 2204 determine whether it should accept or ignore the message. A gateway 2205 MUST ignore a Relay Advertisement message if it fails to satisfy any 2206 of the following requirements: 2208 o The gateway MUST be waiting for a Relay Advertisement message. 2210 o The Discovery Nonce value contained in the Relay Advertisement 2211 message MUST equal to the Discovery Nonce value contained in the 2212 Relay Discovery message. 2214 o The source IP address and UDP port of the Relay Advertisement 2215 message MUST equal to the destination IP address and UDP port of 2216 the matching Relay Discovery message. 2218 Once a gateway receives a Relay Advertisement response to a Relay 2219 Discovery message, it SHOULD ignore any other Relay Advertisements 2220 that arrive on the AMT interface until it sends a new Relay Discovery 2221 message. 2223 If a gateway executes the relay discovery procedure at the start of 2224 each membership update cycle and the relay address returned in the 2225 latest Relay Advertisement message differs from the address returned 2226 in a previous Relay Advertisement message, then the gateway SHOULD 2227 send a Teardown message (if supported) to the old relay address, 2228 using information from the last Membership Query message received 2229 from that relay, as described in Section 5.2.3.7. This behavior is 2230 illustrated in the following diagram. 2232 Gateway Relay-1 2233 ------- ------- 2234 : : 2235 Query Expired | | 2236 Timer (QT)-------->| | 2237 | Relay Discovery | 2238 |------------------->| 2239 | | 2240 | Relay Advertisement| 2241 |<-------------------| 2242 | | 2243 | Request | 2244 |------------------->| 2245 | | 2246 | Membership Query | 2247 |<===================| 2248 Start | | 2249 (QT)<--------| Membership Update | 2250 |===================>| 2251 | | 2252 ~ ~ Relay-2 2253 Expired | | ------- 2254 (QT)-------->| | : 2255 | Relay Discovery | | 2256 |------------------------------------>| 2257 | | | 2258 | Relay Advertisement| | 2259 |<------------------------------------| 2260 | | | 2261 | Teardown | | 2262 |------------------->| | 2263 | | | 2264 | Request | | 2265 |------------------------------------>| 2266 | | | 2267 | Membership Query | | 2268 |<====================================| 2269 Start | | | 2270 (QT)<--------| Membership Update | | 2271 |====================================>| 2272 | | | 2273 : : : 2275 Teardown After Relay Address Change 2277 5.2.3.4.5. Discovery Nonce Generation 2279 The discovery nonce MUST be a random, non-zero, 32-bit value, and if 2280 possible, SHOULD be computed using a cryptographically secure pseudo 2281 random number generator. A new nonce SHOULD be generated each time 2282 the gateway restarts the relay discovery process. The same nonce 2283 SHOULD be used when retransmitting a Relay Discovery message. 2285 5.2.3.5. Membership Query Procedure 2287 This section describes gateway requirements related to the membership 2288 update message sequence described in Section 4.2.1.2. 2290 5.2.3.5.1. Starting the Membership Update Cycle 2292 A gateway may send a Request message to start a membership update 2293 cycle (following the optional relay discovery procedure) in response 2294 to the following events: 2296 o When the gateway pseudo-interface is activated. 2298 o When the gateway wishes to report a group subscription when none 2299 currently exist. 2301 Starting the membership update cycle when a gateway pseudo-interface 2302 is started provides several benefits: 2304 o Better performance by allowing state-change reports to be sent as 2305 they are generated, thus minimizing the time to join. 2307 o More robustness by relying on unsolicited state-change reports to 2308 update group membership state rather than the current-state 2309 reports generated by the membership update cycle. Unsolicited 2310 state-change reports are typically retransmitted multiple times 2311 while current-state reports are not. 2313 o Simplified implementation by eliminating any need to queue IGMP/ 2314 MLD messages for delivery after a Membership Query is received, 2315 since the IGMP/MLD state-change messages may be sent as they are 2316 generated. 2318 However, this approach places an additional load on relays as a 2319 gateway will send periodic requests even when it has no multicast 2320 subscriptions. To reduce load on a relay, a gateway SHOULD only send 2321 a Membership Update message while it has active group subscriptions. 2322 A relay will still need to compute a Response MAC for each Request, 2323 but will not be required to recompute it a second time to 2324 authenticate a Membership Update message that contains no 2325 subscriptions. 2327 5.2.3.5.2. Sending a Request Message 2329 A gateway sends a Request message to a relay to solicit a Membership 2330 Query response and start the membership update cycle. 2332 A gateway constructs a Request message containing a Request Nonce 2333 value computed as described in Section 5.2.3.5.6. The gateway MUST 2334 set the "P" flag in the Request message to identify the protocol the 2335 gateway wishes the relay to use for the general query response. 2337 A gateway MUST send a Request message using the current Relay Address 2338 and IANA-assigned AMT port number as the destination. 2340 A gateway MUST save a copy of the Request message or save the Request 2341 Nonce and P-flag values for possible retransmission and verification 2342 of a Membership Query response. 2344 When a gateway sends a Request message, it may be notified that an 2345 ICMP Destination Unreachable message was received as a result of an 2346 earlier AMT message transmission. Handling of ICMP Destination 2347 Unreachable messages is described in Section 5.2.3.9. 2349 5.2.3.5.3. Waiting for a Membership Query Message 2351 A gateway MAY retransmit a Request message if it does not receive a 2352 matching Membership Query message within some timeout period. If the 2353 gateway retransmits the message multiple times, the timeout period 2354 SHOULD be adjusted to provide an random exponential back-off. The 2355 RECOMMENDED timeout is a random value in the range [initial_timeout, 2356 MIN(initial_timeout * 2^retry_count, maximum_timeout)], with a 2357 RECOMMENDED initial_timeout of 1 second and a RECOMMENDED 2358 maximum_timeout of 120 seconds (which is the recommended minimum NAT 2359 mapping timeout described in [RFC4787]). 2361 If a gateway that uses relay discovery does not receive a Membership 2362 Query within a specified time period or after a specified number of 2363 retries, the gateway SHOULD stop waiting for a Membership Query 2364 message and restart relay discovery to locate another relay. 2366 5.2.3.5.4. Handling a Membership Query Message 2368 When a gateway receives a Membership Query message it must first 2369 determine whether it should accept or ignore the message. A gateway 2370 MUST ignore a Membership Query message, or the encapsulated IP 2371 datagram within it, if the message fails to satisfy any of the 2372 following requirements: 2374 o The gateway MUST be waiting for a Membership Query message. 2376 o The Request Nonce value contained in the Membership Query MUST 2377 equal the Request Nonce value contained in the Request message. 2379 o The source IP address and UDP port of the Membership Query MUST 2380 equal the destination IP address and UDP port of the matching 2381 Request message (i.e., the current relay address). 2383 o The encapsulated IP datagram MUST carry an IGMPv3 or MLDv2 2384 message. The protocol MUST match the protocol identified by the 2385 "P" flag in the Request message. 2387 o The IGMPv3 or MLDv2 message MUST be a general query message. 2389 o The total length of the encapsulated IP datagram as computed from 2390 the lengths contained in the datagram header(s) MUST NOT exceed 2391 the available field length within the Membership Query message. 2393 Once a gateway receives a Membership Query response to a Request 2394 message, it SHOULD ignore any other Membership Query messages that 2395 arrive on the AMT interface until it sends a new Request message. 2397 The gateway MUST save the Membership Query message, or the Request 2398 Nonce, Response MAC, Gateway IP Address and Gateway Port Number 2399 fields for use in sending subsequent Membership Update and Teardown 2400 messages. 2402 The gateway extracts the encapsulated IP datagram and forwards it to 2403 the local IP protocol implementation for checksum verification and 2404 dispatching to the IGMP or MLD implementation running on the pseudo- 2405 interface. The gateway MUST NOT forward any octets that might exist 2406 between the encapsulated IP datagram and the end of the message or 2407 Gateway Address fields. 2409 The MLD protocol specification indicates that senders should use a 2410 link-local source IP address in message datagrams. This requirement 2411 must be relaxed for AMT because gateways and relays do not normally 2412 share a common subnet. For this reason, a gateway implementation 2413 MUST accept MLD (and IGMP) query message datagrams regardless of the 2414 source IP address they carry. This may require additional processing 2415 on the part of the gateway that might be avoided if the relay and 2416 gateway use the IPv4 and IPv6 addresses allocated for use in AMT 2417 encapsulated control packets as described in Section 5.2.1. 2419 The gateway MUST start a timer that will trigger the next iteration 2420 of the membership update cycle by executing the membership query 2421 procedure. The gateway SHOULD compute the timer duration from the 2422 Querier's Query Interval Code carried by the general-query. A 2423 gateway MAY use a smaller timer duration if required to refresh a NAT 2424 mapping that would otherwise timeout. A gateway MAY use a larger 2425 timer duration if it has no group subscriptions to report. 2427 If the gateway supports the Teardown message and the G-flag is set in 2428 the Membership Query message, the gateway MUST compare the Gateway IP 2429 Address and Gateway Port Number on the new Membership Query message 2430 with the values carried by the previous Membership Query message. If 2431 either value has changed the gateway MUST send a Teardown message to 2432 the relay as described in Section 5.2.3.7. 2434 If the L-flag is set in the Membership Query message, the relay is 2435 reporting that it is NOT accepting Membership Update messages that 2436 create new tunnel endpoints and will simply ignore any that do. If 2437 the L-flag is set and the gateway is not currently reporting any 2438 group subscriptions to the relay, the gateway SHOULD stop sending 2439 periodic Request messages and restart the relay discovery procedure 2440 (if discovery is enabled) to find a new relay with which to 2441 communicate. The gateway MAY continue to send updates even if the 2442 L-flag is set, if it has previously reported group subscriptions to 2443 the relay, one or more subscriptions still exist and the gateway 2444 endpoint address has not changed since the last Membership Query was 2445 received (see previous paragraph). 2447 5.2.3.5.5. Handling Query Timer Expiration 2449 When the query timer (started in the previous step) expires, the 2450 gateway should execute the membership query procedure again to 2451 continue the membership update cycle. 2453 5.2.3.5.6. Request Nonce Generation 2455 The request nonce MUST be a random value, and if possible, SHOULD be 2456 computed using a cryptographically secure pseudo random number 2457 generator. A new nonce MUST be generated each time the gateway 2458 starts the membership query process. The same nonce SHOULD be used 2459 when retransmitting a Request message. 2461 5.2.3.6. Membership Update Procedure 2463 This section describes gateway requirements related to the membership 2464 update message sequence described in Section 4.2.1.2. 2466 The membership update process is primarily driven by the host-mode 2467 IGMP or MLD protocol implementation running on the gateway pseudo- 2468 interface. The IGMP and MLD protocols produce current-state reports 2469 in response to general queries generated by the pseudo-interface via 2470 AMT and produce state-change reports in response to receiver requests 2471 made using the IGMP or MLD service interface. 2473 5.2.3.6.1. Handling an IGMP/MLD IP Datagram 2475 The gateway pseudo-interface MUST accept the following IP datagrams 2476 from the IPv4/IGMP and IPv6/MLD protocols running on the pseudo- 2477 interface: 2479 o IPv4 datagrams that carry an IGMPv2, or IGMPv3 Membership Report 2480 or an IGMPv2 Leave Group message as described in Section 4 of 2481 [RFC3376]. 2483 o IPv6 datagrams that carry an MLDv1 or MLDv2 Multicast Listener 2484 Report or an MLDv1 Multicast Listener Done message as described in 2485 Section 5 of [RFC3810]. 2487 The gateway must be prepared to receive these messages any time the 2488 pseudo-interface is running. The gateway MUST ignore any datagrams 2489 not listed above. 2491 A gateway that waits to start a membership update cycle until after 2492 it receives a datagram containing an IGMP/MLD state-change message 2493 MAY: 2495 o Discard IGMP or MLD datagrams until it receives a Membership Query 2496 message, at which time it processes the Membership Query message 2497 as normal to eventually produce a current-state report on the 2498 pseudo-interface which describes the end state (RECOMMENDED). 2500 o Insert IGMP or MLD datagrams into a queue for transmission after 2501 it receives a Membership Query message. 2503 If and when a gateway receives a Membership Query message (for IGMP 2504 or MLD) it sends any queued or incoming IGMP or MLD datagrams to the 2505 relay as described in the next section. 2507 5.2.3.6.2. Sending a Membership Update Message 2509 A gateway cannot send a Membership Update message to a relay until it 2510 has received a Membership Query message from a relay. If the gateway 2511 has not yet located a relay with which to communicate, it MUST first 2512 execute the relay discovery procedure described in Section 5.2.3.4 to 2513 obtain a relay address. If the gateway has a relay address, but has 2514 not yet received a Membership Query message, it MUST first execute 2515 the membership query procedure described in Section 5.2.3.5 to obtain 2516 a Request Nonce and Response MAC that can be used to send a 2517 Membership Update message. 2519 Once a gateway possesses a valid Relay Address, Request Nonce and 2520 Response MAC, it may encapsulate the IP datagram containing the IGMP/ 2521 MLD message into a Membership Update message. The gateway MUST copy 2522 the Request Nonce and Response MAC values from the last Membership 2523 Query received from the relay into the corresponding fields in the 2524 Membership Update. The gateway MUST send the Membership Update 2525 message using the Relay Address and IANA-assigned AMT port number as 2526 the destination. 2528 When a gateway sends a Membership Update message, it may be notified 2529 that an ICMP Destination Unreachable message was received as a result 2530 of an earlier AMT message transmission. Handling of ICMP Destination 2531 Unreachable messages is described in Section 5.2.3.9. 2533 5.2.3.7. Teardown Procedure 2535 This section describes gateway requirements related to the teardown 2536 message sequence described in Section 4.2.1.3. 2538 Gateway support for the Teardown message is OPTIONAL but RECOMMENDED. 2540 A gateway that supports Teardown SHOULD make use of Teardown 2541 functionality if it receives a Membership Query message from a relay 2542 that has the "G" flag set to indicate that it contains valid gateway 2543 address fields. 2545 5.2.3.7.1. Handling a Membership Query Message 2547 As described in Section 5.2.3.5.4, if a gateway supports the Teardown 2548 message, has reported active group subscriptions, and receives a 2549 Membership Query message with the "G" flag set, the gateway MUST 2550 compare the Gateway IP Address and Gateway Port Number on the new 2551 Membership Query message with the values carried by the previous 2552 Membership Query message. If either value has changed the gateway 2553 MUST send a Teardown message as described in the next section. 2555 5.2.3.7.2. Sending a Teardown Message 2557 A gateway sends a Teardown message to a relay to request that it stop 2558 delivering Multicast Data messages to the gateway and delete any 2559 group memberships created by the gateway. 2561 When a gateway constructs a Teardown message, it MUST copy the 2562 Request Nonce, Response MAC, Gateway IP Address and Gateway Port 2563 Number fields from the Membership Query message that provided the 2564 Response MAC for the last Membership Update message sent, into the 2565 corresponding fields of the Teardown message. 2567 A gateway MUST send the Teardown message using the Relay Address and 2568 IANA-assigned AMT port number as the destination. A gateway MAY send 2569 the Teardown message multiple times for robustness. The gateway 2570 SHOULD use the Querier's Robustness Variable (QRV) field contained in 2571 the query encapsulated within the last Membership Query to set the 2572 limit on the number of retransmissions. If the gateway sends the 2573 Teardown message multiple times, it SHOULD insert a delay between 2574 each transmission using the timing algorithm employed in IGMP/MLD for 2575 transmitting unsolicited state-change reports. The RECOMMENDED 2576 default delay value is 1 second. 2578 When a gateway sends a Teardown message, it may be notified that an 2579 ICMP Destination Unreachable message was received as a result of an 2580 earlier AMT message transmission. Handling of ICMP Destination 2581 Unreachable messages is described in Section 5.2.3.9. 2583 5.2.3.8. Shutdown 2585 When a gateway pseudo-interface is stopped and the gateway has 2586 existing group subscriptions, the gateway SHOULD either: 2588 o Send a Teardown message to the relay as described in 2589 Section 5.2.3.7, but only if the gateway supports the Teardown 2590 message, and the current relay is returning gateway address fields 2591 in Membership Query messages, or 2593 o Send a Membership Update message to the relay that will delete 2594 existing group subscriptions. 2596 5.2.3.9. Handling ICMP Destination Unreachable Responses 2598 A gateway may receive an ICMP "Destination Unreachable" message 2599 [RFC0792] after sending an AMT message. Whether the gateway is 2600 notified that an ICMP message was received is highly dependent the 2601 gateway IP stack behavior and gateway implementation. 2603 If the reception of an ICMP Destination Unreachable message is 2604 reported to the gateway while waiting to receive an AMT message, the 2605 gateway may respond as follows, depending on platform capabilities 2606 and which outgoing message triggered the ICMP response: 2608 1. The gateway MAY simply abandon the current relay and restart 2609 relay discovery (if used). This is the least desirable approach 2610 as it does not allow for transient network changes. 2612 2. If the last message sent was a Relay Discovery or Request 2613 message, the gateway MAY simply ignore the ICMP response and 2614 continue waiting for incoming AMT messages. If the gateway is 2615 configured to retransmit Relay Discovery or Request messages, the 2616 normal retransmission behavior for those messages is preserved to 2617 prevent the gateway from prematurely abandoning a relay. 2619 3. If the last message sent was a Membership Update message, the 2620 gateway MAY start a new membership update and associated Request 2621 retransmission cycle. 2623 If the reception of an ICMP Destination Unreachable message is 2624 reported to the gateway when attempting to transmit a new AMT 2625 message, the gateway may respond as follows, depending on platform 2626 capabilities and which outgoing message triggered the ICMP response: 2628 1. The gateway MAY simply abandon the current relay and restart 2629 relay discovery (if used). This is the least desirable approach 2630 as it does not allow for transient network changes. 2632 2. If the last message sent was a Relay Discovery, Request or 2633 Teardown message, the gateway MAY attempt to transmit the new 2634 message. If the gateway is configured to retransmit Relay 2635 Discovery, Request or Teardown messages, the normal 2636 retransmission behavior for those messages is preserved to 2637 prevent the gateway from prematurely abandoning a relay. 2639 3. If the last message sent was a Membership Update message, the 2640 gateway SHOULD start a new membership update and associated 2641 Request retransmission cycle. 2643 5.3. Relay Operation 2645 The following sections describe relay implementation requirements. A 2646 non-normative discussion of relay operation may be found in 2647 Section 4.2. 2649 5.3.1. IP/IGMP/MLD Protocol Requirements 2651 A relay requires a subset of router-mode IGMP and MLD functionality 2652 to provide group membership tracking and report processing. 2654 A relay accessible via IPv4 MUST support IPv4/IGMPv3 and MAY support 2655 IPv6/MLDv2. A relay accessible via IPv6 MUST support IPv6/MLDv2 and 2656 MAY support IPv4/IGMPv3. 2658 A relay MUST apply the forwarding rules described in Section 6.3 of 2659 [RFC3376] and Section 7.3 of [RFC3810]. 2661 A relay MUST handle incoming reports as described in Section 6.4 of 2662 [RFC3376] and Section 7.4 of [RFC3810] with the exception that 2663 actions that lead to queries MAY be modified to eliminate query 2664 generation. A relay MUST accept IGMP and MLD report datagrams 2665 regardless of the IP source address carried by those datagrams. 2667 All other aspects of IGMP/MLD router behavior, such as the handling 2668 of queries, querier election, etc., are not used or required for 2669 relay operation. 2671 5.3.2. Startup 2673 If a relay is deployed for anycast discovery, the relay MUST 2674 advertise an anycast Relay Discovery Address Prefix into the unicast 2675 routing system of the anycast domain. An address within that prefix, 2676 i.e., a Relay Discovery Address, MUST be assigned to a relay 2677 interface. 2679 A unicast IPv4 and/or IPv6 address MUST be assigned to the relay 2680 interface that will be used to send and receive AMT control and data 2681 messages. This address or addresses are returned in Relay 2682 Advertisement messages. 2684 The remaining details of relay "startup" are highly implementation- 2685 dependent and are not addressed in this document. 2687 5.3.3. Running 2689 When a relay is started, it begins listening for AMT messages on the 2690 interface to which the unicast Relay Address(es) has been assigned, 2691 i.e., the address returned in Relay Advertisement messages. 2693 5.3.3.1. Handling AMT Messages 2695 A relay MUST ignore any message other than a Relay Discovery, 2696 Request, Membership Update or Teardown message. The handling of 2697 Relay Discovery, Request, Membership Update, and Teardown messages is 2698 addressed in the sections that follow. 2700 Support for the Teardown message is OPTIONAL. If a relay does not 2701 support the Teardown message, it MUST also ignore this message. 2703 A relay that conforms to this specification MUST ignore any message 2704 with a Version field value other than zero. 2706 5.3.3.2. Handling a Relay Discovery Message 2708 This section describes relay requirements related to the relay 2709 discovery message sequence described in Section 4.2.1.1. 2711 A relay MUST accept and respond to Relay Discovery messages sent to 2712 an anycast relay discovery address or the unicast relay address. If 2713 a relay receives a Relay Discovery message sent to its unicast 2714 address, it MUST respond just as it would if the message had been 2715 sent to its anycast discovery address. 2717 When a relay receives a Relay Discovery message it responds by 2718 sending a Relay Advertisement message back to the source of the Relay 2719 Discovery message. The relay MUST use the source IP address and UDP 2720 port of the Relay Discovery message as the destination IP address and 2721 UDP port. The relay MUST use the destination IP address and UDP port 2722 of the Relay Discovery as the source IP address and UDP port to 2723 ensure successful NAT traversal. 2725 The relay MUST copy the value contained in the Discovery Nonce field 2726 of the Relay Discovery message into the Discovery Nonce field in the 2727 Relay Advertisement message. 2729 If the Relay Discovery message was received as an IPv4 datagram, the 2730 relay MUST return an IPv4 address in the Relay Address field of the 2731 Relay Advertisement message. If the Relay Discovery message was 2732 received as an IPv6 datagram, the relay MUST return an IPv6 address 2733 in the Relay Address field. 2735 5.3.3.3. Handling a Request Message 2737 This section describes relay requirements related to the membership 2738 query portion of the message sequence described in Section 4.2.1.2. 2740 When a relay receives a Request message it responds by sending a 2741 Membership Query message back to the source of the Request message. 2743 The relay MUST use the source IP address and UDP port of the Request 2744 message as the destination IP address and UDP port for the Membership 2745 Query message. The source IP address and UDP port carried by the 2746 Membership Query MUST match the destination IP address and UDP port 2747 of the Request to ensure successful NAT traversal. 2749 The relay MUST return the value contained in the Request Nonce field 2750 of the Request message in the Request Nonce field of the Membership 2751 Query message. The relay MUST compute a MAC value, as described in 2752 Section 5.3.5, and return that value in the Response MAC field of the 2753 Membership Query message. 2755 If a relay supports the Teardown message, it MUST set the G-flag in 2756 the Membership Query message and return the source IP address and UDP 2757 port carried by the Request message in the corresponding Gateway IP 2758 Address and Gateway Port Number fields. If the relay does not 2759 support the Teardown message it SHOULD NOT set these fields as this 2760 may cause the gateway to generate unnecessary Teardown messages. 2762 If the P-flag in the Request message is 0, the relay MUST return an 2763 IPv4-encapsulated IGMPv3 general query in the Membership Query 2764 message. If the P-flag is 1, the relay MUST return an IPv6- 2765 encapsulated MLDv2 general query in the Membership Query message. 2767 If the relay is not accepting Membership Update messages that create 2768 new tunnel endpoints due to resource limitations, it SHOULD set the 2769 L-flag in the Membership Query message to notify the gateway of this 2770 state. Support for the L-flag is OPTIONAL. See Section 5.3.3.8. 2772 The IGMPv3 general query datagram that a relay encapsulates within a 2773 Membership Query message MUST conform to the descriptions found in 2774 Section 4.1 of [RFC3376]. These datagrams MUST possess the IP 2775 headers, header options and header values called for in [RFC3376], 2776 with the following exception; the source IP address for an IGMP 2777 general query datagram MAY be set to the "unspecified" address (all 2778 octets are zero) but SHOULD be set to an address in the address range 2779 specifically assigned by IANA for use in the IGMP messages sent from 2780 a relay to a gateway (i.e. 154.7.1.1 as described in Section 7). 2781 This exception is made because the source address that a relay might 2782 normally send may not be a valid source address on any gateway 2783 interface. The rationale for using the aforementioned source 2784 addresses is primary one of convenience - a gateway will accept an 2785 IGMP query regardless of the source address it carries. See 2786 Section 5.2.1. 2788 The MLDv2 general query datagram that a relay encapsulates within a 2789 Membership Query message MUST conform to the descriptions found in 2790 Section 5.1 of [RFC3810]. These datagrams MUST possess the IP 2791 headers, header options and header values called for in [RFC3810], 2792 with the following exception; the source IP address for an MLD 2793 general query datagram MAY be set to the "unspecified" address (all 2794 octets are zero) but SHOULD be set to an IPv6 link-local address in 2795 the range FE80::/64. A relay may use a dynamically-generated link- 2796 local address or the fixed address FE80::2. As with IGMP, a gateway 2797 will accept an MLD query regardless of the source address it carries. 2798 See Section 5.2.1. 2800 A relay MUST set the Querier's Query Interval Code (QQIC) field in 2801 the general query to supply the gateway with a suggested time 2802 duration to use for the membership query timer. The QQIC field is 2803 defined in Section 4.1.1 in [RFC3376] and Section 5.1.3 in [RFC3810]. 2804 A relay MAY adjust this value to affect the rate at which the Request 2805 messages are sent from a gateway. However, a gateway is allowed to 2806 use a shorter duration than specified in the QQIC field, so a relay 2807 may be limited in its ability to spread out Requests coming from a 2808 gateway. 2810 A relay MUST set the Querier's Robustness Variable (QRV) field in the 2811 general query to a non-zero value. This value SHOULD be greater than 2812 one. If a gateway retransmits membership state change messages, it 2813 will retransmit them (robustness variable - 1) times. 2815 A relay SHOULD set the Max Resp Code field in the general query to a 2816 value of 1 to trigger an immediate response from the gateway (some 2817 host IGMP/MLD implementations may not accept a value of zero). A 2818 relay SHOULD NOT use the IGMPv2/MLDv2 Query Response Interval 2819 variable, if available, to generate the Max Resp Code field value as 2820 the Query Response Interval variable is used in setting the duration 2821 of group state timers and must not be set to such a small value. See 2822 Section 5.3.3.7. 2824 5.3.3.4. Handling a Membership Update Message 2826 This section describes relay requirements related to the membership 2827 update portion of the message sequence described in Section 4.2.1.2. 2829 When a relay receives a Membership Update message it must first 2830 determine whether it should accept or ignore the message. A relay 2831 MUST NOT make any changes to group membership and forwarding state if 2832 the message fails to satisfy any of the following requirements: 2834 o The IP datagram encapsulated within the message MUST be one of the 2835 following: 2837 * IPv4 datagram carrying an IGMPv2 or IGMPv3 Membership Report 2838 message. 2840 * IPv4 datagram carrying an IGMPv2 Leave Group message. 2842 * IPv6 datagram carrying an MLDv1 or MLDv2 Multicast Listener 2843 Report message. 2845 * IPv6 datagram carrying MLDv1 Multicast Listener Done message. 2847 o The encapsulated IP datagram MUST satisfy the IP header 2848 requirements for the IGMP or MLD message type as described in 2849 Section 4 of [RFC3376], Section 2 of [RFC2236], Section 5 of 2850 [RFC3810], and Section 3 of [RFC2710], with the following 2851 exception - a relay MUST accept an IGMP or MLD message regardless 2852 of the IP source address carried by the datagram. 2854 o The total length of the encapsulated IP datagram as computed from 2855 the lengths contained in the datagram header(s) MUST NOT exceed 2856 the available field length within the Membership Update message. 2858 o The computed checksums for the encapsulated IP datagram and its 2859 payload MUST match the values contained therein. Checksum 2860 computation and verification varies by protocol; See [RFC0791] for 2861 IPv4, [RFC3376] for IGMPv3, and [RFC4443] for MLD (ICMPv6). 2863 o If processing of the encapsulated IGMP or MLD message would result 2864 in an allocation of new state or a modification of existing state, 2865 the relay MUST authenticate the source of the Membership message 2866 by verifying that the value contained in the Response MAC field 2867 equals the MAC value computed from the fields in the Membership 2868 Update message datagram. Because the private secret used to 2869 compute Response MAC values may change over time, the relay MUST 2870 retain the previous version of the private secret to use in 2871 authenticating Membership Updates sent during the subsequent query 2872 interval. If the first attempt at Response MAC authentication 2873 fails, the relay MUST attempt to authenticate the Response MAC 2874 using the previous private secret value unless 2*query_interval 2875 time has elapsed since the private secret change. See 2876 Section 5.3.5. An alternative approach to Response MAC generation 2877 that avoids repeated Response MAC computations may be found in 2878 Appendix A.1. 2880 A relay MAY skip source authentication to reduce the computational 2881 cost of handling Membership Update messages if the relay can make a 2882 trivial determination that the IGMP/MLD message carried by the 2883 Membership Update message will produce no changes in group membership 2884 or forwarding state. The relay does not need to compute and compare 2885 MAC values if it finds there are no group subscriptions for the 2886 source of the Membership Update message and either of the following 2887 is true: 2889 o The encapsulated IP datagram is an IGMPv3 Membership Report or 2890 MLDv2 Multicast Listener Report message that contains no group 2891 records. This may often be the case for gateways that 2892 continuously repeat the membership update cycle even though they 2893 have no group subscriptions to report. 2895 o The encapsulated IP datagram is an IGMPv2 Leave Group or MLDv1 2896 Multicast Listener Done message. 2898 The IGMP and MLD protocol specifications indicate that senders SHOULD 2899 use a link-local source IP address in message datagrams. This 2900 requirement must be relaxed for AMT because gateways and relays do 2901 not share a common subnet. For this reason, a relay implementation 2902 MUST accept IGMP and MLD datagrams regardless of the source IP 2903 address they carry. 2905 Once a relay has determined that the Membership Update message is 2906 valid, it processes the encapsulated IGMP or MLD membership message 2907 to update group membership state and communicates with the multicast 2908 protocol to update forwarding state and possibly send multicast 2909 protocol messages towards upstream routers. The relay MUST ignore 2910 any octets that might exist between the encapsulated IP datagram and 2911 the end of the Membership Update message. 2913 As described in Section 4.2.2, a relay uses the source IP address and 2914 source UDP port carried by a Membership Update messages to identify a 2915 tunnel endpoint. A relay uses the tunnel endpoint as the destination 2916 address for any Multicast Data messages it sends as a result of the 2917 group membership and forwarding state created by processing the IGMP/ 2918 MLD messages contained in Membership Update messages received from 2919 the endpoint. 2921 If a Membership Update message originates from a new endpoint, the 2922 relay MUST determine whether it can accept updates from a new 2923 endpoint. If a relay has been configured with a limit on the total 2924 number of endpoints, or a limit on the total number of endpoints for 2925 a given source address, then the relay MAY ignore the Membership 2926 Update message and possibly withdraw any Relay Discovery Address 2927 Prefix announcement that it might have made. See Section 5.3.3.8. 2929 A relay MUST maintain some form of group membership database for each 2930 endpoint. The per-endpoint databases are used update a forwarding 2931 table containing entries that map an (*,G) or (S,G) subscription to a 2932 list of tunnel endpoints. 2934 A relay MUST maintain some form of group membership database 2935 representing a merger of the group membership databases of all 2936 endpoints. The merged group membership database is used to update 2937 upstream multicast forwarding state. 2939 A relay MUST maintain a forwarding table that maps each unique (*,G) 2940 and (S,G) subscription to a list of tunnel endpoints. A relay uses 2941 this forwarding table to provide the destination address when 2942 performing UDP/IP encapsulation of the incoming multicast IP 2943 datagrams to form Multicast Data messages. 2945 If a group filter mode for a group entry on a tunnel endpoint is 2946 EXCLUDE, the relay SHOULD NOT forward datagrams that originate from 2947 sources in the filter source list unless the relay architecture does 2948 not readily support source filtering. A relay MAY ignore the source 2949 list if necessary because gateways are expected to do their own 2950 source filtering. 2952 5.3.3.5. Handling a Teardown Message 2954 This section describes relay requirements related to the teardown 2955 message sequence described in Section 4.2.1.3. 2957 When a relay (that supports the Teardown message) receives a Teardown 2958 message, it MUST first authenticate the source of the Teardown 2959 message by verifying that the Response MAC carried by the Teardown 2960 message is equal to a MAC value computed from the fields carried by 2961 the Teardown message. The method used to compute the MAC differs 2962 from that used to generate and validate the Membership Query and 2963 Membership Update messages in that the source IP address and source 2964 UDP port number used to compute the MAC are taken from the Gateway IP 2965 Address and Gateway Port Number field in the Teardown message rather 2966 than from the IP and UDP headers in the datagram that carries the 2967 Teardown message. The MAC computation is described Section 5.3.5. A 2968 relay MUST ignore a Teardown message If the computed MAC does not 2969 equal the value of the Response MAC field. 2971 If a relay determines that a Teardown message is authentic, it MUST 2972 immediately stop transmitting Multicast Data messages to the endpoint 2973 identified by the Gateway IP Address and Gateway Port Number fields 2974 in the message. The relay MUST eventually delete any group 2975 membership and forwarding state associated with the endpoint, but MAY 2976 delay doing so to allow a gateway to recreate group membership state 2977 on a new endpoint and thereby avoid making unnecessary (temporary) 2978 changes in upstream routing/forwarding state. 2980 The state changes made by a relay when processing a Teardown message 2981 MUST be identical to those that would be made as if the relay had 2982 received an IGMP/MLD report that would cause the IGMP or MLD protocol 2983 to delete all existing group records in the group membership database 2984 associated with the endpoint. The processing of the Teardown message 2985 should trigger or mimic the normal interaction between IGMP or MLD 2986 and a multicast protocol to produce required changes in forwarding 2987 state and possibly send prune/leave messages towards upstream 2988 routers. 2990 5.3.3.6. Handling Multicast IP Datagrams 2992 When a multicast IP datagram is forwarded to the relay pseudo- 2993 interface, the relay MUST, for each gateway that has expressed an 2994 interest in receiving the datagram, encapsulate the IP datagram into 2995 a Multicast Data message and send that message to the gateway. This 2996 process is highly implementation dependent, but conceptually requires 2997 the following steps: 2999 o Use the IP datagram source and destination address to look up the 3000 appropriate (*,G) or (S,G) entry in the endpoint forwarding table 3001 created for the pseudo-interface as a result of IGMP/MLD 3002 processing. 3004 o Possibly replicate the datagram for each gateway endpoint listed 3005 for that (*,G) or (S,G) entry. 3007 o Encapsulate the IP datagram in a UDP/IP Membership Data message, 3008 using the endpoint UDP/IP address as the destination address and 3009 the unicast relay address and IANA-assigned port as the source 3010 UDP/IP address. To ensure successful NAT traversal, the source 3011 address and port MUST match the destination address and port 3012 carried by the Membership Update message sent by the gateway to 3013 create the forwarding table entry. 3015 o If possible, the relay SHOULD compute a valid, non-zero checksum 3016 for the UDP datagram carrying the Membership Data message. See 3017 Section 4.2.2.3. 3019 o Send the message to the gateway. 3021 The relay pseudo-interface MUST ignore any other IP datagrams 3022 forwarded to the pseudo-interface. 3024 5.3.3.7. State Timers 3026 A relay MUST maintain a timer or timers whose expiration will trigger 3027 the removal of any group subscriptions and forwarding state 3028 previously created for a gateway endpoint should the gateway fail to 3029 refresh the group membership state within a specified time interval. 3031 A relay MAY use a variant of the IGMPv3/MLDv2 state management 3032 protocol described in Section 6 of [RFC3376] or Section 7 of 3033 [RFC3810], or may maintain a per-endpoint timer to trigger the 3034 deletion of group membership state. 3036 If a per-endpoint timer is used, the relay MUST restart this timer 3037 each time it receives a new Membership Update message from the 3038 gateway endpoint. 3040 The endpoint timer duration MAY be computed from tunable IGMP/MLD 3041 variables as follows: 3043 ((Robustness_Variable) * (Query_Interval)) + Query_Response_Interval 3045 If IGMP/MLD default values are used for these variables, the gateway 3046 will timeout after 125s * 2 + 10s = 260s. The timer duration MUST be 3047 greater than the query interval suggested in the last Membership 3048 Query message sent to the gateway endpoint. 3050 Regardless of the timers used (IGMPv3/MLDv2 or endpoint), the 3051 Query_Response_Interval value SHOULD be greater than or equal to 10s 3052 to allow for packet loss and round-trip time in the Request/ 3053 Membership Query message exchange. 3055 5.3.3.8. Relay Resource Management 3057 A relay may be configured with various service limits to ensure a 3058 minimum level of performance for gateways that connect to it. 3060 If a relay has determined that it has reached or exceeded maximum 3061 allowable capacity or has otherwise exhausted resources required to 3062 support additional gateways, it SHOULD withdraw any Relay Discovery 3063 Address Prefix it has advertised into the unicast internetwork and 3064 SHOULD set the L-flag in any Membership Query messages it returns to 3065 gateways while in this state. 3067 If the relay receives an update from a gateway that adds group 3068 membership or forwarding state for an endpoint that has already 3069 reached maximum allowable state entries, the relay SHOULD continue to 3070 accept updates from the gateway but ignore any group membership/ 3071 forwarding state additions requested by that gateway. 3073 If the relay receives an update from a gateway that would create a 3074 new tunnel endpoint for a source IP address that has already reached 3075 the maximum allowable number of endpoints (maximum UDP ports), it 3076 should simply ignore the Membership Update. 3078 5.3.4. Shutdown 3080 The following steps should be treated as an abstract description of 3081 the shutdown procedure for a relay: 3083 o Withdraw the Relay Discovery Address Prefix advertisement (if 3084 used). 3086 o Stop listening for Relay Discovery messages. 3088 o Stop listening for control messages from gateways. 3090 o Stop sending data messages to gateways. 3092 o Delete all AMT group membership and forwarding state created on 3093 the relay, coordinating with the multicast routing protocol to 3094 update the group membership state on upstream interfaces as 3095 required. 3097 5.3.5. Response MAC Generation 3099 A Response MAC is produced by a hash digest computation. A Response 3100 MAC value is computed from a Request message for inclusion in a 3101 Membership Query message, is computed from a Membership Update 3102 message to authenticate the Response MAC carried within that message, 3103 and is computed from fields in a Teardown message to authenticate the 3104 Response MAC carried within that message. 3106 Gateways treat the Response MAC field as an opaque value, so a relay 3107 implementation may generate the MAC using any method available to it. 3108 The hash function RECOMMENDED for use in computing the Response MAC 3109 is the MD5 hash digest [RFC1321], though hash functions or keyed-hash 3110 functions of greater cryptographic strength may be used. 3112 The digest MUST be computed over the following values: 3114 o The Source IP address of the message (or Teardown Gateway IP 3115 Address field) 3117 o The Source UDP port of the message (or Teardown Gateway Port 3118 Number field) 3120 o The Request Nonce contained in the message. 3122 o A private secret known only to the relay 3124 An Response MAC generation solution that satisfies these requirements 3125 is described in Appendix A.1. 3127 5.3.6. Private Secret Generation 3129 The private secret, or hash-key, is a random value that the relay 3130 includes in the Response MAC hash digest computation. A relay SHOULD 3131 periodically compute a new private secret. The RECOMMENDED maximum 3132 interval is 2 hours. A relay MUST retain the prior secret for use in 3133 verifying MAC values that were sent to gateways just prior to the use 3134 of the new secret. 3136 The private secret SHOULD be computed using a cryptographically- 3137 secure pseudo-random number generator. The private secret width 3138 SHOULD equal that of the hash function used to compute the Response 3139 MAC, e.g., 128-bits for an MD5 hash. 3141 6. Security Considerations 3143 AMT is not intended to be a strongly secured protocol. In general, 3144 the protocol provides the same level of security and robustness as is 3145 provided by the UDP, IGMP and MLD protocols on which it relies. The 3146 lack of strong security features can largely be attributed to the 3147 desire to make the protocol light-weight by minimizing the state and 3148 computation required to service a single gateway, thereby allowing a 3149 relay to service a larger number of gateways. 3151 Many of the threats and vectors described in [RFC3552] may be 3152 employed against the protocol to launch various types of denial-of- 3153 service attacks that can affect the functioning of gateways or their 3154 ability to locate and communicate with a relay. These scenarios are 3155 described below. 3157 As is the case for UDP, IGMP and MLD, the AMT protocol provides no 3158 mechanisms for ensuring message delivery or integrity. The protocol 3159 does not provide confidentiality - multicast groups, sources and 3160 streams requested by a gateway are sent in the clear. 3162 The protocol does use a three-way handshake to provide trivial source 3163 authentication for state allocation and updates (see below). The 3164 protocol also requires gateways and relays to ignore malformed 3165 messages and those messages that do not carry expected address values 3166 or protocol payload types or content. 3168 6.1. Relays 3170 The three-way handshake provided by the membership update message 3171 sequence (See (Section 4.2.1.2)) provides a defense against source- 3172 spoofing-based resource-exhaustion attacks on a relay by requiring 3173 source authentication before state allocation. However, attackers 3174 may still attempt to flood a relay with Request and Membership Update 3175 messages to force the relay to make the hash computations in an 3176 effort to consume computational resources. Implementations may 3177 choose to limit the frequency with which a relay responds to Request 3178 messages sent from a single IP address or IP address and UDP port 3179 pair, but support for this functionality is not required. The three- 3180 way handshake provides no defense against an eavesdropping or man-in- 3181 the-middle attacker. 3183 Attackers that execute the gateway protocol may consume relay 3184 resources by instantiating a large number of tunnels or joining a 3185 large number of multicast streams. A relay implementation should 3186 provide a mechanism for limiting the number of tunnels (Multicast 3187 Data message destinations) that can be created for a single gateway 3188 source address. Relays should also provide a means for limiting the 3189 number of joins per tunnel instance as a defense against these 3190 attacks. 3192 Relays may withdraw their AMT anycast prefix advertisement when they 3193 reach configured maximum capacity or exhaust required resources. 3194 This behavior allows gateways to use the relay discovery process to 3195 find the next topologically-nearest relay that has advertised the 3196 prefix. This behavior also allows a successful resource exhaustion 3197 attack to propagate from one relay to the next until all relays 3198 reachable using the anycast address have effectively been taken 3199 offline. This behavior may also be used to acquire the unicast 3200 addresses for individual relays which can then be used to launch a 3201 DDoS attack on all of the relays without using the relay discovery 3202 process. To prevent wider disruption of AMT-based distribution 3203 network, relay anycast address advertisements can be limited to 3204 specific administrative routing domains. This will isolate such 3205 attacks to a single domain. 3207 6.2. Gateways 3209 A passive eavesdropper may launch a denial-of-service attack on a 3210 gateway by capturing a Membership Query or Membership Update message 3211 and using the request nonce and message authentication code carried 3212 by the captured message to send a spoofed a Membership Update or 3213 Teardown message to the relay. The spoofed messages may be used to 3214 modify or destroy group membership state associated with the gateway, 3215 thereby changing or interrupting the multicast traffic flows. 3217 A passive eavesdropper may also spoof Multicast Data messages in an 3218 attempt to overload the gateway or disrupt or supplant existing 3219 traffic flows. A properly implemented gateway will filter Multicast 3220 Data messages that do not originate from the expected relay address 3221 and should filter non-multicast packets and multicast IP packets 3222 whose group or source addresses are not included in the current 3223 reception state for the gateway pseudo-interface. 3225 An active eavesdropper may launch a man-in-the-middle attack in which 3226 messages normally exchanged between a gateway and relay are 3227 intercepted, modified, spoofed or discarded by the attacker. The 3228 attacker may deny access to, modify or replace requested multicast 3229 traffic. The AMT protocol provides no means for detecting or 3230 defending against a man-in-the-middle attack - any such functionality 3231 must be provided by multicast receiver applications through 3232 independent detection and validation of incoming multicast datagrams. 3234 The anycast discovery technique for finding relays (see 3235 Section 4.1.4) introduces a risk that a rogue router or a rogue AS 3236 could introduce a bogus route to a specific Relay Discovery Address 3237 prefix, and thus divert or absorb Relay Discovery messages sent by 3238 gateways. Network managers must guarantee the integrity of their 3239 routing to a particular Relay Discovery Address prefix in much the 3240 same way that they guarantee the integrity of all other routes. 3242 6.3. Encapsulated IP Packets 3244 An attacker forging or modifying a Membership Query or Membership 3245 Update message may attempt to embed something other than an IGMP or 3246 MLD message within the encapsulated IP packet carried by these 3247 messages in an effort to introduce these into the recipient's IP 3248 stack. A properly implemented gateway or relay will ignore any such 3249 messages - and may further choose to ignore Membership Query messages 3250 that do not contain a IGMP/MLD general queries or Membership Update 3251 messages that do not contain IGMP/MLD membership reports. 3253 Properly implemented gateways and relays will also filter 3254 encapsulated IP packets that appear corrupted or truncated by 3255 verifying packet length and checksums. 3257 7. IANA Considerations 3259 7.1. IPv4 and IPv6 Anycast Prefix Allocation 3261 IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated to 3262 the public AMT Relays to advertise to the native multicast backbone 3263 (as described in Section 4.1.4). The prefix length should be 3264 determined by the IANA; the prefix should be large enough to 3265 guarantee advertisement in the default-free BGP networks. 3267 7.1.1. IPv4 3269 A prefix length of 24 will meet this requirement. 3271 Internet Systems Consortium (ISC) has offered 154.7.0/24 for this 3272 purpose. 3274 7.1.2. IPv6 3276 A prefix length of 32 will meet this requirement. IANA has 3277 previously set aside the range 2001::/16 for allocating prefixes for 3278 this purpose. 3280 7.2. IPv4 Address Prefix Allocation for IGMP Source Addresses 3282 IANA should allocate an IPv4 prefix dedicated for use in IGMP 3283 messages exchanged between gateways and relays. This address range 3284 is intended for use within tunnels constructed between a gateway and 3285 relay, and as such, is not intended to be globally routable. 3287 A prefix length of 24 will meet this requirement. 3289 Internet Systems Consortium (ISC) has offered 154.7.1/24 for this 3290 purpose. 3292 7.3. UDP Port number 3294 IANA has reserved UDP port number 2268 for AMT. 3296 8. Contributors 3298 The following people provided significant contributions to the design 3299 of the protocol and earlier versions of this specification: 3301 Thomas Morin 3302 France Telecom - Orange 3303 2, avenue Pierre Marzin 3304 Lannion 22300 3305 France 3306 Email: thomas.morin@orange.com 3308 Dirk Ooms 3309 OneSparrow 3310 Belegstraat 13; 2018 Antwerp; 3311 Belgium 3312 EMail: dirk@onesparrow.com 3314 Tom Pusateri 3315 !j 3316 2109 Mountain High Rd. 3317 Wake Forest, NC 27587 3318 USA 3319 Email: pusateri@bangj.com 3321 Dave Thaler 3322 Microsoft Corporation 3323 One Microsoft Way 3324 Redmond, WA 98052-6399 3325 USA 3326 Email: dthaler@microsoft.com 3328 9. Acknowledgments 3330 The authors would like to thank the following individuals for their 3331 suggestions, comments, and corrections: 3333 Amit Aggarwal 3334 Mark Altom 3335 Toerless Eckert 3336 Marshall Eubanks 3337 Gorry Fairhurst 3338 Dino Farinacci 3339 Lenny Giuliano 3340 Andy Huang 3341 Tom Imburgia 3342 Patricia McCrink 3343 Han Nguyen 3344 Doug Nortz 3345 Pekka Savola 3346 Robert Sayko 3347 Greg Shepherd 3348 Steve Simlo 3349 Mohit Talwar 3350 Lorenzo Vicisano 3351 Kurt Windisch 3352 John Zwiebel 3354 The anycast discovery mechanism described in this document is based 3355 on similar work done by the NGTrans WG for obtaining automatic IPv6 3356 connectivity without explicit tunnels ("6to4"). Tony Ballardie 3357 provided helpful discussion that inspired this document. 3359 Juniper Networks was instrumental in funding several versions of this 3360 draft as well as an open source implementation. 3362 10. References 3364 10.1. Normative References 3366 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 3367 August 1980. 3369 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 3370 RFC 792, September 1981. 3372 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 3373 April 1992. 3375 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 3376 Thyagarajan, "Internet Group Management Protocol, Version 3377 3", RFC 3376, October 2002. 3379 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 3380 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 3382 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 3383 Architecture", RFC 4291, February 2006. 3385 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 3386 "Internet Group Management Protocol (IGMP) / Multicast 3387 Listener Discovery (MLD)-Based Multicast Forwarding 3388 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 3390 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 3391 IP", RFC 4607, August 2006. 3393 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 3394 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 3395 RFC 4787, January 2007. 3397 10.2. Informative References 3399 [I-D.ietf-6man-udpchecksums] 3400 Eubanks, M. and P. Chimento, "UDP Checksums for Tunneled 3401 Packets", draft-ietf-6man-udpchecksums-02 (work in 3402 progress), March 2012. 3404 [I-D.ietf-6man-udpzero] 3405 Fairhurst, G. and M. Westerlund, "IPv6 UDP Checksum 3406 Considerations", draft-ietf-6man-udpzero-05 (work in 3407 progress), December 2011. 3409 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 3410 September 1981. 3412 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 3413 RFC 1112, August 1989. 3415 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 3416 Anycasting Service", RFC 1546, November 1993. 3418 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 3419 Hashing for Message Authentication", RFC 2104, 3420 February 1997. 3422 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3423 Requirement Levels", BCP 14, RFC 2119, March 1997. 3425 [RFC2236] Fenner, W., "Internet Group Management Protocol, Version 3426 2", RFC 2236, November 1997. 3428 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 3429 (IPv6) Specification", RFC 2460, December 1998. 3431 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 3432 Translator (NAT) Terminology and Considerations", 3433 RFC 2663, August 1999. 3435 [RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast 3436 Listener Discovery (MLD) for IPv6", RFC 2710, 3437 October 1999. 3439 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 3440 Tunnel Broker", RFC 3053, January 2001. 3442 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 3443 via IPv4 Clouds", RFC 3056, February 2001. 3445 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 3446 RFC 3068, June 2001. 3448 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 3449 Text on Security Considerations", BCP 72, RFC 3552, 3450 July 2003. 3452 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 3453 Independent Multicast - Dense Mode (PIM-DM): Protocol 3454 Specification (Revised)", RFC 3973, January 2005. 3456 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 3457 Message Protocol (ICMPv6) for the Internet Protocol 3458 Version 6 (IPv6) Specification", RFC 4443, March 2006. 3460 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 3461 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 3462 Protocol Specification (Revised)", RFC 4601, August 2006. 3464 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 3465 "Multiprotocol Extensions for BGP-4", RFC 4760, 3466 January 2007. 3468 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 3469 Services", BCP 126, RFC 4786, December 2006. 3471 Appendix A. Implementation Notes 3473 A.1. Response MAC Generation and Keying 3475 This specification does not require relays to use any particular 3476 method to compute the Response MAC field value - only that it contain 3477 a hash of the source IP address, source UDP port, request nonce, and 3478 a private secret known only to the relay. This allows the relay 3479 implementor a significant amount of leeway in the computation and 3480 structure of the value stored in the Response MAC field. 3482 Section Section 5.3.6 states that a relay should periodically compute 3483 a new private secret (or hash-key) for MAC generation. To prevent 3484 the relay from rejecting Membership Update messages that contain 3485 Response MAC values computed from an old secret, the relay is 3486 required to retain the previous secret so that it can re-attempt 3487 authentication using the old secret, should authentication fail after 3488 recomputing the MAC using the new secret. However, this approach 3489 requires a relay to do at least two hash computations for every 3490 Membership Update message that carries an old or a invalid MAC. A 3491 better approach would be to include information within the message 3492 that the relay could use to choose a single secret for authentication 3493 rather relying on sequential authentication failures to test all 3494 possible secrets. 3496 The solution proposed here is to compute and exchange an 3497 "authentication cookie" rather than a simple hash value in the 3498 Response MAC field. The authentication cookie would combine a 3499 timestamp with a hash value. The timestamp is used to calculate the 3500 age of the cookie, allowing the relay to reject a message if the 3501 cookie's age is greater than some maximum allowable value. If the 3502 cookie has not expired, the relay uses the timestamp to lookup the 3503 secret that was in use at that time and then compute and compare the 3504 hash portion of the cookie to authenticate the message source. 3506 A second purpose served by including the timestamp in the MAC field 3507 is that it allows the relay to contribute an unpredictable value to 3508 the authentication hash. This contribution provides a defense 3509 against attempts to use a hash reversal algorithm to determine the 3510 relay's private secret as the hash result will change over time even 3511 if the nonce carried by the Request message does not. 3513 0 1 2 3 3514 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 3515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3516 | V=0 |4 or 5| Reserved | | Response MAC | 3517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 3518 | | 3519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3520 | Request Nonce | 3521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3522 : : 3524 The Opaque Response MAC Field 3526 A relay may use the opaque Response MAC field to store a cookie as 3527 follows: 3529 0 1 2 3 3530 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 3531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3532 | V=0 |4 or 5| Reserved | | Timestamp | 3533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3534 | MD5(Secret,Timestamp,IP_ADDR,IP_PORT,Request-Nonce) | 3535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3536 | Request Nonce | 3537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3538 : : 3540 Using The Response MAC Field To Carry An Authentication Cookie 3542 The timestamp is an unsigned integer measured relative to the start 3543 time of relay. The age of the MAC is computed by subtracting the MAC 3544 timestamp from the current system timestamp. The operands must be 3545 unsigned 16-bit integers and the subtraction must use unsigned 3546 arithmetic to allow for timestamp wrap-around. The timestamp 3547 resolution must provide range sufficient to handle the maximum 3548 allowable age for a MAC, e.g., a resolution of 1 second allows a 3549 maximum age of 18 hours. The timestamp should start at a random 3550 value by adding a random offset, computed at startup, to the current 3551 system time. 3553 +-------------------------+----------------/ /-----------------+ 3554 -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] | 3555 | +-------------------------+----------------/ /-----------------+ 3556 |_____________________________________________________________________ 3557 | 3558 +-------------------------+----------------/ /-----------------+ | 3559 -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |-- 3560 | +-------------------------+----------------/ /-----------------+ 3561 |_____________________________________________________________________ 3562 | 3563 +-------------------------+----------------/ /-----------------+ | 3564 -->| Timestamp(N1) [16-bits] | Random Secret [128-bits] |-- 3565 | +-------------------------+----------------/ /-----------------+ 3566 | 3567 |__ Current 3568 Secret 3570 Private Secret Queue 3572 The timestamp is not only used to compute the age of the MAC, but is 3573 also used to lookup the private secret used to generate the MAC. 3574 Each time a new private secret is computed, the value and the time at 3575 which the value was computed is pushed into a fixed-length queue of 3576 recent values (typically only 2-deep). The relay uses the timestamp 3577 contained in the MAC field to lookup the appropriate secret. The 3578 relay iterates over the list of secrets, starting with the newest 3579 entry, until it finds the first secret with a timestamp that is older 3580 than that contained in the MAC field. The relay then uses that 3581 secret to compute the MAC that will be compared with that carried by 3582 the message. 3584 Author's Address 3586 Gregory Bumgardner 3587 Cisco 3588 3700 Cisco Way 3589 San Jose, CA 95134 3590 USA 3592 Phone: +1 408 853 4993 3593 Email: gbumgard@cisco.com