idnits 2.17.1 draft-ietf-mboned-routingarch-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1059. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1070. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1077. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1083. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 21, 2006) is 6365 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-12) exists of draft-ietf-isis-wg-multi-topology-11 == Outdated reference: A later version (-07) exists of draft-ietf-mboned-addrarch-05 ** Downref: Normative reference to an Informational draft: draft-ietf-mboned-addrarch (ref. 'I-D.ietf-mboned-addrarch') == Outdated reference: A later version (-09) exists of draft-ietf-ospf-mt-06 == Outdated reference: A later version (-09) exists of draft-ietf-pim-bidir-08 ** Downref: Normative reference to an Experimental RFC: RFC 3618 ** Downref: Normative reference to an Experimental RFC: RFC 3973 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) == Outdated reference: A later version (-07) exists of draft-ietf-l2vpn-vpls-pim-snooping-00 == Outdated reference: A later version (-04) exists of draft-ietf-pim-lasthop-threats-00 == Outdated reference: A later version (-12) exists of draft-ietf-pim-sm-bsr-09 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force P. Savola 3 Internet-Draft CSC/FUNET 4 Obsoletes: November 21, 2006 5 3913,2189,2201,1584,1585 6 (if approved) 7 Intended status: Best Current 8 Practice 9 Expires: May 25, 2007 11 Overview of the Internet Multicast Routing Architecture 12 draft-ietf-mboned-routingarch-07.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 BCP 79. 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 This Internet-Draft will expire on May 25, 2007. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2006). 43 Abstract 45 The lack of up-to-date documentation on IP multicast routing 46 protocols and procedures has caused a great deal of confusion. To 47 clarify the situation, this memo describes the routing protocols and 48 techniques currently (as of this writing) in use. This memo also 49 Obsoletes and reclassifies to Historic a number of older multicast 50 protocols. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 1.1. Multicast-related Abbreviations . . . . . . . . . . . . . 5 56 2. Multicast Routing . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1. Setting up Multicast Forwarding State . . . . . . . . . . 6 58 2.1.1. PIM-SM . . . . . . . . . . . . . . . . . . . . . . . . 6 59 2.1.2. PIM-DM . . . . . . . . . . . . . . . . . . . . . . . . 6 60 2.1.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 6 61 2.1.4. DVMRP . . . . . . . . . . . . . . . . . . . . . . . . 7 62 2.1.5. MOSPF . . . . . . . . . . . . . . . . . . . . . . . . 7 63 2.1.6. BGMP . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 2.1.7. CBT . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 2.1.8. Interactions and Summary . . . . . . . . . . . . . . . 8 66 2.2. Distributing Topology Information . . . . . . . . . . . . 8 67 2.2.1. Multi-protocol BGP . . . . . . . . . . . . . . . . . . 9 68 2.2.2. OSPF/IS-IS Multi-topology Extensions . . . . . . . . . 9 69 2.2.3. Issue: Overlapping Unicast/multicast Topology . . . . 9 70 2.2.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 10 71 2.3. Learning (Active) Sources . . . . . . . . . . . . . . . . 10 72 2.3.1. SSM . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 2.3.2. MSDP . . . . . . . . . . . . . . . . . . . . . . . . . 11 74 2.3.3. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 11 75 2.3.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 12 76 2.4. Configuring and Distributing PIM RP Information . . . . . 12 77 2.4.1. Manual RP Configuration . . . . . . . . . . . . . . . 12 78 2.4.2. Embedded-RP . . . . . . . . . . . . . . . . . . . . . 13 79 2.4.3. BSR and Auto-RP . . . . . . . . . . . . . . . . . . . 13 80 2.4.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 13 81 2.5. Mechanisms for Enhanced Redundancy . . . . . . . . . . . . 14 82 2.5.1. Anycast RP . . . . . . . . . . . . . . . . . . . . . . 14 83 2.5.2. Stateless RP Failover . . . . . . . . . . . . . . . . 14 84 2.5.3. Bi-directional PIM . . . . . . . . . . . . . . . . . . 14 85 2.5.4. Summary . . . . . . . . . . . . . . . . . . . . . . . 15 86 2.6. Interactions with Hosts . . . . . . . . . . . . . . . . . 15 87 2.6.1. Hosts Sending Multicast . . . . . . . . . . . . . . . 15 88 2.6.2. Hosts Receiving Multicast . . . . . . . . . . . . . . 15 89 2.6.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 15 90 2.7. Restricting Multicast Flooding in the Link Layer . . . . . 16 91 2.7.1. Router-to-Router Flooding Reduction . . . . . . . . . 16 92 2.7.2. Host/Router Flooding Reduction . . . . . . . . . . . . 16 93 2.7.3. Summary . . . . . . . . . . . . . . . . . . . . . . . 17 94 3. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 95 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 96 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 97 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 98 6.1. Normative References . . . . . . . . . . . . . . . . . . . 18 99 6.2. Informative References . . . . . . . . . . . . . . . . . . 20 100 Appendix A. Multicast Payload Transport Extensions . . . . . . . 22 101 A.1. Reliable Multicast . . . . . . . . . . . . . . . . . . . . 23 102 A.2. Multicast Group Security . . . . . . . . . . . . . . . . . 23 103 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 23 104 Intellectual Property and Copyright Statements . . . . . . . . . . 24 106 1. Introduction 108 Good, up-to-date documentation of IP multicast is close to non- 109 existent. This issue is severely felt with multicast routing 110 protocols and techniques. The consequence is that those who wish to 111 learn of IP multicast and how the routing works in the real world do 112 not know where to begin. Multicast addressing is described in a 113 companion document [I-D.ietf-mboned-addrarch]. 115 The aim of this document is to provide a brief overview of multicast 116 routing protocols and techniques. 118 This memo deals with: 120 o setting up multicast forwarding state (Section 2.1), 122 o distributing multicast topology information (Section 2.2), 124 o learning active sources (Section 2.3), 126 o configuring and distributing the PIM RP information (Section 2.4), 128 o mechanisms for enhanced redundancy (Section 2.5), 130 o interacting with hosts (Section 2.6), and 132 o restricting the multicast flooding in the link layer 133 (Section 2.7). 135 Section 2 starts by describing a simplistic example how these classes 136 of mechanisms fit together. Some multicast data transport issues are 137 also introduced in Appendix A. 139 This memo obsoletes and re-classifies to Historic [RFC2026] Border 140 Gateway Multicast Protocol (BGMP), Core Based Trees (CBT), Multicast 141 OSPF (MOSPF) RFCs: [RFC3913], [RFC2189], [RFC2201], [RFC1584], and 142 [RFC1585]. The purpose of the re-classification is to give the 143 readers (both implementors and deployers) an idea what the status of 144 a protocol is; there may be legacy deployments of some of these 145 protocols, which are not affected by this reclassification. See 146 Section 2.1 for more on each protocol. 148 Further historical perspective may be found in, for example, 149 [RFC1458], [IMRP-ISSUES], and [IM-GAPS]. 151 1.1. Multicast-related Abbreviations 153 ASM Any Source Multicast 154 BGMP Border Gateway Multicast Protocol 155 BSR Bootstrap Router 156 CBT Core Based Trees 157 CGMP Cisco Group Management Protocol 158 DR Designated Router 159 DVMRP Distance Vector Multicast Routing Protocol 160 GARP (IEEE 802.1D-2004) Generic Attribute Reg. Protocol 161 GMRP GARP Multicast Registration Protocol 162 IGMP Internet Group Management Protocol 163 MBGP Multi-protocol BGP (*not* "Multicast BGP") 164 MLD Multicast Listener Discovery 165 MRP (IEEE 802.1ak) Multiple Registration Protocol 166 MMRP (IEEE 802.1ak) Multicast Multiple Registration Proto. 167 MOSPF Multicast OSPF 168 MSDP Multicast Source Discovery Protocol 169 PGM Pragmatic General Multicast 170 PIM Protocol Independent Multicast 171 PIM-DM PIM - Dense Mode 172 PIM-SM PIM - Sparse Mode 173 PIM-SSM PIM - Source-Specific Multicast 174 RGMP (Cisco's) Router Group Management Protocol 175 RP Rendezvous Point 176 SSM Source-specific Multicast 178 2. Multicast Routing 180 In order to give a simplified summary how each of these class of 181 mechanisms fits together, consider the following multicast receiver 182 scenario. 184 When a host wants to receive a transmission, it first needs to find 185 out the multicast group address (and with SSM, source address) using 186 unspecified means. Then it will signal its interest to its router 187 using IGMP or MLD (Section 2.6). To deliver a multicast 188 transmission, the router will need to know how to build the 189 distribution tree which includes all the sources (Section 2.3) and/or 190 to locate the RP (Section 2.4) or one of RPs (Section 2.5). In 191 scenarios where multicast is routed via different topology than 192 unicast, a means to distribute topology information is required 193 (Section 2.2). Nonetheless, using whatever topology information is 194 available, the first-hop router initiates setting up hop-by-hop 195 multicast forwarding state (Section 2.1). When multicast 196 transmission arrives at the receiver's LAN, it is flooded to every 197 port unless flooding reduction such as IGMP snooping is employed 198 (Section 2.7). 200 2.1. Setting up Multicast Forwarding State 202 The most important part of multicast routing is setting up the 203 multicast forwarding state. This section describes the protocols 204 commonly used for this purpose. 206 2.1.1. PIM-SM 208 By far, the most common multicast routing protocol is PIM-SM 209 [RFC4601]. The PIM-SM protocol includes both Any Source Multicast 210 (ASM) and Source-Specific Multicast (SSM) functionality; PIM-SSM is a 211 subset of PIM-SM. Most current routing platforms support PIM-SM. 213 2.1.2. PIM-DM 215 Whereas PIM-SM has been designed to avoid unnecessary flooding of 216 multicast data, PIM-DM [RFC3973] assumed that almost every subnet at 217 a site had at least one receiver for a group. PIM-DM floods 218 multicast transmissions throughout the network ("flood and prune") 219 unless the leaf parts of the network periodically indicate that they 220 are not interested in that particular group. 222 PIM-DM may be an acceptable fit in small and/or simple networks, 223 where setting up an RP would be unnecessary, and possibly in cases 224 where a large percentage of users is expected to want to receive the 225 transmission so that the amount of state the network has to keep is 226 minimal. 228 PIM-DM was used as a first step in transitioning away from DVMRP. It 229 also became apparent that most networks would not have receivers for 230 most groups, and to avoid the bandwidth and state overhead, the 231 flooding paradigm was gradually abandoned. Transitioning from PIM-DM 232 to PIM-SM was easy as PIM-SM was designed to use compatible packet 233 formats and dense-mode operation could also be satisfied by a sparse 234 protocol. PIM-DM is no longer in widespread use. 236 Many implementations also support so-called "sparse-dense" 237 configuration, where Sparse mode is used by default, but Dense is 238 used for configured multicast group ranges (such as Auto-RP in 239 Section 2.4.3) only. Lately, many networks have transitioned away 240 from sparse-dense to only sparse mode. 242 2.1.3. Bi-directional PIM 244 Bi-directional PIM [I-D.ietf-pim-bidir] is a multicast forwarding 245 protocol that establishes a common shared-path for all sources with a 246 single root. It can be used as an alternative to PIM-SM inside a 247 single domain. It doesn't have data-driven events or data- 248 encapsulation. As it doesn't keep source-specific state, it may be a 249 lucrative approach especially in sites with a large number of 250 sources. 252 As of this writing, there is no inter-domain solution to configure a 253 group range to use bi-directional PIM. 255 2.1.4. DVMRP 257 Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075] 258 [I-D.ietf-idmr-dvmrp-v3] [I-D.ietf-idmr-dvmrp-v3-as] was the first 259 protocol designed for multicasting, and to get around initial 260 deployment hurdles. It also included tunneling capabilities which 261 were part of its multicast topology functions. 263 Currently, DVMRP is used only very rarely in operator networks, 264 having been replaced with PIM-SM. The most typical deployment of 265 DVMRP is at a leaf network, to run from a legacy firewall only 266 supporting DVMRP to the internal network. However, GRE tunneling 267 [RFC2784] seems to have overtaken DVMRP in this functionality, and 268 there is relatively little use for DVMRP except in legacy 269 deployments. 271 2.1.5. MOSPF 273 MOSPF [RFC1584] was implemented by several vendors and has seen some 274 deployment in intra-domain networks. However, since it is based on 275 intra-domain OSPF it does not scale to the inter-domain case, 276 operators have found it is easier to deploy a single protocol for use 277 in both intra-domain and inter-domain networks and so it is no longer 278 being actively deployed. 280 2.1.6. BGMP 282 BGMP [RFC3913] did not get sufficient support within the service 283 provider community to get adopted and moved forward in the IETF 284 standards process. There were no reported production implementations 285 and no production deployments. 287 2.1.7. CBT 289 CBT [RFC2201][RFC2189] was an academic project that provided the 290 basis for PIM sparse mode shared trees. Once the shared tree 291 functionality was incorporated into PIM implementations, there was no 292 longer a need for a production CBT implementation. Therefore, CBT 293 never saw production deployment. 295 2.1.8. Interactions and Summary 297 It is worth noting that it is possible to run different protocols 298 with different multicast group ranges. For example, treat some 299 groups as dense or bi-dir in an otherwise PIM-SM network; this 300 typically requires manual configuration of the groups or a mechanism 301 like BSR (Section 2.4.3). It is also possible to interact between 302 different protocols, for example use DVMRP in the leaf network, but 303 PIM-SM upstream. The basics for interactions among different 304 protocols have been outlined in [RFC2715]. 306 The following figure gives a concise summary of the deployment status 307 of different protocols as of this writing. 309 +-------------+-------------+----------------+ 310 | Interdomain | Intradomain | Status | 311 +------------+-------------+-------------+----------------+ 312 | PIM-SM | Yes | Yes | Active | 313 | PIM-DM | Not anymore | Not anymore | Little use | 314 | Bi-dir PIM | No | Yes | Some uptake | 315 | DVMRP | Not anymore | Stub only | Going out | 316 | MOSPF | No | Not anymore | Inactive | 317 | CBT | No | No | Never deployed | 318 | BGMP | No | No | Never deployed | 319 +------------+-------------+-------------+----------------+ 321 From this table, it is clear that PIM-Sparse Mode is the only 322 multicast routing protocol that is deployed inter-domain and, 323 therefore, is most frequently used within multicast domains as well. 324 This is partially result of not working on inter-domain RP/group 325 configuration mechanisms since PIM-SM and MSDP (Section 2.3.2). 327 2.2. Distributing Topology Information 329 PIM has become the de-facto multicast forwarding protocol, but as its 330 name implies, it is independent of the underlying unicast routing 331 protocol. When unicast and multicast topologies are the same 332 ("congruent"), i.e., use the same routing tables (routing information 333 base, RIB), it has been considered sufficient just to distribute one 334 set of reachability information to be used in conjunction with a 335 protocol that sets up multicast forwarding state (e.g., PIM-SM). 337 However, when PIM which by default built multicast topology based on 338 the unicast topology gained popularity, it became apparent that it 339 would be necessary to be able to distribute also non-congruent 340 multicast reachability information in the regular unicast protocols. 341 This was previously not an issue, because DVMRP built its own 342 reachability information. 344 The topology information is needed to perform efficient distribution 345 of multicast transmissions and to prevent transmission loops by 346 applying it to the Reverse Path Forwarding (RPF) check. 348 This subsection introduces these protocols. 350 2.2.1. Multi-protocol BGP 352 Multiprotocol Extensions for BGP-4 [I-D.ietf-idr-rfc2858bis] (often 353 referred to as "MBGP"; however, it is worth noting that "MBGP" does 354 *not* stand for "Multicast BGP") specifies a mechanism by which BGP 355 can be used to distribute different reachability information for 356 unicast (SAFI=1) and multicast traffic (SAFI=2). Multiprotocol BGP 357 has been widely deployed for years, and is also needed to route IPv6. 358 Note that SAFI=3 was originally specified for "both unicast and 359 multicast" but has since then been deprecated. 361 These extensions are in widespread use wherever BGP is used to 362 distribute unicast topology information. Multicast-enabled networks 363 that use BGP should use Multiprotocol BGP to distribute multicast 364 reachability information explicitly even if the topologies are 365 congruent to make an explicit statement about multicast reachability. 366 A number of significant multicast transit providers even require 367 this, by doing the RPF lookups solely based on explicitly advertised 368 multicast address family. 370 2.2.2. OSPF/IS-IS Multi-topology Extensions 372 Similar to BGP, some IGPs also provide the capability for signalling 373 a differing topologies, for example IS-IS multi-topology extensions 374 [I-D.ietf-isis-wg-multi-topology]. These can be used for a multicast 375 topology that differs from unicast. Similar but not so widely 376 implemented work exists for OSPF [I-D.ietf-ospf-mt]. 378 It is worth noting that interdomain incongruence and intradomain 379 incongruence are orthogonal, so one doesn't require the other. 380 Specifically, interdomain incongruence is quite common, while 381 intradomain incongruence isn't, so you see much more deployment of 382 MBGP than MT-ISIS/OSPF. Commonly deployed networks have managed well 383 without protocols handling intradomain incongruence. However, the 384 availability of multi-topology mechanisms may in part replace the 385 typically used workarounds such as tunnels. 387 2.2.3. Issue: Overlapping Unicast/multicast Topology 389 An interesting case occurs when some routers do not distribute 390 multicast topology information explicitly while others do. In 391 particular, this happens when some multicast sites in the Internet 392 are using plain BGP while some use MBGP. 394 Different implementations deal with this in different ways. 395 Sometimes, multicast RPF mechanisms first look up the multicast 396 routing table, or M-RIB ("topology database") with a longest prefix 397 match algorithm, and if they find any entry (including a default 398 route), that is used; if no match is found, the unicast routing table 399 is used instead. 401 An alternative approach is to use longest prefix match on the union 402 of multicast and unicast routing tables; an implementation technique 403 here is to copy the whole unicast routing table over to the multicast 404 routing table. The important point to remember here, though, is to 405 not override the multicast-only routes; if the longest prefix match 406 would find both a (copied) unicast route and a multicast-only route, 407 the latter should be treated as preferable. 409 Another implemented approach is to just look up the information in 410 the unicast routing table, and provide the user capabilities to 411 change that as appropriate, using for example copying functions 412 discussed above. 414 2.2.4. Summary 416 The following table summarizes the topology distribution approaches 417 described in this Section. In particular, it is recommended that if 418 interdomain routing uses BGP, multicast-enabled sites should use MP- 419 BGP SAFI=2 for multicast and SAFI=1 for unicast even if the topology 420 was congruent. 422 +-------------+---------------+ 423 | Interdomain | Intradomain | 424 +--------------------- +--------------+--------------+ 425 | Congruent topology | Yes | Yes | 426 | BGP without SAFI | Not recomm. | Yes | 427 | MP-BGP SAFI=1 only | Not recomm. | Not recomm. | 428 | MP-BGP SAFI=2 | Recommended | Yes | 429 | MP-BGP SAFI=3 | Doesn't work | Doesn't work | 430 | IS-IS multi-topology | No | Yes | 431 | OSPF multi-topology | No | Few implem. | 432 +----------------------+--------------+--------------+ 434 2.3. Learning (Active) Sources 436 Typically, multicast routing protocols must either assume that the 437 receivers know the IP addresses of the (active) sources for a group 438 in advance, possibly using an out-of-band mechanism (SSM), or the 439 transmissions are forwarded to the receivers automatically (ASM). 441 Learning active sources is a relatively straightforward process with 442 a single PIM-SM domain and with a single RP, but having a single 443 PIM-SM domain for the whole Internet is a completely unscalable model 444 for many reasons. Therefore it is required to be able to split up 445 the multicast routing infrastructures to smaller domains, and there 446 must be a way to share information about active sources using some 447 mechanism if the ASM model is to be supported. 449 This section discusses the options. 451 2.3.1. SSM 453 Source-specific Multicast [RFC4607] (sometimes also referred to as 454 "single-source Multicast") does not count on learning active sources 455 in the network. Recipients need to know the source IP addresses 456 using an out of band mechanism which are used to subscribe to the 457 (source, group) channel. The multicast routing uses the source 458 address to set up the state and no further source discovery is 459 needed. 461 As of this writing, there are attempts to analyze and/or define out- 462 of-band source discovery functions which would help SSM in particular 463 [I-D.lehtonen-mboned-dynssm-req]. 465 2.3.2. MSDP 467 Multicast Source Discovery Protocol [RFC3618] was invented as a stop- 468 gap mechanism, when it became apparent that multiple PIM-SM domains 469 (and RPs) were needed in the network, and information about the 470 active sources needed to be propagated between the PIM-SM domains 471 using some other protocol. 473 MSDP is also used to share the state about sources between multiple 474 RPs in a single domain for, e.g., redundancy purposes [RFC3446]. The 475 same can be achieved using PIM extensions [RFC4610]. See Section 2.5 476 for more information. 478 There is no intent to define MSDP for IPv6, but instead use only SSM 479 and Embedded-RP instead [I-D.ietf-mboned-ipv6-multicast-issues]. 481 2.3.3. Embedded-RP 483 Embedded-RP [RFC3956] is an IPv6-only technique to map the address of 484 the RP to the multicast group address. Using this method, it is 485 possible to avoid the use of MSDP while still allowing multiple 486 multicast domains (in the traditional sense). 488 The model works by defining a single RP address for a particular 489 group for all of the Internet, so there is no need to share state 490 about that with any other RPs. If necessary, RP redundancy can still 491 be achieved with Anycast-RP using PIM. 493 2.3.4. Summary 495 The following table summarizes the source discovery approaches and 496 their status. 498 +------+------+------------------------------+ 499 | IPv4 | IPv6 | Status | 500 +----------------------+------+------+------------------------------+ 501 | Bi-dir single domain | Yes | Yes | OK but for intra-domain only | 502 | PIM-SM single domain | Yes | Yes | OK | 503 | PIM-SM with MSDP | Yes | No | De-facto v4 inter-domain ASM | 504 | PIM-SM w/ Embedded-RP| No | Yes | Best inter-domain ASM option | 505 | SSM | Yes | Yes | No major uptake yet | 506 +----------------------+------+------+------------------------------+ 508 2.4. Configuring and Distributing PIM RP Information 510 PIM-SM and Bi-dir PIM configuration mechanisms exist which are used 511 to configure the RP addresses and which groups are to use those RPs 512 in the routers. This section outlines the approaches. 514 2.4.1. Manual RP Configuration 516 It is often easiest just to manually configure the RP information on 517 the routers when PIM-SM is used. 519 Originally, static RP mapping was considered suboptimal since it 520 required explicit configuration changes every time the RP address 521 changed. However, with the advent of anycast RP addressing, the RP 522 address is unlikely to ever change. Therefore, the administrative 523 burden is generally limited to initial configuration. Since there is 524 usually a fair amount of multicast configuration required on all 525 routers anyway (e.g., PIM on all interfaces), adding the RP address 526 statically isn't really an issue. Further, static anycast RP mapping 527 provides the benefits of RP load sharing and redundancy (see 528 Section 2.5) without the complexity found in dynamic mechanisms like 529 Auto-RP and Bootstrap Router (BSR). 531 With such design, an anycast RP uses an address that is configured on 532 a loopback interfaces of the routers currently acting as RPs, and 533 state is distributed using PIM [RFC4610] or MSDP [RFC3446]. 535 Using this technique, each router might only need to be configured 536 with one, portable RP address. 538 2.4.2. Embedded-RP 540 Embedded-RP provides the information about the RP's address in the 541 group addresses which are delegated to those who use the RP, so 542 unless no other ASM than Embedded-RP is used, the network 543 administrator only needs to configure the RP routers. 545 While Embedded-RP in many cases is sufficient for IPv6, other methods 546 of RP configuration are needed if one needs to provide ASM service 547 for other than Embedded-RP group addresses. In particular, service 548 discovery type of applications may need hard-coded addresses that are 549 not dependent on local RP addresses. 551 As the RP's address is exposed to the users and applications, it is 552 very important to ensure it does not change often, e.g., by using 553 manual configuration of an anycast address. 555 2.4.3. BSR and Auto-RP 557 BSR [I-D.ietf-pim-sm-bsr] is a mechanism for configuring the RP 558 address for groups. It may no longer be in as wide use with IPv4 as 559 it was earlier, and for IPv6, Embedded-RP will in many cases be 560 sufficient. 562 Cisco's Auto-RP is an older, proprietary method for distributing 563 group to RP mappings, similar to BSR. Auto-RP has little use today. 565 Both Auto-RP and BSR require some form of control at the routers to 566 ensure that only valid routers are able to advertise themselves as 567 RPs. Further, flooding of BSR and Auto-RP messages must be prevented 568 at PIM borders. Additionally, routers require monitoring that they 569 are actually using the RP(s) the administrators think they should be 570 using, for example if a router (maybe in customer's control) is 571 advertising itself inappropriately. All in all, while BSR and 572 Auto-RP provide easy configuration, they also provide very 573 significant configuration and management complexity. 575 It is worth noting that both Auto-RP and BSR were deployed before the 576 use of a manually configured anycast-RP address became relatively 577 commonplace, and there is actually relatively little need for them 578 today unless there is a need to configure different properties (e.g., 579 sparse, dense, bi-dir) in a dynamic fashion. 581 2.4.4. Summary 583 The following table summarizes the RP discovery mechanisms and their 584 status. With the exception of Embedded-RP, each mechanism operates 585 within a PIM domain. 587 +------+------+-----------------------+ 588 | IPv4 | IPv6 | Deployment | 589 +--------------------+------+------+-----------------------+ 590 | Static RP | Yes | Yes | Especially in ISPs | 591 | Auto-RP | Yes | No | Legacy deployment | 592 | BSR | Yes | Yes | Some, anycast simpler | 593 | Embedded-RP | No | Yes | Growing | 594 +--------------------+------+------+-----------------------+ 596 2.5. Mechanisms for Enhanced Redundancy 598 A couple of mechanisms, already described in this document, have been 599 used as a means to enhance redundancy, resilience against failures, 600 and to recover from failures quickly. This section summarizes these 601 techniques explicitly. 603 2.5.1. Anycast RP 605 As mentioned in Section 2.3.2, MSDP is also used to share the state 606 about sources between multiple RPs in a single domain for, e.g., 607 redundancy purposes [RFC3446]. The purpose of MSDP in this context 608 is to share the same state information on multiple RPs for the same 609 groups to enhance the robustness of the service. 611 Recent PIM extensions [RFC4610] also provide this functionality. In 612 contrast to MSDP, this approach works for both IPv4 and IPv6. 614 2.5.2. Stateless RP Failover 616 It is also possible to use some mechanisms for smaller amount of 617 redundancy as Anycast RP, without sharing state between the RPs. A 618 traditional mechanism has been to use Auto-RP or BSR (see 619 Section 2.4.3) to select another RP when the active one failed. 620 However, the same functionality could be achieved using a shared- 621 unicast RP address ("anycast RP without state sharing") without the 622 complexity of a dynamic mechanism. Further, Anycast RP offers a 623 significantly more extensive failure mitigation strategy, so today 624 there is actually very little need to use stateless failover 625 mechanisms, especially dynamic ones, for redundancy purposes. 627 2.5.3. Bi-directional PIM 629 Because bi-directional PIM (see Section 2.1.3) does not switch to 630 shortest path tree (SPT), the final multicast tree is may be 631 established faster. On the other hand, PIM-SM or SSM may converge 632 more quickly especially in scenarios (e.g., unicast routing change) 633 where bi-directional needs to re-do the Designated Forwarder 634 election. 636 2.5.4. Summary 638 The following table summarizes the techniques for enhanced 639 redundancy. 641 +------+------+-----------------------+ 642 | IPv4 | IPv6 | Deployment | 643 +--------------------+------+------+-----------------------+ 644 | Anycast RP w/ MSDP | Yes | No | De-facto approach | 645 | Anycast RP w/ PIM | Yes | Yes | New, simpler than MSDP| 646 | Stateless RP fail. | Yes | Yes | Causes disturbance | 647 | Bi-dir PIM | Yes | Yes | Deployed at some sites| 648 +-------------+------+------+------------------------------+ 650 2.6. Interactions with Hosts 652 Previous sections have dealt with the components required by routers 653 to be able to do multicast routing. Obviously, the real users of 654 multicast are the hosts: either sending or receiving multicast. This 655 section describes the required interactions with hosts. 657 2.6.1. Hosts Sending Multicast 659 After choosing a multicast group through a variety of means, hosts 660 just send the packets to the link-layer multicast address, and the 661 designated router will receive all the multicast packets and start 662 forwarding them as appropriate. 664 In intra-domain or Embedded-RP scenarios, ASM senders may move to a 665 new IP address without significant impact on the delivery of their 666 transmission. SSM senders cannot change the IP address unless 667 receivers join the new channel or the sender uses an IP mobility 668 technique that is transparent to the receivers. 670 2.6.2. Hosts Receiving Multicast 672 Hosts signal their interest in receiving a multicast group or channel 673 by the use of IGMP [RFC3376] and MLD [RFC3810]. IGMPv2 and MLDv1 are 674 still commonplace, but are also often used in new deployments. Some 675 vendors also support SSM mapping techniques for receivers which use 676 an older IGMP/MLD version where the router maps the join request to 677 an SSM channel based on various, usually complex means of 678 configuration. 680 2.6.3. Summary 682 The following table summarizes the techniques host interaction. 684 +-------+------+----------------------+ 685 | IPv4 | IPv6 | Notes | 686 +--------------------+-------+------+----------------------+ 687 | Host sending | Yes | Yes | No support needed | 688 | Host receiving ASM | IGMP | MLD | Any IGMP/MLD version | 689 | Host receiving SSM | IGMPv3| MLDv2| Also SSM-mapping | 690 +--------------------+-------+------+----------------------+ 692 2.7. Restricting Multicast Flooding in the Link Layer 694 Multicast transmission in the link layer, for example Ethernet, 695 typically includes some form of flooding the packets through a LAN. 696 This causes unnecessary bandwidth usage and discarding unwanted 697 frames on those nodes which did not want to receive the multicast 698 transmission. 700 Therefore a number of techniques have been developed, to be used in 701 Ethernet switches between routers, or between routers and hosts, to 702 limit the flooding. 704 Some mechanisms operate with IP addresses, others with MAC addresses. 705 If filtering is done based on MAC addresses, hosts may receive 706 unnecessary multicast traffic (filtered out in the hosts' IP layer) 707 if more than one IP multicast group addresses maps into the same MAC 708 address, or if IGMPv3/MLDv2 source filters are used. Filtering based 709 on IP destination addresses, or destination and sources addresses, 710 will help avoid these but requires parsing of the Ethernet frame 711 payload. 713 These options are discussed in this section. 715 2.7.1. Router-to-Router Flooding Reduction 717 A proprietary solution, Cisco's RGMP [RFC3488] has been developed to 718 reduce the amount of flooding between routers in a switched networks. 719 This is typically only considered a problem in some Ethernet-based 720 Internet Exchange points or VPNs. 722 There have been proposals to observe and possibly react ("snoop") PIM 723 messages [I-D.ietf-l2vpn-vpls-pim-snooping]. 725 2.7.2. Host/Router Flooding Reduction 727 There are a number of techniques to help reduce flooding both from a 728 router to hosts, and from a host to the routers (and other hosts). 730 Cisco's proprietary CGMP [CGMP] provides a solution where the routers 731 notify the switches, but also allows the switches to snoop IGMP 732 packets to enable faster notification of hosts no longer wishing to 733 receive a group. Fast leave behaviour support for IGMPv3 hasn't been 734 implemented. Due to IGMP report suppression in IGMPv1 and IGMPv2, 735 multicast is still flooded to ports which were once members of a 736 group as long as there is at least one receiver on the link. 737 Flooding restrictions are done based on multicast MAC addresses. 738 IPv6 is not supported. 740 IEEE 802.1D-2004 specification describes Generic Attribute 741 Registration Protocol (GARP), and GARP Multicast Registration 742 Protocol (GMRP) [GMRP] is a link-layer multicast group application of 743 GARP that notifies switches about MAC multicast group memberships. 744 If GMRP is used in conjunction with IP multicast, then the GMRP 745 registration function would become associated with an IGMP "join." 746 However, this GMRP-IGMP association is beyond the scope of GMRP. 747 GMRP requires support at the host stack and it has not been widely 748 implemented. Further, IEEE 802.1 considers GARP and GMRP obsolete 749 being replaced by Multiple Registration Protocol (MRP) and Multicast 750 Multiple Registration Protocol (MMRP) that are being specified in 751 IEEE 802.1ak [802.1ak]. MMRP is expected to be mainly used between 752 bridges. Some further information about GARP/GMRP is also available 753 in Appendix B of [RFC3488]. 755 IGMP snooping [RFC4541] appears to be the most widely implemented 756 technique. IGMP snooping requires that the switches implement a 757 significant amount of IP-level packet inspection; this appears to be 758 something that is difficult to get right, and often the upgrades are 759 also a challenge. 761 Snooping switches also need to identify the ports where routers 762 reside and therefore where to flood the packets. This can be 763 accomplished using Multicast Router Discovery protocol [RFC4286], 764 looking at certain IGMP queries [RFC4541], looking at PIM Hello and 765 possibly other messages, or by manual configuration. An issue with 766 PIM snooping at LANs is that PIM messages can't be turned off or 767 encrypted, leading to security issues [I-D.ietf-pim-lasthop-threats]. 769 IGMP proxying [RFC4605] is sometimes used either as a replacement of 770 a multicast routing protocol on a small router, or to aggregate IGMP/ 771 MLD reports when used with IGMP snooping. 773 2.7.3. Summary 775 The following table summarizes the techniques for multicast flooding 776 reduction inside a single link for router-to-router and last-hop 777 LANs. 779 +--------+-----+---------------------------+ 780 | R-to-R | LAN | Notes | 781 +-----------------------+--------+-----+---------------------------+ 782 | Cisco's RGMP | Yes | No | Replaced by PIM snooping | 783 | PIM snooping | Yes | No | Security issues in LANs | 784 | IGMP/MLD snooping | No | Yes | Common, IGMPv3 or MLD bad | 785 | Multicast Router Disc | No | Yes | Few if any implem. yet | 786 | IEEE GMRP and MMRP | No | No | No host/router deployment | 787 | Cisco's CGMP | No | Yes | Replaced by other snooping| 788 +-----------------------+--------+-----+---------------------------+ 790 3. Acknowledgements 792 Tutoring a couple multicast-related papers, the latest by Kaarle 793 Ritvanen [RITVANEN] convinced the author that up-to-date multicast 794 routing and address assignment/allocation documentation is necessary. 796 Leonard Giuliano, James Lingard, Jean-Jacques Pansiot, Dave Meyer, 797 Stig Venaas, Tom Pusateri, Marshall Eubanks, Dino Farinacci, Bharat 798 Joshi, Albert Manfredi, Jean-Jacques Pansiot, Spencer Dawkins, Sharon 799 Chisholm, John Zwiebel, Dan Romascanu, and Thomas Morin provided good 800 comments, helping in improving this document. 802 4. IANA Considerations 804 This memo includes no request to IANA. 806 5. Security Considerations 808 This memo only describes different approaches to multicast routing, 809 and this has no security considerations; the security analysis of the 810 mentioned protocols is out of scope of this memo. 812 However, there has been analysis of the security of multicast routing 813 infrastructures [RFC4609], IGMP/MLD [I-D.daley-magma-smld-prob], and 814 PIM last-hop issues [I-D.ietf-pim-lasthop-threats]. 816 6. References 818 6.1. Normative References 820 [I-D.ietf-idr-rfc2858bis] 821 Bates, T., "Multiprotocol Extensions for BGP-4", 822 draft-ietf-idr-rfc2858bis-10 (work in progress), 823 March 2006. 825 [I-D.ietf-isis-wg-multi-topology] 826 Przygienda, T., "M-ISIS: Multi Topology (MT) Routing in 827 IS-IS", draft-ietf-isis-wg-multi-topology-11 (work in 828 progress), October 2005. 830 [I-D.ietf-mboned-addrarch] 831 Savola, P., "Overview of the Internet Multicast Addressing 832 Architecture", draft-ietf-mboned-addrarch-05 (work in 833 progress), October 2006. 835 [I-D.ietf-ospf-mt] 836 Psenak, P., "Multi-Topology (MT) Routing in OSPF", 837 draft-ietf-ospf-mt-06 (work in progress), February 2006. 839 [I-D.ietf-pim-bidir] 840 Handley, M., "Bi-directional Protocol Independent 841 Multicast (BIDIR-PIM)", draft-ietf-pim-bidir-08 (work in 842 progress), October 2005. 844 [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 845 3", BCP 9, RFC 2026, October 1996. 847 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 848 Thyagarajan, "Internet Group Management Protocol, Version 849 3", RFC 3376, October 2002. 851 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 852 Protocol (MSDP)", RFC 3618, October 2003. 854 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 855 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 857 [RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous 858 Point (RP) Address in an IPv6 Multicast Address", 859 RFC 3956, November 2004. 861 [RFC3973] Adams, A., Nicholas, J., and W. Siadak, "Protocol 862 Independent Multicast - Dense Mode (PIM-DM): Protocol 863 Specification (Revised)", RFC 3973, January 2005. 865 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 866 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 867 Protocol Specification (Revised)", RFC 4601, August 2006. 869 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 870 IP", RFC 4607, August 2006. 872 6.2. Informative References 874 [802.1ak] "IEEE 802.1ak - Multiple Registration Protocol", 875 . 877 [CGMP] "Cisco Group Management Protocol", 878 . 880 [GMRP] "GARP Multicast Registration Protocol", 881 . 883 [I-D.daley-magma-smld-prob] 884 Daley, G. and G. Kurup, "Trust Models and Security in 885 Multicast Listener Discovery", 886 draft-daley-magma-smld-prob-00 (work in progress), 887 July 2004. 889 [I-D.ietf-idmr-dvmrp-v3] 890 Pusateri, T., "Distance Vector Multicast Routing 891 Protocol", draft-ietf-idmr-dvmrp-v3-11 (work in progress), 892 December 2003. 894 [I-D.ietf-idmr-dvmrp-v3-as] 895 Pusateri, T., "Distance Vector Multicast Routing Protocol 896 Applicability Statement", draft-ietf-idmr-dvmrp-v3-as-01 897 (work in progress), May 2004. 899 [I-D.ietf-l2vpn-vpls-pim-snooping] 900 Hemige, V., "PIM Snooping over VPLS", 901 draft-ietf-l2vpn-vpls-pim-snooping-00 (work in progress), 902 August 2006. 904 [I-D.ietf-mboned-ipv6-multicast-issues] 905 Savola, P., "IPv6 Multicast Deployment Issues", 906 draft-ietf-mboned-ipv6-multicast-issues-02 (work in 907 progress), February 2005. 909 [I-D.ietf-pim-lasthop-threats] 910 Savola, P. and J. Lingard, "Last-hop Threats to Protocol 911 Independent Multicast (PIM)", 912 draft-ietf-pim-lasthop-threats-00 (work in progress), 913 October 2006. 915 [I-D.ietf-pim-sm-bsr] 916 Bhaskar, N., "Bootstrap Router (BSR) Mechanism for PIM", 917 draft-ietf-pim-sm-bsr-09 (work in progress), June 2006. 919 [I-D.lehtonen-mboned-dynssm-req] 920 Lehtonen, R., "Requirements for discovery of dynamic SSM 921 sources", draft-lehtonen-mboned-dynssm-req-00 (work in 922 progress), February 2005. 924 [IM-GAPS] Meyer, D. and B. Nickless, "Internet Multicast Gap 925 Analysis from the MBONED Working Group for the IESG 926 [Expired]", draft-ietf-mboned-iesg-gap-analysis-00 (work 927 in progress), July 2002. 929 [IMRP-ISSUES] 930 Meyer, D., "Some Issues for an Inter-domain Multicast 931 Routing Protocol [Expired]", 932 draft-ietf-mboned-imrp-some-issues-01 (work in progress), 933 September 1997. 935 [RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance 936 Vector Multicast Routing Protocol", RFC 1075, 937 November 1988. 939 [RFC1458] Braudes, B. and S. Zabele, "Requirements for Multicast 940 Protocols", RFC 1458, May 1993. 942 [RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, 943 March 1994. 945 [RFC1585] Moy, J., "MOSPF: Analysis and Experience", RFC 1585, 946 March 1994. 948 [RFC2189] Ballardie, T., "Core Based Trees (CBT version 2) Multicast 949 Routing -- Protocol Specification --", RFC 2189, 950 September 1997. 952 [RFC2201] Ballardie, T., "Core Based Trees (CBT) Multicast Routing 953 Architecture", RFC 2201, September 1997. 955 [RFC2715] Thaler, D., "Interoperability Rules for Multicast Routing 956 Protocols", RFC 2715, October 1999. 958 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 959 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 960 March 2000. 962 [RFC3208] Speakman, T., Crowcroft, J., Gemmell, J., Farinacci, D., 963 Lin, S., Leshchiner, D., Luby, M., Montgomery, T., Rizzo, 964 L., Tweedly, A., Bhaskar, N., Edmonstone, R., 965 Sumanasekera, R., and L. Vicisano, "PGM Reliable Transport 966 Protocol Specification", RFC 3208, December 2001. 968 [RFC3446] Kim, D., Meyer, D., Kilmer, H., and D. Farinacci, "Anycast 969 Rendevous Point (RP) mechanism using Protocol Independent 970 Multicast (PIM) and Multicast Source Discovery Protocol 971 (MSDP)", RFC 3446, January 2003. 973 [RFC3488] Wu, I. and T. Eckert, "Cisco Systems Router-port Group 974 Management Protocol (RGMP)", RFC 3488, February 2003. 976 [RFC3740] Hardjono, T. and B. Weis, "The Multicast Group Security 977 Architecture", RFC 3740, March 2004. 979 [RFC3913] Thaler, D., "Border Gateway Multicast Protocol (BGMP): 980 Protocol Specification", RFC 3913, September 2004. 982 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 983 RFC 4286, December 2005. 985 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 986 "Considerations for Internet Group Management Protocol 987 (IGMP) and Multicast Listener Discovery (MLD) Snooping 988 Switches", RFC 4541, May 2006. 990 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 991 "Internet Group Management Protocol (IGMP) / Multicast 992 Listener Discovery (MLD)-Based Multicast Forwarding 993 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 995 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 996 Independent Multicast - Sparse Mode (PIM-SM) Multicast 997 Routing Security Issues and Enhancements", RFC 4609, 998 October 2006. 1000 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 1001 Independent Multicast (PIM)", RFC 4610, August 2006. 1003 [RITVANEN] 1004 Ritvanen, K., "Multicast Routing and Addressing", HUT 1005 Report, Seminar on Internetworking, May 2004, 1006 . 1008 Appendix A. Multicast Payload Transport Extensions 1010 A couple of mechanisms have been, and are being specified, to improve 1011 the characteristics of the data that can be transported over 1012 multicast. 1014 These go beyond the scope of multicast routing, but as reliable 1015 multicast has some relevance, these are briefly mentioned. 1017 A.1. Reliable Multicast 1019 Reliable Multicast Working Group has been working on experimental 1020 specifications so that applications requiring reliable delivery 1021 characteristics, instead of simple unreliable UDP, could use 1022 multicast as a distribution mechanism. 1024 One such mechanism is Pragmatic Generic Multicast (PGM) [RFC3208]. 1025 This does not require support from the routers, bur PGM-aware routers 1026 may act in router assistance role in the initial delivery and 1027 potential retransmission of missing data. 1029 A.2. Multicast Group Security 1031 Multicast Security Working Group has been working on methods how the 1032 integrity, confidentiality, and authentication of data sent to 1033 multicast groups can be ensured using cryptographic techniques 1034 [RFC3740]. 1036 Author's Address 1038 Pekka Savola 1039 CSC - Scientific Computing Ltd. 1040 Espoo 1041 Finland 1043 Email: psavola@funet.fi 1045 Full Copyright Statement 1047 Copyright (C) The IETF Trust (2006). 1049 This document is subject to the rights, licenses and restrictions 1050 contained in BCP 78, and except as set forth therein, the authors 1051 retain all their rights. 1053 This document and the information contained herein are provided on an 1054 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1055 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1056 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1057 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1058 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1059 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1061 Intellectual Property 1063 The IETF takes no position regarding the validity or scope of any 1064 Intellectual Property Rights or other rights that might be claimed to 1065 pertain to the implementation or use of the technology described in 1066 this document or the extent to which any license under such rights 1067 might or might not be available; nor does it represent that it has 1068 made any independent effort to identify any such rights. Information 1069 on the procedures with respect to rights in RFC documents can be 1070 found in BCP 78 and BCP 79. 1072 Copies of IPR disclosures made to the IETF Secretariat and any 1073 assurances of licenses to be made available, or the result of an 1074 attempt made to obtain a general license or permission for the use of 1075 such proprietary rights by implementers or users of this 1076 specification can be obtained from the IETF on-line IPR repository at 1077 http://www.ietf.org/ipr. 1079 The IETF invites any interested party to bring to its attention any 1080 copyrights, patents or patent applications, or other proprietary 1081 rights that may cover technology that may be required to implement 1082 this standard. Please address the information to the IETF at 1083 ietf-ipr@ietf.org. 1085 Acknowledgment 1087 Funding for the RFC Editor function is provided by the IETF 1088 Administrative Support Activity (IASA).