idnits 2.17.00 (12 Aug 2021) /tmp/idnits14855/draft-aboba-dhc-nad-ipv4-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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 10 pages 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 429 has weird spacing: '...imed to perta...' == Line 473 has weird spacing: '...>, and expir...' == 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 (12 June 2003) is 6911 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC826' is mentioned on line 44, but not defined -- Looks like a reference, but probably isn't: '1' on line 135 -- Looks like a reference, but probably isn't: '2' on line 137 == Missing Reference: 'LLDP' is mentioned on line 291, but not defined == Missing Reference: 'Congdon' is mentioned on line 305, but not defined == Unused Reference: 'RFC791' is defined on line 326, but no explicit reference was found in the text == Unused Reference: 'RFC792' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'RFC1256' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 335, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 341, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 356, but no explicit reference was found in the text == Unused Reference: 'RFC1058' is defined on line 360, but no explicit reference was found in the text == Unused Reference: 'RFC1332' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'RFC1877' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'RFC2284' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC3118' is defined on line 376, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'IEEE8021Q' is defined on line 390, but no explicit reference was found in the text == Unused Reference: 'IEEE8023' is defined on line 394, but no explicit reference was found in the text == Outdated reference: draft-ietf-zeroconf-ipv4-linklocal has been published as RFC 3927 -- Obsolete informational reference (is this intentional?): RFC 2284 (Obsoleted by RFC 3748) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 25 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft Corporation 4 Category: Best Current Practice 5 6 12 June 2003 8 IPv4 Network Attachment Detection 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Copyright Notice 30 Copyright (C) The Internet Society (2003). All Rights Reserved. 32 Abstract 34 This specification attempts to synthesize experience garnered over the 35 years in the deployment of hosts supporting ARP, DHCP and IPv4 Link- 36 Local addresses. Given this experience, this document suggests 37 optimizations for IPv4 network attachment detection as well as 38 heuristics for determining when assignment of an IPv4 Link-Local address 39 is appropriate. 41 1. Introduction 43 This draft attempts to synthesize experience garnered over the years in 44 the deployment of hosts supporting ARP [RFC826], DHCP [RFC2131], and 45 Link-Local IPv4 addresses [IPv4LL]. There are several reasons which 46 this experience is valuable: 48 [a] Avoiding inappropriate use of Link-Local IPv4 addresses. 49 Experience has shown that in the vast majority of cases, the 50 assignment of Link-Local IPv4 addresses is inappropriate. That is, 51 the IPv4 host assigning an Link-Local IPv4 address either is not 52 connected to a network at all, in which case assignment of an Link- 53 Local IPv4 address does no good; or the host is in fact present on 54 a network with a DHCPv4 server but for one reason or another does 55 not receive a response to a DHCPREQUEST or DHCPDISCOVER. 57 [b] Optimization of network attachment detection. The time required to 58 detect movement (or lack of movement) between subnets, and to 59 obtain (or continue to use) a valid IPv4 address represents a 60 significant fraction of the overall latency resulting from movement 61 between points of attachment on the network. As a result, 62 optimization of network attachment detection in IPv4 hosts is 63 helpful, to the extent that it is achievable. 65 In order to provide suggestions for handling problems [a] and [b], this 66 document suggests the following basic principles: 68 [1] Utilization of link layer hints. Link layers such as IEEE 802 69 [IEEE802] provide hints about whether a host remains on the same 70 subnet despite changing its point of attachment, or even whether 71 the host is connected to an adhoc or infrastructure network. Where 72 available, these hints can be used to guide host behavior - with 73 the understanding that they are not infallible and therefore that 74 the host should be capable of making the correct determination even 75 in the presence of misleading hints. Link layer hints are described 76 in more detail in Section 3. 78 [2] Link-Local IPv4 addressing as a mechanism of last resort. 79 According to [IPv4LL], once a Link-Local IPv4 address is assigned, 80 the DHCPv4 server may not be queried again for 5 minutes. As a 81 result, the inappropriate assignment of a Link-Local IPv4 address 82 results in an extended period of limited connectivity. For a host 83 that may change its point of attachment more frequently than every 84 5 minutes, the inappropriate assignment of an Link-Local IPv4 85 address is more than just an annoyance - it can result in an 86 ongoing inability to connect. As a result, this document suggests 87 that hosts behave conservatively with respect to assignment of 88 Link-Local IPv4 addresses, using them only when there is good 89 evidence that a DHCPv4 server is not present. 91 1.1. Framework and assumptions 93 This document specifies a procedure to be performed for IPv4 network 94 attachment detection that depends on two phases: a connectivity test 95 phase, and an IPv4 address acquisition phase. The tests specified in 96 this document are conducted on connection to a network. On 97 disconnection from a network, there is no need to take action until the 98 host is reconnected, since it is typically not possible for a host to 99 communicate until it has obtained connectivity. Therefore, contrary to 100 [RFC2131] Section 3.7, no profitable actions can be taken on network 101 disconnection. 103 The purpose of the connectivity test phase is for the host to be able to 104 quickly determine whether it remains connected to a network on which it 105 had previously obtained a still valid routable IPv4 address. In this 106 case it is possible to continue to use the existing IPv4 address without 107 having to reacquire it. 109 If the connectivity test is not conclusive, then the host may have 110 moved subnets, so that it attempts to reacquire its IPv4 address. It is 111 possible that the attempt to reacquire an address will be unsuccessful, 112 either due to lack of receipt of a DHCPACK, or because a DHCPNAK is 113 received. In this case, the host attempts to acquire an IPv4 address. 114 If the host does not have a valid routable IPv4 address on the "most 115 likely" network, then the connectivity test is skipped and the host 116 attempts to acquire an IPv4 address. 118 1.2. Connectivity Test 120 Where the host has not yet confirmed whether it has moved subnets, the 121 first step is to test connectivity to the default gateway on the "most 122 likely point of attachment". 124 Where the host has retained the IP and MAC address of the default 125 gateway on the "most likely" network, an attempt is made to demonstrate 126 connectivity to the primary default gateway. If connectivity cannot be 127 demonstrated, the host proceeds to IPv4 address acquisition (or re- 128 acquisition), rather than testing connectivity to alternate gateways. 130 In order to determine the "most likely point of attachment" it is 131 assumed that the host is capable of obtaining and writing to stable 132 storage parameters relating to networks that it connects to. This 133 information includes the following: 135 [1] IP and MAC address(es) of the default gateway(s). 137 [2] Link layer information associated with each network. Link layer 138 information is discussed in more detail in Section 2. 140 Based on this information, the host may be able to make an educated 141 guess as to whether it is likely to have moved between subnets, and if 142 so, to which network it has moved. Link layer information which can be 143 used to determine the "most likely point of attachment" is discussed in 144 Section 3. Where no additional information is available, by default the 145 host assumes that the "most likely point of attachment" is the network 146 to which it was most recently connected. 148 Demonstrating connectivity to the default gateway on the "most likely 149 point of attachment" is useful only where the host can immediately 150 utilize a valid routable IPv4 address were connectivity to be confirmed. 151 If the host does not have a valid routable IPv4 address on the "most 152 likely" network, then it will need to obtain an IPv4 address, so that it 153 is preferable to skip the connectivity test entirely and attempt IPv4 154 address acquisition or reacquisition. 156 Where the host had previously obtained an Link-Local IPv4 address on the 157 "most likely" network it is also preferable to skip the connectivity 158 test since Link-Local IPv4 addresses are only used as a last resort. 159 Therefore IPv4 address acquisition or reacquisition is preferred in this 160 case as well. 162 Where the host has evidence that it has moved subnets (such as 163 association to a different SSID), but no valid routable IPv4 address on 164 the new network or information on the default gateway on that network, 165 the connectivity test is also skipped since insufficient information is 166 available to conduct it. 168 To perform the connectivity test, an ARP Request SHOULD be sent, using 169 the host's MAC address as the source, and the MAC address of the primary 170 default gateway as the destination. The host sets the target protocol 171 address (ar$tpa) to the IPv4 address of the primary default gateway, and 172 uses its own MAC address in the sender hardware address field (ar$sha). 173 Since the host does not yet know whether it has moved subnets, it MUST 174 set the sender protocol address field (ar$spa) to 0.0.0.0. This 175 prevents poisoning of the ARP cache with a (potentially invalid) sender 176 IPv4 address. 178 The ARP Request is sent to the unicast MAC address of the default 179 gateway rather than to the broadcast address in order to confirm both 180 the IPv4 address and MAC address of the default gateway. This allows 181 the host to confirm connectivity to the default gateway even where the 182 host moves between two private networks, since in this case the IPv4 183 address of the default gateway could remain the same, while the MAC 184 address would change. 186 Sending an ICMP Echo Request to the default gateway IPv4 address does 187 not provide the same level of assurance and SHOULD NOT be substituted 188 for an ARP Request sent to the MAC address of the default gateway. 189 Where a host moves from one private network to another, an ICMP Echo 190 Request can result in an ICMP Echo Response even when the default 191 gateway has changed, as long as the IPv4 address remains the same. This 192 can occur, for example, where a host moves from one home network using 193 prefix 192.168/16 to another one. In addition, if the ping is sent with 194 TTL > 1, then an ICMP Echo Response can be received from an offlink 195 gateway. 197 If a valid ARP Response is received, the MAC address in the target 198 hardware address field (ar$tha) and the IPv4 address in the target 199 protocol address field (ar$tpa) are matched against the list of networks 200 and associated default gateway parameters. If a match is found, then 201 if the host has a valid IPv4 address lease on the matched network, the 202 host continues to use that IPv4 address, subject to the lease 203 reacquisition and expiration behavior described in [RFC2131], Section 204 4.4.5. 206 If the initial ARP Request does not elicit a Response, the host waits 1 207 second and then sends an ARP Request to the broadcast address. If no 208 ARP Response is received in response to this second (broadcast) Request, 209 the host proceeds to the next phase. If a valid ARP Response is 210 received, but cannot be matched against known networks, the host assumes 211 it has moved subnets and moves on to the next phase. 213 1.3. IP address acquisition 215 Where the connectivity test is inconclusive, where the host had 216 previously obtained an IPv4 Link-Local address on the "most likely" 217 network, or where the host has no valid IPv4 address lease on the "most 218 likely" network, the host attempts to obtain an IPv4 address. 220 If the host has a valid cached configuration but is unable to confirm 221 connectivity to default gateway on the "most likely point of attachment" 222 then the host seeks to verify the cached configuration by entering the 223 INIT-REBOOT state, and sending a DHCPREQUEST to the broadcast address as 224 specified in [RFC2131] Section 4.4.2. 226 If the host does not have a valid cached configuration, or it had 227 previously obtained a Link-Local IPv4 address on the "most likely" 228 network, then the host enters the INIT state and sends a DHCPDISCOVER 229 packet to the broadcast address, as described in [RFC2131] Section 230 4.4.1. If the host does not receive a response to a DHCPREQUEST or 231 DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section 4.1. 233 As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING 234 state that knows the address of a DHCP server may use that address in 235 the DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. 236 However, sending a DHCPREQUEST to the unicast address when in INIT- 237 REBOOT state is not appropriate since it is possible that the client has 238 moved to another subnet, and therefore the DHCPREQUEST needs to be 239 forwarded to and from the DHCP server by a DHCP Relay so that the 240 response can be broadcast. This ensures that the host will receive a 241 response regardless of whether the cached IP address is correct for the 242 network to which it has connected. 244 As noted in [RFC2131] Section 3.2, if the host possesses a valid 245 routable IPv4 address on the "most likely" network and does not receive 246 a response after employing the retransmission algorithm, the client MAY 247 choose to use the previously allocated network address and configuration 248 parameters for the remainder of the unexpired lease. This is preferable 249 to assigning a Link-Local IPv4 address if the host has reason to believe 250 that it is connected to a network on which it possesses a valid IPv4 251 address lease. This would be the case, for example, where a host 252 reconnects to an IEEE 802.11 network with the same SSID as a network on 253 which it had previously obtained a still-valid IPv4 address lease. 255 Alternatively, if the host does not have a valid IPv4 address lease on 256 the "most likely" network and does not receive a response after 257 employing the retransmission algorithm, it MAY assign a Link-Local IPv4 258 address. This would be the preferred behavior, for example, in 259 situations where the host connects to an adhoc IEEE 802.11 network, 260 unless a routable IPv4 address had previously been assigned on that 261 network. 263 However even in this situation, it is likely that the failure to obtain 264 a routable IPv4 address represents a temporary aberration, rather than 265 legitimate detection of an adhoc network. In such a circumstance, it is 266 therefore desirable to abandon the assignment of an Link-Local IPv4 267 address as soon as a valid IPv4 address lease can be obtained. As a 268 result, it is RECOMMENDED that in such a case, the host will attempt to 269 obtain an IPv4 address assignment at 30 second intervals. 271 1.4. Link layer hints 273 In order to assist in IPv4 network attachment detection, link layer 274 information associated with each network may be retained by the host. 275 Based on information obtained from the link layer, the host may be able 276 to make an educated guess as to whether it has moved between subnets, or 277 remained on the same subnet. If it is likely to have moved between 278 subnets, the host may have an educated guess as to which subnet it has 279 moved to. 281 For networks running over PPP [RFC1661], this can include the link 282 characteristics negotiated in LCP, the IP parameters negotiated in IPCP, 283 and perhaps the associated phone number. 285 On IEEE 802 wired networks, source of link layer information include 286 link-layer discovery traffic as well as information exchanged as part of 287 IEEE 802.1X authentication. Link-layer discovery traffic includes Cisco 288 CDP exchanges as well as network identification information passed in 289 the EAP-Request/Identity or within an EAP method exchange. IEEE 802.1 290 is currently working on standardization of Link Layer Discovery Protocol 291 (LLDP) [LLDP] so that this may also be taken into account. 293 For example, Cisco CDP advertisements can provide information on the IP 294 address of the device, allowing for an intelligent guess as to the 295 likely subnet to which it is connected. When used with IEEE 802.1X 296 authentication, the EAP-Request/Identity exchange may contain the name 297 of the authenticator, also providing information on the potential 298 network. Similarly, during the EAP method exchange the authenticator 299 may supply information that may be helpful in identifying the network to 300 which the device is attached. 302 In IEEE 802.11, [IEEE80211] the device provides information in Beacon 303 and/or Probe Response messages, such as the SSID, BSSID, and 304 capabilities. It also includes information on whether the network is 305 operating in Infrastructure or adhoc mode. As described in [Congdon], 306 it is possible to assign a Station to a VLAN dynamically, based on the 307 results of IEEE 802.1X [IEEE8021X] authentication. This implies that a 308 single SSID may offer access to multiple VLANs, and in practice most 309 large WLAN deployments offer access to multiple subnets. Thus, 310 associating to the same SSID is a necessary, but not necessarily a 311 sufficient condition for remaining within the same subnet. In order to 312 provide additional guidance on the subnets to which a given AP offers 313 access, additional subnet-related Information Elements (IEs) have been 314 proposed for addition to the IEEE 802.11 Beacon and Probe Response 315 messages [handoffIE]. 317 While a Station associating to the same SSID may not necessarily remain 318 within the same subnet, on the other hand, a Station associated to a 319 different SSID is likely to have changed subnets. As a result, a 320 Station associating with a different SSID MAY forgo the "remains 321 connected" step in Section ? and go straight to the "Discover new 322 address" step. 324 2. Normative References 326 [RFC791] Postel, J., "Internet Protocol", RFC 791, USC/Information 327 Sciences Institute, September 1981. 329 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 330 USC/Information Sciences Institute, September 1981. 332 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 333 Xerox PARC, September 1991. 335 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 336 Requirement Levels", RFC 2119, March, 1997. 338 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 339 2131, March 1997. 341 [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP 342 Vendor Extensions", RFC 2132, Silicon Graphics, Inc., 343 Bucknell University, March 1997. 345 [IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic 346 Configuration of IPv4 Link-Local Addresses", Internet 347 draft (work in progress), draft-ietf-zeroconf- 348 ipv4-linklocal-08.txt, June 2003. 350 3. Informational References 352 [RFC1034] Mockapetris, P., "Domain Names - Concepts and 353 Facilities", STD 13, RFC 1034, USC/Information Sciences 354 Institute, November 1987. 356 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 357 Specification", STD 13, RFC 1035, USC/Information 358 Sciences Institute, November 1987. 360 [RFC1058] Hedrick, C.L., "Routing Information Protocol", RFC 1058, 361 Rutgers University, June 1, 1988. 363 [RFC1332] McGregor, G., "PPP Internet Control Protocol", RFC 1332, 364 Merit, May 1992. 366 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 367 STD 51, RFC 1661, Daydreamer, July 1994. 369 [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol 370 Extensions for Name Server Addresses", RFC 1877, December 371 1995. 373 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 374 Authentication Protocol (EAP)", RFC 2284, March 1998. 376 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 377 Messages", RFC 3118, June 2001. 379 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 380 Port based Network Access Control, IEEE Std 802.1X-2001, 381 June 2001. 383 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 384 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 385 October 1998. 387 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 388 Overview and Architecture, ANSI/IEEE Std 802, 1990. 390 [IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks: 391 Draft Standard for Virtual Bridged Local Area Networks, 392 P802.1Q, January 1998. 394 [IEEE8023] ISO/IEC 8802-3 Information technology - 395 Telecommunications and information exchange between 396 systems - Local and metropolitan area networks - Common 397 specifications - Part 3: Carrier Sense Multiple Access 398 with Collision Detection (CSMA/CD) Access Method and 399 Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 400 1996), 1996. 402 [IEEE80211] Information technology - Telecommunications and 403 information exchange between systems - Local and 404 metropolitan area networks - Specific Requirements Part 405 11: Wireless LAN Medium Access Control (MAC) and 406 Physical Layer (PHY) Specifications, IEEE Std. 407 802.11-1999, 1999. 409 Acknowledgments 411 The authors would like to acknowledge Erik Guttman and Erik Nordmark of 412 Sun Microsystems, Ted Lemon of Nominum and Thomas Narten of IBM for 413 contributions to this document. 415 Authors' Addresses 417 Bernard Aboba 418 Microsoft Corporation 419 One Microsoft Way 420 Redmond, WA 98052 422 EMail: bernarda@microsoft.com 423 Phone: +1 425 706 6605 424 Fax: +1 425 936 7329 426 Intellectual Property Statement 428 The IETF takes no position regarding the validity or scope of any 429 intellectual property or other rights that might be claimed to pertain 430 to the implementation or use of the technology described in this 431 document or the extent to which any license under such rights might or 432 might not be available; neither does it represent that it has made any 433 effort to identify any such rights. Information on the IETF's 434 procedures with respect to rights in standards-track and standards- 435 related documentation can be found in BCP-11. Copies of claims of 436 rights made available for publication and any assurances of licenses to 437 be made available, or the result of an attempt made to obtain a general 438 license or permission for the use of such proprietary rights by 439 implementors or users of this specification can be obtained from the 440 IETF Secretariat. 442 The IETF invites any interested party to bring to its attention any 443 copyrights, patents or patent applications, or other proprietary rights 444 which may cover technology that may be required to practice this 445 standard. Please address the information to the IETF Executive 446 Director. 448 Full Copyright Statement 450 Copyright (C) The Internet Society (2003). All Rights Reserved. 451 This document and translations of it may be copied and furnished to 452 others, and derivative works that comment on or otherwise explain it or 453 assist in its implementation may be prepared, copied, published and 454 distributed, in whole or in part, without restriction of any kind, 455 provided that the above copyright notice and this paragraph are included 456 on all such copies and derivative works. However, this document itself 457 may not be modified in any way, such as by removing the copyright notice 458 or references to the Internet Society or other Internet organizations, 459 except as needed for the purpose of developing Internet standards in 460 which case the procedures for copyrights defined in the Internet 461 Standards process must be followed, or as required to translate it into 462 languages other than English. The limited permissions granted above are 463 perpetual and will not be revoked by the Internet Society or its 464 successors or assigns. This document and the information contained 465 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 466 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 467 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 468 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 469 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 471 Expiration Date 473 This memo is filed as , and expires 474 December 22, 2003.