[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 RFC 4436

DHC Working Group                                          Bernard Aboba
INTERNET-DRAFT                                     Microsoft Corporation
Category: Proposed Standard
<draft-ietf-dhc-dna-ipv4-04.txt>
21 October 2003



             Detection of Network Attachment (DNA) in IPv4

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC 2026.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   The time required to detect movement (or lack of movement) between
   subnets, and to obtain (or continue to use) a valid IPv4 address may
   be significant as a fraction of the total delay in moving between
   points of attachment.  This specification synthesizes experience
   garnered over the years in the deployment of hosts supporting ARP,
   DHCP and IPv4 Link-Local addresses, in order to optimize detection of
   network attachment by mobile hosts.










Aboba                       Proposed Standard                   [Page 1]

INTERNET-DRAFT                    DNAv4                  21 October 2003


Table of Contents

1.  Introduction..............................................    3
      1.1    Requirements ....................................    4
      1.2    Terminology .....................................    4
2.  Framework ................................................    5
      2.1    Reachability test ...............................    5
      2.2    Packet format ...................................    6
      2.3    IPv4 Address Acquisition ........................    7
3.  Constants ................................................    8
4.  IANA Considerations ......................................    9
5.  Security Considerations ..................................    9
6.  References ...............................................    9
      6.1    Normative references ............................    9
      6.2    Informative references ..........................   10
Acknowledgments ..............................................   11
Authors' Addresses ...........................................   11
Appendix A - Hints ...........................................   12
Intellectual Property Statement ..............................   13
Full Copyright Statement .....................................   13































Aboba                       Proposed Standard                   [Page 2]

INTERNET-DRAFT                    DNAv4                  21 October 2003


1.  Introduction

   The time required to detect movement (or lack of movement) between
   subnets, and to obtain (or continue to use) a valid IPv4 address may
   be significant as a fraction of the total delay in moving between
   points of attachment.  As a result, optimizing detection of network
   attachment is important for mobile hosts.

   This document synthesizes experience in the deployment of hosts
   supporting ARP [RFC826], DHCP [RFC2131], and Link-Local IPv4
   addresses [IPv4LL], specifying a procedure to be performed for IPv4
   detection of network attachment.   The procedure consists of three
   phases: determination of the "most likely" point of attachment,
   reachability testing, and IPv4 address acquisition.

   On disconnection from a network, there is no need to take action
   until the host is reconnected, since it is typically not 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.

   For Detection of Network attachment, the following basic principles
   are suggested:

   [a] Utilization of link layer hints. Link layers such as
       IEEE 802 [IEEE802] provide hints about whether a host
       remains on the same subnet despite changing its point of
       attachment, or even whether the host is connected to an
       adhoc or infrastructure network.  Where available, these
       hints can be used to guide host behavior - with the
       understanding that they are not infallible and therefore
       that the host should be capable of making the correct
       determination even in the presence of misleading hints.
       Link layer hints are described in  more detail in
       Appendix A.

   [b] Link-Local IPv4 addressing as a mechanism of last resort.
       Experience has shown that Link-Local IPv4 addresses are
       often assigned inappropriately.  For example, an IPv4 host
       assigning an Link-Local IPv4 address may not be connected
       to any network, in which case assignment of a Link-Local
       IPv4 address does no good; or the host may be attached to a
       network with a DHCPv4 server but may not receive a response
       to a DHCPREQUEST or DHCPDISCOVER.  As described in Appendix A
       of [IPv4LL] once a Link-Local IPv4 address is assigned,
       existing implementations do not query the DHCPv4 server
       again for 5 minutes.  As noted in Section 2.3, this behavior
       is in violation of [RFC2131] Section 4.1.  For hosts changing



Aboba                       Proposed Standard                   [Page 3]

INTERNET-DRAFT                    DNAv4                  21 October 2003


       their point of attachment more frequently than this,
       inappropriate assignment of an Link-Local IPv4 address can
       result in an ongoing inability to connect.  As a result,
       this document suggests that hosts behave conservatively with
       respect to assignment of Link-Local IPv4 addresses, using
       them only as a last resort.

1.1.  Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.  The key
   words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
   "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document
   are to be interpreted as described in [RFC2119].

1.2.  Terminology

This document uses the following terms:

ar$sha
     ARP packet field: Source Hardware Address [RFC826]. The hardware
     (MAC) address of the originator of an ARP packet.

ar$spa
     ARP packet field: Source Protocol Address [RFC826].  For IP Address
     Resolution this is the IP Address of the sender of the ARP packet.
     If the sender address is unknown, this is set to 0.0.0.0.

ar$tha
     ARP packet field: Target Hardware Address [RFC826].  The hardware
     (MAC) address of the target of an ARP packet, or the broadcast
     address if the target hardware address is unknown.

ar$tpa
     ARP packet field: Target Protocol Address [RFC826].  For IP Address
     Resolution, the IP address for which one desires to know the
     hardware address.

DHCP client
     A DHCP client or "client" is an Internet host using DHCP to obtain
     configuration parameters such as a network address.

DHCP server
     A DHCP server or "server" is an Internet host that returns
     configuration parameters to DHCP clients.

Routable address
     In this specification, the term "routable address" refers to any



Aboba                       Proposed Standard                   [Page 4]

INTERNET-DRAFT                    DNAv4                  21 October 2003


     address other than an IPv4 Link-Local address.  This includes
     private addresses as specified in [RFC1918].

2.  Framework

   On connecting to a new point of attachment, the host attempts to
   determine the "most likely" configuration associated with the new
   point of attachment.

   In order to determine the "most likely" point of attachment it is
   assumed that the host is capable of obtaining and writing to stable
   storage parameters relating to networks that it connects to,
   including:

   [1]  IP and link layer hints associated with each network. For
        details, see Appendix A.
   [2]  The IP and MAC address of the primary default gateway on
        each network.

   By matching the received hints against information previously
   collected, the host may be able to make an educated guess of which
   network it has attached to.  Where no additional information is
   available, by default the host assumes that the "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 of attachment, the host performs a reachability test as
   described below.  If the reachability test is not successful, or if
   the host does not have a valid routable IPv4 address on the "most
   likely" point of attachment, the host proceeds to the IPv4 address
   acquisition phase.

2.1.  Reachability Test

   The purpose of the reachability test is to determine whether the host
   is connected to a network on which it had previously obtained a still
   valid routable IPv4 address.  The test is performed by attempting to
   verify reachability of a previously configured primary default
   gateway on a former point of attachment.  If the test is successful,
   the host may continue to use a valid routable IPv4 address without
   having to re-acquire it.  This reduces roaming latency by allowing
   the host to bypass the DHCP exchange as well as subsequent Duplicate
   Address Detection (DAD).  In contrast to a DHCP exchange, which may
   be between a DHCP client and an offlink DHCP server, the reachability
   test occurs between a host and its next hop router.

   The host skips the reachability test and proceeds to the address
   acquisition phase in the following circumstances:



Aboba                       Proposed Standard                   [Page 5]

INTERNET-DRAFT                    DNAv4                  21 October 2003


   [a] If the host does not have information on the default
       gateway on the network.
   [b] If the host does not have a valid routable IPv4 address
       on the network.  A Link-Local IPv4 address does not
       count as a valid routable IPv4 address.

2.2.  Packet Format

   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 destination.  The host sets the target protocol
   address (ar$tpa) to the IPv4 address of the primary default gateway,
   and uses its own MAC address in the sender hardware address field
   (ar$sha).  The host sets the target hardware address field (ar$tha)
   to 0.

   If the host has a valid globally routable IP address on the most
   likely point of attachment, then it SHOULD set the sender protocol
   address field (ar$spa) to that address. It is assumed that the host
   had previously done duplicate address detection so that an address
   conflict is unlikely.

   However if the host has a private address as defined in [RFC1918],
   then it SHOULD set the sender protocol address field (ar$spa) to the
   unspecified address (0.0.0.0).  This is to avoid an address conflict
   in the case where the host has changed its point of attachment from
   one private network to another.

      Note: Some routers may refuse to answer an ARP Request sent with
      the sender protocol address field (ar$spa) set to the unspecified
      address (0.0.0.0). In this case the reachability test will fail.

   If a valid ARP Response is received, the MAC address in the sender
   hardware address field (ar$sha) and the IPv4 address in the sender
   protocol address field (ar$spa) are matched against the list of
   networks 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 host continues to use that IPv4 address, subject
   to the lease re-acquisition and expiration behavior described in
   [RFC2131], Section 4.4.5.

   Checking for a match on both the IPv4 and MAC addresses of the
   default gateway allows the host to confirm reachability even where
   the host moves between two private networks.  In this case the IPv4
   address of the default gateway could remain the same, while the MAC
   address would change, so that both addresses need to be checked.

   Sending an ICMP Echo Request [RFC792] to the default gateway IPv4



Aboba                       Proposed Standard                   [Page 6]

INTERNET-DRAFT                    DNAv4                  21 October 2003


   address does not provide the same level of assurance since this
   requires an ARP Request/Response to be sent first, and typically does
   not allow the MAC address to be checked as well.  It therefore SHOULD
   NOT be used as a substitute.  Where a host moves from one private
   network to another, an ICMP Echo Request can result in an ICMP Echo
   Response even when the default gateway has changed, as long as the
   IPv4 address remains the same.  This can occur,  for example, where a
   host moves from one home network using prefix 192.168/16 to another
   one.  In addition, if the ping is sent with TTL > 1, then an ICMP
   Echo Response can be received from an off-link gateway.

   If the initial ARP Request does not elicit a Response, the host waits
   for REACHABILITY_TIMER and then sends another ARP Request.  If no ARP
   Response is received in response to this second Request, the host
   proceeds to the IPv4 address acquisition phase.  If a valid ARP
   Response is received, but cannot be matched against known networks,
   the host assumes it has moved subnets and moves on to the address
   acquisition phase.

2.3.  IPv4 Address Acquisition

   If the host has a valid cached configuration on the "most likely"
   point of attachment, but is unable to confirm reachability to the
   primary default gateway, then the host seeks to verify the cached
   configuration by entering the INIT-REBOOT state, and sending a
   DHCPREQUEST to the broadcast address as specified in [RFC2131]
   Section 4.4.2.

   If the host does not have a valid cached configuration, or had not
   previously obtained a routable IPv4 address on the "most likely"
   point of attachment, then the host enters the INIT state and sends a
   DHCPDISCOVER packet to the broadcast address, as described in
   [RFC2131] Section 4.4.1.  If the host does not receive a response to
   a DHCPREQUEST or DHCPDISCOVER, then it retransmits as specified in
   [RFC2131] Section 4.1.

   As discussed in [RFC2131], Section 4.4.4, a host in INIT or REBOOTING
   state that knows the address of a DHCP server may use that address in
   the DHCPDISCOVER or DHCPREQUEST rather than the IP broadcast address.
   In the INIT-REBOOT state a DHCPREQUEST is sent to the broadcast
   address so that the host will receive a response regardless of
   whether the cached IP address is correct for the network to which it
   has connected.

   Sending a DHCPREQUEST to the unicast address in INIT-REBOOT state is
   not appropriate since if the client has moved to another subnet,  a
   DHCP server response cannot be routed back to the client since the
   DHCPREQUEST will bypass the DHCP relay and will contain an invalid



Aboba                       Proposed Standard                   [Page 7]

INTERNET-DRAFT                    DNAv4                  21 October 2003


   source address.

   As described in [IPv4LL] Section 1.7, use of a routable address is
   preferred to a Link-Local IPv4 address whenever it is available.
   [RFC2131] Section 3.2 states that if the host possesses a valid
   routable IPv4 address on the "most likely" network and does not
   receive a response after employing the retransmission algorithm, the
   client MAY choose to use the previously allocated network address and
   configuration parameters for the remainder of the unexpired lease.
   This is preferable to assigning a Link-Local IPv4 address if the host
   has good reason to believe that it remains connected to a network on
   which it possesses a valid IPv4 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.

   If the host does not have a valid IPv4 address lease on the "most
   likely" network and does not receive a response after employing the
   retransmission algorithm, it MAY assign a Link-Local IPv4 address.
   Since a Link-Local IPv4 address is often configured because a DHCP
   server failed to respond to an initial query or is inoperative for
   some time, it is desirable to abandon the Link-Local IPv4 address
   assignment as soon as a valid IPv4 address lease can be obtained.

   Where a Link-Local IPv4 address is assigned, experience has shown
   that five minutes (see [IPv4LL] Appendix A.2) is too long an interval
   to wait until retrying to obtain a routable IPv4 address using DHCP.
   According to [RFC2131] Section 4.1:

          The retransmission delay SHOULD be doubled with
          subsequent retransmissions up to a maximum of 64 seconds.

   As a result, a DHCP client compliant with [RFC2131] will continue to
   retry every 64 seconds, even after allocating a Link-Local IPv4
   address.  Should the DHCP client succeed in obtaining a routable
   address, then as noted in [IPv4LL], the Link-Local IPv4 address is
   deprecated.  In order to avoid inappropriate assignment of an IPv4
   Link-Local address, it is RECOMMENDED that such an address not be
   assigned until the DHCP client has retransmitted at least 3 times.

3.  Constants

The suggested default value of REACHABILITY_TIMER is 200 ms.  This value
was chosen so as to accomodate the maximum retransmission timer likely
to be experienced on an Ethernet network.







Aboba                       Proposed Standard                   [Page 8]

INTERNET-DRAFT                    DNAv4                  21 October 2003


4.  IANA Considerations

   Guidelines for IANA considerations are specified in [RFC2434].  This
   specification does not request the creation of any new parameter
   registries, nor does it require any other IANA assignments.

5.  Security Considerations

   Detection of Network Attachment (DNA) is typically insecure, so that
   it 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 for a host to disable its personal firewall based on
   the belief that it had connected to a home network.

   ARP [RFC826] traffic is inherently insecure, so that the reachability
   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
   network.  Similarly, where DHCP [RFC2131] traffic is not secured, an
   attacker could masquerade as a DHCP server, in order to convince the
   host that it was attached to a particular network.

   Where secure detection of network attachment is required, a host MAY
   wish to skip the ARP-based reachability test entirely since it cannot
   be secured, and go immediately to the IPv4 address acquisition phase,
   utilizing authenticated DHCP [RFC3118].

6.  References

6.1.  Normative References

[RFC792]  Postel, J., "Internet Control Message Protocol", RFC 792,
          USC/Information Sciences Institute, September 1981.

[RFC826]  D. Plummer, "An Ethernet Address Resolution Protocol -or-
          Converting Network Addresses to 48-bit Ethernet Address for
          Transmission on Ethernet Hardware", STD 37, RFC 826, November
          1982.

[RFC1256] Deering, S., "ICMP Router Discovery Messages", RFC 1256, Xerox
          PARC, September 1991.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
          Requirement Levels", RFC 2119, March, 1997.

[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
          March 1997.





Aboba                       Proposed Standard                   [Page 9]

INTERNET-DRAFT                    DNAv4                  21 October 2003


[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
          RFC 3118, June 2001.

[IPv4LL]  Cheshire, S., Aboba, B. and E. Guttman, "Dynamic Configuration
          of IPv4 Link-Local Addresses", Internet draft (work in
          progress), draft-ietf-zeroconf-ipv4-linklocal-10.txt, October
          2003.

6.2.  Informative References

[RFC1661] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
          51, RFC 1661, Daydreamer, July 1994.

[RFC1918] Rekhter, Y., et al., "Address Allocation for Private
          Internets", RFC 1918, February 1996.

[RFC2284] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
          Protocol (EAP)", RFC 2284, March 1998.

[RFC2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
          Considerations Section in RFCs", BCP 26, RFC 2434, October
          1998.

[RFC3580] Congdon, P., et al., "IEEE 802.1X Remote Authentication Dial
          In User Service (RADIUS) Usage Guidelines", RFC 3580,
          September 2003.

[IEEE8021AB]
          IEEE Standards for Local and Metropolitan Area Networks:
          Station and Media Access Control - Connectivity Discovery,
          IEEE Std 802.1AB/D5, September 2003.

[IEEE8021X]
          IEEE Standards for Local and Metropolitan Area Networks: Port
          based Network Access Control, IEEE Std 802.1X-2001, June 2001.

[IEEE802] IEEE Standards for Local and Metropolitan Area Networks:
          Overview and Architecture, ANSI/IEEE Std 802, 1990.

[IEEE8021Q]
          IEEE Standards for Local and Metropolitan Area Networks: Draft
          Standard for Virtual Bridged Local Area Networks, P802.1Q,
          January 1998.

[IEEE80211]
          Information technology - Telecommunications and information
          exchange between systems - Local and metropolitan area
          networks - Specific Requirements Part 11:  Wireless LAN Medium



Aboba                       Proposed Standard                  [Page 10]

INTERNET-DRAFT                    DNAv4                  21 October 2003


          Access Control (MAC) and Physical Layer (PHY) Specifications,
          IEEE Std. 802.11-1999, 1999.

Acknowledgments

   The authors would like to acknowledge Greg Daley of Monash
   University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ted
   Lemon of Nominum and Thomas Narten of IBM for contributions to this
   document.

Authors' Addresses

   Bernard Aboba
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052

   EMail: bernarda@microsoft.com
   Phone: +1 425 706 6605
   Fax:   +1 425 936 7329































Aboba                       Proposed Standard                  [Page 11]

INTERNET-DRAFT                    DNAv4                  21 October 2003


Appendix A - Hints

   In order to assist in IPv4 network attachment detection, information
   associated with each network may be retained by the host.  Based on
   IP and link-layer information, the host may be able to make an
   educated guess as to whether it has moved between subnets, or
   remained on the same subnet.  If it is likely to have moved between
   subnets, the host may have an educated guess as to which subnet it
   has moved to.  The term "strong hint" refers to information which
   provides an unambiguous indication of the network to which a host has
   connected. "Weak hints" involve information which is inconclusive.

   IPv4 ICMP Router Discovery messages [RFC1256] provide information
   directly relevant to determining the network to which a host has
   connected.  As such, information gleaned from Router Advertisements
   can be considered a "strong" hint.

   For networks running over PPP [RFC1661], "weak" hints include the
   link characteristics negotiated in LCP, and the associated phone
   number.  The IP parameters negotiated in IPCP are considered a
   "strong" hint.

   On IEEE 802 [IEEE802] wired networks, hints include link-layer
   discovery traffic as well as information exchanged as part of IEEE
   802.1X authentication [IEEE8021X].  Link-layer discovery traffic
   includes Link Layer Discovery Protocol (LLDP) [IEEE8021AB] traffic as
   well as network identification information passed in the EAP-
   Request/Identity or within an EAP method exchange, as defined in EAP
   [RFC2284].

   For example, LLDP advertisements can provide information on the IP
   address or VLANs supported by the device.  These hints, if provided,
   are considered "strong".  When used with IEEE 802.1X authentication
   [IEEE8021X], the EAP-Request/Identity exchange may contain the name
   of the authenticator, also providing information on the potential
   network.  Similarly, during the EAP method exchange the authenticator
   may supply information that may be helpful in identifying the network
   to which the device is attached.   However, as noted in [RFC3580], it
   is possible for the VLANID defined in [IEEE8021Q] to be assigned
   dynamically, so this static information may not prove definitive.  As
   a result, these hints are considered "weak".

   In IEEE 802.11 [IEEE80211] stations provide information in Beacon
   and/or Probe Response messages, such as the SSID, BSSID, and
   capabilities, as well as information on whether the station is
   operating in Infrastructure or Adhoc mode.  As described in
   [RFC3580], it is possible to assign a Station to a VLAN dynamically,
   based on the results of IEEE 802.1X [IEEE8021X] authentication.  This



Aboba                       Proposed Standard                  [Page 12]

INTERNET-DRAFT                    DNAv4                  21 October 2003


   implies that a single SSID may offer access to multiple VLANs, and in
   practice most large WLAN deployments offer access to multiple
   subnets.

   Thus, associating to the same SSID is a necessary, but not
   necessarily a sufficient condition, for remaining within the same
   subnet: while a Station associating to the same SSID may not
   necessarily remain within the same subnet, a Station associating to a
   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 subnet-related Information
   Elements (IEs) have been proposed for addition to the IEEE 802.11
   Beacon and Probe Response messages.  Such hints are considered
   "strong"; all other IEEE 802.11 hints are considered "weak".

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this 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 effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

Full Copyright Statement

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this



Aboba                       Proposed Standard                  [Page 13]

INTERNET-DRAFT                    DNAv4                  21 October 2003


   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.  The limited permissions granted above are perpetual and
   will not be revoked by the Internet Society or its successors or
   assigns.  This document and the information contained herein is
   provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE
   INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR
   IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Open issues

   Open issues relating to this specification are tracked on the
   following web site:

   http://www.drizzle.com/~aboba/DNA/dnaissues.html

Expiration Date

   This memo is filed as <draft-ietf-dhc-dna-ipv4-04.txt>,  and  expires
   April 22, 2004.

























Aboba                       Proposed Standard                  [Page 14]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/