On Tue, 2013-02-26 at 07:14 +0000, Liubing (Leo) wrote: > We submitted a new draft to discuss the SLAAC/DHCPv6 interaction gaps.
Some time ago I wrote quite a long reply on this list about it. I've changed my mind on a few points, and here's my current thinking, for what it's worth. I think an update to the relevant RFCs (4861?) should be written that makes the following unambiguous statements about the flags. 1: The O and M flags are independent of each other. The O flag implies nothing about address configuration, and the M flag implies nothing about whether ancillary information is available. However, DHCPv6 itself will supply ancillary information along with address information, so a host doing stateful DHCPv6 SHOULD accept and use the information returned with addresses rather than do additional, separate stateless DHCPv6 queries. If a host accepts the ancillary information in response to a stateful DHCPv6 query, then the valid and preferred lifetimes of the ancillary data MUST be set to those of the received address(es). 2: A valid RA can have both the O and the M flags set. 3: The M flag, if set, means that a DHCPv6 service is available for stateful automatic address configuration by the hosts on the link. The presence of a set M flag makes no statement about whether hosts should use the service. The absence of a set M flag makes no statement about whether a DHCPv6 service is available. A host SHOULD perform stateful DHCPv6 address configuration if it sees a set M flag in an RA. However, it SHOULD NOT do so if it already has one or more addresses on the receiving interface that were acquired via stateful DHCPv6. A host MAY attempt to obtain addresses via DHCPv6 without seeing an RA at all. Rationale: The host may be in a network containing a DHCPv6 server, but no router. A host MAY attempt to obtain addresses via DHCPv6 even if it sees an RA with no M flag set. Rationale: There may be multiple routers on a link, not all of which are advertising an M flag. 4: The O flag, if set, means that a stateless DHCPv6 service is available. The presence of a set O flag makes no statement about whether hosts should use the service. The absence of a set O flag makes no statement about whether a DHCPv6 service is available. A host SHOULD perform a stateless DHCPv6 query when it sees a set O flag in an RA. However, it SHOULD NOT do so if it has already acquired information via stateless DHCPv6 and the preferred lifetime of that information has not yet expired. A host MAY attempt stateless DHCPv6 without seeing an RA at all. Rationale: The host may be in a network containing a DHCPv6 server, but no router. A host MAY attempt stateless DHCPv6 even if it sees an RA with no O flag set. Rationale: There may be multiple routers on a link, not all of which are advertising an O flag. 5: Once configured, a DHCPv6 address SHOULD NOT be deconfigured until its valid lifetime has expired. Also, an address MUST NOT be deconfigured solely because an RA is seen with no set M flag. However, a host MAY reduce the valid lifetime of an address to two hours if an RA is seen with no set M flag. Rationale: There may be multiple routers in a network, not all of which are advertising a set M flag. Deconfiguring an address based solely on an RA with no set M flag could result in an address "flap", where one RA causes the address to be configured, the next causes it to be deconfigured. Furthermore, the "contract" between the DHCPv6 server and the host has stipulated that the host may use the address for the extent of the stated valid lifetime. Reducing the valid lifetime to no less than two hours prevents a trivial denial of service attack while permitting an administrator to renumber more quickly if necessary. 6: Information obtained via stateless DHCPv6 SHOULD be considered valid until the valid lifetime of the address(es) to which it pertains expires OR the valid lifetime of the ancillary information expires OR until another successful stateless DHCP query is performed for the relevant address(es), whichever comes first. Also, information obtained via stateless DHCPv6 MUST NOT be discarded solely because an RA is seen with no set O flag. Rationale: There may be multiple routers in a network, not all of which are advertising a set O flag. Discarding information based on an RA with no set O flag could result in the information "flapping", where one RA causes the information to be obtained, the next causes it to be discarded. Furthermore, the "contract" between the DHCPv6 server and the host has stipulated that the host may use the information for the extent of the stated valid lifetime. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Karl Auer (ka...@biplane.com.au) http://www.biplane.com.au/kauer http://www.biplane.com.au/blog GPG fingerprint: B862 FB15 FE96 4961 BC62 1A40 6239 1208 9865 5F9A Old fingerprint: AE1D 4868 6420 AD9A A698 5251 1699 7B78 4EEE 6017 -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
