Protocol Action: 'Information Refresh Time Option for DHCPv6' to Proposed Standard
The IESG <iesg-secretary@ietf.org> Mon, 16 May 2005 21:44 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXnO5-000068-OI; Mon, 16 May 2005 17:44:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXnO2-0008Sf-TX; Mon, 16 May 2005 17:44:30 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25211; Mon, 16 May 2005 17:44:28 -0400 (EDT)
Received: from [132.151.6.50] (helo=newodin.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXnef-0004CS-Hv; Mon, 16 May 2005 18:01:41 -0400
Received: from apache by newodin.ietf.org with local (Exim 4.43) id 1DXnO1-00076K-Q6; Mon, 16 May 2005 17:44:29 -0400
X-test-idtracker: no
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Message-Id: <E1DXnO1-00076K-Q6@newodin.ietf.org>
Date: Mon, 16 May 2005 17:44:29 -0400
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca
Cc: dhc mailing list <dhcwg@ietf.org>, dhc chair <rdroms@cisco.com>, Internet Architecture Board <iab@iab.org>, dhc chair <venaas@uninett.no>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: Protocol Action: 'Information Refresh Time Option for DHCPv6' to Proposed Standard
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: ietf-announce.ietf.org
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
Sender: ietf-announce-bounces@ietf.org
Errors-To: ietf-announce-bounces@ietf.org
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
IETF-Announce@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce