idnits 2.17.1 draft-ietf-magma-mrdisc-01.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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 619. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 625. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (January 2005) is 7041 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MLDV2' is mentioned on line 228, but not defined == Unused Reference: 'RFC3810' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'BCP78' is defined on line 583, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 585, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2463 (Obsoleted by RFC 4443) -- Obsolete informational reference (is this intentional?): RFC 3668 (ref. 'BCP79') (Obsoleted by RFC 3979) Summary: 7 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MAGMA Working Group B. Haberman 3 Internet Draft Caspian Networks 4 draft-ietf-magma-mrdisc-01.txt J. Martin 5 July 2004 Netzwert AG 6 Expires January 2005 8 Multicast Router Discovery 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been disclosed, 14 and any of which I become aware will be disclosed, in accordance 15 with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 2005. 36 Abstract 38 The concept of Internet Group Membership Protocol (IGMP) and 39 Multicast Listener Discovery (MLD) snooping requires the ability to 40 identify the location of multicast routers. Since snooping is not 41 standardized, there are many mechanisms in use to identify the 42 multicast routers. However, this can lead to interoperability 43 issues between multicast routers and snooping switches from 44 different vendors. 46 This document introduces a general mechanism that allows for the 47 discovery of multicast routers. This new mechanism, Multicast 48 Router Discovery (MRD), introduces a standardized means of 49 identifying multicast routers without a dependency on particular 50 multicast routing protocols. 52 Haberman, Martin 1 53 1. Introduction 55 Multicast Router Discovery messages are useful for determining which 56 nodes attached to a switch have multicast routing enabled. This 57 capability is useful in a layer-2 bridging domain with snooping 58 switches. By listening to MRD messages, layer-2 switches can 59 determine where to send multicast source data and group membership 60 messages [RFC1112][RFC2236]. Multicast source data and group 61 membership Reports must be received by all multicast routers on a 62 segment. Using the group membership protocol Query messages to 63 discover multicast routers is insufficient due to query suppression. 65 Although MRD messages could be sent as ICMP messages, the group 66 management protocols were chosen since this functionality is 67 multicast specific. The addition of this functionality to the group 68 membership protocol also allows operators to have congruency between 69 multicast router discovery problems and data forwarding issues. 71 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 72 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 73 "OPTIONAL" in this document are to be interpreted as described in 74 [RFC2119]. Due to the lack of italics, emphasis is indicated herein 75 by bracketing a word or phrase in "*" characters. Furthermore, 76 square brackets are used to denote the value of the enclosed 77 variable, as opposed to the variable itself, written without 78 brackets. 80 2. Protocol Overview 82 Multicast Router Discovery consists of three messages for 83 discovering multicast routers. The Multicast Router Advertisement 84 is sent by routers to advertise that IP multicast forwarding is 85 enabled. Devices may send Multicast Router Solicitation messages in 86 order to solicit Advertisement messages from multicast routers. The 87 Multicast Router Termination messages are sent when a router stops 88 IP multicast routing functions on an interface. 90 Multicast routers send Advertisements periodically on all interfaces 91 on which multicast forwarding is enabled. Advertisement messages 92 are also sent in response to Solicitations. In addition to 93 advertising the location of multicast routers, Advertisements also 94 convey useful information concerning group management protocol 95 variables. This information can be used for consistency checking on 96 the subnet. 98 A device sends Solicitation messages whenever it wishes to discover 99 multicast routers on a directly attached link. 101 A router sends Termination messages when it terminates multicast 102 routing functionality on an interface. 104 Haberman, Martin 2 105 All MRD messages are sent with an IPv4 TTL or IPv6 Hop Limit of 1 106 and contain the Router Alert Option [RFC2113][RFC2711]. 108 Advertisement and Termination messages are sent to the All-Snoopers 109 multicast address. 111 Solicitation messages are sent to the All-Routers multicast address. 113 Any data beyond the fixed message format MUST be ignored. 115 3. Multicast Router Advertisement 117 Multicast Router Advertisements are sent periodically on all router 118 interfaces on which multicast forwarding is enabled. They are also 119 sent in response to Multicast Router Solicitation messages. 121 Advertisements are sent 123 1. Upon the expiration of a periodic (modulo randomization) timer 124 2. As a part of a router's start up procedure 125 3. During the restart of a multicast forwarding interface 126 4. On receipt of a Solicitation message 128 All Advertisements are sent as IGMP (for IPv4) or MLD (for IPv6) 129 messages to the All-Snoopers multicast address. These messages 130 SHOULD be rate-limited. 132 3.1 Advertisement Configuration Variables 134 An MRD implementation MUST support the following variables being 135 configured by system management. Default values are specified to 136 make it unnecessary to configure any of these variables in many 137 cases. 139 3.1.1 MaxAdvertisementInterval 141 This variable is the maximum time (in seconds) allowed between the 142 transmissions of Advertisements on an interface. This value MUST be 143 no less than 4 seconds and no greater than 180 seconds. 145 Default: 20 seconds 147 3.1.2 MinAdvertisementInterval 149 This is the minimum time (in seconds) allowed between the 150 transmissions of Advertisements on an interface. This value MUST be 151 no less than 3 seconds and no greater than MaxAdvertisementInterval. 153 Default: 0.75 * MaxAdvertisementInterval 155 Haberman, Martin 3 156 3.1.3 MaxInitialAdvertisementInterval 158 The first Advertisement transmitted on an interface is sent after 159 waiting a random interval (in seconds) less than this variable. 160 This prevents a flood of Advertisements when multiple routers start 161 up at the same time. 163 Default: 2 seconds 165 3.1.4 MaxInitialAdvertisements 167 This variable is the maximum number of Advertisements that will be 168 transmitted by the advertising interface when MRD starts up. 170 Default: 3 172 3.1.5 NeighborDeadInterval 174 This variable is the maximum time (in seconds) allowed to elapse 175 before a neighbor can be declared unreachable. In order for all 176 devices to have a consistent state, it is necessary for the 177 MaxAdvertisementInterval to be configured consistently in all 178 devices on the subnet. 180 Default: 3 * MaxAdvertisementInterval 182 3.2 Advertisement Packet Format 184 The Advertisement message has the following format: 186 0 1 2 3 187 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 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Type | Ad. Interval | Checksum | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Query Interval | Robustness Variable | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 3.2.1 Type Field 196 The Type field identifies the message as an Advertisement. It is 197 set to X1 (to be assigned by IANA) for IPv4 and X2 (to be assigned 198 by IANA) for IPv6. 200 3.2.2 Advertisement Interval Field 202 This field specifies the periodic time interval at which 203 Advertisement messages are transmitted in units of seconds. This 204 value is set to the configured MaxAdvertisementInterval variable. 206 3.2.3 Checksum Field 208 Haberman, Martin 4 209 The checksum field is set as follows: 211 1. For IPv4 it is the 16-bit one's complement of the one's 212 complement sum of the IGMP message, starting with the Type 213 field. For computing the checksum, the checksum field is set 214 to 0. 215 2. For IPv6 it is ICMPv6 checksum as specified in [RFC2463]. 217 3.2.4 Query Interval Field 219 The Query Interval field is set to the Query Interval value in use 220 by IGMP or MLD on the interface. If IGMP or MLD is not enabled on 221 the advertising interface, this field MUST be set to 0. Note that 222 this is the Querier's Query Interval (QQI), not the Querier's Query 223 Interval Code (QQIC) as specified in the IGMP/MLD specifications. 225 3.2.5 Robustness Variable Field 227 This field is set to the Robustness Variable in use by IGMPv2 228 [RFC2236], IGMPv3 [RFC3376], or MLD [RFC2710][MLDV2] on the 229 advertising interface. If IGMPv1 is in use or no group management 230 protocol is enabled on the interface, this field MUST be set to 0. 232 3.3 IP Header Fields 234 3.3.1 Source Address 236 The IP source address is set to an IP address configured on the 237 advertising interface. For IPv6, a link-local address MUST be used. 239 3.3.2 Destination Address 241 The IP destination address is set to the All-Snoopers multicast 242 address. 244 3.3.3 Time-to-Live / Hop Limit 246 The IPv4 TTL and IPv6 Hop Limit are set to 1. 248 3.3.4 IPv4 Protocol 250 The IPv4 Protocol field is set to IGMP (2). 252 3.4 Sending Multicast Router Advertisements 254 Advertisement messages are sent when the following events occur: 256 1. The expiration of the periodic advertisement interval timer. 257 Note that it this timer is not strictly periodic since it is 258 a random number between MaxAdvertisementInterval and 259 MinAdvertisementInterval. 261 Haberman, Martin 5 262 2. After a random delay less than 263 MaxInitialAdvertisementInterval when an interface is first 264 enabled, is (re-)initialized, or MRD is enabled. A router 265 may send up to a maximum of MaxInitialAdvertisements 266 Advertisements, waiting for a random delay less than 267 MaxInitialAdvertisementInterval between each successive 268 message. Multiple Advertisements are sent for robustness in 269 the face of packet loss on the network. 271 This is to prevent an implosion of Advertisements. An example of 272 this occurring would be when many routers are powered on at the same 273 time. When a Solicitation is received, an Advertisement is sent in 274 response with a random delay less than MAX_RESPONSE_DELAY. If a 275 Solicitation is received while an Advertisement is pending, that 276 Solicitation MUST be ignored. 278 Changes in the Query Interval or Robustness Variable MUST NOT 279 trigger a new advertisement, however the new values MUST be used all 280 future Advertisement messages. 282 When an Advertisement is sent, the periodic advertisement interval 283 timer MUST be reset. 285 3.5 Receiving Multicast Router Advertisements 287 Upon receiving an Advertisement message, devices validate the 288 message with the following criteria: 290 1. The checksum is correct 291 2. The IP destination address is equal to the All-Snoopers 292 multicast address 293 3. For IPv6, the IP source address is a link-local address 295 An Advertisement not meeting the validity requirements MUST be 296 silently discarded and may be logged in a rate-limited manner. 298 If an Advertisement is not received for a particular neighbor within 299 a NeighborDeadInterval time interval, then the neighbor is 300 considered unreachable. 302 4. Multicast Router Solicitation 304 Multicast Router Solicitation messages are used to solicit 305 Advertisements from multicast routers on a segment. These messages 306 are used when a device wishes to discover multicast routers. Upon 307 receiving a solicitation on an interface with IP multicast 308 forwarding and MRD enabled, a router will respond with an 309 Advertisement. 311 Solicitations may be sent when: 313 1. An interface is (re-)initialized 315 Haberman, Martin 6 316 2. MRD is enabled 318 Solicitations are sent to the All-Routers multicast address and 319 SHOULD be rate-limited. 321 4.1 Solicitation Packet Format 323 The Solicitation message has the following format: 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type | Reserved | Checksum | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 4.1.1 Type Field 333 The Type field identifies the message as a Solicitation. It is set 334 to Y1 (to be assigned by IANA) for IPv4 and Y2 (to be assigned by 335 IANA) for IPv6. 337 4.1.2 Reserved Field 339 The Reserved field is set to 0 on transmission and ignored on 340 reception. 342 4.1.3 Checksum Field 344 The checksum field is set as follows: 346 . For IPv4 it is the 16-bit one's complement of the one's 347 complement sum of the IGMP message, starting with the Type 348 field. For computing the checksum, the checksum field is set 349 to 0. 350 . For IPv6 it is ICMPv6 checksum as specified in [RFC2463]. 352 4.2 IP Header Fields 354 4.2.1 Source Address 356 The IP source address is set to an IP address configured on the 357 soliciting interface. For IPv6, a link-local address MUST be used. 359 4.2.2 Destination Address 361 The IP destination address is set to the All-Routers multicast 362 address. 364 4.2.3 Time-to-Live / Hop Limit 366 The IPv4 TTL and IPv6 Hop Limit are set to 1. 368 Haberman, Martin 7 369 4.2.4 IPv4 Protocol 371 The IPv4 Protocol field is set to IGMP (2). 373 4.3 Sending Multicast Router Solicitations 375 Solicitation messages are sent when the following events occur: 377 . After waiting for a random delay less than MAX 378 SOLICITATION_DELAY when an interface first becomes 379 operational, is (re-)initialized, or MRD is enabled. A 380 device may send up to a maximum of MAX_SOLICITATIONS, 381 waiting for a random delay less than MAX SOLICITATION_DELAY 382 between each solicitation. 383 . Optionally, for an implementation specific event. 385 Solicitations MUST be rate-limited; the implementation MUST send no 386 more than MAX_SOLICITATIONS in MAX SOLICITATION_DELAY seconds. 388 4.4 Receiving Multicast Router Solicitations 390 A Solicitation message MUST be validated before a response is sent. 391 A router MUST verify that: 393 . The checksum is correct 394 . The IP destination address is the All-Routers multicast 395 address 396 . For IPv6, the IP source address MUST be a link-local address 398 Solicitations not meeting the validity requirements SHOULD be 399 silently discarded and may be logged in a rate-limited manner. 401 5. Multicast Router Termination 403 The Multicast Router Termination message is used to expedite the 404 notification of a change in the status of a router's multicast 405 forwarding functions. Multicast routers send Terminations when 406 multicast forwarding is disabled on the advertising interface. 408 5.1 Termination Packet Format 410 The Termination message has the following format: 412 0 1 2 3 413 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 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Type | Reserved | Checksum | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 5.1.1 Type Field 420 Haberman, Martin 8 421 The Type field identifies the message as a Termination. It is set 422 to Z1 (to be assigned by IANA) for IPv4 and Z2 (to be assigned by 423 IANA) for IPv6. 425 5.1.2 Reserved Field 427 The Reserved field is set to 0 on transmission and ignored on 428 reception. 430 5.1.3 Checksum Field 432 The checksum field is set as follows: 434 . For IPv4 it is the 16-bit one's complement of the one's 435 complement sum of the IGMP message, starting with the Type 436 field. For computing the checksum, the checksum field is 437 set to 0. 438 . For IPv6 it is ICMPv6 checksum as specified in [RFC2463]. 440 5.2 IP Header Fields 442 5.2.1 Source Address 444 The IP source address is set to an IP address configured on the 445 advertising interface. For IPv6, a link-local address MUST be used. 447 5.2.2 Destination Address 449 The IP destination address is set to the All-Snoopers multicast 450 address. 452 5.2.3 Time-to-Live / Hop Limit 454 The IPv4 TTL and IPv6 Hop Limit are set to 1. 456 5.2.4 IPv4 Protocol 458 The IPv4 Protocol field is set to IGMP (2). 460 5.3 Sending Multicast Router Terminations 462 Termination messages are sent by multicast routers when: 464 . Multicast forwarding is disabled on an interface 465 . An interface is administratively disabled 466 . The router is gracefully shutdown 467 . MRD is disabled 469 5.4 Receiving Multicast Router Terminations 471 Upon receiving a Termination message, devices validate the message. 472 The validation criteria is: 474 Haberman, Martin 9 475 . Checksum MUST be correct 476 . IP destination address MUST equal the All-Snoopers multicast 477 address 478 . For IPv6, the IP source address MUST be a link-local address 480 Termination messages not meeting the validity requirements MUST be 481 silently discarded and may be logged in a rate-limited manner. 483 If the message passes these validation steps, a Solicitation is 484 sent. If an Advertisement is not received within 485 NeighborDeadInterval, the sending router is removed from the list of 486 active multicast routers. 488 6. Protocol Constants 490 The following list identifies constants used in the MRD protocol. 491 These constants are used in the calculation of parameters. 493 . MAX_RESPONSE_DELAY 2 seconds 494 . MAX_SOLICITATION_DELAY 1 second 495 . MAX_SOLICITATIONS 3 transmissions 497 7. Security Considerations 499 The Multicast Router Advertisement message may allow rogue machines 500 to masquerade as multicast routers. This could allow those machines 501 to eavesdrop on multicast data transmissions. Additionally, it could 502 constitute a denial of service attack to other hosts in the same 503 snooping domain or sharing the same device port in the presence of 504 high rate multicast flows. 506 This issue stems from the fact that there is currently no mechanism 507 for hosts to authenticate and authorize messages being sent from 508 local routers. This problem is shared by all IGMP and ICMPv6 509 messages, as well as other protocols such as IPv6 Neighbor 510 Discovery. 512 While solving this problem is beyond the scope of this document, it 513 is worth noting that work in the Secure Neighbor Discovery Working 514 Group may be applicable to Multicast Router Discovery. Should this 515 work prove successful, appropriate mechanisms will be incorporated 516 into a later extension to MRD. 518 8. IANA Considerations 520 This document introduces three new IGMP messages. Each of these 521 messages requires a new IGMP Type value. This document requests 522 IANA to assign three new IGMP Type values to the Multicast Router 523 Discovery Protocol (for IPv4 Advertisements, Solicitations, and 524 Terminations). 526 Haberman, Martin 10 527 This document also introduces three new MLD messages. Each of these 528 messages requires a new ICMPv6 Type value. This document requests 529 IANA to assign three new ICMPv6 Type values from the Informational 530 range to the Multicast Router Discovery Protocol (for IPv6 531 Advertisements, Solicitations, and Terminations). 533 This document also requires the assignment of an All-Snoopers 534 multicast address for IPv4. This multicast address should be in the 535 224.0.0/24 range since it is used for link-local, control message. 536 A corresponding IPv6 multicast address is also requested. Following 537 the guidelines in [RFC3307], the IPv6 multicast address should be 538 link-local in scope and have a group-ID value equal to the lowest- 539 order 8 bits of the requested IPv4 multicast address. 541 9. Acknowledgements 543 ICMP Router Discovery [RFC1256] was used as a general model for 544 Multicast Router Discovery. 546 Morten Christensen, Pekka Savola, Hugh Holbrook, and Isidor Kouvelas 547 provided helpful feedback on various versions of this document. 549 10. References 551 10.1 Normative References 553 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 554 Requirement Levels", BCP 14, RFC 2119, March 1997. 555 [RFC1112] Deering, S., "Host Extensions for IP Multicasting", 556 RFC1112, August 1989. 557 [RFC2236] Fenner, W., "Internet Group Management Protocol, 558 Version 2", RFC2236, November 1997. 559 [RFC2113] Katz, D., "IP Router Alert Option", RFC2113, 560 February 1997. 561 [RFC2711] Partridge, C. and Jackson, A., "IPv6 Router Alert 562 Option", RFC2711, October 1999. 563 [RFC3376] Cain, B., Deering, S., Kouvelas, I., et al., "Internet 564 Group Management Protocol, Version 3", RFC3376, October 565 2002. 566 [RFC2710] Deering, S., Fenner, W., and Haberman, B., "Multicast 567 Listener Discovery (MLD) for IPv6", RFC2710, October 568 1999. 569 [RFC3810] Vida, R. and Costa, L., "Multicast Listener Discovery 570 Version 2 (MLDv2) for IPv6", RFC3810, December 2003. 571 [RFC2463] Conta, A. and Deering, S., "Internet Control Message 572 Protocol (ICMPv6) for the Internet Protocol Version 6 573 (IPv6) Specification", RFC2463, December 1998. 574 [RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast 575 Addresses", RFC3307, August 2002. 577 10.2 Informative References 579 Haberman, Martin 11 581 [RFC1256] Deering, S., "ICMP Router Discovery Messages", September 582 1991. 583 [BCP78] Bradner, S., "IETF Rights in Contributions" 584 RFC3677, BCP78, February 2004. 585 [BCP79] Bradner, S., "Intellectual Property Rights in IETF 586 Technology", RFC3668, BCP79, February 2004. 588 11. Authors 590 Brad Cain and Shantam Biswas were initial authors on this document. 592 12. Editors' Addresses 594 Brian Haberman Jim Martin 595 Caspian Networks Netzwert AG 596 753 Bridgewater Drive An den Treptowers 1 597 Sykesville, MD 21784 D-12435 Berlin 598 USA Germany 600 brian@innovationslab.net jim@netzwert.ag 601 +1-443-280-0932 +49.30/5 900 800-180 603 13. Intellectual Property Statement 605 The IETF takes no position regarding the validity or scope of any 606 Intellectual Property Rights or other rights that might be claimed 607 to pertain to the implementation or use of the technology described 608 in this document or the extent to which any license under such 609 rights might or might not be available; nor does it represent that 610 it has made any independent effort to identify any such rights. 611 Information on the procedures with respect to rights in RFC 612 documents can be found in BCP 78 and BCP 79. 614 Copies of IPR disclosures made to the IETF Secretariat and any 615 assurances of licenses to be made available, or the result of an 616 attempt made to obtain a general license or permission for the use 617 of such proprietary rights by implementers or users of this 618 specification can be obtained from the IETF on-line IPR repository 619 at http://www.ietf.org/ipr. 621 The IETF invites any interested party to bring to its attention any 622 copyrights, patents or patent applications, or other proprietary 623 rights that may cover technology that may be required to implement 624 this standard. Please address the information to the IETF at ietf- 625 ipr@ietf.org. 627 14. Disclaimer of Validity 629 Haberman, Martin 12 630 This document and the information contained herein are provided on 631 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 632 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 633 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 634 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 635 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 636 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 638 15. Copyright Statement 640 Copyright (C) The Internet Society (2004). This document is subject 641 to the rights, licenses and restrictions contained in BCP 78, and 642 except as set forth therein, the authors retain all their rights. 644 16. Acknowledgment 646 Funding for the RFC Editor function is currently provided by the 647 Internet Society. 649 Haberman, Martin 13