idnits 2.17.00 (12 Aug 2021) /tmp/idnits50985/draft-thubert-nemo-basic-usages-00.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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([6]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There is 5 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** 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 274: '..., the Home Agent MUST intercept all th...' RFC 2119 keyword, line 275: '... In order to do so, the Home Agent MAY...' RFC 2119 keyword, line 299: '... interface, it MAY set up a bridge b...' RFC 2119 keyword, line 300: '...vely, the Mobile Router MAY perform ND...' RFC 2119 keyword, line 375: '... link, SHOULD not send any routing p...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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 'SHOULD not' in this paragraph: In order for a Mobile Router to emulate returning Home, it can connect to one or more access link(s) configured for that purpose on the Home Agent. The Mobile Router, after connecting to the access link, SHOULD not send any routing protocol updates on the egress interface because the routing information from the Mobile Router might adversely affect IPv6 route aggregation on the Home Network. However, the Mobile Router must register its binding as if it was accessing a foreign link. -- 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 (October 15, 2003) is 6793 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: '1' is defined on line 408, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 411, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 414, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 417, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 428, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '1') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '3') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3513 (ref. '4') (Obsoleted by RFC 4291) == Outdated reference: draft-ietf-mobileip-ipv6 has been published as RFC 3775 == Outdated reference: draft-ietf-nemo-basic-support has been published as RFC 3963 == Outdated reference: draft-ietf-nemo-requirements has been published as RFC 4886 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-requirements (ref. '7') == Outdated reference: draft-ietf-nemo-terminology has been published as RFC 4885 ** Downref: Normative reference to an Informational draft: draft-ietf-nemo-terminology (ref. '8') Summary: 14 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Mobility P. Thubert 3 Internet-Draft Cisco Systems 4 Expires: April 14, 2004 R. Wakikawa 5 Keio University 6 V. Devarapalli 7 Nokia 8 October 15, 2003 10 Examples of basic Nemo usage 11 draft-thubert-nemo-basic-usages-00 13 Status of this Memo 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that other 20 groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at http:// 28 www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 14, 2004. 35 Copyright Notice 37 Copyright (C) The Internet Society (2003). All Rights Reserved. 39 Abstract 41 This paper documents some practical scenarios and the associated 42 issues when deploying Mobile Routers, conforming the Nemo Basic 43 Support draft [6]. 45 The aim here is specifically to provide some examples of organization 46 of the Home Network, as they were discussed in the Nemo and Nemo 47 Design mailing lists. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology and concepts . . . . . . . . . . . . . . . . . . . 4 53 3. General Expectations . . . . . . . . . . . . . . . . . . . . . 5 54 4. Extended Home Network . . . . . . . . . . . . . . . . . . . . 6 55 4.1 Returning Home . . . . . . . . . . . . . . . . . . . . . . . . 7 56 5. Aggregated Home . . . . . . . . . . . . . . . . . . . . . . . 8 57 5.1 Returning Home . . . . . . . . . . . . . . . . . . . . . . . . 8 58 6. Virtual Home Network . . . . . . . . . . . . . . . . . . . . . 10 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 60 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 62 A. Returning Home in the virtual case . . . . . . . . . . . . . . 13 63 Intellectual Property and Copyright Statements . . . . . . . . 14 65 1. Introduction 67 This document assumes that the reader is familiar with Mobile IPv6 as 68 defined in [5], and with the concept of Mobile Router defined in the 69 Nemo terminology document [8]. 71 Three different organizations of the Home Network are documented: 73 Extended Home Network: In this disposition, the Home Network is but 74 one subnet of a larger aggregation that encompasses the Mobile 75 Networks, called extended Home Network. When at Home, a Mobile 76 Router performs normal routing between the Home Link and the 77 Mobile Networks. 79 Aggregated Home Network: In this disposition, the Home Network 80 actually overlaps with the Mobile Networks. When at Home, a Mobile 81 Router acts as a bridge between the Home Link and the Mobile 82 Networks. 84 Virtual Home Network: In this disposition, there is no physical Home 85 Link at all for the Mobile Routers to come back Home to. 87 In all three cases, the Home Agents collectively advertise only the 88 aggregation of the Mobile Networks. The dichotomy is kept within the 89 Home Agents and the Mobile Routers, as opposed to advertised by means 90 of routing protocols to other parties. 92 Also, it is valid for a Mobile Router to register using an address 93 from one of its own Mobile Network Prefixes in all three cases. 95 The examples provided hereafter aim at illustrating the Nemo Basic 96 Support draft [6] but are by no mean at limiting its scope of 97 application. 99 2. Terminology and concepts 101 This draft uses the following additional terminology: 103 Home Link: The link attached to the interface at the Home Agent on 104 which the Home Prefix is configured. The interface can be a 105 virtual interface, in which case the Home Link is a virtual Home 106 Link. 108 Home Network: The Network formed by the application of the Home 109 Prefix on the Home Link. With Nemo, the concept of Home Network is 110 extended as explained below. 112 Home Address: With Mobile IPv6, a Home Address is derived from the 113 Home Network prefix. This is generalized in Nemo, with some 114 limitations: A Home Address can be either derived from the Home 115 Network or from one of the Mobile Router's Mobile Network 116 prefixes. 118 MRHA Tunnel: The bi-directional tunnel between a Mobile Router and 119 its Home Agent 121 Mobile Aggregated Prefix: An aggregation of Mobile Network Prefixes. 123 Aggregated Home Network: The Home Network associated with a Mobile 124 Aggregated Prefix. This Aggregation is advertised as a subnet on 125 the Home Link, and thus used as Home Network for Nemo purposes. 127 Extended Home Network: The network associated with the aggregation of 128 one or more Home Network(s) and Mobile Network(s). As opposed to 129 the Mobile IPv6 Home Network that is a subnet, the extended Home 130 Network is an aggregation and is further subnetted. 132 Virtual Home Network: The Home Network associated with a Virtual 133 Network. The Extended Home Network and the Aggregated Home Network 134 can be configured as Virtual Home Network. 136 3. General Expectations 138 With Mobile IPv6, the Home Network is generally a physical network 139 interconnecting the Home Agents, and the Mobile Nodes that are at 140 Home. Nemo extends the concept of Home so that it is not only a flat 141 subnet composed of Home Addresses but an aggregation that is itself 142 subnetted in mobile and Home Networks. This aggregation is still 143 referred to as Home. 145 As an example, say that the aggregation has a global routing prefix 146 of m = 48 bits (A:B:C::/48), with subnet ID size of n = 16 bits ( n + 147 m = 64). 149 Say that a Mobile Router, MR1, owns the Mobile Network Prefix 150 A:B:C:1::/64: With basic Nemo, and depending on the deployment, MR1 151 may register using a Home Address from the Home network, A:B:C:0::1, 152 say, or a Home Address, A:B:C:1::1, say, from one of its Mobile 153 Network Prefixes. 155 In a given deployment, one subnet may be reserved for the Home Link 156 (say A:B:C:0::/64) while the others are attributed to Mobile Routers 157 as Mobile Networks (as A:B:C:1::/64 for MR1). Another approach could 158 be to configure the Aggregation of Mobile Networks as the subnet on 159 the Home Link, and let the Mobile Routers manage the overlapping 160 networks. Finally, the aggregation could be configured on a virtual 161 network, with no physical Home Link at all, in which case Home means 162 topologically and administratively close to the Home Agent that owns 163 the virtual network. 165 The following sections provide additional information on these forms 166 of Home Network: 168 4. Extended Home Network 170 One simple approach can be to reserve one or several subnets from an 171 aggregation for the Home Link, and to use the other subnets as Mobile 172 Network Prefixes. In that case, the Home Network and the Mobile 173 Networks do not overlap. The aggregation is called an extended Home 174 Network. 176 | 177 route v /48 A:B:C::/48 179 HA 180 | /64 A:B:C:0::/64 181 --+-----+--+- . -+- . -+-- 182 | | | | 183 MR1 MR2 MRi MRN 184 /64 /64 /64 /64 A:B:C:i::/64 0 < i <= N 186 extended Home Network 188 In that configuration: 190 o There is one physical Home Network and multiple Mobile Networks 192 o The Home and the Mobile Network prefixes are tailored to allow for 193 IPv6 Stateless Address Autoconfiguration with typical interface 194 identifier length for the type of interface (can be for example / 195 64). 197 o The prefix length of the extended Home Network is shorter than 198 that of the Home Network and the Mobile Network prefixes, since it 199 is an aggregation (can be for example /48). 201 o The Mobile Routers are assigned individually a Home Address from 202 the Home Network and use is to register their Mobile Network 203 Prefix(es). In that case, the Home Agent performs DAD in the Home 204 Network as prescribed by Mobile IPv6 for the Home Addresses. 206 o Alternatively, a Mobile Router could also form a Home Address from 207 one of its prefixes and use it to register, performing its own DAD 208 on its ingress network. 210 4.1 Returning Home 212 In the extended Home Network model, the Home Network is configured on 213 a physical interface of the Home Agent, the Home Link. 215 A Mobile Router returns Home by connecting directly to the Home Link, 216 and dropping the MRHA tunnel. 218 If the Home Address of the Mobile Router is derived from one of its 219 Mobile Networks, then the MR may connect to the Home Link using an 220 egress interface and autoconfigure an address on the Home Link. The 221 MR recognizes the prefix of its Home Agent in order to decide that it 222 is Home. Note that in that case the Home Address does not match the 223 Home Prefix. 225 When at Home, the Mobile Router ensures the connectivity of the 226 Mobile Network using standard router operations. 228 In particular, if the HA has the necessary information to continue 229 routing to the Mobile Network Prefixes in the absence of 230 registration, for instance if the Home Address of the Mobile Router 231 is derived from the Home Network, and if the HA uses a static route 232 to the Mobile Network Prefix(es) via that address, then the 233 participation of the MR to the Home IGP is not required. 235 But in the general case, when the MR is at Home, it resumes IGP 236 operations on the Home Link in order to advertise its Mobile 237 Networks. 239 Alternate procedures for ensuring the connectivity of the Mobile 240 Networks when at Home are described in Section 6. In Particular, it 241 is 243 5. Aggregated Home 245 One other approach is to consider that the Aggregation of all the 246 mobile network prefixes is used plainly as the Home Network, refered 247 to as the Aggregated Home Network. This means that the Mobile 248 Aggregated Prefix is configured on the Home Link and advertised by 249 the Home Agent as a subnet. 251 HA 252 | /56 Aggreg /56 253 --+-----+--+- . -+- . -+-- 254 | | | | 255 MR1 MR2 MRi MRN 256 ------ ------ ------ ------ 257 /64 /64 /64 /64 Aggreg|i /64 0 < i <= N 259 Aggregated Home 261 Note: a Mobile Router coming Home sees overlapping prefixes between 262 the ingress and the egress interface and some specific support may be 263 needed. 265 A node on the Home Link will compute that the Aggregated Home Network 266 is actually a subnet on the Home Link and may use it for 267 autoconfiguration purposes. Such a node may also install a connected 268 route to the Aggregated Home Network over the Home Link. 270 As a result, unless the node has a better (longest match) route to a 271 given Mobile Network Prefix, it will lookup all MNNs using Neighbour 272 Discovery over the Home Link. 274 Thus, the Home Agent MUST intercept all the packets to the MNNs on 275 the registered prefixes. In order to do so, the Home Agent MAY 276 perform ND proxying for all addresses in all registered Mobile 277 Network Prefixes, and protect the Mobile Network Prefix space from 278 autoconfiguration by uncontrolled visitors on the Home Link. 280 Alternatives based on a routing protocol or ICMP redirect may apply 281 in some cases. 283 5.1 Returning Home 285 The Aggregated Home Prefix is configured on a physical interface of 286 the Home Agent, the Home Link. As a consequence, the Home Agent has a 287 connected route to the Aggregated Home Network over the Home Link. 289 A Mobile Router returns Home by connecting directly to the Home Link, 290 and dropping the MRHA tunnel. 292 The Mobile Router recognizes its Home Link by a prefix match with its 293 Home Agent. Note that it must expect a shorter prefix than that of 294 its Mobile Networks, even if its Home Address is formed out of one of 295 its Mobile Network Prefixes, but that the Home Address matches the 296 Home Network Prefix. 298 When a Mobile Router connects to the Home Link using its egress 299 interface, it MAY set up a bridge between its ingress interface(s) 300 and the Home Link. Alternatively, the Mobile Router MAY perform ND 301 proxying for all addresses in its Mobile Network Prefixes, between 302 the egress and the related ingress interface. Since the prefixes on 303 the egress and ingress interfaces are overlapping, routing is 304 disallowed. 306 HA 307 | /56 Aggreg /56 308 --+-----+--+- . -+- . -+-- 309 | | | | 310 MR1 MR2 MRi MRN 311 ------ ------ ------ ------ 312 /64 /64 /64 /64 Aggreg|i /64 0 < i <= N 314 Bridging between egress and ingress 316 Alternatively, if the MR has a single ingress Interface, the Mobile 317 Router may use the Mobile Link to connect to the Home Link, merging 318 the two links in a single consistent network. 320 HA 321 | /56 Aggreg /56 322 --+-----+--+- . -+- . -+-- 323 /64 /64 /64 /64 Aggreg|i /64 0 < i <= N 324 ------ ------ ------ ------ 325 MR1 MR2 MRi MRN 326 | | | | 328 Merging the Home and the Mobile Networks 330 This fits the connected route model, since the Aggregated Home is 331 truly located on that network. 333 6. Virtual Home Network 335 The Home Link can be configured on the Home Agent on a virtual link, 336 in which case there's no physical Home Link for Mobile Routers to 337 return Home or for Home Agents to discover each others and perform 338 the ND level interactions as described in Mobile IPv6. [5] 340 /48 eg: A:B:C::/48 341 HA 342 | /64 A:C:C:E::/64 343 --+-----+--+- . -+- . -+-- 344 | | | | 345 MR1 MR2 MRi MRN 346 /64 /64 /64 /64 A:B:C:i::/64 0 < i <= N 348 Virtual Home Network 350 The Extended Home network and the Aggregated Home network models can 351 be adapted for virtual links. There is no change in the way Home 352 Addresses are allocated. As in the case of a physical link, the Home 353 Address of a Mobile router is constructed based on the the Home 354 Prefix or one of the prefixes of its Mobile Network(s). 356 There are certain advantages to making the Home Link a virtual link: 358 A virtual link may not experience any disruption related to 359 physical maintenance or to hardware problems, so it is more 360 available than a physical link. The high availability of the Home 361 Link is critical for the mobility service. 363 The Home Agent does not have to defend the Mobile Router's Home 364 Address through Proxy Neighbor Discovery. The Home Agent does not 365 also have to perform Duplicate Address Detection (DAD) for the 366 Mobile Router's Home Address when it receives a Binding Update 367 from the Mobile Router. 369 The Mobile Router does not have to implement the Returning Home 370 procedure (section 11.5.4 of Mobile IPv6. [5]). 372 In order for a Mobile Router to emulate returning Home, it can 373 connect to one or more access link(s) configured for that purpose on 374 the Home Agent. The Mobile Router, after connecting to the access 375 link, SHOULD not send any routing protocol updates on the egress 376 interface because the routing information from the Mobile Router 377 might adversely affect IPv6 route aggregation on the Home Network. 378 However, the Mobile Router must register its binding as if it was 379 accessing a foreign link. 381 There are also some drawbacks to the virtual Home Link approach: 383 There can be only one Home Agent since Mobile IPv6 relies on 384 Neighbor Discovery on the Home Link for other HA discovery and for 385 Duplicate Address Detection. 387 The Home Agent must maintain a Binding Cache entry for a Mobile 388 Router and forwarding state for its Mobile Network even when the 389 Mobile Router is directly connected to it. All traffic to and from 390 the Mobile Network is sent through the bi-directional tunnel 391 regardless of the Mobile Router location. This results in a 392 tunneling overhead even though the Mobile Router is connected to 393 the Home Network. 395 Some solutions can be proposed in order to perform an equivalent of 396 returning Home on a virtual Home Network. One such approach is 397 sketched in appendix as an illustration. 399 7. Acknowledgements 401 The authors wish to thank: 403 Erik Nordmark, Kent Leung, Thierry Ernst, TJ Kniveton and Alexandru 404 Petrescu for their contributions. 406 References 408 [1] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 409 Specification", RFC 2460, December 1998. 411 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 412 IP Version 6 (IPv6)", RFC 2461, December 1998. 414 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 415 Autoconfiguration", RFC 2462, December 1998. 417 [4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 418 Addressing Architecture", RFC 3513, April 2003. 420 [5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 421 IPv6", draft-ietf-mobileip-ipv6-24 (work in progress), July 422 2003. 424 [6] Devarapalli, V., "Nemo Basic Support Protocol", 425 draft-ietf-nemo-basic-support-01 (work in progress), September 426 2003. 428 [7] Ernst, T., "Network Mobility Support Goals and Requirements", 429 draft-ietf-nemo-requirements-01 (work in progress), May 2003. 431 [8] Ernst, T. and H. Lach, "Network Mobility Support Terminology", 432 draft-ietf-nemo-terminology-00 (work in progress), May 2003. 434 Authors' Addresses 436 Pascal Thubert 437 Cisco Systems Technology Center 438 Village d'Entreprises Green Side 439 400, Avenue Roumanille 440 Biot - Sophia Antipolis 06410 441 FRANCE 443 EMail: pthubert@cisco.com 445 Ryuji Wakikawa 446 Keio University and WIDE 447 5322 Endo Fujisawa Kanagawa 448 252-8520 449 JAPAN 451 EMail: ryuji@sfc.wide.ad.jp 453 Vijay Devarapalli 454 Nokia Research Center 455 313 Fairchild Drive 456 Mountain View, CA 94043 457 USA 459 EMail: vijay.devarapalli@nokia.com 461 Appendix A. Returning Home in the virtual case 463 When a Home Link is virtual, all traffic to and from the Mobile 464 Network is sent through the bi-directional tunnel even at the Home 465 Link. This section describes one possible mechanism that extends 466 basic Nemo to eliminate this tunneling overhead. 468 Although the Home Link is virtual, the Home Agent has at least one 469 physical link to communicate with the external world. One or several 470 of such links, called the virtual Home Access Links, are conceptually 471 associated with the virtual Home Link and considered as part of Home. 473 When accessing one of its virtual Home Access Links, a Mobile Router 474 autoconfigures a Care-of Address from a Router Advertisement as it 475 would do on any visited link, in order to perform the next binding 476 flow. 478 If the Mobile Router is configured to recognize the virtual Home 479 Access Links as part of Home, it deregisters by sending a Binding 480 update with null lifetime sourced at the CareOf. Alternatively, the 481 Home Agent may indicate that the MR is Home as a negative status in 482 the binding acknowledgement. This is achieved by a prefix 483 comparison(s) between the care-of address and the prefix(es) on the 484 virtual Home Access Link(s). 486 With both approaches, the result of the binding flow is a 487 deregistration. Consequently, both the Mobile Router and the Home 488 Agent disable the bi-directional tunnel. At that point, the Home 489 Agent configures its forwarding in order to reach the Mobile Router 490 and its mobile networks at Home. For instance, this may take the form 491 of a route to the Mobile Network prefixes via the MR Home Address, 492 and a connected host route to the MR Home Address via the virtual 493 Home Access link. 495 After successful binding de-registration, the Mobile Router MUST 496 receive packets meant to the Mobile Router's Home Address at the 497 Virtual Home Link. How to intercept packets addressed to the Home 498 Address depends on implementations of the Mobile Router. If the Home 499 Address is not configured at the egress interface, the Mobile Router 500 MUST use proxy Neighbor Discovery to intercept all packets addressed 501 to the Home Address on the virtual Home Link. Otherwise, the Mobile 502 Router does not have to perform any special operation at the virtual 503 Home Link. 505 After all procedures are done successfully, all IPv6 traffic to and 506 from the Mobile Network are routed without a bi-directonal tunnel 507 between the Mobile Router and the Home Agent. 509 Intellectual Property Statement 511 The IETF takes no position regarding the validity or scope of any 512 intellectual property or other rights that might be claimed to 513 pertain to the implementation or use of the technology described in 514 this document or the extent to which any license under such rights 515 might or might not be available; neither does it represent that it 516 has made any effort to identify any such rights. Information on the 517 IETF's procedures with respect to rights in standards-track and 518 standards-related documentation can be found in BCP-11. Copies of 519 claims of rights made available for publication and any assurances of 520 licenses to be made available, or the result of an attempt made to 521 obtain a general license or permission for the use of such 522 proprietary rights by implementors or users of this specification can 523 be obtained from the IETF Secretariat. 525 The IETF invites any interested party to bring to its attention any 526 copyrights, patents or patent applications, or other proprietary 527 rights which may cover technology that may be required to practice 528 this standard. Please address the information to the IETF Executive 529 Director. 531 Full Copyright Statement 533 Copyright (C) The Internet Society (2003). All Rights Reserved. 535 This document and translations of it may be copied and furnished to 536 others, and derivative works that comment on or otherwise explain it 537 or assist in its implementation may be prepared, copied, published 538 and distributed, in whole or in part, without restriction of any 539 kind, provided that the above copyright notice and this paragraph are 540 included on all such copies and derivative works. However, this 541 document itself may not be modified in any way, such as by removing 542 the copyright notice or references to the Internet Society or other 543 Internet organizations, except as needed for the purpose of 544 developing Internet standards in which case the procedures for 545 copyrights defined in the Internet Standards process must be 546 followed, or as required to translate it into languages other than 547 English. 549 The limited permissions granted above are perpetual and will not be 550 revoked by the Internet Society or its successors or assignees. 552 This document and the information contained herein is provided on an 553 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 554 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 555 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 556 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 557 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 559 Acknowledgement 561 Funding for the RFC Editor function is currently provided by the 562 Internet Society.