idnits 2.17.1 draft-holbrook-idmr-igmpv3-ssm-08.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 451. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 475. ** 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: ---------------------------------------------------------------------------- ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Oct 1, 2004) is 7141 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: 'RFC 2119' is mentioned on line 85, but not defined == Unused Reference: 'RFC2119' is defined on line 399, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3678 (ref. 'MSFAPI') == Outdated reference: A later version (-07) exists of draft-ietf-ssm-arch-04 Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT IGMPv3/MLDv2 for SSM H. Holbrook 3 Expires Apr 1, 2005 Cisco Systems 4 B. Cain 5 Storigen Systems 6 B. Haberman 7 JHU APL 8 Oct 1, 2004 10 Using IGMPv3 and MLDv2 for Source-Specific Multicast 11 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable patent 16 or other IPR claims of which I am aware have been disclosed, and any of 17 which I become aware will be disclosed, in accordance with RFC 3668. 19 Internet-Drafts are working documents of the Internet Engineering Task 20 Force (IETF), its areas, and its working groups. Note that other groups 21 may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference material 26 or to cite them other than as "work in 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 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC 2119]. 38 Abstract 40 The Internet Group Management Protocol Version 3 (IGMPv3) and the 41 Multicast Listener Discovery Protocol Version 2 (MLDv2) are protocols 42 that allow a host to inform its neighboring routers of its desire to 43 receive IPv4 and IPv6 multicast transmissions, respectively. Source- 44 Specific Multicast (SSM) is a form of multicast in which a receiver is 45 required to specify both the network-layer address of the source and the 46 multicast destination address in order to receive the multicast 47 transmission. This document defines the notion of an "SSM-aware" router 48 and host, and clarifies and, in some cases, modifies the behavior of 49 IGMPv3 and MLDv2 on SSM-aware routers and hosts to accomodate source- 50 specific multicast. This document updates the IGMPv3 and MLDv2 51 specifications. 53 1. Introduction 55 The Internet Group Management Protocol (IGMP) [RFC1112,IGMPv2,IGMPv3], 56 allows an IPv4 host to communicate IP multicast group membership 57 information to its neighboring routers. IGMP version 3 (IGMPv3) 58 [IGMPv3] provides the ability for a host to selectively request or 59 filter traffic from individual sources within a multicast group. 61 The Multicast Listener Discovery Protocol (MLD) [RFC2710, MLDv2] offers 62 similar functionality for IPv6 hosts. MLD version 2 (MLDv2) provides 63 the analagous "source filtering" functionality of IGMPv3 for IPv6. 65 Due to the commonality of function, the term "Group Management Protocol" 66 or "GMP" will be used to refer to both IGMP and MLD. The term "Source 67 Filtering GMP", or "SFGMP" will be used to refer jointly to the IGMPv3 68 and MLDv2 group management protocols. 70 The use of source-specific multicast is facilitated by small changes to 71 the SFGMP protocols on both hosts and routers. [SSM] defines general 72 requirements that must be followed by systems that implement the SSM 73 service model; this document defines the concrete application of those 74 requirements to systems that implement IGMPv3 and MLDv2. In doing so, 75 this document defines modifications to the host and router portions of 76 IGMPv3 and MLDv2 for use with SSM, and presents a number of 77 clarifications to their behavior when used with SSM addresses. This 78 document updates the IGMPv3 and MLDv2 specifications. 80 1.1. Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in RFC 2119 [RFC 2119]. 86 In order to emphasize the parts of this document that modify the 87 existing protocol specifications ([RFC2710,MLDv2,IGMPv3]), as opposed to 88 merely clarifying them, any protocol modifications are marked with the 89 tag "MODIFICATION". 91 2. Host Requirements for Source-Specific Multicast 93 This section defines the notion of an "SSM-aware" host and then goes on 94 to describe the API requirements and the SFGMP protocol requirements of 95 an SSM-aware host. It is important to note that SSM can be used by any 96 host that supports source filtering APIs and whose operating system 97 supports the appropriate SFGMP. The SFGMP modifications described in 98 this section make SSM work better on an SSM-aware host, but they are not 99 strict prerequisites for the use of SSM. 101 The 232/8 IPv4 address range is currently allocated for SSM by IANA 102 [IANA-ALLOCATION]. In IPv6, the FF3x::/32 range (where 'x' is a valid 103 IPv6 multicast scope value) is reserved for SSM semantics [RFC3306], 104 although today SSM allocations are restricted to FF3x::/96. ([SSM] has 105 a more thorough discussion of this topic.) A host that knows the SSM 106 address range and is capable of applying SSM semantics to it is 107 described as an "SSM-aware" host. 109 A host or router may be configured to apply SSM semantics to addresses 110 other than those in the IANA-allocated range. The GMP module on a host 111 or router SHOULD have a configuration option to set the SSM address 112 range(s). If this configuration option exists, it MUST default to the 113 IANA-allocated SSM range. The mechanism for setting this configuration 114 option MUST at least allow for manual configuration. Protocol 115 mechanisms to set this option may be defined in the future. 117 2.1. API requirements 119 If the host IP module of an SSM-aware host receives a non source- 120 specific request to receive multicast traffic sent to an SSM destination 121 address, it SHOULD return an error to the application, as specified in 122 [MSFAPI] (MODIFICATION). On a non-SSM-aware host, an application that 123 uses the wrong API (e.g., "join(G)", "IPMulticastListen(G,EXCLUDE(S1))" 124 for IGMPv3, or "IPv6MulticastListen(G,EXCLUDE(S2))" for MLDv2) to 125 request delivery of packets sent to an SSM address will not receive the 126 requested service, because an SSM-aware router (following the rules of 127 this document) will refuse to process the request, and the application 128 will receive no indication other than a failure to receive the requested 129 traffic. 131 2.2. GMP requirements 133 This section defines the behavior of the SFGMP protocol module on an 134 SSM-aware host, including two modifications to the protocols as 135 described in [IGMPv3,MLDv2]. It also includes a number of 136 clarifications of protocol operations. In doing so, it documents the 137 behavior of an SSM-aware host with respect to sending and receiving the 138 following GMP message types: 140 - IGMPv1/v2 and MLDv1 Reports (2.2.1) 141 - IGMPv3 and MLDv2 Reports (2.2.2) 142 - IGMPv1/v2 and MLDv1 Queries (2.2.3) 143 - IGMPv2 Leave and MLDv1 Done (2.2.4) 144 - IGMPv2 and MLDv1 Group Specific Query (2.2.5) 145 - IGMPv3 and MLDv2 Group Specific Query (2.2.6) 146 - IGMPv3 and MLDv2 Group-and-Source Specific Query (2.2.7) 148 2.2.1. IGMPv1/v2 and MLDv1 Reports 150 An SSM-aware host operating according to [IGMPv3,MLDv2] could send an 151 IGMPv1, IGMPv2, or MLDv1 report for an SSM address when it is operating 152 in "older-version compatibility mode." This is an exceptional (error) 153 condition, indicating that the router(s) can not provide the SFGMP 154 support needed for SSM, and an error is logged when the host enters 155 compatibility mode for an SSM address, as described below. In this 156 situation, it is likely that traffic sent to a channel (S,G) will not be 157 delivered to a receiving host that has requested to receive channel 158 (S,G). 160 [IGMPv3] and [MLDv2] specify that a host MAY allow an older-version 161 report to suppress its own IGMPv3 or MLDv2 Membership Record. An SSM- 162 aware host, however, MUST NOT allow its report to be suppressed in this 163 situation (MODIFICATION). Suppressing reports in this scenario would 164 provide an avenue for an attacker to deny SSM service to other hosts on 165 the link. 167 2.2.2. IGMPv3 and MLDv2 Reports 169 A host implementation may report more than one SSM channel in a single 170 report, by including either multiple sources within a group record or by 171 including multiple group records. 173 A Group Record for a source-specific destination address may (under 174 normal operation) be any of the following types: 176 - MODE_IS_INCLUDE as part of a Current-State Record 178 - ALLOW_NEW_SOURCES as part of a State-Change Record 180 - BLOCK_OLD_SOURCES as part of a State-Change Record 182 A report may include both SSM destination addresses and non-source- 183 specific, i.e., Any-Source Multicast (ASM) destination addresses, in the 184 same message. 186 Additionally, a CHANGE_TO_INCLUDE_MODE record may be sent by a host in 187 some cases, for instance, when the SSM address range is changed through 188 configuration. A router should process such a record according to the 189 normal SFGMP rules. 191 An SSM-aware host SHOULD NOT send any of the following record types for 192 an SSM address. 194 - MODE_IS_EXCLUDE as part of a Current-State Record 196 - CHANGE_TO_EXCLUDE_MODE as part of a Filter-Mode-Change Record 198 This is a MODIFICATION to [IGMPv3,MLDv2], imposing a restriction on its 199 use for SSM destination addresses. The rationale is that EXCLUDE mode 200 does not apply to SSM addresses, and an SSM-aware router will ignore 201 MODE_IS_EXCLUDE and CHANGE_TO_EXCLUDE_MODE requests in the SSM range, as 202 described below. 204 2.2.3. IGMPv1/IGMPv2 and MLDv1 Queries 206 If an IGMPv1, IGMPv2, or MLDv1 query is received, the SFGMP protocol 207 specifications require the host to revert to the older (IGMPv1, IGMPv2, 208 or MLDv1) mode of operation for that destination address. If this 209 occurs, the host will stop reporting source-specific subscriptions for 210 that destination address and will start using IGMPv1, IGMPv2, or MLDv1 211 to report interest in the SSM destination address, unqualified by a 212 source address. As a result, SSM semantics will no longer be applied to 213 the multicast group address by the router. 215 A router compliant with this document would never generate an IGMPv1, 216 IGMPv2, or MLDv1 query for an address in the SSM range, thus this 217 situation only occurs if either the router is not SSM-aware, or if the 218 host and the router disagree about the SSM address range. For instance, 219 if they have inconsistent manual configurations. 221 A host SHOULD log an error if it receives an IGMPv1, IGMPv2, or MLDv1 222 query for an SSM address (MODIFICATION). 224 In order to mitigate this problem, it must be administratively assured 225 that all routers on a given shared-medium network are compliant with 226 this document and are in agreement about the SSM address range. 228 2.2.4. IGMPv2 Leave and MLDv1 Done 230 IGMP Leave and MLD Done messages are not processed by hosts. IGMPv2 231 Leave and MLDv1 Done messages should not be sent for an SSM address, 232 unless the sending host has reverted to older-version compatibility 233 mode, with all the caveats described above. 235 2.2.5. IGMPv2 and MLDv1 Group Specific Query 237 If a host receives an IGMPv2 or MLDv1 Group Specific Query for an 238 address in any configured source-specific range, it should process the 239 query normally, as per [IGMPv3,MLDv2], even if the group queried is a 240 source-specific destination address. The transmission of such a query 241 likely indicates that the sending router is either not compliant with 242 this document or that it is not configured with the same SSM address 243 range(s) as the receiving host. A host SHOULD log an error in this case 244 (MODIFICATION). 246 2.2.6. IGMPv3 and MLDv2 Group Specific Query 248 If an SSM-aware host receives an SFGMP Group-Specific Query for an SSM 249 address, it must respond with a report if the group matches the source- 250 specific destination address of any of its subscribed source-specific 251 channels, as specified in [IGMPv3,MLDv2]. 253 The rationale for this is that, although in the current SFGMP protocol 254 specifications, a router would have no reason to send one, the semantics 255 of such a query are well-defined in this range and future 256 implementations may have reason to send such a query. Be liberal in 257 what you accept. 259 2.2.7. IGMPv3 and MLDv2 Group-and-Source Specific Query 261 An SFGMP router typically uses a group-and-source specific query to 262 query an SSM channel that a host has requested to leave via a 263 BLOCK_OLD_SOURCES record. A host must respond to a group-and-source 264 specific query for which the group and source in the query match match 265 any channel for which the host has a subscription, as required by 266 [IGMPv3,MLDv2]. The use of an SSM address does not change this 267 behavior. 269 A host must be able to process a query with multiple sources listed per 270 group, again as required by [IGMPv3,MLDv2]. The use of an SSM address 271 does not modify the behavior of the SFGMPs in this regard. 273 3. Router Requirements for Source-Specific Multicast 275 Routers must be aware of the SSM address range in order to provide the 276 SSM service model. A router that knows the SSM address range and is 277 capable of applying SSM semantics to it as described in this section is 278 described as an "SSM-aware" router. An SSM-aware router MAY have a 279 configuration option to apply SSM semantics to addresses other than the 280 IANA-allocated range, but if such an option exists, it MUST default to 281 the IANA-allocated range. 283 This section documents the behavior of routers with respect to the 284 following types of SFGMP messages for source-specific destination 285 addresses: 287 - IGMPv3 and MLDv2 Reports (3.1) 288 - IGMPv3 and MLDv2 General Query (3.2) 289 - IGMPv3 and MLDv2 Group-Specific Query (3.3) 290 - IGMPv3 and MLDv2 Group-and-Source Specific Query (3.4) 291 - IGMPv1/v2 and MLDv1 Reports (3.5) 292 - IGMPv1/v2 and MLDv1 Queries (3.6) 293 - IGMPv2 Leave and MLDv1 Done (3.7) 295 3.1. IGMPv3 and MLDv2 Reports 297 SFGMP Reports are used to report source-specific subscriptions in the 298 SSM address range. A router SHOULD ignore a group record of either of 299 the following types if it refers to an SSM destination address: 301 - MODE_IS_EXCLUDE Current-State Record 303 - CHANGE_TO_EXCLUDE_MODE Filter-Mode-Change Record 305 and a router MAY choose to log an error in this case. It MUST process 306 any other group records within the same report. These behaviors are 307 MODIFICATIONS to [IGMPv3,MLDv2] to prevent non-source-specific semantics 308 from being applied to SSM addresses, and to avoid reverting to older- 309 version compatibility mode. 311 A CHANGE_TO_INCLUDE_MODE Filter-Mode-Change Record is processed per the 312 normal SFGMP rules; Section 2.2.2 describes a legitimate scenario when 313 this could occur. 315 3.2. IGMPv3 and MLDv2 General Queries 317 An SSM router sends periodic SFGMP General Queries as per the IGMPv3 and 318 MLDv2 specifications. No change in behavior is required for SSM. 320 3.3. IGMPv3 and MLDv2 Group Specific Queries 322 SFGMP routers that support source-specific multicast may send group- 323 specific queries for addresses in the source-specific range. This 324 specification does not explicitly prohibit such a message, although, at 325 the time of this writing, a router conformant to [IGMPv3,MLDv2] would 326 not send one. 328 3.4. IGMPv3 and MLDv2 Group-and-Source Specific Queries 330 SFGMP Group-and-Source Specific Queries are used when a receiver has 331 indicated that it is no longer interested in receiving traffic from a 332 particular (S,G) pair to determine if there are any remaining directly- 333 attached hosts with interest in that (S,G) pair. Group-and-Source 334 Specific Queries are used within the source-specific address range when 335 a router receives a BLOCK_OLD_SOURCES Record for one or more source- 336 specific groups. These queries are sent normally, as per 337 [IGMPv3,MLDv2]. 339 3.5. IGMPv1/v2 and MLDv1 Reports 341 An IGMPv1/v2 or MLDv1 report for an address in the source-specific range 342 could be sent by a non-SSM-aware host. A router SHOULD ignore all such 343 reports and specifically SHOULD NOT use them to establish IP forwarding 344 state. This is a MODIFICATION to [IGMPv3,MLDv2]. A router MAY log an 345 error if it receives such a report (also a MODIFICATION). 347 3.6. IGMPv1/v2 and MLDv1 Queries 349 An SFGMP router that loses the querier election to a lower version 350 router must log an error, as specified by [IGMPv3,MLDv2]. 352 3.7. IGMPv2 Leave and MLDv1 Done 354 An IGMPv2 Leave or MLDv1 Done message may be sent by a non-SSM-aware 355 host. A router SHOULD ignore all such messages in the source-specific 356 address range and MAY log an error (MODIFICATION). 358 4. Security Considerations 360 The specific protocol modifications described in this document are not 361 known to create any security concerns that are not already present when 362 IGMPv3 or MLDv2 is used with ASM-style multicast. The reader is 363 referred to [SSM] for an analysis of SSM-specific security issues. 365 It is important that a router not accept non-source-specific reception 366 requests for an SSM destination address. The rules of [IGMPv3] and 367 [MLDv2] require a router, upon receiving such a membership report, to 368 revert to earlier version compatibility mode for the group in question. 369 If the router were to revert in this situation, it would prevent an 370 IGMPv3-capable host from receiving SSM service for that destination 371 address, thus creating a potential for an attacker to deny SSM service 372 to other hosts on the same link. 374 5. IANA Considerations 376 This document has no actions for IANA. 378 6. Acknowledgments 380 The authors would like to thank Vince Laviano, Nidhi Bhaskar, Steve 381 Deering, Toerless Eckert, and Pekka Savola for their input and careful 382 review. 384 7. Normative References 386 [IGMPv2] Fenner, W., "Internet Group Management Protocol, Version 2," 387 RFC 2236, November 1997. 389 [IGMPv3] Cain, B., Deering, S., Fenner, B., Kouvelas, I., and 390 Thyagarajan, A., "Internet Group Management Protocol, Version 3," RFC 391 3376, October 2002. 393 [MSFAPI] Thaler, D., Fenner, B., and Quinn, B. "Socket Interface 394 Extensions for Multicast Source Filters," RFC3678, January 2004. 396 [RFC1112] Deering, S., "Host Extensions for IP Multicasting," RFC 1112, 397 August 1989. 399 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 400 Requirement Levels," RFC 2119, March 1997. 402 [SSM] Holbrook, H., and Cain, B., "Source-Specific Multicast for IP", 403 draft-ietf-ssm-arch-04.txt. Work in Progress. 405 [MLDv2] Vida, R., and Costa, L., "Multicast Listener Discovery Version 2 406 (MLDv2) for IPv6", RFC3810, June 2004. 408 [RFC2710] Deering, S., Fenner, B., and Haberman, B., "Multicast Listener 409 Discovery (MLD) for IPv6", RFC 2710, October 1999. 411 8. Informative References 413 [IANA-ALLOCATION] Internet Assigned Numbers Authority, 414 http://www.iana.org/assignments/multicast-addresses. 416 [RFC3306] Haberman, B., and Thaler, D., "Unicast-prefix-based IPv6 417 Multicast Addresses", RFC 3306, August 2002. 419 Authors' Addresses 421 Hugh Holbrook 422 Cisco Systems 423 170 W. Tasman Drive 424 San Jose, CA 95134 425 holbrook@cisco.com 427 Brad Cain 428 Storigen Systems 429 650 Suffolk St. 430 Lowell, MA 01854 431 bcain@storigen.com 433 Brian Haberman 434 Johns Hopkins University Applied Physics Lab 435 11100 Johns Hopkins Road 436 Laurel, MD 20723-6099 437 brian@innovationslab.net 439 Full Copyright Statement 441 Copyright (C) The Internet Society (2004). This document is subject to 442 the rights, licenses and restrictions contained in BCP 78, and except as 443 set forth therein, the authors retain all their rights. 445 This document and the information contained herein are provided on an 446 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR 447 IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 448 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 449 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 450 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 451 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 453 Intellectual Property Rights Notice 455 The IETF takes no position regarding the validity or scope of any 456 Intellectual Property Rights or other rights that might be claimed to 457 pertain to the implementation or use of the technology described in this 458 document or the extent to which any license under such rights might or 459 might not be available; nor does it represent that it has made any 460 independent effort to identify any such rights. Information on the 461 procedures with respect to rights in RFC documents can be found in BCP 462 78 and BCP 79. 464 Copies of IPR disclosures made to the IETF Secretariat and any 465 assurances of licenses to be made available, or the result of an attempt 466 made to obtain a general license or permission for the use of such 467 proprietary rights by implementers or users of this specification can be 468 obtained from the IETF on-line IPR repository at 469 http://www.ietf.org/ipr. 471 The IETF invites any interested party to bring to its attention any 472 copyrights, patents or patent applications, or other proprietary rights 473 that may cover technology that may be required to implement this 474 standard. Please address the information to the IETF at ietf- 475 ipr@ietf.org. 477 This document expires Apr 1, 2005.