Subject: [dhcwg] Re: WG consensus action: ACCEPT LL34

From: Bernard Aboba <[email-masked]>
Date: Tue, 7 Oct 2003 16:16:09 -0700 (PDT)

If a host has an IP address with a valid lifetime, DHCP (or RS/RA for that
matter) is not required to confirm it.  All that is necessary is a
reachability test to the default gateway, confirming that the host is on
the network in which the address is valid.

The text below makes it seem like it is necessary for the host to send a
DHCPREQUEST whenever it wakes up.  This is not the case.

I'd rather see text relating to transition routable to IPv4LL
addresses, like the text relating to transition from LLv4
to routable addresses, handled outside of the IPv4LL specification,
such as in the DNAv4 specification.

Erik Guttman spoke thusly:

         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.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Oct 2003 15:40:12 -0500

That's basically right, but remember that there are cases where bad 
timing can result in a network link that is in fact correctly 
configured looking like it's got a stale configuration - if you are at 
the edge of an 802.11 network, you will fade in and out, and if you are 
moving around in an 802.11 network that has multiple access points, as 
you wander from one coverage area to the next you may experience 
outages that would trigger a configuration re-check that would fail, 
even though the same check thirty seconds later would succeed.   In 
this situation, we do not want to toss the IP address on the interface, 
because it means that every active TCP connection is going to be shot 
in the head.