idnits 2.17.1 draft-ietf-dhc-dna-ipv4-03.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 12 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 13 pages 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 == Line 94 has weird spacing: '...ibed in more ...' == Line 558 has weird spacing: '...>, and expir...' -- 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 (9 October 2003) is 7498 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) -- Looks like a reference, but probably isn't: '1' on line 152 -- Looks like a reference, but probably isn't: '2' on line 154 == Unused Reference: 'RFC792' is defined on line 347, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 364, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) == Outdated reference: A later version (-17) exists of draft-ietf-zeroconf-ipv4-linklocal-10 -- Obsolete informational reference (is this intentional?): RFC 2284 (Obsoleted by RFC 3748) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DHC Working Group Bernard Aboba 3 INTERNET-DRAFT Microsoft Corporation 4 Category: Proposed Standard 5 6 9 October 2003 8 Detection of Network Attachment (DNA) in IPv4 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 The time required to detect movement (or lack of movement) between 35 subnets, and to obtain (or continue to use) a valid IPv4 address may 36 be significant as a fraction of the total delay in moving between 37 points of attachment. This specification synthesizes experience 38 garnered over the years in the deployment of hosts supporting ARP, 39 DHCP and IPv4 Link-Local addresses, in order to optimize detection of 40 network attachment by mobile hosts. 42 Table of Contents 44 1. Introduction.............................................. 3 45 1.1 Requirements .................................... 4 46 1.2 Terminology ..................................... 4 47 2. Framework ................................................ 4 48 2.1 Reachability test ............................... 5 49 2.2 Packet format ................................... 5 50 2.3 IPv4 Address Acquisition ........................ 7 51 3. IANA Considerations ...................................... 8 52 4. Security Considerations .................................. 8 53 5. References ............................................... 8 54 5.1 Normative references ............................ 8 55 5.2 Informative references .......................... 9 56 Acknowledgments .............................................. 10 57 Authors' Addresses ........................................... 10 58 Appendix A - Hints ........................................... 11 59 Intellectual Property Statement .............................. 12 60 Full Copyright Statement ..................................... 12 61 1. Introduction 63 The time required to detect movement (or lack of movement) between 64 subnets, and to obtain (or continue to use) a valid IPv4 address may 65 be significant as a fraction of the total delay in moving between 66 points of attachment. As a result, optimizing detection of network 67 attachment is important for mobile hosts. 69 This document synthesizes experience in the deployment of hosts 70 supporting ARP [RFC826], DHCP [RFC2131], and Link-Local IPv4 71 addresses [IPv4LL], specifying a procedure to be performed for IPv4 72 detection of network attachment. The procedure consists of three 73 phases: determination of the "most likely" point of attachment, 74 reachability testing, and IPv4 address acquisition. 76 On disconnection from a network, there is no need to take action 77 until the host is reconnected, since it is typically not possible for 78 a host to communicate until it has obtained connectivity. Therefore, 79 contrary to [RFC2131] Section 3.7, no action need be taken on network 80 disconnection. 82 For Detection of Network attachment, the following basic principles 83 are suggested: 85 [a] Utilization of link layer hints. Link layers such as 86 IEEE 802 [IEEE802] provide hints about whether a host 87 remains on the same subnet despite changing its point of 88 attachment, or even whether the host is connected to an 89 adhoc or infrastructure network. Where available, these 90 hints can be used to guide host behavior - with the 91 understanding that they are not infallible and therefore 92 that the host should be capable of making the correct 93 determination even in the presence of misleading hints. 94 Link layer hints are described in more detail in 95 Appendix A. 97 [b] Link-Local IPv4 addressing as a mechanism of last resort. 98 Experience has shown that Link-Local IPv4 addresses are 99 often assigned inappropriately. For example, an IPv4 host 100 assigning an Link-Local IPv4 address may not be connected 101 to any network, in which case assignment of a Link-Local 102 IPv4 address does no good; or the host may be attached to a 103 network with a DHCPv4 server but may not receive a response 104 to a DHCPREQUEST or DHCPDISCOVER. As described in Appendix A 105 of [IPv4LL] once a Link-Local IPv4 address is assigned, 106 existing implementations do not query the DHCPv4 server 107 again for 5 minutes. As noted in Section 2.3, this behavior 108 is in violation of [RFC2131] Section 4.1. For hosts changing 109 their point of attachment more frequently than this, 110 inappropriate assignment of an Link-Local IPv4 address can 111 result in an ongoing inability to connect. As a result, 112 this document suggests that hosts behave conservatively with 113 respect to assignment of Link-Local IPv4 addresses, using 114 them only as a last resort. 116 1.1. Requirements 118 In this document, several words are used to signify the requirements 119 of the specification. These words are often capitalized. The key 120 words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 121 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 122 are to be interpreted as described in [RFC2119]. 124 1.2. Terminology 126 This document uses the following terms: 128 DHCP client 129 A DHCP client or "client" is an Internet host using DHCP to obtain 130 configuration parameters such as a network address. 132 DHCP server 133 A DHCP server or "server" is an Internet host that returns 134 configuration parameters to DHCP clients. 136 Routable address 137 In this specification, the term "routable address" refers to any 138 address other than an IPv4 Link-Local address. This includes 139 private addresses as specified in [RFC1918]. 141 2. Framework 143 On connecting to a new point of attachment, the host attempts to 144 determine the "most likely" configuration associated with the new 145 point of attachment. 147 In order to determine the "most likely" point of attachment it is 148 assumed that the host is capable of obtaining and writing to stable 149 storage parameters relating to networks that it connects to, 150 including: 152 [1] IP and link layer hints associated with each network. For 153 details, see Appendix A. 154 [2] The IP and MAC address of the primary default gateway on 155 each network. 157 By matching the received hints against information previously 158 collected, the host may be able to make an educated guess of which 159 network it has attached to. Where no additional information is 160 available, by default the host assumes that the "most likely" point 161 of attachment is the network to which it was most recently connected. 163 If the host has a valid routable IPv4 address on the "most likely" 164 point of attachment, the host performs a reachability test as 165 described below. If the reachability test is not successful, or if 166 the host does not have a valid routable IPv4 address on the "most 167 likely" point of attachment, the host proceeds to the IPv4 address 168 acquisition phase. 170 2.1. Reachability Test 172 The purpose of the reachability test is to determine whether the host 173 is connected to a network on which it had previously obtained a still 174 valid routable IPv4 address. The test is performed by attempting to 175 verify reachability of a previously configured primary default 176 gateway on a former point of attachment. If the test is successful, 177 the host may continue to use a valid routable IPv4 address without 178 having to re-acquire it. This reduces roaming latency by allowing 179 the host to bypass the DHCP exchange as well as subsequent Duplicate 180 Address Detection (DAD). In contrast to a DHCP exchange, which may 181 be between a DHCP client and an offlink DHCP server, the reachability 182 test occurs between a host and its next hop router. 184 The host skips the reachability test and proceeds to the address 185 acquisition phase in the following circumstances: 187 [a] If the host does not have information on the default 188 gateway on the network. 189 [b] If the host does not have a valid routable IPv4 address 190 on the network. Since Link-Local IPv4 addresses are a 191 last resort, these addresses do not count as a valid 192 routable IPv4 address. 194 2.2. Packet Format 196 To perform the reachability test, an ARP Request SHOULD be sent, 197 using the host's MAC address as the source, and the broadcast MAC 198 address as the destination. The host sets the target protocol 199 address (ar$tpa) to the IPv4 address of the primary default gateway, 200 and uses its own MAC address in the sender hardware address field 201 (ar$sha). 203 If the host has a valid globally routable IP address on the most 204 likely point of attachment, then it SHOULD set the sender protocol 205 address field (ar$spa) to that address. It is assumed that the host 206 had previously done duplicate address detection so that an address 207 conflict is unlikely. 209 However if the host has a private address as defined in [RFC1918], 210 then it SHOULD set the protocol address field (ar$spa) to 0.0.0.0. 211 This is to avoid an address conflict in the case where the host has 212 changed its point of attachment from one private network to another. 214 Note: Some routers may refuse to answer an ARP Request sent with 215 the protocol address field (ar$spa) set to the unspecified 216 address. In this case the reachability test will fail. 218 If a valid ARP Response is received, the MAC address in the target 219 hardware address field (ar$tha) and the IPv4 address in the target 220 protocol address field (ar$tpa) are matched against the list of 221 networks and associated default gateway parameters. If a match is 222 found, then if the host has a valid IPv4 address lease on the 223 matched network, the host continues to use that IPv4 address, subject 224 to the lease re-acquisition and expiration behavior described in 225 [RFC2131], Section 4.4.5. 227 Checking for a match on both the IPv4 and MAC addresses of the 228 default gateway allows the host to confirm reachability even where 229 the host moves between two private networks. In this case the IPv4 230 address of the default gateway could remain the same, while the MAC 231 address would change, so that both addresses need to be checked. 233 Sending an ICMP Echo Request to the default gateway IPv4 address does 234 not provide the same level of assurance since this requires an ARP 235 Request/Response to be sent first, and typically does not allow the 236 MAC address to be checked as well. It therefore SHOULD NOT be used 237 as a substitute. Where a host moves from one private network to 238 another, an ICMP Echo Request can result in an ICMP Echo Response 239 even when the default gateway has changed, as long as the IPv4 240 address remains the same. This can occur, for example, where a host 241 moves from one home network using prefix 192.168/16 to another one. 242 In addition, if the ping is sent with TTL > 1, then an ICMP Echo 243 Response can be received from an off-link gateway. 245 If the initial ARP Request does not elicit a Response, the host waits 246 200ms and then sends another ARP Request. If no ARP Response is 247 received in response to this second Request, the host proceeds to the 248 IPv4 address acquisition phase. If a valid ARP Response is received, 249 but cannot be matched against known networks, the host assumes it has 250 moved subnets and moves on to the address acquisition phase. 252 2.3. IPv4 Address Acquisition 254 If the host has a valid cached configuration on the "most likely" 255 point of attachment, but is unable to confirm reachability to the 256 primary default gateway, then the host seeks to verify the cached 257 configuration by entering the INIT-REBOOT state, and sending a 258 DHCPREQUEST to the broadcast address as specified in [RFC2131] 259 Section 4.4.2. 261 If the host does not have a valid cached configuration, or had not 262 previously obtained a routable IPv4 address on the "most likely" 263 point of attachment, then the host enters the INIT state and sends a 264 DHCPDISCOVER packet to the broadcast address, as described in 265 [RFC2131] Section 4.4.1. If the host does not receive a response to 266 a DHCPREQUEST or DHCPDISCOVER, then it retransmits as specified in 267 [RFC2131] Section 4.1. 269 As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING 270 state that knows the address of a DHCP server may use that address in 271 the DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. 272 However, sending a DHCPREQUEST to the unicast address when in INIT- 273 REBOOT state is not appropriate since it is possible that the client 274 has moved to another subnet, and therefore the DHCPREQUEST needs to 275 be forwarded to and from the DHCP server by a DHCP Relay so that the 276 response can be broadcast. This ensures that the host will receive a 277 response regardless of whether the cached IP address is correct for 278 the network to which it has connected. 280 As described in [IPv4LL] Section 1.7, use of a routable address is 281 preferred to a Link-Local IPv4 address whenever it is available. 282 [RFC2131] Section 3.2 states that if the host possesses a valid 283 routable IPv4 address on the "most likely" network and does not 284 receive a response after employing the retransmission algorithm, the 285 client MAY choose to use the previously allocated network address and 286 configuration parameters for the remainder of the unexpired lease. 287 This is preferable to assigning a Link-Local IPv4 address if the host 288 has good reason to believe that it remains connected to a network on 289 which it possesses a valid IPv4 address lease. This would be the 290 case, for example, where a host has received hints that it believes 291 to be "strong". See Appendix A for details. 293 If the host does not have a valid IPv4 address lease on the "most 294 likely" network and does not receive a response after employing the 295 retransmission algorithm, it MAY assign a Link-Local IPv4 address. 296 Since a Link-Local IPv4 address is often configured because a DHCP 297 server failed to respond to an initial query or is inoperative for 298 some time, it is desirable to abandon the Link-Local IPv4 address 299 assignment as soon as a valid IPv4 address lease can be obtained. 301 Where a Link-Local IPv4 address is assigned, experience has shown 302 that five minutes (see [IPv4LL] Appendix A.2) is too long an interval 303 to wait until retrying to obtain a routable IPv4 address using DHCP. 304 According to [RFC2131] Section 4.1: 306 The retransmission delay SHOULD be doubled with 307 subsequent retransmissions up to a maximum of 64 seconds. 309 As a result, a DHCP client compliant with [RFC2131] will continue to 310 retry every 64 seconds, even after allocating a Link-Local IPv4 311 address. Should the DHCP client succeed in obtaining a routable 312 address, then as noted in [IPv4LL], the Link-Local IPv4 address is 313 deprecated. In order to avoid inappropriate assignment of an IPv4 314 Link-Local address, it is RECOMMENDED that such an address not be 315 assigned until the DHCP client has retransmitted at least 3 times. 317 3. IANA Considerations 319 Guidelines for IANA considerations are specified in [RFC2434]. This 320 specification does not request the creation of any new parameter 321 registries, nor does it require any other IANA assignments. 323 4. Security Considerations 325 Detection of Network Attachment (DNA) is typically insecure, so that 326 it is inadvisable for a host to adjust its security based on which 327 network it believes it is attached to. For example, it would be 328 inappropriate for a host to disable its personal firewall based on 329 the believe that it had connected to a home network. 331 ARP [RFC826] traffic is inherently insecure, so that the reachability 332 test described in Section 1.3 can be easily spoofed by an attacker, 333 leading a host to conclude that it remained attached to a former 334 network. Similarly, where DHCP [RFC2131] traffic is not secured, an 335 attacker could masquerade as a DHCP server, in order to convince the 336 host that it was attached to a particular network. 338 Where secure detection of network attachment is required, a host MAY 339 wish to skip the ARP-based reachability test entirely since it cannot 340 be secured, and go immediately to the IPv4 address acquisition phase, 341 utilizing authenticated DHCP [RFC3118]. 343 5. References 345 5.1. Normative References 347 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 348 USC/Information Sciences Institute, September 1981. 350 [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 351 Converting Network Addresses to 48-bit Ethernet Address for 352 Transmission on Ethernet Hardware", STD 37, RFC 826, November 353 1982. 355 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox 356 PARC, September 1991. 358 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", RFC 2119, March, 1997. 361 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 362 March 1997. 364 [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor 365 Extensions", RFC 2132, Silicon Graphics, Inc., Bucknell 366 University, March 1997. 368 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 369 Considerations Section in RFCs", BCP 26, RFC 2434, October 370 1998. 372 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 373 RFC 3118, June 2001. 375 [IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 376 of IPv4 Link-Local Addresses", Internet draft (work in 377 progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October 378 2003. 380 5.2. Informative References 382 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 383 51, RFC 1661, Daydreamer, July 1994. 385 [RFC1918] Rekhter, Y., et al., "Address Allocation for Private 386 Internets", RFC 1918, February 1996. 388 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication 389 Protocol (EAP)", RFC 2284, March 1998. 391 [RFC3580] Congdon, P., et al., "IEEE 802.1X Remote Authentication Dial 392 In User Service (RADIUS) Usage Guidelines", RFC 3580, 393 September 2003. 395 [IEEE8021AB] 396 IEEE Standards for Local and Metropolitan Area Networks: 397 Station and Media Access Control - Connectivity Discovery, 398 IEEE Std 802.1AB/D5, September 2003. 400 [IEEE8021X] 401 IEEE Standards for Local and Metropolitan Area Networks: Port 402 based Network Access Control, IEEE Std 802.1X-2001, June 2001. 404 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 405 Overview and Architecture, ANSI/IEEE Std 802, 1990. 407 [IEEE8021Q] 408 IEEE Standards for Local and Metropolitan Area Networks: Draft 409 Standard for Virtual Bridged Local Area Networks, P802.1Q, 410 January 1998. 412 [IEEE80211] 413 Information technology - Telecommunications and information 414 exchange between systems - Local and metropolitan area 415 networks - Specific Requirements Part 11: Wireless LAN Medium 416 Access Control (MAC) and Physical Layer (PHY) Specifications, 417 IEEE Std. 802.11-1999, 1999. 419 Acknowledgments 421 The authors would like to acknowledge Greg Daley of Monash 422 University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted 423 Lemon of Nominum and Thomas Narten of IBM for contributions to this 424 document. 426 Authors' Addresses 428 Bernard Aboba 429 Microsoft Corporation 430 One Microsoft Way 431 Redmond, WA 98052 433 EMail: bernarda@microsoft.com 434 Phone: +1 425 706 6605 435 Fax: +1 425 936 7329 437 Appendix A - Hints 439 In order to assist in IPv4 network attachment detection, information 440 associated with each network may be retained by the host. Based on 441 IP and link-layer information, the host may be able to make an 442 educated guess as to whether it has moved between subnets, or 443 remained on the same subnet. If it is likely to have moved between 444 subnets, the host may have an educated guess as to which subnet it 445 has moved to. The term "strong hint" refers to information which 446 provides an unambiguous indication of the network to which a host has 447 connected. "Weak hints" involve information which is inconclusive. 449 IPv4 ICMP Router Discovery messages [RFC1256] provide information 450 directly relevant to determining the network to which a host has 451 connected. As such, information gleaned from Router Advertisements 452 can be considered a "strong" hint. 454 For networks running over PPP [RFC1661], "weak" hints include the 455 link characteristics negotiated in LCP, and the associated phone 456 number. The IP parameters negotiated in IPCP are considered a 457 "strong" hint. 459 On IEEE 802 [IEEE802] wired networks, hints include link-layer 460 discovery traffic as well as information exchanged as part of IEEE 461 802.1X authentication [IEEE8021X]. Link-layer discovery traffic 462 includes Link Layer Discovery Protocol [IEEE8021AB] traffic as well 463 as network identification information passed in the EAP- 464 Request/Identity or within an EAP method exchange, as defined in EAP 465 [RFC2284]. 467 For example, LLDP advertisements can provide information on the IP 468 address or VLANs supported by the device. These hints, if provided, 469 are considered "strong". When used with IEEE 802.1X authentication 470 [IEEE8021X], the EAP-Request/Identity exchange may contain the name 471 of the authenticator, also providing information on the potential 472 network. Similarly, during the EAP method exchange the authenticator 473 may supply information that may be helpful in identifying the network 474 to which the device is attached. However, as noted in [RFC3580], it 475 is possible for the VLANID defined in [IEEE8021Q] to be assigned 476 dynamically, so this static information may not prove definitive. As 477 a result, these hints are considered "weak". 479 In IEEE 802.11 [IEEE80211] stations provide information in Beacon 480 and/or Probe Response messages, such as the SSID, BSSID, and 481 capabilities, as well as information on whether the station is 482 operating in Infrastructure or Adhoc mode. As described in 483 [RFC3580], it is possible to assign a Station to a VLAN dynamically, 484 based on the results of IEEE 802.1X [IEEE8021X] authentication. This 485 implies that a single SSID may offer access to multiple VLANs, and in 486 practice most large WLAN deployments offer access to multiple 487 subnets. 489 Thus, associating to the same SSID is a necessary, but not 490 necessarily a sufficient condition, for remaining within the same 491 subnet. While a Station associating to the same SSID may not 492 necessarily remain within the same subnet; on the other hand, a 493 Station associating to a different SSID is likely to have changed 494 subnets. 496 In order to provide additional guidance on the subnets to which a 497 given AP offers access, additional subnet-related Information 498 Elements (IEs) have been proposed for addition to the IEEE 802.11 499 Beacon and Probe Response messages. Such hints are considered 500 "strong"; all other IEEE 802.11 hints are considered "weak". 502 Intellectual Property 504 The IETF takes no position regarding the validity or scope of any 505 intellectual property or other rights that might be claimed to 506 pertain to the implementation or use of the technology described in 507 this document or the extent to which any license under such rights 508 might or might not be available; neither does it represent that it 509 has made any effort to identify any such rights. Information on the 510 IETF's procedures with respect to rights in standards-track and 511 standards-related documentation can be found in BCP-11. Copies of 512 claims of rights made available for publication and any assurances of 513 licenses to be made available, or the result of an attempt made to 514 obtain a general license or permission for the use of such 515 proprietary rights by implementors or users of this specification can 516 be obtained from the IETF Secretariat. 518 The IETF invites any interested party to bring to its attention any 519 copyrights, patents or patent applications, or other proprietary 520 rights which may cover technology that may be required to practice 521 this standard. Please address the information to the IETF Executive 522 Director. 524 Full Copyright Statement 526 Copyright (C) The Internet Society (2003). All Rights Reserved. 528 This document and translations of it may be copied and furnished to 529 others, and derivative works that comment on or otherwise explain it 530 or assist in its implementation may be prepared, copied, published 531 and distributed, in whole or in part, without restriction of any 532 kind, provided that the above copyright notice and this paragraph are 533 included on all such copies and derivative works. However, this 534 document itself may not be modified in any way, such as by removing 535 the copyright notice or references to the Internet Society or other 536 Internet organizations, except as needed for the purpose of 537 developing Internet standards in which case the procedures for 538 copyrights defined in the Internet Standards process must be 539 followed, or as required to translate it into languages other than 540 English. The limited permissions granted above are perpetual and 541 will not be revoked by the Internet Society or its successors or 542 assigns. This document and the information contained herein is 543 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 544 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 545 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 546 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 547 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 549 Open issues 551 Open issues relating to this specification are tracked on the 552 following web site: 554 http://www.drizzle.com/~aboba/DNA/dnaissues.html 556 Expiration Date 558 This memo is filed as , and expires 559 April 22, 2004.