Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP
Erik Guttman <[email protected]>
| Newsgroups | gmane.ietf.zeroconf,gmane.ietf.dhc |
|---|---|
| Message-ID | <[email protected]> |
Ted Lemon wrote:
>
> On Tuesday, September 23, 2003, at 05:14 AM, Erik Guttman wrote:
>
>> The text supplied by Bernard has the property that it does not
>> specify any new behavior for DHCP. The new text makes it clear
>> that an implementation of IPv4LL must attempt to obtain configuration
>> via DHCP according to the DHCP specification, even if it has failed
>> to in the past. I think this satisfies Ted's concern:
>>
>> Ted Lemon wrote:
>> > The correct fix is to make sure that the DHCP client does not in fact
>> > modify its behaviour to make IPv4ll work, but rather to modify IPv4ll
>> > so that it doesn't interfere with the operation of the DHCP client.
>
>
> The new text that Bernard has supplied, at least as specified in your
> proposed resolution for LL34, does not seem to address the problem at
> all. The problem is that right now the IPv4ll protocol specification
> creates a situation in which there is an incentive to break the DHCP
> client in order to get correct IPv4ll behavior.
I do not follow you. Please see my assessment of the current draft,
below. I see nowhere, except where it is stated that DHCP SHOULD NOT
configure from the IPv4 LL prefix, that we introduce direct or indirect
requirements on DHCP or DHCP client behavior.
> My goal is not to
> break the DHCP client less. It is to not break it at all. If you
> don't agree with this goal, can you please try to build consensus by
> explaining why you don't agree with it?
I do agree with you. The DHCP client should not be broken or effected
by IPv4LL. The host stack which uses both will of course be more
complex than one which does not.
> Also, I think that you should withdraw the statement that your proposed
> solution to LL34 has been accepted, since there was no discussion on it,
> and thus no opportunity for consensus.
There was plenty of discussion about it both here and on the zeroconf
list, but that is neither here nor there. I want to satisfy your
technical concern even if I can't respond to your liking about the
process by which we've been demanding decision points in otherwise
circular ZEROCONF discussions.
> I certainly do not agree that
> it solves the stated problem. Possibly I am reading too much into the
> problem statement, but if so, I think we need a new discussion item:
> "IPv4LL state machine must not place requirements on DHCPv4 state machine."
What if we add this sentence, verbatim, to the end of section 2.11?
This specification places no requirements on the DHCPv4 state machine.
-----------
Let's be 100% clear what the requirements that ZEROCONF is placing on
DHCP. The current text in
http://www.ietf.org/internet-drafts/draft-ietf-zeroconf-ipv4-linklocal-10.txt
regarding DHCP is as follows (an exhaustive excerpt). I add emphasis
to aid those who follow the DHC list but not the zeroconf list.
Abstract
To participate in wide-area IP networking, a host needs to be
configured, either manually by the user or automatically from a
source on the network such as a DHCP server. Unfortunately, such
*******************
external configuration information may not always be available. It
***************************************************************
is therefore beneficial for a host to be able to depend on a useful
subset of IP networking functions even when no configuration is
available. This document describes how a host may automatically
configure an interface with an IPv4 address within the 169.254/16
prefix that is valid for communication with other devices connected
to the same physical (or logical) link.
=> no requirements on dhcp
1. Introduction
As the Internet Protocol continues to grow in popularity, it becomes
increasingly valuable to be able to use familiar IP tools such as FTP
not only for global communication, but for local communication as
well. For example, two people with laptop computers supporting IEEE
802.11 Wireless LANs [802.11] may meet and wish to exchange files.
It is desirable for these people to be able to use IP application
*****************************************************
software without the inconvenience of having to manually configure
******* *********
static IP addresses or set up a DHCP server [RFC2131].
******************************
=> no requirements on dhcp
1.6. Alternate Use Prohibition
Note that addresses in the 169.254/16 prefix SHOULD NOT be configured
***********************************************************
manually or by a DHCP server. Manual or DHCP configuration may cause
****************
a host to use an address in the 169.254/16 prefix without following
the special rules regarding duplicate detection and automatic
configuration that pertain to addresses in this prefix. While
[RFC2131] indicates that a DHCP client SHOULD probe a newly received
address with ARP, this is not mandatory. Similarly, while [RFC2131]
recommends that a DHCP server SHOULD probe an address using an ICMP
Echo Request before allocating it, this is also not mandatory, and
even if the server does this, Link-Local IPv4 addresses are not
routable, so a DHCP server not directly connected to a link cannot
detect whether a host on that link is already using the desired Link-
Local IPv4 address.
Administrators wishing to configure their own local addresses (using
manual configuration, a DHCP server, or any other mechanism not
described in this document) should use one of the existing private
address prefixes [RFC1918], not the 169.254/16 prefix.
=> SHOULD requirement placed on DHCP administration
2.6.1. Source Address Usage
Since each interface on a host may have a Link-Local IPv4 address in
*********************************
addition to zero or more other addresses configured by other means
************ *********************
(e.g. manually or via a DHCP server), a host may have to make a
**** *****************
choice about what source address to use when it sends a packet or
initiates a TCP connection.
=> no requirements placed on DHCP
2.8. Link-Local Packets are Local
It should be understood that this mediated communication is not
mandatory; it is an option afforded to designers of extremely simple
devices. Any designer of a device desiring unmediated communication
**********************************************************
outside the local link need only implement today's conventional IP
******************************************************************
host software (e.g. a DHCP client) in order to enjoy the same degree
**********************************
of global addressability available to other conventional IPv4 hosts.
Such networked devices should of course implement a degree of
security appropriate to being connected to a global public network.
=> no requirements on DHCP
2.11. Transition from Link-Local to Routable Address
As discussed in Section 1.7, use of a routable address is preferred
to assignment of a Link-Local IPv4 address. A Link-Local IPv4 address
*************************
can be configured due to transient failures, such as incomplete link-
*****************
layer authentication, spanning tree convergence issues, or because a
*********
DHCP server failed to respond to an initial query, or is inoperative
*****************************
for some time.
Where a Link-Local IPv4 address is assigned due to a transient
failure, experience has shown that five minutes (see Appendix A.2)
*********************************************************
may be too long an interval to wait prior to attempting to configure
********************************************************************
with DHCP. This document does not specify a strategy for quickly
*****************************************************************
recovering a routable address in situations where a Link-Local IPv4
*******************************************************************
address is assigned due to a transient failure. In situations where
*******************************************************************
many hosts are present on a single subnet, frequent attempts to
***************************************************************
contact the DHCP server could result in a heavy traffic load. Further
************************************************************
discussion of this issue is provided in [DNAv4].
=> no requirements on DHCP. The current text states what existing
implementations do, and that this has problems. Apparently they
are ignoring the DHCP recommendations, which I hope I get right:
RFC2131, section 3 subsection 5 which suggests that
The client should choose to retransmit
the DHCPREQUEST enough times to give adequate probability of
contacting the server without causing the client (and the user of
that client) to wait overly long before giving up; e.g., a client
retransmitting as described in section 4.1 might retransmit the
DHCPREQUEST message four times, for a total delay of 60 seconds,
before restarting the initialization procedure. If the client
receives neither a DHCPACK or a DHCPNAK message after employing the
retransmission algorithm, the client reverts to INIT state and
restarts the initialization process.
and RFC2131, section 4.4.1 which requires (SHOULD) that a random
delay of 1-10 seconds elapse before a DHCPDISCOVER packet is sent
while in INIT state.
The Microsoft and Apple software which implements the '5 minute'
delay before initiating DHCP configuration lengthened the suggested
1-10 second wait before reentering INIT state.
The appendices describe current practice and do not place any
requirements on DHCP.
========================================================================
Erik