Subject: Protocol Action: 'Information Refresh Time Option for DHCPv6' to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 16 May 2005 17:44:29 -0400

The IESG has approved the following document:

- 'Information Refresh Time Option for DHCPv6 '
   <draft-ietf-dhc-lifetime-03.txt> as a Proposed Standard

This document is the product of the Dynamic Host Configuration Working Group. 

The IESG contact persons are Margaret Wasserman and Mark Townsley.

   - Technical Summary

   A host that uses stateless address autoconfiguration (RFC 2462)
   will still require the configuration of other configuration
   information.  DHCPv6 (RFC 3315, RFC 3736) is one way in which a
   host might obtain other configuration information.  The mechanism
   described in RFC 3736, "stateless DHCPv6", provides configuration
   information but does not give the host any indication of when the
   DHCPv6 server should be contacted to refresh that configuration
   information.  This document describes a DHCPv6 option for
   specifying an upper bound for how long a client should wait before
   refreshing information retrieved from DHCPv6.

   The option specified in this document meets the requirements of
   draft-ietf-dhc-stateless-dhcpv6-renumbering, which has been
   accepted for publication as an Informational RFC.

   - Working Group Summary

   The dhc WG developed, discussed and published
   draft-ietf-dhc-stateless-dhcpv6-renumbering, which defines the
   requirements for managing the updating of configuration parameters
   obtained through stateless DHCPv6.

   The specification in this document has been given thorough review
   by the dhc WG.  During the review, several issues about details of
   the configuration update process were resolved through discussion
   in the WG mailing list.

   - Protocol Quality

   The protocol specified in this document is a simple extension to
   the DHCPv6 protocol, which would have been appropriate to include
   in RFC 3315.  The option has been implemented in KAME DHCP server
   and in Lucent DHCP client. The two implementations have been tested
   for interoperability.  From Joe Quanaim prior to previous IETF:

     Since the lifetime draft will be discussed next week at the ietf,
     I thought I would let you know that I have implemented the
     functionality in a dhcpv6 client and successfully tested it
     against the kame server implementation.  I figure it might help
     to be able to cite implementations.

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce