idnits 2.17.1 draft-ietf-mboned-auto-multicast-07.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1368. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1345. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1358. ** 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 (November 16, 2006) is 6370 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) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 10 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 Expires: May 20, 2007 A. Aggarwal 5 Microsoft Corporation 6 L. Vicisano 7 Cisco Systems 8 T. Pusateri 9 !j 10 November 16, 2006 12 Automatic IP Multicast Without Explicit Tunnels (AMT) 13 draft-ietf-mboned-auto-multicast-07 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on May 20, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 Automatic Multicast Tunneling (AMT) allows multicast communication 47 amongst isolated multicast-enabled sites or hosts, attached to a 48 network which has no native multicast support. It also enables them 49 to exchange multicast traffic with the native multicast 50 infrastructure and does not require any manual configuration. AMT 51 uses an encapsulation interface so that no changes to a host stack or 52 applications are required, all protocols (not just UDP) are handled, 53 and there is no additional overhead in core routers. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 6 60 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 7 62 4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.4. AMT Relay Router . . . . . . . . . . . . . . . . . . . . . 7 65 4.5. AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 8 66 4.6. AMT Relay Anycast Address . . . . . . . . . . . . . . . . 8 67 4.7. AMT Subnet Anycast Prefix . . . . . . . . . . . . . . . . 8 68 4.8. AMT Gateway Anycast Address . . . . . . . . . . . . . . . 8 69 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 5.1. Receiving Multicast in an AMT Site . . . . . . . . . . . . 9 71 5.1.1. Scalability Considerations . . . . . . . . . . . . . . 10 72 5.1.2. Spoofing Considerations . . . . . . . . . . . . . . . 10 73 5.1.3. Protocol Sequence for a Gateway Joining SSM 74 Receivers to a Relay . . . . . . . . . . . . . . . . . 11 75 5.2. Sourcing Multicast from an AMT site . . . . . . . . . . . 13 76 5.2.1. Supporting Site-MBone Multicast . . . . . . . . . . . 13 77 5.2.2. Supporting Site-Site Multicast . . . . . . . . . . . . 14 78 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 16 79 6.1. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 16 80 6.1.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 16 81 6.1.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 16 82 6.1.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 16 83 6.2. AMT Relay Advertisement . . . . . . . . . . . . . . . . . 16 84 6.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 6.2.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 17 86 6.2.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 17 87 6.2.4. Relay Address . . . . . . . . . . . . . . . . . . . . 17 88 6.3. AMT Request . . . . . . . . . . . . . . . . . . . . . . . 17 89 6.3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 18 90 6.3.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 18 91 6.3.3. Request Nonce . . . . . . . . . . . . . . . . . . . . 18 92 6.4. AMT Membership Query . . . . . . . . . . . . . . . . . . . 18 93 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 6.4.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 19 95 6.4.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 19 96 6.4.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 19 97 6.4.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 19 98 6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 20 99 6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20 101 6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20 102 6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 21 103 6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 21 104 6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 21 105 6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21 106 6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 21 107 6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 22 108 7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 23 109 7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 23 110 7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 23 111 7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 24 112 7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 24 113 7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 24 114 7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 25 115 7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 26 116 7.6. Receiving AMT Membership Updates by the Gateway . . . . . 26 117 7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 26 118 8. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 28 119 8.1. At Startup time . . . . . . . . . . . . . . . . . . . . . 28 120 8.2. Receiving Relay Discovery messages sent to the Anycast 121 Address . . . . . . . . . . . . . . . . . . . . . . . . . 28 122 8.3. Receiving Membership Updates from AMT Gateways . . . . . . 28 123 8.4. Receiving (S,G) Joins from the Native Side, for AMT 124 Sources . . . . . . . . . . . . . . . . . . . . . . . . . 29 125 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 126 9.1. IPv4 and IPv6 Anycast Prefix Allocation . . . . . . . . . 30 127 9.1.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30 128 9.1.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30 129 9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation . . . . . . . . 30 130 9.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 30 131 9.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 30 132 9.3. UDP Port number . . . . . . . . . . . . . . . . . . . . . 30 133 10. Security Considerations . . . . . . . . . . . . . . . . . . . 31 134 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32 135 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33 136 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 137 13.1. Normative References . . . . . . . . . . . . . . . . . . . 34 138 13.2. Informative References . . . . . . . . . . . . . . . . . . 34 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 140 Intellectual Property and Copyright Statements . . . . . . . . . . 38 142 1. Introduction 144 The primary goal of this document is to foster the deployment of 145 native IP multicast by enabling a potentially large number of nodes 146 to connect to the already present multicast infrastructure. 147 Therefore, the techniques discussed here should be viewed as an 148 interim solution to help in the various stages of the transition to a 149 native multicast network. 151 To allow fast deployment, the solution presented here only requires 152 small and concentrated changes to the network infrastructure, and no 153 changes at all to user applications or to the socket API of end- 154 nodes' operating systems. The protocol introduced in this 155 specification can be deployed in a few strategically-placed network 156 nodes and in user-installable software modules (pseudo device drivers 157 and/or user-mode daemons) that reside underneath the socket API of 158 end-nodes' operating systems. This mechanism is very similar to that 159 used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6 160 connectivity. 162 Effectively, AMT treats the unicast-only internetwork as a large non- 163 broadcast multi-access (NBMA) link layer, over which we require the 164 ability to multicast. To do this, multicast packets being sent to or 165 from a site must be encapsulated in unicast packets. If the group 166 has members in multiple sites, AMT encapsulation of the same 167 multicast packet will take place multiple times by necessity. 169 2. Applicability 171 AMT is not a substitute for native multicast or a statically 172 configured multicast tunnel for high traffic flow. Unicast 173 replication is required to reach multiple receivers that are not part 174 of the native multicast infrastructure. Unicast replication is also 175 required by non-native sources to different parts of the native 176 multicast infrastructure. However, this is no worse than regular 177 unicast distribution of streams and in most cases much better. 179 The following problems are addressed: 181 1. Allowing isolated sites/hosts to receive the SSM flavor of 182 multicast ([RFC4607]). 184 2. Allowing isolated non-NAT sites/hosts to transmit the SSM flavor 185 of multicast. 187 3. Allowing isolated sites/hosts to receive general multicast (ASM 188 [RFC1112]). 190 This document does not address allowing isolated sites/hosts to 191 transmit general multicast. We expect that other solutions (e.g., 192 Tunnel Brokers, a la [RFC3053]) will be used for sites that desire 193 this capability. 195 Implementers should be aware that site administrators may have 196 configured administratively scoped multicast boundaries and a remote 197 gateway may provide a means to circumvent administrative boundaries. 198 Therefore, implementations should allow for the configuration of such 199 boundaries on relays and gateways and perform filtering as needed. 201 3. Requirements notation 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in [RFC2119]. 207 4. Definitions 209 +---------------+ Internet +---------------+ 210 | AMT Site | | Native MCast | 211 | | | | 212 | +------+----+ AMT +----+----+ AMT | 213 | |AMT Gateway| Anycast |AMT Relay| Subnet | 214 | | +-----+-+ Prefix +-+-----+ | Prefix | 215 | | |AMT IF | <------------|AMT IF | |--------> | 216 | | +-----+-+ +-+-----+ | | 217 | +------+----+ +----+----+ | 218 | | | | 219 +---------------+ +---------------+ 221 4.1. AMT Pseudo-Interface 223 AMT encapsulation of multicast packets inside unicast packets occurs 224 at a point that is logically equivalent to an interface, with the 225 link layer being the unicast-only network. This point is referred to 226 as a pseudo-interface. Some implementations may treat it exactly 227 like any other interface and others may treat it like a tunnel end- 228 point. 230 4.2. AMT Gateway 232 A host, or a site gateway router, supporting an AMT Pseudo- 233 Interface. It does not have native multicast connectivity to the 234 native multicast backbone infrastructure. It is simply referred to 235 in this document as a "gateway". 237 4.3. AMT Site 239 A multicast-enabled network not connected to the multicast backbone 240 served by an AMT Gateway. It could also be a stand- alone AMT 241 Gateway. 243 4.4. AMT Relay Router 245 A multicast router configured to support transit routing between AMT 246 Sites and the native multicast backbone infrastructure. The relay 247 router has one or more interfaces connected to the native multicast 248 infrastructure, zero or more interfaces connected to the non- 249 multicast capable internetwork, and an AMT pseudo-interface. It is 250 simply referred to in this document as a "relay". 252 As with [RFC3056], we assume that normal multicast routers do not 253 want to be tunnel endpoints (especially if this results in high fan 254 out), and similarly that service providers do not want encapsulation 255 to arbitrary routers. Instead, we assume that special-purpose 256 routers will be deployed that are suitable for serving as relays. 258 4.5. AMT Relay Anycast Prefix 260 A well-known address prefix used to advertise (into the unicast 261 routing infrastructure) a route to an available AMT Relay Router. 262 This could also be private (i.e., not well-known) for a private 263 relay. 265 Prefixes for both IPv4 and IPv6 will be assigned in a future version 266 of this draft. 268 4.6. AMT Relay Anycast Address 270 An anycast address which is used to reach the nearest AMT Relay 271 Router. 273 This address corresponds to the setting the low-order octet of the 274 AMT Relay Anycast Prefix to 1 (for both IPv4 and IPv6). 276 4.7. AMT Subnet Anycast Prefix 278 A well-known address prefix used to advertise (into the M-RIB of the 279 native multicast-enabled infrastructure) a route to AMT Sites. This 280 prefix will be used to enable sourcing SSM traffic from an AMT 281 Gateway. 283 4.8. AMT Gateway Anycast Address 285 An anycast address in the AMT Subnet Anycast Prefix range, which is 286 used by an AMT Gateway to enable sourcing SSM traffic from local 287 applications. 289 5. Overview 291 5.1. Receiving Multicast in an AMT Site 293 Internet 294 +---------------+ +---------------+ 295 | AMT Site | 2. 3-way Membership | MBone | 296 | | Handshake | | 297 | 1. Join +---+---+ =================> +---+---+ | 298 | +---->|Gateway| | Relay | | 299 | | +---+---+ <================= +---+---+ | 300 | R-+ | 3. Receive Data | | 301 +---------------+ +---------------+ 303 AMT relays and gateways cooperate to transmit multicast traffic 304 sourced within the native multicast infrastructure to AMT sites: 305 relays receive the traffic natively and unicast-encapsulate it to 306 gateways; gateways decapsulate the traffic and possibly forward it 307 into the AMT site. 309 Each gateway has an AMT pseudo-interface that serves as a default 310 multicast route. Requests to join a multicast session are sent to 311 this interface and encapsulated to a particular relay reachable 312 across the unicast-only infrastructure. 314 Each relay has an AMT pseudo-interface too. Multicast traffic sent 315 on this interface is encapsulated to zero or more gateways that have 316 joined to the relay. The AMT recipient-list is determined for each 317 multicast session. This requires the relay to keep state for each 318 gateway which has joined a particular group or (source, group) pair. 319 Multicast packets from the native infrastructure behind the relay 320 will be sent to each gateway which has requested them. 322 All multicast packets (data and control) are encapsulated in unicast 323 packets. UDP encapsulation is used for all AMT control and data 324 packets using the IANA reserved UDP port number for AMT. 326 Each relay, plus the set of all gateways using the relay, together 327 are thought of as being on a separate logical NBMA link. This 328 implies that the AMT recipient-list is a list of "link layer" 329 addresses which are (IP address, UDP port) pairs. 331 Since the number of gateways using a relay can be quite large, and we 332 expect that most sites will not want to receive most groups, an 333 explicit-joining protocol is required for gateways to communicate 334 group membership information to a relay. The two most likely 335 candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the 336 PIM-Sparse Mode protocol [RFC4601]. Since an AMT gateway may be a 337 host, and hosts typically do not implement routing protocols, 338 gateways will use IGMP/MLD as described in Section 7 below. This 339 allows a host kernel (or a pseudo device driver) to easily implement 340 AMT gateway behavior, and obviates the relay from the need to know 341 whether a given gateway is a host or a router. From the relay's 342 perspective, all gateways are indistinguishable from hosts on an NBMA 343 leaf network. 345 5.1.1. Scalability Considerations 347 It is possible that millions of hosts will enable AMT gateway 348 functionality and so an important design goal is not to create 349 gateway state in each relay until the gateway joins a multicast 350 group. But even the requirement that a relay keep group state per 351 gateway that has joined a group introduces potential scalability 352 concerns. 354 Scalability of AMT can be achieved by adding more relays, and using 355 an appropriate relay discovery mechanism for gateways to discover 356 relays. The solution we adopt is to assign addresses in anycast 357 fashion to relays [RFC1546], [RFC2373]. However, simply sending 358 periodic membership reports to an anycast address can cause 359 duplicates. Specifically, if routing changes such that a different 360 relay receives a periodic membership report, both the new and old 361 relays will encapsulate data to the AMT site until the old relay's 362 state times out. This is obviously undesirable. Instead, we use the 363 anycast address merely to find the unicast address of a relay to 364 which membership reports are sent. 366 Since adding another relay has the result of adding another 367 independent NBMA link, this allows the gateways to be spread out 368 among more relays so as to keep the number of gateways per relay at a 369 reasonable level. 371 5.1.2. Spoofing Considerations 373 An attacker could affect the group state in the relay or gateway by 374 spoofing the source address in the join or leave reports. This can 375 be used to launch reflection or denial of service attacks on the 376 target. Such attacks can be mitigated by using a three way handshake 377 between the gateway and the relay for each multicast membership 378 report or leave. 380 When a gateway or relay wants to send a membership report, it first 381 sends an AMT Request with a request nonce in it. The receiving side 382 (the respondent) can calculate a message authentication code (MAC) 383 based on (for example) the source IP address of the Request, the 384 source UDP port, the request nonce, and a secret key known only to 385 the respondent. The algorithm and the input used to calculate the 386 MAC does not have to be standardized since the respondent generates 387 and verifies the MAC and the originator simply echoes it. 389 An AMT Membership Query is sent back including the request nonce and 390 the MAC to the originator of the Request. The originator then sends 391 the IGMP/MLD Membership/Listener Report or Leave/Done (including the 392 IP Header) along with the request nonce and the received MAC back to 393 the respondent finalizing the 3-way handshake. 395 Upon reception, the respondent can recalculate the MAC based on the 396 source IP address, the source UDP port, the request nonce, and the 397 local secret. The IGMP/MLD message is only accepted if the received 398 MAC matches the calculated MAC. 400 The local secret never has to be shared with the other side. It is 401 only used to verify return routability of the originator. 403 5.1.3. Protocol Sequence for a Gateway Joining SSM Receivers to a Relay 405 This description assumes the Gateway can be a host joining as a 406 receiver or a network device acting as a Gateway when a directly 407 connected host joins as a receiver. 409 o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1). 411 o Gateway receives report has no tunnel state with a Relay so it 412 originates an AMT Relay Discovery message addressed to the Anycast 413 Relay IP address. 415 o The closest Relay topologically receives the AMT Relay Discovery 416 message and returns the nonce from the Discovery in an AMT Relay 417 Advertisement message so the Gateway can learn of the Relay's 418 unique IP address. 420 o When the Gateway receives the AMT Relay Advertisement message, it 421 now has an address to use for all subsequent (S,G) entries it will 422 join on behalf of attached receivers (or itself). 424 o The Gateway now sends an AMT Request message to the Relay's unique 425 IP address to begin the process of joining the (S,G). 427 o The Relay responds to the AMT Request message by returning the 428 nonce from the Request in a AMT Query message. The Query message 429 contains an IGMP/MLD QUERY indicating how often the Gateway should 430 repeat AMT Request messages so the (S,G) state can stay refreshed 431 in the Relay. The Query message also includes an opaque security 432 code which is generated locally (with no external coordination). 434 o When the Gateway receives the AMT Query message it responds by 435 copying the security code from the AMT Query message into a AMT 436 Membership Update message. In the Update message contains (S1,G1) 437 in an IGMPv3/MLDv2 formatted packet with an IP header. The nonce 438 from the AMT Request is also included in the AMT Membership Update 439 message. 441 o When the Relay receives the AMT Membership Update, it will add the 442 tunnel to the Gateway in it's outgoing interface list for it's 443 (S1,G1) entry stored in the multicast routing table. If the 444 (S1,G1) entry was created do to this interaction, the multicast 445 routing protocol running on the Relay will trigger a Join message 446 towards source S1 to build a native multicast tree in the native 447 multicast infrastructure. 449 o As packets are sent from the host S1, they will travel natively 450 down the multicast tree associated with (S1,G1) in the native 451 multicast infrastructure to the Relay. The Relay will replicate 452 to all interfaces in it's outgoing interface list as well as the 453 tunnel outgoing interface, which is encapsulated in a unicast AMT 454 Multicast Data message. 456 o When the Gateway receives the AMT Multicast Data message, it will 457 accept the packet since it was received over the pseudo-interface 458 associated with the tunnel to the Relay it had attached to, and 459 forward the packet to the outgoing interfaces joined by any 460 attached receiver hosts (or deliver the packet to the application 461 when the Gateway is the receiver). 463 o If later (S2,G2) is joined by a receiver, a 3-way handshake of 464 Request/ Query/Update occurs for this entry. The Discovery/ 465 Advertisement exchange is not required. 467 o To keep the state for (S1,G1) and (S2,G2) alive in the Relay, the 468 Gateway will send periodic AMT Request messages which cause Query 469 messages to be returned. And in response to the Query message all 470 joined state in the Gateway is packed in the fewest number of AMT 471 Membership Update messages. 473 o When the Gateway leaves all (S,G) entries, the Relay can free 474 resources associated with the tunnel. It is assumed that when the 475 Gateway would want to join an (S,G) again, it would start the 476 Discovery/Advertisement tunnel establishment process over again. 478 This same procedure would be used for receivers who operate in Any- 479 Source Multicast (ASM) mode. 481 5.2. Sourcing Multicast from an AMT site 483 Two cases are discussed below: multicast traffic sourced in an AMT 484 site and received in the MBone, and multicast traffic sourced in an 485 AMT site and received in another AMT site. 487 In both cases only SSM sources are supported. Furthermore this 488 specification only deals with the source residing directly in the 489 gateway. To enable a generic node in an AMT site to source 490 multicast, additional coordination between the gateway and the 491 source-node is required. 493 The gateway SHOULD allow for filtering link-local and site-local 494 traffic. 496 The general mechanism used to join towards AMT sources is based on 497 the following: 499 1. Applications residing in the gateway use addresses in the AMT 500 Subnet Anycast Prefix to send multicast, as a result of sourcing 501 traffic on the AMT pseudo-interface. 503 2. The AMT Subnet Anycast Prefix is advertised for RPF reachability 504 in the M-RIB by relays and gateways. 506 3. Relays or gateways that receive a join for a source/group pair 507 use information encoded in the address pair to rebuild the 508 address of the gateway (source) to which to encapsulate the join 509 (see Section 7.2 for more details). The membership reports use 510 the same three way handshake as outlined in Section 5.1.2 512 5.2.1. Supporting Site-MBone Multicast 514 Internet 515 +---------------+ +---------------+ 516 | AMT Site | 2. 3-way Membership | MBone | 517 | | Handshake | | 518 | +---+---+ <================= +---+---+ 1. Join | 519 | |Gateway| | Relay |<-----+ | 520 | +---+---+ =================> +---+---+ | | 521 | | 3. Receive Data | +-R | 522 +---------------+ +---------------+ 524 If a relay receives an explicit join from the native infrastructure, 525 for a given (source, group) pair where the source address belongs to 526 the AMT Subnet Anycast Prefix, then the relay will periodically 527 (using the rules specified in Section 5.1.2) encapsulate membership 528 updates for the group to the gateway. The gateway must keep state 529 per relay from which membership reports have been sent, and forward 530 multicast traffic from the site to all relays from which membership 531 reports have been received. The choice of whether this state and 532 replication is done at the link-layer (i.e., by the tunnel interface) 533 or at the network-layer is implementation dependent. 535 If there are multiple relays present, this ensures that data from the 536 AMT site is received via the closest relay to the receiver. This is 537 necessary when the routers in the native multicast infrastructure 538 employ Reverse-Path Forwarding (RPF) checks against the source 539 address, such as occurs when PIM Sparse-Mode [RFC4601] is used by the 540 multicast infrastructure. 542 The solution above will scale to an arbitrary number of relays, as 543 long at the number of relays requiring multicast traffic from a given 544 AMT site remains reasonable enough to not overly burden the site's 545 gateway. 547 A source at or behind an AMT gateway requires the gateway to do the 548 replication to one or more relays and receiving gateways. If this 549 places too much of a burden on the sourcing gateway, the source 550 should join the native multicast infrastructure through a permanent 551 tunnel so that replication occurs within the native multicast 552 infrastructure. 554 5.2.2. Supporting Site-Site Multicast 556 Internet 557 +---------------+ +---------------+ 558 | AMT Site | 2. 3-way Membership | AMT Site | 559 | | Handshake | | 560 | +---+---+ <================= +---+---+ 1. Join | 561 | |Gateway| |Gateway|<-----+ | 562 | +---+---+ =================> +---+---+ | | 563 | | 3. Receive Data | +-R | 564 +---------------+ +---------------+ 566 Since we require gateways to accept membership reports, as described 567 above, it is also possible to support multicast among AMT sites, 568 without requiring assistance from any relays. 570 When a gateway wants to join a given (source, group) pair, where the 571 source address belongs to the AMT Subnet Anycast Prefix, then the 572 gateway will periodically unicast encapsulate an IGMPv3/MLDv2 Report 573 [RFC3376], [RFC3810] (including IP Header) directly to the site 574 gateway for the source. 576 We note that this can result in a significant amount of state at a 577 site gateway sourcing multicast to a large number of other AMT sites. 578 However, it is expected that this is not unreasonable for two 579 reasons. First, the gateway does not have native multicast 580 connectivity, and as a result is likely doing unicast replication at 581 present. The amount of state is thus the same as what such a site 582 already deals with. Secondly, any site expecting to source traffic 583 to a large number of sites could get a point-to-point tunnel to the 584 native multicast infrastructure, and use that instead of AMT. 586 6. Message Formats 588 6.1. AMT Relay Discovery 590 The AMT Relay Discovery message is a UDP packet sent from the AMT 591 gateway unicast address to the AMT relay anycast address to discover 592 the unicast address of an AMT relay. 594 The UDP source port is uniquely selected by the local host operating 595 system. The UDP destination port is the IANA reserved AMT port 596 number. The UDP checksum MUST be valid in AMT control messages. 598 The payload of the UDP packet contains the following fields. 600 0 1 2 3 601 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 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | Type=0x1 | Reserved | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | Discovery Nonce | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 Fields: 610 6.1.1. Type 612 The type of the message. 614 6.1.2. Reserved 616 A 24-bit reserved field. Sent as 0, ignored on receipt. 618 6.1.3. Discovery Nonce 620 A 32-bit random value generated by the gateway and replayed by the 621 relay. 623 6.2. AMT Relay Advertisement 625 The AMT Relay Advertisement message is a UDP packet sent from the AMT 626 relay anycast address to the source of the discovery message. 628 The UDP source port is the IANA reserved AMT port number and the UDP 629 destination port is the source port received in the Discovery 630 message. The UDP checksum MUST be valid in AMT control messages. 632 The payload of the UDP packet contains the following fields. 634 0 1 2 3 635 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 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Type=0x2 | Reserved | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Discovery Nonce | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Relay Address | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Fields: 646 6.2.1. Type 648 The type of the message. 650 6.2.2. Reserved 652 A 24-bit reserved field. Sent as 0, ignored on receipt. 654 6.2.3. Discovery Nonce 656 A 32-bit random value generated by the gateway and replayed by the 657 relay. 659 6.2.4. Relay Address 661 The unicast IPv4 or IPv6 address of the AMT relay. The family can be 662 determined by the length of the Advertisement. 664 6.3. AMT Request 666 A Request packet is sent to begin a 3-way handshake for sending an 667 IGMP/MLD Membership/Listener Report or Leave/Done. It can be sent 668 from a gateway to a relay, from a gateway to another gateway, or from 669 a relay to a gateway. 671 It is sent from the originator's unique unicast address to the 672 respondents' unique unicast address. 674 The UDP source port is uniquely selected by the local host operating 675 system. It can be different for each Request and different from the 676 source port used in Discovery messages but does not have to be. The 677 UDP destination port is the IANA reserved AMT port number. The UDP 678 checksum MUST be valid in AMT control messages. 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Type=0x3 | Reserved | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Request Nonce | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Fields: 690 6.3.1. Type 692 The type of the message. 694 6.3.2. Reserved 696 A 24-bit reserved field. Sent as 0, ignored on receipt. 698 6.3.3. Request Nonce 700 A 32-bit identifier used to distinguish this request. 702 6.4. AMT Membership Query 704 An AMT Membership Query packet is sent from the respondent back to 705 the originator to solicit an AMT Membership Update while confirming 706 the source of the original request. It contains a relay Message 707 Authentication Code (MAC) that is a cryptographic hash of a private 708 secret, the originators address, and the request nonce. 710 It is sent from the destination address received in the Request to 711 the source address received in the Request which is the same address 712 used in the Relay Advertisement. 714 The UDP source port is the IANA reserved AMT port number and the UDP 715 destination port is the source port received in the Request message. 716 The UDP checksum MUST be valid in AMT control messages. 718 0 1 2 3 719 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 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Type=0x4 | Reserved | Response MAC | 722 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 723 | Response MAC (continued) | 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 725 | Request Nonce | 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | IGMP Membership Query or MLD Listener Query | 728 | (including IP Header) | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | ... | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 Fields: 735 6.4.1. Type 737 The type of the message. 739 6.4.2. Reserved 741 A 8-bit reserved field. Sent as 0, ignored on receipt. 743 6.4.3. Response MAC 745 A 48-bit hash generated by the respondent and sent to the originator 746 for inclusion in the AMT Membership Update. The algorithm used for 747 this is chosen by the respondent. One algorithm that could be used 748 is HMAC-MD5-48 [RFC2104]. 750 6.4.4. Request Nonce 752 A 32-bit identifier used to distinguish this request echoed back to 753 the originator. 755 6.4.5. IGMP/MLD Query (including IP Header) 757 The message contains either an IGMP Query or an MLD Multicast 758 Listener Query. The IGMP or MLD version sent should default to 759 IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1. 760 The IGMP/MLD Query includes a full IP Header. The IP source address 761 of the query would match the anycast address on the pseudo interface. 762 The TTL of the outer header should be sufficient to reach the tunnel 763 endpoint and not mimic the inner header TTL which is typically 1 for 764 IGMP/MLD messages. 766 6.5. AMT Membership Update 768 An AMT Membership Update is sent in response to a previously received 769 AMT Query message. It contains the original IGMP/MLD Membership/ 770 Listener Report or Leave/Done received over the AMT pseudo-interface 771 including the original IP header. It echoes the Response MAC 772 received in the AMT Membership Query so the respondent can verify 773 return routability to the originator. 775 It is sent from the destination address received in the Query to the 776 source address received in the Query which should both be the same as 777 the original Request. 779 The UDP source and destination port numbers should be the same ones 780 sent in the original Request. 782 The relay is not required to use the IP source address of the IGMP 783 Membership Report for any particular purpose. 785 0 1 2 3 786 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 787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 | Type=0x5 | Reserved | Response MAC | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 790 | Response MAC (continued) | 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | Request Nonce | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | IGMP or MLD Message (including IP header) | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | ... | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 Fields: 801 6.5.1. Type 803 The type of the message. 805 6.5.2. Reserved 807 A 8-bit reserved field. Sent as 0, ignored on receipt. 809 6.5.3. Response MAC 811 The 48-bit MAC received in the Membership Query and echoed back in 812 the Membership Update. 814 6.5.4. Request Nonce 816 A 32-bit identifier used to distinguish this request. 818 6.5.5. IGMP/MLD Message (including IP Header) 820 The message contains either an IGMP Membership Report, an IGMP 821 Membership Leave, an MLD Multicast Listener Report, or an MLD 822 Listener Done. The IGMP or MLD version sent should be in response 823 the version of the query received in the AMT Membership Query. The 824 IGMP/MLD Message includes a full IP Header. 826 6.6. AMT IP Multicast Data 828 The AMT Data message is a UDP packet encapsulating the IP Multicast 829 data requested by the originator based on a previous AMT Membership 830 Update message. 832 It is sent from the unicast destination address of the Membership 833 update to the source address of the Membership Update. 835 The UDP source and destination port numbers should be the same ones 836 sent in the original Query. The UDP checksum SHOULD be 0 in the AMT 837 IP Multicast Data message. 839 The payload of the UDP packet contains the following fields. 841 0 1 2 3 842 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 843 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 | Type=0x6 | Reserved | IP Multicast Data ... | 845 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 846 | ... | 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 Fields: 851 6.6.1. Type 853 The type of the message. 855 6.6.2. Reserved 857 An 8-bit reserved field. Sent as 0, ignored on receipt. 859 6.6.3. IP Multicast Data 861 The original IP Multicast data packet that is being replicated by the 862 relay to the gateways including the original IP header. 864 7. AMT Gateway Details 866 This section details the behavior of an AMT Gateway, which may be a 867 router serving an AMT site, or the site may consist of a single host, 868 serving as its own gateway. 870 7.1. At Startup Time 872 At startup time, the AMT gateway will bring up an AMT pseudo- 873 interface, to be used for encapsulation. The gateway will then send 874 an AMT Relay Discovery message to the AMT Relay Anycast Address, and 875 note the unicast address (which is treated as a link-layer address to 876 the encapsulation interface) from the AMT Relay Advertisement 877 message. This discovery SHOULD be done periodically (e.g., once a 878 day) to re-resolve the unicast address of a close relay. The gateway 879 also SHOULD initialize a timer used to send periodic membership 880 reports to a random value from the interval [0, [Query Interval]] 881 before sending the first periodic report, in order to prevent startup 882 synchronization (e.g., after a power outage). 884 If the gateway is serving as a local router, it SHOULD also function 885 as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD 886 host-mode interface being the AMT pseudo-interface. This enables it 887 to translate group memberships on its downstream interfaces into 888 IGMP/MLD Reports. Hosts receiving multicast packets through an AMT 889 gateway acting as a proxy should ensure that their M-RIB accepts 890 multicast packets from the AMT gateway for the sources it is joining. 892 7.2. Gateway Group and Source Addresses 894 To support sourcing traffic to SSM groups by a gateway with a global 895 unicast address, the AMT Subnet Anycast Prefix is treated as the 896 subnet prefix of the AMT pseudo-interface, and an anycast address is 897 added on the interface. This anycast address is formed by 898 concatenating the AMT Subnet Anycast Prefix followed by the high bits 899 of the gateway's global unicast address. 901 The remaining bits of its global unicast address are appended to the 902 SSM prefix to create the group address and any spare bits may be 903 allocated using local policy. 905 If a gateway wants to source multicast traffic, it must select the 906 gateway source address and SSM group address in such a way that the 907 AMT relay can have enough information to reconstruct the gateway's 908 unicast address when it receives an SSM join for the source. 910 Note that multiple gateways might end up with the same anycast 911 address assigned to their pseudo-interfaces. 913 7.2.1. IPv4 915 For example, if IANA assigns the IPv4 prefix x.y/16 as the AMT Subnet 916 Anycast Prefix, and the gateway has global unicast address a.b.c.d, 917 then the AMT Gateway's Anycast Source Address will be x.y.a.b. Since 918 the IPv4 SSM group range is 232/8, it MUST allocate IPv4 SSM groups 919 in the range 232.c.d/24. 921 Group: 922 8 16 8 923 +------------+------------------------+-------------+ 924 | SSM prefix | Low 16 bits of | Local | 925 | 232/8 | real source address | Policy | 926 +------------+------------------------+-------------+ 928 Source: 929 +-------------------------+-------------------------+ 930 |16-bit AMT unicast prefix| high 16 bits of real src| 931 +-------------------------+-------------------------+ 933 This allows for 2^8 (256) IPv4 group addresses for use by each AMT 934 gateway. An allocation of a prefix with length 18 would allow for 935 2^6 (64) IPv4 group addresses. 937 7.2.2. IPv6 939 Similarly for IPv6, this is illustrated in the following figure. 941 Group: 942 32 64 32 943 +------------+------------------------+-------------+ 944 | SSM prefix | Low 64 bits of | Local | 945 | FF3x::/32 | real source address | Policy | 946 +------------+------------------------+-------------+ 948 Source: 949 +-------------------------+-------------------------+ 950 |64-bit AMT unicast prefix| high 64 bits of real src| 951 +-------------------------+-------------------------+ 953 This allows for 2^32 (over 4 billion) IPv6 group addresses for use by 954 each AMT gateway. 956 7.3. Joining Groups with MBone Sources 958 The IGMP/MLD protocol usually operates by having the Querier 959 multicast an IGMP/MLD Query message on the link. This behavior does 960 not work on NBMA links which do not support multicast. Since the set 961 of gateways is typically unknown to the relay (and potentially quite 962 large), unicasting the queries is also impractical. The following 963 behavior is used instead. 965 Applications residing in a gateway should join groups on the AMT 966 pseudo-interface, causing IGMP/MLD Membership/Listener Reports to be 967 sent over that interface. When UDP encapsulating the membership 968 reports (and in fact any other messages, unless specified otherwise 969 in this document), the destination address in the outer IP header is 970 the relay's unicast address. Robustness is provided by the 971 underlying IGMP/MLD protocol messages sent on the AMT pseudo- 972 interface. In other words, the gateway does not need to retransmit 973 IGMP/MLD Membership/Listener Reports and Leave/Done messages received 974 on the pseudo-interface since IGMP/MLD will already do this. The 975 gateway simply needs to encapsulate each IGMP/MLD Membership/Listener 976 Report and Leave/Done message it receives. 978 However, since periodic IGMP/MLD Membership/Listener Reports are sent 979 in response to IGMP/MLD Queries, some mechanism to trigger periodic 980 Membership/Listener Reports and Leave/Done messages are necessary. 981 This can be achieved in any implementation-specific manner. Some 982 possibilities include: 984 1. The AMT pseudo-interface might periodically manufacture IGMPv3/ 985 MLDv2 Queries as if they had been received from an IGMP/MLD 986 Querier, and deliver them to the IP layer, after which normal 987 IGMP/MLD behavior will cause the appropriate reports to be sent. 989 2. The IGMP/MLD module itself might provide an option to operate in 990 periodic mode on specific interfaces. 992 The Querier's Robustness Variable (QRV) defined in [RFC3376] and 993 [RFC3810] can be used to adjust the number of Membership/Listener 994 Reports that are sent by the host joining the group. 996 If the gateway is behind a firewall device, the firewall may require 997 the gateway to periodically refresh the UDP state in the firewall at 998 a shorter interval than the standard IGMP/MLD Query interval. 999 Therefore, this IGMP/MLD Query interval should be configurable to 1000 ensure the firewall does not revert to blocking the UDP encapsulated 1001 IP Multicast data packets. 1003 7.4. Responding to Relay Changes 1005 When a gateway determines that its current relay is unreachable 1006 (e.g., upon receipt of an ICMP Unreachable message [RFC0792] for the 1007 relay's unicast address), it may need to repeat relay address 1008 discovery. However, care should be taken not to abandon the current 1009 relay too quickly due to transient network conditions. 1011 7.5. Joining SSM Groups with AMT Gateway Sources 1013 An IGMPv3/MLDv2 Report for a given (source, group) pair MAY be 1014 encapsulated directly to the source, when the source address belongs 1015 to the AMT Subnet Anycast Prefix. 1017 The "link-layer" address to use as the destination address in the 1018 outer IP header is obtained as follows. The source address in the 1019 inclusion list of the IGMPv3/MLDv2 report will be an AMT Gateway 1020 Anycast Address with the high bits of the address, and the remaining 1021 bits will be in the middle of the group address. 1023 Section 7.2 describes this format to recover the gateway source 1024 address. 1026 7.6. Receiving AMT Membership Updates by the Gateway 1028 When an AMT Request is received by the gateway from another gateway 1029 or relay, it follows the same 3-way handshake procedure a relay would 1030 follow if it received the AMT Request. It generates a MAC and 1031 responds with an AMT Membership Query. When the AMT Membership 1032 Update is received, it verifies the MAC and then processes the IGMP/ 1033 MLD Membership/Listener Report or Leave/Done. 1035 At the gateway, the IGMP/MLD packet should be an IGMPv3/MLDv2 source 1036 specific (S,G) join or leave. 1038 If S is not the AMT Gateway Anycast Address, the packet is silently 1039 discarded. If G does not contain the low bits of the global unicast 1040 address (as described above), the packet is also silently discarded. 1042 The gateway adds the source address (from the outer IP header) and 1043 UDP port of the report to a membership list for G. Maintaining this 1044 membership list may be done in any implementation-dependent manner. 1045 For example, it might be maintained by the "link-layer" inside the 1046 AMT pseudo-interface, making it invisible to the normal IGMP/MLD 1047 module. 1049 7.7. Sending data to SSM groups 1051 When multicast packets are sent on the AMT pseudo-interface, they are 1052 encapsulated as follows. If the group address is not an SSM group, 1053 then the packet is silently discarded (this memo does not currently 1054 provide a way to send to non-SSM groups). 1056 If the group address is an SSM group, then the packet is unicast 1057 encapsulated to each remote node from which the gateway has received 1058 an IGMPv3/MLDv2 report for the packet's (source, group) pair. 1060 8. Relay Router Details 1062 8.1. At Startup time 1064 At startup time, the relay router will bring up an NBMA-style AMT 1065 pseudo-interface. It shall also add the AMT Relay Anycast Address on 1066 some interface. 1068 The relay router shall then advertise the AMT Relay Anycast Prefix 1069 into the unicast-only Internet, as if it were a connection to an 1070 external network. When the advertisement is done using BGP, the AS 1071 path leading to the AMT Relay Anycast Prefix shall include the 1072 identifier of the local AS. 1074 The relay router shall also enable IGMPv3/MLDv2 on the AMT pseudo- 1075 interface, except that it shall not multicast Queries (this might be 1076 done, for example, by having the AMT pseudo-device drop them, or by 1077 having the IGMP/MLD module not send them in the first place). 1079 Finally, to support sourcing SSM traffic from AMT sites, the AMT 1080 Subnet Anycast Prefix is assigned to the AMT pseudo-interface, and 1081 the AMT Subnet Anycast Prefix is injected by the AMT Relay into the 1082 M-RIB of MBGP. 1084 8.2. Receiving Relay Discovery messages sent to the Anycast Address 1086 When a relay receives an AMT Relay Discovery message directed to the 1087 AMT Relay Anycast Address, it should respond with an AMT Relay 1088 Advertisement containing its unicast address. The source and 1089 destination addresses of the advertisement should be the same as the 1090 destination and source addresses of the discovery message 1091 respectively. Further, the nonce in the discovery message MUST be 1092 copied into the advertisement message. 1094 8.3. Receiving Membership Updates from AMT Gateways 1096 The relay operates passively, sending no periodic IGMP/MLD Queries 1097 but simply tracking membership information according to AMT Request/ 1098 Query/Membership Update tuples received. In addition, the relay must 1099 also do explicit membership tracking, as to which gateways on the AMT 1100 pseudo-interface have joined which groups. Once an AMT Membership 1101 Update has been successfully received, it updates the forwarding 1102 state for the appropriate group and source (if provided). When data 1103 arrives for that group, the traffic must be encapsulated to each 1104 gateway which has joined that group or (S,G). 1106 The explicit membership tracking and unicast replication may be done 1107 in any implementation-specific manner. Some examples are: 1109 1. The AMT pseudo-device driver might track the group information 1110 and perform the replication at the "link-layer", with no changes 1111 to a pre-existing IGMP/MLD module. 1113 2. The IGMP/MLD module might have native support for explicit 1114 membership tracking, especially if it supports other NBMA-style 1115 interfaces. 1117 If a relay wants to affect the rate at which the AMT Requests are 1118 originated from a gateway, it can tune the membership timeout by 1119 adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/ 1120 MLD Query contained within the AMT Membership Query message. The 1121 QQIC field is defined in [RFC3376] and [RFC3810]. 1123 8.4. Receiving (S,G) Joins from the Native Side, for AMT Sources 1125 The relay sends an IGMPv3/MLDv2 report to the AMT source as described 1126 above in Section 5.1.2 1128 9. IANA Considerations 1130 9.1. IPv4 and IPv6 Anycast Prefix Allocation 1132 The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated 1133 to the public AMT Relays to advertise to the native multicast 1134 backbone. The prefix length should be determined by the IANA; the 1135 prefix should be large enough to guarantee advertisement in the 1136 default-free BGP networks. 1138 9.1.1. IPv4 1140 A prefix length of 18 will meet this requirement. 1142 9.1.2. IPv6 1144 A prefix length of 32 will meet this requirement. IANA has 1145 previously set aside the range 2001::/16 for allocating prefixes for 1146 this purpose. 1148 9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation 1150 It should also be noted that this prefix length directly affects the 1151 number of groups available to be created by the AMT gateway: in the 1152 IPv4 case, a prefix length of 16 gives 256 groups, and a prefix 1153 length of 8 gives 65536 groups. 1155 9.2.1. IPv4 1157 As described above in Section 7.2.1 an IPv4 prefix with a length of 1158 18 is requested for this purpose. 1160 9.2.2. IPv6 1162 As described above in Section 7.2.2 an IPv6 prefix with a length of 1163 48 is requested. 1165 9.3. UDP Port number 1167 IANA has previously allocated UDP reserved port number 2268 for AMT 1168 encapsulation. 1170 All allocations are a one time effort and there will be no need for 1171 any recurring assignment after this stage. 1173 10. Security Considerations 1175 The anycast technique introduces a risk that a rogue router or a 1176 rogue AS could introduce a bogus route to the AMT Relay Anycast 1177 prefix, and thus divert the traffic. Network managers have to 1178 guarantee the integrity of their routing to the AMT Relay Anycast 1179 prefix in much the same way that they guarantee the integrity of all 1180 other routes. 1182 Within the native MBGP infrastructure, there is a risk that a rogue 1183 router or a rogue AS could inject a false route to the AMT Subnet 1184 Anycast Prefix, and thus divert joins and cause RPF failures of 1185 multicast traffic. As the AMT Subnet Anycast Prefix will be 1186 advertised by multiple entities, guaranteeing the integrity of this 1187 shared MBGP prefix is much more challenging than verifying the 1188 correctness of a regular unicast advertisement. To mitigate this 1189 threat, routing operators should configure the BGP sessions to filter 1190 out any more specific advertisements for the AMT Subnet Anycast 1191 Prefix. 1193 Gateways and relays will accept and decapsulate multicast traffic 1194 from any source from which regular unicast traffic is accepted. If 1195 this is for any reason felt to be a security risk, then additional 1196 source address based packet filtering MUST be applied: 1198 1. To prevent a rogue sender (that can't do traditional spoofing 1199 because of e.g. access lists deployed by its ISP) from making use 1200 of AMT to send packets to an SSM tree, a relay that receives an 1201 encapsulated multicast packet MUST discard the multicast packet 1202 if the IP source address in the outer header does not match the 1203 source address that would be extracted using the rules of 1204 Section 7.2. 1206 2. A gateway MUST discard encapsulated multicast packets if the 1207 source address in the outer header is not the address to which 1208 the encapsulated join message was sent. An AMT Gateway that 1209 receives an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard the 1210 message if the IP destination address in the outer header does 1211 not match the source address that would be extracted using the 1212 rules of Section 7.2. 1214 11. Contributors 1216 The following people provided significant contributions to earlier 1217 versions of this draft. 1219 Dirk Ooms 1220 OneSparrow 1221 Belegstraat 13; 2018 Antwerp; Belgium 1222 EMail: dirk@onesparrow.com 1224 12. Acknowledgments 1226 Most of the mechanisms described in this document are based on 1227 similar work done by the NGTrans WG for obtaining automatic IPv6 1228 connectivity without explicit tunnels ("6to4"). Tony Ballardie 1229 provided helpful discussion that inspired this document. 1231 In addition, extensive comments were received from Pekka Savola, Greg 1232 Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John 1233 Zwiebel, and Lenny Giuliano. 1235 Juniper Networks was instrumental in funding several versions of this 1236 draft as well as an open source implementation. 1238 13. References 1240 13.1. Normative References 1242 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1243 RFC 792, September 1981. 1245 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1246 Thyagarajan, "Internet Group Management Protocol, Version 1247 3", RFC 3376, October 2002. 1249 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1250 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1252 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1253 "Internet Group Management Protocol (IGMP) / Multicast 1254 Listener Discovery (MLD)-Based Multicast Forwarding 1255 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1257 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1258 IP", RFC 4607, August 2006. 1260 13.2. Informative References 1262 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1263 RFC 1112, August 1989. 1265 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 1266 Anycasting Service", RFC 1546, November 1993. 1268 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1269 Hashing for Message Authentication", RFC 2104, 1270 February 1997. 1272 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1273 Requirement Levels", BCP 14, RFC 2119, March 1997. 1275 [RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing 1276 Architecture", RFC 2373, July 1998. 1278 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 1279 Tunnel Broker", RFC 3053, January 2001. 1281 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1282 via IPv4 Clouds", RFC 3056, February 2001. 1284 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1285 RFC 3068, June 2001. 1287 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1288 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1289 Protocol Specification (Revised)", RFC 4601, August 2006. 1291 Authors' Addresses 1293 Dave Thaler 1294 Microsoft Corporation 1295 One Microsoft Way 1296 Redmond, WA 98052-6399 1297 USA 1299 Phone: +1 425 703 8835 1300 Email: dthaler@microsoft.com 1302 Mohit Talwar 1303 Microsoft Corporation 1304 One Microsoft Way 1305 Redmond, WA 98052-6399 1306 USA 1308 Phone: +1 425 705 3131 1309 Email: mohitt@microsoft.com 1311 Amit Aggarwal 1312 Microsoft Corporation 1313 One Microsoft Way 1314 Redmond, WA 98052-6399 1315 USA 1317 Phone: +1 425 706 0593 1318 Email: amitag@microsoft.com 1320 Lorenzo Vicisano 1321 Cisco Systems 1322 170 West Tasman Dr. 1323 San Jose, CA 95134 1324 USA 1326 Phone: +1 408 525 2530 1327 Email: lorenzo@cisco.com 1328 Tom Pusateri 1329 !j 1330 222 E. Jones Ave. 1331 Wake Forest, NC 27587 1332 USA 1334 Email: pusateri@bangj.com 1336 Intellectual Property Statement 1338 The IETF takes no position regarding the validity or scope of any 1339 Intellectual Property Rights or other rights that might be claimed to 1340 pertain to the implementation or use of the technology described in 1341 this document or the extent to which any license under such rights 1342 might or might not be available; nor does it represent that it has 1343 made any independent effort to identify any such rights. Information 1344 on the procedures with respect to rights in RFC documents can be 1345 found in BCP 78 and BCP 79. 1347 Copies of IPR disclosures made to the IETF Secretariat and any 1348 assurances of licenses to be made available, or the result of an 1349 attempt made to obtain a general license or permission for the use of 1350 such proprietary rights by implementers or users of this 1351 specification can be obtained from the IETF on-line IPR repository at 1352 http://www.ietf.org/ipr. 1354 The IETF invites any interested party to bring to its attention any 1355 copyrights, patents or patent applications, or other proprietary 1356 rights that may cover technology that may be required to implement 1357 this standard. Please address the information to the IETF at 1358 ietf-ipr@ietf.org. 1360 Disclaimer of Validity 1362 This document and the information contained herein are provided on an 1363 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1364 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1365 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1366 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1367 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1368 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1370 Copyright Statement 1372 Copyright (C) The Internet Society (2006). This document is subject 1373 to the rights, licenses and restrictions contained in BCP 78, and 1374 except as set forth therein, the authors retain all their rights. 1376 Acknowledgment 1378 Funding for the RFC Editor function is currently provided by the 1379 Internet Society.