new issue: [LL40] IPv4 LL does not alter the behavior of the DHCPv4 state machine

We need to evaluate whether to make this change.

===========================================================================
Description of Issue  IPv4 LL does not alter the behavior of the DHCPv4 
state machine
Submitter Name  Ted Lemon
Submitter Email Address  [email protected]
Date first submitted  24 Oct 03
Reference
Comment Type ['T'echnical | 'E'ditorial]  T
Priority ['S' Must fix | '1' Should fix | '2' May fix ]  1
Section  2.12 (new section)
Rationale/Explanation of issue:
Lengthy description of problem:

So I think the right answer to this question is to simply decouple
the IPv4LL and DHCP state machines. As long as the IPV4ll state machine
can reach out and touch the DHCP state machine, it's likely to do things
that break the operation of the DHCP state machine.

So the right answer is, IMHO, that if the IPv4LL believes that it *may* be
in a state where connectivity has been lost, it should configure itself a
link-local address, and when it leaves that state, it should make the
transition back to using the globally routable address exclusively.

In other words, the IPv4LL state machine should watch the DHCP state
machine and make decisions at least in part based on what state the DHCP
client is in, but the DHCP client should not change its behavior at all to
accomodate this. So if the DHCP client is in the INIT-REBOOT state and
doesn't get an answer from the DHCP server, it should continue using its
globally routable address. But the IPv4LL agent should make note of this,
and configure an IPv4LL address.


Requested Change: Add section this new section:

! 2.12 Interaction between DHCPv4 client and IPv4ll state machines
!
! A device that implements both IPv4ll and a DHCPv4 client should not
! alter the behavior of the DHCPv4 client to accommodate IPv4
! Link-Local configuration. Some early implementations of IPv4
! Link-Local that were tightly coupled to the DHCP client chose to
! abandon routable IPv4 addresses acquired using DHCP, in favor of
! IPv4 Link-Local addresses, in cases where the DHCP server could not
! be contacted, and to stop the DHCP client from attempting to
! acquire a new IP address for much longer than the maximum time of
! 60 seconds specified in Dynamic Host Configuration Protocol
! [RFC2131]. The maximum time specified in RFC2131 should be
! observed even in cases where IPv4 link-local presents an
! alternative to DHCP.
!
! Similarly, in some cases where IPv4 Link-Local implementations are
! tightly coupled to the DHCP client, the DHCP client detects changes
! in connectivity and immediately triggers an INIT-REBOOT cycle in
! the client. If the DHCP client is not immediately able to contact
! the DHCP server, it abandons the address acquired through DHCP,
! which triggers a switch to IPv4 Link-Local. This behavior is
! allowed by RFC2131, but it has problems. Users of devices that
! are moving from one location to another and experience temporary
! loss of connectivity can lose all active TCP connections, even
! though the time they spent out of reach of the DHCP server was far
! less than the timeout on a TCP connection. We therefore
! recommend that implementors of IPv4 Link-Local avoid this
! strategy.
!
! Further discussion of this issue is provided in [DNAv4].