idnits 2.17.1 draft-ietf-mboned-auto-multicast-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1375. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1359. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1365. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 20, 2006) is 6520 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 2373 (Obsoleted by RFC 3513) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Thaler 2 Internet-Draft M. Talwar 3 Expires: December 22, 2006 A. Aggarwal 4 Microsoft Corporation 5 L. Vicisano 6 Cisco Systems 7 T. Pusateri 8 !j 9 June 20, 2006 11 Automatic IP Multicast Without Explicit Tunnels (AMT) 12 draft-ietf-mboned-auto-multicast-06 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on December 22, 2006. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 Automatic Multicast Tunneling (AMT) allows multicast communication 46 amongst isolated multicast-enabled sites or hosts, attached to a 47 network which has no native multicast support. It also enables them 48 to exchange multicast traffic with the native multicast 49 infrastructure and does not require any manual configuration. AMT 50 uses an encapsulation interface so that no changes to a host stack or 51 applications are required, all protocols (not just UDP) are handled, 52 and there is no additional overhead in core routers. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 6 59 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 7 61 4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 7 62 4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.4. AMT Relay Router . . . . . . . . . . . . . . . . . . . . . 7 64 4.5. AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 8 65 4.6. AMT Relay Anycast Address . . . . . . . . . . . . . . . . 8 66 4.7. AMT Subnet Anycast Prefix . . . . . . . . . . . . . . . . 8 67 4.8. AMT Gateway Anycast Address . . . . . . . . . . . . . . . 8 68 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.1. Receiving Multicast in an AMT Site . . . . . . . . . . . . 9 70 5.1.1. Scalability Considerations . . . . . . . . . . . . . . 10 71 5.1.2. Spoofing Considerations . . . . . . . . . . . . . . . 10 72 5.1.3. Protocol Sequence for a Gateway Joining SSM 73 Receivers to a Relay . . . . . . . . . . . . . . . . . 11 74 5.2. Sourcing Multicast from an AMT site . . . . . . . . . . . 13 75 5.2.1. Supporting Site-MBone Multicast . . . . . . . . . . . 13 76 5.2.2. Supporting Site-Site Multicast . . . . . . . . . . . . 14 77 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16 78 6.1. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 16 79 6.1.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 6.1.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 16 81 6.1.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 16 82 6.2. AMT Relay Advertisement . . . . . . . . . . . . . . . . . 16 83 6.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17 84 6.2.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 17 85 6.2.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 17 86 6.2.4. Relay Address . . . . . . . . . . . . . . . . . . . . 17 87 6.3. AMT Request . . . . . . . . . . . . . . . . . . . . . . . 17 88 6.3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 18 89 6.3.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 18 90 6.3.3. Request Nonce . . . . . . . . . . . . . . . . . . . . 18 91 6.4. AMT Membership Query . . . . . . . . . . . . . . . . . . . 18 92 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 19 93 6.4.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 19 94 6.4.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 19 95 6.4.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 19 96 6.4.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 19 97 6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 20 98 6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20 100 6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20 101 6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 21 102 6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 21 103 6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 21 104 6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21 105 6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22 106 6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 22 107 7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 23 108 7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 23 109 7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 23 110 7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 24 111 7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 24 112 7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 24 113 7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 25 114 7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 26 115 7.6. Receiving AMT Membership Updates by the Gateway . . . . . 26 116 7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 26 117 8. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 28 118 8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 28 119 8.2. Receiving Relay Discovery messages sent to the Anycast 120 Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 121 8.3. Receiving Membership Updates from AMT Gateways . . . . . . 28 122 8.4. Receiving (S,G) Joins from the Native Side, for AMT 123 Sources . . . . . . . . . . . . . . . . . . . . . . . . . 29 124 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 125 9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 30 126 9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30 127 9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30 128 9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation . . . . . . . . 30 129 9.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30 130 9.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30 131 9.3. UDP Port number . . . . . . . . . . . . . . . . . . . . . 30 132 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 133 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 134 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 135 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 136 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 137 13.2. Informative References . . . . . . . . . . . . . . . . . . 34 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 139 Intellectual Property and Copyright Statements . . . . . . . . . . 38 141 1. Introduction 143 The primary goal of this document is to foster the deployment of 144 native IP multicast by enabling a potentially large number of nodes 145 to connect to the already present multicast infrastructure. 146 Therefore, the techniques discussed here should be viewed as an 147 interim solution to help in the various stages of the transition to a 148 native multicast network. 150 To allow fast deployment, the solution presented here only requires 151 small and concentrated changes to the network infrastructure, and no 152 changes at all to user applications or to the socket API of end- 153 nodes' operating systems. The protocol introduced in this 154 specification can be deployed in a few strategically-placed network 155 nodes and in user-installable software modules (pseudo device drivers 156 and/or user-mode daemons) that reside underneath the socket API of 157 end-nodes' operating systems. This mechanism is very similar to that 158 used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6 159 connectivity. 161 Effectively, AMT treats the unicast-only internetwork as a large non- 162 broadcast multi-access (NBMA) link layer, over which we require the 163 ability to multicast. To do this, multicast packets being sent to or 164 from a site must be encapsulated in unicast packets. If the group 165 has members in multiple sites, AMT encapsulation of the same 166 multicast packet will take place multiple times by necessity. 168 2. Applicability 170 AMT is not a substitute for native multicast or a statically 171 configured multicast tunnel for high traffic flow. Unicast 172 replication is required to reach multiple receivers that are not part 173 of the native multicast infrastructure. Unicast replication is also 174 required by non-native sources to different parts of the native 175 multicast infrastructure. However, this is no worse than regular 176 unicast distribution of streams and in most cases much better. 178 The following problems are addressed: 180 1. Allowing isolated sites/hosts to receive the SSM flavor of 181 multicast ([I-D.ietf-ssm-arch]). 183 2. Allowing isolated non-NAT sites/hosts to transmit the SSM flavor 184 of multicast. 186 3. Allowing isolated sites/hosts to receive general multicast (ASM 187 [RFC1112]). 189 This document does not address allowing isolated sites/hosts to 190 transmit general multicast. We expect that other solutions (e.g., 191 Tunnel Brokers, a la [RFC3053]) will be used for sites that desire 192 this capability. 194 Implementers should be aware that site administrators may have 195 configured administratively scoped multicast boundaries and a remote 196 gateway may provide a means to circumvent administrative boundaries. 197 Therefore, implementations should allow for the configuration of such 198 boundaries on relays and gateways and perform filtering as needed. 200 3. Requirements notation 202 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 203 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 204 document are to be interpreted as described in [RFC2119]. 206 4. Definitions 208 +---------------+ Internet +---------------+ 209 | AMT Site | | Native MCast | 210 | | | | 211 | +------+----+ AMT +----+----+ AMT | 212 | |AMT Gateway| Anycast |AMT Relay| Subnet | 213 | | +-----+-+ Prefix +-+-----+ | Prefix | 214 | | |AMT IF | <------------|AMT IF | |--------> | 215 | | +-----+-+ +-+-----+ | | 216 | +------+----+ +----+----+ | 217 | | | | 218 +---------------+ +---------------+ 220 4.1. AMT Pseudo-Interface 222 AMT encapsulation of multicast packets inside unicast packets occurs 223 at a point that is logically equivalent to an interface, with the 224 link layer being the unicast-only network. This point is referred to 225 as a pseudo-interface. Some implementations may treat it exactly 226 like any other interface and others may treat it like a tunnel end- 227 point. 229 4.2. AMT Gateway 231 A host, or a site gateway router, supporting an AMT Pseudo- 232 Interface. It does not have native multicast connectivity to the 233 native multicast backbone infrastructure. It is simply referred to 234 in this document as a "gateway". 236 4.3. AMT Site 238 A multicast-enabled network not connected to the multicast backbone 239 served by an AMT Gateway. It could also be a stand- alone AMT 240 Gateway. 242 4.4. AMT Relay Router 244 A multicast router configured to support transit routing between AMT 245 Sites and the native multicast backbone infrastructure. The relay 246 router has one or more interfaces connected to the native multicast 247 infrastructure, zero or more interfaces connected to the non- 248 multicast capable internetwork, and an AMT pseudo-interface. It is 249 simply referred to in this document as a "relay". 251 As with [RFC3056], we assume that normal multicast routers do not 252 want to be tunnel endpoints (especially if this results in high fan 253 out), and similarly that service providers do not want encapsulation 254 to arbitrary routers. Instead, we assume that special-purpose 255 routers will be deployed that are suitable for serving as relays. 257 4.5. AMT Relay Anycast Prefix 259 A well-known address prefix used to advertise (into the unicast 260 routing infrastructure) a route to an available AMT Relay Router. 261 This could also be private (i.e., not well-known) for a private 262 relay. 264 Prefixes for both IPv4 and IPv6 will be assigned in a future version 265 of this draft. 267 4.6. AMT Relay Anycast Address 269 An anycast address which is used to reach the nearest AMT Relay 270 Router. 272 This address corresponds to the setting the low-order octet of the 273 AMT Relay Anycast Prefix to 1 (for both IPv4 and IPv6). 275 4.7. AMT Subnet Anycast Prefix 277 A well-known address prefix used to advertise (into the M-RIB of the 278 native multicast-enabled infrastructure) a route to AMT Sites. This 279 prefix will be used to enable sourcing SSM traffic from an AMT 280 Gateway. 282 4.8. AMT Gateway Anycast Address 284 An anycast address in the AMT Subnet Anycast Prefix range, which is 285 used by an AMT Gateway to enable sourcing SSM traffic from local 286 applications. 288 5. Overview 290 5.1. Receiving Multicast in an AMT Site 292 Internet 293 +---------------+ +---------------+ 294 | AMT Site | 2. 3-way Membership | MBone | 295 | | Handshake | | 296 | 1. Join +---+---+ =================> +---+---+ | 297 | +---->|Gateway| | Relay | | 298 | | +---+---+ <================= +---+---+ | 299 | R-+ | 3. Receive Data | | 300 +---------------+ +---------------+ 302 AMT relays and gateways cooperate to transmit multicast traffic 303 sourced within the native multicast infrastructure to AMT sites: 304 relays receive the traffic natively and unicast-encapsulate it to 305 gateways; gateways decapsulate the traffic and possibly forward it 306 into the AMT site. 308 Each gateway has an AMT pseudo-interface that serves as a default 309 multicast route. Requests to join a multicast session are sent to 310 this interface and encapsulated to a particular relay reachable 311 across the unicast-only infrastructure. 313 Each relay has an AMT pseudo-interface too. Multicast traffic sent 314 on this interface is encapsulated to zero or more gateways that have 315 joined to the relay. The AMT recipient-list is determined for each 316 multicast session. This requires the relay to keep state for each 317 gateway which has joined a particular group or (source, group) pair. 318 Multicast packets from the native infrastructure behind the relay 319 will be sent to each gateway which has requested them. 321 All multicast packets (data and control) are encapsulated in unicast 322 packets. UDP encapsulation is used for all AMT control and data 323 packets using the IANA reserved UDP port number for AMT. 325 Each relay, plus the set of all gateways using the relay, together 326 are thought of as being on a separate logical NBMA link. This 327 implies that the AMT recipient-list is a list of "link layer" 328 addresses which are (IP address, UDP port) pairs. 330 Since the number of gateways using a relay can be quite large, and we 331 expect that most sites will not want to receive most groups, an 332 explicit-joining protocol is required for gateways to communicate 333 group membership information to a relay. The two most likely 334 candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the 335 PIM-Sparse Mode protocol [I-D.ietf-pim-sm-v2-new]. Since an AMT 336 gateway may be a host, and hosts typically do not implement routing 337 protocols, gateways will use IGMP/MLD as described in Section 7 338 below. This allows a host kernel (or a pseudo device driver) to 339 easily implement AMT gateway behavior, and obviates the relay from 340 the need to know whether a given gateway is a host or a router. From 341 the relay's perspective, all gateways are indistinguishable from 342 hosts on an NBMA leaf network. 344 5.1.1. Scalability Considerations 346 It is possible that millions of hosts will enable AMT gateway 347 functionality and so an important design goal is not to create 348 gateway state in each relay until the gateway joins a multicast 349 group. But even the requirement that a relay keep group state per 350 gateway that has joined a group introduces potential scalability 351 concerns. 353 Scalability of AMT can be achieved by adding more relays, and using 354 an appropriate relay discovery mechanism for gateways to discover 355 relays. The solution we adopt is to assign addresses in anycast 356 fashion to relays [RFC1546], [RFC2373]. However, simply sending 357 periodic membership reports to an anycast address can cause 358 duplicates. Specifically, if routing changes such that a different 359 relay receives a periodic membership report, both the new and old 360 relays will encapsulate data to the AMT site until the old relay's 361 state times out. This is obviously undesirable. Instead, we use the 362 anycast address merely to find the unicast address of a relay to 363 which membership reports are sent. 365 Since adding another relay has the result of adding another 366 independent NBMA link, this allows the gateways to be spread out 367 among more relays so as to keep the number of gateways per relay at a 368 reasonable level. 370 5.1.2. Spoofing Considerations 372 An attacker could affect the group state in the relay or gateway by 373 spoofing the source address in the join or leave reports. This can 374 be used to launch reflection or denial of service attacks on the 375 target. Such attacks can be mitigated by using a three way handshake 376 between the gateway and the relay for each multicast membership 377 report or leave. 379 When a gateway or relay wants to send a membership report, it first 380 sends an AMT Request with a request nonce in it. The receiving side 381 (the respondent) can calculate a message authentication code (MAC) 382 based on (for example) the source IP address of the Request, the 383 source UDP port, the request nonce, and a secret key known only to 384 the respondent. The algorithm and the input used to calculate the 385 MAC does not have to be standardized since the respondent generates 386 and verifies the MAC and the originator simply echoes it. 388 An AMT Membership Query is sent back including the request nonce and 389 the MAC to the originator of the Request. The originator then sends 390 the IGMP/MLD Membership/Listener Report or Leave/Done (including the 391 IP Header) along with the request nonce and the received MAC back to 392 the respondent finalizing the 3-way handshake. 394 Upon reception, the respondent can recalculate the MAC based on the 395 source IP address, the source UDP port, the request nonce, and the 396 local secret. The IGMP/MLD message is only accepted if the received 397 MAC matches the calculated MAC. 399 The local secret never has to be shared with the other side. It is 400 only used to verify return routability of the originator. 402 5.1.3. Protocol Sequence for a Gateway Joining SSM Receivers to a Relay 404 This description assumes the Gateway can be a host joining as a 405 receiver or a network device acting as a Gateway when a directly 406 connected host joins as a receiver. 408 o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1). 410 o Gateway receives report has no tunnel state with a Relay so it 411 originates an AMT Relay Discovery message addressed to the Anycast 412 Relay IP address. 414 o The closest Relay topologically receives the AMT Relay Discovery 415 message and returns the nonce from the Discovery in an AMT Relay 416 Advertisement message so the Gateway can learn of the Relay's 417 unique IP address. 419 o When the Gateway receives the AMT Relay Advertisement message, it 420 now has an address to use for all subsequent (S,G) entries it will 421 join on behalf of attached receivers (or itself). 423 o The Gateway now sends an AMT Request message to the Relay's unique 424 IP address to begin the process of joining the (S,G). 426 o The Relay responds to the AMT Request message by returning the 427 nonce from the Request in a AMT Query message. The Query message 428 contains an IGMP/MLD QUERY indicating how often the Gateway should 429 repeat AMT Request messages so the (S,G) state can stay refreshed 430 in the Relay. The Query message also includes an opaque security 431 code which is generated locally (with no external coordination). 433 o When the Gateway receives the AMT Query message it responds by 434 copying the security code from the AMT Query message into a AMT 435 Membership Update message. In the Update message contains (S1,G1) 436 in an IGMPv3/MLDv2 formatted packet with an IP header. The nonce 437 from the AMT Request is also included in the AMT Membership Update 438 message. 440 o When the Relay receives the AMT Membership Update, it will add the 441 tunnel to the Gateway in it's outgoing interface list for it's 442 (S1,G1) entry stored in the multicast routing table. If the 443 (S1,G1) entry was created do to this interaction, the multicast 444 routing protocol running on the Relay will trigger a Join message 445 towards source S1 to build a native multicast tree in the native 446 multicast infrastructure. 448 o As packets are sent from the host S1, they will travel natively 449 down the multicast tree associated with (S1,G1) in the native 450 multicast infrastructure to the Relay. The Relay will replicate 451 to all interfaces in it's outgoing interface list as well as the 452 tunnel outgoing interface, which is encapsulated in a unicast AMT 453 Multicast Data message. 455 o When the Gateway receives the AMT Multicast Data message, it will 456 accept the packet since it was received over the pseudo-interface 457 associated with the tunnel to the Relay it had attached to, and 458 forward the packet to the outgoing interfaces joined by any 459 attached receiver hosts (or deliver the packet to the application 460 when the Gateway is the receiver). 462 o If later (S2,G2) is joined by a receiver, a 3-way handshake of 463 Request/ Query/Update occurs for this entry. The Discovery/ 464 Advertisement exchange is not required. 466 o To keep the state for (S1,G1) and (S2,G2) alive in the Relay, the 467 Gateway will send periodic AMT Request messages which cause Query 468 messages to be returned. And in response to the Query message all 469 joined state in the Gateway is packed in the fewest number of AMT 470 Membership Update messages. 472 o When the Gateway leaves all (S,G) entries, the Relay can free 473 resources associated with the tunnel. It is assumed that when the 474 Gateway would want to join an (S,G) again, it would start the 475 Discovery/Advertisement tunnel establishment process over again. 477 This same procedure would be used for receivers who operate in Any- 478 Source Multicast (ASM) mode. 480 5.2. Sourcing Multicast from an AMT site 482 Two cases are discussed below: multicast traffic sourced in an AMT 483 site and received in the MBone, and multicast traffic sourced in an 484 AMT site and received in another AMT site. 486 In both cases only SSM sources are supported. Furthermore this 487 specification only deals with the source residing directly in the 488 gateway. To enable a generic node in an AMT site to source 489 multicast, additional coordination between the gateway and the 490 source-node is required. 492 The gateway SHOULD allow for filtering link-local and site-local 493 traffic. 495 The general mechanism used to join towards AMT sources is based on 496 the following: 498 1. Applications residing in the gateway use addresses in the AMT 499 Subnet Anycast Prefix to send multicast, as a result of sourcing 500 traffic on the AMT pseudo-interface. 502 2. The AMT Subnet Anycast Prefix is advertised for RPF reachability 503 in the M-RIB by relays and gateways. 505 3. Relays or gateways that receive a join for a source/group pair 506 use information encoded in the address pair to rebuild the 507 address of the gateway (source) to which to encapsulate the join 508 (see Section 7.2 for more details). The membership reports use 509 the same three way handshake as outlined in Section 5.1.2 511 5.2.1. Supporting Site-MBone Multicast 513 Internet 514 +---------------+ +---------------+ 515 | AMT Site | 2. 3-way Membership | MBone | 516 | | Handshake | | 517 | +---+---+ <================= +---+---+ 1. Join | 518 | |Gateway| | Relay |<-----+ | 519 | +---+---+ =================> +---+---+ | | 520 | | 3. Receive Data | +-R | 521 +---------------+ +---------------+ 523 If a relay receives an explicit join from the native infrastructure, 524 for a given (source, group) pair where the source address belongs to 525 the AMT Subnet Anycast Prefix, then the relay will periodically 526 (using the rules specified in Section 5.1.2) encapsulate membership 527 updates for the group to the gateway. The gateway must keep state 528 per relay from which membership reports have been sent, and forward 529 multicast traffic from the site to all relays from which membership 530 reports have been received. The choice of whether this state and 531 replication is done at the link-layer (i.e., by the tunnel interface) 532 or at the network-layer is implementation dependent. 534 If there are multiple relays present, this ensures that data from the 535 AMT site is received via the closest relay to the receiver. This is 536 necessary when the routers in the native multicast infrastructure 537 employ Reverse-Path Forwarding (RPF) checks against the source 538 address, such as occurs when PIM Sparse-Mode [I-D.ietf-pim-sm-v2-new] 539 is used by the multicast infrastructure. 541 The solution above will scale to an arbitrary number of relays, as 542 long at the number of relays requiring multicast traffic from a given 543 AMT site remains reasonable enough to not overly burden the site's 544 gateway. 546 A source at or behind an AMT gateway requires the gateway to do the 547 replication to one or more relays and receiving gateways. If this 548 places too much of a burden on the sourcing gateway, the source 549 should join the native multicast infrastructure through a permanent 550 tunnel so that replication occurs within the native multicast 551 infrastructure. 553 5.2.2. Supporting Site-Site Multicast 555 Internet 556 +---------------+ +---------------+ 557 | AMT Site | 2. 3-way Membership | AMT Site | 558 | | Handshake | | 559 | +---+---+ <================= +---+---+ 1. Join | 560 | |Gateway| |Gateway|<-----+ | 561 | +---+---+ =================> +---+---+ | | 562 | | 3. Receive Data | +-R | 563 +---------------+ +---------------+ 565 Since we require gateways to accept membership reports, as described 566 above, it is also possible to support multicast among AMT sites, 567 without requiring assistance from any relays. 569 When a gateway wants to join a given (source, group) pair, where the 570 source address belongs to the AMT Subnet Anycast Prefix, then the 571 gateway will periodically unicast encapsulate an IGMPv3/MLDv2 Report 572 [RFC3376], [RFC3810] (including IP Header) directly to the site 573 gateway for the source. 575 We note that this can result in a significant amount of state at a 576 site gateway sourcing multicast to a large number of other AMT sites. 577 However, it is expected that this is not unreasonable for two 578 reasons. First, the gateway does not have native multicast 579 connectivity, and as a result is likely doing unicast replication at 580 present. The amount of state is thus the same as what such a site 581 already deals with. Secondly, any site expecting to source traffic 582 to a large number of sites could get a point-to-point tunnel to the 583 native multicast infrastructure, and use that instead of AMT. 585 6. Message Formats 587 6.1. AMT Relay Discovery 589 The AMT Relay Discovery message is a UDP packet sent from the AMT 590 gateway unicast address to the AMT relay anycast address to discover 591 the unicast address of an AMT relay. 593 The UDP source port is uniquely selected by the local host operating 594 system. The UDP destination port is the IANA reserved AMT port 595 number. The UDP checksum MUST be valid in AMT control messages. 597 The payload of the UDP packet contains the following fields. 599 0 1 2 3 600 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 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 602 | Type=0x1 | Reserved | 603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 604 | Discovery Nonce | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 Fields: 609 6.1.1. Type 611 The type of the message. 613 6.1.2. Reserved 615 A 24-bit reserved field. Sent as 0, ignored on receipt. 617 6.1.3. Discovery Nonce 619 A 32-bit random value generated by the gateway and replayed by the 620 relay. 622 6.2. AMT Relay Advertisement 624 The AMT Relay Advertisement message is a UDP packet sent from the AMT 625 relay anycast address to the source of the discovery message. 627 The UDP source port is the IANA reserved AMT port number and the UDP 628 destination port is the source port received in the Discovery 629 message. The UDP checksum MUST be valid in AMT control messages. 631 The payload of the UDP packet contains the following fields. 633 0 1 2 3 634 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 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 636 | Type=0x2 | Reserved | 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Discovery Nonce | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Relay Address | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 Fields: 645 6.2.1. Type 647 The type of the message. 649 6.2.2. Reserved 651 A 24-bit reserved field. Sent as 0, ignored on receipt. 653 6.2.3. Discovery Nonce 655 A 32-bit random value generated by the gateway and replayed by the 656 relay. 658 6.2.4. Relay Address 660 The unicast IPv4 or IPv6 address of the AMT relay. The family can be 661 determined by the length of the Advertisement. 663 6.3. AMT Request 665 A Request packet is sent to begin a 3-way handshake for sending an 666 IGMP/MLD Membership/Listener Report or Leave/Done. It can be sent 667 from a gateway to a relay, from a gateway to another gateway, or from 668 a relay to a gateway. 670 It is sent from the originator's unique unicast address to the 671 respondents' unique unicast address. 673 The UDP source port is uniquely selected by the local host operating 674 system. It can be different for each Request and different from the 675 source port used in Discovery messages but does not have to be. The 676 UDP destination port is the IANA reserved AMT port number. The UDP 677 checksum MUST be valid in AMT control messages. 679 0 1 2 3 680 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 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 682 | Type=0x3 | Reserved | 683 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 | Request Nonce | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 Fields: 689 6.3.1. Type 691 The type of the message. 693 6.3.2. Reserved 695 A 24-bit reserved field. Sent as 0, ignored on receipt. 697 6.3.3. Request Nonce 699 A 32-bit identifier used to distinguish this request. 701 6.4. AMT Membership Query 703 An AMT Membership Query packet is sent from the respondent back to 704 the originator to solicit an AMT Membership Update while confirming 705 the source of the original request. It contains a relay Message 706 Authentication Code (MAC) that is a cryptographic hash of a private 707 secret, the originators address, and the request nonce. 709 It is sent from the destination address received in the Request to 710 the source address received in the Request which is the same address 711 used in the Relay Advertisement. 713 The UDP source port is the IANA reserved AMT port number and the UDP 714 destination port is the source port received in the Request message. 715 The UDP checksum MUST be valid in AMT control messages. 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Type=0x4 | Reserved | Response MAC | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | Response MAC (continued) | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | Request Nonce | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | IGMP Membership Query or MLD Listener Query | 727 | (including IP Header) | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | ... | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 732 Fields: 734 6.4.1. Type 736 The type of the message. 738 6.4.2. Reserved 740 A 8-bit reserved field. Sent as 0, ignored on receipt. 742 6.4.3. Response MAC 744 A 48-bit hash generated by the respondent and sent to the originator 745 for inclusion in the AMT Membership Update. The algorithm used for 746 this is chosen by the respondent. One algorithm that could be used 747 is HMAC-MD5-48 [RFC2104]. 749 6.4.4. Request Nonce 751 A 32-bit identifier used to distinguish this request echoed back to 752 the originator. 754 6.4.5. IGMP/MLD Query (including IP Header) 756 The message contains either an IGMP Query or an MLD Multicast 757 Listener Query. The IGMP or MLD version sent should default to 758 IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1. 759 The IGMP/MLD Query includes a full IP Header. The IP source address 760 of the query would match the anycast address on the pseudo interface. 761 The TTL of the outer header should be sufficient to reach the tunnel 762 endpoint and not mimic the inner header TTL which is typically 1 for 763 IGMP/MLD messages. 765 6.5. AMT Membership Update 767 An AMT Membership Update is sent in response to a previously received 768 AMT Query message. It contains the original IGMP/MLD Membership/ 769 Listener Report or Leave/Done received over the AMT pseudo-interface 770 including the original IP header. It echoes the Response MAC 771 received in the AMT Membership Query so the respondent can verify 772 return routability to the originator. 774 It is sent from the destination address received in the Query to the 775 source address received in the Query which should both be the same as 776 the original Request. 778 The UDP source and destination port numbers should be the same ones 779 sent in the original Request. 781 The relay is not required to use the IP source address of the IGMP 782 Membership Report for any particular purpose. 784 0 1 2 3 785 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 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 787 | Type=0x5 | Reserved | Response MAC | 788 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 789 | Response MAC (continued) | 790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 | Request Nonce | 792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 793 | IGMP or MLD Message (including IP header) | 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | ... | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 Fields: 800 6.5.1. Type 802 The type of the message. 804 6.5.2. Reserved 806 A 8-bit reserved field. Sent as 0, ignored on receipt. 808 6.5.3. Response MAC 810 The 48-bit MAC received in the Membership Query and echoed back in 811 the Membership Update. 813 6.5.4. Request Nonce 815 A 32-bit identifier used to distinguish this request. 817 6.5.5. IGMP/MLD Message (including IP Header) 819 The message contains either an IGMP Membership Report, an IGMP 820 Membership Leave, an MLD Multicast Listener Report, or an MLD 821 Listener Done. The IGMP or MLD version sent should be in response 822 the version of the query received in the AMT Membership Query. The 823 IGMP/MLD Message includes a full IP Header. 825 6.6. AMT IP Multicast Data 827 The AMT Data message is a UDP packet encapsulating the IP Multicast 828 data requested by the originator based on a previous AMT Membership 829 Update message. 831 It is sent from the unicast destination address of the Membership 832 update to the source address of the Membership Update. 834 The UDP source and destination port numbers should be the same ones 835 sent in the original Query. The UDP checksum SHOULD be 0 in the AMT 836 IP Multicast Data message. 838 The payload of the UDP packet contains the following fields. 840 0 1 2 3 841 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 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | Type=0x6 | Reserved | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | IP Multicast Data | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | ... | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 Fields: 852 6.6.1. Type 854 The type of the message. 856 6.6.2. Reserved 858 A 24-bit reserved field. Sent as 0, ignored on receipt. 860 6.6.3. IP Multicast Data 862 The original IP Multicast data packet that is being replicated by the 863 relay to the gateways including the original IP header. 865 7. AMT Gateway Details 867 This section details the behavior of an AMT Gateway, which may be a 868 router serving an AMT site, or the site may consist of a single host, 869 serving as its own gateway. 871 7.1. At Startup Time 873 At startup time, the AMT gateway will bring up an AMT pseudo- 874 interface, to be used for encapsulation. The gateway will then send 875 an AMT Relay Discovery message to the AMT Relay Anycast Address, and 876 note the unicast address (which is treated as a link-layer address to 877 the encapsulation interface) from the AMT Relay Advertisement 878 message. This discovery SHOULD be done periodically (e.g., once a 879 day) to re-resolve the unicast address of a close relay. The gateway 880 also SHOULD initialize a timer used to send periodic membership 881 reports to a random value from the interval [0, [Query Interval]] 882 before sending the first periodic report, in order to prevent startup 883 synchronization (e.g., after a power outage). 885 If the gateway is serving as a local router, it SHOULD also function 886 as an IGMP/MLD Proxy, as described in [I-D.ietf-magma-igmp-proxy], 887 with its IGMP/MLD host-mode interface being the AMT pseudo-interface. 888 This enables it to translate group memberships on its downstream 889 interfaces into IGMP/MLD Reports. Hosts receiving multicast packets 890 through an AMT gateway acting as a proxy should ensure that their 891 M-RIB accepts multicast packets from the AMT gateway for the sources 892 it is joining. 894 7.2. Gateway Group and Source Addresses 896 To support sourcing traffic to SSM groups by a gateway with a global 897 unicast address, the AMT Subnet Anycast Prefix is treated as the 898 subnet prefix of the AMT pseudo-interface, and an anycast address is 899 added on the interface. This anycast address is formed by 900 concatenating the AMT Subnet Anycast Prefix followed by the high bits 901 of the gateway's global unicast address. 903 The remaining bits of its global unicast address are appended to the 904 SSM prefix to create the group address and any spare bits may be 905 allocated using local policy. 907 If a gateway wants to source multicast traffic, it must select the 908 gateway source address and SSM group address in such a way that the 909 AMT relay can have enough information to reconstruct the gateway's 910 unicast address when it receives an SSM join for the source. 912 Note that multiple gateways might end up with the same anycast 913 address assigned to their pseudo-interfaces. 915 7.2.1. IPv4 917 For example, if IANA assigns the IPv4 prefix x.y/16 as the AMT Subnet 918 Anycast Prefix, and the gateway has global unicast address a.b.c.d, 919 then the AMT Gateway's Anycast Source Address will be x.y.a.b. Since 920 the IPv4 SSM group range is 232/8, it MUST allocate IPv4 SSM groups 921 in the range 232.c.d/24. 923 Group: 924 8 16 8 925 +------------+------------------------+-------------+ 926 | SSM prefix | Low 16 bits of | Local | 927 | 232/8 | real source address | Policy | 928 +------------+------------------------+-------------+ 930 Source: 931 +-------------------------+-------------------------+ 932 |16-bit AMT unicast prefix| high 16 bits of real src| 933 +-------------------------+-------------------------+ 935 This allows for 2^8 (256) IPv4 group addresses for use by each AMT 936 gateway. An allocation of a prefix with length 18 would allow for 937 2^6 (64) IPv4 group addresses. 939 7.2.2. IPv6 941 Similarly for IPv6, this is illustrated in the following figure. 943 Group: 944 32 64 32 945 +------------+------------------------+-------------+ 946 | SSM prefix | Low 64 bits of | Local | 947 | FF3x::/32 | real source address | Policy | 948 +------------+------------------------+-------------+ 950 Source: 951 +-------------------------+-------------------------+ 952 |64-bit AMT unicast prefix| high 64 bits of real src| 953 +-------------------------+-------------------------+ 955 This allows for 2^32 (over 4 billion) IPv6 group addresses for use by 956 each AMT gateway. 958 7.3. Joining Groups with MBone Sources 960 The IGMP/MLD protocol usually operates by having the Querier 961 multicast an IGMP/MLD Query message on the link. This behavior does 962 not work on NBMA links which do not support multicast. Since the set 963 of gateways is typically unknown to the relay (and potentially quite 964 large), unicasting the queries is also impractical. The following 965 behavior is used instead. 967 Applications residing in a gateway should join groups on the AMT 968 pseudo-interface, causing IGMP/MLD Membership/Listener Reports to be 969 sent over that interface. When UDP encapsulating the membership 970 reports (and in fact any other messages, unless specified otherwise 971 in this document), the destination address in the outer IP header is 972 the relay's unicast address. Robustness is provided by the 973 underlying IGMP/MLD protocol messages sent on the AMT pseudo- 974 interface. In other words, the gateway does not need to retransmit 975 IGMP/MLD Membership/Listener Reports and Leave/Done messages received 976 on the pseudo-interface since IGMP/MLD will already do this. The 977 gateway simply needs to encapsulate each IGMP/MLD Membership/Listener 978 Report and Leave/Done message it receives. 980 However, since periodic IGMP/MLD Membership/Listener Reports are sent 981 in response to IGMP/MLD Queries, some mechanism to trigger periodic 982 Membership/Listener Reports and Leave/Done messages are necessary. 983 This can be achieved in any implementation-specific manner. Some 984 possibilities include: 986 1. The AMT pseudo-interface might periodically manufacture IGMPv3/ 987 MLDv2 Queries as if they had been received from an IGMP/MLD 988 Querier, and deliver them to the IP layer, after which normal 989 IGMP/MLD behavior will cause the appropriate reports to be sent. 991 2. The IGMP/MLD module itself might provide an option to operate in 992 periodic mode on specific interfaces. 994 The Querier's Robustness Variable (QRV) defined in [RFC3376] and 995 [RFC3810] can be used to adjust the number of Membership/Listener 996 Reports that are sent by the host joining the group. 998 If the gateway is behind a firewall device, the firewall may require 999 the gateway to periodically refresh the UDP state in the firewall at 1000 a shorter interval than the standard IGMP/MLD Query interval. 1001 Therefore, this IGMP/MLD Query interval should be configurable to 1002 ensure the firewall does not revert to blocking the UDP encapsulated 1003 IP Multicast data packets. 1005 7.4. Responding to Relay Changes 1007 When a gateway determines that its current relay is unreachable 1008 (e.g., upon receipt of an ICMP Unreachable message [RFC0792] for the 1009 relay's unicast address), it may need to repeat relay address 1010 discovery. However, care should be taken not to abandon the current 1011 relay too quickly due to transient network conditions. 1013 7.5. Joining SSM Groups with AMT Gateway Sources 1015 An IGMPv3/MLDv2 Report for a given (source, group) pair MAY be 1016 encapsulated directly to the source, when the source address belongs 1017 to the AMT Subnet Anycast Prefix. 1019 The "link-layer" address to use as the destination address in the 1020 outer IP header is obtained as follows. The source address in the 1021 inclusion list of the IGMPv3/MLDv2 report will be an AMT Gateway 1022 Anycast Address with the high bits of the address, and the remaining 1023 bits will be in the middle of the group address. 1025 Section 7.2 describes this format to recover the gateway source 1026 address. 1028 7.6. Receiving AMT Membership Updates by the Gateway 1030 When an AMT Request is received by the gateway from another gateway 1031 or relay, it follows the same 3-way handshake procedure a relay would 1032 follow if it received the AMT Request. It generates a MAC and 1033 responds with an AMT Membership Query. When the AMT Membership 1034 Update is received, it verifies the MAC and then processes the IGMP/ 1035 MLD Membership/Listener Report or Leave/Done. 1037 At the gateway, the IGMP/MLD packet should be an IGMPv3/MLDv2 source 1038 specific (S,G) join or leave. 1040 If S is not the AMT Gateway Anycast Address, the packet is silently 1041 discarded. If G does not contain the low bits of the global unicast 1042 address (as described above), the packet is also silently discarded. 1044 The gateway adds the source address (from the outer IP header) and 1045 UDP port of the report to a membership list for G. Maintaining this 1046 membership list may be done in any implementation-dependent manner. 1047 For example, it might be maintained by the "link-layer" inside the 1048 AMT pseudo-interface, making it invisible to the normal IGMP/MLD 1049 module. 1051 7.7. Sending data to SSM groups 1053 When multicast packets are sent on the AMT pseudo-interface, they are 1054 encapsulated as follows. If the group address is not an SSM group, 1055 then the packet is silently discarded (this memo does not currently 1056 provide a way to send to non-SSM groups). 1058 If the group address is an SSM group, then the packet is unicast 1059 encapsulated to each remote node from which the gateway has received 1060 an IGMPv3/MLDv2 report for the packet's (source, group) pair. 1062 8. Relay Router Details 1064 8.1. At Startup time 1066 At startup time, the relay router will bring up an NBMA-style AMT 1067 pseudo-interface. It shall also add the AMT Relay Anycast Address on 1068 some interface. 1070 The relay router shall then advertise the AMT Relay Anycast Prefix 1071 into the unicast-only Internet, as if it were a connection to an 1072 external network. When the advertisement is done using BGP, the AS 1073 path leading to the AMT Relay Anycast Prefix shall include the 1074 identifier of the local AS. 1076 The relay router shall also enable IGMPv3/MLDv2 on the AMT pseudo- 1077 interface, except that it shall not multicast Queries (this might be 1078 done, for example, by having the AMT pseudo-device drop them, or by 1079 having the IGMP/MLD module not send them in the first place). 1081 Finally, to support sourcing SSM traffic from AMT sites, the AMT 1082 Subnet Anycast Prefix is assigned to the AMT pseudo-interface, and 1083 the AMT Subnet Anycast Prefix is injected by the AMT Relay into the 1084 M-RIB of MBGP. 1086 8.2. Receiving Relay Discovery messages sent to the Anycast Address 1088 When a relay receives an AMT Relay Discovery message directed to the 1089 AMT Relay Anycast Address, it should respond with an AMT Relay 1090 Advertisement containing its unicast address. The source and 1091 destination addresses of the advertisement should be the same as the 1092 destination and source addresses of the discovery message 1093 respectively. Further, the nonce in the discovery message MUST be 1094 copied into the advertisement message. 1096 8.3. Receiving Membership Updates from AMT Gateways 1098 The relay operates passively, sending no periodic IGMP/MLD Queries 1099 but simply tracking membership information according to AMT Request/ 1100 Query/Membership Update tuples received. In addition, the relay must 1101 also do explicit membership tracking, as to which gateways on the AMT 1102 pseudo-interface have joined which groups. Once an AMT Membership 1103 Update has been successfully received, it updates the forwarding 1104 state for the appropriate group and source (if provided). When data 1105 arrives for that group, the traffic must be encapsulated to each 1106 gateway which has joined that group or (S,G). 1108 The explicit membership tracking and unicast replication may be done 1109 in any implementation-specific manner. Some examples are: 1111 1. The AMT pseudo-device driver might track the group information 1112 and perform the replication at the "link-layer", with no changes 1113 to a pre-existing IGMP/MLD module. 1115 2. The IGMP/MLD module might have native support for explicit 1116 membership tracking, especially if it supports other NBMA-style 1117 interfaces. 1119 If a relay wants to affect the rate at which the AMT Requests are 1120 originated from a gateway, it can tune the membership timeout by 1121 adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/ 1122 MLD Query contained within the AMT Membership Query message. The 1123 QQIC field is defined in [RFC3376] and [RFC3810]. 1125 8.4. Receiving (S,G) Joins from the Native Side, for AMT Sources 1127 The relay sends an IGMPv3/MLDv2 report to the AMT source as described 1128 above in Section 5.1.2 1130 9. IANA Considerations 1132 9.1. IPv4 and IPv6 Anycast Prefix Allocation 1134 The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated 1135 to the public AMT Relays to advertise to the native multicast 1136 backbone. The prefix length should be determined by the IANA; the 1137 prefix should be large enough to guarantee advertisement in the 1138 default-free BGP networks. 1140 9.1.1. IPv4 1142 A prefix length of 18 will meet this requirement. 1144 9.1.2. IPv6 1146 A prefix length of 32 will meet this requirement. IANA has 1147 previously set aside the range 2001::/16 for allocating prefixes for 1148 this purpose. 1150 9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation 1152 It should also be noted that this prefix length directly affects the 1153 number of groups available to be created by the AMT gateway: in the 1154 IPv4 case, a prefix length of 16 gives 256 groups, and a prefix 1155 length of 8 gives 65536 groups. 1157 9.2.1. IPv4 1159 As described above in Section 7.2.1 an IPv4 prefix with a length of 1160 18 is requested for this purpose. 1162 9.2.2. IPv6 1164 As described above in Section 7.2.2 an IPv6 prefix with a length of 1165 48 is requested. 1167 9.3. UDP Port number 1169 IANA has previously allocated UDP reserved port number 2268 for AMT 1170 encapsulation. 1172 All allocations are a one time effort and there will be no need for 1173 any recurring assignment after this stage. 1175 10. Security Considerations 1177 The anycast technique introduces a risk that a rogue router or a 1178 rogue AS could introduce a bogus route to the AMT Relay Anycast 1179 prefix, and thus divert the traffic. Network managers have to 1180 guarantee the integrity of their routing to the AMT Relay Anycast 1181 prefix in much the same way that they guarantee the integrity of all 1182 other routes. 1184 Within the native MBGP infrastructure, there is a risk that a rogue 1185 router or a rogue AS could inject a false route to the AMT Subnet 1186 Anycast Prefix, and thus divert joins and cause RPF failures of 1187 multicast traffic. As the AMT Subnet Anycast Prefix will be 1188 advertised by multiple entities, guaranteeing the integrity of this 1189 shared MBGP prefix is much more challenging than verifying the 1190 correctness of a regular unicast advertisement. To mitigate this 1191 threat, routing operators should configure the BGP sessions to filter 1192 out any more specific advertisements for the AMT Subnet Anycast 1193 Prefix. 1195 Gateways and relays will accept and decapsulate multicast traffic 1196 from any source from which regular unicast traffic is accepted. If 1197 this is for any reason felt to be a security risk, then additional 1198 source address based packet filtering MUST be applied: 1200 1. To prevent a rogue sender (that can't do traditional spoofing 1201 because of e.g. access lists deployed by its ISP) from making use 1202 of AMT to send packets to an SSM tree, a relay that receives an 1203 encapsulated multicast packet MUST discard the multicast packet 1204 if the IP source address in the outer header does not match the 1205 source address that would be extracted using the rules of 1206 Section 7.2. 1208 2. A gateway MUST discard encapsulated multicast packets if the 1209 source address in the outer header is not the address to which 1210 the encapsulated join message was sent. An AMT Gateway that 1211 receives an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard the 1212 message if the IP destination address in the outer header does 1213 not match the source address that would be extracted using the 1214 rules of Section 7.2. 1216 11. Contributors 1218 The following people provided significant contributions to earlier 1219 versions of this draft. 1221 Dirk Ooms 1222 OneSparrow 1223 Belegstraat 13; 2018 Antwerp; Belgium 1224 EMail: dirk@onesparrow.com 1226 12. Acknowledgments 1228 Most of the mechanisms described in this document are based on 1229 similar work done by the NGTrans WG for obtaining automatic IPv6 1230 connectivity without explicit tunnels ("6to4"). Tony Ballardie 1231 provided helpful discussion that inspired this document. 1233 In addition, extensive comments were received from Pekka Savola, Greg 1234 Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John 1235 Zwiebel, and Lenny Giuliano. 1237 Juniper Networks was instrumental in funding several versions of this 1238 draft as well as an open source implementation. 1240 13. References 1242 13.1. Normative References 1244 [I-D.ietf-magma-igmp-proxy] 1245 Fenner, B., He, H., Haberman, B., and H. Sandick, "IGMP/ 1246 MLD-based Multicast Forwarding ('IGMP/MLD Proxying')", 1247 draft-ietf-magma-igmp-proxy-06 (work in progress), 1248 April 2004. 1250 [I-D.ietf-ssm-arch] 1251 Holbrook, H. and B. Cain, "Source-Specific Multicast for 1252 IP", draft-ietf-ssm-arch-07 (work in progress), 1253 October 2005. 1255 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1256 RFC 792, September 1981. 1258 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1259 Thyagarajan, "Internet Group Management Protocol, Version 1260 3", RFC 3376, October 2002. 1262 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1263 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1265 13.2. Informative References 1267 [I-D.ietf-pim-sm-v2-new] 1268 Fenner, B., "Protocol Independent Multicast - Sparse Mode 1269 (PIM-SM): Protocol Specification (Revised)", 1270 draft-ietf-pim-sm-v2-new-12 (work in progress), 1271 March 2006. 1273 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1274 RFC 1112, August 1989. 1276 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 1277 Anycasting Service", RFC 1546, November 1993. 1279 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1280 Hashing for Message Authentication", RFC 2104, 1281 February 1997. 1283 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1284 Requirement Levels", BCP 14, RFC 2119, March 1997. 1286 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 1287 Architecture", RFC 2373, July 1998. 1289 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 1290 Tunnel Broker", RFC 3053, January 2001. 1292 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1293 via IPv4 Clouds", RFC 3056, February 2001. 1295 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1296 RFC 3068, June 2001. 1298 Authors' Addresses 1300 Dave Thaler 1301 Microsoft Corporation 1302 One Microsoft Way 1303 Redmond, WA 98052-6399 1304 USA 1306 Phone: +1 425 703 8835 1307 Email: dthaler@microsoft.com 1309 Mohit Talwar 1310 Microsoft Corporation 1311 One Microsoft Way 1312 Redmond, WA 98052-6399 1313 USA 1315 Phone: +1 425 705 3131 1316 Email: mohitt@microsoft.com 1318 Amit Aggarwal 1319 Microsoft Corporation 1320 One Microsoft Way 1321 Redmond, WA 98052-6399 1322 USA 1324 Phone: +1 425 706 0593 1325 Email: amitag@microsoft.com 1327 Lorenzo Vicisano 1328 Cisco Systems 1329 170 West Tasman Dr. 1330 San Jose, CA 95134 1331 USA 1333 Phone: +1 408 525 2530 1334 Email: lorenzo@cisco.com 1335 Tom Pusateri 1336 !j 1337 222 E. Jones Ave. 1338 Wake Forest, NC 27587 1339 USA 1341 Email: pusateri@bangj.com 1343 Intellectual Property Statement 1345 The IETF takes no position regarding the validity or scope of any 1346 Intellectual Property Rights or other rights that might be claimed to 1347 pertain to the implementation or use of the technology described in 1348 this document or the extent to which any license under such rights 1349 might or might not be available; nor does it represent that it has 1350 made any independent effort to identify any such rights. Information 1351 on the procedures with respect to rights in RFC documents can be 1352 found in BCP 78 and BCP 79. 1354 Copies of IPR disclosures made to the IETF Secretariat and any 1355 assurances of licenses to be made available, or the result of an 1356 attempt made to obtain a general license or permission for the use of 1357 such proprietary rights by implementers or users of this 1358 specification can be obtained from the IETF on-line IPR repository at 1359 http://www.ietf.org/ipr. 1361 The IETF invites any interested party to bring to its attention any 1362 copyrights, patents or patent applications, or other proprietary 1363 rights that may cover technology that may be required to implement 1364 this standard. Please address the information to the IETF at 1365 ietf-ipr@ietf.org. 1367 Disclaimer of Validity 1369 This document and the information contained herein are provided on an 1370 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1371 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1372 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1373 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1374 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1375 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1377 Copyright Statement 1379 Copyright (C) The Internet Society (2006). This document is subject 1380 to the rights, licenses and restrictions contained in BCP 78, and 1381 except as set forth therein, the authors retain all their rights. 1383 Acknowledgment 1385 Funding for the RFC Editor function is currently provided by the 1386 Internet Society.