WG ACTION: resolution of open isues LL53 LL63 LL70, changes to LL56 LL57
Erik Guttman <[email protected]> Mon, 7 Jun 2004 12:27:15 +0200 (CEST)
| Newsgroups | gmane.ietf.zeroconf |
|---|---|
| Message-ID | <[email protected]> |
Next Steps:
Please review the propsed consensus calls below. This is really your last
chance to voice a position on the issues before we declare them closed.
We will post an internet-draft including the changes.
Once it appears I will initiate a one week last call for us to review
the document to make sure that he decided changes have been made. After
that, we will make any last fixes required to make it consistent with our
decisions.
Once we have a completed draft, I will request the IESG advancement it
to proposed standard.
Outcome of the last round of last calls:
LL53 Improve constants text - fix various errors due to recent changes
LL56 Clarify disputed text
LL57 Add additional text to Section 9 clarify WATCH_WAIT applies to
IEEE 802
LL63 Accept choice 'D'
LL70 Accept revised text
Details:
---------------------------------
LL53 Forward references requested
Change 1.3 from
(a) the number of, and interval between, ARP probes,
see NUM_PROBES, PROBE_MIN, PROBE_MAX defined in Section 2.2.1
^^^^^^^^^^
to
(a) the number of, and interval between, ARP probes,
see PROBE_NUM, PROBE_MIN, PROBE_MAX defined in Section 2.2.1
Section 9 must include WATCH_WAIT and omit PROBE_INTERVAL (which is not
needed, since this is now defined using PROBE_MIN and PROBE_MAX.) I reviewed
the document (the text in the latest prerelease draft-ietf-zeroconf-ipv4-
linklocal-15.txt) to ensure that the text below is consistent.
START_WAIT 1 second (initial random delay)
PROBE_MIN 1 second (minimum delay till repeated probe)
PROBE_MAX 2 seconds (maximum delay till repeated probe)
PROBE_NUM 3 (number of probe packets)
ANNOUNCE_N 2 (number of announcement packets)
ANNOUNCE_INTERVAL 2 seconds (time between announcement packets)
MAX_COLLISIONS 10 (max collisions before rate limiting)
RATE_LIMIT_INTERVAL 60 seconds (delay between successive attempts)
DEFEND_INTERVAL 10 seconds (after probes, wait for defense)
WATCH_WAIT 10 seconds (time to continue to defend your address,
for IEEE 802 networks)
If we accept the following suggestion - constants throughout the document
must change. Therefore, I suggest we reject:
We now have 5 parameters for the probing process and there is clearly
confusion over their meaning. I would like to see clearer naming:
NUM_PROBES, PRE_PROBE_MAX, INTER_PROBE_MIN, INTER_PROBE_MAX, POST_PROBE_WAIT.
The new text of 3.1(a) should name all 5 of the probing parameters thus:
(a) the number and timing of ARP probes
See NUM_PROBES, PRE_PROBE_MAX, INTER_PROBE_MIN, INTER_PROBE_MAX,
POST_PROBE_WAIT defined in section 2.2.1
------------------------
LL56 Contradictory text?
Change:
"IPv4 addresses and names which can only be resolved on the local link
SHOULD NOT be forwarded, they SHOULD only be sent when a Link-Local
address is used as the source address. This strong advice should hinder
limited scope addresses and names from leaving the context in
which they apply."
To:
"IPv4 addresses and names which can only be resolved on the local link
SHOULD NOT be forwarded beyond the local link. IPv4 Link-Local addresses
SHOULD only be sent when a Link-Local address is used as the source
address. This strong advice should hinder limited scope addresses
and names from leaving the context in which they apply."
------------------------------------
LL57 Straightforward editorial fixes
Philip was concerned with the text in LL57. I believe his concern is
satisfied by the fix in LL53, which modifies the definition of the
WATCH_WAIT constant in section 9.
WATCH_WAIT 10 seconds (time to continue to defend your address,
for IEEE 802 networks)
---------------------------------
LL63 Text should be more explicit
Section 2.11, Replace
A device that implements both IPv4 Link-Local and a DHCPv4 client
should not alter the behavior of the DHCPv4 client to accommodate
IPv4 Link-Local configuration. In particular configuration of an
IPv4 Link-Local address, whether or not a DHCP server is currently
responding, is not sufficient reason to unconfigure a valid DHCP
lease, to stop the DHCP client from attempting to acquire a new IP
address, to change DHCP timeouts or to change the behavior of the
DHCP state machine in any other way.
Several early implementations of IPv4 Link-Local have modified the
DHCP state machine in an attempt to make IPv4 Link-Local more
reliable, and the field experience we have gained from this has
shown that it does not work - reliability of DHCP service is
significantly reduced. If increased reliability of IPv4 Link-Local
is desired, we recommend that the IPv4 Link-Local state machine track
the DHCP client state machine and, in cases where it is not certain
that the DHCP-assigned address is correct, the IPv4 Link-Local state
machine acquire an IPv4 Link-Local address without causing the DHCP
state machine to relinquish its address.
With
As documented in Appendix A, early implementations of IPv4
Link-Local have modified the DHCP state machine. Field experience
shows that these modifications reduce the reliability of the DHCP
service.
A device that implements both IPv4 Link-Local and a DHCPv4 client
should not alter the behavior of the DHCPv4 client to accommodate
IPv4 Link-Local configuration. In particular configuration of an
IPv4 Link-Local address, whether or not a DHCP server is currently
responding, is not sufficient reason to unconfigure a valid DHCP
lease, to stop the DHCP client from attempting to acquire a new IP
address, to change DHCP timeouts or to change the behavior of the
DHCP state machine in any other way.
Further discussion of this issue is provided in [DNAv4]."
------------------------------------
LL70 DNAv4 normative or informative?
Was:
1.9. When to configure a Link-Local IPv4 address
Having addresses of multiple different scopes assigned to an
interface, with no adequate way to determine in what circumstances
each address should be used, leads to complexity for applications and
confusion for users. A host with an address on a link can
communicate with all other devices on that link, whether those
devices use Link-Local addresses, or routable addresses. For these
reasons, a host SHOULD NOT have both a valid routable address and a
Link-Local IPv4 address configured on the same interface.
A routable address is any address that is:
* a unicast address (see Section 1.2)
* not a loopback address
* not contained within the 169.254/16 prefix reserved for Link-Local
IPv4 addresses
A "valid routable address" is a routable address that passes the
reachability test described in section 2 of "Detection of Network
Attachment (DNA) in IPv4" [DNAv4].
The assignment and use of a Link-Local IPv4 address on an interface
is based solely on the state of the interface, and is independent of
any other protocols such as DHCP. A host MUST NOT alter its behavior
and use of other protocols such as DHCP because the host has assigned
a Link-Local IPv4 address to an interface.
When an interface has a valid routable address configured on an
interface, the host SHOULD NOT also assign a Link-Local IPv4 address
to that interface.
If a host finds that an interface that was previous configured with a
Link-Local IPv4 address is now configured with a valid routable
address, the host MUST always use the routable address when
initiating new communications, and MUST cease advertising the
availability of the Link-Local IPv4 address through whatever
mechanisms that address had been made known to others. The host
SHOULD continue to use the Link-Local IPv4 address for communications
underway when the routable address was configured, and MAY continue
to accept new communications addressed to the Link-Local IPv4
address. Ways in which a valid routable address might be configured
for the interface include:
* Manual configuration
* Address assignment through DHCP
* Roaming of the host to a network on which a routable address
assigned to the interface is valid
If a host finds that an interface that was previously configured with
a valid routable address no longer has a valid routable address, the
host MAY identify a usable Link-Local IPv4 address (as described in
section 2) and assign that address to the interface. Ways in which a
valid routable address might no longer be assigned to an interface
include:
* Removal of the address from the interface through manual
configuration
* Expiration of the lease on the address assigned through DHCP
* Roaming of the host to a new network on which the address is no
longer valid.
Further discussion of the issues in detection of transient failures
and the use of DHCP in response to network attachment failure is
provided in "Detection of Network Attachment (DNA) in IPv4". [DNAv4]
Becomes:
1.9. When to configure an IPv4 Link-Local address
Having addresses of multiple different scopes assigned to an
interface, with no adequate way to determine in what circumstances
each address should be used, leads to complexity for applications and
confusion for users. A host with an address on a link can communicate
with all other devices on that link, whether those devices use Link-
Local addresses, or routable addresses. For these reasons, a host
SHOULD NOT have both an operable routable address and an IPv4
Link-Local address configured on the same interface. The term
"operable address" is used to mean an address which works
effectively for communication in the current network context
(see below). When a operable routable address is available
on an interface, the host SHOULD NOT also assign an IPv4
Link-Local address on that interface. However, during the
transition (in either direction) between using routable and IPv4
Link-Local addresses both MAY be in use at once subject to these rules:
1. The assignment of an IPv4 Link-Local address on an interface is
based solely on the state of the interface, and is independent of
any other protocols such as DHCP. A host MUST NOT alter its
behavior and use of other protocols such as DHCP because the host
has assigned an IPv4 Link-Local address to an interface.
2. If a host finds that an interface that was previously configured
with an IPv4 Link-Local address now has an operable routable
address available, the host MUST use the routable address when
initiating new communications, and MUST cease advertising the
availability of the IPv4 Link-Local address through whatever
mechanisms that address had been made known to others. The host
SHOULD continue to use the IPv4 Link-Local address for
communications already underway, and MAY continue to accept new
communications addressed to the IPv4 Link-Local address. Ways in
which an operable routable address might become
available on an interface include:
* Manual configuration
* Address assignment through DHCP
* Roaming of the host to a network on which a previously
assigned address becomes operable.
3. If a host finds that an interface no longer has an operable routable
address available, the host MAY identify a usable IPv4 Link-Local
address (as described in section 2) and assign that address to the
interface. Ways in which an operable routable address might cease to
be available on an interface include:
* Removal of the address from the interface through manual
configuration
* Expiration of the lease on the address assigned through DHCP
* Roaming of the host to a new network on which the address is no
longer operable.
The determination by the system of whether an address is "operable" is
not clear cut and many changes in the system context (e.g.
router changes) may affect the operability of an address. In
particular roaming of a host from one network to another is likely -
but not certain - to change the operability of a configured address but
detecting such a move is not always trivial.
"Detection of Network Attachment (DNA) in IPv4" [DNAv4]
provides further discussion of address assignment and operability
determination.
------------------------------
Erik Guttman
ZEROCONF WG Chair