idnits 2.17.1 draft-ietf-dhc-dna-ipv4-04.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 13 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 14 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 583 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 (21 October 2003) is 7492 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 171 -- Looks like a reference, but probably isn't: '2' on line 173 == 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) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DHC Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft Corporation 3 Category: Proposed Standard 4 5 21 October 2003 7 Detection of Network Attachment (DNA) in IPv4 9 This document is an Internet-Draft and is in full conformance with all 10 provisions of Section 10 of RFC 2026. 12 Internet-Drafts are working documents of the Internet Engineering Task 13 Force (IETF), its areas, and its working groups. Note that other groups 14 may also distribute working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference material 19 or to cite them other than as "work in progress." 21 The list of current Internet-Drafts can be accessed at 22 http://www.ietf.org/ietf/1id-abstracts.txt 24 The list of Internet-Draft Shadow Directories can be accessed at 25 http://www.ietf.org/shadow.html. 27 Copyright Notice 29 Copyright (C) The Internet Society (2003). All Rights Reserved. 31 Abstract 33 The time required to detect movement (or lack of movement) between 34 subnets, and to obtain (or continue to use) a valid IPv4 address may 35 be significant as a fraction of the total delay in moving between 36 points of attachment. This specification synthesizes experience 37 garnered over the years in the deployment of hosts supporting ARP, 38 DHCP and IPv4 Link-Local addresses, in order to optimize detection of 39 network attachment by mobile hosts. 41 Table of Contents 43 1. Introduction.............................................. 3 44 1.1 Requirements .................................... 4 45 1.2 Terminology ..................................... 4 46 2. Framework ................................................ 5 47 2.1 Reachability test ............................... 5 48 2.2 Packet format ................................... 6 49 2.3 IPv4 Address Acquisition ........................ 7 50 3. Constants ................................................ 8 51 4. IANA Considerations ...................................... 9 52 5. Security Considerations .................................. 9 53 6. References ............................................... 9 54 6.1 Normative references ............................ 9 55 6.2 Informative references .......................... 10 56 Acknowledgments .............................................. 11 57 Authors' Addresses ........................................... 11 58 Appendix A - Hints ........................................... 12 59 Intellectual Property Statement .............................. 13 60 Full Copyright Statement ..................................... 13 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 ar$sha 129 ARP packet field: Source Hardware Address [RFC826]. The hardware 130 (MAC) address of the originator of an ARP packet. 132 ar$spa 133 ARP packet field: Source Protocol Address [RFC826]. For IP Address 134 Resolution this is the IP Address of the sender of the ARP packet. 135 If the sender address is unknown, this is set to 0.0.0.0. 137 ar$tha 138 ARP packet field: Target Hardware Address [RFC826]. The hardware 139 (MAC) address of the target of an ARP packet, or the broadcast 140 address if the target hardware address is unknown. 142 ar$tpa 143 ARP packet field: Target Protocol Address [RFC826]. For IP Address 144 Resolution, the IP address for which one desires to know the 145 hardware address. 147 DHCP client 148 A DHCP client or "client" is an Internet host using DHCP to obtain 149 configuration parameters such as a network address. 151 DHCP server 152 A DHCP server or "server" is an Internet host that returns 153 configuration parameters to DHCP clients. 155 Routable address 156 In this specification, the term "routable address" refers to any 157 address other than an IPv4 Link-Local address. This includes 158 private addresses as specified in [RFC1918]. 160 2. Framework 162 On connecting to a new point of attachment, the host attempts to 163 determine the "most likely" configuration associated with the new 164 point of attachment. 166 In order to determine the "most likely" point of attachment it is 167 assumed that the host is capable of obtaining and writing to stable 168 storage parameters relating to networks that it connects to, 169 including: 171 [1] IP and link layer hints associated with each network. For 172 details, see Appendix A. 173 [2] The IP and MAC address of the primary default gateway on 174 each network. 176 By matching the received hints against information previously 177 collected, the host may be able to make an educated guess of which 178 network it has attached to. Where no additional information is 179 available, by default the host assumes that the "most likely" point 180 of attachment is the network to which it was most recently connected. 182 If the host has a valid routable IPv4 address on the "most likely" 183 point of attachment, the host performs a reachability test as 184 described below. If the reachability test is not successful, or if 185 the host does not have a valid routable IPv4 address on the "most 186 likely" point of attachment, the host proceeds to the IPv4 address 187 acquisition phase. 189 2.1. Reachability Test 191 The purpose of the reachability test is to determine whether the host 192 is connected to a network on which it had previously obtained a still 193 valid routable IPv4 address. The test is performed by attempting to 194 verify reachability of a previously configured primary default 195 gateway on a former point of attachment. If the test is successful, 196 the host may continue to use a valid routable IPv4 address without 197 having to re-acquire it. This reduces roaming latency by allowing 198 the host to bypass the DHCP exchange as well as subsequent Duplicate 199 Address Detection (DAD). In contrast to a DHCP exchange, which may 200 be between a DHCP client and an offlink DHCP server, the reachability 201 test occurs between a host and its next hop router. 203 The host skips the reachability test and proceeds to the address 204 acquisition phase in the following circumstances: 206 [a] If the host does not have information on the default 207 gateway on the network. 208 [b] If the host does not have a valid routable IPv4 address 209 on the network. A Link-Local IPv4 address does not 210 count as a valid routable IPv4 address. 212 2.2. Packet Format 214 To perform the reachability test, an ARP Request SHOULD be sent, 215 using the host's MAC address as the source, and the broadcast MAC 216 address as the destination. The host sets the target protocol 217 address (ar$tpa) to the IPv4 address of the primary default gateway, 218 and uses its own MAC address in the sender hardware address field 219 (ar$sha). The host sets the target hardware address field (ar$tha) 220 to 0. 222 If the host has a valid globally routable IP address on the most 223 likely point of attachment, then it SHOULD set the sender protocol 224 address field (ar$spa) to that address. It is assumed that the host 225 had previously done duplicate address detection so that an address 226 conflict is unlikely. 228 However if the host has a private address as defined in [RFC1918], 229 then it SHOULD set the sender protocol address field (ar$spa) to the 230 unspecified address (0.0.0.0). This is to avoid an address conflict 231 in the case where the host has changed its point of attachment from 232 one private network to another. 234 Note: Some routers may refuse to answer an ARP Request sent with 235 the sender protocol address field (ar$spa) set to the unspecified 236 address (0.0.0.0). In this case the reachability test will fail. 238 If a valid ARP Response is received, the MAC address in the sender 239 hardware address field (ar$sha) and the IPv4 address in the sender 240 protocol address field (ar$spa) are matched against the list of 241 networks and associated default gateway parameters. If a match is 242 found, then if the host has a valid IPv4 address lease on the 243 matched network, the host continues to use that IPv4 address, subject 244 to the lease re-acquisition and expiration behavior described in 245 [RFC2131], Section 4.4.5. 247 Checking for a match on both the IPv4 and MAC addresses of the 248 default gateway allows the host to confirm reachability even where 249 the host moves between two private networks. In this case the IPv4 250 address of the default gateway could remain the same, while the MAC 251 address would change, so that both addresses need to be checked. 253 Sending an ICMP Echo Request [RFC792] to the default gateway IPv4 254 address does not provide the same level of assurance since this 255 requires an ARP Request/Response to be sent first, and typically does 256 not allow the MAC address to be checked as well. It therefore SHOULD 257 NOT be used as a substitute. Where a host moves from one private 258 network to another, an ICMP Echo Request can result in an ICMP Echo 259 Response even when the default gateway has changed, as long as the 260 IPv4 address remains the same. This can occur, for example, where a 261 host moves from one home network using prefix 192.168/16 to another 262 one. In addition, if the ping is sent with TTL > 1, then an ICMP 263 Echo Response can be received from an off-link gateway. 265 If the initial ARP Request does not elicit a Response, the host waits 266 for REACHABILITY_TIMER and then sends another ARP Request. If no ARP 267 Response is received in response to this second Request, the host 268 proceeds to the IPv4 address acquisition phase. If a valid ARP 269 Response is received, but cannot be matched against known networks, 270 the host assumes it has moved subnets and moves on to the address 271 acquisition phase. 273 2.3. IPv4 Address Acquisition 275 If the host has a valid cached configuration on the "most likely" 276 point of attachment, but is unable to confirm reachability to the 277 primary default gateway, then the host seeks to verify the cached 278 configuration by entering the INIT-REBOOT state, and sending a 279 DHCPREQUEST to the broadcast address as specified in [RFC2131] 280 Section 4.4.2. 282 If the host does not have a valid cached configuration, or had not 283 previously obtained a routable IPv4 address on the "most likely" 284 point of attachment, then the host enters the INIT state and sends a 285 DHCPDISCOVER packet to the broadcast address, as described in 286 [RFC2131] Section 4.4.1. If the host does not receive a response to 287 a DHCPREQUEST or DHCPDISCOVER, then it retransmits as specified in 288 [RFC2131] Section 4.1. 290 As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING 291 state that knows the address of a DHCP server may use that address in 292 the DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. 293 In the INIT-REBOOT state a DHCPREQUEST is sent to the broadcast 294 address so that the host will receive a response regardless of 295 whether the cached IP address is correct for the network to which it 296 has connected. 298 Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is 299 not appropriate since if the client has moved to another subnet, a 300 DHCP server response cannot be routed back to the client since the 301 DHCPREQUEST will bypass the DHCP relay and will contain an invalid 302 source address. 304 As described in [IPv4LL] Section 1.7, use of a routable address is 305 preferred to a Link-Local IPv4 address whenever it is available. 306 [RFC2131] Section 3.2 states that if the host possesses a valid 307 routable IPv4 address on the "most likely" network and does not 308 receive a response after employing the retransmission algorithm, the 309 client MAY choose to use the previously allocated network address and 310 configuration parameters for the remainder of the unexpired lease. 311 This is preferable to assigning a Link-Local IPv4 address if the host 312 has good reason to believe that it remains connected to a network on 313 which it possesses a valid IPv4 address lease. This would be the 314 case, for example, where a host has received hints that it believes 315 to be "strong". See Appendix A for details. 317 If the host does not have a valid IPv4 address lease on the "most 318 likely" network and does not receive a response after employing the 319 retransmission algorithm, it MAY assign a Link-Local IPv4 address. 320 Since a Link-Local IPv4 address is often configured because a DHCP 321 server failed to respond to an initial query or is inoperative for 322 some time, it is desirable to abandon the Link-Local IPv4 address 323 assignment as soon as a valid IPv4 address lease can be obtained. 325 Where a Link-Local IPv4 address is assigned, experience has shown 326 that five minutes (see [IPv4LL] Appendix A.2) is too long an interval 327 to wait until retrying to obtain a routable IPv4 address using DHCP. 328 According to [RFC2131] Section 4.1: 330 The retransmission delay SHOULD be doubled with 331 subsequent retransmissions up to a maximum of 64 seconds. 333 As a result, a DHCP client compliant with [RFC2131] will continue to 334 retry every 64 seconds, even after allocating a Link-Local IPv4 335 address. Should the DHCP client succeed in obtaining a routable 336 address, then as noted in [IPv4LL], the Link-Local IPv4 address is 337 deprecated. In order to avoid inappropriate assignment of an IPv4 338 Link-Local address, it is RECOMMENDED that such an address not be 339 assigned until the DHCP client has retransmitted at least 3 times. 341 3. Constants 343 The suggested default value of REACHABILITY_TIMER is 200 ms. This value 344 was chosen so as to accomodate the maximum retransmission timer likely 345 to be experienced on an Ethernet network. 347 4. IANA Considerations 349 Guidelines for IANA considerations are specified in [RFC2434]. This 350 specification does not request the creation of any new parameter 351 registries, nor does it require any other IANA assignments. 353 5. Security Considerations 355 Detection of Network Attachment (DNA) is typically insecure, so that 356 it is inadvisable for a host to adjust its security based on which 357 network it believes it is attached to. For example, it would be 358 inappropriate for a host to disable its personal firewall based on 359 the belief that it had connected to a home network. 361 ARP [RFC826] traffic is inherently insecure, so that the reachability 362 test described in Section 1.3 can be easily spoofed by an attacker, 363 leading a host to conclude that it remained attached to a former 364 network. Similarly, where DHCP [RFC2131] traffic is not secured, an 365 attacker could masquerade as a DHCP server, in order to convince the 366 host that it was attached to a particular network. 368 Where secure detection of network attachment is required, a host MAY 369 wish to skip the ARP-based reachability test entirely since it cannot 370 be secured, and go immediately to the IPv4 address acquisition phase, 371 utilizing authenticated DHCP [RFC3118]. 373 6. References 375 6.1. Normative References 377 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 378 USC/Information Sciences Institute, September 1981. 380 [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 381 Converting Network Addresses to 48-bit Ethernet Address for 382 Transmission on Ethernet Hardware", STD 37, RFC 826, November 383 1982. 385 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox 386 PARC, September 1991. 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", RFC 2119, March, 1997. 391 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 392 March 1997. 394 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", 395 RFC 3118, June 2001. 397 [IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration 398 of IPv4 Link-Local Addresses", Internet draft (work in 399 progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October 400 2003. 402 6.2. Informative References 404 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD 405 51, RFC 1661, Daydreamer, July 1994. 407 [RFC1918] Rekhter, Y., et al., "Address Allocation for Private 408 Internets", RFC 1918, February 1996. 410 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication 411 Protocol (EAP)", RFC 2284, March 1998. 413 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA 414 Considerations Section in RFCs", BCP 26, RFC 2434, October 415 1998. 417 [RFC3580] Congdon, P., et al., "IEEE 802.1X Remote Authentication Dial 418 In User Service (RADIUS) Usage Guidelines", RFC 3580, 419 September 2003. 421 [IEEE8021AB] 422 IEEE Standards for Local and Metropolitan Area Networks: 423 Station and Media Access Control - Connectivity Discovery, 424 IEEE Std 802.1AB/D5, September 2003. 426 [IEEE8021X] 427 IEEE Standards for Local and Metropolitan Area Networks: Port 428 based Network Access Control, IEEE Std 802.1X-2001, June 2001. 430 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 431 Overview and Architecture, ANSI/IEEE Std 802, 1990. 433 [IEEE8021Q] 434 IEEE Standards for Local and Metropolitan Area Networks: Draft 435 Standard for Virtual Bridged Local Area Networks, P802.1Q, 436 January 1998. 438 [IEEE80211] 439 Information technology - Telecommunications and information 440 exchange between systems - Local and metropolitan area 441 networks - Specific Requirements Part 11: Wireless LAN Medium 442 Access Control (MAC) and Physical Layer (PHY) Specifications, 443 IEEE Std. 802.11-1999, 1999. 445 Acknowledgments 447 The authors would like to acknowledge Greg Daley of Monash 448 University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted 449 Lemon of Nominum and Thomas Narten of IBM for contributions to this 450 document. 452 Authors' Addresses 454 Bernard Aboba 455 Microsoft Corporation 456 One Microsoft Way 457 Redmond, WA 98052 459 EMail: bernarda@microsoft.com 460 Phone: +1 425 706 6605 461 Fax: +1 425 936 7329 463 Appendix A - Hints 465 In order to assist in IPv4 network attachment detection, information 466 associated with each network may be retained by the host. Based on 467 IP and link-layer information, the host may be able to make an 468 educated guess as to whether it has moved between subnets, or 469 remained on the same subnet. If it is likely to have moved between 470 subnets, the host may have an educated guess as to which subnet it 471 has moved to. The term "strong hint" refers to information which 472 provides an unambiguous indication of the network to which a host has 473 connected. "Weak hints" involve information which is inconclusive. 475 IPv4 ICMP Router Discovery messages [RFC1256] provide information 476 directly relevant to determining the network to which a host has 477 connected. As such, information gleaned from Router Advertisements 478 can be considered a "strong" hint. 480 For networks running over PPP [RFC1661], "weak" hints include the 481 link characteristics negotiated in LCP, and the associated phone 482 number. The IP parameters negotiated in IPCP are considered a 483 "strong" hint. 485 On IEEE 802 [IEEE802] wired networks, hints include link-layer 486 discovery traffic as well as information exchanged as part of IEEE 487 802.1X authentication [IEEE8021X]. Link-layer discovery traffic 488 includes Link Layer Discovery Protocol (LLDP) [IEEE8021AB] traffic as 489 well as network identification information passed in the EAP- 490 Request/Identity or within an EAP method exchange, as defined in EAP 491 [RFC2284]. 493 For example, LLDP advertisements can provide information on the IP 494 address or VLANs supported by the device. These hints, if provided, 495 are considered "strong". When used with IEEE 802.1X authentication 496 [IEEE8021X], the EAP-Request/Identity exchange may contain the name 497 of the authenticator, also providing information on the potential 498 network. Similarly, during the EAP method exchange the authenticator 499 may supply information that may be helpful in identifying the network 500 to which the device is attached. However, as noted in [RFC3580], it 501 is possible for the VLANID defined in [IEEE8021Q] to be assigned 502 dynamically, so this static information may not prove definitive. As 503 a result, these hints are considered "weak". 505 In IEEE 802.11 [IEEE80211] stations provide information in Beacon 506 and/or Probe Response messages, such as the SSID, BSSID, and 507 capabilities, as well as information on whether the station is 508 operating in Infrastructure or Adhoc mode. As described in 509 [RFC3580], it is possible to assign a Station to a VLAN dynamically, 510 based on the results of IEEE 802.1X [IEEE8021X] authentication. This 511 implies that a single SSID may offer access to multiple VLANs, and in 512 practice most large WLAN deployments offer access to multiple 513 subnets. 515 Thus, associating to the same SSID is a necessary, but not 516 necessarily a sufficient condition, for remaining within the same 517 subnet: while a Station associating to the same SSID may not 518 necessarily remain within the same subnet, a Station associating to a 519 different SSID is likely to have changed subnets. 521 In order to provide additional guidance on the subnets to which a 522 given AP offers access, additional subnet-related Information 523 Elements (IEs) have been proposed for addition to the IEEE 802.11 524 Beacon and Probe Response messages. Such hints are considered 525 "strong"; all other IEEE 802.11 hints are considered "weak". 527 Intellectual Property 529 The IETF takes no position regarding the validity or scope of any 530 intellectual property or other rights that might be claimed to 531 pertain to the implementation or use of the technology described in 532 this document or the extent to which any license under such rights 533 might or might not be available; neither does it represent that it 534 has made any effort to identify any such rights. Information on the 535 IETF's procedures with respect to rights in standards-track and 536 standards-related documentation can be found in BCP-11. Copies of 537 claims of rights made available for publication and any assurances of 538 licenses to be made available, or the result of an attempt made to 539 obtain a general license or permission for the use of such 540 proprietary rights by implementors or users of this specification can 541 be obtained from the IETF Secretariat. 543 The IETF invites any interested party to bring to its attention any 544 copyrights, patents or patent applications, or other proprietary 545 rights which may cover technology that may be required to practice 546 this standard. Please address the information to the IETF Executive 547 Director. 549 Full Copyright Statement 551 Copyright (C) The Internet Society (2003). All Rights Reserved. 553 This document and translations of it may be copied and furnished to 554 others, and derivative works that comment on or otherwise explain it 555 or assist in its implementation may be prepared, copied, published 556 and distributed, in whole or in part, without restriction of any 557 kind, provided that the above copyright notice and this paragraph are 558 included on all such copies and derivative works. However, this 559 document itself may not be modified in any way, such as by removing 560 the copyright notice or references to the Internet Society or other 561 Internet organizations, except as needed for the purpose of 562 developing Internet standards in which case the procedures for 563 copyrights defined in the Internet Standards process must be 564 followed, or as required to translate it into languages other than 565 English. The limited permissions granted above are perpetual and 566 will not be revoked by the Internet Society or its successors or 567 assigns. This document and the information contained herein is 568 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 569 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 570 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 571 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 572 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 574 Open issues 576 Open issues relating to this specification are tracked on the 577 following web site: 579 http://www.drizzle.com/~aboba/DNA/dnaissues.html 581 Expiration Date 583 This memo is filed as , and expires 584 April 22, 2004.