idnits 2.17.1 draft-ietf-mboned-auto-multicast-00.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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 : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 419: '...ving as a local router, it SHOULD also...' RFC 2119 keyword, line 423: '...orts. The gateway MUST also advertise...' RFC 2119 keyword, line 505: '...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 (20 February 2001) is 8465 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 90, but not defined == Missing Reference: 'TBD IANA' is mentioned on line 244, but not defined == Unused Reference: 'BGMP' is defined on line 772, 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' Summary: 9 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MBoneD Working Group Dave Thaler 2 INTERNET-DRAFT Mohit Talwar 3 Expires August 2001 Microsoft 4 Lorenzo Vicisano 5 Cisco 6 Dirk Ooms 7 Alcatel 8 20 February 2001 10 IPv4 Automatic Multicast Without Explicit Tunnels (AMT) 11 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet- 26 Drafts as reference material or to cite them other than as "work 27 in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 36 Draft AMT February 2001 38 Copyright (C) The Internet Society (2001). All Rights Reserved. 40 1. Abstract 42 Automatic Multicast Tunneling (AMT) allows multicast communication 43 amongst isolated multicast-enabled sites or hosts, attached to a 44 network which has no native multicast support. It also enables 45 them to exchange multicast traffic with the native multicast 46 infrastructure (MBone) and does not require any manual 47 configuration. AMT uses an encapsulation interface so that no 48 changes to a host stack, or applications, are required, all 49 protocols (not just UDP) are handled, and there is no additional 50 overhead in core routers. 52 2. Introduction 54 Automatic Multicast Tunneling (AMT) allows multicast communication 55 amongst isolated multicast-enabled sites or hosts, attached to a 56 network which has no native multicast support. It also enables 57 them to exchange multicast traffic with the native multicast 58 infrastructure (MBone) and does not require any manual 59 configuration. Effectively, it treats the unicast-only 60 internetwork as a large non-broadcast multi-access (NBMA) link 61 layer, over which we require the ability to multicast. To do 62 this, multicast packets being sent to or from a site must be 63 encapsulated in unicast packets. If the group has members in 64 multiple sites, AMT encapsulation of the same multicast packet 65 will take place multiple times by necessity. 67 The primary goal of this document is to foster the deployment of 68 native IP multicast by enabling a potentially large number of 69 nodes to connect to the already present multicast infrastructure. 70 Therefore, the techniques discussed here should be viewed as an 71 interim solution to help in the various stages of the transition 72 to a native multicast network. 74 To allow fast deployment, the solution presented here only 75 requires small and concentrated changes to the network 76 infrastructure, and no changes at all to user applications or to 77 the socket API of end-nodes' operating systems. The protocols 78 introduced in this specification are implemented in a few 79 strategically-placed network nodes and in user-installable 80 software modules (pseudo device drivers and/or user-mode daemons) 81 that reside underneath the socket API of end-nodes' operating 82 systems. This mechanism is very similar to that used by "6to4" 83 Draft AMT February 2001 85 [6TO4, ANYCAST] to get automatic IPv6 connectivity. 87 In order of importance, the following problems are addressed: 89 o Allowing isolated sites/hosts to receive general multicast (ISM 90 [RFC1112]). 92 o Allowing isolated sites/hosts to receive the SSM flavor of 93 multicast ([SSM]). 95 o Allowing isolated sites/hosts to transmit the SSM flavor of 96 multicast. 98 This document does not address allowing isolated sites/hosts to 99 transmit general multicast. We expect that other solutions (e.g., 100 Tunnel Brokers, a la [BROKER]) will be used for sites that desire 101 this capability. 103 3. Definitions 105 +---------------+ Internet +---------------+ 106 | AMT Site | | MBone | 107 | | AMT | | 108 | +------+----+ Relay +----+----+ AMT | 109 | |AMT Gateway| Anycast |AMT Relay| Subnet | 110 | | +-----+-+ Prefix +-+-----+ | Prefix | 111 | | |AMT IF | <--------|AMT IF | |--------> | 112 | | +-----+-+ +-+-----+ | | 113 | +------+----+ +----+----+ | 114 | | | | 115 +---------------+ +---------------+ 117 Figure 1: Automatic Multicast Definitions. 119 AMT Pseudo-Interface 120 AMT encapsulation of multicast packets inside unicast packets 121 occurs at a point that is logically equivalent to an 122 interface, with the link layer being the unicast-only 123 network. This point is referred to as a pseudo-interface. 124 Some implementors may treat it exactly like any other 125 interface and others may treat it like a tunnel end-point. 127 Draft AMT February 2001 129 AMT Gateway 130 A host, or a site gateway router, supporting an AMT Pseudo- 131 Interface. It does not have native multicast connectivity to 132 the native multicast backbone infrastructure. It is simply 133 referred to in this document as a "gateway". 135 AMT Site 136 A multicast-enabled network not connected to the multicast 137 backbone served by an AMT Gateway. It could also be a stand- 138 alone AMT Gateway. 140 AMT Relay Router 141 A multicast router configured to support transit routing 142 between AMT Sites and the native multicast backbone 143 infrastructure. The relay router has one or more interfaces 144 connected to the native multicast infrastructure, zero or 145 more interfaces connected to the non-multicast capable 146 internetwork, and an AMT pseudo-interface. It is simply 147 referred to in this document as a "relay". 149 As with [6TO4], we assume that normal multicast routers do 150 not want to be tunnel endpoints (especially if this results 151 in high-fanout), and similarly that service providers do not 152 want encapsulation to arbitrary routers. Instead, we assume 153 that special-purpose routers will be deployed that are 154 suitable for serving as relays. 156 AMT Relay Anycast Prefix 157 A well-known address prefix used to advertise (into the 158 unicast routing infrastructure) a route to an available AMT 159 Relay Router. 161 The value of this prefix is x.x.x.0/nn [length and value TBD 162 IANA]. 164 AMT Relay Anycast Address 165 An anycast address which is used to reach the nearest AMT 166 Relay Router. 168 This address corresponds to host number 1 in the AMT Relay 169 Anycast Prefix, x.x.x.1. 171 AMT Unicast Autonomous System ID 172 A 16-bit Autonomous system ID, for use in BGP in accordance 173 to this memo. AS 10888 might be usable for this, but for now 175 Draft AMT February 2001 177 we'll assume it's different, to avoid confusion. This number 178 represents a "pseudo-AS" common to all AMT relays. 180 To protect themselves from erroneous advertisements, managers 181 of border routers often use databases to check the relation 182 between the advertised network and the last hop in the AS 183 path. Associating a specific AS number with the AMT Relay 184 Anycast Address allows us to enter this relationship in the 185 databases used to check inter-domain routing [ANYCAST]. 187 AMT Subnet Prefix 188 A well-known address prefix used to advertise (into the M-RIB 189 of the native multicast-enabled infrastructure) a route to 190 AMT Sites. This prefix will be used to enable sourcing SSM 191 traffic from an AMT Gateway. 193 AMT Gateway Anycast Address 194 An anycast address in the AMT Subnet Prefix range, which is 195 used by an AMT Gateway to enable sourcing SSM traffic from 196 local applications. 198 AMT Multicast Autonomous System ID 199 A 16-bit Autonomous system ID, for use in MBGP in accordance 200 to this memo. We assume that the existing AS 10888 is 201 suitable for this purpose. (Note: if this is a problem, a 202 different one would be fine.) 204 4. Overview 206 4.1. Receiving Multicast in an AMT Site 208 +---------------+ Internet +---------------+ 209 | AMT Site | | MBone | 210 | | 3. Data | | 211 | 1. Join +---+---+ <================= +---+---+ | 212 | +---->|Gateway| | Relay | | 213 | | +---+---+ =================> +---+---+ | 214 | R-+ | 2. IGMP Report | | 215 +---------------+ +---------------+ 217 Figure 2: Receiving Multicast in an AMT Site. 219 AMT relays and gateways cooperate to transmit multicast traffic 220 sourced within the native multicast infrastructure to AMT sites: 222 Draft AMT February 2001 224 relays receive the traffic natively and unicast-encapsulate it to 225 gateways; gateways decapsulate the traffic and possibly re- 226 multicast it in the AMT site. 228 Each gateway has an AMT pseudo-interface that serves as a default 229 multicast route. Requests to join a multicast session are sent to 230 this interface and encapsulated to a particular relay reachable 231 across the unicast-only infrastructure. 233 Each relay has an AMT pseudo-interface too. Multicast traffic 234 sent on this interface is encapsulated to zero or more gateways 235 that have joined to the relay. The AMT recipient-list is 236 determined for each multicast session. This requires the relay to 237 keep state for each gateway which has joined a particular group 238 (or (source, group) pair). Multicast packets from the native 239 infrastructure behind the relay will be sent to each gateway which 240 has requested them. 242 All multicast packets (data and control) are encapsulated in 243 unicast packets. To work across NAT's, the encapsulation is done 244 over UDP using a well-known port number [TBD IANA]. 246 Each relay, plus the set of all gateways (perhaps unknown to the 247 relay) using the relay, together can be thought of as being on a 248 separate logical NBMA link. This implies that the AMT recipient- 249 list is a list of "link layer" addresses which are (IP address, 250 UDP port) pairs. 252 Since the number of gateways using a relay can be quite large, and 253 we expect that most sites will not want to receive most groups, an 254 explicit-joining protocol is required for gateways to communicate 255 group membership information to a relay. The two most likely 256 candidates are the IGMP [IGMP] protocol, and the PIM-Sparse Mode 257 [PIMSM] protocol. Since an AMT gateway may be a host, and hosts 258 typically do not implement routing protocols, gateways will use 259 IGMP as described in Section 5 below. This allows a host kernel 260 (or a pseudo device driver) to easily implement AMT gateway 261 behavior, and obviates the relay from the need to know whether a 262 given gateway is a host or a router. From the relay's 263 perspective, all gateways are indistinguishable from hosts on an 264 NBMA leaf network. 266 Draft AMT February 2001 268 4.1.1. Scalability Considerations 270 The requirement that a relay keep group state per gateway that has 271 joined the group introduces potential scalability concerns. 273 However, scalability of AMT can be achieved by adding more relays, 274 and using an appropriate relay discovery mechanism for gateways to 275 discover relays. The solution we adopt is to assign an anycast 276 address to relays. However, simply sending periodic IGMP Reports 277 to an anycast address can cause duplicates. Specifically, if 278 routing changes such that a different relay receives a periodic 279 IGMP Report, both the new and old relays will encapsulate data to 280 the AMT site until the old relay's state times out. This is 281 obviously undesirable. Instead, we use the anycast address merely 282 to find a unicast address which can then be used. 284 Since adding another relay has the result of adding another 285 independent NBMA link, this allows the gateways to be spread out 286 among more relays so as to keep the number of gateways per relay 287 at a reasonable level. 289 4.2. Sourcing Multicast from an AMT site 291 Two cases are discussed below: multicast traffic sourced in an AMT 292 site and received in the MBone, and multicast traffic sourced in 293 an AMT site and received in another AMT site. 295 In both cases only SSM sources are supported. Furthermore this 296 specification only deals with the source residing directly in the 297 gateway. To enable a generic node in an AMT site to source 298 multicast, additional coordination between the gateway and the 299 source-node is required. 301 The general mechanism used to join towards AMT sources is based on 302 the following: 304 o Applications residing in the gateway use addresses in the AMT 305 Subnet Prefix to send multicast, as a result of sourcing traffic 306 on the AMT pseudo-interface. 308 o The AMT Subnet Prefix is advertised for RPF reachability in the 309 M-RIB by relays and gateways. 311 Draft AMT February 2001 313 o Relays or gateways that receive a join for a source/group pair 314 use information encoded in the address pair to rebuild the 315 address of the gateway (source) to which to encapsulate the IGMP 316 Report (see section 5 for more details). 318 It is expected that this mechanism will be the identical to that 319 used to join back to a source on normal media, as is being 320 proposed in the SSM WG. 322 4.2.1. Supporting Site-MBone Multicast 324 +---------------+ Internet +---------------+ 325 | AMT Site | | MBone | 326 | | 3. Data | | 327 | +---+---+ =================> +---+---+ 1. Join | 328 | |Gateway| | Relay |<-----+ | 329 | +---+---+ <================= +---+---+ | | 330 | | 2. IGMP Report | +-R | 331 +---------------+ +---------------+ 333 Figure 3: Site-MBone Multicast. 335 If a relay receives an explicit join from the native 336 infrastructure, for a given (source, group) pair where the source 337 address belongs to the AMT Subnet Prefix, then the relay will 338 periodically (using the rules specified in Section 5) UDP 339 encapsulate an IGMP Report for the group to the gateway. The 340 gateway must keep state per relay from which an IGMP Report has 341 been sent, and forward multicast traffic from the site to all 342 relays from which IGMP Reports have been received. The choice of 343 whether this state and replication is done at the link-layer 344 (i.e., by the tunnel interface) or at the network-layer is 345 implementation-dependent. 347 If there are multiple relays present, this ensures that data from 348 the AMT site is received via the closest relay to the receiver. 349 This is necessary when the routers in the native multicast 350 infrastructure employ Reverse-Path Forwarding (RPF) checks against 351 the source address, such as occurs when [PIMSM] is used by the 352 multicast infrastructure. 354 The solution above will scale to an arbitrary number of relays, as 355 long at the number of relays requiring multicast traffic from a 356 given AMT site remains reasonable enough to not overly burden the 357 Draft AMT February 2001 359 site's gateway. 361 4.2.2. Supporting Site-Site Multicast 363 +---------------+ Internet +---------------+ 364 | AMT Site | | AMT Site | 365 | | 3. Data | | 366 | +---+---+ =================> +---+---+ 1. Join | 367 | |Gateway| |Gateway|<-----+ | 368 | +---+---+ <================= +---+---+ | | 369 | | 2. IGMP Report | +-R | 370 +---------------+ +---------------+ 372 Figure 4: Site-Site Multicast. 374 Since we require gateways to accept IGMP Reports, as described 375 above, it is also possible to support multicast among AMT sites, 376 without requiring assistance from any relays. 378 When a gateway wants to join a given (source, group) pair, where 379 the source address belongs to the AMT Subnet Prefix, then the 380 gateway will periodically unicast encapsulate an IGMPv3 [IGMPv3] 381 Report directly to the site gateway for the source. 383 We note that this can result in a significant amount of state at a 384 site gateway sourcing multicast to a large number of other AMT 385 sites. However, it is expected that this is not unreasonable for 386 two reasons. First, the gateway does not have native multicast 387 connectivity, and as a result is likely doing unicast replication 388 at present. The amount of state is thus the same as what such a 389 site already deals with. Secondly, any site expecting to source 390 traffic to a large number of sites could get a point-to-point 391 tunnel to the native multicast infrastructure, and use that 392 instead of AMT. 394 5. AMT Gateway Details 396 This section details the behavior of an AMT Gateway, which may be 397 a router serving an AMT site, or the site may consist of a single 398 host, serving as its own gateway. 400 Draft AMT February 2001 402 5.1. At Startup Time 404 At startup time, the AMT gateway will bring up an AMT pseudo- 405 interface, to be used for encapsulation. The gateway will then 406 send a UDP encapsulated ICMP Echo Request to the AMT Relay Anycast 407 Address, and note the unicast address (which is treated as a link- 408 layer address to the encapsulation interface) from the UDP 409 encapsulated ICMP Echo Response. These "pings" should be done 410 periodically (e.g., once a day) to re-resolve the unicast address 411 of a close relay. Note that the ICMP messages are unicast 412 encapsulated, just as the multicast packets. 414 The gateway also initializes a timer used to send periodic IGMP 415 Reports to a random value from the interval [0, [Query Interval]] 416 before sending the first periodic report, in order to prevent 417 startup synchronization (e.g., after a power outage). 419 If the gateway is serving as a local router, it SHOULD also 420 function as an IGMP Proxy, as described in [IGMPPROXY], with its 421 IGMP host-mode interface being the AMT pseudo-interface. This 422 enables it to translate group memberships on its downstream 423 interfaces into IGMP Reports. The gateway MUST also advertise 424 itself as the default route for multicast in the M-RIB (or it must 425 be the default unicast router if unicast and multicast topologies 426 are congruent). Also, if a shared tree routing protocol is used 427 inside the AMT site, each tree-root must be a gateway, e.g., in 428 PIM-SM each RP must be a gateway. 430 Finally, to support sourcing traffic to SSM groups by a gateway 431 with a global unicast address, the AMT Subnet Prefix is treated as 432 the subnet prefix of the AMT pseudo-interface, and an anycast 433 address is added on the interface. This anycast address is formed 434 by concatenating the AMT Subnet Prefix followed by the high bits 435 of the gateway's global unicast address. For example, if IANA 436 assigns the prefix x.y/16 as the AMT Subnet Prefix, and the 437 gateway has global unicast address a.b.c.d, then the AMT Gateway's 438 Anycast Address will be x.y.a.b. Note that multiple gateways 439 might end up with the same address assigned to their pseudo- 440 interfaces. 442 5.2. Joining Groups with MBone Sources 444 The IGMP protocol usually operates by having the Querier multicast 445 an IGMP Query message on the link. This behavior does not work on 446 Draft AMT February 2001 448 NBMA links which do not support multicast. Since the set of 449 gateways is typically unknown to the relay (and potentially quite 450 large), unicasting the queries is also impractical. The following 451 behavior is used instead. 453 Applications residing in a gateway should join groups on the AMT 454 pseudo-interface, causing IGMP Membership Reports to be sent over 455 that interface. When UDP encapsulating the IGMP Reports (and in 456 fact any other messages, unless specified otherwise in this 457 document), the destination address in the outer IP header is the 458 relay's unicast address. To provide robustness, gateways unicast 459 IGMP Reports to the relay every [Query Interval] (defined as 125 460 in [IGMP]) seconds. 462 Generating periodic reports can be done in any implementation- 463 specific manner. Some possibilities include: 465 o The AMT pseudo-interface might periodically manufacture 466 IGMPv3 Queries as if they had been received from an IGMP 467 Querier, and deliver them to the IP layer, after which normal 468 IGMP behavior will cause the appropriate reports to be sent. 470 o The IGMP module itself might provide an option to operate in 471 periodic mode on specific interfaces. 473 5.3. Responding to Relay Changes 475 When a gateway determines that its current relay is unreachable 476 (e.g., upon receipt of a ICMP Unreachable message for the relay's 477 unicast address), it immediately repeats the unicast address 478 resolution step by sending a UDP encapsulated ICMP Echo Request to 479 the AMT Relay Anycast Address, and storing the source address of 480 the UDP encapsulated ICMP Echo Response as the new unicast address 481 to use as a "link-layer" destination. 483 5.4. Creating SSM groups 485 When a gateway wants to create an SSM group (i.e., in 232/8) for 486 which it can source traffic, the remaining 24 bits must be 487 generated as described below. ([SSM] states that "the policy for 488 allocating these bits is strictly locally determined at the 489 sender's host.") 490 Draft AMT February 2001 492 When the gateway determined its AMT Gateway Anycast Address as 493 described above, it used the high bits of its global unicast 494 address. The remaining bits of its global unicast address are 495 appended to the 232/8 prefix, and any spare bits may be allocated 496 using any policy (again, strictly locally determined at the 497 sender's host). 499 For example, if IANA allocates x.y/16 as the AMT Subnet Prefix, 500 and the device has global unicast address a.b.c.d, then it must 501 allocate SSM groups in the range 232.c.d/24. 503 5.5. Joining SSM Groups with AMT Sources 505 An IGMPv3 Report for a given (source, group) pair MAY be 506 encapsulated directly to the source, when the source address 507 belongs to the AMT Subnet Prefix. (It is expected that this 508 mechanism will be the same mechanism as that used to join back to 509 a source on normal media, as is being proposed in the SSM WG.) 511 The "link-layer" address to use as the destination address in the 512 outer IP header is obtained as follows. The source address in the 513 inclusion list of the IGMPv3 report will be an AMT Gateway Anycast 514 Address with the high bits of the address, and the remaining bits 515 will be in the middle of the group address. 517 For example, if IANA assigns x.y/16 as the AMT Subnet Prefix, and 518 the IGMPv3 Report is for (x.y.a.b, 232.c.d.e), then the "link 519 layer" destination address used for encapsulation is a.b.c.d. 521 5.6. Receiving IGMPv3 Reports on the AMT Interface 523 When an IGMPv3 report is received on the AMT pseudo-interface, and 524 the report is a request to join a given (S, G) pair, then the 525 following actions are taken. 527 If S is not the AMT Gateway Anycast Address of the gateway, the 528 packet is dropped. If G does not contain the low bits of the 529 global unicast address (as described above), the packet is also 530 dropped. 532 Otherwise, the gateway adds the source address (from the outer IP 533 header) and UDP port of the report to a membership list for G. 534 Maintaining this membership list may be done in any 535 Draft AMT February 2001 537 implementation-dependent manner. For example, it might be 538 maintained by the "link-layer" inside the AMT pseudo-interface, 539 making it invisible to the normal IGMP module. 541 5.7. Sending data to SSM groups 543 When multicast packets are sent on the AMT pseudo-interface, they 544 are encapsulated as follows. If the group address is not an SSM 545 group, then the packet is dropped (this memo does not currently 546 provide a way to send to non-SSM groups). 548 If the group address is an SSM group, then the packet is unicast 549 encapsulated to each remote node from which the gateway has 550 received an IGMPv3 report for the packet's (source, group) pair. 552 6. Relay Router Details 554 6.1. At startup time 556 At startup time, the relay router will bring up an NBMA-style AMT 557 pseudo-interface. It shall also add the AMT Relay Anycast Address 558 on some interface. 560 The relay router shall then advertise the AMT Relay Anycast Prefix 561 into the unicast-only Internet, as if it were a connection to an 562 external network. When the advertisement is done using BGP, the 563 AS path leading to the AMT Relay Anycast Prefix shall include the 564 identifier of the local AS and the AMT Unicast Autonomous System 565 ID. 567 The relay router shall also enable IGMPv3 on the AMT pseudo- 568 interface, except that it shall not multicast Queries (this might 569 be done, for example, by having the AMT pseudo-device drop them, 570 or by having the IGMP module not send them in the first place). 572 Finally, to support sourcing SSM traffic from AMT sites, the AMT 573 Subnet Prefix is assigned to the AMT pseudo-interface, and the AMT 574 Subnet Prefix is injected into the M-RIB of MBGP. 576 Draft AMT February 2001 578 6.2. Receiving Echo Requests to the Anycast Address 580 When a relay receives a UDP encapsulated ICMP Echo Request 581 directed to the AMT Relay Anycast Address, it should respond with 582 a UDP encapsulated ICMP Echo Response from a unicast address 583 reachable on the unicast-only network (anycast addresses should 584 not be used as the source address of the ICMP Echo Response). 586 Unicast encapsulation of the ICMP Echo Request ensures that the 587 message will be seen by the AMT pseudo-interface which can then 588 process it. Specifically, it needs to ensure that the ICMP Echo 589 Response contains the appropriate source address. 591 6.3. Receiving Joins from AMT Gateways 593 The relay operates passively, sending no Queries but simply 594 tracking membership information according to Reports and Leave 595 messages, as a router normally would. In addition, the relay must 596 also do explicit membership tracking, as to which gateways on the 597 AMT pseudo-interface have joined which groups. When data arrives 598 for that group, the traffic must be encapsulated to each gateway 599 which has joined that group. 601 The explicit membership tracking and unicast replication may be 602 done in any implementation-specific manner. Some examples are: 604 o The AMT pseudo-device driver might track the group 605 information and perform the replication at the "link-layer", 606 with no changes to a pre-existing IGMP module. 608 o The IGMP module might have native support for explicit 609 membership tracking, especially if it supports other NBMA- 610 style interfaces. 612 6.4. Receiving (S,G) Joins from the Native Side, for AMT 613 Sources 615 The relay encapsulates an IGMPv3 report to the AMT source as 616 described above in Section 5.5. 618 Draft AMT February 2001 620 7. IANA Considerations 622 The IANA should allocate a prefix dedicated to the AMT Relays to 623 the native multicast backbone. The prefix length should be 624 determined by the IANA; the prefix should be large enough to 625 guarantee advertisement in the default- free BGP networks; a 626 length of 16 will meet this requirement. This is a one time 627 effort; there is no need for any recurring assignment after this 628 stage. 630 The IANA should also allocate an Autonomous System ID which can be 631 used as a pseudo-AS when advertising routes to the above prefix. 633 Furthermore, to support sourcing SSM traffic from AMT gateways, 634 the IANA should allocate a subnet prefix dedicated to the AMT 635 link. The prefix length should be determined by the IANA; the 636 prefix should be large enough to guarantee advertisement in the 637 default- free BGP networks; a length of 16 will meet this 638 requirement. This is a one time effort; there is no need for any 639 recurring assignment after this stage. It should also be noted 640 that this prefix length directly affects the number of groups 641 available to be created by the AMT gateway: a length of 16 gives 642 256 groups, and a length of 8 gives 65536 groups. For diagnostic 643 purposes, it is helpful to have a prefix length which is a 644 multiple of 8, although this is not required. 646 An autonomous system number dedicated to a pseudo-AS for multicast 647 is already in use today (AS 10888), and so it is expected that no 648 additional AS number is required for this prefix. 650 Finally, IANA should reserve a well-known UDP port number for AMT 651 encapsulation. 653 8. Security Considerations 655 The anycast technique introduces a risk that a rogue router or a 656 rogue AS could introduce a bogus route to the AMT Relay Anycast 657 Prefix, and thus divert the traffic. Network managers have to 658 guarantee the integrity of their routing to the AMT Relay anycast 659 prefix in much the same way that they guarantee the integrity of 660 all other routes. 662 Within the native MBGP infrastructure, there is a risk that a 663 rogue router or a rogue AS could introduce a bogus route to the 664 Draft AMT February 2001 666 AMT Subnet Prefix, and thus divert joins and cause RPF failures of 667 multicast traffic. Again, network managers have to guarantee the 668 integrity of the MBGP routing to the AMT subnet prefix in much the 669 same way that they guarantee the integrity of all other routes in 670 the M-RIB. 672 By default, gateways and relays will accept and decapsulate 673 multicast traffic any source from which regular unicast traffic is 674 accepted. If this is for any reason felt to be a security risk, 675 then additional source address based packet filtering could be 676 applied. 678 9. Acknowledgements 680 Most of the mechanisms described in this document are based on 681 similar work done by the NGTrans WG for obtaining automatic IPv6 682 connectivity without explicit tunnels ("6to4"). Tony Ballardie 683 provided helpful discussion that inspired this document. 685 10. Appendix A: Open Issues 687 Under the proposed mechanism, a gateway sends its IGMPv3 Reports 688 for MBone sources to the relay closest to itself (discovered using 689 the UDP encapsulated "ping"). This ensures that, as far as 690 possible, multicast traffic flows through the native multicast 691 infrastructure and the automatic multicast encapsulation is short. 693 However, there might be reasons to create automatic tunnels to the 694 relay closest to the MBone source instead. An ISP, for example, 695 might be willing to provide a relay for only its own customers, 696 those wishing to multicast their transmission to a much wider 697 audience. A mechanism, complementary to the one described in this 698 document, might be used to provide this facility. It uses UDP 699 encapsulated ICMP Redirect messages as described below. 701 While injecting routes for its sources into the M-RIB, such an ISP 702 might, for example, use a new BGP attribute to convey the address 703 of the preferred relay. This would let other relays redirect any 704 IGMP Reports to the preferred relay by sending a UDP encapsulated 705 ICMP Redirect. 707 An IGMP Report sent by a gateway to the relay closest to it would 708 consist of the following packet: 710 Draft AMT February 2001 712 OuterIP [UDP [InnerIP [IGMP Report]]] 714 The relay would respond with: 716 OuterIP' [UDP' [InnerIP' [ICMP Redirect [InnerIP [IGMP Report]]]]] 718 An ICMP Redirect contains the first 64 bits of the original packet 719 [ICMP]. Hence the gateway would get 44 bytes (64 - sizeof(Inner 720 IP)) of the IGMP Report, enough to easily extract the (source, 721 group) pair, and redirect its report to the preferred gateway. 723 Certainly additional complexity is undesirable, so it is an open 724 issue as to whether redirects are needed at all. 726 11. Authors' Addresses 728 Dave Thaler 729 Microsoft Corporation 730 One Microsoft Way 731 Redmond, WA 98052-6399 732 Phone: +1 425 703 8835 733 EMail: dthaler@microsoft.com 735 Mohit Talwar 736 Microsoft Corporation 737 One Microsoft Way 738 Redmond, WA 98052-6399 739 Phone: +1 425 705 3131 740 EMail: mohitt@microsoft.com 742 Lorenzo Vicisano 743 Cisco Systems 744 170 West Tasman Dr. 745 San Jose, CA 95134 746 Phone: +1 408 525 2530 747 EMail: lorenzo@cisco.com 749 Dirk Ooms 750 Alcatel 751 F. Wellesplein 1, 2018 Antwerp, Belgium 752 Phone: +32 3 2404732 753 EMail: dirk.ooms@alcatel.be 755 Draft AMT February 2001 757 12. References 759 [6TO4] 760 Carpenter, B., and K. Moore, "Connection of IPv6 Domains via 761 IPv4 Clouds", RFC 3056, February 2001. 763 [BROKER] 764 Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 765 Tunnel Broker", RFC 3053, January 2001. 767 [ANYCAST] 768 C. Huitema, "An anycast prefix for 6to4 relay routers", Work 769 in progress, draft-ietf-ngtrans-6to4anycast-02.txt, February 770 2001. 772 [BGMP] 773 Thaler, D., Estrin, D., and D. Meyer, "Border Gateway 774 Multicast Protocol (BGMP): Protocol Specification", Work in 775 progress, draft-ietf-bgmp-spec-02.txt, November 2000. 777 [ICMP] 778 Postel, J., "Internet Control Message Protocol", RFC 792, 779 September 1981. 781 [IGMPPROXY] 782 W. Fenner, "IGMP-based Multicast Forwarding (``IGMP 783 Proxying'')", Work in progress, draft-fenner-igmp- 784 proxy-03.txt, July 2000. 786 [IGMP] 787 W. Fenner, "Internet Group Management Protocol, Version 2", 788 RFC 2236, November 1997. 790 [IGMPv3] 791 Cain, B., Deering, S., Fenner, B., Kouvelas, I., and A. 792 Thyagarajan, "Internet Group Management Protocol, Version 3", 793 Work in progress, draft-ietf-idmr-igmp-v3-06.txt, January 794 2001. 796 [PIMSM] 797 Estrin, D. Farinacci, D., Helmy, A., Thaler, D., Deering, S., 798 Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei. 799 "Protocol Independent Multicast-Sparse Mode (PIM-SM): 800 Protocol Specification", RFC 2362, June 1998. 802 Draft AMT February 2001 804 [SSM] 805 Holbrook, H., and B. Cain, "Source-Specific Multicast for 806 IP", Work in progress, draft-holbrook-ssm-arch-01.txt, 807 November 2000. 809 13. Full Copyright Statement 811 Copyright (C) The Internet Society (2001). All Rights Reserved. 813 This document and translations of it may be copied and furnished 814 to others, and derivative works that comment on or otherwise 815 explain it or assist in its implmentation may be prepared, copied, 816 published and distributed, in whole or in part, without 817 restriction of any kind, provided that the above copyright notice 818 and this paragraph are included on all such copies and derivative 819 works. However, this document itself may not be modified in any 820 way, such as by removing the copyright notice or references to the 821 Internet Society or other Internet organizations, except as needed 822 for the purpose of developing Internet standards in which case the 823 procedures for copyrights defined in the Internet Standards 824 process must be followed, or as required to translate it into 825 languages other than English. 827 The limited permissions granted above are perpetual and will not 828 be revoked by the Internet Society or its successors or assigns. 830 This document and the information contained herein is provided on 831 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 832 ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 833 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 834 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 835 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.