idnits 2.17.1 draft-ietf-dhc-dna-ipv4-01.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 503 has weird spacing: '...imed to perta...' == Line 555 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 (11 September 2003) is 7532 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) -- Looks like a reference, but probably isn't: '1' on line 161 -- Looks like a reference, but probably isn't: '2' on line 164 == Missing Reference: 'LLDP' is mentioned on line 468, but not defined == Missing Reference: 'Congdon' is mentioned on line 483, but not defined == Unused Reference: 'RFC791' is defined on line 337, but no explicit reference was found in the text == Unused Reference: 'RFC792' is defined on line 340, but no explicit reference was found in the text == Unused Reference: 'RFC2132' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RFC2434' is defined on line 361, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 375, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 379, but no explicit reference was found in the text == Unused Reference: 'RFC1058' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'RFC1332' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'RFC1877' is defined on line 392, but no explicit reference was found in the text == Unused Reference: 'RFC2284' is defined on line 399, but no explicit reference was found in the text == Unused Reference: 'IEEE8021Q' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'IEEE8023' is defined on line 413, 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-09 -- Obsolete informational reference (is this intentional?): RFC 2284 (Obsoleted by RFC 3748) Summary: 3 errors (**), 0 flaws (~~), 20 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: Best Current Practice 5 6 11 September 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 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 detection of network attachment in IPv4 as well as 38 heuristics for determining when assignment of an IPv4 Link-Local address 39 is appropriate. 41 Table of Contents 43 1. Introduction.............................................. 3 44 1.1 Requirements .................................... 3 45 1.2 Terminology ..................................... 3 46 2. Framework ................................................ 4 47 2.1 Most Likely Point of Attachment ................. 4 48 2.2 Reachability test ............................... 5 49 2.3 IPv4 Address Acquisition ........................ 6 50 3. Constants ................................................ 8 51 4. IANA Considerations ...................................... 8 52 5. Security Considerations .................................. 8 53 6. References ............................................... 8 54 6.1 Normative references ............................ 8 55 6.2 Informative references .......................... 9 56 Acknowledgments .............................................. 10 57 Authors' Addresses ........................................... 10 58 Appendix A - Hints ........................................... 12 59 Intellectual Property Statement .............................. 13 60 Full Copyright Statement ..................................... 13 61 1. Introduction 63 This draft attempts to synthesize experience garnered over the years in 64 the deployment of hosts supporting ARP [RFC826], DHCP [RFC2131], and 65 Link-Local IPv4 addresses [IPv4LL]. Experience has indicated the 66 importance of several goals in detection of network attachment: 68 [a] Avoiding inappropriate assignment of Link-Local IPv4 addresses. 69 Experience has shown that in the vast majority of cases, the 70 assignment of Link-Local IPv4 addresses is inappropriate. That 71 is, the IPv4 host assigning an Link-Local IPv4 address either 72 is not connected to a network at all, in which case assignment 73 of an Link-Local IPv4 address does no good; or the host is in 74 fact present on a network with a DHCPv4 server but for one 75 reason or another does not receive a response to a DHCPREQUEST 76 or DHCPDISCOVER. 78 [b] Latency Optimization. The time required to detect movement (or 79 lack of movement) between subnets, and to obtain (or continue to 80 use) a valid IPv4 address represents a significant fraction of 81 the overall latency resulting from movement between points of 82 attachment on the network. As a result, optimization of 83 detection of network attachment in IPv4 hosts is helpful, to the 84 extent that it is achievable. 86 In order to achieve these goals, this document specifies 87 procedures conducted on connection to a network. On 88 disconnection from a network, there is no need to take action 89 until the host is reconnected, since it is typically not 90 possible for a host to communicate until it has obtained 91 connectivity. Therefore, contrary to [RFC2131] Section 3.7, no 92 action need be taken on network disconnection. 94 1.1. Requirements 96 In this document, several words are used to signify the requirements of 97 the specification. These words are often capitalized. The key words 98 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 99 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 100 interpreted as described in [RFC2119]. 102 1.2. Terminology 104 This document uses the following terms: 106 DHCP client 107 A DHCP client or "client" is an Internet host using DHCP to 108 obtain configuration parameters such as a network address. 110 DHCP server 111 A DHCP server or "server" is an Internet host that returns 112 configuration parameters to DHCP clients. 114 Routable address 115 In this specification, the term "routable address" refers to any 116 address other than an IPv4 Link-Local address. This includes 117 private addresses as specified in [RFC1918]. 119 2. Framework 121 This document specifies a procedure to be performed for IPv4 network 122 attachment detection that depends on three phases: determination of the 123 "most likely" point of attachment, a reachability test phase, and an 124 IPv4 address acquisition phase. 126 The following basic principles are suggested: 128 [1] Utilization of link layer hints. Link layers such as IEEE 802 129 [IEEE802] provide hints about whether a host remains on the same 130 subnet despite changing its point of attachment, or even whether 131 the host is connected to an adhoc or infrastructure network. 132 Where available, these hints can be used to guide host behavior 133 - with the understanding that they are not infallible and 134 therefore that the host should be capable of making the correct 135 determination even in the presence of misleading hints. Link 136 layer hints are described in more detail in Appendix A. 138 [2] Link-Local IPv4 addressing as a mechanism of last resort. In 139 existing implementations of [IPv4LL], once a Link-Local IPv4 140 address is assigned, the DHCPv4 server may not be queried again 141 for 5 minutes. As a result, the inappropriate assignment of a 142 Link-Local IPv4 address results in an extended period of limited 143 connectivity. For a host that may change its point of 144 attachment more frequently than every 5 minutes, the 145 inappropriate assignment of an Link-Local IPv4 address is more 146 than just an annoyance - it can result in an ongoing inability 147 to connect. As a result, this document suggests that hosts 148 behave conservatively with respect to assignment of Link-Local 149 IPv4 addresses, using them only as a last resort. 151 2.1. Most Likely Point of Attachment 153 On connecting to a new point of attachment, the host attempts to 154 determine the "most likely" configuration associated with the new point 155 of attachment. 157 In order to determine the "most likely" point of attachment it is 158 assumed that the host is capable of obtaining and writing to stable 159 storage parameters relating to networks that it connects to, including: 161 [1] IP and link layer hints associated with each network. For 162 details, see Appendix A. 164 [2] The IP and MAC address of default gateway(s) on each network. 166 By matching the received hints against information previously 167 collected, the host may be able to make an educated guess of 168 which network it has attached to. Where no additional 169 information is available, by default the host assumes that the 170 "most likely" point of attachment is the network to which it was 171 most recently connected. 173 If the host has a valid routable IPv4 address on the "most 174 likely" point of attachment, the host performs a reachability 175 test as described below. If the reachability test is not 176 successful, or if the host does not have a valid routable IPv4 177 address on the "most likely" point of attachment, the host 178 proceeds to the IPv4 address acquisition phase. 180 2.2. Reachability Test 182 The purpose of the reachability test is for the host to quickly 183 determine whether it is connected to a network on which it had 184 previously obtained a still valid routable IPv4 address. The test is 185 performed by attempting to verify reachability of a previously 186 configured primary default gateway on a former point of attachment. If 187 the test is successful, the host may continue to use a valid routable 188 IPv4 address without having to re-acquire it. 190 The host skips the reachability test and proceeds to the address 191 acquisition phase in the following circumstances: 193 [a] If the host does not have information on the default gateway on 194 the network. 196 [b] If the host does not have a valid routable IPv4 address on the 197 network. Since Link-Local IPv4 addresses are a last resort, 198 these addresses do not count as a valid routable IPv4 address. 200 2.2.1. Packet Format 202 To perform the reachability test, an ARP Request SHOULD be sent, using 203 the host's MAC address as the source, and the broadcast MAC address as 204 the destination. The host sets the target protocol address (ar$tpa) to 205 the IPv4 address of the primary default gateway, and uses its own MAC 206 address in the sender hardware address field (ar$sha). Since the host 207 has not yet confirmed the subnet on which it is attached, it MUST set 208 the sender protocol address field (ar$spa) to 0.0.0.0. This prevents 209 poisoning of the ARP cache with a (potentially invalid) sender IPv4 210 address. 212 If a valid ARP Response is received, the MAC address in the target 213 hardware address field (ar$tha) and the IPv4 address in the target 214 protocol address field (ar$tpa) are matched against the list of networks 215 and associated default gateway parameters. If a match is found, then 216 if the host has a valid IPv4 address lease on the matched network, the 217 host continues to use that IPv4 address, subject to the lease re- 218 acquisition and expiration behavior described in [RFC2131], Section 219 4.4.5. 221 Checking for a match on both the IPv4 and MAC addresses of the default 222 gateway allows the host to confirm reachability even where the host 223 moves between two private networks. In this case the IPv4 address of 224 the default gateway could remain the same, while the MAC address would 225 change, so that both addresses need to be checked. 227 Sending an ICMP Echo Request to the default gateway IPv4 address does 228 not provide the same level of assurance since this requires an ARP 229 Request/Response to be sent first, and typically does not allow the MAC 230 address to be checked as well. It therefore SHOULD NOT be used as a 231 substitute. Where a host moves from one private network to another, an 232 ICMP Echo Request can result in an ICMP Echo Response even when the 233 default gateway has changed, as long as the IPv4 address remains the 234 same. This can occur, for example, where a host moves from one home 235 network using prefix 192.168/16 to another one. In addition, if the 236 ping is sent with TTL > 1, then an ICMP Echo Response can be received 237 from an off-link gateway. 239 If the initial ARP Request does not elicit a Response, the host waits 240 200ms and then sends another ARP Request. If no ARP Response is 241 received in response to this second Request, the host proceeds to the 242 IPv4 address acquisition phase. If a valid ARP Response is received, 243 but cannot be matched against known networks, the host assumes it has 244 moved subnets and moves on to the address acquisition phase. 246 2.3. IPv4 Address Acquisition 248 If the host has a valid cached configuration on the "most likely" point 249 of attachment, but is unable to confirm reachability to the primary 250 default gateway, then the host seeks to verify the cached configuration 251 by entering the INIT-REBOOT state, and sending a DHCPREQUEST to the 252 broadcast address as specified in [RFC2131] Section 4.4.2. 254 If the host does not have a valid cached configuration, or had not 255 previously obtained a routable IPv4 address on the "most likely" point 256 of attachment, then the host enters the INIT state and sends a 257 DHCPDISCOVER packet to the broadcast address, as described in [RFC2131] 258 Section 4.4.1. If the host does not receive a response to a DHCPREQUEST 259 or DHCPDISCOVER, then it retransmits as specified in [RFC2131] Section 260 4.1. 262 As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING 263 state that knows the address of a DHCP server may use that address in 264 the DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. 265 However, sending a DHCPREQUEST to the unicast address when in INIT- 266 REBOOT state is not appropriate since it is possible that the client has 267 moved to another subnet, and therefore the DHCPREQUEST needs to be 268 forwarded to and from the DHCP server by a DHCP Relay so that the 269 response can be broadcast. This ensures that the host will receive a 270 response regardless of whether the cached IP address is correct for the 271 network to which it has connected. 273 As described in [IPv4LL] Section 1.7, use of a routable address is 274 preferred to use of a Link-Local IPv4 address. [RFC2131] Section 3.2 275 states that if the host possesses a valid routable IPv4 address on the 276 "most likely" network and does not receive a response after employing 277 the retransmission algorithm, the client MAY choose to use the 278 previously allocated network address and configuration parameters for 279 the remainder of the unexpired lease. This is preferable to assigning a 280 Link-Local IPv4 address if the host has good reason to believe that it 281 remains connected to a network on which it possesses a valid IPv4 282 address lease. This would be the case, for example, where a host has 283 received "hints" that it believes to be "strong". See Appendix A for 284 details. 286 If the host does not have a valid IPv4 address lease on the "most 287 likely" network and does not receive a response after employing the 288 retransmission algorithm, it MAY assign a Link-Local IPv4 address. 289 Since a Link-Local IPv4 address is often configured because a DHCP 290 server failed to respond to an initial query or is inoperative for some 291 time, it is desirable to abandon the Link-Local IPv4 address assignment 292 as soon as a valid IPv4 address lease can be obtained. 294 Where a Link-Local IPv4 address is assigned, experience has shown that 295 five minutes (see [IPv4LL] Appendix A.2) was too long an interval to 296 wait and try to obtain a routable IPv4 address via DHCP. A host which 297 has been configured with a Link-Local IPv4 address SHOULD periodically 298 attempt to obtain a routable IPv4 address via DHCP. The recommended 299 policy is to attempt to obtain an address via DHCP after waiting for 300 RECONF_INTERVAL, plus a random number of seconds, uniformly distributed, 301 between zero to RECONF_JITTER seconds. 303 3. Constants 305 RECONF_INTERVAL 30 seconds 306 RECONF_JITTER 10 seconds 308 4. IANA Considerations 310 This specification does not request the creation of any new parameter 311 registries, not does it require any other IANA assignments 313 5. Security Considerations 315 Detection of Network Attachment (DNA) is typically insecure, so that it 316 is inadvisable for a host to adjust its security based on which network 317 it believes it is attached to. For example, it would be inappropriate 318 for a host to disable its personal firewall based on the believe that it 319 had connected to a home network. 321 ARP [RFC826] traffic is inherently insecure, so that the reachability 322 test described in Section 1.3 can be easily spoofed by an attacker, 323 leading a host to conclude that it remained attached to a former 324 network. Similarly, where DHCP [RFC2131] traffic is not secured, an 325 attacker could masquerade as a DHCP server, in order to convince the 326 host that it was attached to a particular network. 328 Where secure detection of network attachment is required, a host MAY 329 wish to skip the ARP-based reachability test entirely since it cannot be 330 secured, and go immediately to the IPv4 address acquisition phase, 331 utilizing authenticated DHCP [RFC3118]. 333 6. References 335 6.1. Normative References 337 [RFC791] Postel, J., "Internet Protocol", RFC 791, USC/Information 338 Sciences Institute, September 1981. 340 [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, 341 USC/Information Sciences Institute, September 1981. 343 [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- 344 Converting Network Addresses to 48-bit Ethernet Address 345 for Transmission on Ethernet Hardware", STD 37, RFC 826, 346 November 1982. 348 [RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, 349 Xerox PARC, September 1991. 351 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 352 Requirement Levels", RFC 2119, March, 1997. 354 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 355 2131, March 1997. 357 [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP 358 Vendor Extensions", RFC 2132, Silicon Graphics, Inc., 359 Bucknell University, March 1997. 361 [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an 362 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 363 October 1998. 365 [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP 366 Messages", RFC 3118, June 2001. 368 [IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic 369 Configuration of IPv4 Link-Local Addresses", Internet 370 draft (work in progress), draft-ietf-zeroconf- 371 ipv4-linklocal-09.txt, September 2003. 373 6.2. Informative References 375 [RFC1034] Mockapetris, P., "Domain Names - Concepts and 376 Facilities", STD 13, RFC 1034, USC/Information Sciences 377 Institute, November 1987. 379 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 380 Specification", STD 13, RFC 1035, USC/Information 381 Sciences Institute, November 1987. 383 [RFC1058] Hedrick, C.L., "Routing Information Protocol", RFC 1058, 384 Rutgers University, June 1, 1988. 386 [RFC1332] McGregor, G., "PPP Internet Control Protocol", RFC 1332, 387 Merit, May 1992. 389 [RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", 390 STD 51, RFC 1661, Daydreamer, July 1994. 392 [RFC1877] Cobb, S., "PPP Internet Protocol Control Protocol 393 Extensions for Name Server Addresses", RFC 1877, December 394 1995. 396 [RFC1918] Rekhter, Y., et al., "Address Allocation for Private 397 Internets", RFC 1918, February 1996. 399 [RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible 400 Authentication Protocol (EAP)", RFC 2284, March 1998. 402 [IEEE8021X] IEEE Standards for Local and Metropolitan Area Networks: 403 Port based Network Access Control, IEEE Std 802.1X-2001, 404 June 2001. 406 [IEEE802] IEEE Standards for Local and Metropolitan Area Networks: 407 Overview and Architecture, ANSI/IEEE Std 802, 1990. 409 [IEEE8021Q] IEEE Standards for Local and Metropolitan Area Networks: 410 Draft Standard for Virtual Bridged Local Area Networks, 411 P802.1Q, January 1998. 413 [IEEE8023] ISO/IEC 8802-3 Information technology - 414 Telecommunications and information exchange between 415 systems - Local and metropolitan area networks - Common 416 specifications - Part 3: Carrier Sense Multiple Access 417 with Collision Detection (CSMA/CD) Access Method and 418 Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 419 1996), 1996. 421 [IEEE80211] Information technology - Telecommunications and 422 information exchange between systems - Local and 423 metropolitan area networks - Specific Requirements Part 424 11: Wireless LAN Medium Access Control (MAC) and 425 Physical Layer (PHY) Specifications, IEEE Std. 426 802.11-1999, 1999. 428 Acknowledgments 430 The authors would like to acknowledge Erik Guttman and Erik Nordmark of 431 Sun Microsystems, Ted Lemon of Nominum and Thomas Narten of IBM for 432 contributions to this document. 434 Authors' Addresses 436 Bernard Aboba 437 Microsoft Corporation 438 One Microsoft Way 439 Redmond, WA 98052 441 EMail: bernarda@microsoft.com 442 Phone: +1 425 706 6605 443 Fax: +1 425 936 7329 444 Appendix A - Hints 446 In order to assist in IPv4 network attachment detection, information 447 associated with each network may be retained by the host. Based on IP 448 and link-layer information, the host may be able to make an educated 449 guess as to whether it has moved between subnets, or remained on the 450 same subnet. If it is likely to have moved between subnets, the host 451 may have an educated guess as to which subnet it has moved to. The term 452 "strong hint" refers to information which provides an unambiguous 453 indication of the network to which a host has connected. "Weak hints" 454 involve information which is inconclusive. 456 IPv4 ICMP Router Discovery messages [RFC1256] provide information 457 directly relevant to determining the network to which a host has 458 connected. As such, information gleaned from Router Advertisements can 459 be considered a "strong" hint. 461 For networks running over PPP [RFC1661], "weak" hints include the link 462 characteristics negotiated in LCP, and the associated phone number. The 463 IP parameters negotiated in IPCP are considered a "strong" hint. 465 On IEEE 802 wired networks, hints include link-layer discovery traffic 466 as well as information exchanged as part of IEEE 802.1X authentication. 467 Link-layer discovery traffic includes Link Layer Discovery Protocol 468 [LLDP] traffic as well as network identification information passed in 469 the EAP-Request/Identity or within an EAP method exchange. 471 For example, LLDP advertisements can provide information on the IP 472 address or VLANs supported by the device. These hints, if provided, are 473 considered "strong"; all other hints are considered "weak". When used 474 with IEEE 802.1X authentication, the EAP-Request/Identity exchange may 475 contain the name of the authenticator, also providing information on the 476 potential network. Similarly, during the EAP method exchange the 477 authenticator may supply information that may be helpful in identifying 478 the network to which the device is attached. 480 In IEEE 802.11 [IEEE80211] stations provide information in Beacon and/or 481 Probe Response messages, such as the SSID, BSSID, and capabilities, as 482 well as information on whether the station is operating in 483 Infrastructure or Adhoc mode. As described in [Congdon], it is possible 484 to assign a Station to a VLAN dynamically, based on the results of IEEE 485 802.1X [IEEE8021X] authentication. This implies that a single SSID may 486 offer access to multiple VLANs, and in practice most large WLAN 487 deployments offer access to multiple subnets. 489 Thus, associating to the same SSID is a necessary, but not necessarily a 490 sufficient condition, for remaining within the same subnet. While a 491 Station associating to the same SSID may not necessarily remain within 492 the same subnet; on the other hand, a Station associating to a 493 different SSID is likely to have changed subnets. In order to provide 494 additional guidance on the subnets to which a given AP offers access, 495 additional subnet-related Information Elements (IEs) have been proposed 496 for addition to the IEEE 802.11 Beacon and Probe Response messages. 497 Such hints are considered "strong"; all other IEEE 802.11 hints are 498 considered "weak". 500 Intellectual Property 502 The IETF takes no position regarding the validity or scope of any 503 intellectual property or other rights that might be claimed to pertain 504 to the implementation or use of the technology described in this 505 document or the extent to which any license under such rights might or 506 might not be available; neither does it represent that it has made any 507 effort to identify any such rights. Information on the IETF's 508 procedures with respect to rights in standards-track and standards- 509 related documentation can be found in BCP-11. Copies of claims of 510 rights made available for publication and any assurances of licenses to 511 be made available, or the result of an attempt made to obtain a general 512 license or permission for the use of such proprietary rights by 513 implementors or users of this specification can be obtained from the 514 IETF Secretariat. 516 The IETF invites any interested party to bring to its attention any 517 copyrights, patents or patent applications, or other proprietary rights 518 which may cover technology that may be required to practice this 519 standard. Please address the information to the IETF Executive 520 Director. 522 Full Copyright Statement 524 Copyright (C) The Internet Society (2003). All Rights Reserved. 526 This document and translations of it may be copied and furnished to 527 others, and derivative works that comment on or otherwise explain it or 528 assist in its implementation may be prepared, copied, published and 529 distributed, in whole or in part, without restriction of any kind, 530 provided that the above copyright notice and this paragraph are included 531 on all such copies and derivative works. However, this document itself 532 may not be modified in any way, such as by removing the copyright notice 533 or references to the Internet Society or other Internet organizations, 534 except as needed for the purpose of developing Internet standards in 535 which case the procedures for copyrights defined in the Internet 536 Standards process must be followed, or as required to translate it into 537 languages other than English. The limited permissions granted above are 538 perpetual and will not be revoked by the Internet Society or its 539 successors or assigns. This document and the information contained 540 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 541 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 542 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 543 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 544 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 546 Open issues 548 Open issues relating to this specification are tracked on the following 549 web site: 551 http://www.drizzle.com/~aboba/DNA/dnaissues.html 553 Expiration Date 555 This memo is filed as , and expires 556 February 22, 2004.