idnits 2.17.1 draft-ietf-mboned-auto-multicast-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- No issues found here. 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 (March 7, 2010) is 5157 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) -- 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: 1 error (**), 0 flaws (~~), 1 warning (==), 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: September 8, 2010 Microsoft Corporation 6 L. Vicisano 7 Qualcomm Inc. 8 T. Pusateri 9 !j 10 March 7, 2010 12 Automatic IP Multicast Without Explicit Tunnels (AMT) 13 draft-ietf-mboned-auto-multicast-10 15 Abstract 17 Automatic Multicast Tunneling (AMT) allows multicast communication 18 amongst isolated multicast-enabled sites or hosts, attached to a 19 network which has no native multicast support. It also enables them 20 to exchange multicast traffic with the native multicast 21 infrastructure and does not require any manual configuration. AMT 22 uses an encapsulation interface so that no changes to a host stack or 23 applications are required, all protocols (not just UDP) are handled, 24 and there is no additional overhead in core routers. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on September 8, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 79 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 7 81 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 8 83 4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 8 84 4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 4.4. AMT Relay Router . . . . . . . . . . . . . . . . . . . . . 8 86 4.5. AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 9 87 4.6. AMT Relay Anycast Address . . . . . . . . . . . . . . . . 9 88 4.7. AMT Subnet Anycast Prefix . . . . . . . . . . . . . . . . 9 89 4.8. AMT Gateway Anycast Address . . . . . . . . . . . . . . . 9 90 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 91 5.1. Receiving Multicast in an AMT Site . . . . . . . . . . . . 10 92 5.1.1. Scalability Considerations . . . . . . . . . . . . . . 11 93 5.1.2. Spoofing Considerations . . . . . . . . . . . . . . . 11 94 5.1.3. Protocol Sequence for a Gateway Joining SSM 95 Receivers to a Relay . . . . . . . . . . . . . . . . . 12 96 5.2. Sourcing Multicast from an AMT site . . . . . . . . . . . 14 97 5.2.1. Supporting Site-MBone Multicast . . . . . . . . . . . 15 98 5.2.2. Supporting Site-Site Multicast . . . . . . . . . . . . 16 99 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17 100 6.1. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 17 101 6.1.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17 102 6.1.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 17 103 6.1.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 17 104 6.2. AMT Relay Advertisement . . . . . . . . . . . . . . . . . 17 105 6.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 18 106 6.2.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 18 107 6.2.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 18 108 6.2.4. Relay Address . . . . . . . . . . . . . . . . . . . . 18 109 6.3. AMT Request . . . . . . . . . . . . . . . . . . . . . . . 18 110 6.3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 19 111 6.3.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 19 112 6.3.3. Request Nonce . . . . . . . . . . . . . . . . . . . . 19 113 6.4. AMT Membership Query . . . . . . . . . . . . . . . . . . . 19 114 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20 115 6.4.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20 116 6.4.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20 117 6.4.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 20 118 6.4.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 20 119 6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 21 120 6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21 121 6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22 122 6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 22 123 6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 22 124 6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 22 125 6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 22 126 6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 23 127 6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 23 128 6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 23 129 6.7. AMT Membership Teardown . . . . . . . . . . . . . . . . . 23 130 6.7.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 24 131 6.7.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 24 132 6.7.3. Original Response MAC . . . . . . . . . . . . . . . . 24 133 6.7.4. Original Request Nonce . . . . . . . . . . . . . . . . 24 134 6.7.5. Original Source Port . . . . . . . . . . . . . . . . . 24 135 6.7.6. Source AFI . . . . . . . . . . . . . . . . . . . . . . 24 136 6.7.7. Original Source Address . . . . . . . . . . . . . . . 25 137 6.7.8. IGMP/MLD Message (including IP Header) . . . . . . . . 25 138 7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 26 139 7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 26 140 7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 26 141 7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 27 142 7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 27 143 7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 28 144 7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 28 145 7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 29 146 7.6. Receiving AMT Membership Updates by the Gateway . . . . . 29 147 7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 29 148 8. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 30 149 8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 30 150 8.2. Receiving Relay Discovery messages sent to the Anycast 151 Address . . . . . . . . . . . . . . . . . . . . . . . . . 30 152 8.3. Receiving Membership Updates from AMT Gateways . . . . . . 30 153 8.4. Receiving (S,G) Joins from the Native Side, for AMT 154 Sources . . . . . . . . . . . . . . . . . . . . . . . . . 31 155 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 156 9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 32 157 9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32 158 9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32 159 9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation . . . . . . . . 32 160 9.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 32 161 9.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 32 162 9.3. UDP Port number . . . . . . . . . . . . . . . . . . . . . 32 163 10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 164 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34 165 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35 166 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 167 13.1. Normative References . . . . . . . . . . . . . . . . . . . 36 168 13.2. Informative References . . . . . . . . . . . . . . . . . . 36 169 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 171 1. Introduction 173 The primary goal of this document is to foster the deployment of 174 native IP multicast by enabling a potentially large number of nodes 175 to connect to the already present multicast infrastructure. 176 Therefore, the techniques discussed here should be viewed as an 177 interim solution to help in the various stages of the transition to a 178 native multicast network. 180 To allow fast deployment, the solution presented here only requires 181 small and concentrated changes to the network infrastructure, and no 182 changes at all to user applications or to the socket API of end- 183 nodes' operating systems. The protocol introduced in this 184 specification can be deployed in a few strategically-placed network 185 nodes and in user-installable software modules (pseudo device drivers 186 and/or user-mode daemons) that reside underneath the socket API of 187 end-nodes' operating systems. This mechanism is very similar to that 188 used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6 189 connectivity. 191 Effectively, AMT treats the unicast-only inter-network as a large 192 non-broadcast multi-access (NBMA) link layer, over which we require 193 the ability to multicast. To do this, multicast packets being sent 194 to or from a site must be encapsulated in unicast packets. If the 195 group has members in multiple sites, AMT encapsulation of the same 196 multicast packet will take place multiple times by necessity. 198 2. Applicability 200 AMT is not a substitute for native multicast or a statically 201 configured multicast tunnel for high traffic flow. Unicast 202 replication is required to reach multiple receivers that are not part 203 of the native multicast infrastructure. Unicast replication is also 204 required by non-native sources to different parts of the native 205 multicast infrastructure. However, this is no worse than regular 206 unicast distribution of streams and in most cases much better. 208 The following problems are addressed: 210 1. Allowing isolated sites/hosts to receive the SSM flavor of 211 multicast ([RFC4607]). 213 2. Allowing isolated non-NAT sites/hosts to transmit the SSM flavor 214 of multicast. 216 3. Allowing isolated sites/hosts to receive general multicast (ASM 217 [RFC1112]). 219 This document does not address allowing isolated sites/hosts to 220 transmit general multicast. We expect that other solutions (e.g., 221 Tunnel Brokers, a la [RFC3053]) will be used for sites that desire 222 this capability. 224 Implementers should be aware that site administrators may have 225 configured administratively scoped multicast boundaries and a remote 226 gateway may provide a means to circumvent administrative boundaries. 227 Therefore, implementations should allow for the configuration of such 228 boundaries on relays and gateways and perform filtering as needed. 230 3. Requirements notation 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 234 document are to be interpreted as described in [RFC2119]. 236 4. Definitions 238 +---------------+ Internet +---------------+ 239 | AMT Site | | Native MCast | 240 | | | | 241 | +------+----+ AMT +----+----+ AMT | 242 | |AMT Gateway| Anycast |AMT Relay| Subnet | 243 | | +-----+-+ Prefix +-+-----+ | Prefix | 244 | | |AMT IF | <------------|AMT IF | |--------> | 245 | | +-----+-+ +-+-----+ | | 246 | +------+----+ +----+----+ | 247 | | | | 248 +---------------+ +---------------+ 250 4.1. AMT Pseudo-Interface 252 AMT encapsulation of multicast packets inside unicast packets occurs 253 at a point that is logically equivalent to an interface, with the 254 link layer being the unicast-only network. This point is referred to 255 as a pseudo-interface. Some implementations may treat it exactly 256 like any other interface and others may treat it like a tunnel end- 257 point. 259 4.2. AMT Gateway 261 A host, or a site gateway router, supporting an AMT Pseudo- 262 Interface. It does not have native multicast connectivity to the 263 native multicast backbone infrastructure. It is simply referred to 264 in this document as a "gateway". 266 4.3. AMT Site 268 A multicast-enabled network not connected to the multicast backbone 269 served by an AMT Gateway. It could also be a stand- alone AMT 270 Gateway. 272 4.4. AMT Relay Router 274 A multicast router configured to support transit routing between AMT 275 Sites and the native multicast backbone infrastructure. The relay 276 router has one or more interfaces connected to the native multicast 277 infrastructure, zero or more interfaces connected to the non- 278 multicast capable inter-network, and an AMT pseudo-interface. It is 279 simply referred to in this document as a "relay". 281 As with [RFC3056], we assume that normal multicast routers do not 282 want to be tunnel endpoints (especially if this results in high fan 283 out), and similarly that service providers do not want encapsulation 284 to arbitrary routers. Instead, we assume that special-purpose 285 routers will be deployed that are suitable for serving as relays. 287 4.5. AMT Relay Anycast Prefix 289 A well-known address prefix used to advertise (into the unicast 290 routing infrastructure) a route to an available AMT Relay Router. 291 This could also be private (i.e., not well-known) for a private 292 relay. 294 Prefixes for both IPv4 and IPv6 will be assigned in a future version 295 of this draft. 297 4.6. AMT Relay Anycast Address 299 An anycast address which is used to reach the nearest AMT Relay 300 Router. 302 This address corresponds to the setting the low-order octet of the 303 AMT Relay Anycast Prefix to 1 (for both IPv4 and IPv6). 305 4.7. AMT Subnet Anycast Prefix 307 A well-known address prefix used to advertise (into the M-RIB of the 308 native multicast-enabled infrastructure) a route to AMT Sites. This 309 prefix will be used to enable sourcing SSM traffic from an AMT 310 Gateway. 312 4.8. AMT Gateway Anycast Address 314 An anycast address in the AMT Subnet Anycast Prefix range, which is 315 used by an AMT Gateway to enable sourcing SSM traffic from local 316 applications. 318 5. Overview 320 5.1. Receiving Multicast in an AMT Site 322 Internet 323 +---------------+ +---------------+ 324 | AMT Site | 2. 3-way Membership | MBone | 325 | | Handshake | | 326 | 1. Join +---+---+ =================> +---+---+ | 327 | +---->|Gateway| | Relay | | 328 | | +---+---+ <================= +---+---+ | 329 | R-+ | 3. Receive Data | | 330 +---------------+ +---------------+ 332 Receiving Multicast in an AMT Site 334 AMT relays and gateways cooperate to transmit multicast traffic 335 sourced within the native multicast infrastructure to AMT sites: 336 relays receive the traffic natively and unicast-encapsulate it to 337 gateways; gateways decapsulate the traffic and possibly forward it 338 into the AMT site. 340 Each gateway has an AMT pseudo-interface that serves as a default 341 multicast route. Requests to join a multicast session are sent to 342 this interface and encapsulated to a particular relay reachable 343 across the unicast-only infrastructure. 345 Each relay has an AMT pseudo-interface too. Multicast traffic sent 346 on this interface is encapsulated to zero or more gateways that have 347 joined to the relay. The AMT recipient-list is determined for each 348 multicast session. This requires the relay to keep state for each 349 gateway which has joined a particular group or (source, group) pair. 350 Multicast packets from the native infrastructure behind the relay 351 will be sent to each gateway which has requested them. 353 All multicast packets (data and control) are encapsulated in unicast 354 packets. UDP encapsulation is used for all AMT control and data 355 packets using the IANA reserved UDP port number for AMT. 357 Each relay, plus the set of all gateways using the relay, together 358 are thought of as being on a separate logical NBMA link. This 359 implies that the AMT recipient-list is a list of "link layer" 360 addresses which are (IP address, UDP port) pairs. 362 Since the number of gateways using a relay can be quite large, and we 363 expect that most sites will not want to receive most groups, an 364 explicit-joining protocol is required for gateways to communicate 365 group membership information to a relay. The two most likely 366 candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the 367 PIM-Sparse Mode protocol [RFC4601]. Since an AMT gateway may be a 368 host, and hosts typically do not implement routing protocols, 369 gateways will use IGMP/MLD as described in Section 7 below. This 370 allows a host kernel (or a pseudo device driver) to easily implement 371 AMT gateway behavior, and obviates the relay from the need to know 372 whether a given gateway is a host or a router. From the relay's 373 perspective, all gateways are indistinguishable from hosts on an NBMA 374 leaf network. 376 5.1.1. Scalability Considerations 378 It is possible that millions of hosts will enable AMT gateway 379 functionality and so an important design goal is not to create 380 gateway state in each relay until the gateway joins a multicast 381 group. But even the requirement that a relay keep group state per 382 gateway that has joined a group introduces potential scalability 383 concerns. 385 Scalability of AMT can be achieved by adding more relays, and using 386 an appropriate relay discovery mechanism for gateways to discover 387 relays. The solution we adopt is to assign addresses in anycast 388 fashion to relays [RFC1546], [RFC4291]. However, simply sending 389 periodic membership reports to an anycast address can cause 390 duplicates. Specifically, if routing changes such that a different 391 relay receives a periodic membership report, both the new and old 392 relays will encapsulate data to the AMT site until the old relay's 393 state times out. This is obviously undesirable. Instead, we use the 394 anycast address merely to find the unicast address of a relay to 395 which membership reports are sent. 397 Since adding another relay has the result of adding another 398 independent NBMA link, this allows the gateways to be spread out 399 among more relays so as to keep the number of gateways per relay at a 400 reasonable level. 402 5.1.2. Spoofing Considerations 404 An attacker could affect the group state in the relay or gateway by 405 spoofing the source address in the join or leave reports. This can 406 be used to launch reflection or denial of service attacks on the 407 target. Such attacks can be mitigated by using a three way handshake 408 between the gateway and the relay for each multicast membership 409 report or leave. 411 When a gateway or relay wants to send a membership report, it first 412 sends an AMT Request with a request nonce in it. The receiving side 413 (the respondent) can calculate a message authentication code (MAC) 414 based on (for example) the source IP address of the Request, the 415 source UDP port, the request nonce, and a secret key known only to 416 the respondent. The algorithm and the input used to calculate the 417 MAC does not have to be standardized since the respondent generates 418 and verifies the MAC and the originator simply echoes it. 420 An AMT Membership Query is sent back including the request nonce and 421 the MAC to the originator of the Request. The originator then sends 422 the IGMP/MLD Membership/Listener Report or Leave/Done (including the 423 IP Header) along with the request nonce and the received MAC back to 424 the respondent finalizing the 3-way handshake. 426 Upon reception, the respondent can recalculate the MAC based on the 427 source IP address, the source UDP port, the request nonce, and the 428 local secret. The IGMP/MLD message is only accepted if the received 429 MAC matches the calculated MAC. 431 The local secret never has to be shared with the other side. It is 432 only used to verify return routability of the originator. 434 Since the same Request Nonce and source IP address can be re-used, 435 the receiver SHOULD change its secret key at least once per hour. 436 However, AMT Membership updates received with the previous secret 437 MUST be accepted for up to the IGMP/MLD Query Interval. 439 The condition might occur where the gateway or relay that initially 440 sent the AMT Request dynamically changes its IP address. This might 441 occur due to a change in wireless networks, a DHCP assignment, or 442 another network failure. When this occurs, it is no longer possible 443 to verify the MAC using the source address and source port. Though, 444 in order to reduce state, it is desirable to tear down the state that 445 was created with the old source address. A Teardown message with 446 special considerations for calculating the MAC is described below to 447 perform this function. 449 5.1.3. Protocol Sequence for a Gateway Joining SSM Receivers to a Relay 451 This description assumes the Gateway can be a host joining as a 452 receiver or a network device acting as a Gateway when a directly 453 connected host joins as a receiver. 455 o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1). 457 o Gateway receives report. If it has no tunnel state with a Relay, 458 it originates an AMT Relay Discovery message addressed to the 459 Anycast Relay IP address. The AMT Relay Discovery message can be 460 sent on demand if no relay is known at this time or at startup and 461 be periodically refreshed. 463 o The closest Relay topologically receives the AMT Relay Discovery 464 message and returns the nonce from the Discovery in an AMT Relay 465 Advertisement message so the Gateway can learn of the Relay's 466 unique IP address. 468 o When the Gateway receives the AMT Relay Advertisement message, it 469 now has an address to use for all subsequent (S,G) entries it will 470 join on behalf of attached receivers (or itself). 472 o If the gateway has a valid Response MAC from a previous AMT Query 473 message, it can send an AMT Membership Update message as described 474 below. Otherwise, the Gateway sends an AMT Request message to the 475 Relay's unique IP address to begin the process of joining the 476 (S,G). The gateway also SHOULD initialize a timer used to send 477 periodic Requests to a random value from the interval [0, [Query 478 Interval]] before sending the first periodic report, in order to 479 prevent startup synchronization. 481 o The Relay responds to the AMT Request message by returning the 482 nonce from the Request in a AMT Query message. The Query message 483 contains an IGMP/MLD QUERY indicating how often the Gateway should 484 repeat AMT Request messages so the (S,G) state can stay refreshed 485 in the Relay. The Query message also includes an opaque security 486 code which is generated locally (with no external coordination). 488 o When the Gateway receives the AMT Query message it responds by 489 copying the security code from the AMT Query message into a AMT 490 Membership Update message. The Update message contains (S1,G1) in 491 an IGMPv3/MLDv2 formatted packet with an IP header. The nonce 492 from the AMT Request is also included in the AMT Membership Update 493 message. 495 o When the Relay receives the AMT Membership Update, it will add the 496 tunnel to the Gateway in it's outgoing interface list for it's 497 (S1,G1) entry stored in the multicast routing table. If the 498 (S1,G1) entry was created do to this interaction, the multicast 499 routing protocol running on the Relay will trigger a Join message 500 towards source S1 to build a native multicast tree in the native 501 multicast infrastructure. 503 o As packets are sent from the host S1, they will travel natively 504 down the multicast tree associated with (S1,G1) in the native 505 multicast infrastructure to the Relay. The Relay will replicate 506 to all interfaces in it's outgoing interface list as well as the 507 tunnel outgoing interface, which is encapsulated in a unicast AMT 508 Multicast Data message. 510 o When the Gateway receives the AMT Multicast Data message, it will 511 accept the packet since it was received over the pseudo-interface 512 associated with the tunnel to the Relay it had attached to, and 513 forward the packet to the outgoing interfaces joined by any 514 attached receiver hosts (or deliver the packet to the application 515 when the Gateway is the receiver). 517 o If later (S2,G2) is joined by a receiver, a 3-way handshake of 518 Request/ Query/Update occurs for this entry. The Discovery/ 519 Advertisement exchange is not required. 521 o To keep the state for (S1,G1) and (S2,G2) alive in the Relay, the 522 Gateway will send periodic AMT Membership Updates. The Membership 523 Update can be sent directly if the sender has a valid nonce from a 524 previous Request. If not, an AMT Request messages should be sent 525 to solicit a Query Message. When sending a periodic state 526 refresh, all joined state in the Gateway is packed in the fewest 527 number of AMT Membership Update messages. 529 o When the Gateway leaves all (S,G) entries, the Relay can free 530 resources associated with the tunnel. It is assumed that when the 531 Gateway would want to join an (S,G) again, it would start the 532 Discovery/Advertisement tunnel establishment process over again. 534 This same procedure would be used for receivers who operate in Any- 535 Source Multicast (ASM) mode. 537 5.2. Sourcing Multicast from an AMT site 539 Two cases are discussed below: multicast traffic sourced in an AMT 540 site and received in the MBone, and multicast traffic sourced in an 541 AMT site and received in another AMT site. 543 In both cases only SSM sources are supported. Furthermore this 544 specification only deals with the source residing directly in the 545 gateway. To enable a generic node in an AMT site to source 546 multicast, additional coordination between the gateway and the 547 source-node is required. 549 The gateway SHOULD allow for filtering link-local and site-local 550 traffic. 552 The general mechanism used to join towards AMT sources is based on 553 the following: 555 1. Applications residing in the gateway use addresses in the AMT 556 Subnet Anycast Prefix to send multicast, as a result of sourcing 557 traffic on the AMT pseudo-interface. 559 2. The AMT Subnet Anycast Prefix is advertised for RPF reachability 560 in the M-RIB by relays and gateways. 562 3. Relays or gateways that receive a join for a source/group pair 563 use information encoded in the address pair to rebuild the 564 address of the gateway (source) to which to encapsulate the join 565 (see Section 7.2 for more details). The membership reports use 566 the same three way handshake as outlined in Section 5.1.2 568 5.2.1. Supporting Site-MBone Multicast 570 Internet 571 +---------------+ +---------------+ 572 | AMT Site | 2. 3-way Membership | MBone | 573 | | Handshake | | 574 | +---+---+ <================= +---+---+ 1. Join | 575 | |Gateway| | Relay |<-----+ | 576 | +---+---+ =================> +---+---+ | | 577 | | 3. Receive Data | +-R | 578 +---------------+ +---------------+ 580 Site-MBone Multicast 582 If a relay receives an explicit join from the native infrastructure, 583 for a given (source, group) pair where the source address belongs to 584 the AMT Subnet Anycast Prefix, then the relay will periodically 585 (using the rules specified in Section 5.1.2) encapsulate membership 586 updates for the group to the gateway. The gateway must keep state 587 per relay from which membership reports have been sent, and forward 588 multicast traffic from the site to all relays from which membership 589 reports have been received. The choice of whether this state and 590 replication is done at the link-layer (i.e., by the tunnel interface) 591 or at the network-layer is implementation dependent. 593 If there are multiple relays present, this ensures that data from the 594 AMT site is received via the closest relay to the receiver. This is 595 necessary when the routers in the native multicast infrastructure 596 employ Reverse-Path Forwarding (RPF) checks against the source 597 address, such as occurs when PIM Sparse-Mode [RFC4601] is used by the 598 multicast infrastructure. 600 The solution above will scale to an arbitrary number of relays, as 601 long at the number of relays requiring multicast traffic from a given 602 AMT site remains reasonable enough to not overly burden the site's 603 gateway. 605 A source at or behind an AMT gateway requires the gateway to do the 606 replication to one or more relays and receiving gateways. If this 607 places too much of a burden on the sourcing gateway, the source 608 should join the native multicast infrastructure through a permanent 609 tunnel so that replication occurs within the native multicast 610 infrastructure. 612 5.2.2. Supporting Site-Site Multicast 614 Internet 615 +---------------+ +---------------+ 616 | AMT Site | 2. 3-way Membership | AMT Site | 617 | | Handshake | | 618 | +---+---+ <================= +---+---+ 1. Join | 619 | |Gateway| |Gateway|<-----+ | 620 | +---+---+ =================> +---+---+ | | 621 | | 3. Receive Data | +-R | 622 +---------------+ +---------------+ 624 Site-Site Multicast 626 Since we require gateways to accept membership reports, as described 627 above, it is also possible to support multicast among AMT sites, 628 without requiring assistance from any relays. 630 When a gateway wants to join a given (source, group) pair, where the 631 source address belongs to the AMT Subnet Anycast Prefix, then the 632 gateway will periodically unicast encapsulate an IGMPv3/MLDv2 Report 633 [RFC3376], [RFC3810] (including IP Header) directly to the site 634 gateway for the source. 636 We note that this can result in a significant amount of state at a 637 site gateway sourcing multicast to a large number of other AMT sites. 638 However, it is expected that this is not unreasonable for two 639 reasons. First, the gateway does not have native multicast 640 connectivity, and as a result is likely doing unicast replication at 641 present. The amount of state is thus the same as what such a site 642 already deals with. Secondly, any site expecting to source traffic 643 to a large number of sites could get a point-to-point tunnel to the 644 native multicast infrastructure, and use that instead of AMT. 646 6. Message Formats 648 6.1. AMT Relay Discovery 650 The AMT Relay Discovery message is a UDP packet sent from the AMT 651 gateway unicast address to the AMT relay anycast address to discover 652 the unicast address of an AMT relay. 654 The UDP source port is uniquely selected by the local host operating 655 system. The UDP destination port is the IANA reserved AMT port 656 number. The UDP checksum MUST be valid in AMT control messages. 658 The payload of the UDP packet contains the following fields. 660 0 1 2 3 661 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 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Type=0x1 | Reserved | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 | Discovery Nonce | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 AMT Relay Discovery 670 6.1.1. Type 672 The type of the message. 674 6.1.2. Reserved 676 A 24-bit reserved field. Sent as 0, ignored on receipt. 678 6.1.3. Discovery Nonce 680 A 32-bit random value generated by the gateway and replayed by the 681 relay. 683 6.2. AMT Relay Advertisement 685 The AMT Relay Advertisement message is a UDP packet sent from the AMT 686 relay anycast address to the source of the discovery message. 688 The UDP source port is the IANA reserved AMT port number and the UDP 689 destination port is the source port received in the Discovery 690 message. The UDP CHECKSUM MUST be valid in AMT control messages. 692 The payload of the UDP packet contains the following fields. 694 0 1 2 3 695 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 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Type=0x2 | Reserved | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Discovery Nonce | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Relay Address | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 AMT Relay Advertisement 706 6.2.1. Type 708 The type of the message. 710 6.2.2. Reserved 712 A 24-bit reserved field. Sent as 0, ignored on receipt. 714 6.2.3. Discovery Nonce 716 A 32-bit random value generated by the gateway and replayed by the 717 relay. 719 6.2.4. Relay Address 721 The unicast IPv4 or IPv6 address of the AMT relay. The family can be 722 determined by the length of the Advertisement. 724 6.3. AMT Request 726 A Request packet is sent to begin a 3-way handshake for sending an 727 IGMP/MLD Membership/Listener Report or Leave/Done. It can be sent 728 from a gateway to a relay, from a gateway to another gateway, or from 729 a relay to a gateway. 731 It is sent from the originator's unique unicast address to the 732 respondents' unique unicast address. 734 The UDP source port is uniquely selected by the local host operating 735 system. It can be different for each Request and different from the 736 source port used in Discovery messages but does not have to be. The 737 UDP destination port is the IANA reserved AMT port number. The UDP 738 checksum MUST be valid in AMT control messages. 740 0 1 2 3 741 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 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Type=0x3 | Reserved | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Request Nonce | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 AMT Relay Advertisement 750 6.3.1. Type 752 The type of the message. 754 6.3.2. Reserved 756 A 24-bit reserved field. Sent as 0, ignored on receipt. 758 6.3.3. Request Nonce 760 A 32-bit identifier used to distinguish this request. 762 6.4. AMT Membership Query 764 An AMT Membership Query packet is sent from the respondent back to 765 the originator to solicit an AMT Membership Update while confirming 766 the source of the original request. It contains a relay Message 767 Authentication Code (MAC) that is a cryptographic hash of a private 768 secret, the originators address, and the request nonce. 770 It is sent from the destination address received in the Request to 771 the source address received in the Request which is the same address 772 used in the Relay Advertisement. 774 The UDP source port is the IANA reserved AMT port number and the UDP 775 destination port is the source port received in the Request message. 776 The UDP checksum MUST be valid in AMT control messages. 778 0 1 2 3 779 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 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | Type=0x4 | Reserved | Response MAC | 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | Response MAC (continued) | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Request Nonce | 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | IGMP Membership Query or MLD Listener Query | 788 | (including IP Header) | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | ... | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 AMT Membership Query 795 6.4.1. Type 797 The type of the message. 799 6.4.2. Reserved 801 A 8-bit reserved field. Sent as 0, ignored on receipt. 803 6.4.3. Response MAC 805 A 48-bit hash generated by the respondent and sent to the originator 806 for inclusion in the AMT Membership Update. The algorithm used for 807 this is chosen by the respondent but an algorithm such as HMAC-MD5-48 808 [RFC2104] SHOULD be used at a minimum. 810 6.4.4. Request Nonce 812 A 32-bit identifier used to distinguish this request echoed back to 813 the originator. 815 6.4.5. IGMP/MLD Query (including IP Header) 817 The message contains either an IGMP Query or an MLD Multicast 818 Listener Query. The IGMP or MLD version sent should default to 819 IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1. 820 The IGMP/MLD Query includes a full IP Header. The IP source address 821 of the query would match the anycast address on the pseudo interface. 822 The TTL of the outer header should be sufficient to reach the tunnel 823 endpoint and not mimic the inner header TTL which is typically 1 for 824 IGMP/MLD messages. 826 6.5. AMT Membership Update 828 An AMT Membership Update is sent to report a membership after a valid 829 Response MAC has been received. It contains the original IGMP/MLD 830 Membership/Listener Report or Leave/Done received over the AMT 831 pseudo-interface including the original IP header. It echoes the 832 Response MAC received in the AMT Membership Query so the respondent 833 can verify return routability to the originator. 835 It is sent from the destination address received in the Query to the 836 source address received in the Query which should both be the same as 837 the original Request. 839 The UDP source and destination port numbers should be the same ones 840 sent in the original Request. 842 The relay is not required to use the IP source address of the IGMP 843 Membership Report for any particular purpose. 845 The same Request Nonce and Response MAC can be used across multiple 846 AMT Membership Update messages without having to send individual AMT 847 Membership Query messages. 849 0 1 2 3 850 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 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Type=0x5 | Reserved | Response MAC | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Response MAC (continued) | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Request Nonce | 857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 858 | IGMP or MLD Message (including IP header) | 859 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 | ... | 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 863 AMT Membership Update 865 6.5.1. Type 867 The type of the message. 869 6.5.2. Reserved 871 A 8-bit reserved field. Sent as 0, ignored on receipt. 873 6.5.3. Response MAC 875 The 48-bit MAC received in the Membership Query and echoed back in 876 the Membership Update. 878 6.5.4. Request Nonce 880 A 32-bit identifier used to distinguish this request. 882 6.5.5. IGMP/MLD Message (including IP Header) 884 The message contains either an IGMP Membership Report, an IGMP 885 Membership Leave, an MLD Multicast Listener Report, or an MLD 886 Listener Done. The IGMP or MLD version sent should be in response 887 the version of the query received in the AMT Membership Query. The 888 IGMP/MLD Message includes a full IP Header. 890 6.6. AMT IP Multicast Data 892 The AMT Data message is a UDP packet encapsulating the IP Multicast 893 data requested by the originator based on a previous AMT Membership 894 Update message. 896 It is sent from the unicast destination address of the Membership 897 update to the source address of the Membership Update. 899 The UDP source and destination port numbers should be the same ones 900 sent in the original Query. The UDP checksum MUST be valid in AMT 901 control messages. 903 The payload of the UDP packet contains the following fields. 905 0 1 2 3 906 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 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 908 | Type=0x6 | Reserved | IP Multicast Data ... | 909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 | ... | 911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 913 AMT IP Multicast Data 915 6.6.1. Type 917 The type of the message. 919 6.6.2. Reserved 921 An 8-bit reserved field. Sent as 0, ignored on receipt. 923 6.6.3. IP Multicast Data 925 The original IP Multicast data packet that is being replicated by the 926 relay to the gateways including the original IP header. 928 6.7. AMT Membership Teardown 930 An AMT Membership Teardown is sent to report an IGMP Membership Leave 931 or MLD Listener Done after a valid Response MAC has been received and 932 after the source address that was used to generate the Response MAC 933 is no longer available for sourcing packets. 935 An AMT Membership Teardown from the original source address and 936 source port is NOT valid and should be discarded if received. Use an 937 AMT Membership Update instead. 939 An AMT Membership Teardown can only contain either an IGMP Membership 940 Leave or an MLD Listener Done message. The encapsulated IGMP/MLD 941 message will have to be fabricated by the sender of the AMT 942 Membership Teardown in the case where there wasn't an original IGMP/ 943 MLD message to be forwarded. 945 In order for the receiver to verify the Membership Teardown message, 946 it must contain the original source address and source port in 947 addition to the Original Request Nonce and Original Response MAC. 949 It is sent to the source address received in the original Query which 950 should be the same as the original Request. 952 The UDP destination port number should be the same one sent in the 953 original Request. 955 The relay is not required to use the IP source address of the IGMP 956 Membership Report for any particular purpose. 958 0 1 2 3 959 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 960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 961 | Type=0x7 | Reserved | Original Response MAC | 962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 963 | Original Response MAC (continued) | 964 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 965 | Original Request Nonce | 966 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 967 | Original Source Port | Source AFI | 968 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 969 | Original Source Address | 970 | ... | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | IGMP Membership Leave or | 973 | MLD Listener Done (including IP header) | 974 | ... | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 AMT Membership Teardown 979 6.7.1. Type 981 The type of the message. 983 6.7.2. Reserved 985 A 8-bit reserved field. Sent as 0, ignored on receipt. 987 6.7.3. Original Response MAC 989 The 48-bit MAC received in the Membership Query and echoed back in 990 the Membership Update. 992 6.7.4. Original Request Nonce 994 A 32-bit identifier used to distinguish this request. 996 6.7.5. Original Source Port 998 The 16-bit port number used in the original AMT Membership update 999 that was used to generate the Original Response MAC. 1001 6.7.6. Source AFI 1003 A 16-bit Address Family Identifier (AFI) [RFC4760] used to determine 1004 the protocol address family of the following Original Source Address. 1006 Presently defined values for the Address Family Identifier field are 1007 specified in IANA's Address Family Numbers registry [IANA.AFN] 1009 6.7.7. Original Source Address 1011 The source address used in the original AMT Membership update that 1012 was used to generate the Original Response MAC. 1014 6.7.8. IGMP/MLD Message (including IP Header) 1016 The message contains either an IGMP Membership Leave or an MLD 1017 Listener Done. The IGMP or MLD version sent should be in response 1018 the version of the query received in the original AMT Membership 1019 Query. The IGMP/MLD Message includes a full IP Header. 1021 7. AMT Gateway Details 1023 This section details the behavior of an AMT Gateway, which may be a 1024 router serving an AMT site, or the site may consist of a single host, 1025 serving as its own gateway. 1027 7.1. At Startup Time 1029 At startup time, the AMT gateway will bring up an AMT pseudo- 1030 interface to be used for encapsulation. The gateway needs to 1031 discover an AMT Relay to send Membership Requests. It can send an 1032 AMT Relay Discovery at startup time or wait until it has a group 1033 membership to report. The AMT Relay Discovery message is sent to the 1034 AMT Relay Anycast Address. A unicast address (which is treated as a 1035 link-layer address to the encapsulation interface) is received in the 1036 AMT Relay Advertisement message. The discovery process SHOULD be 1037 done periodically (e.g., once a day) to re-resolve the unicast 1038 address of a close relay. To prevent startup synchronization, the 1039 timer SHOULD use at least 10 percent jitter. 1041 If the gateway is serving as a local router, it SHOULD also function 1042 as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD 1043 host-mode interface being the AMT pseudo-interface. This enables it 1044 to translate group memberships on its downstream interfaces into 1045 IGMP/MLD Reports. Hosts receiving multicast packets through an AMT 1046 gateway acting as a proxy should ensure that their M-RIB accepts 1047 multicast packets from the AMT gateway for the sources it is joining. 1049 7.2. Gateway Group and Source Addresses 1051 To support sourcing traffic to SSM groups by a gateway with a global 1052 unicast address, the AMT Subnet Anycast Prefix is treated as the 1053 subnet prefix of the AMT pseudo-interface, and an anycast address is 1054 added on the interface. This anycast address is formed by 1055 concatenating the AMT Subnet Anycast Prefix followed by the high bits 1056 of the gateway's global unicast address. 1058 The remaining bits of its global unicast address are appended to the 1059 SSM prefix to create the group address and any spare bits may be 1060 allocated using local policy. 1062 If a gateway wants to source multicast traffic, it must select the 1063 gateway source address and SSM group address in such a way that the 1064 AMT relay can have enough information to reconstruct the gateway's 1065 unicast address when it receives an SSM join for the source. 1067 Note that multiple gateways might end up with the same anycast 1068 address assigned to their pseudo-interfaces. 1070 7.2.1. IPv4 1072 For example, if IANA assigns the IPv4 prefix x.y/16 as the AMT Subnet 1073 Anycast Prefix, and the gateway has global unicast address a.b.c.d, 1074 then the AMT Gateway's Anycast Source Address will be x.y.a.b. Since 1075 the IPv4 SSM group range is 232/8, it MUST allocate IPv4 SSM groups 1076 in the range 232.c.d/24. 1078 Group: 1079 8 16 8 1080 +------------+------------------------+-------------+ 1081 | SSM prefix | Low 16 bits of | Local | 1082 | 232/8 | real source address | Policy | 1083 +------------+------------------------+-------------+ 1085 Source: 1086 +-------------------------+-------------------------+ 1087 |16-bit AMT unicast prefix| high 16 bits of real src| 1088 +-------------------------+-------------------------+ 1090 IPv4 format 1092 This allows for 2^8 (256) IPv4 group addresses for use by each AMT 1093 gateway. 1095 7.2.2. IPv6 1097 Similarly for IPv6, this is illustrated in the following figure. 1099 Group: 1100 32 64 32 1101 +------------+------------------------+-------------+ 1102 | SSM prefix | Low 64 bits of | Local | 1103 | FF3x::/32 | real source address | Policy | 1104 +------------+------------------------+-------------+ 1106 Source: 1107 +-------------------------+-------------------------+ 1108 |64-bit AMT unicast prefix| high 64 bits of real src| 1109 +-------------------------+-------------------------+ 1111 IPv6 format 1113 This allows for 2^32 (over 4 billion) IPv6 group addresses for use by 1114 each AMT gateway. 1116 7.3. Joining Groups with MBone Sources 1118 The IGMP/MLD protocol usually operates by having the Querier 1119 multicast an IGMP/MLD Query message on the link. This behavior does 1120 not work on NBMA links which do not support multicast. Since the set 1121 of gateways is typically unknown to the relay (and potentially quite 1122 large), unicasting the queries is also impractical. The following 1123 behavior is used instead. 1125 Applications residing in a gateway should join groups on the AMT 1126 pseudo-interface, causing IGMP/MLD Membership/Listener Reports to be 1127 sent over that interface. When UDP encapsulating the membership 1128 reports (and in fact any other messages, unless specified otherwise 1129 in this document), the destination address in the outer IP header is 1130 the relay's unicast address. Robustness is provided by the 1131 underlying IGMP/MLD protocol messages sent on the AMT pseudo- 1132 interface. In other words, the gateway does not need to retransmit 1133 IGMP/MLD Membership/Listener Reports and Leave/Done messages received 1134 on the pseudo-interface since IGMP/MLD will already do this. The 1135 gateway simply needs to encapsulate each IGMP/MLD Membership/Listener 1136 Report and Leave/Done message it receives. 1138 However, since periodic IGMP/MLD Membership/Listener Reports are sent 1139 in response to IGMP/MLD Queries, a mechanism to trigger periodic 1140 Membership/Listener Reports and Leave/Done messages is necessary. 1141 The gateway should use a timer to trigger periodic AMT Membership 1142 Updates. 1144 If the gateway is behind a firewall device, the firewall may require 1145 the gateway to periodically refresh the UDP state in the firewall at 1146 a shorter interval than the standard IGMP/MLD Query interval. AMT 1147 Requests can be sent periodically to solicit IGMP/MLD Queries. The 1148 interval at which the AMT Requests are sent should be configurable to 1149 ensure the firewall does not revert to blocking the UDP encapsulated 1150 IP Multicast data packets. When the AMT Query is received, it can be 1151 ignored unless it is time for a periodic AMT Membership Update. 1153 The relay can use the Querier's Robustness Variable (QRV) defined in 1154 [RFC3376] and [RFC3810] to adjust the number of Membership/Listener 1155 Reports that are sent by the host joining the group. 1157 7.4. Responding to Relay Changes 1159 When a gateway determines that its current relay is unreachable 1160 (e.g., upon receipt of an ICMP Unreachable message [RFC0792] for the 1161 relay's unicast address), it may need to repeat relay address 1162 discovery. However, care should be taken not to abandon the current 1163 relay too quickly due to transient network conditions. 1165 7.5. Joining SSM Groups with AMT Gateway Sources 1167 An IGMPv3/MLDv2 Report for a given (source, group) pair MAY be 1168 encapsulated directly to the source, when the source address belongs 1169 to the AMT Subnet Anycast Prefix. 1171 The "link-layer" address to use as the destination address in the 1172 outer IP header is obtained as follows. The source address in the 1173 inclusion list of the IGMPv3/MLDv2 report will be an AMT Gateway 1174 Anycast Address with the high bits of the address, and the remaining 1175 bits will be in the middle of the group address. 1177 Section 7.2 describes this format to recover the gateway source 1178 address. 1180 7.6. Receiving AMT Membership Updates by the Gateway 1182 When an AMT Request is received by the gateway from another gateway 1183 or relay, it follows the same 3-way handshake procedure a relay would 1184 follow if it received the AMT Request. It generates a MAC and 1185 responds with an AMT Membership Query. When the AMT Membership 1186 Update is received, it verifies the MAC and then processes the IGMP/ 1187 MLD Membership/Listener Report or Leave/Done. 1189 At the gateway, the IGMP/MLD packet should be an IGMPv3/MLDv2 source 1190 specific (S,G) join or leave. 1192 If S is not the AMT Gateway Anycast Address, the packet is silently 1193 discarded. If G does not contain the low bits of the global unicast 1194 address (as described above), the packet is also silently discarded. 1196 The gateway adds the source address (from the outer IP header) and 1197 UDP port of the report to a membership list for G. Maintaining this 1198 membership list may be done in any implementation-dependent manner. 1199 For example, it might be maintained by the "link-layer" inside the 1200 AMT pseudo-interface, making it invisible to the normal IGMP/MLD 1201 module. 1203 7.7. Sending data to SSM groups 1205 When multicast packets are sent on the AMT pseudo-interface, they are 1206 encapsulated as follows. If the group address is not an SSM group, 1207 then the packet is silently discarded (this memo does not currently 1208 provide a way to send to non-SSM groups). 1210 If the group address is an SSM group, then the packet is unicast 1211 encapsulated to each remote node from which the gateway has received 1212 an IGMPv3/MLDv2 report for the packet's (source, group) pair. 1214 8. Relay Router Details 1216 8.1. At Startup time 1218 At startup time, the relay router will bring up an NBMA-style AMT 1219 pseudo-interface. It shall also add the AMT Relay Anycast Address on 1220 some interface. 1222 The relay router shall then advertise the AMT Relay Anycast Prefix 1223 into the unicast-only Internet, as if it were a connection to an 1224 external network. When the advertisement is done using BGP, the AS 1225 path leading to the AMT Relay Anycast Prefix shall include the 1226 identifier of the local AS. 1228 The relay router shall also enable IGMPv3/MLDv2 on the AMT pseudo- 1229 interface, except that it shall not multicast Queries (this might be 1230 done, for example, by having the AMT pseudo-device drop them, or by 1231 having the IGMP/MLD module not send them in the first place). 1233 Finally, to support sourcing SSM traffic from AMT sites, the AMT 1234 Subnet Anycast Prefix is assigned to the AMT pseudo-interface, and 1235 the AMT Subnet Anycast Prefix is injected by the AMT Relay into the 1236 M-RIB of MBGP. 1238 8.2. Receiving Relay Discovery messages sent to the Anycast Address 1240 When a relay receives an AMT Relay Discovery message directed to the 1241 AMT Relay Anycast Address, it should respond with an AMT Relay 1242 Advertisement containing its unicast address. The source and 1243 destination addresses of the advertisement should be the same as the 1244 destination and source addresses of the discovery message 1245 respectively. Further, the nonce in the discovery message MUST be 1246 copied into the advertisement message. 1248 8.3. Receiving Membership Updates from AMT Gateways 1250 The relay operates passively, sending no periodic IGMP/MLD Queries 1251 but simply tracking membership information according to AMT Request/ 1252 Query/Membership Update tuples received. In addition, the relay must 1253 also do explicit membership tracking, as to which gateways on the AMT 1254 pseudo-interface have joined which groups. Once an AMT Membership 1255 Update has been successfully received, it updates the forwarding 1256 state for the appropriate group and source (if provided). When data 1257 arrives for that group, the traffic must be encapsulated to each 1258 gateway which has joined that group or (S,G). 1260 The explicit membership tracking and unicast replication may be done 1261 in any implementation-specific manner. Some examples are: 1263 1. The AMT pseudo-device driver might track the group information 1264 and perform the replication at the "link-layer", with no changes 1265 to a pre-existing IGMP/MLD module. 1267 2. The IGMP/MLD module might have native support for explicit 1268 membership tracking, especially if it supports other NBMA-style 1269 interfaces. 1271 If a relay wants to affect the rate at which the AMT Requests are 1272 originated from a gateway, it can tune the membership timeout by 1273 adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/ 1274 MLD Query contained within the AMT Membership Query message. The 1275 QQIC field is defined in [RFC3376] and [RFC3810]. However, since the 1276 gateway may need to send AMT Requests frequently enough to prevent 1277 firewall state from timing out, the relay may be limited in its 1278 ability to spread out Requests coming from a gateway by adjusting the 1279 QQIC field. 1281 8.4. Receiving (S,G) Joins from the Native Side, for AMT Sources 1283 The relay sends an IGMPv3/MLDv2 report to the AMT source as described 1284 above in Section 5.1.2 1286 9. IANA Considerations 1288 9.1. IPv4 and IPv6 Anycast Prefix Allocation 1290 The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated 1291 to the public AMT Relays to advertise to the native multicast 1292 backbone. The prefix length should be determined by the IANA; the 1293 prefix should be large enough to guarantee advertisement in the 1294 default-free BGP networks. 1296 9.1.1. IPv4 1298 A prefix length of 16 will meet this requirement. 1300 9.1.2. IPv6 1302 A prefix length of 32 will meet this requirement. IANA has 1303 previously set aside the range 2001::/16 for allocating prefixes for 1304 this purpose. 1306 9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation 1308 It should also be noted that this prefix length directly affects the 1309 number of groups available to be created by the AMT gateway: in the 1310 IPv4 case, a prefix length of 16 gives 256 groups, and a prefix 1311 length of 8 gives 65536 groups. 1313 All allocations are a one time effort and there will be no need for 1314 any recurring assignment after this stage. 1316 9.2.1. IPv4 1318 As described above in Section 7.2.1 an IPv4 prefix with a length of 1319 16 is requested for this purpose. 1321 9.2.2. IPv6 1323 As described above in Section 7.2.2 an IPv6 prefix with a length of 1324 32 is requested. 1326 9.3. UDP Port number 1328 IANA has previously allocated UDP reserved port number 2268 for AMT 1329 encapsulation. 1331 10. Security Considerations 1333 The anycast technique introduces a risk that a rogue router or a 1334 rogue AS could introduce a bogus route to the AMT Relay Anycast 1335 prefix, and thus divert the traffic. Network managers have to 1336 guarantee the integrity of their routing to the AMT Relay Anycast 1337 prefix in much the same way that they guarantee the integrity of all 1338 other routes. 1340 Within the native MBGP infrastructure, there is a risk that a rogue 1341 router or a rogue AS could inject a false route to the AMT Subnet 1342 Anycast Prefix, and thus divert joins and cause RPF failures of 1343 multicast traffic. As the AMT Subnet Anycast Prefix will be 1344 advertised by multiple entities, guaranteeing the integrity of this 1345 shared MBGP prefix is much more challenging than verifying the 1346 correctness of a regular unicast advertisement. To mitigate this 1347 threat, routing operators should configure the BGP sessions to filter 1348 out any more specific advertisements for the AMT Subnet Anycast 1349 Prefix. 1351 Gateways and relays will accept and decapsulate multicast traffic 1352 from any source from which regular unicast traffic is accepted. If 1353 this is for any reason felt to be a security risk, then additional 1354 source address based packet filtering MUST be applied: 1356 1. To prevent a rogue sender (that can't do traditional spoofing 1357 because of e.g. access lists deployed by its ISP) from making use 1358 of AMT to send packets to an SSM tree, a relay that receives an 1359 encapsulated multicast packet MUST discard the multicast packet 1360 if the IP source address in the outer header does not match the 1361 source address that would be extracted using the rules of 1362 Section 7.2. 1364 2. A gateway MUST discard encapsulated multicast packets if the 1365 source address in the outer header is not the address to which 1366 the encapsulated join message was sent. An AMT Gateway that 1367 receives an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard the 1368 message if the IP destination address in the outer header does 1369 not match the source address that would be extracted using the 1370 rules of Section 7.2. 1372 11. Contributors 1374 The following people provided significant contributions to earlier 1375 versions of this draft. 1377 Dirk Ooms 1378 OneSparrow 1379 Belegstraat 13; 2018 Antwerp; Belgium 1380 EMail: dirk@onesparrow.com 1382 12. Acknowledgments 1384 Most of the mechanisms described in this document are based on 1385 similar work done by the NGTrans WG for obtaining automatic IPv6 1386 connectivity without explicit tunnels ("6to4"). Tony Ballardie 1387 provided helpful discussion that inspired this document. 1389 In addition, extensive comments were received from Pekka Savola, Greg 1390 Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John 1391 Zwiebel, and Lenny Giuliano. 1393 Juniper Networks was instrumental in funding several versions of this 1394 draft as well as an open source implementation. 1396 Greg Shepherd suggested the inclusion of the AMT Membership Teardown 1397 message based on field experience. 1399 13. References 1401 13.1. Normative References 1403 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1404 RFC 792, September 1981. 1406 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1407 Thyagarajan, "Internet Group Management Protocol, Version 1408 3", RFC 3376, October 2002. 1410 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1411 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1413 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1414 "Internet Group Management Protocol (IGMP) / Multicast 1415 Listener Discovery (MLD)-Based Multicast Forwarding 1416 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1418 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1419 IP", RFC 4607, August 2006. 1421 13.2. Informative References 1423 [IANA.AFN] 1424 IANA, "Address Family Numbers", . 1428 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1429 RFC 1112, August 1989. 1431 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 1432 Anycasting Service", RFC 1546, November 1993. 1434 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1435 Hashing for Message Authentication", RFC 2104, 1436 February 1997. 1438 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1439 Requirement Levels", BCP 14, RFC 2119, March 1997. 1441 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 1442 Tunnel Broker", RFC 3053, January 2001. 1444 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1445 via IPv4 Clouds", RFC 3056, February 2001. 1447 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1448 RFC 3068, June 2001. 1450 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1451 Architecture", RFC 4291, February 2006. 1453 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1454 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1455 Protocol Specification (Revised)", RFC 4601, August 2006. 1457 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 1458 "Multiprotocol Extensions for BGP-4", RFC 4760, 1459 January 2007. 1461 Authors' Addresses 1463 Dave Thaler 1464 Microsoft Corporation 1465 One Microsoft Way 1466 Redmond, WA 98052-6399 1467 USA 1469 Phone: +1 425 703 8835 1470 Email: dthaler@microsoft.com 1472 Mohit Talwar 1473 Microsoft Corporation 1474 One Microsoft Way 1475 Redmond, WA 98052-6399 1476 USA 1478 Phone: +1 425 705 3131 1479 Email: mohitt@microsoft.com 1481 Amit Aggarwal 1482 Microsoft Corporation 1483 One Microsoft Way 1484 Redmond, WA 98052-6399 1485 USA 1487 Phone: +1 425 706 0593 1488 Email: amitag@microsoft.com 1490 Lorenzo Vicisano 1491 Qualcomm Inc. 1492 3165 Kifer Road 1493 Santa Clara, CA 95051 1494 USA 1496 Email: vicisano@qualcomm.com 1497 Tom Pusateri 1498 !j 1499 2109 Mountain High Rd. 1500 Wake Forest, NC 27587 1501 USA 1503 Email: pusateri@bangj.com