Re: [dhcwg] WG consensus action: ACCEPT LL34 better transition to routable from v4LL using DHCP

Mika Liljeberg wrote:

> I know we have a (more than rough) WG consensus to not configure a
> link-local at the same time with a routable address but we should not
> take that contraint beyond the point where it stops being useful.
> Remember that we made this decision to protect a small class of
> applications that may fail, because they are unaware that they are not
> supposed to pass LLs around.
> 
> If it is not possible to verify that a routable address is working we're
> faced with a situation where nearly ALL applications will break (due to
> having no connectivity at all) if we make the wrong choise. In this
> situation, having BOTH the routable address and the LL configured at the
> same time is simply the least desctructive option.

In the case of the transition from unconfigured to configured there
is clear consensus that one should 'give up' (that is: stop advertising,
stop initiating new connections from and eventually stop accepting
communication from) a link-local configured address.

In the case of the transition from configured to unconfigured there
is no clear consensus yet.

Choices are
   - give up dhcp configuration and configure link-local
   - hold onto dhcp configuration and don't configure link-local

These I discussed in the text I suggested.  (Does that text make sense?)

   - hold onto dhcp configuration and configure link-local

This is a problematic situation in that the host is now 'multihomed',
with all the attendant problems we have discussed ad nauseum.  One
way to address this is to mention that this implementation is in no
way ruled out, but neither is it specified, and refer anyone
interested in pursuing this option to section 3.

> So what I'm trying to say is, if we have a valid DHCP lease and we can't
> get a response from the DHCP server, there is absolutely no reason why
> we should discard that lease prior to configuring a LL. In this case it
> is acceptable to configure both. I'm not proposing that an
> implementation SHOULD configure both, merely that it MAY do so. In any
> case the LL can and should be deprecated as soon as the DHCP server
> comes back online.
> 
> As for a manually configured addresses, there is absolutely no reason to
> prevent a manually configured address from coexisting with a LL address,
> since the admin can also manually disable the LL if it is not desired.
> If the admin wants to have both why should be care?

Manual intervention of host configuration is not always possible (to
deconfigure a link-local address, for example).

The point is, the sensible default policy is that when the host is
configured manually, link-local addresses do not get configured.
If an implementor wishes to venture into multihoming-territory, we
do not forbid it, but we do list a set of issues of which the
implementor must consider and address.  The specification and its
state machine assume the implementor will not go this way.  In the
case of an interface configured with more than one addresses, the
state machine is more complex since it needs to take into account
such things as changes to the host's routing table.

Erik

-----------
ps. please comment on suggested text (from previous message):

 >       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.