idnits 2.17.1 draft-ietf-mboned-auto-multicast-04.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.a on line 19. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1042. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1049. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1061), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 50. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 96: '... The keywords MUST, MUST NOT, REQUIR...' RFC 2119 keyword, line 97: '... SHOULD NOT, RECOMMENDED, MAY, and O...' RFC 2119 keyword, line 658: '... local router, it SHOULD also function...' RFC 2119 keyword, line 662: '...ts. The gateway MUST also advertise i...' RFC 2119 keyword, line 739: '...he remaining 24 bits MUST be generated...' (7 more instances...) 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC1112' is mentioned on line 87, but not defined == Missing Reference: 'RFC-2119' is mentioned on line 99, but not defined == Unused Reference: 'IGMPv3' is defined on line 957, but no explicit reference was found in the text == Unused Reference: 'MLDv2' is defined on line 961, but no explicit reference was found in the text == Unused Reference: 'Brad88' is defined on line 981, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-06 -- Obsolete informational reference (is this intentional?): RFC 3068 (ref. 'ANYCAST') (Obsoleted by RFC 7526) -- Obsolete informational reference (is this intentional?): RFC 2362 (ref. 'PIMSM') (Obsoleted by RFC 4601, RFC 5059) Summary: 10 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dave Thaler 3 Internet-Draft Mohit Talwar 4 February 2005 Amit Aggarwal 5 Expires: August 21, 2005 Microsoft 6 Lorenzo Vicisano 7 Cisco Systems 8 Tom Pusateri 9 Juniper Networks 11 Automatic IP Multicast Without Explicit Tunnels (AMT) 12 draft-ietf-mboned-auto-multicast-04.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 Abstract 39 Automatic Multicast Tunneling (AMT) allows multicast communication 40 amongst isolated multicast-enabled sites or hosts, attached to a 41 network which has no native multicast support. It also enables them 42 to exchange multicast traffic with the native multicast 43 infrastructure (MBone) and does not require any manual configuration. 44 AMT uses an encapsulation interface so that no changes to a host 45 stack or applications are required, all protocols (not just UDP) are 46 handled, and there is no additional overhead in core routers. 48 Copyright Notice 50 Copyright (C) The Internet Society (2005). All Rights Reserved. 52 1. Introduction 54 The primary goal of this document is to foster the deployment of 55 native IP multicast by enabling a potentially large number of nodes 56 to connect to the already present multicast infrastructure. 57 Therefore, the techniques discussed here should be viewed as an 58 interim solution to help in the various stages of the transition to a 59 native multicast network. 61 To allow fast deployment, the solution presented here only requires 62 small and concentrated changes to the network infrastructure, and no 63 changes at all to user applications or to the socket API of end- 64 nodes' operating systems. The protocol introduced in this 65 specification is deployed in a few strategically-placed network nodes 66 and in user-installable software modules (pseudo device drivers 67 and/or user-mode daemons) that reside underneath the socket API of 68 end-nodes' operating systems. This mechanism is very similar to that 69 used by "6to4" [6TO4, ANYCAST] to get automatic IPv6 connectivity. 71 Effectively, AMT treats the unicast-only internetwork as a large non- 72 broadcast multi-access (NBMA) link layer, over which we require the 73 ability to multicast. To do this, multicast packets being sent to or 74 from a site must be encapsulated in unicast packets. If the group 75 has members in multiple sites, AMT encapsulation of the same 76 multicast packet will take place multiple times by necessity. 78 The following problems are addressed: 80 1. Allowing isolated sites/hosts to receive the SSM flavor of 81 multicast ([SSM]). 83 2. Allowing isolated sites/hosts to transmit the SSM flavor of 84 multicast. 86 3. Allowing isolated sites/hosts to receive general multicast (ISM 87 [RFC1112]). 89 This document does not address allowing isolated sites/hosts to 90 transmit general multicast. We expect that other solutions (e.g., 91 Tunnel Brokers, a la [BROKER]) will be used for sites that desire 92 this capability. 94 2. Requirements Terminology 96 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 97 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 98 document, are to be interpreted as described in [RFC-2119]. 100 3. Definitions 102 +---------------+ Internet +---------------+ 103 | AMT Site | | MBone | 104 | | AMT | | 105 | +------+----+ Relay +----+----+ AMT | 106 | |AMT Gateway| Anycast |AMT Relay| Subnet | 107 | | +-----+-+ Prefix +-+-----+ | Prefix | 108 | | |AMT IF | <--------|AMT IF | |--------> | 109 | | +-----+-+ +-+-----+ | | 110 | +------+----+ +----+----+ | 111 | | | | 112 +---------------+ +---------------+ 114 Figure 1: Automatic Multicast Definitions. 116 AMT Pseudo-Interface 117 AMT encapsulation of multicast packets inside unicast packets 118 occurs at a point that is logically equivalent to an interface, 119 with the link layer being the unicast-only network. This point is 120 referred to as a pseudo-interface. Some implementations may treat 121 it exactly like any other interface and others may treat it like a 122 tunnel end-point. 124 AMT Gateway 125 A host, or a site gateway router, supporting an AMT Pseudo- 126 Interface. It does not have native multicast connectivity to the 127 native multicast backbone infrastructure. It is simply referred 128 to in this document as a "gateway". 130 AMT Site 131 A multicast-enabled network not connected to the multicast 132 backbone served by an AMT Gateway. It could also be a stand- 133 alone AMT Gateway. 135 AMT Relay Router 136 A multicast router configured to support transit routing between 137 AMT Sites and the native multicast backbone infrastructure. The 138 relay router has one or more interfaces connected to the native 139 multicast infrastructure, zero or more interfaces connected to the 140 non-multicast capable internetwork, and an AMT pseudo-interface. 141 It is simply referred to in this document as a "relay". 143 As with [6TO4], we assume that normal multicast routers do not 144 want to be tunnel endpoints (especially if this results in high 145 fanout), and similarly that service providers do not want 146 encapsulation to arbitrary routers. Instead, we assume that 147 special-purpose routers will be deployed that are suitable for 148 serving as relays. 150 AMT Relay Anycast Prefix 151 A well-known address prefix used to advertise (into the unicast 152 routing infrastructure) a route to an available AMT Relay Router. 153 This could also be private (i.e., not well-known) for a private 154 relay. 156 Prefixes for both IPv4 and IPv6 will be assigned in a future 157 version of this draft. 159 AMT Relay Anycast Address 160 An anycast address which is used to reach the nearest AMT Relay 161 Router. 163 This address corresponds to the lowest address in the AMT Relay 164 Anycast Prefix. 166 AMT Unicast Autonomous System ID 167 A 16-bit Autonomous System ID, for use in BGP in accordance to 168 this memo. AS 10888 might be usable for this, but for now we'll 169 assume it's different, to avoid confusion. This number represents 170 a "pseudo-AS" common to all AMT relays using the well known AMT 171 Relay Anycast Prefix (private relays use their own ID). 173 To protect themselves from erroneous advertisements, managers of 174 border routers often use databases to check the relation between 175 the advertised network and the last hop in the AS path. 176 Associating a specific AS number with the AMT Relay Anycast 177 Address allows us to enter this relationship in the databases used 178 to check inter-domain routing [ANYCAST]. 180 AMT Subnet Prefix 181 A well-known address prefix used to advertise (into the M-RIB of 182 the native multicast-enabled infrastructure) a route to AMT Sites. 184 This prefix will be used to enable sourcing SSM traffic from an 185 AMT Gateway. 187 AMT Gateway Anycast Address 188 An anycast address in the AMT Subnet Prefix range, which is used 189 by an AMT Gateway to enable sourcing SSM traffic from local 190 applications. 192 AMT Multicast Autonomous System ID 193 A 16-bit Autonomous system ID, for use in MBGP in accordance to 194 this memo. This number represents a "pseudo-AS" common to all AMT 195 relays using the well known AMT Subnet Prefix (private relays use 196 their own ID). We assume that the existing AS 10888 is suitable 197 for this purpose. (Note: if this is a problem, a different one 198 would be fine.) 200 4. Overview 202 4.1. Receiving Multicast in an AMT Site 204 Internet 205 +---------------+ +---------------+ 206 | AMT Site | 2. 3-way Membership | MBone | 207 | | Handshake | | 208 | 1. Join +---+---+ =================> +---+---+ | 209 | +---->|Gateway| | Relay | | 210 | | +---+---+ <================= +---+---+ | 211 | R-+ | 3. Receive Data | | 212 +---------------+ +---------------+ 214 Figure 2: Receiving Multicast in an AMT Site. 216 AMT relays and gateways cooperate to transmit multicast traffic 217 sourced within the native multicast infrastructure to AMT sites: 218 relays receive the traffic natively and unicast-encapsulate it to 219 gateways; gateways decapsulate the traffic and possibly forward it 220 into the AMT site. 222 Each gateway has an AMT pseudo-interface that serves as a default 223 multicast route. Requests to join a multicast session are sent to 224 this interface and encapsulated to a particular relay reachable 225 across the unicast-only infrastructure. 227 Each relay has an AMT pseudo-interface too. Multicast traffic sent 228 on this interface is encapsulated to zero or more gateways that have 229 joined to the relay. The AMT recipient-list is determined for each 230 multicast session. This requires the relay to keep state for each 231 gateway which has joined a particular group or (source, group) pair). 232 Multicast packets from the native infrastructure behind the relay 233 will be sent to each gateway which has requested them. 235 All multicast packets (data and control) are encapsulated in unicast 236 packets. To work across NAT's, the encapsulation is done over UDP 237 using the IANA reserved AMT port number. 239 Each relay, plus the set of all gateways using the relay, together 240 are thought of as being on a separate logical NBMA link. This 241 implies that the AMT recipient- list is a list of "link layer" 242 addresses which are (IP address, UDP port) pairs. 244 Since the number of gateways using a relay can be quite large, and we 245 expect that most sites will not want to receive most groups, an 246 explicit-joining protocol is required for gateways to communicate 247 group membership information to a relay. The two most likely 248 candidates are the IGMP/MLD [IGMPv3/MLDv2] protocol, and the PIM- 249 Sparse Mode [PIMSM] protocol. Since an AMT gateway may be a host, 250 and hosts typically do not implement routing protocols, gateways will 251 use IGMP/MLD as described in Section 5 below. This allows a host 252 kernel (or a pseudo device driver) to easily implement AMT gateway 253 behavior, and obviates the relay from the need to know whether a 254 given gateway is a host or a router. From the relay's perspective, 255 all gateways are indistinguishable from hosts on an NBMA leaf 256 network. 258 4.1.1. Scalability Considerations 260 It is possible that millions of hosts will enable AMT gateway 261 functionality and so an important design goal is not to create 262 gateway state in each relay until the gateway joins a multicast 263 group. But even the requirement that a relay keep group state per 264 gateway that has joined a group introduces potential scalability 265 concerns. 267 Scalability of AMT can be achieved by adding more relays, and using 268 an appropriate relay discovery mechanism for gateways to discover 269 relays. The solution we adopt is to assign an anycast address to 270 relays. However, simply sending periodic membership reports to the 271 anycast address can cause duplicates. Specifically, if routing 272 changes such that a different relay receives a periodic membership 273 report, both the new and old relays will encapsulate data to the AMT 274 site until the old relay's state times out. This is obviously 275 undesirable. Instead, we use the anycast address merely to find the 276 unicast address of a relay to which membership reports are sent. 278 Since adding another relay has the result of adding another 279 independent NBMA link, this allows the gateways to be spread out 280 among more relays so as to keep the number of gateways per relay at a 281 reasonable level. 283 4.1.2. Spoofing Considerations 285 An attacker could affect the group state in the relay or gateway by 286 spoofing the source address in the join or leave reports. This can be 287 used to launch reflection or denial of service attacks on the target. 288 Such attacks can be mitigated by using a three way handshake between 289 the gateway and the relay for each multicast membership report or 290 leave. 292 When a gateway or relay wants to send a membership report, it first 293 sends an AMT Request with a request nonce in it. The receiving side 294 (the respondent) can calculate a message authentication code (MAC) 295 based on the source IP address of the Request, the source UDP port, 296 the request nonce, and a secret key known only to the respondent. 297 The algorithm used to calculate the MAC does not have to be 298 standardized since the respondent generates and verifies the MAC and 299 the originator simply echoes it. 301 An AMT Membership Query is sent back including the request nonce and 302 the MAC to the originator of the Request. The originator then sends 303 the IGMP/MLD Membership/Listener Report or Leave/Done along with the 304 request nonce and the received MAC back to the respondent finalizing 305 the 3-way handshake. 307 Upon reception, the respondent can recalculate the MAC based on the 308 source IP address, the source UDP port, the request nonce, and the 309 local secret. The IGMP/MLD message is only accepted if the received 310 MAC matches the calculated MAC. 312 The local secret never has to be shared with the other side. It is 313 only used to verify return routability of the originator. 315 4.2. Sourcing Multicast from an AMT site 317 Two cases are discussed below: multicast traffic sourced in an AMT 318 site and received in the MBone, and multicast traffic sourced in an 319 AMT site and received in another AMT site. 321 In both cases only SSM sources are supported. Furthermore this 322 specification only deals with the source residing directly in the 323 gateway. To enable a generic node in an AMT site to source 324 multicast, additional coordination between the gateway and the 325 source-node is required. 327 The general mechanism used to join towards AMT sources is based on 328 the following: 330 1. Applications residing in the gateway use addresses in the AMT 331 Subnet Prefix to send multicast, as a result of sourcing traffic 332 on the AMT pseudo-interface. 334 2. The AMT Subnet Prefix is advertised for RPF reachability in the M- 335 RIB by relays and gateways. 337 3. Relays or gateways that receive a join for a source/group pair use 338 information encoded in the address pair to rebuild the address of 339 the gateway (source) to which to encapsulate the join (see Section 340 5 for more details). The membership reports use the same three way 341 handshake as outlined in Section 4.1.2. 343 4.2.1. Supporting Site-MBone Multicast 345 Internet 346 +---------------+ +---------------+ 347 | AMT Site | 2. 3-way Membership | MBone | 348 | | Handshake | | 349 | +---+---+ <================= +---+---+ 1. Join | 350 | |Gateway| | Relay |<-----+ | 351 | +---+---+ =================> +---+---+ | | 352 | | 3. Receive Data | +-R | 353 +---------------+ +---------------+ 355 Figure 3: Site-MBone Multicast. 357 If a relay receives an explicit join from the native infrastructure, 358 for a given (source, group) pair where the source address belongs to 359 the AMT Subnet Prefix, then the relay will periodically (using the 360 rules specified in Section 4.1.2) encapsulate membership updates for 361 the group to the gateway. The gateway must keep state per relay from 362 which membership reports have been sent, and forward multicast 363 traffic from the site to all relays from which membership reports 364 have been received. The choice of whether this state and replication 365 is done at the link-layer (i.e., by the tunnel interface) or at the 366 network-layer is implementation dependent. 368 If there are multiple relays present, this ensures that data from the 369 AMT site is received via the closest relay to the receiver. This is 370 necessary when the routers in the native multicast infrastructure 371 employ Reverse-Path Forwarding (RPF) checks against the source 372 address, such as occurs when [PIMSM] is used by the multicast 373 infrastructure. 375 The solution above will scale to an arbitrary number of relays, as 376 long at the number of relays requiring multicast traffic from a given 377 AMT site remains reasonable enough to not overly burden the site's 378 gateway. 380 4.2.2. Supporting Site-Site Multicast 382 Internet 383 +---------------+ +---------------+ 384 | AMT Site | 2. 3-way Membership | AMT Site | 385 | | Handshake | | 386 | +---+---+ <================= +---+---+ 1. Join | 387 | |Gateway| |Gateway|<-----+ | 388 | +---+---+ =================> +---+---+ | | 389 | | 3. Receive Data | +-R | 390 +---------------+ +---------------+ 392 Figure 4: Site-Site Multicast. 394 Since we require gateways to accept membership reports, as described 395 above, it is also possible to support multicast among AMT sites, 396 without requiring assistance from any relays. 398 When a gateway wants to join a given (source, group) pair, where the 399 source address belongs to the AMT Subnet Prefix, then the gateway 400 will periodically unicast encapsulate an IGMPv3/MLDv2 [IGMPv3/MLDv2] 401 Report directly to the site gateway for the source. 403 We note that this can result in a significant amount of state at a 404 site gateway sourcing multicast to a large number of other AMT sites. 405 However, it is expected that this is not unreasonable for two 406 reasons. First, the gateway does not have native multicast 407 connectivity, and as a result is likely doing unicast replication at 408 present. The amount of state is thus the same as what such a site 409 already deals with. Secondly, any site expecting to source traffic to 410 a large number of sites could get a point-to-point tunnel to the 411 native multicast infrastructure, and use that instead of AMT. 413 5. Message Formats 415 5.1. AMT Relay Discovery 417 The AMT Relay Discovery message is a UDP packet sent from the AMT 418 gateway unicast address to the AMT relay anycast address to discover 419 the unicast address of an AMT relay. 421 The UDP source port is uniquely selected by the local host operating 422 system. The UDP destination port is the IANA reserved AMT port 423 number. 425 The payload of the UDP packet contains the following fields. 427 0 1 2 3 428 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 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 430 | Type=0x1 | Reserved | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | Discovery Nonce | 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 Fields: 437 Type 438 The type of the message. 440 Reserved 441 A 24-bit reserved field. Sent as 0, ignored on receipt. 443 Discovery Nonce 444 A 32-bit random value generated by the gateway and replayed by the 445 relay. 447 5.2. AMT Relay Advertisement 449 The AMT Relay Advertisement message is a UDP packet sent from the AMT 450 relay anycast address to the source of the discovery message. 452 The UDP source port is the IANA reserved AMT port number and the UDP 453 destination port is the source port received in the Discovery 454 message. 456 The payload of the UDP packet contains the following fields. 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Type=0x2 | Reserved | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Discovery Nonce | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | Relay Address | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 Fields: 470 Type 471 The type of the message. 473 Reserved 474 A 24-bit reserved field. Sent as 0, ignored on receipt. 476 Discovery Nonce 477 A 32-bit random value replayed from the discovery message. 479 Relay Address 480 The unicast IPv4 or IPv6 address of the AMT relay. The family can 481 be determined by the length of the Advertisement. 483 5.3. AMT Request 485 A Request packet is sent to begin a 3-way handshake for sending an 486 IGMP/MLD Membership/Listener Report or Leave/Done. It can be sent 487 from a gateway to a relay, from a gateway to another gateway, or from 488 a relay to a gateway. 490 It is sent from the originator's unique unicast address to the 491 respondents' unique unicast address. 493 The UDP source port is uniquely selected by the local host operating 494 system. It can be different for each Request and different from the 495 source port used in Discovery messages but does not have to be. The 496 UDP destination port is the IANA reserved AMT port number. 498 Fields: 500 Type 501 The type of the message. 503 0 1 2 3 504 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 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Type=0x3 | Reserved | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Request Nonce | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 Reserved 512 A 24-bit reserved field. Sent as 0, ignored on receipt. 514 Request Nonce 515 A 32-bit identifier used to distinguish this request. 517 5.4. AMT Membership Query 519 An AMT Membership Query packet is sent from the relay back to the 520 originator to solicit an AMT Membership Update while confirming the 521 source of the original request. It contains a relay Message 522 Authentication Code (MAC) that is a cryptographic hash of a private 523 secret, the originators address, and the request nonce. 525 It is sent from the destination address received in the Request to 526 the source address received in the Request. 528 The UDP source port is the IANA reserved AMT port number and the UDP 529 destination port is the source port received in the Request message. 531 0 1 2 3 532 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 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | Type=0x4 | Reserved | Response MAC | 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 | Response MAC (continued) | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | Request Nonce | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Fields: 543 Type 544 The type of the message. 546 Reserved 547 An 8-bit reserved field. Sent as 0, ignored on receipt. 549 Response MAC 550 A 48-bit hash generated by the respondent and sent to the 551 originator for inclusion in the AMT Membership Update. The 552 algorithm used for this is chosen by the respondent. One algorithm 553 that could be used is HMAC-MD5-48 [HMAC]. 555 Request Nonce 556 A 32-bit identifier used to distinguish this request echoed back 557 to the originator. 559 5.5. AMT Membership Update 561 An AMT Membership Update is sent from the originator to the 562 respondent containing the original IGMP/MLD Membership/Listener 563 Report or Leave/Done received over the AMT pseudo-interface. It 564 echoes the Response MAC received in the AMT Membership Query so the 565 respondent can verify return routability to the originator. 567 It is sent from the destination address received in the Query to the 568 source address received in the Query which should both be the same as 569 the original Request. 571 The UDP source and destination port numbers should be the same ones 572 sent in the original Request. 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Type=0x5 | Reserved | Response MAC | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Response MAC (continued) | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | Request Nonce | 582 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 583 | IGMP/MLD Message | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | ... | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 Fields: 590 Type 591 The type of the message. 593 Reserved 594 An 8-bit reserved field. Sent as 0, ignored on receipt. 596 Response MAC 597 The 48-bit MAC received in the Membership Query and echoed back in 598 the Membership Update. 600 Request Nonce 601 A 32-bit identifier used to distinguish this request. 603 5.6. AMT Multicast Data 605 The AMT Data message is a UDP packet encapsulating the data requested 606 by the originator based on a previous AMT Membership Update message. 608 It is sent from the unicast destination address of the Membership 609 update to the source address of the Membership Update. 611 The UDP source and destination port numbers should be the same ones 612 sent in the original Query. 614 The payload of the UDP packet contains the following fields. 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Type=0x6 | Reserved | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Multicast Data | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | ... | 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 626 Fields: 628 Type 629 The type of the message. 631 Reserved 632 A 24-bit reserved field. Sent as 0, ignored on receipt. 634 UDP Multicast Data 635 The original Multicast UDP data packet that is being replicated by 636 the relay to the gateways. 638 6. AMT Gateway Details 640 This section details the behavior of an AMT Gateway, which may be a 641 router serving an AMT site, or the site may consist of a single host, 642 serving as its own gateway. 644 6.1. At Startup Time 646 At startup time, the AMT gateway will bring up an AMT pseudo- 647 interface, to be used for encapsulation. The gateway will then send 648 a AMT Relay Discovery message to the AMT Relay Anycast Address, and 649 note the unicast address (which is treated as a link-layer address to 650 the encapsulation interface) from the AMT Relay Advertisement 651 message. This discovery should be done periodically (e.g., once a 652 day) to re-resolve the unicast address of a close relay. The gateway 653 also initializes a timer used to send periodic membership reports to 654 a random value from the interval [0, [Query Interval]] before sending 655 the first periodic report, in order to prevent startup 656 synchronization (e.g., after a power outage). 658 If the gateway is serving as a local router, it SHOULD also function 659 as an IGMP/MLD Proxy, as described in [PROXY], with its IGMP/MLD 660 host-mode interface being the AMT pseudo-interface. This enables it 661 to translate group memberships on its downstream interfaces into 662 IGMP/MLD Reports. The gateway MUST also advertise itself as the 663 default route for multicast in the M-RIB (or it must be the default 664 unicast router if unicast and multicast topologies are congruent). 665 Also, if a shared tree routing protocol is used inside the AMT site, 666 each tree-root must be a gateway, e.g., in PIM-SM each RP must be a 667 gateway. 669 Finally, to support sourcing traffic to SSM groups by a gateway with 670 a global unicast address, the AMT Subnet Prefix is treated as the 671 subnet prefix of the AMT pseudo-interface, and an anycast address is 672 added on the interface. This anycast address is formed by 673 concatenating the AMT Subnet Prefix followed by the high bits of the 674 gateway's global unicast address. For example, if IANA assigns the 675 IPv4 prefix x.y/16 as the AMT Subnet Prefix, and the gateway has 676 global unicast address a.b.c.d, then the AMT Gateway's Anycast 677 Address will be x.y.a.b. Note that multiple gateways might end up 678 with the same anycast address assigned to their pseudo-interfaces. 680 6.2. Joining Groups with MBone Sources 682 The IGMP/MLD protocol usually operates by having the Querier 683 multicast an IGMP/MLD Query message on the link. This behavior does 684 not work on NBMA links which do not support multicast. Since the set 685 of gateways is typically unknown to the relay (and potentially quite 686 large), unicasting the queries is also impractical. The following 687 behavior is used instead. 689 Applications residing in a gateway should join groups on the AMT 690 pseudo-interface, causing IGMP/MLD Membership/Listener Reports to be 691 sent over that interface. When UDP encapsulating the membership 692 reports (and in fact any other messages, unless specified otherwise 693 in this document), the destination address in the outer IP header is 694 the relay's unicast address. Robustness is provided by the 695 underlying IGMP/MLD protocol messages sent on the AMT pseudo- 696 interface. In other words, the gateway does not need to retransmit 697 IGMP/MLD Membership/Listener Reports and Leave/Done messages received 698 on the pseudo-interface since IGMP/MLD will already do this. The 699 gateway simply needs to encapsulate each IGMP/MLD Membership/Listener 700 Report and Leave/Done message it receives. 702 However, since periodic IGMP/MLD Membership/Listener Reports are sent 703 in response to IGMP/MLD Queries, some mechanism to trigger periodic 704 Membership/Listener Reports and Leave/Done messages are necessary. 705 This can be achieved in any implementation-specific manner. Some 706 possibilities include: 708 1. The AMT pseudo-interface might periodically manufacture 709 IGMPv3/MLDv2 Queries as if they had been received from an IGMP/MLD 710 Querier, and deliver them to the IP layer, after which normal 711 IGMP/MLD behavior will cause the appropriate reports to be sent. 713 2. The IGMP/MLD module itself might provide an option to operate in 714 periodic mode on specific interfaces. 716 If the gateway is behind a firewall device, the firewall may require 717 the gateway to periodically refresh the UDP state in the firewall at 718 a shorter interval than the standard IGMP/MLD Query interval. 719 Therefore, this IGMP/MLD Query interval should be configurable to 720 ensure the firewall does not revert to blocking the UDP encapsulated 721 multicast data packets. 723 6.3. Responding to Relay Changes 725 When a gateway determines that its current relay is unreachable 726 (e.g., upon receipt of a ICMP Unreachable message [ICMP] for the 727 relay's unicast address), it may need to repeat relay address 728 discovery. However, care should be taken not to abandon the current 729 relay too quickly due to transient network conditions. Some 730 implementations may find it difficult to send a discovery packet to 731 the anycast relay address while the gateway has an address configured 732 on the AMT pseudo-interface on the same anycast prefix. Therefore, it 733 may be necessary to tear down the AMT pseudo-interface to rediscover 734 a new relay. 736 6.4. Creating SSM groups 738 When a gateway wants to create an SSM group (i.e., in 232/8) for 739 which it can source traffic, the remaining 24 bits MUST be generated 740 as described below. ([SSM] states that "the policy for allocating 741 these bits is strictly locally determined at the sender's host.") 743 When the gateway determined its AMT Gateway Anycast Address as 744 described above, it used the high bits of its global unicast address. 745 The remaining bits of its global unicast address are appended to the 746 232/8 prefix, and any spare bits may be allocated using any policy 747 (again, strictly locally determined at the sender's host). 749 For example, if the IPv4 AMT Subnet Prefix is x.y/16, and the device 750 has global unicast address a.b.c.d, then it MUST allocate IPv4 SSM 751 groups in the range 232.c.d/24. 753 6.5. Joining SSM Groups with AMT Sources 755 An IGMPv3/MLDv2 Report for a given (source, group) pair MAY be 756 encapsulated directly to the source, when the source address belongs 757 to the AMT Subnet Prefix. 759 The "link-layer" address to use as the destination address in the 760 outer IP header is obtained as follows. The source address in the 761 inclusion list of the IGMPv3/MLDv2 report will be an AMT Gateway 762 Anycast Address with the high bits of the address, and the remaining 763 bits will be in the middle of the group address. 765 For example, if the IPv4 AMT Subnet Prefix is x.y/16, and the IGMPv3 766 Report is for (x.y.a.b, 232.c.d.e), then the "link layer" IPv4 767 destination address used for encapsulation is a.b.c.d. 769 6.6. Receiving IGMPv3/MLDv2 Reports at the Gateway 771 When an AMT Request is received by the gateway, it follows the same 772 3-way handshake procedure a relay would follow if it received the AMT 773 Request. It generates a MAC and responds with an AMT Membership 774 Query. When the AMT Membership Update is received, it verifies the 775 MAC and then processes the IGMP/MLD Membership/Listener Report or 776 Leave/Done. 778 At the gateway, the IGMP/MLD packet should be an IGMPv3/MLDv2 source 779 specific (S,G) join or leave. 781 If S is not the AMT Gateway Anycast Address, the packet is dropped. 782 If G does not contain the low bits of the global unicast address (as 783 described above), the packet is also dropped. 785 The gateway adds the source address (from the outer IP header) and 786 UDP port of the report to a membership list for G. Maintaining this 787 membership list may be done in any implementation-dependent manner. 788 For example, it might be maintained by the "link-layer" inside the 789 AMT pseudo-interface, making it invisible to the normal IGMP/MLD 790 module. 792 6.7. Sending data to SSM groups 794 When multicast packets are sent on the AMT pseudo-interface, they are 795 encapsulated as follows. If the group address is not an SSM group, 796 then the packet is dropped (this memo does not currently provide a 797 way to send to non-SSM groups). 799 If the group address is an SSM group, then the packet is unicast 800 encapsulated to each remote node from which the gateway has received 801 an IGMPv3/MLDv2 report for the packet's (source, group) pair. 803 7. Relay Router Details 805 7.1. At Startup time 807 At startup time, the relay router will bring up an NBMA-style AMT 808 pseudo-interface. It shall also add the AMT Relay Anycast Address on 809 some interface. 811 The relay router shall then advertise the AMT Relay Anycast Prefix 812 into the unicast-only Internet, as if it were a connection to an 813 external network. When the advertisement is done using BGP, the AS 814 path leading to the AMT Relay Anycast Prefix shall include the 815 identifier of the local AS and the AMT Unicast Autonomous System ID. 817 The relay router shall also enable IGMPv3/MLDv2 on the AMT pseudo- 818 interface, except that it shall not multicast Queries (this might be 819 done, for example, by having the AMT pseudo-device drop them, or by 820 having the IGMP/MLD module not send them in the first place). 822 Finally, to support sourcing SSM traffic from AMT sites, the AMT 823 Subnet Prefix is assigned to the AMT pseudo-interface, and the AMT 824 Subnet Prefix is injected into the M-RIB of MBGP. 826 7.2. Receiving Relay Discovery messages sent to the Anycast Address 828 When a relay receives a AMT Relay Discovery message directed to the 829 AMT Relay Anycast Address, it should respond with a AMT Relay 830 Advertisement containing its unicast address. The source and 831 destination addresses of the advertisement should be the same as the 832 destination and source addresses of the discovery message 833 respectively. Further, the nonce in the discovery message MUST be 834 copied into the advertisement message. 836 7.3. Receiving Membership Updates from AMT Gateways 838 The relay operates passively, sending no Queries but simply tracking 839 membership information according to Reports and Leave messages, as a 840 router normally would. In addition, the relay must also do explicit 841 membership tracking, as to which gateways on the AMT pseudo- 842 interface have joined which groups. Once an AMT Membership Update has 843 been successfully received, it updates the forwarding state for the 844 appropriate group and source (if provided). When data arrives for 845 that group, the traffic must be encapsulated to each gateway which 846 has joined that group. 848 The explicit membership tracking and unicast replication may be done 849 in any implementation-specific manner. Some examples are: 851 1. The AMT pseudo-device driver might track the group information and 852 perform the replication at the "link-layer", with no changes to a 853 pre-existing IGMP/MLD module. 855 2. The IGMP/MLD module might have native support for explicit 856 membership tracking, especially if it supports other NBMA-style 857 interfaces. 859 7.4. Receiving (S,G) Joins from the Native Side, for AMT Sources 861 The relay encapsulates an IGMPv3/MLDv2 report to the AMT source as 862 described above in Section 4.1.2. 864 8. IANA Considerations 866 The IANA should allocate a prefix dedicated to the public AMT Relays 867 to the native multicast backbone. The prefix length should be 868 determined by the IANA; the prefix should be large enough to 869 guarantee advertisement in the default- free BGP networks; a length 870 of 16 will meet this requirement. This is a one time effort; there 871 is no need for any recurring assignment after this stage. 873 The IANA should also allocate an Autonomous System ID which can be 874 used as a pseudo-AS when advertising routes to the above prefix. 875 Furthermore, to support sourcing SSM traffic from AMT gateways, the 876 IANA should allocate a subnet prefix dedicated to the AMT link. The 877 prefix length should be determined by the IANA; the prefix should be 878 large enough to guarantee advertisement in the default- free BGP 879 networks; a length of 16 will meet this requirement. This is a one 880 time effort; there is no need for any recurring assignment after this 881 stage. It should also be noted that this prefix length directly 882 affects the number of groups available to be created by the AMT 883 gateway: a length of 16 gives 256 groups, and a length of 8 gives 884 65536 groups. For diagnostic purposes, it is helpful to have a 885 prefix length which is a multiple of 8, although this is not 886 required. 888 An autonomous system number dedicated to a pseudo-AS for multicast is 889 already in use today (AS 10888), and so it is expected that no 890 additional AS number is required for this prefix. 892 IANA has allocated UDP reserved port number 2268 for AMT 893 encapsulation. 895 9. Security Considerations 897 The anycast technique introduces a risk that a rogue router or a 898 rogue AS could introduce a bogus route to the AMT Relay Anycast 899 Prefix, and thus divert the traffic. Network managers have to 900 guarantee the integrity of their routing to the AMT Relay anycast 901 prefix in much the same way that they guarantee the integrity of all 902 other routes. 904 Within the native MBGP infrastructure, there is a risk that a rogue 905 router or a rogue AS could introduce a bogus route to the AMT Subnet 906 Prefix, and thus divert joins and cause RPF failures of multicast 907 traffic. Again, network managers have to guarantee the integrity of 908 the MBGP routing to the AMT subnet prefix in much the same way that 909 they guarantee the integrity of all other routes in the M-RIB. 911 Gateways and relays will accept and decapsulate multicast traffic 912 from any source from which regular unicast traffic is accepted. If 913 this is for any reason felt to be a security risk, then additional 914 source address based packet filtering MUST be applied: 916 1. To prevent a rogue sender (that can't do traditional spoofing 917 because of e.g. access lists deployed by its ISP) from making use 918 of AMT to send packets to an SSM tree, a relay that receives an 919 encapsulated multicast packet MUST discard the multicast packet if 920 the IPv4 source address in the outer header is not composed of the 921 last 2 bytes of the source address and the 2 middle bytes of the 922 destination address of the inner header (i.e., a.b.c.d must be 923 composed of the a.b of x.y.a.b and the c.d of 232.c.d.e). 925 2. A gateway MUST discard encapsulated multicast packets if the 926 source address in the outer header is not the address to which the 927 encapsulated join message was sent. An AMT Gateway that receives 928 an encapsulated IGMPv3/MLDv2 (S,G)-Join MUST discard the message 929 if the IPv4 destination address in the outer header is not 930 composed of the last 2 bytes of S and the 2 middle bytes of G 931 (i.e. the destination address a.b.c.d must be composed of the a.b 932 of the multicast source x.y.a.b and the c.d of the multicast group 933 232.c.d.e). 935 10. Contributors 937 The following people provided significant contributions to earlier 938 versions of this draft. 940 Dirk Ooms 941 OneSparrow 942 Belegstraat 13; 2018 Antwerp; Belgium 943 EMail: dirk@onesparrow.com 945 11. Acknowledgments 947 Most of the mechanisms described in this document are based on 948 similar work done by the NGTrans WG for obtaining automatic IPv6 949 connectivity without explicit tunnels ("6to4"). Tony Ballardie 950 provided helpful discussion that inspired this document. 952 12. Normative References 954 [ICMP] Postel, J., "Internet Control Message Protocol", RFC 792, 955 September 1981. 957 [IGMPv3] Cain, B., Deering, S., Fenner, B., Kouvelas, I., 958 Thyagarajan A., "Internet Group Management Protocol, 959 Version 3", RFC 3376, October 2002. 961 [MLDv2] Vida, R., Costa, L., "Multicast Listener Discovery 962 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 964 [PROXY] Fenner, W., He, H., Haberman, B., Sandick, H., "IGMP/MLD- 965 based Multicast Forwarding ("IGMP/MLD Proxying")", Work 966 in progress, draft-ietf-magma-igmp-proxy-06.txt, April 967 2004. 969 [SSM] Holbrook, H., Cain, B., "Source-Specific Multicast for 970 IP", Work in Progress, draft-ietf-ssm-arch-06.txt, 971 September 2004. 973 13. Informative References 975 [ANYCAST] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 976 RFC 3068, June 2001. 978 [6TO4] Carpenter, B., Moore, K., "Connection of IPv6 Domains via 979 IPv4 Clouds", RFC 3056, February 2001. 981 [Brad88] Braden, R., Borman, D., Partridge, C., "Computing the 982 Internet Checksum", RFC 1071, September 1988. 984 [BROKER] Durand, A., Fasano, P., Guardini, I., Lento, D., "IPv6 985 Tunnel Broker", RFC 3053, January 2001. 987 [HMAC] Krawczyk, H., Bellare, M., Canetti, R., "HMAC: Keyed- 988 Hashing for Message Authentication", RFC 2104, February 989 1997. 991 [PIMSM] Estrin, D. Farinacci, D., Helmy, A., Thaler, D., Deering, 992 S., Handley, M., Jacobson, V., Liu, C., Sharma, P., Wei, 993 L., "Protocol Independent Multicast-Sparse Mode (PIM-SM): 994 Protocol Specification", RFC 2362, June 1998. 996 14. Author's Address 998 Dave Thaler 999 Microsoft Corporation 1000 One Microsoft Way 1001 Redmond, WA 98052-6399 1002 Phone: +1 425 703 8835 1003 EMail: dthaler@microsoft.com 1005 Mohit Talwar 1006 Microsoft Corporation 1007 One Microsoft Way 1008 Redmond, WA 98052-6399 1009 Phone: +1 425 705 3131 1010 EMail: mohitt@microsoft.com 1012 Amit Aggarwal 1013 Microsoft Corporation 1014 One Microsoft Way 1015 Redmond, WA 98052-6399 1016 Phone: +1 425 706 0593 1017 EMail: amitag@microsoft.com 1019 Lorenzo Vicisano 1020 Cisco Systems 1021 170 West Tasman Dr. 1022 San Jose, CA 95134 1023 Phone: +1 408 525 2530 1024 EMail: lorenzo@cisco.com 1026 Tom Pusateri 1027 Juniper Networks, Inc. 1028 1194 North Mathilda Avenue 1029 Sunnyvale, CA 94089 USA 1030 Phone: +1 408 745 2000 1031 EMail: pusateri@juniper.net 1033 15. Intellectual Property Rights Notice 1035 The IETF takes no position regarding the validity or scope of any 1036 Intellectual Property Rights or other rights that might be claimed to 1037 pertain to the implementation or use of the technology described in 1038 this document or the extent to which any license under such rights 1039 might or might not be available; nor does it represent that it has 1040 made any independent effort to identify any such rights. Information 1041 on the procedures with respect to rights in RFC documents can be 1042 found in BCP 78 and BCP 79. 1044 Copies of IPR disclosures made to the IETF Secretariat and any 1045 assurances of licenses to be made available, or the result of an 1046 attempt made to obtain a general license or permission for the use of 1047 such proprietary rights by implementers or users of this 1048 specification can be obtained from the IETF on-line IPR repository at 1049 http://www.ietf.org/ipr. 1051 The IETF invites any interested party to bring to its attention any 1052 copyrights, patents or patent applications, or other proprietary 1053 rights that may cover technology that may be required to implement 1054 this standard. Please address the information to the IETF at ietf- 1055 ipr@ietf.org." 1057 16. Full Copyright Statement 1059 Copyright (C) The Internet Society (2004). This document is subject 1060 to the rights, licenses and restrictions contained in BCP 78, and 1061 except as set forth therein, the authors retain all their rights. 1063 17. Disclaimer 1065 This document and the information contained herein are provided on an 1066 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1067 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1068 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1069 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1070 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1071 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1072 Table of Contents 1074 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1075 2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3 1076 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3 1077 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1078 4.1. Receiving Multicast in an AMT Site . . . . . . . . . . . . . 5 1079 4.2. Sourcing Multicast from an AMT site . . . . . . . . . . . . 7 1080 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 10 1081 5.1. AMT Relay Discovery . . . . . . . . . . . . . . . . . . . . 10 1082 5.2. AMT Relay Advertisement . . . . . . . . . . . . . . . . . . 10 1083 5.3. AMT Request . . . . . . . . . . . . . . . . . . . . . . . . 11 1084 5.4. AMT Membership Query . . . . . . . . . . . . . . . . . . . . 12 1085 5.5. AMT Membership Update . . . . . . . . . . . . . . . . . . . 13 1086 5.6. AMT Multicast Data . . . . . . . . . . . . . . . . . . . . . 14 1087 6. AMT Gateway Details . . . . . . . . . . . . . . . . . . . . . 15 1088 6.1. At Startup Time . . . . . . . . . . . . . . . . . . . . . . 15 1089 6.2. Joining Groups with MBone Sources . . . . . . . . . . . . . 15 1090 6.3. Responding to Relay Changes . . . . . . . . . . . . . . . . 16 1091 6.4. Creating SSM groups . . . . . . . . . . . . . . . . . . . . 17 1092 6.5. Joining SSM Groups with AMT Sources . . . . . . . . . . . . 17 1093 6.6. Receiving IGMPv3/MLDv2 Reports at the Gateway . . . . . . . 17 1094 6.7. Sending data to SSM groups . . . . . . . . . . . . . . . . . 18 1095 7. Relay Router Details . . . . . . . . . . . . . . . . . . . . . 18 1096 7.1. At Startup time . . . . . . . . . . . . . . . . . . . . . . 18 1097 7.2. Receiving Relay Discovery messages sent to the Anycast 1098 Address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1099 7.3. Receiving Membership Updates from AMT Gateways . . . . . . . 19 1100 7.4. Receiving (S,G) Joins from the Native Side, for AMT Sources 1101 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1102 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 1103 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 1104 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 21 1105 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 1106 12. Normative References . . . . . . . . . . . . . . . . . . . . 21 1107 13. Informative References . . . . . . . . . . . . . . . . . . . 22 1108 14. Author's Address . . . . . . . . . . . . . . . . . . . . . . 22 1109 15. Intellectual Property Rights Notice . . . . . . . . . . . . . 23 1110 16. Full Copyright Statement . . . . . . . . . . . . . . . . . . 24 1111 17. Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . . 24