LL34: Comments on the state diagram and proposed text

Some comments on the state diagram:

"INIT waits before entering SELECT state."

How long?

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

The IPv4LL address can be claimed while the host is asleep,
and so it is necessary to rerun claim and defend
rather than just configuring the address, as specified in
Section 2.2.  Also, it is possible that the DHCP server is
now available so that an argument can be made that if the
host was previously assigned routable IP addresses that are still valid,
that it should test whether it is connected to any of those points of
attachment before assigning an IPv4 LL address. In fact, I think
the proposed text suggests this as well.

My recommendation is to delete the above paragraph.

"ANNOUNCE Send ARP announcements the enter CONFIGURED
state."

Think you mean "then enter"

Here are some comments on the proposed text for 2.12:

       2.12 Transition from Routable Address to Link-Local

           A host may 'wake up' (see Section 2.2) with a valid DHCP
           lease.

[BA] It may also change its point of attachment. So would change to:
"On changing its point of attachment, or awaking from sleep mode,
a host with a still valid routable IP address (e.g. DHCP lease not
expired) will typically prefer to use this address if it can confirm
attachment to the network on which the address was assigned."

           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.

[BA]  The MUST is inappropriate because there is no need to use DHCP to
confirm attachment to a network on which a still valid IP address was
assigned. A simple reachability test will suffice.  Suggest changing to:

"Before a host with a valid routable IP address configures a
Link-Local IPv4 address it SHOULD first attempt to confirm the usability
of the routable address, using mechanisms such as those specified in
[DNAv4]. If the usability of an existing valid routable IPv4 address cannot be
confirmed, then the host MUST attempt to acquire an IPv4 address,
using a mechanism such as DHCPv4.  In the case where the DHCPv4 client is
unable to contact a DHCPv4 server, the implementor has a choice:
either abandon the DHCPv4 lease and configure an IPv4 Link-Local
address or configure the address previously assigned by DHCPv4 "

           Implementors are faced with a trade-off:  'Robustness to
           DHCP Server Unresponsiveness' versus 'Rapid Transition to
           Autoconfigured State'.

[BA] In fact, the DNA-specified procedure does not require this tradeoff;
if reachability to the default gateway can be confirmed then the host can
reuse a valid routable address even if the DHCP server does not respond.
I suggest that the above paragraph be deleted.

           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.

[BA] Again, these paragraphs seem to imply that the issue is DHCP server
reachability; the issue is the ability of the host to
confirm its point of attachment. If the host is unable to confirm
reachability of the default gateway then configuring a routable address
will not help much since the host will be unable to reach hosts off-link
anyway.  My advice would be to delete the above paragraphs.

           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.

[BA]  I thought we agreed that the 5 minute wait time is a bad idea.  The
maximum DHCP RTO is 64 seconds.  So I'd delete "for several minutes at a
time,"

           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.


[BA] This paragraph is ok.


















>
> I am concerned if we simply say 'refer to DNAv4' we will
> make DNAv4 a normative reference.  Perhaps this is the
> right thing to do, but it sure won't grease the rails for
> IPv4LL to come out.  Every month this spec is delayed there
> are more implementations that Stuart is coaching toward
> poor behavior.
>
> Erik