idnits 2.17.1 draft-ietf-mboned-auto-multicast-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 864 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 10) being 579 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 20 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 449 instances 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 441: '...ving as a local router, it SHOULD also...' RFC 2119 keyword, line 445: '...orts. The gateway MUST also advertise...' RFC 2119 keyword, line 529: '...or a given (source, group) pair MAY be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2002) is 8045 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) == Missing Reference: 'RFC1112' is mentioned on line 97, but not defined == Missing Reference: 'TBD IANA' is mentioned on line 257, but not defined == Unused Reference: 'BGMP' is defined on line 820, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3053 (ref. 'BROKER') == Outdated reference: A later version (-03) exists of draft-ietf-ngtrans-6to4anycast-02 ** Downref: Normative reference to an Historic draft: draft-ietf-ngtrans-6to4anycast (ref. 'ANYCAST') == Outdated reference: A later version (-06) exists of draft-ietf-bgmp-spec-02 ** Downref: Normative reference to an Historic draft: draft-ietf-bgmp-spec (ref. 'BGMP') == Outdated reference: A later version (-10) exists of draft-ietf-idmr-igmp-v3-06 ** Obsolete normative reference: RFC 2362 (ref. 'PIMSM') (Obsoleted by RFC 4601, RFC 5059) == Outdated reference: A later version (-03) exists of draft-holbrook-ssm-arch-01 -- Possible downref: Normative reference to a draft: ref. 'SSM' -- Possible downref: Normative reference to a draft: ref. 'MSNIP' Summary: 13 errors (**), 0 flaws (~~), 11 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MBoneD Working Group Dave Thaler 3 INTERNET-DRAFT Mohit Talwar 4 Expires October 2002 Microsoft 5 Lorenzo Vicisano 6 Cisco 7 Dirk Ooms 8 Alcatel 9 April 2002 11 IPv4 Automatic Multicast Without Explicit Tunnels (AMT) 12 14 Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six 25 months and may be updated, replaced, or obsoleted by other 26 documents at any time. It is inappropriate to use Internet- 27 Drafts as reference material or to cite them other than as "work 28 in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Copyright Notice 38 Expires October 2002 [Page 1] 40 Draft AMT April 2002 42 Copyright (C) The Internet Society (2001). All Rights Reserved. 44 1. 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 49 them to exchange multicast traffic with the native multicast 50 infrastructure (MBone) and does not require any manual 51 configuration. AMT uses an encapsulation interface so that no 52 changes to a host stack, or applications, are required, all 53 protocols (not just UDP) are handled, and there is no additional 54 overhead in core routers. 56 2. Introduction 58 Automatic Multicast Tunneling (AMT) allows multicast communication 59 amongst isolated multicast-enabled sites or hosts, attached to a 60 network which has no native multicast support. It also enables 61 them to exchange multicast traffic with the native multicast 62 infrastructure (MBone) and does not require any manual 63 configuration. Effectively, it treats the unicast-only 64 internetwork as a large non-broadcast multi-access (NBMA) link 65 layer, over which we require the ability to multicast. To do 66 this, multicast packets being sent to or from a site must be 67 encapsulated in unicast packets. If the group has members in 68 multiple sites, AMT encapsulation of the same multicast packet 69 will take place multiple times by necessity. 71 The primary goal of this document is to foster the deployment of 72 native IP multicast by enabling a potentially large number of 73 nodes to connect to the already present multicast infrastructure. 74 Therefore, the techniques discussed here should be viewed as an 75 interim solution to help in the various stages of the transition 76 to a native multicast network. 78 To allow fast deployment, the solution presented here only 79 requires small and concentrated changes to the network 80 infrastructure, and no changes at all to user applications or to 81 the socket API of end-nodes' operating systems. The protocols 82 introduced in this specification are implemented in a few 83 strategically-placed network nodes and in user-installable 84 software modules (pseudo device drivers and/or user-mode daemons) 85 that reside underneath the socket API of end-nodes' operating 86 systems. This mechanism is very similar to that used by "6to4" 88 Expires October 2002 [Page 2] 90 Draft AMT April 2002 92 [6TO4, ANYCAST] to get automatic IPv6 connectivity. 94 In order of importance, the following problems are addressed: 96 o Allowing isolated sites/hosts to receive general multicast (ISM 97 [RFC1112]). 99 o Allowing isolated sites/hosts to receive the SSM flavor of 100 multicast ([SSM]). 102 o Allowing isolated sites/hosts to transmit the SSM flavor of 103 multicast. 105 This document does not address allowing isolated sites/hosts to 106 transmit general multicast. We expect that other solutions (e.g., 107 Tunnel Brokers, a la [BROKER]) will be used for sites that desire 108 this capability. 110 3. Definitions 112 +---------------+ Internet +---------------+ 113 | AMT Site | | MBone | 114 | | AMT | | 115 | +------+----+ Relay +----+----+ AMT | 116 | |AMT Gateway| Anycast |AMT Relay| Subnet | 117 | | +-----+-+ Prefix +-+-----+ | Prefix | 118 | | |AMT IF | <--------|AMT IF | |--------> | 119 | | +-----+-+ +-+-----+ | | 120 | +------+----+ +----+----+ | 121 | | | | 122 +---------------+ +---------------+ 124 Figure 1: Automatic Multicast Definitions. 126 AMT Pseudo-Interface 127 AMT encapsulation of multicast packets inside unicast packets 128 occurs at a point that is logically equivalent to an 129 interface, with the link layer being the unicast-only 130 network. This point is referred to as a pseudo-interface. 131 Some implementors may treat it exactly like any other 132 interface and others may treat it like a tunnel end-point. 134 Expires October 2002 [Page 3] 136 Draft AMT April 2002 138 AMT Gateway 139 A host, or a site gateway router, supporting an AMT Pseudo- 140 Interface. It does not have native multicast connectivity to 141 the native multicast backbone infrastructure. It is simply 142 referred to in this document as a "gateway". 144 AMT Site 145 A multicast-enabled network not connected to the multicast 146 backbone served by an AMT Gateway. It could also be a 147 stand-alone AMT Gateway. 149 AMT Relay Router 150 A multicast router configured to support transit routing 151 between AMT Sites and the native multicast backbone 152 infrastructure. The relay router has one or more interfaces 153 connected to the native multicast infrastructure, zero or 154 more interfaces connected to the non-multicast capable 155 internetwork, and an AMT pseudo-interface. It is simply 156 referred to in this document as a "relay". 158 As with [6TO4], we assume that normal multicast routers do 159 not want to be tunnel endpoints (especially if this results 160 in high-fanout), and similarly that service providers do not 161 want encapsulation to arbitrary routers. Instead, we assume 162 that special-purpose routers will be deployed that are 163 suitable for serving as relays. 165 AMT Relay Anycast Prefix 166 A well-known address prefix used to advertise (into the 167 unicast routing infrastructure) a route to an available AMT 168 Relay Router. 170 The value of this prefix is x.x.x.0/nn [length and value TBD 171 IANA]. 173 AMT Relay Anycast Address 174 An anycast address which is used to reach the nearest AMT 175 Relay Router. 177 This address corresponds to host number 1 in the AMT Relay 178 Anycast Prefix, x.x.x.1. 180 AMT Unicast Autonomous System ID 181 A 16-bit Autonomous system ID, for use in BGP in accordance 182 to this memo. AS 10888 might be usable for this, but for now 184 Expires October 2002 [Page 4] 186 Draft AMT April 2002 188 we'll assume it's different, to avoid confusion. This number 189 represents a "pseudo-AS" common to all AMT relays. 191 To protect themselves from erroneous advertisements, managers 192 of border routers often use databases to check the relation 193 between the advertised network and the last hop in the AS 194 path. Associating a specific AS number with the AMT Relay 195 Anycast Address allows us to enter this relationship in the 196 databases used to check inter-domain routing [ANYCAST]. 198 AMT Subnet Prefix 199 A well-known address prefix used to advertise (into the M-RIB 200 of the native multicast-enabled infrastructure) a route to 201 AMT Sites. This prefix will be used to enable sourcing SSM 202 traffic from an AMT Gateway. 204 AMT Gateway Anycast Address 205 An anycast address in the AMT Subnet Prefix range, which is 206 used by an AMT Gateway to enable sourcing SSM traffic from 207 local applications. 209 AMT Multicast Autonomous System ID 210 A 16-bit Autonomous system ID, for use in MBGP in accordance 211 to this memo. We assume that the existing AS 10888 is 212 suitable for this purpose. (Note: if this is a problem, a 213 different one would be fine.) 215 4. Overview 217 4.1. Receiving Multicast in an AMT Site 219 +---------------+ Internet +---------------+ 220 | AMT Site | | MBone | 221 | | 3. Data | | 222 | 1. Join +---+---+ <================= +---+---+ | 223 | +---->|Gateway| | Relay | | 224 | | +---+---+ =================> +---+---+ | 225 | R-+ | 2. IGMP Report | | 226 +---------------+ +---------------+ 228 Figure 2: Receiving Multicast in an AMT Site. 230 AMT relays and gateways cooperate to transmit multicast traffic 231 sourced within the native multicast infrastructure to AMT sites: 233 Expires October 2002 [Page 5] 235 Draft AMT April 2002 237 relays receive the traffic natively and unicast-encapsulate it to 238 gateways; gateways decapsulate the traffic and possibly re- 239 multicast it in the AMT site. 241 Each gateway has an AMT pseudo-interface that serves as a default 242 multicast route. Requests to join a multicast session are sent to 243 this interface and encapsulated to a particular relay reachable 244 across the unicast-only infrastructure. 246 Each relay has an AMT pseudo-interface too. Multicast traffic 247 sent on this interface is encapsulated to zero or more gateways 248 that have joined to the relay. The AMT recipient-list is 249 determined for each multicast session. This requires the relay to 250 keep state for each gateway which has joined a particular group 251 (or (source, group) pair). Multicast packets from the native 252 infrastructure behind the relay will be sent to each gateway which 253 has requested them. 255 All multicast packets (data and control) are encapsulated in 256 unicast packets. To work across NAT's, the encapsulation is done 257 over UDP using a well-known port number [TBD IANA]. 259 Each relay, plus the set of all gateways (perhaps unknown to the 260 relay) using the relay, together can be thought of as being on a 261 separate logical NBMA link. This implies that the AMT recipient- 262 list is a list of "link layer" addresses which are (IP address, 263 UDP port) pairs. 265 Since the number of gateways using a relay can be quite large, and 266 we expect that most sites will not want to receive most groups, an 267 explicit-joining protocol is required for gateways to communicate 268 group membership information to a relay. The two most likely 269 candidates are the IGMP [IGMP] protocol, and the PIM-Sparse Mode 270 [PIMSM] protocol. Since an AMT gateway may be a host, and hosts 271 typically do not implement routing protocols, gateways will use 272 IGMP as described in Section 5 below. This allows a host kernel 273 (or a pseudo device driver) to easily implement AMT gateway 274 behavior, and obviates the relay from the need to know whether a 275 given gateway is a host or a router. From the relay's 276 perspective, all gateways are indistinguishable from hosts on an 277 NBMA leaf network. 279 Expires October 2002 [Page 6] 281 Draft AMT April 2002 283 4.1.1. Scalability Considerations 285 The requirement that a relay keep group state per gateway that has 286 joined the group introduces potential scalability concerns. 288 However, scalability of AMT can be achieved by adding more relays, 289 and using an appropriate relay discovery mechanism for gateways to 290 discover relays. The solution we adopt is to assign an anycast 291 address to relays. However, simply sending periodic IGMP Reports 292 to an anycast address can cause duplicates. Specifically, if 293 routing changes such that a different relay receives a periodic 294 IGMP Report, both the new and old relays will encapsulate data to 295 the AMT site until the old relay's state times out. This is 296 obviously undesirable. Instead, we use the anycast address merely 297 to find a unicast address which can then be used. 299 Since adding another relay has the result of adding another 300 independent NBMA link, this allows the gateways to be spread out 301 among more relays so as to keep the number of gateways per relay 302 at a reasonable level. 304 4.2. Sourcing Multicast from an AMT site 306 Two cases are discussed below: multicast traffic sourced in an AMT 307 site and received in the MBone, and multicast traffic sourced in 308 an AMT site and received in another AMT site. 310 In both cases only SSM sources are supported. Furthermore this 311 specification only deals with the source residing directly in the 312 gateway. To enable a generic node in an AMT site to source 313 multicast, additional coordination between the gateway and the 314 source-node is required. 316 The general mechanism used to join towards AMT sources is based on 317 the following: 319 o Applications residing in the gateway use addresses in the AMT 320 Subnet Prefix to send multicast, as a result of sourcing traffic 321 on the AMT pseudo-interface. 323 o The AMT Subnet Prefix is advertised for RPF reachability in the 324 M-RIB by relays and gateways. 326 Expires October 2002 [Page 7] 328 Draft AMT April 2002 330 o Relays or gateways that receive a join for a source/group pair 331 use information encoded in the address pair to rebuild the 332 address of the gateway (source) to which to encapsulate the join 333 (see section 5 for more details). 335 It is expected that this join mechanism will be the identical to 336 that used to join back to a source on normal media, as is being 337 proposed in the SSM WG [MSNIP]. 339 4.2.1. Supporting Site-MBone Multicast 341 +---------------+ Internet +---------------+ 342 | AMT Site | | MBone | 343 | | 3. Data | | 344 | +---+---+ =================> +---+---+ 1. Join | 345 | |Gateway| | Relay |<-----+ | 346 | +---+---+ <================= +---+---+ | | 347 | | 2. IGMP Report | +-R | 348 +---------------+ +---------------+ 350 Figure 3: Site-MBone Multicast. 352 If a relay receives an explicit join from the native 353 infrastructure, for a given (source, group) pair where the source 354 address belongs to the AMT Subnet Prefix, then the relay will 355 periodically (using the rules specified in Section 5) UDP 356 encapsulate an IGMP Report for the group to the gateway. The 357 gateway must keep state per relay from which an IGMP Report has 358 been sent, and forward multicast traffic from the site to all 359 relays from which IGMP Reports have been received. The choice of 360 whether this state and replication is done at the link-layer 361 (i.e., by the tunnel interface) or at the network-layer is 362 implementation-dependent. 364 If there are multiple relays present, this ensures that data from 365 the AMT site is received via the closest relay to the receiver. 366 This is necessary when the routers in the native multicast 367 infrastructure employ Reverse-Path Forwarding (RPF) checks against 368 the source address, such as occurs when [PIMSM] is used by the 369 multicast infrastructure. 371 The solution above will scale to an arbitrary number of relays, as 372 long at the number of relays requiring multicast traffic from a 373 given AMT site remains reasonable enough to not overly burden the 375 Expires October 2002 [Page 8] 377 Draft AMT April 2002 379 site's gateway. 381 4.2.2. Supporting Site-Site Multicast 383 +---------------+ Internet +---------------+ 384 | AMT Site | | AMT Site | 385 | | 3. Data | | 386 | +---+---+ =================> +---+---+ 1. Join | 387 | |Gateway| |Gateway|<-----+ | 388 | +---+---+ <================= +---+---+ | | 389 | | 2. IGMP Report | +-R | 390 +---------------+ +---------------+ 392 Figure 4: Site-Site Multicast. 394 Since we require gateways to accept IGMP 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 399 the source address belongs to the AMT Subnet Prefix, then the 400 gateway will periodically unicast encapsulate an IGMPv3 [IGMPv3] 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 405 sites. However, it is expected that this is not unreasonable for 406 two reasons. First, the gateway does not have native multicast 407 connectivity, and as a result is likely doing unicast replication 408 at present. The amount of state is thus the same as what such a 409 site already deals with. Secondly, any site expecting to source 410 traffic to a large number of sites could get a point-to-point 411 tunnel to the native multicast infrastructure, and use that 412 instead of AMT. 414 5. AMT Gateway Details 416 This section details the behavior of an AMT Gateway, which may be 417 a router serving an AMT site, or the site may consist of a single 418 host, serving as its own gateway. 420 Expires October 2002 [Page 9] 422 Draft AMT April 2002 424 5.1. At Startup Time 426 At startup time, the AMT gateway will bring up an AMT pseudo- 427 interface, to be used for encapsulation. The gateway will then 428 send a UDP encapsulated ICMP Echo Request to the AMT Relay Anycast 429 Address, and note the unicast address (which is treated as a 430 link-layer address to the encapsulation interface) from the UDP 431 encapsulated ICMP Echo Response. These "pings" should be done 432 periodically (e.g., once a day) to re-resolve the unicast address 433 of a close relay. Note that the ICMP messages are unicast 434 encapsulated, just as the multicast packets. 436 The gateway also initializes a timer used to send periodic IGMP 437 Reports to a random value from the interval [0, [Query Interval]] 438 before sending the first periodic report, in order to prevent 439 startup synchronization (e.g., after a power outage). 441 If the gateway is serving as a local router, it SHOULD also 442 function as an IGMP Proxy, as described in [IGMPPROXY], with its 443 IGMP host-mode interface being the AMT pseudo-interface. This 444 enables it to translate group memberships on its downstream 445 interfaces into IGMP Reports. The gateway MUST also advertise 446 itself as the default route for multicast in the M-RIB (or it must 447 be the default unicast router if unicast and multicast topologies 448 are congruent). Also, if a shared tree routing protocol is used 449 inside the AMT site, each tree-root must be a gateway, e.g., in 450 PIM-SM each RP must be a gateway. 452 Finally, to support sourcing traffic to SSM groups by a gateway 453 with a global unicast address, the AMT Subnet Prefix is treated as 454 the subnet prefix of the AMT pseudo-interface, and an anycast 455 address is added on the interface. This anycast address is formed 456 by concatenating the AMT Subnet Prefix followed by the high bits 457 of the gateway's global unicast address. For example, if IANA 458 assigns the prefix x.y/16 as the AMT Subnet Prefix, and the 459 gateway has global unicast address a.b.c.d, then the AMT Gateway's 460 Anycast Address will be x.y.a.b. Note that multiple gateways 461 might end up with the same address assigned to their pseudo- 462 interfaces. 464 5.2. Joining Groups with MBone Sources 466 The IGMP protocol usually operates by having the Querier multicast 467 an IGMP Query message on the link. This behavior does not work on 469 Draft AMT April 2002 471 NBMA links which do not support multicast. Since the set of 472 gateways is typically unknown to the relay (and potentially quite 473 large), unicasting the queries is also impractical. The following 474 behavior is used instead. 476 Applications residing in a gateway should join groups on the AMT 477 pseudo-interface, causing IGMP Membership Reports to be sent over 478 that interface. When UDP encapsulating the IGMP Reports (and in 479 fact any other messages, unless specified otherwise in this 480 document), the destination address in the outer IP header is the 481 relay's unicast address. To provide robustness, gateways unicast 482 IGMP Reports to the relay every [Query Interval] (defined as 125 483 in [IGMP]) seconds. 485 Generating periodic reports can be done in any implementation- 486 specific manner. Some possibilities include: 488 o The AMT pseudo-interface might periodically manufacture 489 IGMPv3 Queries as if they had been received from an IGMP 490 Querier, and deliver them to the IP layer, after which normal 491 IGMP behavior will cause the appropriate reports to be sent. 493 o The IGMP module itself might provide an option to operate in 494 periodic mode on specific interfaces. 496 5.3. Responding to Relay Changes 498 When a gateway determines that its current relay is unreachable 499 (e.g., upon receipt of a ICMP Unreachable message for the relay's 500 unicast address), it immediately repeats the unicast address 501 resolution step by sending a UDP encapsulated ICMP Echo Request to 502 the AMT Relay Anycast Address, and storing the source address of 503 the UDP encapsulated ICMP Echo Response as the new unicast address 504 to use as a "link-layer" destination. 506 5.4. Creating SSM groups 508 When a gateway wants to create an SSM group (i.e., in 232/8) for 509 which it can source traffic, the remaining 24 bits must be 510 generated as described below. ([SSM] states that "the policy for 511 allocating these bits is strictly locally determined at the 512 sender's host.") 514 Draft AMT April 2002 516 When the gateway determined its AMT Gateway Anycast Address as 517 described above, it used the high bits of its global unicast 518 address. The remaining bits of its global unicast address are 519 appended to the 232/8 prefix, and any spare bits may be allocated 520 using any policy (again, strictly locally determined at the 521 sender's host). 523 For example, if IANA allocates x.y/16 as the AMT Subnet Prefix, 524 and the device has global unicast address a.b.c.d, then it must 525 allocate SSM groups in the range 232.c.d/24. 527 5.5. Joining SSM Groups with AMT Sources 529 An IGMPv3 Report for a given (source, group) pair MAY be 530 encapsulated directly to the source, when the source address 531 belongs to the AMT Subnet Prefix. (It is expected that this 532 mechanism will be the same mechanism as that used to join back to 533 a source on normal media, as is being proposed in the SSM WG.) 535 The "link-layer" address to use as the destination address in the 536 outer IP header is obtained as follows. The source address in the 537 inclusion list of the IGMPv3 report will be an AMT Gateway Anycast 538 Address with the high bits of the address, and the remaining bits 539 will be in the middle of the group address. 541 For example, if IANA assigns x.y/16 as the AMT Subnet Prefix, and 542 the IGMPv3 Report is for (x.y.a.b, 232.c.d.e), then the "link 543 layer" destination address used for encapsulation is a.b.c.d. 545 5.6. Receiving IGMPv3 Reports on the AMT Interface 547 When an IGMPv3 report is received on the AMT pseudo-interface, and 548 the report is a request to join a given (S, G) pair, then the 549 following actions are taken. 551 If S is not the AMT Gateway Anycast Address of the gateway, the 552 packet is dropped. If G does not contain the low bits of the 553 global unicast address (as described above), the packet is also 554 dropped. 556 Otherwise, the gateway adds the source address (from the outer IP 557 header) and UDP port of the report to a membership list for G. 558 Maintaining this membership list may be done in any 560 Draft AMT April 2002 562 implementation-dependent manner. For example, it might be 563 maintained by the "link-layer" inside the AMT pseudo-interface, 564 making it invisible to the normal IGMP module. 566 5.7. Sending data to SSM groups 568 When multicast packets are sent on the AMT pseudo-interface, they 569 are encapsulated as follows. If the group address is not an SSM 570 group, then the packet is dropped (this memo does not currently 571 provide a way to send to non-SSM groups). 573 If the group address is an SSM group, then the packet is unicast 574 encapsulated to each remote node from which the gateway has 575 received an IGMPv3 report for the packet's (source, group) pair. 577 6. Relay Router Details 579 6.1. At startup time 581 At startup time, the relay router will bring up an NBMA-style AMT 582 pseudo-interface. It shall also add the AMT Relay Anycast Address 583 on some interface. 585 The relay router shall then advertise the AMT Relay Anycast Prefix 586 into the unicast-only Internet, as if it were a connection to an 587 external network. When the advertisement is done using BGP, the 588 AS path leading to the AMT Relay Anycast Prefix shall include the 589 identifier of the local AS and the AMT Unicast Autonomous System 590 ID. 592 The relay router shall also enable IGMPv3 on the AMT pseudo- 593 interface, except that it shall not multicast Queries (this might 594 be done, for example, by having the AMT pseudo-device drop them, 595 or by having the IGMP module not send them in the first place). 597 Finally, to support sourcing SSM traffic from AMT sites, the AMT 598 Subnet Prefix is assigned to the AMT pseudo-interface, and the AMT 599 Subnet Prefix is injected into the M-RIB of MBGP. 601 Draft AMT April 2002 603 6.2. Receiving Echo Requests to the Anycast Address 605 When a relay receives a UDP encapsulated ICMP Echo Request 606 directed to the AMT Relay Anycast Address, it should respond with 607 a UDP encapsulated ICMP Echo Response from a unicast address 608 reachable on the unicast-only network (anycast addresses should 609 not be used as the source address of the ICMP Echo Response). 611 Unicast encapsulation of the ICMP Echo Request ensures that the 612 message will be seen by the AMT pseudo-interface which can then 613 process it. Specifically, it needs to ensure that the ICMP Echo 614 Response contains the appropriate source address. 616 6.3. Receiving Joins from AMT Gateways 618 The relay operates passively, sending no Queries but simply 619 tracking membership information according to Reports and Leave 620 messages, as a router normally would. In addition, the relay must 621 also do explicit membership tracking, as to which gateways on the 622 AMT pseudo-interface have joined which groups. When data arrives 623 for that group, the traffic must be encapsulated to each gateway 624 which has joined that group. 626 The explicit membership tracking and unicast replication may be 627 done in any implementation-specific manner. Some examples are: 629 o The AMT pseudo-device driver might track the group 630 information and perform the replication at the "link-layer", 631 with no changes to a pre-existing IGMP module. 633 o The IGMP module might have native support for explicit 634 membership tracking, especially if it supports other NBMA- 635 style interfaces. 637 6.4. Receiving (S,G) Joins from the Native Side, for AMT 638 Sources 640 The relay encapsulates an IGMPv3 report to the AMT source as 641 described above in Section 5.5. 643 Draft AMT April 2002 645 7. IANA Considerations 647 The IANA should allocate a prefix dedicated to the AMT Relays to 648 the native multicast backbone. The prefix length should be 649 determined by the IANA; the prefix should be large enough to 650 guarantee advertisement in the default- free BGP networks; a 651 length of 16 will meet this requirement. This is a one time 652 effort; there is no need for any recurring assignment after this 653 stage. 655 The IANA should also allocate an Autonomous System ID which can be 656 used as a pseudo-AS when advertising routes to the above prefix. 658 Furthermore, to support sourcing SSM traffic from AMT gateways, 659 the IANA should allocate a subnet prefix dedicated to the AMT 660 link. The prefix length should be determined by the IANA; the 661 prefix should be large enough to guarantee advertisement in the 662 default- free BGP networks; a length of 16 will meet this 663 requirement. This is a one time effort; there is no need for any 664 recurring assignment after this stage. It should also be noted 665 that this prefix length directly affects the number of groups 666 available to be created by the AMT gateway: a length of 16 gives 667 256 groups, and a length of 8 gives 65536 groups. For diagnostic 668 purposes, it is helpful to have a prefix length which is a 669 multiple of 8, although this is not required. 671 An autonomous system number dedicated to a pseudo-AS for multicast 672 is already in use today (AS 10888), and so it is expected that no 673 additional AS number is required for this prefix. 675 Finally, IANA should reserve a well-known UDP port number for AMT 676 encapsulation. 678 8. Security Considerations 680 The anycast technique introduces a risk that a rogue router or a 681 rogue AS could introduce a bogus route to the AMT Relay Anycast 682 Prefix, and thus divert the traffic. Network managers have to 683 guarantee the integrity of their routing to the AMT Relay anycast 684 prefix in much the same way that they guarantee the integrity of 685 all other routes. 687 Within the native MBGP infrastructure, there is a risk that a 688 rogue router or a rogue AS could introduce a bogus route to the 690 Draft AMT April 2002 692 AMT Subnet Prefix, and thus divert joins and cause RPF failures of 693 multicast traffic. Again, network managers have to guarantee the 694 integrity of the MBGP routing to the AMT subnet prefix in much the 695 same way that they guarantee the integrity of all other routes in 696 the M-RIB. 698 Gateways and relays will accept and decapsulate multicast traffic 699 from any source from which regular unicast traffic is accepted. 700 If this is for any reason felt to be a security risk, then 701 additional source address based packet filtering could be applied: 703 o To avoid that a rogue sender (that can't do traditional 704 spoofing because of e.g. access lists deployed by its ISP) 705 makes use of AMT to send packets to an SSM tree, a relay that 706 receives an encapsulated multicast packet COULD discard the 707 multicast packet if the IPv4 source address in the outer 708 header is not composed of the last 2 bytes of the source 709 address and the 2 middle bytes of the destination address of 710 the inner header (i.e. a.b.c.d must be composed of the a.b of 711 x.y.a.b and the c.d of 232.c.d.e). 713 o A gateway COULD discard encapsulated multicast packets if the 714 source address in the outer header is not the address to 715 which the encapsulated join message was sent. 717 An AMT Gateway that receives an encapsulated IGMPv3 (S,G)-Join 718 COULD discard the message if the IPv4 destination address in the 719 outer header is not composed of the last 2 bytes of S and the 2 720 middle bytes of G (i.e. the destination address a.b.c.d must be 721 composed of the a.b of the multicast source x.y.a.b and the c.d of 722 the multicast group 232.c.d.e). The usefulness of this check will 723 depend on the security measures taken in [MSNIP]. 725 9. Acknowledgements 727 Most of the mechanisms described in this document are based on 728 similar work done by the NGTrans WG for obtaining automatic IPv6 729 connectivity without explicit tunnels ("6to4"). Tony Ballardie 730 provided helpful discussion that inspired this document. 732 Draft AMT April 2002 734 10. Appendix A: Open Issues 736 Under the proposed mechanism, a gateway sends its IGMPv3 Reports 737 for MBone sources to the relay closest to itself (discovered using 738 the UDP encapsulated "ping"). This ensures that, as far as 739 possible, multicast traffic flows through the native multicast 740 infrastructure and the automatic multicast encapsulation is short. 742 However, there might be reasons to create automatic tunnels to the 743 relay closest to the MBone source instead. An ISP, for example, 744 might be willing to provide a relay for only its own customers, 745 those wishing to multicast their transmission to a much wider 746 audience. A mechanism, complementary to the one described in this 747 document, might be used to provide this facility. It uses UDP 748 encapsulated ICMP Redirect messages as described below. 750 While injecting routes for its sources into the M-RIB, such an ISP 751 might, for example, use a new BGP attribute to convey the address 752 of the preferred relay. This would let other relays redirect any 753 IGMP Reports to the preferred relay by sending a UDP encapsulated 754 ICMP Redirect. 756 An IGMP Report sent by a gateway to the relay closest to it would 757 consist of the following packet: 759 OuterIP [UDP [InnerIP [IGMP Report]]] 761 The relay would respond with: 763 OuterIP' [UDP' [InnerIP' [ICMP Redirect [InnerIP [IGMP Report]]]]] 765 An ICMP Redirect contains the first 64 bits of the original packet 766 [ICMP]. Hence the gateway would get 44 bytes (64 - sizeof(Inner 767 IP)) of the IGMP Report, enough to easily extract the (source, 768 group) pair, and redirect its report to the preferred gateway. 770 Certainly additional complexity is undesirable, so it is an open 771 issue as to whether redirects are needed at all. 773 11. Authors' Addresses 775 Dave Thaler 776 Microsoft Corporation 777 One Microsoft Way 779 Draft AMT April 2002 781 Redmond, WA 98052-6399 782 Phone: +1 425 703 8835 783 EMail: dthaler@microsoft.com 785 Mohit Talwar 786 Microsoft Corporation 787 One Microsoft Way 788 Redmond, WA 98052-6399 789 Phone: +1 425 705 3131 790 EMail: mohitt@microsoft.com 792 Lorenzo Vicisano 793 Cisco Systems 794 170 West Tasman Dr. 795 San Jose, CA 95134 796 Phone: +1 408 525 2530 797 EMail: lorenzo@cisco.com 799 Dirk Ooms 800 Alcatel 801 F. Wellesplein 1, 2018 Antwerp, Belgium 802 Phone: +32 3 2404732 803 EMail: dirk.ooms@alcatel.be 805 12. References 807 [6TO4] 808 Carpenter, B., and K. Moore, "Connection of IPv6 Domains via 809 IPv4 Clouds", RFC 3056, February 2001. 811 [BROKER] 812 Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 813 Tunnel Broker", RFC 3053, January 2001. 815 [ANYCAST] 816 C. Huitema, "An anycast prefix for 6to4 relay routers", Work 817 in progress, draft-ietf-ngtrans-6to4anycast-02.txt, February 818 2001. 820 [BGMP] 821 Thaler, D., Estrin, D., and D. Meyer, "Border Gateway 822 Multicast Protocol (BGMP): Protocol Specification", Work in 823 progress, draft-ietf-bgmp-spec-02.txt, November 2000. 825 Draft AMT April 2002 827 [ICMP] 828 Postel, J., "Internet Control Message Protocol", RFC 792, 829 September 1981. 831 [IGMPPROXY] 832 W. Fenner, "IGMP-based Multicast Forwarding (``IGMP 833 Proxying'')", Work in progress, draft-fenner-igmp-proxy- 834 03.txt, July 2000. 836 [IGMP] 837 W. Fenner, "Internet Group Management Protocol, Version 2", 838 RFC 2236, November 1997. 840 [IGMPv3] 841 Cain, B., Deering, S., Fenner, B., Kouvelas, I., and A. 842 Thyagarajan, "Internet Group Management Protocol, Version 3", 843 Work in progress, draft-ietf-idmr-igmp-v3-06.txt, January 844 2001. 846 [PIMSM] 847 Estrin, D. Farinacci, D., Helmy, A., Thaler, D., Deering, S., 848 Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei. 849 "Protocol Independent Multicast-Sparse Mode (PIM-SM): 850 Protocol Specification", RFC 2362, June 1998. 852 [SSM] 853 Holbrook, H., and B. Cain, "Source-Specific Multicast for 854 IP", Work in progress, draft-holbrook-ssm-arch-01.txt, 855 November 2000. 857 [MSNIP] 858 Fenner B., H. Holbrook, H., and I. Kouvelas, "Multicast 859 Source Notification of Interest Protocol (MSNIP)", Work in 860 progress, draft-ietf-idmr-msnip-01.txt, November 2001. 862 13. Full Copyright Statement 864 Copyright (C) The Internet Society (2001). All Rights Reserved. 866 This document and translations of it may be copied and furnished 867 to others, and derivative works that comment on or otherwise 868 explain it or assist in its implmentation may be prepared, copied, 869 published and distributed, in whole or in part, without 870 restriction of any kind, provided that the above copyright notice 872 Draft AMT April 2002 874 and this paragraph are included on all such copies and derivative 875 works. However, this document itself may not be modified in any 876 way, such as by removing the copyright notice or references to the 877 Internet Society or other Internet organizations, except as needed 878 for the purpose of developing Internet standards in which case the 879 procedures for copyrights defined in the Internet Standards 880 process must be followed, or as required to translate it into 881 languages other than English. 883 The limited permissions granted above are perpetual and will not 884 be revoked by the Internet Society or its successors or assigns. 886 This document and the information contained herein is provided on 887 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 888 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 889 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 890 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 891 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.