[dhcwg] comments on draft-ietf-dhc-dna-ipv4-04.txt

[Mark Stapp <mjs@cisco.com>]

I have some comments on draft-ietf-dhc-dna-ipv4-04.txt - on section 2.1 in 
particular.

[2.1] Reachability Test

    Doesn't this sentence in 2.1 sort of turn DHCP on its head?

      "The purpose of the reachability test is to determine whether
       the host is connected to a network on which it had previously
       obtained a still valid routable IPv4 address."

    As I understand it, it's only the DHCP server who knows
    authoritatively whether the address binding that the client
    remembers is still valid. Working around that authority in
    circumstances where the server has failed, if the client could
    actually determine that, would be one thing. But working around
    that without the client's even attempting to confirm its binding
    with the server is problematic.

    This section states that a host may skip confirmation of its DHCP
    address when it reconnects under some circumstances. The DHCP
    INIT-REBOOT state is actually pretty important, and skipping it
    could have some undesireable consequences. As 2.1 is worded now, a
    host could have a week-old memory of an address it got on network
    A, and could re-use it upon reconnecting to network A without
    attempting INIT-REBOOT. That's a pretty dramatic change, if I've
    read the text accurately, and I'm not comfortable with it.

    Is the goal of 2.1 to assist clients who have marginal connections
    - wireless clients whose associations are flapping, for example?
    Maybe a time-based, stateful heuristic would be appropriate
    here. For example, if the host believes that it has reconnected to
    network A, and that it last communicated with the DHCP server on
    network A within the last - one minute? five minutes?  - then it
    could proceed without INIT-REBOOT. If the host had

	  a) been off of network A for more than five minutes, or

	  b) been attached to some other network since it last
	     attached to network A

    then it would go through INIT-REBOOT normally.

    Or are there folks who think that the client should always do
    INIT-REBOOT if it can? In that case, if there's a latency issue
    for some types of client or some types of link, maybe we should
    try to make a low-latency answer available from the server without
    changing the client behavior at all.

Thanks,
Mark


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg