draft-ietf-dhc-ipv4-autoconfig-04.txt   draft-ietf-dhc-ipv4-autoconfig-05.txt 
Dynamic Host Configuration WG Ryan Troll Dynamic Host Configuration WG Ryan Troll
Document: draft-ietf-dhc-ipv4-autoconfig-04.txt @Home Network Document: draft-ietf-dhc-ipv4-autoconfig-05.txt Excite@Home
Expires October 19, 1999 April 14, 1999 Expires September 7, 2000 March 2, 2000
Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network Automatically Choosing an IP Address in an Ad-Hoc IPv4 Network
<draft-ietf-dhc-ipv4-autoconfig-04.txt> <draft-ietf-dhc-ipv4-autoconfig-05.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Internet-Drafts are all provisions of Section 10 of RFC2026. Internet-Drafts are work-
working documents of the Internet Engineering Task Force (IETF), its ing documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also dis-
distribute working documents as Internet-Drafts. tribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet- Drafts as at any time. It is inappropriate to use Internet- Drafts as refer-
reference material or to cite them other than as "work in progress." ence material or to cite them other than as "work in progress."
To view the list Internet-Draft Shadow Directories, see 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. http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
Abstract Abstract
With operating systems appearing in more and more devices, as well With operating systems appearing in more and more devices, as well
as computers appearing in more and more aspects of everyday life, as computers appearing in more and more aspects of everyday life,
communication between networked devices is increasingly important. communication between networked devices is increasingly important.
The communication mechanism between these devices must be able to The communication mechanism between these devices must be able to
skipping to change at page 1, line 47 skipping to change at page 1, line 50
This draft describes a method by which a host may automatically give This draft describes a method by which a host may automatically give
itself a link-local IPv4 address, so that it will be able to use IP itself a link-local IPv4 address, so that it will be able to use IP
applications in the absence of an IP address management mechanism, applications in the absence of an IP address management mechanism,
such as DHCP. This mechanism is in use today by a few operating such as DHCP. This mechanism is in use today by a few operating
systems, and additional information on those implementations is also systems, and additional information on those implementations is also
provided. provided.
1. Introduction 1. Introduction
Now that networked applications are becoming more prevalent, Now that networked applications are becoming more prevalent, operat-
operating systems are migrating towards more scalable network ing systems are migrating towards more scalable network protocols
protocols such as IP, allowing them to work in all sizes of such as IP, allowing them to work in all sizes of environments.
environments. However, there is a price to pay for this migration
-- IP requires configuration that other protocols (IPX, Appletalk) Internet Draft IPv4 Auto-Configuration MO] 0dy], 0*year]
do not require.
However, there is a price to pay for this migration -- IP requires
configuration that other protocols (IPX, Appletalk) do not require.
Dynamic creation of usable ad-hoc networks is very useful when there Dynamic creation of usable ad-hoc networks is very useful when there
are only a few machines on the entire network. (For example, a are only a few machines on the entire network. (For example, a
dentist's office may only have a couple of machines.) In order to dentist's office may only have a couple of machines.) In order to
allow a site such as this to use IP, the machines must each be allow a site such as this to use IP, the machines must each be con-
configured with an IP address. OS's wish to retain the minimal figured with an IP address. OS's wish to retain the minimal confi-
configuration that was necessary under their non-IP network stacks. guration that was necessary under their non-IP network stacks.
Dynamic configuration protocols such as DHCP [DHCP] allow a site Dynamic configuration protocols such as DHCP [DHCP] allow a site
administrator to take care of the network configuration for a administrator to take care of the network configuration for a
machine remotely. By requesting network parameters via DHCP, the machine remotely. By requesting network parameters via DHCP, the
site administrator may provide all information necessary without the site administrator may provide all information necessary without the
host's owner having to do anything. However, not all sites have a host's owner having to do anything. However, not all sites have a
central administrator to take care of this. central administrator to take care of this.
To accommodate unmanaged networks, the OS may decide to To accommodate unmanaged networks, the OS may decide to intelli-
intelligently choose an IP address for itself. These addresses are gently choose an IP address for itself. These addresses are only
only valid for the local network. valid for the local network.
This document describes a method by which an OS may determine This document describes a method by which an OS may determine
whether or not to autoconfigure itself an IP address, as well as how whether or not to autoconfigure itself an IP address, as well as how
to inter-operate cleanly with an existing managed infrastructure, to inter-operate cleanly with an existing managed infrastructure,
allowing a host to easily move between managed and unmanaged network allowing a host to easily move between managed and unmanaged network
segments. segments.
1.1. Conventions Used in the Document 1.1. Conventions Used in the Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS]. document are to be interpreted as described in [KEYWORDS].
1.2. Terminology 1.2. Terminology
Site Administrator Site Administrator
A Site Administrator is the person or organization A Site Administrator is the person or organiza-
responsible for handing out IP addresses to client tion responsible for handing out IP addresses to
machines. client machines.
DHCP Client A DHCP Client is an Internet host using DHCP to DHCP Client A DHCP Client is an Internet host using DHCP to
obtain configuration parameters such as a network obtain configuration parameters such as a network
address. address.
DHCP Server A DHCP Server is an Internet host that returns DHCP Server A DHCP Server is an Internet host that returns
configuration parameters to DHCP Clients. configuration parameters to DHCP Clients.
Internet Draft IPv4 Auto-Configuration MO] 0dy], 0*year]
1.3. Usage Clarification 1.3. Usage Clarification
This document describes a method by which a host may automatically This document describes a method by which a host may automatically
choose an IPv4 address in the absence of a central service to choose an IPv4 address in the absence of a central service to main-
maintain and hand out addresses. This is not designed to replace tain and hand out addresses. This is not designed to replace this
this functionality, but to basicly provide it in small networks. functionality, but to basicly provide it in small networks.
This SHOULD NOT be used for large-scale networks. As more and more This SHOULD NOT be used for large-scale networks. As more and more
machines begin to use this mechanism on a network, startup times for machines begin to use this mechanism on a network, startup times for
these machines will begin to increase, as the chance of collisions these machines will begin to increase, as the chance of collisions
will rise. will rise.
Addresses allocated by this mechanism MUST NOT be routed by any Addresses allocated by this mechanism MUST NOT be routed by any net-
network device. The addresses are designed to be link local work device. The addresses are designed to be link local addresses.
addresses. Link local address are to be, by definition, restricted Link local address are to be, by definition, restricted to the local
to the local network segment. Allocation of link-local addresses in network segment. Allocation of link-local addresses in an IPv6 net-
an IPv6 network is described in [IPv6SAC]. work is described in [IPv6SAC].
Finally, it should be noted that this functionality is designed to Finally, it should be noted that this functionality is designed to
work on a host that is running a DHCP Client. Hosts that are not work on a host that is running a DHCP Client. Hosts that are not
running a DHCP Client are not considered in this draft, and MUST NOT running a DHCP Client are not considered in this draft, and MUST NOT
attempt to use these mechanisms to configure an IP address, as these attempt to use these mechanisms to configure an IP address, as these
no-dhcp-client hosts will not interoperate with the existing no-dhcp-client hosts will not interoperate with the existing infras-
infrastructure correctly. (This mechanism relies on the DHCP Server tructure correctly. (This mechanism relies on the DHCP Server for
for some information, and if a host can not receive this some information, and if a host can not receive this information, it
information, it will not be fully informed.) will not be fully informed.)
2. To Choose or Not To Choose 2. To Choose or Not To Choose
The first thing an Internet host should do is attempt to get an The first thing an Internet host should do is attempt to get an
administratively assigned address using DHCP. Only after the DHCP administratively assigned address using DHCP. Only after the DHCP
process fails should a host use the methods later for process fails should a host use the methods later for autoconfigura-
autoconfiguration. tion.
2.1. Obtaining an Address via DHCP 2.1. Obtaining an Address via DHCP
A host begins by requesting an IP address via DHCP [DHCP]. This is A host begins by requesting an IP address via DHCP [DHCP]. This is
done by sending out a DHCPDISCOVER message, with various tags set done by sending out a DHCPDISCOVER message, with various tags set
indicating what options the DHCP Client would like to receive indicating what options the DHCP Client would like to receive infor-
information for [DHCPOPT]. The DHCP Client SHOULD also send the mation for [DHCPOPT]. The DHCP Client SHOULD also send the DHCP
DHCP AutoConfigure option described in [DHCPAC]. AutoConfigure option described in [DHCPAC].
According to [DHCP], Section 4.4.1, the amount of time over which a According to [DHCP], Section 4.4.1, the amount of time over which a
DHCP Client should listen for DHCPOFFERS is implementation DHCP Client should listen for DHCPOFFERS is implementation depen-
dependant. During this time, if a DHCPOFFER is received, network dant. During this time, if a DHCPOFFER is received, network confi-
configuration MUST occur as described in [DHCP] and [DHCPAC]. guration MUST occur as described in [DHCP] and [DHCPAC].
If, during this time, no valid DHCPOFFERS are received, the DHCP If, during this time, no valid DHCPOFFERS are received, the DHCP
Internet Draft IPv4 Auto-Configuration MO] 0dy], 0*year]
Client is free to autoconfigure an IP address according to section 3 Client is free to autoconfigure an IP address according to section 3
of this document. of this document.
2.2. Rebinding an Existing IP Address 2.2. Rebinding an Existing IP Address
If the DHCP Client already has an existing IP address, it MUST If the DHCP Client already has an existing IP address, it MUST fol-
follow the instructions outlined in [DHCP]. If the client winds up low the instructions outlined in [DHCP]. If the client winds up
back in the INIT state, refer to section 2.1 of this document. back in the INIT state, refer to section 2.1 of this document.
3. Choosing an IP Address 3. Choosing an IP Address
Once a DHCP Client has determined it must auto-configure an IP Once a DHCP Client has determined it must auto-configure an IP
address, it chooses an address. The algorithm for choosing an address, it chooses an address. The algorithm for choosing an
address is implementation dependant. The address range to use MUST address is implementation dependant. The address range to use MUST
be "169.254/16", which is registered with the IANA as the LINKLOCAL be "169.254/16", which is registered with the IANA as the LINKLOCAL
net. net.
skipping to change at page 5, line 6 skipping to change at page 5, line 5
address of all 0s is referred to as an "ARP probe". address of all 0s is referred to as an "ARP probe".
While waiting for a possible response to this request, the client While waiting for a possible response to this request, the client
MUST also listen for other ARP probes for the same address (but not MUST also listen for other ARP probes for the same address (but not
from its own hardware address). This will occur if two (or more) from its own hardware address). This will occur if two (or more)
hosts are attempting to autoconfigure the exact same address. If hosts are attempting to autoconfigure the exact same address. If
the client receives a response to the ARP request, or sees another the client receives a response to the ARP request, or sees another
ARP probe for the same address, it MUST consider the address as ARP probe for the same address, it MUST consider the address as
being in use, and move on. being in use, and move on.
Internet Draft IPv4 Auto-Configuration MO] 0dy], 0*year]
Clients SHOULD randomize their IP address selection algorithm, to Clients SHOULD randomize their IP address selection algorithm, to
help keep clients from becoming stuck in a loop with other clients help keep clients from becoming stuck in a loop with other clients
while trying to allocate an address. Algorithm designers MUST make while trying to allocate an address. Algorithm designers MUST make
sure that their algorithm will not cause the client IP selection sure that their algorithm will not cause the client IP selection
process to become stuck when interoperating with any other possible process to become stuck when interoperating with any other possible
algorithms. algorithms.
4. Ongoing Checks for a DHCP Server 4. Ongoing Checks for a DHCP Server
When the client originally sent out it's request, there may have When the client originally sent out it's request, there may have
been a network problem stopping the DHCP Server from responding. To been a network problem stopping the DHCP Server from responding. To
make sure this is not the case, a host with an auto-configured IP make sure this is not the case, a host with an auto-configured IP
address MUST keep checking for an active DHCP Server. To do this, address MUST keep checking for an active DHCP Server. To do this,
the host MUST attempt to fetch an IP address as described in section the host MUST attempt to fetch an IP address as described in section
1 of this document. 1 of this document.
When rechecking, if the host has determined no DHCP Server is When rechecking, if the host has determined no DHCP Server is
responding, it MUST wait a period of time and try again. This responding, it MUST wait a period of time and try again. This
interval is tunable. The suggested default for Ethernet interval is tunable. The suggested default for Ethernet implementa-
implementations is to check every 5 minutes. tions is to check every 5 minutes.
If the host receives a response from a DHCP Server, it MUST respond If the host receives a response from a DHCP Server, it MUST respond
and attempt to obtain a lease from the server (per the DHCP and attempt to obtain a lease from the server (per the DHCP specifi-
specification). If the client is successful in obtaining a new cation). If the client is successful in obtaining a new lease, and
lease, and the internet host does not support multiple addresses on the internet host does not support multiple addresses on the inter-
the interface being configured, it MUST drop any existing auto- face being configured, it MUST drop any existing auto-configured IP
configured IP address, and all active connections, while moving to address, and all active connections, while moving to the new
the new address. If the internet host does support multiple address. If the internet host does support multiple addresses on
addresses on the interface, it MAY keep the auto-configured address the interface, it MAY keep the auto-configured address active.
active.
If the DHCP response is an AutoConfigure [DHCPAC] response set to If the DHCP response is an AutoConfigure [DHCPAC] response set to
"DoNOTAutoConfigure", the host MUST drop all connections, give up "DoNOTAutoConfigure", the host MUST drop all connections, give up
any existing auto-configured IP address, and continue checking for a any existing auto-configured IP address, and continue checking for a
DHCP server. DHCP server.
WARNING: If the client drops all connections, the user may lose data WARNING: If the client drops all connections, the user may lose data
being access over the existing connections. The operating system being access over the existing connections. The operating system
SHOULD do everything it can to allow existing clients to finish SHOULD do everything it can to allow existing clients to finish
using all existing connections before closing them. It SHOULD NOT using all existing connections before closing them. It SHOULD NOT
allocate any further connections using the auto-configured IP allocate any further connections using the auto-configured IP
address. address.
5. Current Vendor Implementations 5. Current Vendor Implementations
As of this writing, Microsoft and Apple have operating systems that As of this writing, Microsoft and Apple have operating systems that
contain this functionality. Descriptions of the implementation contain this functionality. Descriptions of the implementation
dependant parts are listed below. dependant parts are listed below.
Internet Draft IPv4 Auto-Configuration MO] 0dy], 0*year]
5.1. Microsoft Windows 98 5.1. Microsoft Windows 98
With the initial release of Windows 98, Microsoft introduced auto- With the initial release of Windows 98, Microsoft introduced auto-
configuration functionality. When developed, the AutoConfig configuration functionality. When developed, the AutoConfig
[DHCPAC] specification did not exist, so the initial release does [DHCPAC] specification did not exist, so the initial release does
not contain this functionality. not contain this functionality.
The Win98 DHCP Client sends out a total of 4 DHCPDISCOVERs, with an The Win98 DHCP Client sends out a total of 4 DHCPDISCOVERs, with an
inter-packet interval of 6 seconds. When no response is received inter-packet interval of 6 seconds. When no response is received
after all 4 packets (24 seconds), it will auto-configure an address. after all 4 packets (24 seconds), it will auto-configure an address.
skipping to change at page 7, line 10 skipping to change at page 7, line 5
Another security concern is the DOS attack that may be made on the Another security concern is the DOS attack that may be made on the
local subnet which stops all machines from being able to allocate an local subnet which stops all machines from being able to allocate an
IP address. A malicious host on the local wire may listen for ARP IP address. A malicious host on the local wire may listen for ARP
probes, and respond with it's own ARP probe. This will stop the probes, and respond with it's own ARP probe. This will stop the
auto-configuring machine from using that address, and it will move auto-configuring machine from using that address, and it will move
on to the next one. Eventually, it will run out of addresses to on to the next one. Eventually, it will run out of addresses to
attempt, and will give up. The use of DHCP removes this attack, attempt, and will give up. The use of DHCP removes this attack,
leaving only the concerns described in [DHCP]. leaving only the concerns described in [DHCP].
Internet Draft IPv4 Auto-Configuration MO] 0dy], 0*year]
Finally, machines that rely on this for communication over a large Finally, machines that rely on this for communication over a large
network may allocate the same address if the network itself is network may allocate the same address if the network itself is seg-
segmented when the machines boot. If the link between two machines mented when the machines boot. If the link between two machines is
is down when they boot, they may both auto-configure the same down when they boot, they may both auto-configure the same address.
address. However, when the network link returns, there will be However, when the network link returns, there will be numerous prob-
numerous problems (ARP caches, etc.) There is currently no way to lems (ARP caches, etc.) There is currently no way to solve this
solve this auto-configuration problem without causing all hosts auto-configuration problem without causing all hosts involved to
involved to re-autoconfigure IP addresses. The use of DHCP to re-autoconfigure IP addresses. The use of DHCP to configure hosts
configure hosts on a subnet will solve this, and hosts that on a subnet will solve this, and hosts that implement this confi-
implement this configuration mechanism will behave appropriately on guration mechanism will behave appropriately on a DHCP managed net-
a DHCP managed network in which the DHCP server is not initially work in which the DHCP server is not initially available.
available.
7. Acknowledgments 7. Acknowledgments
I'd like to thank Microsoft and Apple for their help in writing this I'd like to thank Microsoft and Apple for their help in writing this
document. document.
8. Copyright 8. Copyright
Copyright (C) The Internet Society 1999. All Rights Reserved. Copyright (C) The Internet Society 1999. All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of develop-
developing Internet standards in which case the procedures for ing Internet standards in which case the procedures for copyrights
copyrights defined in the Internet Standards process must be defined in the Internet Standards process must be followed, or as
followed, or as required to translate it into languages other than required to translate it into languages other than English.
English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
9. References 9. References
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997 March 1997
<ftp://ds.internic.net/rfc/rfc2131.txt> Internet Draft IPv4 Auto-Configuration MO] 0dy], 0*year]
[DHCPOPT] Alexander, S. and Droms, R., "DHCP Options and BOOTP <ftp://ftp.isi.edu/in-notes/rfc2131.txt>
Vendor Extension", RFC 2132, March 1997
<ftp://ds.internic.net/rfc/rfc2132.txt> [DHCPAC] Troll, R., "DHCP Option to Disable Stateless Auto-
Configuration in IPv4 Clients", RFC 2563, May 1999
[KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate <ftp://ftp.isi.edu/in-notes/rfc2563.txt>
Requirement Levels", RFC 2119, March 1997
<ftp://ds.internic.net/rfc/rfc2119.txt> [DHCPOPT] Alexander, S. and Droms, R., "DHCP Options and BOOTP Ven-
dor Extension", RFC 2132, March 1997
[IPv6SAC] Thomson, S. and Narten, T., "IPv6 Stateless Address <ftp://ftp.isi.edu/in-notes/rfc2132.txt>
Autoconfiguration", RFC 2462, December 1998
<ftp://ds.internic.net/rfc/rfc2462.txt> [IPv6SAC] Thomson, S. and Narten, T., "IPv6 Stateless Address Auto-
configuration", RFC 2462, December 1998
[DHCPAC] Troll, R., "DHCP Option to Disable Stateless Auto- <ftp://ftp.isi.edu/in-notes/rfc2462.txt>
Configuration in IPv4 Clients", RFC Work in progress, January
1999
<ftp://ds.internic.net/rfc/rfcWork in progress.txt> [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997
<ftp://ftp.isi.edu/in-notes/rfc2119.txt>
10. Author's Address 10. Author's Address
Ryan Troll Ryan Troll
@Home Network Excite@Home Network
425 Broadway 450 Broadway
Redwood City, CA 94063 Redwood City, CA 94063
Phone: (650) 569-6031 Phone: (650) 556-6031
EMail: rtroll@corp.home.net EMail: rtroll@excitehome.net
 End of changes. 

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