draft-ietf-dhc-dna-ipv4-00.txt   draft-ietf-dhc-dna-ipv4-01.txt 
DHC Working Group Bernard Aboba DHC Working Group Bernard Aboba
INTERNET-DRAFT Microsoft Corporation INTERNET-DRAFT Microsoft Corporation
Category: Best Current Practice Category: Best Current Practice
<draft-ietf-dhc-dna-ipv4-00.txt> <draft-ietf-dhc-dna-ipv4-01.txt>
10 August 2003 11 September 2003
Detection of Network Attachment (DNA) in IPv4 Detection of Network Attachment (DNA) in IPv4
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026. provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts. may also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction.............................................. 3 1. Introduction.............................................. 3
1.1 Requirements .................................... 3 1.1 Requirements .................................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
2. Framework ................................................ 4 2. Framework ................................................ 4
2.1 Most Likely Point of Attachment ................. 4 2.1 Most Likely Point of Attachment ................. 4
2.2 Reachability test ............................... 5 2.2 Reachability test ............................... 5
2.3 IPv4 Address Acquisition ........................ 6 2.3 IPv4 Address Acquisition ........................ 6
3. IANA Considerations ...................................... 8 3. Constants ................................................ 8
4. Security Considerations .................................. 8 4. IANA Considerations ...................................... 8
5. References ............................................... 8 5. Security Considerations .................................. 8
5.1 Normative references ............................ 8 6. References ............................................... 8
5.2 Informative references .......................... 9 6.1 Normative references ............................ 8
6.2 Informative references .......................... 9
Acknowledgments .............................................. 10 Acknowledgments .............................................. 10
Authors' Addresses ........................................... 10 Authors' Addresses ........................................... 10
Appendix A - Hints ........................................... 11 Appendix A - Hints ........................................... 12
Intellectual Property Statement .............................. 12 Intellectual Property Statement .............................. 13
Full Copyright Statement ..................................... 12 Full Copyright Statement ..................................... 13
1. Introduction 1. Introduction
This draft attempts to synthesize experience garnered over the years in This draft attempts to synthesize experience garnered over the years in
the deployment of hosts supporting ARP [RFC826], DHCP [RFC2131], and the deployment of hosts supporting ARP [RFC826], DHCP [RFC2131], and
Link-Local IPv4 addresses [IPv4LL]. Experience has indicated the Link-Local IPv4 addresses [IPv4LL]. Experience has indicated the
importance of several goals in detection of network attachment: importance of several goals in detection of network attachment:
[a] Avoiding inappropriate assignment of Link-Local IPv4 addresses. [a] Avoiding inappropriate assignment of Link-Local IPv4 addresses.
Experience has shown that in the vast majority of cases, the Experience has shown that in the vast majority of cases, the
assignment of Link-Local IPv4 addresses is inappropriate. That is, assignment of Link-Local IPv4 addresses is inappropriate. That
the IPv4 host assigning an Link-Local IPv4 address either is not is, the IPv4 host assigning an Link-Local IPv4 address either
connected to a network at all, in which case assignment of an Link- is not connected to a network at all, in which case assignment
Local IPv4 address does no good; or the host is in fact present on of an Link-Local IPv4 address does no good; or the host is in
a network with a DHCPv4 server but for one reason or another does fact present on a network with a DHCPv4 server but for one
not receive a response to a DHCPREQUEST or DHCPDISCOVER. reason or another does not receive a response to a DHCPREQUEST
or DHCPDISCOVER.
[b] Latency Optimization. The time required to detect movement (or [b] Latency Optimization. The time required to detect movement (or
lack of movement) between subnets, and to obtain (or continue to lack of movement) between subnets, and to obtain (or continue to
use) a valid IPv4 address represents a significant fraction of the use) a valid IPv4 address represents a significant fraction of
overall latency resulting from movement between points of the overall latency resulting from movement between points of
attachment on the network. As a result, optimization of detection attachment on the network. As a result, optimization of
of network attachment in IPv4 hosts is helpful, to the extent that detection of network attachment in IPv4 hosts is helpful, to the
it is achievable. extent that it is achievable.
In order to achieve these goals, this document specifies procedures In order to achieve these goals, this document specifies
conducted on connection to a network. On disconnection from a network, procedures conducted on connection to a network. On
there is no need to take action until the host is reconnected, since it disconnection from a network, there is no need to take action
is typically not possible for a host to communicate until it has until the host is reconnected, since it is typically not
obtained connectivity. Therefore, contrary to [RFC2131] Section 3.7, no possible for a host to communicate until it has obtained
connectivity. Therefore, contrary to [RFC2131] Section 3.7, no
action need be taken on network disconnection. action need be taken on network disconnection.
1.1. Requirements 1.1. Requirements
In this document, several words are used to signify the requirements of In this document, several words are used to signify the requirements of
the specification. These words are often capitalized. The key words the specification. These words are often capitalized. The key words
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in [RFC2119]. interpreted as described in [RFC2119].
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
DHCP client A DHCP client or "client" is an Internet host using DHCP DHCP client
to obtain configuration parameters such as a network A DHCP client or "client" is an Internet host using DHCP to
address. obtain configuration parameters such as a network address.
DHCP server A DHCP server or "server" is an Internet host that DHCP server
returns configuration parameters to DHCP clients. A DHCP server or "server" is an Internet host that returns
configuration parameters to DHCP clients.
Routable address Routable address
In this specification, the term "routable address" refers In this specification, the term "routable address" refers to any
to any address other than an IPv4 Link-Local address. address other than an IPv4 Link-Local address. This includes
This includes private addresses as specified in private addresses as specified in [RFC1918].
[RFC1918].
2. Framework 2. Framework
This document specifies a procedure to be performed for IPv4 network This document specifies a procedure to be performed for IPv4 network
attachment detection that depends on three phases: determination of the attachment detection that depends on three phases: determination of the
"most likely" point of attachment, a reachability test phase, and an "most likely" point of attachment, a reachability test phase, and an
IPv4 address acquisition phase. IPv4 address acquisition phase.
The following basic principles are suggested: The following basic principles are suggested:
[1] Utilization of link layer hints. Link layers such as IEEE 802 [1] Utilization of link layer hints. Link layers such as IEEE 802
[IEEE802] provide hints about whether a host remains on the same [IEEE802] provide hints about whether a host remains on the same
subnet despite changing its point of attachment, or even whether subnet despite changing its point of attachment, or even whether
the host is connected to an adhoc or infrastructure network. Where the host is connected to an adhoc or infrastructure network.
available, these hints can be used to guide host behavior - with Where available, these hints can be used to guide host behavior
the understanding that they are not infallible and therefore that - with the understanding that they are not infallible and
the host should be capable of making the correct determination even therefore that the host should be capable of making the correct
in the presence of misleading hints. Link layer hints are determination even in the presence of misleading hints. Link
described in more detail in Appendix A. layer hints are described in more detail in Appendix A.
[2] Link-Local IPv4 addressing as a mechanism of last resort. In [2] Link-Local IPv4 addressing as a mechanism of last resort. In
existing implementations of [IPv4LL], once a Link-Local IPv4 existing implementations of [IPv4LL], once a Link-Local IPv4
address is assigned, the DHCPv4 server may not be queried again for address is assigned, the DHCPv4 server may not be queried again
5 minutes. As a result, the inappropriate assignment of a Link- for 5 minutes. As a result, the inappropriate assignment of a
Local IPv4 address results in an extended period of limited Link-Local IPv4 address results in an extended period of limited
connectivity. For a host that may change its point of attachment connectivity. For a host that may change its point of
more frequently than every 5 minutes, the inappropriate assignment attachment more frequently than every 5 minutes, the
of an Link-Local IPv4 address is more than just an annoyance - it inappropriate assignment of an Link-Local IPv4 address is more
can result in an ongoing inability to connect. As a result, this than just an annoyance - it can result in an ongoing inability
document suggests that hosts behave conservatively with respect to to connect. As a result, this document suggests that hosts
assignment of Link-Local IPv4 addresses, using them only as a last behave conservatively with respect to assignment of Link-Local
resort. IPv4 addresses, using them only as a last resort.
2.1. Most Likely Point of Attachment 2.1. Most Likely Point of Attachment
On connecting to a new point of attachment, the host attempts to On connecting to a new point of attachment, the host attempts to
determine the "most likely" configuration associated with the new point determine the "most likely" configuration associated with the new point
of attachment. of attachment.
In order to determine the "most likely" point of attachment it is In order to determine the "most likely" point of attachment it is
assumed that the host is capable of obtaining and writing to stable assumed that the host is capable of obtaining and writing to stable
storage parameters relating to networks that it connects to, including: storage parameters relating to networks that it connects to, including:
[1] IP and link layer hints associated with each network. For details, [1] IP and link layer hints associated with each network. For
see Appendix A. details, see Appendix A.
[2] The IP and MAC address of default gateway(s) on each network. [2] The IP and MAC address of default gateway(s) on each network.
By matching the received hints against information previously collected, By matching the received hints against information previously
the host may be able to make an educated guess of which network it has collected, the host may be able to make an educated guess of
attached to. Where no additional information is available, by default which network it has attached to. Where no additional
the host assumes that the "most likely" point of attachment is the information is available, by default the host assumes that the
network to which it was most recently connected. "most likely" point of attachment is the network to which it was
most recently connected.
If the host has a valid routable IPv4 address on the "most likely" point If the host has a valid routable IPv4 address on the "most
of attachment, the host performs a reachability test as described below. likely" point of attachment, the host performs a reachability
If the reachability test is not successful, or if the host does not have test as described below. If the reachability test is not
a valid routable IPv4 address on the "most likely" point of attachment, successful, or if the host does not have a valid routable IPv4
the host proceeds to the IPv4 address acquisition phase. address on the "most likely" point of attachment, the host
proceeds to the IPv4 address acquisition phase.
2.2. Reachability Test 2.2. Reachability Test
The purpose of the reachability test is for the host to quickly The purpose of the reachability test is for the host to quickly
determine whether it is connected to a network on which it had determine whether it is connected to a network on which it had
previously obtained a still valid routable IPv4 address. The test is previously obtained a still valid routable IPv4 address. The test is
performed by attempting to verify reachability of a previously performed by attempting to verify reachability of a previously
configured primary default gateway on a former point of attachment. If configured primary default gateway on a former point of attachment. If
the test is successful, the host may continue to use a valid routable the test is successful, the host may continue to use a valid routable
IPv4 address without having to re-acquire it. IPv4 address without having to re-acquire it.
The host skips the reachability test and proceeds to the address The host skips the reachability test and proceeds to the address
acquisition phase in the following circumstances: acquisition phase in the following circumstances:
[a] If the host does not have information on the default gateway on the [a] If the host does not have information on the default gateway on
network. the network.
[b] If the host does not have a valid routable IPv4 address on the [b] If the host does not have a valid routable IPv4 address on the
network. Since Link-Local IPv4 addresses are a last resort, these network. Since Link-Local IPv4 addresses are a last resort,
addresses do not count as a valid routable IPv4 address. these addresses do not count as a valid routable IPv4 address.
2.2.1. Packet Format 2.2.1. Packet Format
To perform the reachability test, an ARP Request SHOULD be sent, using To perform the reachability test, an ARP Request SHOULD be sent, using
the host's MAC address as the source, and the broadcast MAC address as the host's MAC address as the source, and the broadcast MAC address as
the destination. The host sets the target protocol address (ar$tpa) to the destination. The host sets the target protocol address (ar$tpa) to
the IPv4 address of the primary default gateway, and uses its own MAC the IPv4 address of the primary default gateway, and uses its own MAC
address in the sender hardware address field (ar$sha). Since the host
address in the sender hardware address field (ar$sha). Since the host
has not yet confirmed the subnet on which it is attached, it MUST set has not yet confirmed the subnet on which it is attached, it MUST set
the sender protocol address field (ar$spa) to 0.0.0.0. This prevents the sender protocol address field (ar$spa) to 0.0.0.0. This prevents
poisoning of the ARP cache with a (potentially invalid) sender IPv4 poisoning of the ARP cache with a (potentially invalid) sender IPv4
address. address.
If a valid ARP Response is received, the MAC address in the target If a valid ARP Response is received, the MAC address in the target
hardware address field (ar$tha) and the IPv4 address in the target hardware address field (ar$tha) and the IPv4 address in the target
protocol address field (ar$tpa) are matched against the list of networks protocol address field (ar$tpa) are matched against the list of networks
and associated default gateway parameters. If a match is found, then and associated default gateway parameters. If a match is found, then
if the host has a valid IPv4 address lease on the matched network, the if the host has a valid IPv4 address lease on the matched network, the
skipping to change at page 7, line 24 skipping to change at page 7, line 24
state that knows the address of a DHCP server may use that address in state that knows the address of a DHCP server may use that address in
the DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address. the DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
However, sending a DHCPREQUEST to the unicast address when in INIT- However, sending a DHCPREQUEST to the unicast address when in INIT-
REBOOT state is not appropriate since it is possible that the client has REBOOT state is not appropriate since it is possible that the client has
moved to another subnet, and therefore the DHCPREQUEST needs to be moved to another subnet, and therefore the DHCPREQUEST needs to be
forwarded to and from the DHCP server by a DHCP Relay so that the forwarded to and from the DHCP server by a DHCP Relay so that the
response can be broadcast. This ensures that the host will receive a response can be broadcast. This ensures that the host will receive a
response regardless of whether the cached IP address is correct for the response regardless of whether the cached IP address is correct for the
network to which it has connected. network to which it has connected.
As noted in [RFC2131] Section 3.2, if the host possesses a valid As described in [IPv4LL] Section 1.7, use of a routable address is
routable IPv4 address on the "most likely" network and does not receive preferred to use of a Link-Local IPv4 address. [RFC2131] Section 3.2
a response after employing the retransmission algorithm, the client MAY states that if the host possesses a valid routable IPv4 address on the
choose to use the previously allocated network address and configuration "most likely" network and does not receive a response after employing
parameters for the remainder of the unexpired lease. This is preferable the retransmission algorithm, the client MAY choose to use the
to assigning a Link-Local IPv4 address if the host has reason to believe previously allocated network address and configuration parameters for
that it remains connected to a network on which it possesses a valid the remainder of the unexpired lease. This is preferable to assigning a
IPv4 address lease. This would be the case, for example, where a host Link-Local IPv4 address if the host has good reason to believe that it
has received "hints" that it believes to be "strong". See Appendix A remains connected to a network on which it possesses a valid IPv4
for details. address lease. This would be the case, for example, where a host has
received "hints" that it believes to be "strong". See Appendix A for
details.
Alternatively, if the host does not have a valid IPv4 address lease on If the host does not have a valid IPv4 address lease on the "most
the "most likely" network and does not receive a response after likely" network and does not receive a response after employing the
employing the retransmission algorithm, it MAY assign a Link-Local IPv4 retransmission algorithm, it MAY assign a Link-Local IPv4 address.
address. This is the preferred behavior only in situations where an Since a Link-Local IPv4 address is often configured because a DHCP
adhoc network is likely to be in operation. For example, a host might server failed to respond to an initial query or is inoperative for some
choose to assign an IPv4 Link-Local address on an IEEE 1394 or adhoc time, it is desirable to abandon the Link-Local IPv4 address assignment
IEEE 802.11 network, unless a routable IPv4 address had previously been as soon as a valid IPv4 address lease can be obtained.
assigned on that network.
However even in this situation, it is possible that the failure to Where a Link-Local IPv4 address is assigned, experience has shown that
obtain a routable IPv4 address represents a temporary aberration, rather five minutes (see [IPv4LL] Appendix A.2) was too long an interval to
than legitimate detection of an adhoc network. It is therefore wait and try to obtain a routable IPv4 address via DHCP. A host which
desirable to abandon the assignment of an Link-Local IPv4 address as has been configured with a Link-Local IPv4 address SHOULD periodically
soon as a valid IPv4 address lease can be obtained. Where an IPv4 Link- attempt to obtain a routable IPv4 address via DHCP. The recommended
Local address is assigned, it is therefore RECOMMENDED that the host policy is to attempt to obtain an address via DHCP after waiting for
attempt to obtain an IPv4 address at 30 second intervals. RECONF_INTERVAL, plus a random number of seconds, uniformly distributed,
between zero to RECONF_JITTER seconds.
3. IANA Considerations 3. Constants
RECONF_INTERVAL 30 seconds
RECONF_JITTER 10 seconds
4. IANA Considerations
This specification does not request the creation of any new parameter This specification does not request the creation of any new parameter
registries, not does it require any other IANA assignments registries, not does it require any other IANA assignments
4. Security Considerations 5. Security Considerations
Detection of Network Attachment (DNA) is typically insecure, so that it Detection of Network Attachment (DNA) is typically insecure, so that it
is inadvisable for a host to adjust its security based on which network is inadvisable for a host to adjust its security based on which network
it believes it is attached to. For example, it would be inappropriate it believes it is attached to. For example, it would be inappropriate
for a host to disable its personal firewall based on the believe that it for a host to disable its personal firewall based on the believe that it
had connected to a home network. had connected to a home network.
ARP [RFC826] traffic is inherently insecure, so that the reachability ARP [RFC826] traffic is inherently insecure, so that the reachability
test described in Section 1.3 can be easily spoofed by an attacker, test described in Section 1.3 can be easily spoofed by an attacker,
leading a host to conclude that it remained attached to a former leading a host to conclude that it remained attached to a former
network. Similarly, where DHCP [RFC2131] traffic is not secured, an network. Similarly, where DHCP [RFC2131] traffic is not secured, an
attacker could masquerade as a DHCP server, in order to convince the attacker could masquerade as a DHCP server, in order to convince the
host that it was attached to a particular network. host that it was attached to a particular network.
Where secure detection of network attachment is required, a host MAY Where secure detection of network attachment is required, a host MAY
wish to skip the ARP-based reachability test entirely since it cannot be wish to skip the ARP-based reachability test entirely since it cannot be
secured, and go immediately to the IPv4 address acquisition phase, secured, and go immediately to the IPv4 address acquisition phase,
utilizing authenticated DHCP [RFC3118]. utilizing authenticated DHCP [RFC3118].
5. References 6. References
5.1. Normative References 6.1. Normative References
[RFC791] Postel, J., "Internet Protocol", RFC 791, USC/Information [RFC791] Postel, J., "Internet Protocol", RFC 791, USC/Information
Sciences Institute, September 1981. Sciences Institute, September 1981.
[RFC792] Postel, J., "Internet Control Message Protocol", RFC 792, [RFC792] Postel, J., "Internet Control Message Protocol", RFC 792,
USC/Information Sciences Institute, September 1981. USC/Information Sciences Institute, September 1981.
[RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or- [RFC826] D. Plummer, "An Ethernet Address Resolution Protocol -or-
Converting Network Addresses to 48-bit Ethernet Address Converting Network Addresses to 48-bit Ethernet Address
for Transmission on Ethernet Hardware", STD 37, RFC 826, for Transmission on Ethernet Hardware", STD 37, RFC 826,
skipping to change at page 9, line 19 skipping to change at page 9, line 25
[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an [RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic [IPv4LL] Cheshire, S., Aboba, B. and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", Internet Configuration of IPv4 Link-Local Addresses", Internet
draft (work in progress), draft-ietf-zeroconf- draft (work in progress), draft-ietf-zeroconf-
ipv4-linklocal-09.txt, August 2003. ipv4-linklocal-09.txt, September 2003.
5.2. Informative References 6.2. Informative References
[RFC1034] Mockapetris, P., "Domain Names - Concepts and [RFC1034] Mockapetris, P., "Domain Names - Concepts and
Facilities", STD 13, RFC 1034, USC/Information Sciences Facilities", STD 13, RFC 1034, USC/Information Sciences
Institute, November 1987. Institute, November 1987.
[RFC1035] Mockapetris, P., "Domain Names - Implementation and [RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, USC/Information Specification", STD 13, RFC 1035, USC/Information
Sciences Institute, November 1987. Sciences Institute, November 1987.
[RFC1058] Hedrick, C.L., "Routing Information Protocol", RFC 1058, [RFC1058] Hedrick, C.L., "Routing Information Protocol", RFC 1058,
skipping to change at page 12, line 13 skipping to change at page 12, line 13
Station associating to the same SSID may not necessarily remain within Station associating to the same SSID may not necessarily remain within
the same subnet; on the other hand, a Station associating to a the same subnet; on the other hand, a Station associating to a
different SSID is likely to have changed subnets. In order to provide different SSID is likely to have changed subnets. In order to provide
additional guidance on the subnets to which a given AP offers access, additional guidance on the subnets to which a given AP offers access,
additional subnet-related Information Elements (IEs) have been proposed additional subnet-related Information Elements (IEs) have been proposed
for addition to the IEEE 802.11 Beacon and Probe Response messages. for addition to the IEEE 802.11 Beacon and Probe Response messages.
Such hints are considered "strong"; all other IEEE 802.11 hints are Such hints are considered "strong"; all other IEEE 802.11 hints are
considered "weak". considered "weak".
Intellectual Property Statement Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards- procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses to rights made available for publication and any assurances of licenses to
skipping to change at page 12, line 52 skipping to change at page 13, line 4
provided that the above copyright notice and this paragraph are included provided that the above copyright notice and this paragraph are included
on all such copies and derivative works. However, this document itself on all such copies and derivative works. However, this document itself
may not be modified in any way, such as by removing the copyright notice may not be modified in any way, such as by removing the copyright notice
or references to the Internet Society or other Internet organizations, or references to the Internet Society or other Internet organizations,
except as needed for the purpose of developing Internet standards in except as needed for the purpose of developing Internet standards in
which case the procedures for copyrights defined in the Internet which case the procedures for copyrights defined in the Internet
Standards process must be followed, or as required to translate it into Standards process must be followed, or as required to translate it into
languages other than English. The limited permissions granted above are languages other than English. The limited permissions granted above are
perpetual and will not be revoked by the Internet Society or its perpetual and will not be revoked by the Internet Society or its
successors or assigns. This document and the information contained successors or assigns. This document and the information contained
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Open issues Open issues
Open issues relating to this specification are tracked on the following Open issues relating to this specification are tracked on the following
web site: web site:
http://www.drizzle.com/~aboba/DNA/dnaissues.html http://www.drizzle.com/~aboba/DNA/dnaissues.html
Expiration Date Expiration Date
This memo is filed as <draft-ietf-dhc-dna-ipv4-00.txt>, and expires This memo is filed as <draft-ietf-dhc-dna-ipv4-01.txt>, and expires
February 22, 2004. February 22, 2004.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/