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]> |
Mika Liljeberg wrote:
> Nice state machine, although it does not address the case where it is
> uncertain whether a configured address is not working or not. In this
> case a node must be able to configure a LL address, advertise it, and
> allow applications to fall back on it. There are two very common ad-hoc
> cases where this can happen: 1) manually configured address in an
> invalid context, and 2) valid DHCP lease in an invalid context.
Mika,
You are not satisfied with the arcs in the state machine which
lead to 'EXIT' since they do not spell out the exact conditions
in which an interface 'has been configured'.
I remind (as wg chair)
- We have already ruled out the formal application of IPv4LL
'in all cases' or 'to provide IP configuration in the case
of *misconfiguration*' to provide robustness, etc.
I believe (as wg participant, not as wg chair)
- We must rule out the case where the IPv4LL spec 'overrules'
manually configured addresses.
- We must cautiously state what it means to be configured with
a DHCP - as we may 'wake up' with a valid lease in a context
other than that which DHCP configured the host.
We have already had this discussion. It hinges upon a passage
in RFC 2131:
3.7 When clients should use DHCP
A client SHOULD use DHCP to reacquire or verify its IP address and
network parameters whenever the local network parameters may have
changed; e.g., at system boot time or after a disconnection from the
local network, as the local network configuration may change without
the client's or user's knowledge.
If a client has knowledge of a previous network address and is unable
to contact a local DHCP server, the client may continue to use the
previous network address until the lease for that address expires.
Note the word >>may<<.
Thus, the implementor of IPv4LL has discretion. I suggest that we
1) add a new section:
2.12 Transition from Routable Address to Link-Local
A host may 'wake up' (see Section 2.2) with a valid DHCP
lease. According to RFC 2131, Section 3.7:
A client SHOULD use DHCP to reacquire or verify its
IP address and network parameters whenever the local
network parameters may have changed; e.g., at system
boot time or after a disconnection from the local
network, as the local network configuration may change
without the client's or user's knowledge.
If a client has knowledge of a previous network address
and is unable to contact a local DHCP server, the client
may continue to use the previous network address until
the lease for that address expires.
Before a host with a valid DHCP address configures an IPv4
LL address it MUST use DHCP to attempt to reacquire or
verify its IP address and network parameters. In the case
where the the DHCP client is unable to contact a local DHCP
server, the behavior of the IPv4 link-local configuration
implementation is not specified. The implementor has a
choice: Either abandon the DHCP lease and configure a
link-local address or retain the previous network address.
Implementors are faced with a trade-off: 'Robustness to
DHCP Server Unresponsiveness' versus 'Rapid Transition to
Autoconfigured State'.
If DHCP configuration parameters continue to be used
despite the DHCP server's lack of response, the client
will be more robust to transient DHCP server inavailability.
The disadvantage is that a mobile host removed from the
context in which it received a long-duration lease will not
autoconfigure. This means, for example, that a laptop
computer may continue to use the configuration it received
'at work' even though the owner is currently 'at home.'
If autoconfiguration occurs as soon as it has been determined
that the DHCP client is unable to contact a local DHCP server,
the host will respond to 'waking up' in a new network
environment. This will allow the host to communicate with
other hosts which implement this specification on the link
as soon as possible. The disadvantage of this strategy is
that it will encourage unneeded and disruptive interface
configuration changes in the case where a DHCP server is
unresponsive for a short period of time.
Retaining the configuration supplied by DHCP emphasizes
stability of service for hosts on centrally configured
networks. This is the most prevalent networking context
today. Users are easily annoyed if their hosts become
reconfigured and unusable for several minutes at a time,
which is the likely outcome if a spurious configured to
link-local transition is undertaken. Obtaining
autoconfiguration parameters as quickly as possible
(according to the protocol timers defined by RFC 2131 and
this specification) benefits the mobile user whose host
finds itself in different networking contexts and wishes
to gain access to their resources immediately.
2) add the state machine below to the IPv4 LL specification in a
new section:
2.13 IPv4 Linklocal Configuration State Machine
<as cited below>
I think that this addresses your concerns and would greatly improve
the draft. This gets to the heart of Ted's concerns, too, I think.
Erik
> On Wed, 2003-10-01 at 11:34, Erik Guttman wrote:
>>We do not have a diagram of a state machine for IPv4LL, but perhaps
>>that would be very useful. I think it would look something like
>>this:
>>
>> Interface is active and has no <---------------------+
>> IPv4 address configured |
>> | |
>> v interface has IPv4 addr configured? |
>> +--> INIT ---------------------------------------> EXIT
>> | | 2.2 1.7 ^ ^
>> | v <-------------------+ | |
>> | SELECT <---+ | | |
>> | | 2.1 | ARP with | | |
>> | v | claimed | | |
>> | CLAIM | address ADAGIO | |
>> | ^ | 2.2.1| received ^ | |
>> | 2.2.1 | v --+ |2.2.1 | |
>> | CLAIM-WAIT ------------------+ | |
>> | | 2.2.1 -----------------------------------+ |
>> 2.5 | v interface has IPv4 addr configured? |
>>
>> DOUBT ANNOUNCE 1.7 |
>>
>> ^| | 2.4 |
>> |+-> v interface has IPv4 addr configured? |
>> +-- CONFIGURED ------------------------------> DEPRECATED
>> 2.5 ^ | 2.5 1.7
>>conflict! | |
>> +-----+
>> defend
>>
>> State Behavior
>> ========== =============================================
>> INIT Host has no configured IPv4 address on an
>> interface. INIT waits before entering SELECT
>> state. If INIT detects it has been configured
>> during this time, INIT goes to EXIT state. See
>> Section 2.2.
>>
>> SELECT Select a suitable address. See Section 2.1. The
>> only possible transition is to CLAIM state.
>>
>> A special case of SELECT is where the host has
>> woken up and previously had a link-local address
>> configured. In this case, the previously configured
>> is selected. See Section 2.2.
>>
>> CLAIM Send a probe as per Section 2.2.
>>
>> CLAIM-WAIT Wait for any ARP messages with the claimed
>> address originating from a different sender.
>>
>> If interface is configured during this wait
>> period enter EXIT state, do not configure an
>> IPv4 LL address. See Section 1.7.
>>
>> If an ARP message indicates that the selected
>> address is in use, and this is the first through
>> nineth retry, enter SELECT state. If this is
>> the tenth or more retry, enter ADAGIO state.
>> See Section 2.2.1.
>>
>> If no ARP message is detected as the result of
>> the probe after the wait duration ends, and this
>> is the first or second try, return to CLAIM state.
>> If this is the third try, enter the CONFIGURED
>> state. See Section 2.2.1.
>>
>> ADDAGIO Wait at least a minute then enter SELECT state.
>>
>> ANNOUNCE Send ARP announcements the enter CONFIGURED
>> state.
>>
>> CONFIGURED The link-local address has been configured for
>> the interface and is now usable. The host must
>> respond to three events.
>>
>> If a claim is detected, respond with a defending
>> ARP. Stay in CONFIGURED state.
>>
>> If an ARP with a conflicting assignment of the
>> configured address is detected, defense may be
>> undertaken once (enter the state of DOUBT) or
>> go directly to INIT state, surrendering the
>> configured address.
>>
>> DOUBT If an ARP with a source address is detecting
>> which conflicts with the configured address
>> during 10 seconds, proceed to INIT state.
>> See Section 2.5.
>>
>> Otherwise, the conflicting use of the address
>> has been defended against. Return to the
>> CONFIGURED state. See Section 2.5.
>>
>> DEPRECATED This state is entered when a link-local address
>> has been autoconfigured for an interface, then
>> subsequently the interface receives a configured
>> address (as from DHCP). In this state, new
>> connections are established with the configured
>> address and the link-local address is not advertised.
>> Eventually, one SHOULD transition to EXIT state.
>> See Section 1.7.
>>
>> EXIT Cease using the IPv4 link-local address, do not
>> attempt to configure another such address unless
>> an interface exists for which there is no IPv4
>> link-local address configured.
>>
>>
>>
>>I hope that this makes it clear: In each case where there is
>>a transition marked "interface has IPv4 addr configured? 1.7"
>>this could be caused by the DHCP state machine entering BOUND
>>state. It is also possible to transition from EXIT to INIT
>>in the case where a configured address is no longer available.
>>We do not enter into a full discussion of this transition in
>>this specification. It is considered in more detail in
>>http://www.ietf.org/internet-drafts/draft-ietf-dhc-dna-ipv4-02.txt
>>
>>Erik
>>
>