datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Detecting Network Attachment in IPv4 (DNAv4)
RFC 4436

Document type: RFC - Proposed Standard (March 2006; Errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 4436 (Proposed Standard)
Responsible AD: Margaret Wasserman
Send notices to: rdroms@cisco.com, venaas@uninett.no

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

[include full document text]