idnits 2.17.1 draft-ietf-mboned-auto-multicast-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 11, 2011) is 4673 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) == Unused Reference: 'RFC4760' is defined on line 1251, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-6man-udpchecksums-00 -- 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: 0 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft M. Talwar 4 Intended status: Standards Track A. Aggarwal 5 Expires: January 12, 2012 Microsoft Corporation 6 L. Vicisano 7 Qualcomm Inc. 8 T. Pusateri 9 !j 10 T. Morin 11 France Telecom - Orange 12 July 11, 2011 14 Automatic IP Multicast Tunneling 15 draft-ietf-mboned-auto-multicast-11 17 Abstract 19 Automatic IP Multicast Tunneling (AMT) allows multicast reception by 20 isolated multicast-enabled sites or hosts, attached to a network 21 which has no native multicast support. It enables them to receive 22 multicast traffic from the native multicast infrastructure without 23 requiring any manual configuration. AMT uses an encapsulation 24 interface so that no changes to a host stack or applications are 25 required, all protocols (not just UDP) are handled, and there is no 26 additional overhead in core routers. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 12, 2012. 45 Copyright Notice 47 Copyright (c) 2011 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 This document may contain material from IETF Documents or IETF 61 Contributions published or made publicly available before November 62 10, 2008. The person(s) controlling the copyright in some of this 63 material may not have granted the IETF Trust the right to allow 64 modifications of such material outside the IETF Standards Process. 65 Without obtaining an adequate license from the person(s) controlling 66 the copyright in such materials, this document may not be modified 67 outside the IETF Standards Process, and derivative works of it may 68 not be created outside the IETF Standards Process, except to format 69 it for publication as an RFC or to translate it into languages other 70 than English. 72 Table of Contents 74 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 76 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 7 77 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 8 79 4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 8 80 4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 8 81 4.4. AMT Relay . . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.5. AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 9 83 4.6. AMT Relay Anycast Address . . . . . . . . . . . . . . . . 9 84 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 5.1. Scalability Considerations . . . . . . . . . . . . . . . . 11 86 5.2. Spoofing Considerations . . . . . . . . . . . . . . . . . 11 87 5.3. Protocol Sequence . . . . . . . . . . . . . . . . . . . . 12 88 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 15 89 6.1. Use of UDP . . . . . . . . . . . . . . . . . . . . . . . . 15 90 6.2. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 15 91 6.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 6.2.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 15 93 6.2.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 15 94 6.3. AMT Relay Advertisement . . . . . . . . . . . . . . . . . 16 95 6.3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 6.3.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 16 97 6.3.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 16 98 6.3.4. Relay Address . . . . . . . . . . . . . . . . . . . . 16 99 6.4. AMT Request . . . . . . . . . . . . . . . . . . . . . . . 16 100 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17 101 6.4.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 17 102 6.4.3. Request Nonce . . . . . . . . . . . . . . . . . . . . 17 103 6.5. AMT Membership Query . . . . . . . . . . . . . . . . . . . 17 104 6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 18 105 6.5.2. Flags . . . . . . . . . . . . . . . . . . . . . . . . 18 106 6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 19 107 6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 19 108 6.5.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 19 109 6.5.6. Gateway information fields . . . . . . . . . . . . . . 19 110 6.6. AMT Membership Update . . . . . . . . . . . . . . . . . . 19 111 6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20 112 6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20 113 6.6.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20 114 6.6.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 21 115 6.6.5. IGMP/MLD Message (including IP Header) . . . . . . . . 21 116 6.7. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 21 117 6.7.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 22 118 6.7.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22 119 6.7.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 22 121 6.8. AMT Teardown . . . . . . . . . . . . . . . . . . . . . . . 22 122 6.8.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 23 123 6.8.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 23 124 6.8.3. Original Response MAC . . . . . . . . . . . . . . . . 23 125 6.8.4. Original Request Nonce . . . . . . . . . . . . . . . . 23 126 6.8.5. Original Source Port . . . . . . . . . . . . . . . . . 23 127 6.8.6. Original Source Address . . . . . . . . . . . . . . . 23 128 7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 25 129 7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 25 130 7.2. Gateway identification . . . . . . . . . . . . . . . . . . 25 131 7.3. Joining Multicast Groups . . . . . . . . . . . . . . . . . 26 132 7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 26 133 8. AMT Relay Details . . . . . . . . . . . . . . . . . . . . . . 27 134 8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 27 135 8.2. Receiving Relay Discovery messages sent to the Anycast 136 Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 137 8.3. Receiving Membership Updates from AMT Gateways . . . . . . 27 138 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 139 9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 29 140 9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 29 141 9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 29 142 9.2. UDP Port number . . . . . . . . . . . . . . . . . . . . . 29 143 10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 144 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 31 145 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 146 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 147 13.1. Normative References . . . . . . . . . . . . . . . . . . . 33 148 13.2. Informative References . . . . . . . . . . . . . . . . . . 33 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 151 1. Introduction 153 The primary goal of this document is to foster the deployment of 154 native IP multicast by enabling a potentially large number of nodes 155 to connect to the already present multicast infrastructure. 156 Therefore, the techniques discussed here should be viewed as an 157 interim solution to help in the various stages of the transition to a 158 native multicast network. 160 To allow fast deployment, the solution presented here only requires 161 small and concentrated changes to the network infrastructure, and no 162 changes at all to user applications or to the socket API of end- 163 nodes' operating systems. The protocol introduced in this 164 specification can be deployed in a few strategically-placed network 165 nodes and in user-installable software modules (pseudo device drivers 166 and/or user-mode daemons) that reside underneath the socket API of 167 end-nodes' operating systems. This mechanism is very similar to that 168 used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6 169 connectivity. 171 Effectively, AMT treats the unicast-only inter-network as a large 172 non-broadcast multi-access (NBMA) link layer, over which we require 173 the ability to multicast. To do this, multicast packets being sent 174 to site must be encapsulated in unicast packets. If the group has 175 members in multiple sites, AMT encapsulation of the same multicast 176 packet will take place multiple times by necessity. 178 A previous of this solution was previously "Automatic IP Multicast 179 without explicit Tunnels", to highlight the fact that the tunneling 180 used is lightweight and does not require statically configured 181 tunnels used as point to point interfaces. 183 2. Applicability 185 AMT is not a substitute for native multicast or a statically 186 configured multicast tunnel for high traffic flow. Unicast 187 replication is required to reach multiple receivers that are not part 188 of the native multicast infrastructure. However, this is no worse 189 than regular unicast distribution of streams and in most cases much 190 better. 192 This document specifies procedures allowing isolated sites to receive 193 both general Any Source Multicast (ASM, [RFC1112]), and Specific 194 Source Multicast (SSM, [RFC4607]). 196 Earlier versions of this document were describing how to use AMT to 197 allow isolated non-NAT sites/hosts to transmit SSM multicast ; the 198 specifications for these functionalities have been left off the 199 current document for the following reasons: the drawback that these 200 specifications required a source site Gateway to replicate traffic to 201 many Relays in the multicast-enabled part of the network, lack of 202 contributors to document alternative proposals based on AMT, 203 existence of ways to offer similar functionality using Tunnel Broker 204 approaches [RFC3053], or at the application layer. 206 Implementers should be aware that site administrators may have 207 configured administratively scoped multicast boundaries and a remote 208 gateway may provide a means to circumvent administrative boundaries. 209 Therefore, implementations should allow for the configuration of such 210 boundaries on relays and gateways and perform filtering as needed. 212 3. Requirements notation 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in [RFC2119]. 218 4. Definitions 220 +---------------+ Internet +---------------+ 221 | AMT Site | | Native MCast | 222 | | | | 223 | +------+----+ AMT +----+----+ | 224 | |AMT Gateway| Anycast |AMT Relay| | 225 | | +-----+-+ Prefix +-+-----+ | | 226 | | |AMT IF | <------------|AMT IF | | | 227 | | +-----+-+ +-+-----+ | | 228 | +------+----+ +----+----+ | 229 | | | | 230 +---------------+ +---------------+ 232 4.1. AMT Pseudo-Interface 234 AMT encapsulation of multicast packets inside unicast packets occurs 235 at a point that is logically equivalent to an interface, with the 236 link layer being the unicast-only network. This point is referred to 237 as a pseudo-interface. Some implementations may treat it exactly 238 like any other interface and others may treat it like a tunnel end- 239 point. 241 4.2. AMT Gateway 243 A host, or a site gateway router, supporting an AMT Pseudo-Interface. 244 It does not have native multicast connectivity to the native 245 multicast backbone infrastructure. It is simply referred to in this 246 document as a "gateway". 248 4.3. AMT Site 250 A multicast-enabled network not connected to the multicast backbone 251 served by an AMT Gateway. It could also be a stand-alone AMT 252 Gateway. 254 4.4. AMT Relay 256 A multicast router configured to support transit routing between AMT 257 Sites and the native multicast backbone infrastructure. The relay 258 router has one or more interfaces connected to the native multicast 259 infrastructure, zero or more interfaces connected to the non- 260 multicast capable inter-network, and an AMT pseudo-interface. It is 261 simply referred to in this document as a "relay". 263 As with [RFC3056], we assume that normal multicast routers do not 264 want to be tunnel endpoints (especially if this results in high fan 265 out). Instead, we assume that special-purpose routers will be 266 deployed that are suitable for serving as relays. 268 4.5. AMT Relay Anycast Prefix 270 A well-known address prefix used to advertise (into the unicast 271 routing infrastructure) a route to an available AMT Relay Router. 272 This could also be private (i.e., not well-known) for a private 273 relay. 275 Prefixes for both IPv4 and IPv6 will be assigned in a future version 276 of this draft. 278 4.6. AMT Relay Anycast Address 280 An anycast address which is used to reach the nearest AMT Relay 281 Router. 283 This address corresponds to the setting the low-order octet of the 284 AMT Relay Anycast Prefix to 1 (for both IPv4 and IPv6). 286 5. Overview 288 Internet 289 +---------------+ +---------------+ 290 | AMT Site | 2. 3-way Membership | Native MCast | 291 | | Handshake | | 292 | 1. Join +---+---+ =================> +---+---+ | 293 | +---->|Gateway| | Relay | | 294 | | +---+---+ <================= +---+---+ | 295 | R-+ | 3. Receive Data | | 296 +---------------+ +---------------+ 298 Receiving Multicast in an AMT Site 300 AMT relays and gateways cooperate to transmit multicast traffic 301 sourced within the native multicast infrastructure to AMT sites: 302 relays receive the traffic natively and unicast-encapsulate it to 303 gateways; gateways decapsulate the traffic and possibly forward it 304 into the AMT site. 306 Each gateway has an AMT pseudo-interface that serves as a default 307 multicast route. Requests to join a multicast session are sent to 308 this interface and encapsulated to a particular relay reachable 309 across the unicast-only infrastructure. 311 Each relay has an AMT pseudo-interface too. Multicast traffic sent 312 on this interface is encapsulated to zero or more gateways that have 313 joined to the relay. The AMT recipient-list is determined for each 314 multicast session. This requires the relay to keep state for each 315 gateway which has joined a particular group or (source, group) pair. 316 Multicast packets from the native infrastructure behind the relay 317 will be sent to each gateway which has requested them. 319 All multicast packets (data and control) are encapsulated in unicast 320 packets. UDP encapsulation is used for all AMT control and data 321 packets using the IANA reserved UDP port number for AMT. 323 Each relay, plus the set of all gateways using the relay, together 324 are thought of as being on a separate logical NBMA link. This 325 implies that the AMT recipient-list is a list of "link layer" 326 addresses which are (IP address, UDP port) pairs. 328 Since the number of gateways using a relay can be quite large, and we 329 expect that most sites will not want to receive most groups, an 330 explicit-joining protocol is required for gateways to communicate 331 group membership information to a relay. The two most likely 332 candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the 333 PIM-Sparse Mode protocol [RFC4601]. Since an AMT gateway may be a 334 host, and hosts typically do not implement routing protocols, 335 gateways will use IGMP/MLD as described in Section 7 below. This 336 allows a host kernel (or a pseudo device driver) to easily implement 337 AMT gateway behavior, and obviates the relay from the need to know 338 whether a given gateway is a host or a router. From the relay's 339 perspective, all gateways are indistinguishable from hosts on an NBMA 340 leaf network. 342 5.1. Scalability Considerations 344 It is possible that millions of hosts will enable AMT gateway 345 functionality and so an important design goal is not to create 346 gateway state in each relay until the gateway joins a multicast 347 group. But even the requirement that a relay keep group state per 348 gateway that has joined a group introduces potential scalability 349 concerns. 351 Scalability of AMT can be achieved by adding more relays, and using 352 an appropriate relay discovery mechanism for gateways to discover 353 relays. The solution we adopt is to assign addresses in anycast 354 fashion to relays [RFC1546], [RFC4291]. However, simply sending 355 periodic membership reports to an anycast address can cause 356 duplicates. Specifically, if routing changes such that a different 357 relay receives a periodic membership report, both the new and old 358 relays will encapsulate data to the AMT site until the old relay's 359 state times out. This is obviously undesirable. Instead, we use the 360 anycast address merely to find the unicast address of a relay to 361 which membership reports are sent. 363 This approach allows the gateways to be spread out among more relays 364 so as to keep the number of gateways per relay at a reasonable level. 366 5.2. Spoofing Considerations 368 An attacker could affect the group state in the relay by spoofing the 369 source address in AMT Update messages containing join or leave 370 reports. This can be used to launch reflection or denial of service 371 attacks on the target Relay. Such attacks can be mitigated by using 372 a three way handshake between the gateway and the relay for each 373 multicast membership report or leave. 375 When a gateway wants to send a membership report, it first sends an 376 AMT Request with a request nonce in it. The Relay can calculate a 377 message authentication code (MAC) based on (for example)the source IP 378 address of the Request, the source UDP port, the request nonce, and a 379 secret key known only to the Relay. The algorithm does not have to 380 be standardized since the Relay generates and verifies the MAC and 381 the Gateway simply echoes it back, but an algorithm such as 382 HMAC-MD5-48 [RFC2104] SHOULD be used at a minimum. 384 An AMT Membership Query is sent back to the gateway having originated 385 the Request, including the request nonce and the MAC. The gateway 386 then sends the IGMP/MLD Membership/Listener Report or Leave/Done 387 (including the IP Header) along with the request nonce and the 388 received MAC back to the relay, finalizing the 3-way handshake. 390 Upon reception, the relay can recalculate the MAC based on the source 391 IP address, the source UDP port, the request nonce, and the local 392 secret. The IGMP/MLD message is only accepted if the received MAC 393 matches the calculated MAC. 395 A relay MUST NOT create state for a gateway before successful 396 validation of a MAC of an AMT Update from this gateway; a relay 397 SHOULD delete all states for a gateway after a small timer after it 398 stops having any AMT forwarding state for a Gateway (i.e. the Gateway 399 left all multicast groups it had joined). 401 The local secret never has to be shared with the other side. It is 402 only used to verify return routability of the originator. 404 Since the same Request Nonce and source IP address can be re-used, 405 the relay SHOULD change its secret key at least once per hour. 406 However, AMT Membership updates received with the previous secret 407 MUST be accepted for up to the IGMP/MLD Query Interval. 409 The condition might occur where the gateway that initially sent the 410 AMT Request dynamically changes its IP address. This might occur due 411 to a change in wireless networks, a DHCP assignment, or another 412 network failure. When this occurs, it is no longer possible to 413 verify the MAC using the source address and source port. Though, in 414 order to reduce state, it is desirable to tear down the state that 415 was created with the old source address. A Teardown message with 416 special considerations for calculating the MAC is described below to 417 perform this function. 419 5.3. Protocol Sequence 421 This description assumes the Gateway can be a host joining as a 422 receiver or a network device acting as a Gateway when a directly 423 connected host joins as a receiver. 425 Protocol sequence for a multicast SSM channel (S1,G1): 427 o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1). 429 o Gateway receives report. If it has no tunnel state with a Relay, 430 it originates an AMT Relay Discovery message addressed to the 431 Anycast Relay IP address. The AMT Relay Discovery message can be 432 sent on demand if no relay is known at this time or at startup and 433 be periodically refreshed. 435 o The closest Relay topologically receives the AMT Relay Discovery 436 message and returns the nonce from the Discovery in an AMT Relay 437 Advertisement message so the Gateway can learn of the Relay's 438 unique IP address. 440 o When the Gateway receives the AMT Relay Advertisement message, it 441 now has an address to use for all subsequent (S,G) entries it will 442 join on behalf of attached receivers (or itself). 444 o If the gateway has a valid Response MAC from a previous AMT Query 445 message, it can send an AMT Membership Update message as described 446 below. Otherwise, the Gateway sends an AMT Request message to the 447 Relay's unique IP address to begin the process of joining the 448 (S,G). The gateway also SHOULD initialize a timer used to send 449 periodic Requests to a random value from the interval [0, [Query 450 Interval]] before sending the first periodic report, in order to 451 prevent startup synchronization. 453 o The Relay responds to the AMT Request message by returning the 454 nonce from the Request in a AMT Query message. The Query message 455 contains an IGMP/MLD QUERY indicating how often the Gateway should 456 repeat AMT Request messages so the (S,G) state can stay refreshed 457 in the Relay. The Query message also includes an opaque security 458 code which is generated locally (with no external coordination). 460 o When the Gateway receives the AMT Query message it responds by 461 copying the security code from the AMT Query message into a AMT 462 Membership Update message. The Update message contains (S1,G1) in 463 an IGMPv3/MLDv2 formatted packet with an IP header. The nonce 464 from the AMT Request is also included in the AMT Membership Update 465 message. 467 o When the Relay receives the AMT Membership Update, it will add the 468 tunnel to the Gateway in it's outgoing interface list for it's 469 (S1,G1) entry stored in the multicast routing table. If the 470 (S1,G1) entry was created do to this interaction, the multicast 471 routing protocol running on the Relay will trigger a Join message 472 towards source S1 to build a native multicast tree in the native 473 multicast infrastructure. 475 o As packets are sent from the host S1, they will travel natively 476 down the multicast tree associated with (S1,G1) in the native 477 multicast infrastructure to the Relay. The Relay will replicate 478 to all interfaces in it's outgoing interface list as well as the 479 tunnel outgoing interface, which is encapsulated in a unicast AMT 480 Multicast Data message. 482 o When the Gateway receives the AMT Multicast Data message, it will 483 accept the packet since it was received over the pseudo-interface 484 associated with the tunnel to the Relay it had attached to, and 485 forward the packet to the outgoing interfaces joined by any 486 attached receiver hosts (or deliver the packet to the application 487 when the Gateway is the receiver). 489 o If later (S2,G2) is joined by a receiver, a 3-way handshake of 490 Request/ Query/Update occurs for this entry. The Discovery/ 491 Advertisement exchange is not required. 493 o To keep the state for (S1,G1) and (S2,G2) alive in the Relay, the 494 Gateway will send periodic AMT Membership Updates. The Membership 495 Update can be sent directly if the sender has a valid nonce from a 496 previous Request. If not, an AMT Request messages should be sent 497 to solicit a Query Message. When sending a periodic state 498 refresh, all joined state in the Gateway is packed in the fewest 499 number of AMT Membership Update messages. 501 o When the Gateway leaves all (S,G) entries, the Relay can free 502 resources associated with the tunnel. It is assumed that when the 503 Gateway would want to join an (S,G) again, it would start the 504 Discovery/Advertisement tunnel establishment process over again. 506 This same procedure would be used for receivers who operate in Any- 507 Source Multicast (ASM) mode. 509 6. Message Formats 511 6.1. Use of UDP 513 All AMT messages are UDP packets. 515 Messages sent to the Relay are sent to the IANA reserved AMT port 516 number (Section 9), from a source port uniquely selected by the host 517 operating system of the Gateway. Messages sent by the Relay are sent 518 from the IANA reserved AMT port number. 520 The UDP checksum MUST be valid in all AMT control messages (Relay 521 Discovery, Relay Advertisement, Membership Request, Membership Query, 522 Membership Update). Section 6.7 specifies the behavior with 523 reference to the UDP checksums of AMT IP Multicast Data messages. 525 6.2. AMT Relay Discovery 527 The AMT Relay Discovery message is sent from the AMT gateway unicast 528 address to the AMT Relay Anycast address to discover the unicast 529 address of an AMT relay. 531 The payload of the UDP packet contains the following fields. 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Type=0x1 | Reserved | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Discovery Nonce | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 AMT Relay Discovery 543 6.2.1. Type 545 The type of the message. 547 6.2.2. Reserved 549 A 24-bit reserved field. Sent as 0, ignored on receipt. 551 6.2.3. Discovery Nonce 553 A 32-bit random value generated by the gateway and replayed by the 554 relay. 556 6.3. AMT Relay Advertisement 558 The AMT Relay Advertisement message sent from the AMT relay anycast 559 address to the source of the discovery message. 561 The UDP source port is the IANA reserved AMT port number and the UDP 562 destination port is the source port received in the Discovery 563 message. 565 The payload of the UDP packet contains the following fields. 567 0 1 2 3 568 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 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 | Type=0x2 | Reserved | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 572 | Discovery Nonce | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Relay Address | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 AMT Relay Advertisement 579 6.3.1. Type 581 The type of the message. 583 6.3.2. Reserved 585 A 24-bit reserved field. Sent as 0, ignored on receipt. 587 6.3.3. Discovery Nonce 589 A 32-bit random value generated by the gateway and replayed by the 590 relay. 592 6.3.4. Relay Address 594 The unicast IPv4 or IPv6 address of the AMT relay. The family can be 595 determined by the length of the Advertisement. 597 6.4. AMT Request 599 A Request packet is sent by a Gateway to a Relay to begin a 3-way 600 handshake for sending an IGMP/MLD Membership/Listener Report or 601 Leave/Done. 603 It is sent from the Gateway address to the Relay's unique unicast 604 address. 606 The UDP source port is uniquely selected by the local host operating 607 system. It can be different from the source port used in Discovery 608 messages but does not have to be. The UDP source port must be 609 consistent across Request and Update messages (see also Section 7.2). 611 The UDP destination port is the IANA reserved AMT port number. 613 0 1 2 3 614 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 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 616 | Type=0x3 | Reserved | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Request Nonce | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 AMT Request 623 6.4.1. Type 625 The type of the message. 627 6.4.2. Reserved 629 A 24-bit reserved field. Sent as 0, ignored on receipt. 631 6.4.3. Request Nonce 633 A 32-bit identifier used to distinguish this request. 635 6.5. AMT Membership Query 637 An AMT Membership Query packet is sent from the Relay back to the 638 Gateway to solicit an AMT Membership Update while confirming the 639 source of the original request. It contains a relay Message 640 Authentication Code (MAC) that is a cryptographic hash of a private 641 secret, the originators address, and the request nonce. 643 It is sent from the destination address received in the Request to 644 the source address of the Request, i.e. the Relay Address advertised 645 in the Relay Advertisement message. 647 The UDP source port is the IANA reserved AMT port number and the UDP 648 destination port is the source port received in the Request message. 650 0 1 2 3 651 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 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | Type=0x4 | Flags | Response MAC | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Response MAC (continued) | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Request Nonce | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | IGMP Membership Query or MLD Listener Query | 660 | (including IP Header) | 661 | ... | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Gateway Port Number | Gateway Address ... | ? 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ? 665 | ... Gateway Address (ctd) ... | ? 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ? 667 | ... Gateway Address (ctd) ... | ? 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ? 669 | ... Gateway Address (ctd) ... | ? 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ? 671 | ... Gateway Address (ctd) | ? 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 AMT Membership Query 676 6.5.1. Type 678 The type of the message. 680 6.5.2. Flags 682 An 8-bit flags field having the following format: 683 0 1 2 3 4 5 6 7 684 +-+-+-+-+-+-+-+-+ 685 | Reserved |G| 686 +-+-+-+-+-+-+-+-+ 688 The "G" flag is set to 1 if Gateway information fields are present in 689 the Query message (see below Section 6.5.6), and to zero if they are 690 not. 692 Other flags are currently unused and reserved: they are sent as zero 693 and their value is ignored on receipt. 695 6.5.3. Response MAC 697 A 48-bit hash generated by the Relay and sent to the Gateway for 698 inclusion in the AMT Membership Update (see Section 5.2). 700 6.5.4. Request Nonce 702 A 32-bit identifier echoed back to the originator to used to identify 703 the corresponding request (see Section 5.2). 705 6.5.5. IGMP/MLD Query (including IP Header) 707 The message contains either an IGMP Query or an MLD Multicast 708 Listener Query. The IGMP or MLD version sent should default to 709 IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1. 710 The IGMP/MLD Query includes a full IP Header. The IP source address 711 of the query would match the anycast address on the pseudo interface. 712 The TTL of the outer IP header should be sufficient to reach the 713 tunnel endpoint and not mimic the inner IP header TTL which is 714 typically 1 for IGMP/MLD messages. 716 6.5.6. Gateway information fields 718 The "Gateway Port Number" and "Gateway Address" fields are present in 719 the Query message if, and only if, the "G" flag is set in the Flags 720 field. 722 6.5.6.1. Gateway Port Number 724 A 16-bit field containing a UDP port value. 726 The Relay sets this field to the value of the UDP source port of the 727 Request message that triggered the Query message. 729 6.5.6.2. Gateway Address 731 A 16-byte field containing the IP source address of the Request 732 message that triggered this Query message. The field contains an 733 IPv4-compatible IPv6 address ([RFC4291], section 2.5.5.1) if the 734 address is an IPv4 address (i.e. the IPv4 address prefixed with 96 735 bits set to zero), or an IPv6 address. 737 6.6. AMT Membership Update 739 An AMT Membership Update is sent to report a membership after a valid 740 Response MAC has been received. It contains the original IGMP/MLD 741 Membership/Listener Report or Leave/Done received over the AMT 742 pseudo-interface including the original IP header. It echoes the 743 Response MAC received in the AMT Membership Query so the respondent 744 can verify return routability to the originator. 746 It is sent from the destination address received in the Query to the 747 source address received in the Query which should both be the same as 748 the original Request. 750 The UDP source and destination port numbers should be the same ones 751 sent in the original Request. 753 The UDP destination port is the IANA reserved AMT port number and the 754 UDP source port is the source port used for the Request message. 756 The Relay is not required to use the IP source address of the IGMP 757 Membership Report for any particular purpose. 759 The same Request Nonce and Response MAC can be used across multiple 760 AMT Membership Update messages without having to send individual AMT 761 Membership Query messages. 763 0 1 2 3 764 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 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Type=0x5 | Reserved | Response MAC | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Response MAC (continued) | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Request Nonce | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | IGMP or MLD Message (including IP header) | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | ... | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 AMT Membership Update 779 6.6.1. Type 781 The type of the message. 783 6.6.2. Reserved 785 A 8-bit reserved field. Sent as 0, ignored on receipt. 787 6.6.3. Response MAC 789 The 48-bit MAC received in the Membership Query and echoed back in 790 the Membership Update (see Section 5.2). 792 6.6.4. Request Nonce 794 A 32-bit identifier matching the nonce in the AMT Request (see 795 Section 5.2). 797 6.6.5. IGMP/MLD Message (including IP Header) 799 The message contains either an IGMP Membership Report, an IGMP 800 Membership Leave, an MLD Multicast Listener Report, or an MLD 801 Listener Done. The IGMP or MLD version sent should be in function of 802 the version of the query received in the AMT Membership Query. The 803 IGMP/MLD Message includes a full IP Header. 805 6.7. AMT IP Multicast Data 807 The AMT Data message is a UDP packet encapsulating the IP Multicast 808 data requested by the originator based on a previous AMT Membership 809 Update message. 811 It is sent from the Relay's unique unicast address (destination 812 address of the Membership update) to the Gateway's unicast address 813 (source address of the Membership Update). 815 The UDP source port is the IANA reserved AMT port number and the 816 destination port should be the same as the source port of the 817 Membership Update that resulted in the creation of forwarding state 818 for the encapsulated IP packet. 820 The UDP checksum SHOULD be zero for AMT IP Multicast Data messages 821 carried over IPv4, and MAY be zero for AMT IP Multicast Data messages 822 carried over IPv6 [I-D.ietf-6man-udpchecksums]. 824 The payload of the UDP packet contains the following fields. 826 0 1 2 3 827 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 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 | Type=0x6 | Reserved | IP Multicast Data ... | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | ... | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 834 AMT IP Multicast Data 836 6.7.1. Type 838 The type of the message. 840 6.7.2. Reserved 842 An 8-bit reserved field. Sent as 0, ignored on receipt. 844 6.7.3. IP Multicast Data 846 The original IP Multicast data packet that is being replicated by the 847 Relay to the Gateway, including the original IP header. 849 6.8. AMT Teardown 851 An AMT Teardown is sent by a Gateway after a valid Response MAC has 852 been received and after the source address that was used to generate 853 the Response MAC is no longer available for sending packets. 855 It is sent to the source address received in the original Query which 856 should be the same as the original Request. 858 The UDP destination port number should be the same one sent in the 859 original Request. 861 An AMT Teardown from the original source address and source port is 862 NOT valid and should be discarded if received. Use an AMT Membership 863 Update instead. 865 In order for the Relay to verify the Teardown message, this message 866 must contain the original source address and source port in addition 867 to the Original Request Nonce and Original Response MAC. In 868 situations where NAT is used, this information can be known by the 869 Gateway thanks to the optional Gateway information fields in the 870 Query message (Section 6.5.6). Hence, a Relay supporting the 871 Teardown mechanism SHOULD include the Gateway information fields in 872 the Query messages it sends. 874 On reception of a valid Teardown message, a Relay should remove all 875 state corresponding to the gateway identified by the (original source 876 address, original source port) tuple, and stop forwarding all traffic 877 to this destination. 879 0 1 2 3 880 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 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Type=0x7 | Reserved | Original Response MAC | 883 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 884 | Original Response MAC (continued) | 885 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 | Original Request Nonce | 887 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 888 | Original Source Port | Original Source Address ... | 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Original Source Address (ctd) ... | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 892 | ... Original Source Address (ctd) ... | 893 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 894 | ... Original Source Address (ctd) ... | 895 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 896 | ... Original Src Addr. (ctd) | 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 AMT Membership Teardown 901 6.8.1. Type 903 The type of the message. 905 6.8.2. Reserved 907 A 8-bit reserved field. Sent as 0, ignored on receipt. 909 6.8.3. Original Response MAC 911 The 48-bit MAC received in the Membership Query. 913 6.8.4. Original Request Nonce 915 A 32-bit identifier corresponding to the original Request. 917 6.8.5. Original Source Port 919 The 16-bit port number used in the original AMT Request message that 920 was used to generate the Original Response MAC. 922 6.8.6. Original Source Address 924 A 16-byte field containing the IP source address used in the original 925 AMT Request message that was used to generate the Original Response 926 MAC of the Request message that triggered this Query message. The 927 field contains an IPv4-compatible IPv6 address ([RFC4291], section 928 2.5.5.1) if the address is an IPv4 address (i.e. the IPv4 address 929 prefixed with 96 bits set to zero), or an IPv6 address. 931 7. AMT Gateway Details 933 This section details the behavior of an AMT Gateway, which may be a 934 router serving an AMT site, or the site may consist of a single host, 935 serving as its own gateway. 937 7.1. At Startup Time 939 At startup time, the AMT gateway will bring up an AMT pseudo- 940 interface to be used for encapsulation. The gateway needs to 941 discover an AMT Relay to send Membership Requests. It can send an 942 AMT Relay Discovery at startup time or wait until it has a group 943 membership to report. The AMT Relay Discovery message is sent to the 944 AMT Relay Anycast Address. A unicast address (which is treated as a 945 link-layer address to the encapsulation interface) is received in the 946 AMT Relay Advertisement message. The discovery process SHOULD be 947 done periodically (e.g., once a day) to re-resolve the unicast 948 address of a close relay. To prevent startup synchronization, the 949 timer SHOULD use at least 10 percent jitter. 951 If the gateway is serving as a local router, it SHOULD also function 952 as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD 953 host-mode interface being the AMT pseudo-interface. This enables it 954 to translate group memberships on its downstream interfaces into 955 IGMP/MLD Reports. Hosts receiving multicast packets through an AMT 956 gateway acting as a proxy should ensure that their M-RIB accepts 957 multicast packets from the AMT gateway for the sources it is joining. 959 7.2. Gateway identification 961 From the point of view of a Relay, a Gateway is identified by the (IP 962 source address, UDP source port) tuple in Membership Update messages. 963 If an implementation of Gateway procedure was to use a different UDP 964 source port and/or IP source address to join or leave different 965 multicast groups, it would appear to the Relay as distinct Gateways. 967 For instance, a Relay having forwarding state resulting in the 968 forwarding of (S,G) to a said gateway identified by a (IP source 969 address, UDP source port) tuple, will not remove this state if it 970 receives an AMT Membership Update message from a different (IP source 971 address, UDP source port) tuple. 973 It results that a Gateway has to use the same UDP source port for AMT 974 Request and AMT Update messages related to a same (S,G). A said 975 Gateway instance is typically expected to use the same UDP source 976 port and IP source address for all Request and Updates messages for 977 all multicast groups. 979 7.3. Joining Multicast Groups 981 The IGMP/MLD protocol usually operates by having the Querier 982 multicast an IGMP/MLD Query message on the link. This behavior does 983 not work on NBMA links which do not support multicast. Since the set 984 of gateways is typically unknown to the relay (and potentially quite 985 large), unicasting the queries is also impractical. The following 986 behavior is used instead. 988 Applications residing in a gateway should join groups on the AMT 989 pseudo-interface, causing IGMP/MLD Membership/Listener Reports to be 990 sent over that interface. When UDP encapsulating the membership 991 reports (and in fact any other messages, unless specified otherwise 992 in this document), the destination address in the outer IP header is 993 the relay's unicast address. Robustness is provided by the 994 underlying IGMP/MLD protocol messages sent on the AMT pseudo- 995 interface. In other words, the gateway does not need to retransmit 996 IGMP/MLD Membership/Listener Reports and Leave/Done messages received 997 on the pseudo-interface since IGMP/MLD will already do this. The 998 gateway simply needs to encapsulate each IGMP/MLD Membership/Listener 999 Report and Leave/Done message it receives. 1001 However, since periodic IGMP/MLD Membership/Listener Reports are sent 1002 in response to IGMP/MLD Queries, a mechanism to trigger periodic 1003 Membership/Listener Reports and Leave/Done messages is necessary. 1004 The gateway should use a timer to trigger periodic AMT Membership 1005 Updates. 1007 If the gateway is behind a firewall device, the firewall may require 1008 the gateway to periodically refresh the UDP state in the firewall at 1009 a shorter interval than the standard IGMP/MLD Query interval. AMT 1010 Requests can be sent periodically to solicit IGMP/MLD Queries. The 1011 interval at which the AMT Requests are sent should be configurable to 1012 ensure the firewall does not revert to blocking the UDP encapsulated 1013 IP Multicast data packets. When the AMT Query is received, it can be 1014 ignored unless it is time for a periodic AMT Membership Update. 1016 The relay can use the Querier's Robustness Variable (QRV) defined in 1017 [RFC3376] and [RFC3810] to adjust the number of Membership/Listener 1018 Reports that are sent by the host joining the group. 1020 7.4. Responding to Relay Changes 1022 When a gateway determines that its current relay is unreachable 1023 (e.g., upon receipt of an ICMP Unreachable message [RFC0792] for the 1024 relay's unicast address), it may need to repeat relay address 1025 discovery. However, care should be taken not to abandon the current 1026 relay too quickly due to transient network conditions. 1028 8. AMT Relay Details 1030 8.1. At Startup time 1032 At startup time, the relay router will bring up an NBMA-style AMT 1033 pseudo-interface. It shall also add the AMT Relay Anycast Address on 1034 some interface. 1036 The relay router shall then advertise the AMT Relay Anycast Prefix 1037 into the unicast-only Internet, as if it were a connection to an 1038 external network. When the advertisement is done using BGP, the AS 1039 path leading to the AMT Relay Anycast Prefix shall include the 1040 identifier of the local AS. 1042 The relay router shall also enable IGMPv3/MLDv2 on the AMT pseudo- 1043 interface, except that it shall not multicast Queries (this might be 1044 done, for example, by having the AMT pseudo-device drop them, or by 1045 having the IGMP/MLD module not send them in the first place). 1047 8.2. Receiving Relay Discovery messages sent to the Anycast Address 1049 When a relay receives an AMT Relay Discovery message directed to the 1050 AMT Relay Anycast Address, it should respond with an AMT Relay 1051 Advertisement containing its unicast address. The source and 1052 destination addresses of the advertisement should be the same as the 1053 destination and source addresses of the discovery message 1054 respectively. Further, the nonce in the discovery message MUST be 1055 copied into the advertisement message. 1057 8.3. Receiving Membership Updates from AMT Gateways 1059 The relay operates passively, sending no periodic IGMP/MLD Queries 1060 but simply tracking membership information according to AMT Request/ 1061 Query/Membership Update tuples received. As noted in Section 7.2, 1062 the Relay tracks Gateways based on the (IP source address, UDP source 1063 port) tuple. In addition, the relay must also do explicit membership 1064 tracking, as to which gateways on the AMT pseudo-interface have 1065 joined which groups. Once an AMT Membership Update has been 1066 successfully received, it updates the forwarding state for the 1067 appropriate group and source (if provided). When data arrives for 1068 that group, the traffic must be encapsulated, once to each (address, 1069 port) of each gateway which has joined that group or (S,G). 1071 The explicit membership tracking and unicast replication may be done 1072 in any implementation-specific manner. Some examples are: 1074 1. The AMT pseudo-device driver might track the group information 1075 and perform the replication at the "link-layer", with no changes 1076 to a pre-existing IGMP/MLD module. 1078 2. The IGMP/MLD module might have native support for explicit 1079 membership tracking, especially if it supports other NBMA-style 1080 interfaces. 1082 If a relay wants to affect the rate at which the AMT Requests are 1083 originated from a gateway, it can tune the membership timeout by 1084 adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/ 1085 MLD Query contained within the AMT Membership Query message. The 1086 QQIC field is defined in [RFC3376] and [RFC3810]. However, since the 1087 gateway may need to send AMT Requests frequently enough to prevent 1088 firewall state from timing out, the relay may be limited in its 1089 ability to spread out Requests coming from a gateway by adjusting the 1090 QQIC field. 1092 9. IANA Considerations 1094 9.1. IPv4 and IPv6 Anycast Prefix Allocation 1096 The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated 1097 to the public AMT Relays to advertise to the native multicast 1098 backbone. The prefix length should be determined by the IANA; the 1099 prefix should be large enough to guarantee advertisement in the 1100 default-free BGP networks. 1102 9.1.1. IPv4 1104 A prefix length of 16 will meet this requirement. 1106 9.1.2. IPv6 1108 A prefix length of 32 will meet this requirement. IANA has 1109 previously set aside the range 2001::/16 for allocating prefixes for 1110 this purpose. 1112 9.2. UDP Port number 1114 IANA has previously allocated UDP reserved port number 2268 for AMT 1115 encapsulation. 1117 10. Security Considerations 1119 The anycast technique introduces a risk that a rogue router or a 1120 rogue AS could introduce a bogus route to the AMT Relay Anycast 1121 prefix, and thus divert the traffic. Network managers have to 1122 guarantee the integrity of their routing to the AMT Relay Anycast 1123 prefix in much the same way that they guarantee the integrity of all 1124 other routes. 1126 Gateways will accept and decapsulate multicast traffic from any 1127 source from which regular unicast traffic is accepted. If this is, 1128 for any reason, felt to be a security risk, then additional source 1129 address based packet filtering MUST be applied: a gateway MUST 1130 discard encapsulated multicast packets if the source address in the 1131 outer header is not the address of the Relay to which the 1132 encapsulated join message was sent. AMT Gateways MUST also drop non- 1133 multicast traffic incoming on an AMT pseudo-interface. 1135 AMT Relays MUST NOT process AMT Data messages. 1137 AMT Relays and Gateways MUST drop IP messages encapsulated in AMT 1138 Query and Update messages that are not IGMP/MLD messages. 1140 Even though a Relay does not need to maintain any state before 1141 completion of the three-way handshake (Section 5.2), if no mitigation 1142 is in place, it is still possible for one host to instantiate a large 1143 amount of Gateways instances that would each join one or more 1144 multicast groups to a Relay, thus resulting in a large amount of 1145 resources being used on the Relay. Thus, AMT Relays MUST be 1146 implemented so as to allow the mitigation of risks of denial of 1147 service attacks on their resources. A Relay SHOULD NOT allow the 1148 instantiation of an unbounded number of AMT pseudo-interfaces for a 1149 said gateway IP address. For instance, an implementation may provide 1150 a way to set a configurable limit on the maximum number of pseudo- 1151 interfaces to a same gateway IP address, with a default value for 1152 this limit being low enough to provide protection, and high enough to 1153 cope with the possibility of an address being shared by multiple 1154 devices. 1156 In the case where a Relay is reaching the situation where it would 1157 stop accepting to instantiate new pseudo-interfaces, it MAY stop 1158 advertising the AMT Relay Anycast address; thanks to the AMT 1159 discovery procedures, this will allow legitimate AMT Gateways to fall 1160 back on another Relay. 1162 11. Contributors 1164 The following people provided significant contributions to earlier 1165 versions of these specifications: 1167 Dirk Ooms 1168 OneSparrow 1169 Belegstraat 13; 2018 Antwerp; Belgium 1170 EMail: dirk@onesparrow.com 1172 12. Acknowledgments 1174 Most of the mechanisms described in this document are based on 1175 similar work done by the NGTrans WG for obtaining automatic IPv6 1176 connectivity without explicit tunnels ("6to4"). Tony Ballardie 1177 provided helpful discussion that inspired this document. 1179 In addition, extensive comments were received from Pekka Savola, Greg 1180 Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John 1181 Zwiebel, Lenny Giuliano and Greg Bumgardner. 1183 Juniper Networks was instrumental in funding several versions of this 1184 draft as well as an open source implementation. 1186 Greg Shepherd suggested the inclusion of the AMT Membership Teardown 1187 message based on field experience. 1189 Contributors from AT&T provided useful inputs and ideas that were 1190 integrated into these specifications: Mark Altom, Andy Huang, Tom 1191 Imburgia, Patricia McCrink, Han Nguyen, Doug Nortz and Robert Sayko. 1193 13. References 1195 13.1. Normative References 1197 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1198 RFC 792, September 1981. 1200 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1201 Thyagarajan, "Internet Group Management Protocol, Version 1202 3", RFC 3376, October 2002. 1204 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1205 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1207 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1208 "Internet Group Management Protocol (IGMP) / Multicast 1209 Listener Discovery (MLD)-Based Multicast Forwarding 1210 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1212 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1213 IP", RFC 4607, August 2006. 1215 [I-D.ietf-6man-udpchecksums] 1216 Eubanks, M., "UDP Checksums for Tunneled Packets", 1217 draft-ietf-6man-udpchecksums-00 (work in progress), 1218 March 2011. 1220 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1221 Architecture", RFC 4291, February 2006. 1223 13.2. Informative References 1225 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1226 RFC 1112, August 1989. 1228 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 1229 Anycasting Service", RFC 1546, November 1993. 1231 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1232 Hashing for Message Authentication", RFC 2104, 1233 February 1997. 1235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1236 Requirement Levels", BCP 14, RFC 2119, March 1997. 1238 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 1239 Tunnel Broker", RFC 3053, January 2001. 1241 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1242 via IPv4 Clouds", RFC 3056, February 2001. 1244 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1245 RFC 3068, June 2001. 1247 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1248 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1249 Protocol Specification (Revised)", RFC 4601, August 2006. 1251 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1252 "Multiprotocol Extensions for BGP-4", RFC 4760, 1253 January 2007. 1255 Authors' Addresses 1257 Dave Thaler 1258 Microsoft Corporation 1259 One Microsoft Way 1260 Redmond, WA 98052-6399 1261 USA 1263 Phone: +1 425 703 8835 1264 Email: dthaler@microsoft.com 1266 Mohit Talwar 1267 Microsoft Corporation 1268 One Microsoft Way 1269 Redmond, WA 98052-6399 1270 USA 1272 Phone: +1 425 705 3131 1273 Email: mohitt@microsoft.com 1275 Amit Aggarwal 1276 Microsoft Corporation 1277 One Microsoft Way 1278 Redmond, WA 98052-6399 1279 USA 1281 Phone: +1 425 706 0593 1282 Email: amitag@microsoft.com 1284 Lorenzo Vicisano 1285 Qualcomm Inc. 1286 3165 Kifer Road 1287 Santa Clara, CA 95051 1288 USA 1290 Email: vicisano@qualcomm.com 1291 Tom Pusateri 1292 !j 1293 2109 Mountain High Rd. 1294 Wake Forest, NC 27587 1295 USA 1297 Email: pusateri@bangj.com 1299 Thomas Morin 1300 France Telecom - Orange 1301 2, avenue Pierre Marzin 1302 Lannion 22300 1303 France 1305 Phone: +33 2 96 05 3734 1306 Email: thomas.morin@orange-ftgroup.com