idnits 2.17.00 (12 Aug 2021) /tmp/idnits7693/draft-ietf-magma-msnip-04.txt: 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 seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 54 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 258: '...Pv6. This option MUST be included in a...' RFC 2119 keyword, line 286: '...MSNIP, the mis-configuration SHOULD be...' RFC 2119 keyword, line 290: '...ers on that link MUST be configured to...' RFC 2119 keyword, line 317: '...system MUST default to flooding and im...' RFC 2119 keyword, line 325: '... IP system MUST use the SSM mult...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Both the Host Interest Solicitation message and the Receiver Membership Report message MUST not be forwarded by routers (see section 12). The Router Alert option [9] [10] MUST be included in the packet by the router or host IP system transmitting the message. Routers receiving Host Interest Solicitation messages and IP systems receiving Receiver Membership Reports MUST not process a received MSNIP message if the Router Alert option is not present. -- 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 (19 June 2003) is 6911 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) == Unused Reference: '7' is defined on line 1019, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 1022, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2463 (ref. '5') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2461 (ref. '6') (Obsoleted by RFC 4861) -- Possible downref: Non-RFC (?) normative reference: ref. '7' ** Obsolete normative reference: RFC 2401 (ref. '8') (Obsoleted by RFC 4301) == Outdated reference: draft-ietf-magma-igmp-proxy has been published as RFC 4605 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force MAGMA WG 2 INTERNET-DRAFT B. Fenner/AT&T 3 draft-ietf-magma-msnip-04.txt B. Haberman/Caspian Networks 4 H. Holbrook/Cisco 5 I. Kouvelas/Cisco 6 19 June 2003 7 Expires: December 2003 9 Multicast Source Notification of Interest Protocol (MSNIP) 11 Status of this Document 13 This document is an Internet-Draft and is in full conformance with all 14 provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering Task 17 Force (IETF), its areas, and its working groups. Note that other groups 18 may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet- Drafts as reference material 23 or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This document is a product of the IETF MAGMA WG. Comments should be 32 addressed to the authors, or the WG's mailing list at magma@ietf.org. 34 Abstract 36 This document discusses the Multicast Source Interest 37 Notification Protocol (MSNIP). MSNIP is an extension to 38 IGMPv3 and MLDv2 that provides membership notification 39 services for sources of multicast traffic operating within the 40 SSM destination address range. 42 Table of Contents 44 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 45 2. Routing Protocol Support. . . . . . . . . . . . . . . . 3 46 3. Service Interface for Requesting Membership Noti- 47 fication . . . . . . . . . . . . . . . . . . . . . . . . . 4 48 3.1. Application Operation. . . . . . . . . . . . . . . . 5 49 4. MSNIP Managed Address Range Negotiation . . . . . . . . 6 50 4.1. Router Coordination. . . . . . . . . . . . . . . . . 6 51 4.1.1. MSNIP Operation Option. . . . . . . . . . . . . . 6 52 4.1.2. SSM Range Option. . . . . . . . . . . . . . . . . 7 53 4.2. Managed Range Discovery by Source Systems. . . . . . 8 54 5. Requesting and Receiving Notifications. . . . . . . . . 8 55 5.1. Host Interest Solicitation . . . . . . . . . . . . . 9 56 5.2. Router Receiver Membership Reports . . . . . . . . . 9 57 6. Application Notification. . . . . . . . . . . . . . . . 11 58 7. Router Processing . . . . . . . . . . . . . . . . . . . 13 59 8. Message Formats . . . . . . . . . . . . . . . . . . . . 14 60 8.1. Host Interest Solicitation Message . . . . . . . . . 15 61 8.2. Receiver Membership Report Packet. . . . . . . . . . 16 62 8.3. IPv4 Header Fields . . . . . . . . . . . . . . . . . 18 63 8.4. IPv6 Header Fields . . . . . . . . . . . . . . . . . 18 64 9. Constants Timers and Default Values . . . . . . . . . . 18 65 10. Possible Optimisations . . . . . . . . . . . . . . . . 19 66 10.1. Suppressing HIS Messages. . . . . . . . . . . . . . 19 67 10.2. Host Stack Filtering. . . . . . . . . . . . . . . . 19 68 10.3. Responding to Unexpected IGMP Queries . . . . . . . 19 69 10.4. Host and Router Startup . . . . . . . . . . . . . . 20 70 11. Inter-operation with IGMP / MLD Proxying . . . . . . . 20 71 12. Security Considerations. . . . . . . . . . . . . . . . 21 72 12.1. Receiver Membership Report attacks. . . . . . . . . 21 73 12.2. Host Interest Solicitation attacks. . . . . . . . . 22 74 12.3. MSNIP Managed Range Discovery . . . . . . . . . . . 22 75 13. IANA Considerations. . . . . . . . . . . . . . . . . . 23 76 14. Acknowledgments. . . . . . . . . . . . . . . . . . . . 23 77 15. Normative References . . . . . . . . . . . . . . . . . 23 78 16. Informative References . . . . . . . . . . . . . . . . 24 80 1. Introduction 82 The Multicast Source Notification of Interest Protocol (MSNIP) is 83 an extension to version 3 of the Internet Group Membership Protocol 84 (IGMPv3 [1]) and version 2 of the Multicast Listener Discovery Protocol 85 (MLDv2 [2]). MSNIP operates between multicast sources and their first- 86 hop routers to provide information on the presence of receivers to the 87 source systems. Using the services offered by MSNIP an application on an 88 IP system wishing to source multicast data can register to be notified 89 when receivers join and leave the session. This enables multicast 90 sources to avoid the work of transmitting packets onto their first-hop 91 link when there are no joined receivers. 93 A common scenario where MSNIP may be useful is one where there is a 94 multicast server offering a large pool of potential flows that map onto 95 separate multicast destination addresses but receivers exist only for a 96 small subset of the flows. If the source were to continuously transmit 97 data for all the flows that could potentially have receivers, 98 significant resources would be wasted in the system itself as well as 99 the first-hop link and first-hop router. Using a higher level control 100 protocol to determine the existence of receivers for particular flows 101 may not be practical as there may be many potential receivers in each 102 active session. 104 Information on which multicast destination addresses have receivers 105 for a particular sender is typically available to the multicast routing 106 protocol on the first hop router for a source. MSNIP uses this 107 information to notify the application in the sending system of when it 108 should start or stop transmitting. This is achieved without any 109 destination address specific state on the first-hop router for potential 110 sources without receivers. 112 2. Routing Protocol Support 114 For reasons described in this section, MSNIP only supports 115 transmission control for applications that use multicast destination 116 addresses that are routed using Source Specific Multicast (SSM). 118 Many currently deployed multicast routing protocols require data 119 from an active source to be propagated past the first-hop router before 120 information on the existence of receivers becomes available on the 121 first-hop. In addition, such protocols require that this activity is 122 repeated periodically to maintain source liveness state on remote 123 routers. All dense-mode protocols fall under this category as well as 124 sparse-mode protocols that use shared trees for source discovery (such 125 as PIM-SM [11]). In order to provide receiver interest notification for 126 such protocols, the default mode of operation would require that the 127 source IP system periodically transmits on all potential destination 128 addresses and the first-hop routers prune the traffic back. Such a 129 flood-and-prune behaviour on the first-hop link significantly diminishes 130 the benefits of managing source transmission. 132 In contrast, with source-specific sparse-mode protocols such as 133 PIM-SSM [11] availability of receiver membership information on the 134 first-hop routers is independent of data transmission. Such protocols 135 use an external mechanism for source discovery (like source-specific 136 IGMPv3 membership reports) to build source-specific multicast trees. 138 Clearly these two classes of routing protocols require different 139 handling for the problem MSNIP is trying to solve. In addition the 140 second type covers the majority of applications that MSNIP is targeted 141 at. MSNIP avoids the extra complication in supporting routing protocols 142 that require a flood and prune behaviour. 144 3. Service Interface for Requesting Membership Notification 146 Applications within an IP system that wish to source multicast 147 packets and are interested in being notified on the existence of 148 receivers must register with the IP layer of the system. MSNIP requires 149 that within the IP system, there is (at least conceptually) a service 150 interface that can be used to register with the IP layer for such 151 notifications. Dual stack systems supporting both IPv4 and IPv6 need to 152 provide separate service interfaces for each protocol. 154 A system's IPv4 or IPv6 service interface must support the 155 following operation or any logical equivalent: 157 IPMulticastSourceRegister (socket, source-address, multicast-address) 158 IPMulticastSourceDeregister (socket, source-address, multicast-address) 160 In addition the application must provide the following interface 161 for receiving notifications from the IP system: 163 IPMulticastSourceStart (socket, source-address, multicast-address) 164 IPMulticastSourceStop (socket, source-address, multicast-address) 166 where: 168 socket 169 is an implementation-specific parameter used to distinguish amongst 170 different requesting entities (e.g., programs or processes) within 171 the system; the socket parameter of BSD UNIX system calls is a 172 specific example. 174 source-address 175 is the IP unicast source address that the application wishes to use 176 in transmitting data to the specified multicast address. The 177 specified address must be one of the IP addresses associated with 178 the network interfaces of the IP system. Note that an interface in 179 an IP system may be associated with more than one IP address. An 180 implementation may allow a special "unspecified" value to be passed 181 as the source-address parameter, in which case the request would 182 apply to the "primary" IP address of the "primary" or "default" 183 interface of the system (perhaps established by system 184 configuration). If transmission to the same multicast address is 185 desired using more than one source IP address, 186 IPMulticastSourceRegister must be invoked separately for each 187 desired source address. 189 multicast-address 190 is the IP multicast destination address to which the request 191 pertains. If the application wishes to transmit data to more than 192 one multicast addresses for a given source address, 193 IPMulticastSourceRegister must be invoked separately for each 194 desired multicast address. 196 3.1. Application Operation 198 Applications wishing to use MSNIP to control their multicast data 199 transmission to destination G from source address S operate as follows. 201 Initially the application contacts the IP system to obtain the 202 socket handle for use on all subsequent interactions. The application 203 invokes IPMulticastSourceRegister for the desired S and G and then waits 204 without transmitting any packets for the IP system to notify that 205 receivers for the session exist. 207 If and when the IP system notifies the application that receivers 208 exist using the IPMulticastSourceStart call, the application may start 209 transmitting data. After the application has been notified to send, if 210 all receivers for the session leave, the IP system will notify the 211 application using the IPMulticastSourceStop call. At this point the 212 application should stop transmitting data until it is notified again 213 that receivers have joined through another IPMulticastSourceStart call. 215 When the application no longer wishes to transmit data it should 216 invoke the IPMulticastSourceDeregister call to let the IP system know 217 that it is no longer interested in notifications for this source and 218 destination. The IPMulticastSourceDeregister call should be implicit in 219 the teardown of the associated socket state. 221 4. MSNIP Managed Address Range Negotiation 223 With current multicast deployment in the Internet, different 224 multicast routing protocols coexist and operate under separate parts of 225 the multicast address space. Multicast routers are consistently 226 configured with information that maps specific multicast address ranges 227 to multicast routing protocols. Part of this configuration describes the 228 subset of the address space that is used by source-specific multicast 229 (SSM) [12]. As described in section 2, MSNIP only tries to control 230 application transmission within the SSM address range. 232 It is desirable for applications within an IP system that supports 233 MSNIP to have a consistent service interface for multicast transmission 234 that does not require the application to be aware of the SSM address 235 range. MSNIP supports this by allowing applications to use the service 236 interface described in section 3 for multicast destination addresses 237 that are outside its operating range. When an application registers for 238 notifications for a destination address that is not managed by MSNIP it 239 is immediately notified to start transmitting. This is equivalent to the 240 default behaviour of IP multicast without MSNIP support which forces 241 multicast applications to assume that there are multicast receivers 242 present in the network. 244 4.1. Router Coordination 246 In order for MSNIP to operate on a shared link where two or more 247 multicast routers may be present, all the multicast routers must be 248 MSNIP-capable and have an identical configuration for the SSM address 249 range. MSNIP enforces these requirements by using two new options for 250 IPv4 in the Multicast Router Discovery protocol [3] and one new option 251 for IPv6 in the Neighbour Discovery / ICMPv6 protocol [6]. 253 4.1.1. MSNIP Operation Option 255 A multicast router advertises that it is participating in MSNIP 256 using the MSNIP Operation option in either the Multicast Router 257 Discovery protocol for IPv4 or the Neighbour Discovery / ICMPv6 protocol 258 for IPv6. This option MUST be included in all router advertisement 259 messages of a router that is configured for MSNIP. The format of the 260 option is as follows: 262 0 1 2 3 263 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type | Length | Padding | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Padding | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Type The type field is set to WW (TBD by IANA) for IPv4 and ZZ (TBD by 271 IANA) for IPv6. 273 Length 274 The length field is set to 0 for IPv4 and 1 for IPv6. 276 Padding 277 The six extra bytes of padding are only present in IPv6 and are 278 required to bring the size of the option up to the eight octet 279 boundary. The value of the padding bytes must be set to zero on 280 transmission and ignored on receipt. 282 A multicast router uses received Multicast Router Advertisement and 283 Neighbour Discovery / ICMPv6 messages to determine if all live neighbour 284 multicast routers on each interface are participating in MSNIP. When a 285 router advertisement message not containing an MSNIP option is received 286 by a router participating in MSNIP, the mis-configuration SHOULD be 287 logged to the operator in a rate-limited manner. 289 If even one multicast router on a link does not have MSNIP 290 capability then ALL routers on that link MUST be configured to not 291 provide MSNIP services and to not advertise the MSNIP Operation option. 293 4.1.2. SSM Range Option 295 The SSM Range Multicast Router Discovery option advertises the IPv4 296 SSM Range with which the router is configured. The option is defined in 297 [4]. This option is only valid in IPv4. 299 The SSM range for IPv6 is well defined for all valid scopes [15] 300 and a mechanism to allow additional ranges to operate in SSM mode on a 301 per-link bases is not required. 303 4.2. Managed Range Discovery by Source Systems 305 When an application in an IP system uses the MSNIP service 306 interface to register for notification, the IP system must behave 307 differently depending on whether or not the destination address for 308 which the application registered is operating under SSM (and is being 309 managed by MSNIP). For SSM channels, the IP system should only instruct 310 the application to transmit when there are receivers for the multicast 311 destination. For non-SSM destination addresses the IP system will not be 312 able to determine if there are receivers and should immediately instruct 313 the application to transmit. In addition, an MSNIP-capable IP system 314 must be able to detect if there are multicast routers on its connected 315 links and if they support MSNIP operation. If no multicast routers are 316 present or if the multicast routers are not MSNIP-capable then the IP 317 system MUST default to flooding and immediately instruct applications to 318 transmit. 320 An IP system controls transmission behaviour under the different 321 possible conditions by adapting its definition of the MSNIP-managed 322 multicast destination address range: 324 o On a link with multicast routers operating the MSNIP protocol the 325 IP system MUST use the SSM multicast destination address range as 326 the MSNIP-managed range. IPv4 systems MUST use the contents of 327 the SSM Range option in received Multicast Router Advertisement 328 messages [4] to discover the configured SSM range. SSM range 329 discovery is not needed in IPv6 where the SSM destination address 330 range is fixed. 332 o On a link not connected to a multicast routed infrastructure or 333 on a link with multicast routers that do not support MSNIP 334 operation, the IP system MUST use an empty range as its MSNIP- 335 managed range. This forces applications transmitting to any 336 multicast destination address to default to flooding thus 337 providing backward compatibility. 339 As described in 4.1.1, an IP system can determine the status of a 340 link and distinguish between the above two cases through the reception 341 of IPv4 Multicast Router Advertisement and Neighbour Discovery / ICMPv6 342 messages. 344 5. Requesting and Receiving Notifications 346 Like IGMP, MSNIP is an asymmetric protocol specifying different 347 behaviour for systems wishing to source traffic and for multicast 348 routers. Host IP systems multicast Host Interest Solicitation messages 349 to register for notification with their first-hop routers. Routers 350 unicast Router Receiver Membership Reports to IP systems to notify them 351 of the arrival of the first or departure of the last receiver for a 352 session. Note that a system may perform at the same time both of the 353 above functions. An example is a router that wishes to source traffic. 355 5.1. Host Interest Solicitation 357 Source systems that wish to be managed by MSNIP periodically 358 transmit a Host Interest Solicitation message. This message is multicast 359 with a multicast destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) 360 or ALL_MLDv2_ROUTERS (TBA) and is transmitted every [Interest 361 Solicitation Interval] seconds. The Host Interest Solicitation message 362 contains a holdtime which is set to [Interest Solicitation Holdtime] and 363 instructs the multicast first-hop routers to maintain MSNIP state for 364 this IP system for the specified period. Systems with multiple 365 interfaces or multiple IP addresses per interface must originate 366 separate Host Interest Solicitation messages from each of their IP 367 addresses that they wish to have managed by MSNIP. In practice a system 368 with more than one IP address is treated by MSNIP as multiple IP 369 systems. 371 When an IP system first comes up it transmits [Robustness Variable] 372 Host Interest Solicitation messages spaced by [Initial Interest 373 Solicitation Interval] seconds. 375 All MSNIP capable routers that receive a Host Interest Solicitation 376 message from an IP system, maintain a system interest record of the 377 form: 379 (IP system address, holdtime timer) 381 Each time a Host Interest Solicitation message is received from the IP 382 system, the holdtime timer is reset to the holdtime in the received 383 message. In addition the router may respond to the solicitation message 384 with a Receiver Membership Report message described in section 5.2. The 385 message contains a TRANSMIT record for each of the multicast destination 386 addresses within the MSNIP-managed range for which the routing protocol 387 indicates there are receivers for this source system. 389 The holdtime timer of a record counts down to zero. When the 390 holdtime timer of a specific system interest record expires, the record 391 is deleted. 393 5.2. Router Receiver Membership Reports 395 Receiver Membership Report messages are used by routers to 396 communicate the receiver membership status of particular multicast 397 destination addresses to a specific IP system. Each message contains a 398 list of transmission control records of either TRANSMIT or HOLD type 399 that instruct a system to respectively start or stop sending traffic on 400 this link to the specified multicast destination address. Receiver 401 Membership Report messages are unicast to the target system. 403 In addition to reports sent in response to Host Interest 404 Solicitation messages, routers send unsolicited Receiver Membership 405 Reports to IP systems when the receiver membership status reported by 406 the multicast routing protocol changes for a specific source and 407 multicast destination. Such reports are only sent if the multicast 408 destination address is managed by MSNIP and the router has a system 409 interest record created by a previously received Host Interest 410 Solicitation message with an IP system address equal to the source 411 address. If the source / destination pair satisfy these conditions then 412 [Robustness Variable] Receiver Membership Reports are sent out spaced by 413 [Unsolicited Membership Report Interval] seconds. If the membership 414 status changes again for the same destination address and source system 415 while transmission of Receiver Membership Reports is still pending then 416 the pending report messages are canceled and a new set of [Robustness 417 Variable] messages indicating the new state are scheduled. 419 When an IP system receives a Receiver Membership Report message, 420 for each of the TRANSMIT records listed in the message, it creates or 421 updates a transmission record of the form: 423 (router address, source address, multicast address, holdtime timer) 425 The router address is obtained from the source address on the IP header 426 of the received message. The source address is obtained from the 427 destination address of the IP header of the received message. The 428 multicast address is obtained from the information in the TRANSMIT 429 record. The holdtime timer is set to the value of the holdtime field in 430 the received Receiver Membership Report message. 432 For each HOLD record present in the message, the system deletes the 433 matching previously created transmission record from its state. 435 The holdtime timer of a record counts down to zero. When the 436 holdtime timer of a specific transmission record expires, the record is 437 deleted. 439 Note that creation and deletion of transmission records in an IP 440 system's state may cause local applications to be notified to start and 441 stop transmitting data (see section 6). 443 6. Application Notification 445 This section describes the relation between protocol events and 446 notifications to source applications within an IP system. The state 447 machine below is specific to each source address of the IP system and 448 each multicast destination address. The initial state is the No Info 449 state. 451 +-----------------------------------+ 452 | Figures omitted from text version | 453 +-----------------------------------+ 455 Figure 1: Per source-address (S) and multicast destination address (G) 456 state machine at an IP system 458 In tabular form, the state-machine is: 460 +-------------------+---------------------------------------------------+ 461 | | Prev State | 462 | Event +----------------+------------------+---------------+ 463 | | No Info | Hold | Transmit | 464 +-------------------+----------------+------------------+---------------+ 465 | New Register | - | - | - | 466 | | Start new | | Start new | 467 +-------------------+----------------+------------------+---------------+ 468 | | -> Hold | - | - | 469 | Start Manage | Stop ALL | | | 470 | | registered | | | 471 +-------------------+----------------+------------------+---------------+ 472 | | - | -> No Info | -> No Info | 473 | Stop Manage | | Stop ALL | | 474 | | | registered | | 475 +-------------------+----------------+------------------+---------------+ 476 | | - | -> Transmit | - | 477 | Recv TRANSMIT | | Start ALL | | 478 | | | registered | | 479 +-------------------+----------------+------------------+---------------+ 480 | Recv last HOLD | - | - | -> Hold | 481 | or timeout | | | Stop ALL | 482 | | | | registered | 483 +-------------------+----------------+------------------+---------------+ 485 The events in the state machine above have the following meaning: 487 New register 488 A new application has registered through a call to 489 IPMulticastSourceRegister for this S and G. 491 Start manage 492 We received a SSM Range option in an MRD packet on the interface 493 that S belongs to that changed the status of G from a non-managed 494 to a MSNIP-managed destination address. The SSM Range option is 495 only valid in IPv4. 497 Stop manage 498 We received a SSM Range option in an MRD packet on the interface 499 that S belongs to that changed the status of G from a MSNIP-managed 500 to a non-managed destination address or the mapping state that 501 caused this destination address to be managed expired. The SSM 502 Range option is only valid in IPv4. 504 Receive TRANSMIT 505 We received a Receiver Membership Report with S as the IP 506 destination address that contains a TRANSMIT record for G. 508 Receive last HOLD or timeout 509 We either received a Receiver Membership Report with S as the IP 510 destination address that contains a HOLD record for G or the 511 holdtime timer in a transmission record for S and G expired and 512 there are no other transmission records for S and G. This means 513 that the last router that was reporting receivers no longer does so 514 and there are no routers left wishing to receive traffic from this 515 S to destination address G. 517 The state machine actions have the following meaning: 519 Start new 520 Send an IPMulticastSourceStart notification to the application that 521 just registered for this S and G. 523 Start ALL registered 524 Send an IPMulticastSourceStart notification to all applications 525 that are registered for this S and G. 527 Stop ALL registered 528 Send an IPMulticastSourceStop notification to all applications that 529 are registered for this S and G. 531 7. Router Processing 533 This section describes the per-source system tracking state machine 534 operated by each first-hop router. The initial state is No Info. 536 +-----------------------------------+ 537 | Figures omitted from text version | 538 +-----------------------------------+ 540 Figure 2: Per IP source system (S) state machine at a router 542 In tabular form, the state-machine is: 544 +----------------------+------------------------------------------------+ 545 | | Prev State | 546 | Event +------------------------+-----------------------+ 547 | | Not tracking | Tracking | 548 +----------------------+------------------------+-----------------------+ 549 | | -> Tracking | - | 550 | Receive HIS | Set HT to message | Set HT to message | 551 | | holdtime; Send ALL | holdtime; Send ALL | 552 | | existing TRANSMITs | existing TRANSMITs | 553 +----------------------+------------------------+-----------------------+ 554 | HIS timeout | - | -> Not tracking | 555 | | | | 556 +----------------------+------------------------+-----------------------+ 557 | Receivers for new | - | - | 558 | destination G | | Send TRANSMIT for | 559 | | | G | 560 +----------------------+------------------------+-----------------------+ 561 | Receivers of G | - | - | 562 | leave | | Send HOLD for G | 563 +----------------------+------------------------+-----------------------+ 565 The events in state machine above have the following meaning: 567 Receive HIS 568 The router has received a Host Interest Solicitation from S. 570 HIS timeout 571 The holdtime timer (HT) in the host interest record associated with 572 S has expired. 574 Receivers for new destination G 575 The routing protocol has informed MSNIP that it now has receivers 576 for the MSNIP-managed destination address G and source IP system S. 578 Receivers of G leave 579 The routing protocol has informed MSNIP that all receivers for the 580 MSNIP-managed destination address G and source IP system S have 581 left the channel. 583 The state machine actions have the following meaning: 585 Set HT to message holdtime 586 The holdtime timer in the host interest record associated with S is 587 restarted to the value of the holdtime field in the received Host 588 Interest Solicitation message. 590 Send ALL existing TRANSMITs 591 The router builds and transmits Receiver Membership Reports to S 592 that contain a TRANSMIT record for each of the MSNIP-managed 593 destination addresses that have receivers for S. 595 Send TRANSMIT for G 596 The router builds and transmits a Receiver Membership Report to S 597 that contains a TRANSMIT record for the destination address G. 599 Send HOLD for G 600 The router builds and transmits a Receiver Membership Report to S 601 that contains a HOLD record for the destination address G. 603 8. Message Formats 605 The following packet formats are valid for both IPv4 and IPv6. IP 606 version-specific values will be explicitly defined. 608 There are two message types of concern to the MSNIP protocol 609 described in this document: 611 +-------------------+----------------------------+ 612 | Type Number (hex) | Message Name | 613 +-------------------+----------------------------+ 614 | | | 615 | 0xXX | Host Interest Solicitation | 616 +-------------------+----------------------------+ 617 | 0xYY | Receiver Membership Report | 618 +-------------------+----------------------------+ 620 Both the Host Interest Solicitation message and the Receiver 621 Membership Report message MUST not be forwarded by routers (see section 622 12). The Router Alert option [9] [10] MUST be included in the packet by 623 the router or host IP system transmitting the message. Routers receiving 624 Host Interest Solicitation messages and IP systems receiving Receiver 625 Membership Reports MUST not process a received MSNIP message if the 626 Router Alert option is not present. 628 8.1. Host Interest Solicitation Message 630 A Host Interest Solicitation message is periodically multicast by MSNIP 631 capable systems to declare interest in Receiver Membership Reports from 632 multicast routers on the link. The Host Interest Solicitation message is 633 multicast with a destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) 634 or ALL_MLDv2_ROUTERS (TBA). 636 0 1 2 3 637 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | Type | Reserved | Checksum | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Holdtime | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Type The type field is set to XX (to be assigned by IANA as an IGMP type 645 for IPv4 and an ICMPv6 type for IPv6). 647 Reserved 648 Transmitted as zero. Ignored upon receipt. 650 Checksum 651 In IPv4, the Checksum is the 16-bit one's complement of the one's 652 complement sum of the whole IGMP message (the entire IP payload). 653 In IPv6, the Checksum is the standard ICMPv6 checksum, covering the 654 entire MLDv2 message plus a "pseudo-header" of IPv6 header fields 655 [5]. For computing the checksum, the Checksum field is set to zero. 657 When receiving packets, the checksum MUST be verified before 658 processing a packet. 660 Holdtime 661 The amount of time a receiving router must keep the system interest 662 state alive, in seconds. The default value for this field is 663 [Interest Solicitation Holdtime]. 665 8.2. Receiver Membership Report Packet 667 A Receiver Membership Report packet is unicast by first-hop multicast 668 routers and targeted at potential sources to inform them of the 669 existence or not of receivers for the listed multicast destination 670 addresses. 672 0 1 2 3 673 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Type | Dest Count | Checksum | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Holdtime | Reserved | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Record-Type-1 | Record-Reserved-1 | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Destination-Address-1 | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | . | 684 | . | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 Type The type field is set to YY (to be assigned by IANA as an IGMP type 688 for IPv4 and an ICMPv6 type for IPv6). 690 Dest Count 691 The number of multicast destination address records present in this 692 message. 694 Checksum 695 In IPv4, the Checksum is the 16-bit one's complement of the one's 696 complement sum of the whole IGMP message (the entire IP payload). 697 In IPv6, the Checksum is the standard ICMPv6 checksum, covering the 698 entire MLDv2 message plus a "pseudo-header" of IPv6 header fields 700 [5]. For computing the checksum, the Checksum field is set to zero. 701 When receiving packets, the checksum MUST be verified before 702 processing a packet. 704 Holdtime 705 The amount of time in seconds that the target host must keep alive 706 the transmission record state created or updated by the TRANSMIT 707 records in this report. The router originating the Receiver 708 Membership Report sets this field to the current value of the 709 holdtime timer in the system interest record corresponding to the 710 target host. As a result Receiver Membership Reports sent in 711 response to the reception of a Host Interest Solicitation message 712 have their holdtime set to the value of the holdtime field in the 713 received HIS message. 715 Reserved 716 Transmitted as zero. Ignored upon receipt. 718 Record-Type-1 719 The type of the first transmission control record in this message. 720 Valid values are: 722 +-------------+----------------------------------------------+-------+ 723 | Record Type | Description | Value | 724 +-------------+----------------------------------------------+-------+ 725 | TRANSMIT | Request to start transmitting to destination | 1 | 726 +-------------+----------------------------------------------+-------+ 727 | HOLD | Request to stop transmitting to destination | 2 | 728 +-------------+----------------------------------------------+-------+ 730 Reserved 731 Transmitted as zero. Ignored upon receipt. 733 Destination-Address-1 734 The multicast destination address of the first record in the 735 message. 737 8.3. IPv4 Header Fields 739 Like all IGMP messages, MSNIP messages are encapsulated in IPv4 740 datagrams, with an IP protocol number of 2. MSNIP messages can be 741 identified from other IGMP messages by the message types listed in 742 section 8. Every MSNIP message described in this document is sent with 743 an IP Time-to-Live of 1, and carries an IP Router Alert option [9] in 744 its IP header. 746 8.4. IPv6 Header Fields 748 MLD messages are a sub-protocol of the Internet Control Message 749 Protocol (ICMPv6 [5]). MSNIP messages are identified in IPv6 packets by 750 the combination of a preceding Next Header value of 58 and by the MLD 751 message types listed in section 8. All MSNIP messages described in this 752 document are sent with a link-local IPv6 Source Address (or the 753 unspecified address, if a valid link-local address is not available), an 754 IPv6 Hop Limit of 1, and an IPv6 Router Alert option [10] in a Hop-by- 755 hop Options header. 757 9. Constants Timers and Default Values 759 Robustness Variable 760 The Robustness Variable allows tuning for the expected packet loss 761 on a network. If a network is expected to be lossy, the Robustness 762 Variable may be increased. MSNIP is robust to (Robustness Variable 763 - 1) packet losses. The Robustness Variable MUST NOT be zero, and 764 SHOULD NOT be one. Default: 2 766 Interest Solicitation Interval 767 The interval used by MSNIP capable systems between transmissions of 768 Host Interest Solicitation messages. Default: 60 secs 770 Interest Solicitation Holdtime 771 The interval inserted in Host Interest Solicitation messages by 772 systems to instruct routers how long they should maintain system 773 interest state for. This MUST be ((the Robustness Variable) times 774 (the Interest Solicitation Interval) plus (one second)). 776 Initial Interest Solicitation Interval 777 The interval used by systems to send out the initial Host Interest 778 Solicitation messages when they first come up. Default: 1 second. 780 Unsolicited Membership Report Interval 781 The interval used by routers to send out a set of Membership Report 782 messages when the receiver membership changes for a specific 783 system. Default: 1 second. 785 10. Possible Optimisations 787 10.1. Suppressing HIS Messages 789 A possible optimisation for MSNIP is to suppress the transmission 790 of Host Interest Solicitation messages from the source address of an IP 791 system for which no local application has registered interest. In 792 addition to conserving bandwidth, not transmitting HIS messages prevents 793 remote receivers for groups with no matching source application from 794 creating transmission record state in the host system. 796 10.2. Host Stack Filtering 798 Legacy applications that have not been coded with MSNIP support can 799 still be prevented from wasting first-hop link bandwidth by filtering 800 transmitted packets at the operating system level. Even though such 801 applications will not register for MSNIP notifications with the host 802 operating system, if the OS is MSNIP-capable and the application is 803 transmitting data to an MSNIP-managed group for which there are no 804 transmit records, the OS can safely filter the packets and not transmit 805 them on the wire. 807 A problem with the filtering approach is that it cannot be combined 808 with the HIS message suppression optimisation (see section 10.1). If 809 there are no registered applications in the system and HIS messages are 810 being suppressed then the first-hop routers will not send any Receiver 811 Membership Reports to the system. As a result, knowledge of receiver 812 membership from the presence of transmit records for groups operated by 813 legacy applications will not exist. It therefore becomes unsafe to 814 filter packets from legacy applications. 816 10.3. Responding to Unexpected IGMP Queries 818 Under steady state the router side of the IGMP protocol elects a 819 single router on each link that is responsible for issuing IGMP Queries. 820 Routers other than the acting IGMP querier will send an IGMP Query only 821 if they restart and have no IGMP querier election state or if the active 822 Querier crashes and a new election takes place. 824 MSNIP can take advantage of this mechanism to quickly populate the 825 host interest records of a new router starting up. When the router comes 826 up it will issue an IGMP Query in an attempt to be elected as a Querier. 827 MSNIP-capable hosts will notice that the sender of the Query is not the 828 acting Querier. They can use this trigger to respond with Host Interest 829 Solicitation Messages (with transmission randomised over a small 830 interval) to quickly bring the new router up-to-date. 832 10.4. Host and Router Startup 834 When a host operating system is restarted there may be applications 835 that are started as part of the initialisation process and want to 836 source IPv4 multicast traffic. It is possible for the applications to 837 register through MSNIP with the IP subsystem and to start transmitting 838 multicast data before the host receives the MSNIP-managed range 839 definition through the SSM Range option of the Multicast Router 840 Discovery protocol. 842 This temporary flooding can be avoided if the host OS holds off 843 notifying MSNIP-capable applications that they can transmit until it 844 receives an MRD advertisement and learns the SSM configuration for the 845 network. This behaviour has the drawback that it is not compatible with 846 legacy networks with no MRD deployment. In such a network the host OS 847 has to be able to determine after a configurable period that MRD is not 848 enabled and hence all multicast applications wishing to source traffic 849 should be notified to transmit. A good default value for this period is 850 the MAX_RESPONSE_DELAY of the Multicast Router Discovery protocol [4]. 852 Late router startup is harder to deal with. Hosts that start up 853 before the multicast router may time out waiting for an MRD 854 advertisement and instruct all MSNIP-capable multicast source 855 applications to transmit data. One way to work around this problem is to 856 configure the host OS to wait forever for an MRD advertisement before 857 instructing MSNIP applications to transmit. 859 11. Inter-operation with IGMP / MLD Proxying 861 MSNIP is intended for use on networks with multicast servers 862 offering a large number of potential sessions. Although unlikely, it is 863 possible to deploy such a server behind an IGMP / MLD Proxy [14]. If the 864 proxy is not MSNIP-aware and does not implement the extensions described 865 below then sources behind the proxy will default to flooding. 867 If a device performing IGMP / MLD Proxying wishes to proxy MSNIP, 868 it MUST forward MSNIP Host Interest Solicitation messages that are 869 received on downstream interfaces to its upstream interface. No special 870 treatment is required for MSNIP Receiver Membership Reports as they are 871 unicast to the target host. 873 In addition to the forwarding of MSNIP messages, an IGMP proxy MUST 874 operate the Multicast Router Discovery protocol [3] on all its 875 downstream interfaces and advertise the MSNIP capability option (section 876 4.1.1) and SSM address range option (section 4.1.2). The MSNIP 877 capability option should be advertised on downstream interfaces only if 878 it is included in MRD messages received on the upstream interface. The 879 address range to be included in the SSM Range option MUST be determined 880 by MRD and IGMP messages received on the upstream interface of the proxy 881 according to the rules in section 4.2. 883 In addition to the forwarding of MSNIP messages, an MLD proxy MUST 884 operate the IPv6 Neighbour Discovery protocol. The MSNIP capability 885 option should be advertised on downstream interfaces when it is included 886 in IPv6 Neighbour Discovery messages received on the upstream interface. 888 12. Security Considerations 890 We consider the ramifications of a forged message of each type. As 891 described in [1] and [2], IPSEC AH can be used to authenticate IGMP and 892 MLD messages if desired. 894 12.1. Receiver Membership Report attacks 896 A DoS attack on a host could be staged through forged Receiver 897 Membership Report messages. The attacker can send a large number of 898 reports, each with a large number of TRANSMIT records and a holdtime 899 field set to a large value. The host will have to store and maintain the 900 transmission records specified in all of those reports for the duration 901 of the holdtime. This would consume both memory and CPU cycles in the 902 host. 904 Forged Receiver Membership Report messages from the local network 905 can be easily traced. There are three measures necessary to defend 906 against externally forged reports: 908 o Routers SHOULD NOT forward Receiver Membership Reports. This is 909 easier for a router to accomplish if the report carries the 910 Router-Alert option. 912 o Hosts SHOULD ignore Receiver Membership Reports without the 913 Router-Alert option. 915 Note that a remote attack through the multicast routing protocol is 916 possible. A remote site can originate join state for a large number of 917 groups that will propagate through MSNIP to the target source host. 918 Such attacks are considered a more significant problem for the routers 919 involved and are left up to the routing protocol security. 921 HOLD records in forged Receiver Membership Report messages are not 922 a significant threat as hosts track the individual interests of each 923 first-hop router separately. Only by forging the source address of the 924 report message so that is appears to have originated from a real first- 925 hop router can the attacker cause the source to stop transmitting to a 926 group that has valid receivers. Such forged messages can be detected by 927 the router itself. 929 12.2. Host Interest Solicitation attacks 931 Forged Host Interest Solicitation messages can have two effects: 933 o When non-existent source addresses are used the solicitation 934 messages can create unwanted host record state on attached 935 routers for the duration of the holdtime specified in the 936 message. 938 o When a source address corresponding to an existing host is used 939 in the forged HIS message, receipt of the message by attached 940 routers will cause them to transmit Receiver Membership Reports 941 messages for all MSNIP-managed multicast destination addresses 942 with receivers for the target host. Although no additional state 943 will be created in routers or hosts from this attack, bandwidth 944 and CPU is wasted in both the first-hop routers and the target 945 host. 947 Just like for the Receiver Membership Report message, attacks using 948 the Host Interest Solicitation message can be reduced by requiring the 949 use of the Router-Alert option on the message. 951 12.3. MSNIP Managed Range Discovery 953 As discussed in [4] it is possible for directly connected systems 954 to send forged Multicast Router Advertisement messages containing the 955 SSM Range Discovery option. As the SSM Range Discovery option determines 956 the MSNIP-managed range under IPv4, such forged messages can temporarily 957 replace the managed range map with incorrect information in receiving 958 hosts. An incorrect mapping can have two effects: 960 o Applications using a multicast destination address within the 961 real SSM range that have no valid receivers can be tricked into 962 thinking that their chosen destination address is no longer an 963 SSM address and will therefore start transmitting data. 965 o Applications using group addresses outside the valid SSM range 966 can be tricked into thinking that they are using an SSM 967 destination address and therefore prevented from transmitting 968 data. 970 The Multicast Router Discovery SSM Range Option specification 971 suggests that a router receiving a Multicast Router Advertisement with 972 an inconsistent SSM Range Option log the event to the operator. Such 973 logging will enable tracking of this type of attack. 975 13. IANA Considerations 977 This document introduces the following new types and options that 978 require allocation by IANA: 980 o Two new IGMP messages for Host Interest Solicitation and Receiver 981 Membership Report. Each of these messages requires a new IGMP 982 type value to be assigned by IANA [13]. 984 o The new MSNIP Operation option for the Multicast Router Discovery 985 protocol. This option requires a new MRD type value to be 986 assigned by IANA. 988 o The new MSNIP Operation option for the Neighbour Discovery / 989 ICMPv6 protocol. This option requires a new NDP / ICMPv6 type 990 value to be assigned by IANA. 992 14. Acknowledgments 994 The authors would like to thank Dave Thaler, Jon Crowcroft, Toerless 995 Eckert, Haixiang He, Pekka Savola and Karen Kimball for their 996 contribution to this specification. 998 15. Normative References 1000 [1] Cain B., Deering S., Fenner W., Kouvelas I. and A. Thyagarajan, 1001 "Internet Group Management Protocol, Version 3", RFC 3376. 1003 [2] Vida R. and Costa L., "Multicast Listener Discovery Version 2 1004 (MLDv2) for IPv6", work in progress, , 1005 June 2003. 1007 [3] Biswas S. and Haberman B., "IGMP Multicast Router Discovery", Work 1008 In Progress, , January 2003. 1010 [4] Kouvelas I., "Multicast Router Discovery SSM Range Option", work in 1011 progress, , June 2003. 1013 [5] Conta A. and Deering S., "Internet Control Message Protocol (ICMPv6) 1014 for the Internet Protocol Version 6 (IPv6)", RFC 2463. 1016 [6] Narten T., Nordmark E. and Simpson W., "Neighbour Discovery for IP 1017 Version 6 (IPv6)", RFC 2461. 1019 [7] Holbrook H. and Cain B., "Source-Specific Multicast for IP", work in 1020 progress, , March 2003. 1022 [8] Kent S. and Atkinson R., "Security Architecture for the Internet 1023 Protocol.", RFC 2401. 1025 [9] Katz D., "IP Router Alert Option", RFC 2113. 1027 [10] Partridge C. and Jackson A., "IPv6 Router Alert Option", RFC 2711. 1029 16. Informative References 1031 [11] Fenner W., Handley M., Holbrook H. and Kouvelas I., "Protocol 1032 Independent Multicast - Sparse Mode (PIM-SM): Protocol 1033 Specification (Revised)", Work In Progress, , March 2003. 1036 [12] Albanna Z., Almeroth K. and Meyer D., "IANA Guidelines for IPv4 1037 Multicast Address Allocation", Best Current Practices, , 2001. 1040 [13] Fenner W., "IANA Considerations for IGMP", 1041 http://www.iana.org/assignments/igmp-type-numbers, RFC 3228 (BCP 1042 57), February 2002. 1044 [14] Fenner W., He H., Haberman B. and Sandick H., "IGMP / MLD-based 1045 Multicast Forwarding (IGMP / MLD Proxying)" draft-ietf-magma-igmp- 1046 proxy-02.txt, March 2003. 1048 [15] B. Haberman, D. Thaler, "Unicast-Prefix-based IPv6 Multicast 1049 Addresses", RFC 3306, August 2002. 1051 Authors' Addresses 1053 Bill Fenner 1054 AT&T Labs - Research 1055 75 Willow Road 1056 Menlo Park, CA 94025 1057 fenner@research.att.com 1059 Brian Haberman 1060 Caspian Networks 1061 1 Park Drive, Suite 300 1062 Research Triangle Park, NC 27709 1063 brian@innovationslab.net 1065 Hugh Holbrook 1066 Cisco Systems 1067 170 W. Tasman Drive 1068 San Jose, CA 95134 1069 holbrook@cisco.com 1071 Isidor Kouvelas 1072 Cisco Systems 1073 170 W. Tasman Drive 1074 San Jose, CA 95134 1075 kouvelas@cisco.com 1077 Full Copyright Statement 1079 Copyright (C) The Internet Society (Apr 1 2003). All Rights Reserved. 1081 This document and translations of it may be copied and furnished to 1082 others, and derivative works that comment on or otherwise explain it or 1083 assist in its implementation may be prepared, copied, published and 1084 distributed, in whole or in part, without restriction of any kind, 1085 provided that the above copyright notice and this paragraph are included 1086 on all such copies and derivative works. However, this document itself 1087 may not be modified in any way, such as by removing the copyright notice 1088 or references to the Internet Society or other Internet organisations, 1089 except as needed for the purpose of developing Internet standards in 1090 which case the procedures for copyrights defined in the Internet 1091 Standards process must be followed, or as required to translate it into 1092 languages other than English. 1094 The limited permissions granted above are perpetual and will not be 1095 revoked by the Internet Society or its successors or assigns. 1097 This document and the information contained herein is provided on 1098 an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1099 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1100 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1101 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1102 FITNESS FOR A PARTICULAR PURPOSE.