DHCPv6 Relay Initiated Release
draft-gandhewar-dhc-v6-relay-initiated-release-01
| Document | Type |
Expired Internet-Draft
(dhc WG)
Expired & archived
|
|
|---|---|---|---|
| Author | Sunil M Gandhewar | ||
| Last updated | 2016-04-04 (Latest revision 2015-10-01) | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Candidate for WG Adoption | |
| Document shepherd | (None) | ||
| IESG | IESG state | Expired | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) is initiated by a DHCPv6 client. A DHCPv6 server can force DHCPv6 client to send RENEW or INFORMATION-REQUEST by sending a RECONFIGURE message. There may be multiple DHCPv6 network devices connected in between a DHCPv6 client and a server, each one reserving resources for the DHCPv6 client. There are no DHCPv6 messages that a relay can initiate in order to control the client binding. A DHCPv6 client may not always send a RELEASE message when it no longer needs the IPv6 address or prefix and network resources for the associated services it is using. This document specifies a way to request release to be initiated by an intermediate DHCPv6 network device, e.g. DHCPv6 relay, on behalf of DHCPv6 client. This helps to relinquish network resources sooner than the lease expiration time.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)