idnits 2.17.1 draft-ietf-mboned-auto-multicast-08.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, updated by RFC 4748 on line 1377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1388. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1401. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (October 3, 2007) is 6050 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 3068 (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft M. Talwar 4 Intended status: Standards Track A. Aggarwal 5 Expires: April 5, 2008 Microsoft Corporation 6 L. Vicisano 7 Cisco Systems 8 T. Pusateri 9 !j 10 October 3, 2007 12 Automatic IP Multicast Without Explicit Tunnels (AMT) 13 draft-ietf-mboned-auto-multicast-08 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 April 5, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 59 3. Requirements notation . . . . . . . . . . . . . . . . . . . . 7 60 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 4.1. AMT Pseudo-Interface . . . . . . . . . . . . . . . . . . . 8 62 4.2. AMT Gateway . . . . . . . . . . . . . . . . . . . . . . . 8 63 4.3. AMT Site . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 4.4. AMT Relay Router . . . . . . . . . . . . . . . . . . . . . 8 65 4.5. AMT Relay Anycast Prefix . . . . . . . . . . . . . . . . . 9 66 4.6. AMT Relay Anycast Address . . . . . . . . . . . . . . . . 9 67 4.7. AMT Subnet Anycast Prefix . . . . . . . . . . . . . . . . 9 68 4.8. AMT Gateway Anycast Address . . . . . . . . . . . . . . . 9 69 5. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 5.1. Receiving Multicast in an AMT Site . . . . . . . . . . . . 10 71 5.1.1. Scalability Considerations . . . . . . . . . . . . . . 11 72 5.1.2. Spoofing Considerations . . . . . . . . . . . . . . . 11 73 5.1.3. Protocol Sequence for a Gateway Joining SSM 74 Receivers to a Relay . . . . . . . . . . . . . . . . . 12 75 5.2. Sourcing Multicast from an AMT site . . . . . . . . . . . 14 76 5.2.1. Supporting Site-MBone Multicast . . . . . . . . . . . 15 77 5.2.2. Supporting Site-Site Multicast . . . . . . . . . . . . 16 78 6. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17 79 6.1. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . 17 80 6.1.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 6.1.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 17 82 6.1.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 17 83 6.2. AMT Relay Advertisement . . . . . . . . . . . . . . . . . 17 84 6.2.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 6.2.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 18 86 6.2.3. Discovery Nonce . . . . . . . . . . . . . . . . . . . 18 87 6.2.4. Relay Address . . . . . . . . . . . . . . . . . . . . 18 88 6.3. AMT Request . . . . . . . . . . . . . . . . . . . . . . . 18 89 6.3.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 19 90 6.3.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 19 91 6.3.3. Request Nonce . . . . . . . . . . . . . . . . . . . . 19 92 6.4. AMT Membership Query . . . . . . . . . . . . . . . . . . . 19 93 6.4.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 20 94 6.4.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 20 95 6.4.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 20 96 6.4.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 20 97 6.4.5. IGMP/MLD Query (including IP Header) . . . . . . . . . 20 98 6.5. AMT Membership Update . . . . . . . . . . . . . . . . . . 21 99 6.5.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 21 100 6.5.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 22 101 6.5.3. Response MAC . . . . . . . . . . . . . . . . . . . . . 22 102 6.5.4. Request Nonce . . . . . . . . . . . . . . . . . . . . 22 103 6.5.5. IGMP/MLD Message (including IP Header) . . . . . . . . 22 104 6.6. AMT IP Multicast Data . . . . . . . . . . . . . . . . . . 22 105 6.6.1. Type . . . . . . . . . . . . . . . . . . . . . . . . . 23 106 6.6.2. Reserved . . . . . . . . . . . . . . . . . . . . . . . 23 107 6.6.3. IP Multicast Data . . . . . . . . . . . . . . . . . . 23 108 7. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 24 109 7.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . 24 110 7.2. Gateway Group and Source Addresses . . . . . . . . . . . . 24 111 7.2.1. IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 25 112 7.2.2. IPv6 . . . . . . . . . . . . . . . . . . . . . . . . . 25 113 7.3. Joining Groups with MBone Sources . . . . . . . . . . . . 26 114 7.4. Responding to Relay Changes . . . . . . . . . . . . . . . 26 115 7.5. Joining SSM Groups with AMT Gateway Sources . . . . . . . 27 116 7.6. Receiving AMT Membership Updates by the Gateway . . . . . 27 117 7.7. Sending data to SSM groups . . . . . . . . . . . . . . . . 27 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 140 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 141 Intellectual Property and Copyright Statements . . . . . . . . . . 38 143 1. Introduction 145 The primary goal of this document is to foster the deployment of 146 native IP multicast by enabling a potentially large number of nodes 147 to connect to the already present multicast infrastructure. 148 Therefore, the techniques discussed here should be viewed as an 149 interim solution to help in the various stages of the transition to a 150 native multicast network. 152 To allow fast deployment, the solution presented here only requires 153 small and concentrated changes to the network infrastructure, and no 154 changes at all to user applications or to the socket API of end- 155 nodes' operating systems. The protocol introduced in this 156 specification can be deployed in a few strategically-placed network 157 nodes and in user-installable software modules (pseudo device drivers 158 and/or user-mode daemons) that reside underneath the socket API of 159 end-nodes' operating systems. This mechanism is very similar to that 160 used by "6to4" [RFC3056], [RFC3068] to get automatic IPv6 161 connectivity. 163 Effectively, AMT treats the unicast-only inter-network as a large 164 non-broadcast multi-access (NBMA) link layer, over which we require 165 the ability to multicast. To do this, multicast packets being sent 166 to or from a site must be encapsulated in unicast packets. If the 167 group has members in multiple sites, AMT encapsulation of the same 168 multicast packet will take place multiple times by necessity. 170 2. Applicability 172 AMT is not a substitute for native multicast or a statically 173 configured multicast tunnel for high traffic flow. Unicast 174 replication is required to reach multiple receivers that are not part 175 of the native multicast infrastructure. Unicast replication is also 176 required by non-native sources to different parts of the native 177 multicast infrastructure. However, this is no worse than regular 178 unicast distribution of streams and in most cases much better. 180 The following problems are addressed: 182 1. Allowing isolated sites/hosts to receive the SSM flavor of 183 multicast ([RFC4607]). 185 2. Allowing isolated non-NAT sites/hosts to transmit the SSM flavor 186 of multicast. 188 3. Allowing isolated sites/hosts to receive general multicast (ASM 189 [RFC1112]). 191 This document does not address allowing isolated sites/hosts to 192 transmit general multicast. We expect that other solutions (e.g., 193 Tunnel Brokers, a la [RFC3053]) will be used for sites that desire 194 this capability. 196 Implementers should be aware that site administrators may have 197 configured administratively scoped multicast boundaries and a remote 198 gateway may provide a means to circumvent administrative boundaries. 199 Therefore, implementations should allow for the configuration of such 200 boundaries on relays and gateways and perform filtering as needed. 202 3. Requirements notation 204 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 205 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 206 document are to be interpreted as described in [RFC2119]. 208 4. Definitions 210 +---------------+ Internet +---------------+ 211 | AMT Site | | Native MCast | 212 | | | | 213 | +------+----+ AMT +----+----+ AMT | 214 | |AMT Gateway| Anycast |AMT Relay| Subnet | 215 | | +-----+-+ Prefix +-+-----+ | Prefix | 216 | | |AMT IF | <------------|AMT IF | |--------> | 217 | | +-----+-+ +-+-----+ | | 218 | +------+----+ +----+----+ | 219 | | | | 220 +---------------+ +---------------+ 222 4.1. AMT Pseudo-Interface 224 AMT encapsulation of multicast packets inside unicast packets occurs 225 at a point that is logically equivalent to an interface, with the 226 link layer being the unicast-only network. This point is referred to 227 as a pseudo-interface. Some implementations may treat it exactly 228 like any other interface and others may treat it like a tunnel end- 229 point. 231 4.2. AMT Gateway 233 A host, or a site gateway router, supporting an AMT Pseudo- 234 Interface. It does not have native multicast connectivity to the 235 native multicast backbone infrastructure. It is simply referred to 236 in this document as a "gateway". 238 4.3. AMT Site 240 A multicast-enabled network not connected to the multicast backbone 241 served by an AMT Gateway. It could also be a stand- alone AMT 242 Gateway. 244 4.4. AMT Relay Router 246 A multicast router configured to support transit routing between AMT 247 Sites and the native multicast backbone infrastructure. The relay 248 router has one or more interfaces connected to the native multicast 249 infrastructure, zero or more interfaces connected to the non- 250 multicast capable inter-network, and an AMT pseudo-interface. It is 251 simply referred to in this document as a "relay". 253 As with [RFC3056], we assume that normal multicast routers do not 254 want to be tunnel endpoints (especially if this results in high fan 255 out), and similarly that service providers do not want encapsulation 256 to arbitrary routers. Instead, we assume that special-purpose 257 routers will be deployed that are suitable for serving as relays. 259 4.5. AMT Relay Anycast Prefix 261 A well-known address prefix used to advertise (into the unicast 262 routing infrastructure) a route to an available AMT Relay Router. 263 This could also be private (i.e., not well-known) for a private 264 relay. 266 Prefixes for both IPv4 and IPv6 will be assigned in a future version 267 of this draft. 269 4.6. AMT Relay Anycast Address 271 An anycast address which is used to reach the nearest AMT Relay 272 Router. 274 This address corresponds to the setting the low-order octet of the 275 AMT Relay Anycast Prefix to 1 (for both IPv4 and IPv6). 277 4.7. AMT Subnet Anycast Prefix 279 A well-known address prefix used to advertise (into the M-RIB of the 280 native multicast-enabled infrastructure) a route to AMT Sites. This 281 prefix will be used to enable sourcing SSM traffic from an AMT 282 Gateway. 284 4.8. AMT Gateway Anycast Address 286 An anycast address in the AMT Subnet Anycast Prefix range, which is 287 used by an AMT Gateway to enable sourcing SSM traffic from local 288 applications. 290 5. Overview 292 5.1. Receiving Multicast in an AMT Site 294 Internet 295 +---------------+ +---------------+ 296 | AMT Site | 2. 3-way Membership | MBone | 297 | | Handshake | | 298 | 1. Join +---+---+ =================> +---+---+ | 299 | +---->|Gateway| | Relay | | 300 | | +---+---+ <================= +---+---+ | 301 | R-+ | 3. Receive Data | | 302 +---------------+ +---------------+ 304 Receiving Multicast in an AMT Site 306 AMT relays and gateways cooperate to transmit multicast traffic 307 sourced within the native multicast infrastructure to AMT sites: 308 relays receive the traffic natively and unicast-encapsulate it to 309 gateways; gateways decapsulate the traffic and possibly forward it 310 into the AMT site. 312 Each gateway has an AMT pseudo-interface that serves as a default 313 multicast route. Requests to join a multicast session are sent to 314 this interface and encapsulated to a particular relay reachable 315 across the unicast-only infrastructure. 317 Each relay has an AMT pseudo-interface too. Multicast traffic sent 318 on this interface is encapsulated to zero or more gateways that have 319 joined to the relay. The AMT recipient-list is determined for each 320 multicast session. This requires the relay to keep state for each 321 gateway which has joined a particular group or (source, group) pair. 322 Multicast packets from the native infrastructure behind the relay 323 will be sent to each gateway which has requested them. 325 All multicast packets (data and control) are encapsulated in unicast 326 packets. UDP encapsulation is used for all AMT control and data 327 packets using the IANA reserved UDP port number for AMT. 329 Each relay, plus the set of all gateways using the relay, together 330 are thought of as being on a separate logical NBMA link. This 331 implies that the AMT recipient-list is a list of "link layer" 332 addresses which are (IP address, UDP port) pairs. 334 Since the number of gateways using a relay can be quite large, and we 335 expect that most sites will not want to receive most groups, an 336 explicit-joining protocol is required for gateways to communicate 337 group membership information to a relay. The two most likely 338 candidates are the IGMP/MLD protocol [RFC3376], [RFC3810], and the 339 PIM-Sparse Mode protocol [RFC4601]. Since an AMT gateway may be a 340 host, and hosts typically do not implement routing protocols, 341 gateways will use IGMP/MLD as described in Section 7 below. This 342 allows a host kernel (or a pseudo device driver) to easily implement 343 AMT gateway behavior, and obviates the relay from the need to know 344 whether a given gateway is a host or a router. From the relay's 345 perspective, all gateways are indistinguishable from hosts on an NBMA 346 leaf network. 348 5.1.1. Scalability Considerations 350 It is possible that millions of hosts will enable AMT gateway 351 functionality and so an important design goal is not to create 352 gateway state in each relay until the gateway joins a multicast 353 group. But even the requirement that a relay keep group state per 354 gateway that has joined a group introduces potential scalability 355 concerns. 357 Scalability of AMT can be achieved by adding more relays, and using 358 an appropriate relay discovery mechanism for gateways to discover 359 relays. The solution we adopt is to assign addresses in anycast 360 fashion to relays [RFC1546], [RFC4291]. However, simply sending 361 periodic membership reports to an anycast address can cause 362 duplicates. Specifically, if routing changes such that a different 363 relay receives a periodic membership report, both the new and old 364 relays will encapsulate data to the AMT site until the old relay's 365 state times out. This is obviously undesirable. Instead, we use the 366 anycast address merely to find the unicast address of a relay to 367 which membership reports are sent. 369 Since adding another relay has the result of adding another 370 independent NBMA link, this allows the gateways to be spread out 371 among more relays so as to keep the number of gateways per relay at a 372 reasonable level. 374 5.1.2. Spoofing Considerations 376 An attacker could affect the group state in the relay or gateway by 377 spoofing the source address in the join or leave reports. This can 378 be used to launch reflection or denial of service attacks on the 379 target. Such attacks can be mitigated by using a three way handshake 380 between the gateway and the relay for each multicast membership 381 report or leave. 383 When a gateway or relay wants to send a membership report, it first 384 sends an AMT Request with a request nonce in it. The receiving side 385 (the respondent) can calculate a message authentication code (MAC) 386 based on (for example) the source IP address of the Request, the 387 source UDP port, the request nonce, and a secret key known only to 388 the respondent. The algorithm and the input used to calculate the 389 MAC does not have to be standardized since the respondent generates 390 and verifies the MAC and the originator simply echoes it. 392 An AMT Membership Query is sent back including the request nonce and 393 the MAC to the originator of the Request. The originator then sends 394 the IGMP/MLD Membership/Listener Report or Leave/Done (including the 395 IP Header) along with the request nonce and the received MAC back to 396 the respondent finalizing the 3-way handshake. 398 Upon reception, the respondent can recalculate the MAC based on the 399 source IP address, the source UDP port, the request nonce, and the 400 local secret. The IGMP/MLD message is only accepted if the received 401 MAC matches the calculated MAC. 403 The local secret never has to be shared with the other side. It is 404 only used to verify return routability of the originator. 406 Since the same Request Nonce and source IP address can be re-used, 407 the receiver SHOULD change its secret key at least once per hour. 408 However, AMT Membership updates received with the previous secret 409 MUST be accepted for up to the IGMP/MLD Query Interval. 411 5.1.3. Protocol Sequence for a Gateway Joining SSM Receivers to a Relay 413 This description assumes the Gateway can be a host joining as a 414 receiver or a network device acting as a Gateway when a directly 415 connected host joins as a receiver. 417 o Receiver at AMT site sends IGMPv3/MLDv2 report joining (S1,G1). 419 o Gateway receives report. If it has no tunnel state with a Relay, 420 it originates an AMT Relay Discovery message addressed to the 421 Anycast Relay IP address. The AMT Relay Discovery message can be 422 sent on demand if no relay is known at this time or at startup and 423 be periodically refreshed. 425 o The closest Relay topologically receives the AMT Relay Discovery 426 message and returns the nonce from the Discovery in an AMT Relay 427 Advertisement message so the Gateway can learn of the Relay's 428 unique IP address. 430 o When the Gateway receives the AMT Relay Advertisement message, it 431 now has an address to use for all subsequent (S,G) entries it will 432 join on behalf of attached receivers (or itself). 434 o If the gateway has a valid Response MAC from a previous AMT Query 435 message, it can send an AMT Membership Update message as described 436 below. Otherwise, the Gateway sends an AMT Request message to the 437 Relay's unique IP address to begin the process of joining the 438 (S,G). The gateway also SHOULD initialize a timer used to send 439 periodic Requests to a random value from the interval [0, [Query 440 Interval]] before sending the first periodic report, in order to 441 prevent startup synchronization. 443 o The Relay responds to the AMT Request message by returning the 444 nonce from the Request in a AMT Query message. The Query message 445 contains an IGMP/MLD QUERY indicating how often the Gateway should 446 repeat AMT Request messages so the (S,G) state can stay refreshed 447 in the Relay. The Query message also includes an opaque security 448 code which is generated locally (with no external coordination). 450 o When the Gateway receives the AMT Query message it responds by 451 copying the security code from the AMT Query message into a AMT 452 Membership Update message. The Update message contains (S1,G1) in 453 an IGMPv3/MLDv2 formatted packet with an IP header. The nonce 454 from the AMT Request is also included in the AMT Membership Update 455 message. 457 o When the Relay receives the AMT Membership Update, it will add the 458 tunnel to the Gateway in it's outgoing interface list for it's 459 (S1,G1) entry stored in the multicast routing table. If the 460 (S1,G1) entry was created do to this interaction, the multicast 461 routing protocol running on the Relay will trigger a Join message 462 towards source S1 to build a native multicast tree in the native 463 multicast infrastructure. 465 o As packets are sent from the host S1, they will travel natively 466 down the multicast tree associated with (S1,G1) in the native 467 multicast infrastructure to the Relay. The Relay will replicate 468 to all interfaces in it's outgoing interface list as well as the 469 tunnel outgoing interface, which is encapsulated in a unicast AMT 470 Multicast Data message. 472 o When the Gateway receives the AMT Multicast Data message, it will 473 accept the packet since it was received over the pseudo-interface 474 associated with the tunnel to the Relay it had attached to, and 475 forward the packet to the outgoing interfaces joined by any 476 attached receiver hosts (or deliver the packet to the application 477 when the Gateway is the receiver). 479 o If later (S2,G2) is joined by a receiver, a 3-way handshake of 480 Request/ Query/Update occurs for this entry. The Discovery/ 481 Advertisement exchange is not required. 483 o To keep the state for (S1,G1) and (S2,G2) alive in the Relay, the 484 Gateway will send periodic AMT Membership Updates. The Membership 485 Update can be sent directly if the sender has a valid nonce from a 486 previous Request. If not, an AMT Request messages should be sent 487 to solicit a Query Message. When sending a periodic state 488 refresh, all joined state in the Gateway is packed in the fewest 489 number of AMT Membership Update messages. 491 o When the Gateway leaves all (S,G) entries, the Relay can free 492 resources associated with the tunnel. It is assumed that when the 493 Gateway would want to join an (S,G) again, it would start the 494 Discovery/Advertisement tunnel establishment process over again. 496 This same procedure would be used for receivers who operate in Any- 497 Source Multicast (ASM) mode. 499 5.2. Sourcing Multicast from an AMT site 501 Two cases are discussed below: multicast traffic sourced in an AMT 502 site and received in the MBone, and multicast traffic sourced in an 503 AMT site and received in another AMT site. 505 In both cases only SSM sources are supported. Furthermore this 506 specification only deals with the source residing directly in the 507 gateway. To enable a generic node in an AMT site to source 508 multicast, additional coordination between the gateway and the 509 source-node is required. 511 The gateway SHOULD allow for filtering link-local and site-local 512 traffic. 514 The general mechanism used to join towards AMT sources is based on 515 the following: 517 1. Applications residing in the gateway use addresses in the AMT 518 Subnet Anycast Prefix to send multicast, as a result of sourcing 519 traffic on the AMT pseudo-interface. 521 2. The AMT Subnet Anycast Prefix is advertised for RPF reachability 522 in the M-RIB by relays and gateways. 524 3. Relays or gateways that receive a join for a source/group pair 525 use information encoded in the address pair to rebuild the 526 address of the gateway (source) to which to encapsulate the join 527 (see Section 7.2 for more details). The membership reports use 528 the same three way handshake as outlined in Section 5.1.2 530 5.2.1. Supporting Site-MBone Multicast 532 Internet 533 +---------------+ +---------------+ 534 | AMT Site | 2. 3-way Membership | MBone | 535 | | Handshake | | 536 | +---+---+ <================= +---+---+ 1. Join | 537 | |Gateway| | Relay |<-----+ | 538 | +---+---+ =================> +---+---+ | | 539 | | 3. Receive Data | +-R | 540 +---------------+ +---------------+ 542 Site-MBone Multicast 544 If a relay receives an explicit join from the native infrastructure, 545 for a given (source, group) pair where the source address belongs to 546 the AMT Subnet Anycast Prefix, then the relay will periodically 547 (using the rules specified in Section 5.1.2) encapsulate membership 548 updates for the group to the gateway. The gateway must keep state 549 per relay from which membership reports have been sent, and forward 550 multicast traffic from the site to all relays from which membership 551 reports have been received. The choice of whether this state and 552 replication is done at the link-layer (i.e., by the tunnel interface) 553 or at the network-layer is implementation dependent. 555 If there are multiple relays present, this ensures that data from the 556 AMT site is received via the closest relay to the receiver. This is 557 necessary when the routers in the native multicast infrastructure 558 employ Reverse-Path Forwarding (RPF) checks against the source 559 address, such as occurs when PIM Sparse-Mode [RFC4601] is used by the 560 multicast infrastructure. 562 The solution above will scale to an arbitrary number of relays, as 563 long at the number of relays requiring multicast traffic from a given 564 AMT site remains reasonable enough to not overly burden the site's 565 gateway. 567 A source at or behind an AMT gateway requires the gateway to do the 568 replication to one or more relays and receiving gateways. If this 569 places too much of a burden on the sourcing gateway, the source 570 should join the native multicast infrastructure through a permanent 571 tunnel so that replication occurs within the native multicast 572 infrastructure. 574 5.2.2. Supporting Site-Site Multicast 576 Internet 577 +---------------+ +---------------+ 578 | AMT Site | 2. 3-way Membership | AMT Site | 579 | | Handshake | | 580 | +---+---+ <================= +---+---+ 1. Join | 581 | |Gateway| |Gateway|<-----+ | 582 | +---+---+ =================> +---+---+ | | 583 | | 3. Receive Data | +-R | 584 +---------------+ +---------------+ 586 Site-Site Multicast 588 Since we require gateways to accept membership reports, as described 589 above, it is also possible to support multicast among AMT sites, 590 without requiring assistance from any relays. 592 When a gateway wants to join a given (source, group) pair, where the 593 source address belongs to the AMT Subnet Anycast Prefix, then the 594 gateway will periodically unicast encapsulate an IGMPv3/MLDv2 Report 595 [RFC3376], [RFC3810] (including IP Header) directly to the site 596 gateway for the source. 598 We note that this can result in a significant amount of state at a 599 site gateway sourcing multicast to a large number of other AMT sites. 600 However, it is expected that this is not unreasonable for two 601 reasons. First, the gateway does not have native multicast 602 connectivity, and as a result is likely doing unicast replication at 603 present. The amount of state is thus the same as what such a site 604 already deals with. Secondly, any site expecting to source traffic 605 to a large number of sites could get a point-to-point tunnel to the 606 native multicast infrastructure, and use that instead of AMT. 608 6. Message Formats 610 6.1. AMT Relay Discovery 612 The AMT Relay Discovery message is a UDP packet sent from the AMT 613 gateway unicast address to the AMT relay anycast address to discover 614 the unicast address of an AMT relay. 616 The UDP source port is uniquely selected by the local host operating 617 system. The UDP destination port is the IANA reserved AMT port 618 number. The UDP checksum MUST be valid in AMT control messages. 620 The payload of the UDP packet contains the following fields. 622 0 1 2 3 623 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 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Type=0x1 | Reserved | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Discovery Nonce | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 AMT Relay Discovery 632 6.1.1. Type 634 The type of the message. 636 6.1.2. Reserved 638 A 24-bit reserved field. Sent as 0, ignored on receipt. 640 6.1.3. Discovery Nonce 642 A 32-bit random value generated by the gateway and replayed by the 643 relay. 645 6.2. AMT Relay Advertisement 647 The AMT Relay Advertisement message is a UDP packet sent from the AMT 648 relay anycast address to the source of the discovery message. 650 The UDP source port is the IANA reserved AMT port number and the UDP 651 destination port is the source port received in the Discovery 652 message. The UDP checksum MUST be valid in AMT control messages. 654 The payload of the UDP packet contains the following fields. 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Type=0x2 | Reserved | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | Discovery Nonce | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 663 | Relay Address | 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 AMT Relay Advertisement 668 6.2.1. Type 670 The type of the message. 672 6.2.2. Reserved 674 A 24-bit reserved field. Sent as 0, ignored on receipt. 676 6.2.3. Discovery Nonce 678 A 32-bit random value generated by the gateway and replayed by the 679 relay. 681 6.2.4. Relay Address 683 The unicast IPv4 or IPv6 address of the AMT relay. The family can be 684 determined by the length of the Advertisement. 686 6.3. AMT Request 688 A Request packet is sent to begin a 3-way handshake for sending an 689 IGMP/MLD Membership/Listener Report or Leave/Done. It can be sent 690 from a gateway to a relay, from a gateway to another gateway, or from 691 a relay to a gateway. 693 It is sent from the originator's unique unicast address to the 694 respondents' unique unicast address. 696 The UDP source port is uniquely selected by the local host operating 697 system. It can be different for each Request and different from the 698 source port used in Discovery messages but does not have to be. The 699 UDP destination port is the IANA reserved AMT port number. The UDP 700 checksum MUST be valid in AMT control messages. 702 0 1 2 3 703 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 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | Type=0x3 | Reserved | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Request Nonce | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 AMT Relay Advertisement 712 6.3.1. Type 714 The type of the message. 716 6.3.2. Reserved 718 A 24-bit reserved field. Sent as 0, ignored on receipt. 720 6.3.3. Request Nonce 722 A 32-bit identifier used to distinguish this request. 724 6.4. AMT Membership Query 726 An AMT Membership Query packet is sent from the respondent back to 727 the originator to solicit an AMT Membership Update while confirming 728 the source of the original request. It contains a relay Message 729 Authentication Code (MAC) that is a cryptographic hash of a private 730 secret, the originators address, and the request nonce. 732 It is sent from the destination address received in the Request to 733 the source address received in the Request which is the same address 734 used in the Relay Advertisement. 736 The UDP source port is the IANA reserved AMT port number and the UDP 737 destination port is the source port received in the Request message. 738 The UDP checksum MUST be valid in AMT control messages. 740 0 1 2 3 741 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | Type=0x4 | Reserved | Response MAC | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | Response MAC (continued) | 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 | Request Nonce | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | IGMP Membership Query or MLD Listener Query | 750 | (including IP Header) | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | ... | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 AMT Membership Query 757 6.4.1. Type 759 The type of the message. 761 6.4.2. Reserved 763 A 8-bit reserved field. Sent as 0, ignored on receipt. 765 6.4.3. Response MAC 767 A 48-bit hash generated by the respondent and sent to the originator 768 for inclusion in the AMT Membership Update. The algorithm used for 769 this is chosen by the respondent but an algorithm such as HMAC-MD5-48 770 [RFC2104] SHOULD be used at a minimum. 772 6.4.4. Request Nonce 774 A 32-bit identifier used to distinguish this request echoed back to 775 the originator. 777 6.4.5. IGMP/MLD Query (including IP Header) 779 The message contains either an IGMP Query or an MLD Multicast 780 Listener Query. The IGMP or MLD version sent should default to 781 IGMPv3 or MLDv2 unless explicitly configured to use IGMPv2 or MLDv1. 782 The IGMP/MLD Query includes a full IP Header. The IP source address 783 of the query would match the anycast address on the pseudo interface. 784 The TTL of the outer header should be sufficient to reach the tunnel 785 endpoint and not mimic the inner header TTL which is typically 1 for 786 IGMP/MLD messages. 788 6.5. AMT Membership Update 790 An AMT Membership Update is sent to report a membership after a valid 791 Response MAC has been received. It contains the original IGMP/MLD 792 Membership/Listener Report or Leave/Done received over the AMT 793 pseudo-interface including the original IP header. It echoes the 794 Response MAC received in the AMT Membership Query so the respondent 795 can verify return routability to the originator. 797 It is sent from the destination address received in the Query to the 798 source address received in the Query which should both be the same as 799 the original Request. 801 The UDP source and destination port numbers should be the same ones 802 sent in the original Request. 804 The relay is not required to use the IP source address of the IGMP 805 Membership Report for any particular purpose. 807 The same Request Nonce and Response MAC can be used across multiple 808 AMT Membership Update messages without having to send individual AMT 809 Membership Query messages. 811 0 1 2 3 812 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 813 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 814 | Type=0x5 | Reserved | Response MAC | 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Response MAC (continued) | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Request Nonce | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | IGMP or MLD Message (including IP header) | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | ... | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 AMT Membership Update 827 6.5.1. Type 829 The type of the message. 831 6.5.2. Reserved 833 A 8-bit reserved field. Sent as 0, ignored on receipt. 835 6.5.3. Response MAC 837 The 48-bit MAC received in the Membership Query and echoed back in 838 the Membership Update. 840 6.5.4. Request Nonce 842 A 32-bit identifier used to distinguish this request. 844 6.5.5. IGMP/MLD Message (including IP Header) 846 The message contains either an IGMP Membership Report, an IGMP 847 Membership Leave, an MLD Multicast Listener Report, or an MLD 848 Listener Done. The IGMP or MLD version sent should be in response 849 the version of the query received in the AMT Membership Query. The 850 IGMP/MLD Message includes a full IP Header. 852 6.6. AMT IP Multicast Data 854 The AMT Data message is a UDP packet encapsulating the IP Multicast 855 data requested by the originator based on a previous AMT Membership 856 Update message. 858 It is sent from the unicast destination address of the Membership 859 update to the source address of the Membership Update. 861 The UDP source and destination port numbers should be the same ones 862 sent in the original Query. The UDP checksum SHOULD be 0 in the AMT 863 IP Multicast Data message. 865 The payload of the UDP packet contains the following fields. 867 0 1 2 3 868 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 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Type=0x6 | Reserved | IP Multicast Data ... | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | ... | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 AMT IP Multicast Data 877 6.6.1. Type 879 The type of the message. 881 6.6.2. Reserved 883 An 8-bit reserved field. Sent as 0, ignored on receipt. 885 6.6.3. IP Multicast Data 887 The original IP Multicast data packet that is being replicated by the 888 relay to the gateways including the original IP header. 890 7. AMT Gateway Details 892 This section details the behavior of an AMT Gateway, which may be a 893 router serving an AMT site, or the site may consist of a single host, 894 serving as its own gateway. 896 7.1. At Startup Time 898 At startup time, the AMT gateway will bring up an AMT pseudo- 899 interface to be used for encapsulation. The gateway needs to 900 discover an AMT Relay to send Membership Requests. It can send an 901 AMT Relay Discovery at startup time or wait until it has a group 902 membership to report. The AMT Relay Discovery message is sent to the 903 AMT Relay Anycast Address. A unicast address (which is treated as a 904 link-layer address to the encapsulation interface) is received in the 905 AMT Relay Advertisement message. The discovery process SHOULD be 906 done periodically (e.g., once a day) to re-resolve the unicast 907 address of a close relay. To prevent startup synchronization, the 908 timer SHOULD use at least 10 percent jitter. 910 If the gateway is serving as a local router, it SHOULD also function 911 as an IGMP/MLD Proxy, as described in [RFC4605], with its IGMP/MLD 912 host-mode interface being the AMT pseudo-interface. This enables it 913 to translate group memberships on its downstream interfaces into 914 IGMP/MLD Reports. Hosts receiving multicast packets through an AMT 915 gateway acting as a proxy should ensure that their M-RIB accepts 916 multicast packets from the AMT gateway for the sources it is joining. 918 7.2. Gateway Group and Source Addresses 920 To support sourcing traffic to SSM groups by a gateway with a global 921 unicast address, the AMT Subnet Anycast Prefix is treated as the 922 subnet prefix of the AMT pseudo-interface, and an anycast address is 923 added on the interface. This anycast address is formed by 924 concatenating the AMT Subnet Anycast Prefix followed by the high bits 925 of the gateway's global unicast address. 927 The remaining bits of its global unicast address are appended to the 928 SSM prefix to create the group address and any spare bits may be 929 allocated using local policy. 931 If a gateway wants to source multicast traffic, it must select the 932 gateway source address and SSM group address in such a way that the 933 AMT relay can have enough information to reconstruct the gateway's 934 unicast address when it receives an SSM join for the source. 936 Note that multiple gateways might end up with the same anycast 937 address assigned to their pseudo-interfaces. 939 7.2.1. IPv4 941 For example, if IANA assigns the IPv4 prefix x.y/16 as the AMT Subnet 942 Anycast Prefix, and the gateway has global unicast address a.b.c.d, 943 then the AMT Gateway's Anycast Source Address will be x.y.a.b. Since 944 the IPv4 SSM group range is 232/8, it MUST allocate IPv4 SSM groups 945 in the range 232.c.d/24. 947 Group: 948 8 16 8 949 +------------+------------------------+-------------+ 950 | SSM prefix | Low 16 bits of | Local | 951 | 232/8 | real source address | Policy | 952 +------------+------------------------+-------------+ 954 Source: 955 +-------------------------+-------------------------+ 956 |16-bit AMT unicast prefix| high 16 bits of real src| 957 +-------------------------+-------------------------+ 959 IPv4 format 961 This allows for 2^8 (256) IPv4 group addresses for use by each AMT 962 gateway. 964 7.2.2. IPv6 966 Similarly for IPv6, this is illustrated in the following figure. 968 Group: 969 32 64 32 970 +------------+------------------------+-------------+ 971 | SSM prefix | Low 64 bits of | Local | 972 | FF3x::/32 | real source address | Policy | 973 +------------+------------------------+-------------+ 975 Source: 976 +-------------------------+-------------------------+ 977 |64-bit AMT unicast prefix| high 64 bits of real src| 978 +-------------------------+-------------------------+ 980 IPv6 format 982 This allows for 2^32 (over 4 billion) IPv6 group addresses for use by 983 each AMT gateway. 985 7.3. Joining Groups with MBone Sources 987 The IGMP/MLD protocol usually operates by having the Querier 988 multicast an IGMP/MLD Query message on the link. This behavior does 989 not work on NBMA links which do not support multicast. Since the set 990 of gateways is typically unknown to the relay (and potentially quite 991 large), unicasting the queries is also impractical. The following 992 behavior is used instead. 994 Applications residing in a gateway should join groups on the AMT 995 pseudo-interface, causing IGMP/MLD Membership/Listener Reports to be 996 sent over that interface. When UDP encapsulating the membership 997 reports (and in fact any other messages, unless specified otherwise 998 in this document), the destination address in the outer IP header is 999 the relay's unicast address. Robustness is provided by the 1000 underlying IGMP/MLD protocol messages sent on the AMT pseudo- 1001 interface. In other words, the gateway does not need to retransmit 1002 IGMP/MLD Membership/Listener Reports and Leave/Done messages received 1003 on the pseudo-interface since IGMP/MLD will already do this. The 1004 gateway simply needs to encapsulate each IGMP/MLD Membership/Listener 1005 Report and Leave/Done message it receives. 1007 However, since periodic IGMP/MLD Membership/Listener Reports are sent 1008 in response to IGMP/MLD Queries, a mechanism to trigger periodic 1009 Membership/Listener Reports and Leave/Done messages is necessary. 1010 The gateway should use a timer to trigger periodic AMT Membership 1011 Updates. 1013 If the gateway is behind a firewall device, the firewall may require 1014 the gateway to periodically refresh the UDP state in the firewall at 1015 a shorter interval than the standard IGMP/MLD Query interval. AMT 1016 Requests can be sent periodically to solicit IGMP/MLD Queries. The 1017 interval at which the AMT Requests are sent should be configurable to 1018 ensure the firewall does not revert to blocking the UDP encapsulated 1019 IP Multicast data packets. When the AMT Query is received, it can be 1020 ignored unless it is time for a periodic AMT Membership Update. 1022 The relay can use the Querier's Robustness Variable (QRV) defined in 1023 [RFC3376] and [RFC3810] to adjust the number of Membership/Listener 1024 Reports that are sent by the host joining the group. 1026 7.4. Responding to Relay Changes 1028 When a gateway determines that its current relay is unreachable 1029 (e.g., upon receipt of an ICMP Unreachable message [RFC0792] for the 1030 relay's unicast address), it may need to repeat relay address 1031 discovery. However, care should be taken not to abandon the current 1032 relay too quickly due to transient network conditions. 1034 7.5. Joining SSM Groups with AMT Gateway Sources 1036 An IGMPv3/MLDv2 Report for a given (source, group) pair MAY be 1037 encapsulated directly to the source, when the source address belongs 1038 to the AMT Subnet Anycast Prefix. 1040 The "link-layer" address to use as the destination address in the 1041 outer IP header is obtained as follows. The source address in the 1042 inclusion list of the IGMPv3/MLDv2 report will be an AMT Gateway 1043 Anycast Address with the high bits of the address, and the remaining 1044 bits will be in the middle of the group address. 1046 Section 7.2 describes this format to recover the gateway source 1047 address. 1049 7.6. Receiving AMT Membership Updates by the Gateway 1051 When an AMT Request is received by the gateway from another gateway 1052 or relay, it follows the same 3-way handshake procedure a relay would 1053 follow if it received the AMT Request. It generates a MAC and 1054 responds with an AMT Membership Query. When the AMT Membership 1055 Update is received, it verifies the MAC and then processes the IGMP/ 1056 MLD Membership/Listener Report or Leave/Done. 1058 At the gateway, the IGMP/MLD packet should be an IGMPv3/MLDv2 source 1059 specific (S,G) join or leave. 1061 If S is not the AMT Gateway Anycast Address, the packet is silently 1062 discarded. If G does not contain the low bits of the global unicast 1063 address (as described above), the packet is also silently discarded. 1065 The gateway adds the source address (from the outer IP header) and 1066 UDP port of the report to a membership list for G. Maintaining this 1067 membership list may be done in any implementation-dependent manner. 1068 For example, it might be maintained by the "link-layer" inside the 1069 AMT pseudo-interface, making it invisible to the normal IGMP/MLD 1070 module. 1072 7.7. Sending data to SSM groups 1074 When multicast packets are sent on the AMT pseudo-interface, they are 1075 encapsulated as follows. If the group address is not an SSM group, 1076 then the packet is silently discarded (this memo does not currently 1077 provide a way to send to non-SSM groups). 1079 If the group address is an SSM group, then the packet is unicast 1080 encapsulated to each remote node from which the gateway has received 1081 an IGMPv3/MLDv2 report for the packet's (source, group) pair. 1083 8. Relay Router Details 1085 8.1. At Startup time 1087 At startup time, the relay router will bring up an NBMA-style AMT 1088 pseudo-interface. It shall also add the AMT Relay Anycast Address on 1089 some interface. 1091 The relay router shall then advertise the AMT Relay Anycast Prefix 1092 into the unicast-only Internet, as if it were a connection to an 1093 external network. When the advertisement is done using BGP, the AS 1094 path leading to the AMT Relay Anycast Prefix shall include the 1095 identifier of the local AS. 1097 The relay router shall also enable IGMPv3/MLDv2 on the AMT pseudo- 1098 interface, except that it shall not multicast Queries (this might be 1099 done, for example, by having the AMT pseudo-device drop them, or by 1100 having the IGMP/MLD module not send them in the first place). 1102 Finally, to support sourcing SSM traffic from AMT sites, the AMT 1103 Subnet Anycast Prefix is assigned to the AMT pseudo-interface, and 1104 the AMT Subnet Anycast Prefix is injected by the AMT Relay into the 1105 M-RIB of MBGP. 1107 8.2. Receiving Relay Discovery messages sent to the Anycast Address 1109 When a relay receives an AMT Relay Discovery message directed to the 1110 AMT Relay Anycast Address, it should respond with an AMT Relay 1111 Advertisement containing its unicast address. The source and 1112 destination addresses of the advertisement should be the same as the 1113 destination and source addresses of the discovery message 1114 respectively. Further, the nonce in the discovery message MUST be 1115 copied into the advertisement message. 1117 8.3. Receiving Membership Updates from AMT Gateways 1119 The relay operates passively, sending no periodic IGMP/MLD Queries 1120 but simply tracking membership information according to AMT Request/ 1121 Query/Membership Update tuples received. In addition, the relay must 1122 also do explicit membership tracking, as to which gateways on the AMT 1123 pseudo-interface have joined which groups. Once an AMT Membership 1124 Update has been successfully received, it updates the forwarding 1125 state for the appropriate group and source (if provided). When data 1126 arrives for that group, the traffic must be encapsulated to each 1127 gateway which has joined that group or (S,G). 1129 The explicit membership tracking and unicast replication may be done 1130 in any implementation-specific manner. Some examples are: 1132 1. The AMT pseudo-device driver might track the group information 1133 and perform the replication at the "link-layer", with no changes 1134 to a pre-existing IGMP/MLD module. 1136 2. The IGMP/MLD module might have native support for explicit 1137 membership tracking, especially if it supports other NBMA-style 1138 interfaces. 1140 If a relay wants to affect the rate at which the AMT Requests are 1141 originated from a gateway, it can tune the membership timeout by 1142 adjusting the Querier's Query Interval Code (QQIC) field in the IGMP/ 1143 MLD Query contained within the AMT Membership Query message. The 1144 QQIC field is defined in [RFC3376] and [RFC3810]. However, since the 1145 gateway may need to send AMT Requests frequently enough to prevent 1146 firewall state from timing out, the relay may be limited in its 1147 ability to spread out Requests coming from a gateway by adjusting the 1148 QQIC field. 1150 8.4. Receiving (S,G) Joins from the Native Side, for AMT Sources 1152 The relay sends an IGMPv3/MLDv2 report to the AMT source as described 1153 above in Section 5.1.2 1155 9. IANA Considerations 1157 9.1. IPv4 and IPv6 Anycast Prefix Allocation 1159 The IANA should allocate an IPv4 prefix and an IPv6 prefix dedicated 1160 to the public AMT Relays to advertise to the native multicast 1161 backbone. The prefix length should be determined by the IANA; the 1162 prefix should be large enough to guarantee advertisement in the 1163 default-free BGP networks. 1165 9.1.1. IPv4 1167 A prefix length of 16 will meet this requirement. 1169 9.1.2. IPv6 1171 A prefix length of 32 will meet this requirement. IANA has 1172 previously set aside the range 2001::/16 for allocating prefixes for 1173 this purpose. 1175 9.2. IPv4 and IPv6 AMT Subnet Prefix Allocation 1177 It should also be noted that this prefix length directly affects the 1178 number of groups available to be created by the AMT gateway: in the 1179 IPv4 case, a prefix length of 16 gives 256 groups, and a prefix 1180 length of 8 gives 65536 groups. 1182 9.2.1. IPv4 1184 As described above in Section 7.2.1 an IPv4 prefix with a length of 1185 16 is requested for this purpose. 1187 9.2.2. IPv6 1189 As described above in Section 7.2.2 an IPv6 prefix with a length of 1190 32 is requested. 1192 9.3. UDP Port number 1194 IANA has previously allocated UDP reserved port number 2268 for AMT 1195 encapsulation. 1197 All allocations are a one time effort and there will be no need for 1198 any recurring assignment after this stage. 1200 10. Security Considerations 1202 The anycast technique introduces a risk that a rogue router or a 1203 rogue AS could introduce a bogus route to the AMT Relay Anycast 1204 prefix, and thus divert the traffic. Network managers have to 1205 guarantee the integrity of their routing to the AMT Relay Anycast 1206 prefix in much the same way that they guarantee the integrity of all 1207 other routes. 1209 Within the native MBGP infrastructure, there is a risk that a rogue 1210 router or a rogue AS could inject a false route to the AMT Subnet 1211 Anycast Prefix, and thus divert joins and cause RPF failures of 1212 multicast traffic. As the AMT Subnet Anycast Prefix will be 1213 advertised by multiple entities, guaranteeing the integrity of this 1214 shared MBGP prefix is much more challenging than verifying the 1215 correctness of a regular unicast advertisement. To mitigate this 1216 threat, routing operators should configure the BGP sessions to filter 1217 out any more specific advertisements for the AMT Subnet Anycast 1218 Prefix. 1220 Gateways and relays will accept and decapsulate multicast traffic 1221 from any source from which regular unicast traffic is accepted. If 1222 this is for any reason felt to be a security risk, then additional 1223 source address based packet filtering MUST be applied: 1225 1. To prevent a rogue sender (that can't do traditional spoofing 1226 because of e.g. access lists deployed by its ISP) from making use 1227 of AMT to send packets to an SSM tree, a relay that receives an 1228 encapsulated multicast packet MUST discard the multicast packet 1229 if the IP source address in the outer header does not match the 1230 source address that would be extracted using the rules of 1231 Section 7.2. 1233 2. A gateway MUST discard encapsulated multicast packets if the 1234 source address in the outer header is not the address to which 1235 the encapsulated join message was sent. An AMT Gateway that 1236 receives an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard the 1237 message if the IP destination address in the outer header does 1238 not match the source address that would be extracted using the 1239 rules of Section 7.2. 1241 11. Contributors 1243 The following people provided significant contributions to earlier 1244 versions of this draft. 1246 Dirk Ooms 1247 OneSparrow 1248 Belegstraat 13; 2018 Antwerp; Belgium 1249 EMail: dirk@onesparrow.com 1251 12. Acknowledgments 1253 Most of the mechanisms described in this document are based on 1254 similar work done by the NGTrans WG for obtaining automatic IPv6 1255 connectivity without explicit tunnels ("6to4"). Tony Ballardie 1256 provided helpful discussion that inspired this document. 1258 In addition, extensive comments were received from Pekka Savola, Greg 1259 Shepherd, Dino Farinacci, Toerless Eckert, Marshall Eubanks, John 1260 Zwiebel, and Lenny Giuliano. 1262 Juniper Networks was instrumental in funding several versions of this 1263 draft as well as an open source implementation. 1265 13. References 1267 13.1. Normative References 1269 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1270 RFC 792, September 1981. 1272 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1273 Thyagarajan, "Internet Group Management Protocol, Version 1274 3", RFC 3376, October 2002. 1276 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1277 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1279 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1280 "Internet Group Management Protocol (IGMP) / Multicast 1281 Listener Discovery (MLD)-Based Multicast Forwarding 1282 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1284 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 1285 IP", RFC 4607, August 2006. 1287 13.2. Informative References 1289 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 1290 RFC 1112, August 1989. 1292 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 1293 Anycasting Service", RFC 1546, November 1993. 1295 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 1296 Hashing for Message Authentication", RFC 2104, 1297 February 1997. 1299 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1300 Requirement Levels", BCP 14, RFC 2119, March 1997. 1302 [RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 1303 Tunnel Broker", RFC 3053, January 2001. 1305 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 1306 via IPv4 Clouds", RFC 3056, February 2001. 1308 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 1309 RFC 3068, June 2001. 1311 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1312 Architecture", RFC 4291, February 2006. 1314 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1315 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1316 Protocol Specification (Revised)", RFC 4601, August 2006. 1318 Authors' Addresses 1320 Dave Thaler 1321 Microsoft Corporation 1322 One Microsoft Way 1323 Redmond, WA 98052-6399 1324 USA 1326 Phone: +1 425 703 8835 1327 Email: dthaler@microsoft.com 1329 Mohit Talwar 1330 Microsoft Corporation 1331 One Microsoft Way 1332 Redmond, WA 98052-6399 1333 USA 1335 Phone: +1 425 705 3131 1336 Email: mohitt@microsoft.com 1338 Amit Aggarwal 1339 Microsoft Corporation 1340 One Microsoft Way 1341 Redmond, WA 98052-6399 1342 USA 1344 Phone: +1 425 706 0593 1345 Email: amitag@microsoft.com 1347 Lorenzo Vicisano 1348 Cisco Systems 1349 170 West Tasman Dr. 1350 San Jose, CA 95134 1351 USA 1353 Phone: +1 408 525 2530 1354 Email: lorenzo@cisco.com 1355 Tom Pusateri 1356 !j 1357 222 E. Jones Ave. 1358 Wake Forest, NC 27587 1359 USA 1361 Email: pusateri@bangj.com 1363 Full Copyright Statement 1365 Copyright (C) The IETF Trust (2007). 1367 This document is subject to the rights, licenses and restrictions 1368 contained in BCP 78, and except as set forth therein, the authors 1369 retain all their rights. 1371 This document and the information contained herein are provided on an 1372 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1373 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1374 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1375 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1376 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1377 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1379 Intellectual Property 1381 The IETF takes no position regarding the validity or scope of any 1382 Intellectual Property Rights or other rights that might be claimed to 1383 pertain to the implementation or use of the technology described in 1384 this document or the extent to which any license under such rights 1385 might or might not be available; nor does it represent that it has 1386 made any independent effort to identify any such rights. Information 1387 on the procedures with respect to rights in RFC documents can be 1388 found in BCP 78 and BCP 79. 1390 Copies of IPR disclosures made to the IETF Secretariat and any 1391 assurances of licenses to be made available, or the result of an 1392 attempt made to obtain a general license or permission for the use of 1393 such proprietary rights by implementers or users of this 1394 specification can be obtained from the IETF on-line IPR repository at 1395 http://www.ietf.org/ipr. 1397 The IETF invites any interested party to bring to its attention any 1398 copyrights, patents or patent applications, or other proprietary 1399 rights that may cover technology that may be required to implement 1400 this standard. Please address the information to the IETF at 1401 ietf-ipr@ietf.org. 1403 Acknowledgment 1405 Funding for the RFC Editor function is provided by the IETF 1406 Administrative Support Activity (IASA).