doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc4436.txt b/doc/rfc/rfc4436.txt
new file mode 100644
index 0000000..ab453e7
--- /dev/null
+++ b/doc/rfc/rfc4436.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+Network Working Group                                           B. Aboba
+Request for Comments: 4436                         Microsoft Corporation
+Category: Standards Track                                     J. Carlson
+                                                        Sun Microsystems
+                                                             S. Cheshire
+                                                          Apple Computer
+                                                              March 2006
+
+
+              Detecting Network Attachment in IPv4 (DNAv4)
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2006).
+
+Abstract
+
+   The time required to detect movement between networks and to obtain
+   (or to continue to use) an IPv4 configuration may be significant as a
+   fraction of the total handover latency in moving between points of
+   attachment.  This document synthesizes, from experience in the
+   deployment of hosts supporting ARP, DHCP, and IPv4 Link-Local
+   addresses, a set of steps known as Detecting Network Attachment for
+   IPv4 (DNAv4), in order to decrease the handover latency in moving
+   between points of attachment.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 1]
+
+RFC 4436                         DNAv4                        March 2006
+
+
+Table of Contents
+
+   1. Introduction ....................................................2
+      1.1. Applicability ..............................................2
+      1.2. Requirements ...............................................5
+      1.3. Terminology ................................................5
+   2. Overview ........................................................6
+      2.1. Reachability Test ..........................................8
+           2.1.1. Packet Format .......................................9
+      2.2. IPv4 Address Acquisition ..................................10
+      2.3. IPv4 Link-Local Addresses .................................11
+      2.4. Manually Assigned Addresses ...............................12
+   3. Security Considerations ........................................12
+   4. References .....................................................13
+      4.1. Normative References ......................................13
+      4.2. Informative References ....................................13
+   5. Acknowledgements ...............................................14
+
+1.  Introduction
+
+   The time required to detect movement between networks and to obtain
+   (or to continue to use) an operable IPv4 configuration may be
+   significant as a fraction of the total handover latency in moving
+   between points of attachment.
+
+   This document synthesizes, from experience in the deployment of hosts
+   supporting ARP [RFC826], DHCP [RFC2131], and IPv4 Link-Local
+   addresses [RFC3927], a set of steps known as Detecting Network
+   Attachment for IPv4 (DNAv4).  DNAv4 optimizes the (common) case of
+   re-attachment to a network that one has been connected to previously
+   by attempting to re-use a previous (but still valid) configuration,
+   reducing the re-attachment time on LANs to a few milliseconds.  Since
+   this procedure is dependent on the ARP protocol, it is not suitable
+   for use on media that do not support ARP.
+
+1.1.  Applicability
+
+   DHCP is an effective and widely adopted mechanism for a host to
+   obtain an IP address for use on a particular network link, or to
+   re-validate a previously obtained address via DHCP's INIT-REBOOT
+   mechanism [RFC2131].
+
+   When obtaining a new address, DHCP specifies that the client SHOULD
+   use ARP to verify that the offered address is not already in use.
+   The process of address conflict detection [ACD] can take as much as
+   seven seconds.  In principle, this time interval could be shortened,
+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 2]
+
+RFC 4436                         DNAv4                        March 2006
+
+
+   with the obvious trade-off: the less time a host spends waiting to
+   see if another host is already using its intended address, the
+   greater the risk of inadvertent address conflicts.
+
+   Where the client successfully re-validates a previously obtained
+   address using the INIT-REBOOT mechanism, the DHCP specification does
+   not require the client to perform address conflict detection, so this
+   seven-second delay does not apply.  However, the DHCP server may be
+   slow to respond or may be down and not responding at all, so hosts
+   could benefit from having an alternative way to quickly determine
+   that a previously obtained address is valid for use on this
+   particular link.
+
+   When the client moves between networks, the address re-validation
+   attempt may be unsuccessful; a DHCPNAK may be received in response to
+   a DHCPREQUEST, causing the client to restart the configuration
+   process by moving to the INIT state.  If an address previously
+   obtained on the new network is still operable, DNAv4 enables the host
+   to confirm the new configuration quickly, bypassing restart of the
+   configuration process and conflict detection.
+
+   The alternative mechanism specified by this document applies when a
+   host has a previously allocated DHCP address, which was not returned
+   to the DHCP server via a DHCPRELEASE message, and which still has
+   time remaining on its lease.  In this case, the host may determine
+   whether it has re-attached to the logical link where this address is
+   valid for use, by sending a unicast ARP Request packet to a router
+   previously known for that link (or, in the case of a link with more
+   than one router, by sending one or more unicast ARP Request packets
+   to one or more of those routers).
+
+   The use of unicast ARP has a number of benefits.  One benefit is that
+   unicast packets impose less burden on the network than broadcast
+   packets, particularly on 802.11 networks where broadcast packets may
+   be sent at rates as low as 1 Mb/sec.  Another benefit is that if the
+   host is not on the link it hoped to find itself on, a broadcast ARP
+   Request could pollute the ARP caches of peers on that link.  When
+   using private addresses [RFC1918], another device could be
+   legitimately using the same address, and a broadcast ARP Request
+   could disrupt its communications, causing TCP connections to be
+   broken, and similar problems.  Also, using a unicast ARP packet
+   addressed to the MAC address of the router the host is expecting to
+   find means that if the host is not on the expected link there will be
+   no device with that MAC address, and the ARP packet will harmlessly
+   disappear into the void without doing any damage.
+
+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 3]
+
+RFC 4436                         DNAv4                        March 2006
+
+
+   These issues that define the applicability of DNAv4 lead us to a
+   number of conclusions:
+
+      o  DNAv4 is a performance optimization.  Its purpose is to speed
+         up a process that may require as much as a few hundred
+         milliseconds (DHCP INIT-REBOOT), as well as to reduce multi-
+         second conflict detection delays when a host changes networks.
+
+      o  As a performance optimization, it must not sacrifice
+         correctness.  In other words, false positives are not
+         acceptable.  DNAv4 must not conclude that a host has returned
+         to a previously visited link where it has an operable IP
+         address if this is not in fact the case.
+
+      o  As a performance optimization, false negatives are acceptable.
+         It is not an absolute requirement that this optimization
+         correctly recognize a previously visited link in all possible
+         cases.  For example, if a router ignores unicast ARP Requests,
+         then DNAv4 will not be able to detect that it has returned to
+         the same link in the future.  This is acceptable because the
+         host still operates correctly as it did without DNAv4, just
+         without the performance benefit.  Users and network operators
+         who desire the performance improvement offered by DNAv4 can
+         upgrade their routers to support DNAv4.
+
+      o  As a performance optimization, where DNAv4 fails to provide a
+         benefit, it should add little or no delay compared to today's
+         DHCP processing.  In practice, this implies that DHCP
+         processing needs to proceed in parallel.  Waiting for DNAv4 to
+         fail before beginning DHCP processing can greatly increase
+         total processing time, the opposite of the desired effect.
+
+      o  Trials are inexpensive.  DNAv4 performs its checks using small
+         unicast packets.  An IPv4 ARP packet on Ethernet is just 42
+         octets, including the Ethernet header.  This means that the
+         cost of an unsuccessful attempt is small, whereas the cost of a
+         missed opportunity (having the right address available as a
+         candidate and choosing not to try it for some reason) is large.
+         As a result, the best strategy is often to try all available
+         candidate configurations, rather than try to determine which
+         candidates, if any, may be correct for this link, based on
+         heuristics or hints.  For a heuristic to offer the prospect of
+         being a potentially useful way to eliminate inappropriate
+         configurations from the candidate list, that heuristic has to
+         (a) be fast and inexpensive to compute, as compared to sending
+         a 42-octet unicast packet, and (b) have high probability of not
+         falsely eliminating a candidate configuration that could be
+         found to be the correct one.
+
+
+
+Aboba, et al.               Standards Track                     [Page 4]
+
+RFC 4436                         DNAv4                        March 2006
+
+
+      o  Time is limited.  If DNAv4 is to be effective in enabling low
+         latency handoffs, it needs to complete in less than 10 ms.
+         This implies that any heuristic used to eliminate candidate
+         configurations needs to take at most a few milliseconds to
+         compute.  This does not leave much room for heuristics based on
+         observation of link-layer or Internet-layer traffic.
+
+1.2.  Requirements
+
+   In this document, several words are used to signify the requirements
+   of the specification.  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
+   "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].
+
+1.3.  Terminology
+
+   This document uses the following terms:
+
+   ar$sha
+      ARP packet field: Sender Hardware Address [RFC826].  The hardware
+      (MAC) address of the originator of an ARP packet.
+
+   ar$spa
+      ARP packet field: Sender Protocol Address [RFC826].  For IP
+      Address Resolution, this is the IPv4 address of the sender of the
+      ARP packet.
+
+   ar$tha
+      ARP packet field: Target Hardware Address [RFC826].  The hardware
+      (MAC) address of the target of an ARP packet.
+
+   ar$tpa
+      ARP packet field: Target Protocol Address [RFC826].  For IPv4
+      Address Resolution, the IPv4 address for which one desires to know
+      the hardware address.
+
+   DHCP client
+      A DHCP client or "client" is an Internet host using the Dynamic
+      Host Configuration Protocol (DHCP) [RFC2131] 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.
+
+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 5]
+
+RFC 4436                         DNAv4                        March 2006
+
+
+   Link
+      A communication facility or medium over which network nodes can
+      communicate.  Each link is associated with a minimum of two
+      endpoints.  Each link endpoint has a unique link-layer identifier.
+
+   Link Down
+      An event provided by the link layer that signifies a state change
+      associated with the interface's no longer being capable of
+      communicating data frames; transient periods of high frame loss
+      are not sufficient.  DNAv4 does not utilize "Link Down"
+      indications.
+
+   Link Layer
+      Conceptual layer of control or processing logic that is
+      responsible for maintaining control of the data link.  The data
+      link layer functions provide an interface between the higher-layer
+      logic and the data link.  The link layer is the layer immediately
+      below IP.
+
+   Link Up
+      An event provided by the link layer that signifies a state change
+      associated with the interface's becoming capable of communicating
+      data frames.
+
+   Point of Attachment
+      The link endpoint on the link to which the host is currently
+      connected.
+
+   Routable address
+      In this specification, the term "routable address" refers to any
+      unicast IPv4 address other than an IPv4 Link-Local address.  This
+      includes private addresses as specified in "Address Allocation for
+      Private Internets" [RFC1918].
+
+   Operable address
+      In this specification, the term "operable address" refers either
+      to a static IPv4 address, or an address assigned via DHCPv4 that
+      has not been returned to the DHCP server via a DHCP RELEASE
+      message, and whose lease has not yet expired.
+
+2.  Overview
+
+   On connecting to a new point of attachment, the host responds to a
+   "Link Up" indication from the link layer by carrying out the DNAv4
+   procedure.
+
+   For each network that it connects to, it is assumed that the host
+   saves the following parameters to stable storage:
+
+
+
+Aboba, et al.               Standards Track                     [Page 6]
+
+RFC 4436                         DNAv4                        March 2006
+
+
+   [1] The IPv4 and MAC address of one or more test nodes on the
+       network.
+
+   [2] The IPv4 configuration parameters, including the DHCP client
+       identifier, assigned address, and lease expiration time.
+
+   From the set of networks that have operable IPv4 addresses associated
+   with them, the host selects a subset and attempts to confirm the
+   configuration for each network, using the reachability test described
+   in Section 2.1.
+
+   For a particular network, the host SHOULD use the addresses of local
+   routers (preferably default gateways) as its test nodes.  If more
+   than one address is known, those addresses may be tested in parallel.
+   In order to ensure configuration validity, the host SHOULD only
+   configure routes for which the next hop address passes the
+   reachability test.  Other routes SHOULD be re-learned.
+
+   DNAv4 does not significantly increase the likelihood of an address
+   conflict.  The reachability test is only carried out for a network
+   when the host has previously completed conflict detection as
+   recommended in Section 2.2 of the DHCP specification [RFC2131] and
+   obtained an operable IPv4 configuration on that network.
+   Restrictions on sending ARP Requests and Responses are described in
+   Section 2.1.1.
+
+   One case where DNAv4 does increase the likelihood of an address
+   conflict is when:
+
+      o  a DHCP server hands out an address lease,
+
+      o  the host with that lease leaves the network,
+
+      o  the DHCP server is power-cycled or crashes and is rebooted,
+
+      o  the DHCP server, having failed to save leases to stable
+         storage, assigns that same address to another host, and
+
+      o  the first host returns and, having a still-valid lease with
+         time remaining, proceeds to use its assigned address,
+         conflicting with the new host that is now using that same
+         address.
+
+   While Section 4 of the DHCP specification [RFC2131] assumes that DHCP
+   servers save their leases in persistent storage, almost no consumer-
+   grade NAT gateway does so.  Short DHCP lease lifetimes can mitigate
+   this risk, though this also limits the operable candidate
+   configurations available for DNAv4 to try.
+
+
+
+Aboba, et al.               Standards Track                     [Page 7]
+
+RFC 4436                         DNAv4                        March 2006
+
+
+2.1.  Reachability Test
+
+   The host skips the reachability test for a network if any of the
+   following conditions are true:
+
+   [a] The host does not have an operable routable IPv4 address on that
+       network.  In this case, the reachability test cannot confirm that
+       the host has an operable routable IPv4 address, so completing the
+       reachability test would serve no purpose.
+
+   [b] The host does not know the addresses of any test nodes on that
+       network.  In this case, insufficient information is available to
+       carry out the reachability test.
+
+   [c] If DHCP authentication [RFC3118] is configured.  The reachability
+       test utilizes ARP, which is insecure.  Hosts that have been
+       configured to attempt DHCP authentication SHOULD NOT utilize the
+       reachability test.  Security issues are discussed in Section 4.
+
+   [d] The contents of the DHCP Client Identifier option that the client
+       used to obtain the candidate configuration is different from the
+       DHCP Client Identifier option the client intends to present on
+       the interface in question.  In this case, it is anticipated that
+       a DHCP server would NAK any request made by the client to acquire
+       or extend the candidate configuration, since the two interfaces
+       are presenting differing identities.
+
+   If the reachability test is successful, the host SHOULD continue to
+   use the operable routable IPv4 address associated with the confirmed
+   network, without needing to re-acquire it.  Once a valid reachability
+   test response is received, validation is complete, and additional
+   responses should be discarded.
+
+   If a DHCPv4 client is operational, it is RECOMMENDED that the host
+   attempt to obtain IPv4 configuration via DHCPv4 in parallel with the
+   reachability tests, with the host using the first answer returned.
+   This ensures that the DNAv4 procedure will not result in additional
+   delay in the case where reachability tests fail, or where sending a
+   DHCPREQUEST from the INIT-REBOOT state, as described in Section 3.2
+   and 4.3.2 of the DHCP specification [RFC2131], completes more quickly
+   than the reachability tests.
+
+   In situations where both DNAv4 and DHCP are used on the same link, it
+   is possible that the reachability test will complete successfully,
+   and then DHCP will complete later with a different result.  If this
+   happens, the implementation SHOULD abandon the reachability test
+
+
+
+
+
+Aboba, et al.               Standards Track                     [Page 8]
+
+RFC 4436                         DNAv4                        March 2006
+
+
+   results and use the DHCP result instead, unless the address confirmed
+   via the reachability test has been manually assigned (see Section
+   2.4).
+
+   Where the reachability test does not return an answer, this is
+   typically because the host is not attached to the network whose
+   configuration is being tested.  In such circumstances, there is
+   typically little value in aggressively retransmitting reachability
+   tests that do not elicit a response.
+
+   Where DNAv4 and DHCP are tried in parallel, one strategy is to
+   forsake reachability test retransmissions and to allow only the DHCP
+   client to retransmit.  In order to reduce competition between DNAv4
+   and DHCP retransmissions, a DNAv4 implementation that retransmits may
+   utilize the retransmission strategy described in Section 4.1 of the
+   DHCP specification [RFC2131], scheduling DNAv4 retransmissions
+   between DHCP retransmissions.
+
+   If a response is received to any reachability test or DHCP message,
+   pending retransmissions are canceled.  It is RECOMMENDED that a DNAv4
+   implementation retransmit no more than twice.  To provide damping in
+   the case of spurious "Link Up" indications, it is RECOMMENDED that
+   the DNAv4 procedure be carried out no more than once a second.
+
+2.1.1.  Packet Format
+
+   The reachability test is performed by sending a unicast ARP Request.
+   The host MUST set the target protocol address (ar$tpa) to the IPv4
+   address of the node being tested, and the sender protocol address
+   field (ar$spa) to its own candidate IPv4 address.  The ARP Request
+   MUST use the host MAC address as the source, and the test node MAC
+   address as the destination.  The host includes its MAC address in the
+   sender hardware address field (ar$sha) and sets the target hardware
+   address field (ar$tha) to 0.
+
+   If a valid ARP Reply is received, the MAC address in the sender
+   hardware address field (ar$sha) in the ARP Reply is matched against
+   the target hardware address field (ar$tpa) in the ARP Request, and
+   the IPv4 address in the sender protocol address field (ar$spa) of the
+   ARP Reply is matched against the target protocol address field
+   (ar$tpa) in the ARP Request.  If a match is found, then the host
+   continues to use that IPv4 address, subject to the lease re-
+   acquisition and expiration behavior described in Section 4.4.5 of the
+   DHCP specification [RFC2131].
+
+   The risk of an address conflict is greatest when the host moves
+   between private networks, since in this case the completion of
+   conflict detection on the former network does not provide assurance
+
+
+
+Aboba, et al.               Standards Track                     [Page 9]
+
+RFC 4436                         DNAv4                        March 2006
+
+
+   against an address conflict on the new network.  Until a host has
+   confirmed the operability of its IPv4 configuration by receipt of a
+   response to the reachability test, it SHOULD NOT respond to ARP
+   Requests and SHOULD NOT broadcast ARP Requests containing its address
+   within the sender protocol address field (ar$spa).
+
+   Sending an ICMP Echo Request [RFC792] would not be an acceptable way
+   of testing a candidate configuration, since sending any IP packet
+   generally requires an ARP Request/Reply exchange and, as explained
+   above, ARP packets may not be broadcast safely until after the
+   candidate configuration has been confirmed.  Also, where a host moves
+   from one private network to another, an ICMP Echo Request can result
+   in an ICMP Echo Response even when the MAC address 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
+   router.  As a result, if the MAC address of the test node is not
+   checked, the host can mistakenly confirm attachment, potentially
+   resulting in an address conflict.  As a result, sending an ICMP Echo
+   Request SHOULD NOT be used as a substitute for the reachability test.
+
+2.2.  IPv4 Address Acquisition
+
+   If the host has an operable routable IPv4 address on one or more
+   networks, and if DHCPv4 is enabled on the interface, the host SHOULD
+   attempt to acquire an IPv4 configuration using DHCPv4, in parallel
+   with one or more reachability tests.  This is accomplished by
+   entering the INIT-REBOOT state and sending a DHCPREQUEST to the
+   broadcast address, as specified in Section 4.4.2 of the DHCP
+   specification [RFC2131].
+
+   If the host does not have an operable routable IPv4 address on any
+   network, the host enters the INIT state and sends a DHCPDISCOVER
+   packet to the broadcast address, as described in Section 4.4.1 of the
+   DHCP specification [RFC2131].  If the host supports the Rapid Commit
+   Option [RFC4039], it is possible that the exchange can be shortened
+   from a 4-message exchange to a 2-message exchange.
+
+   If the host does not receive a response to a DHCPREQUEST or
+   DHCPDISCOVER, then it retransmits as specified in Section 4.1 of the
+   DHCP specification [RFC2131].
+
+   As discussed in Section 4.4.4 of the DHCP specification [RFC2131], 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 IPv4 broadcast address.  In the INIT-REBOOT state, a
+   DHCPREQUEST is sent to the broadcast address so that the host will
+
+
+
+Aboba, et al.               Standards Track                    [Page 10]
+
+RFC 4436                         DNAv4                        March 2006
+
+
+   receive a response regardless of whether the previously configured
+   IPv4 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 DHCP 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 source address.
+
+2.3.  IPv4 Link-Local Addresses
+
+   DNAv4 applies only to previously configured addresses that had some
+   lease lifetime associated with them, during which lifetime the
+   address may be legitimately regarded as being reserved for exclusive
+   use by the assigned host.  DHCP-assigned addresses fit this
+   description, but IPv4 Link-Local address [RFC3927] do not, since IPv4
+   Link-Local addresses are not handed out by an authoritative server
+   and do not come with any guaranteed usable lifetime.
+
+   A host's claim on an IPv4 Link-Local address is valid only as long as
+   that host remains connected to the link, actively defending against
+   probes for its chosen address.  As soon as a host shuts down, sleeps,
+   or otherwise disconnects from a link, it immediately relinquishes any
+   claim it may have had on any IPv4 Link-Local address on that link.  A
+   host wishing to reclaim a previously used IPv4 Link-Local address
+   MUST perform the full probing and announcement process required by
+   "Dynamic Configuration of IPv4 Link-Local Addresses" [RFC3927] and
+   MUST NOT attempt to use DNAv4 as a shortcut to bypass that process.
+
+   Where the host does not have an operable routable IPv4 address on any
+   network, the host MAY configure an IPv4 Link-Local address prior to
+   entering the INIT state and sending a DHCPDISCOVER packet, as
+   described in Section 2.3 of the DHCP specification [RFC2131].  Where
+   a host can confirm that it remains connected to a network on which it
+   possesses an operable routable IPv4 address, that address should be
+   used, and the IPv4 Link-Local address is deprecated, as noted in
+   Section 1.9 of the IPv4 Link-Local specification [RFC3927].
+
+   Where a host has an operable routable IPv4 address on one or more
+   networks but the reachability test cannot confirm the configuration
+   and the DHCPv4 client does not receive a response after employing the
+   retransmission algorithm, Section 3.2 of the DHCP specification
+   [RFC2131] states that the client MAY choose to use the previously
+   allocated network address and configuration parameters for the
+   remainder of the unexpired lease.
+
+
+
+
+
+
+Aboba, et al.               Standards Track                    [Page 11]
+
+RFC 4436                         DNAv4                        March 2006
+
+
+2.4.  Manually Assigned Addresses
+
+   An implementation may use DNAv4 to confirm the configuration of
+   manually assigned addresses.  However, special consideration is
+   required for this to produce reliable results, so it SHOULD NOT be
+   enabled by default.
+
+   For the purposes of DNAv4, manually assigned addresses may be treated
+   as equivalent to DHCP-assigned addresses with an infinite lifetime.
+   This does not significantly increase the probability of an address
+   conflict as long as the manually assigned address is reserved by the
+   DHCP server or is outside the scope of addresses assigned by a DHCP
+   server.  However, where the manually assigned address is within an
+   address scope utilized by a DHCP server, it is possible that the host
+   will be unavailable when the DHCP server checks for a conflict prior
+   to assigning the conflicting address.  In this case, a host utilizing
+   DNAv4 could confirm an address that had been assigned to another
+   host.
+
+   Typically, an address is manually assigned on a network because a
+   dynamically assigned address was not suitable for some reason.
+   Therefore, where DNAv4 and DHCP are run in parallel and DNAv4
+   confirms a manual configuration, it may be undesirable to allow this
+   configuration to be overridden by DHCP, as described in Section 2.1.
+   However, packet loss may cause the reachability test to fail while
+   DHCP completes successfully, resulting in the host obtaining a
+   dynamic address where a static address is desired.  In order to
+   provide for reliable reconfirmation of manually assigned addresses,
+   reachability tests for manual configurations require a more
+   aggressive retransmission strategy than that detailed in Section 4.1
+   of the DHCP specification [RFC2131].  For example, shorter
+   retransmission intervals and more persistent retransmissions may be
+   required.
+
+3.  Security Considerations
+
+   Detecting Network Attachment for IPv4 (DNAv4) is based on ARP and
+   DHCP and inherits the security vulnerabilities of these two
+   protocols.
+
+   ARP [RFC826] traffic is not secured, so an attacker gaining access to
+   the network can spoof a response to the reachability test described
+   in Section 2.1, leading the querier to conclude falsely that it is
+   attached to a network that it is not connected to.
+
+   Similarly, where DHCPv4 traffic is not secured, an attacker could
+   masquerade as a DHCPv4 server, in order to convince the host that it
+   was attached to a particular network.  This and other threats
+
+
+
+Aboba, et al.               Standards Track                    [Page 12]
+
+RFC 4436                         DNAv4                        March 2006
+
+
+   relating to DHCPv4 are described in "Authentication for DHCP
+   Messages" [RFC3118].
+
+   The effect of these attacks will typically be limited to denial of
+   service, unless the host utilizes its IP configuration for other
+   purposes, such as security configuration or location determination.
+   For example, a host that disables its personal firewall based on
+   evidence that it had attached to a home network could be compromised
+   by spoofing of the DNAv4 reachability test.  In general, adjustment
+   of the security configuration based on DNAv4 is NOT RECOMMENDED.
+
+   Hosts that depend on secure IP configuration SHOULD NOT use DNAv4 but
+   SHOULD instead utilize DHCP authentication [RFC3118], possibly in
+   combination with the Rapid Commit Option [RFC4039].
+
+4.  References
+
+4.1.  Normative References
+
+   [RFC826]  Plummer, D., "Ethernet Address Resolution Protocol: Or
+             converting network protocol addresses to 48.bit Ethernet
+             address for transmission on Ethernet hardware", STD 37, RFC
+             826, November 1982.
+
+   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
+             March 1997.
+
+4.2.  Informative References
+
+   [ACD]     Cheshire, S., "IPv4 Address Conflict Detection", Work in
+             Progress, July 2005.
+
+   [RFC792]  Postel, J., "Internet Control Message Protocol", STD 5, RFC
+             792, September 1981.
+
+   [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
+             and E. Lear, "Address Allocation for Private Internets",
+             BCP 5, RFC 1918, February 1996.
+
+   [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
+             Messages", RFC 3118, June 2001.
+
+   [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
+             Configuration of IPv4 Link-Local Addresses", RFC 3927, May
+             2005.
+
+
+
+Aboba, et al.               Standards Track                    [Page 13]
+
+RFC 4436                         DNAv4                        March 2006
+
+
+   [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for
+             the Dynamic Host Configuration Protocol version 4
+             (DHCPv4)", RFC 4039, March 2005.
+
+5.  Acknowledgements
+
+   The authors would like to acknowledge Greg Daley of Monash
+   University, Erik Guttman and Erik Nordmark of Sun Microsystems, Ralph
+   Droms of Cisco Systems, Ted Lemon of Nominum, John Loughney of Nokia,
+   Thomas Narten of IBM and David Hankins of ISC for contributions to
+   this document.
+
+Authors' Addresses
+
+   Bernard Aboba
+   Microsoft Corporation
+   One Microsoft Way
+   Redmond, WA 98052
+
+   Phone: +1 425 818 4011
+   Fax:   +1 425 936 7329
+   EMail: bernarda@microsoft.com
+
+
+   James Carlson
+   Sun Microsystems, Inc
+   1 Network Drive
+   Burlington, MA  01803-2757
+   USA
+
+   Phone: +1 781 442 2084
+   Fax:   +1 781 442 1677
+   EMail: james.d.carlson@sun.com
+
+
+   Stuart Cheshire
+   Apple Computer, Inc.
+   1 Infinite Loop
+   Cupertino, California 95014, USA
+
+   Phone: +1 408 974 3207
+   EMail: rfc@stuartcheshire.org
+
+
+
+
+
+
+
+
+
+Aboba, et al.               Standards Track                    [Page 14]
+
+RFC 4436                         DNAv4                        March 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Aboba, et al.               Standards Track                    [Page 15]
+