Re: LL34: Comments on the state diagram and proposed text

Bernard,

Bernard Aboba wrote:
> Some comments on the state diagram:

The basic questions I have are:

   o Does the diagram clarify things or make them more difficult
     to understand?

   o Is it late in the game to add such a diagram, as it will
     require quite a bit of work to get it right?


> "INIT waits before entering SELECT state."
> 
> How long?

This is specified in section 2.2.1: A random time between
PROBE_MIN and PROBE_MAX.

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

That is what I said.  That's what the SELECT state means.

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

Or - add an ARC from SELECT to EXIT, so that if there is an IPv4
address selected we will go to EXIT.

> "ANNOUNCE Send ARP announcements the enter CONFIGURED
> state."
> 
> Think you mean "then enter"

Yes.

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

OK.

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

OK.


>            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 OK with these changes.  Are others?

Thanks,

Erik