draft-ietf-dhc-dhcpv6-reconfigure-rebind-04.txt   draft-ietf-dhc-dhcpv6-reconfigure-rebind-05.txt 
Network Working Group D. Evans Network Working Group D. Evans
Internet-Draft ARRIS International, Inc. Internet-Draft ARRIS International, Inc.
Intended status: Informational R. Droms Intended status: Informational R. Droms
Expires: March 12, 2009 Cisco Systems, Inc. Expires: May 7, 2009 Cisco Systems, Inc.
September 8, 2008 November 3, 2008
Rebind Capability in DHCPv6 Reconfigure Messages Rebind Capability in DHCPv6 Reconfigure Messages
draft-ietf-dhc-dhcpv6-reconfigure-rebind-04.txt draft-ietf-dhc-dhcpv6-reconfigure-rebind-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 12, 2009. This Internet-Draft will expire on May 7, 2009.
Abstract Abstract
This document updates RFC 3315 to allow the Rebind message type to This document updates RFC 3315 to allow the Rebind message type to
appear in the Reconfigure Message option of a Reconfigure message, appear in the Reconfigure Message option of a Reconfigure message,
which allows DHCPv6 servers to instruct clients to perform a Rebind which extends the Reconfigure message to allow a DHCPv6 server to
operation as well as a Renew operation. The document also clarifies cause a DHCPv6 client to send a Rebind message. The document also
how a DHCPv6 client responds to a received Reconfigure message. clarifies how a DHCPv6 client responds to a received Reconfigure
message.
1. Introduction 1. Introduction
DHCPv6 [RFC3315] allows a server to send an unsolicited Reconfigure DHCPv6 [RFC3315] allows a server to send an unsolicited Reconfigure
message to a client. The client's response to a Reconfigure message, message to a client. The client's response to a Reconfigure message,
according to section 19 of RFC3315 is either a Renew or an according to section 19 of RFC3315 is either a Renew or an
Information-Request message, depending on the contents of the msg- Information-Request message, depending on the contents of the msg-
type field in the Reconfigure Message option of the Reconfigure type field in the Reconfigure Message option of the Reconfigure
message. message.
skipping to change at page 3, line 26 skipping to change at page 3, line 26
option-len 1. option-len 1.
msg-type 5 for Renew message, 6 for Rebind, 11 for msg-type 5 for Renew message, 6 for Rebind, 11 for
Information-request message. Information-request message.
4. Server Behavior 4. Server Behavior
This section updates specific text in sections 19.1, 19.2 and 19.3 of This section updates specific text in sections 19.1, 19.2 and 19.3 of
RFC 3315. RFC 3315.
The server MUST include a Reconfigure Message option (as defined in The server MUST include a Reconfigure Message option (as defined in
Section 3 to select whether the client responds with a Renew message, Section 3) to select whether the client responds with a Renew
a Rebind message or an Information-Request message. message, a Rebind message or an Information-Request message.
The Reconfigure message causes the client to initiate a Renew/Reply, The Reconfigure message causes the client to initiate a Renew/Reply,
a Rebind/Reply message exchange or an Information-request/Reply a Rebind/Reply message exchange or an Information-request/Reply
message exchange. The server interprets the receipt of a Renew, a message exchange. The server interprets the receipt of a Renew, a
Rebind or an Information-request message (whichever was specified in Rebind or an Information-request message (whichever was specified in
the original Reconfigure message) from the client as satisfying the the original Reconfigure message) from the client as satisfying the
Reconfigure message request. Reconfigure message request.
The server retransmits a Reconfigure message specifying a Rebind The server retransmits a Reconfigure message specifying a Rebind
message in the same way as described in section 19.1.2 of RFC 3315. message in the same way as described in section 19.1.2 of RFC 3315.
skipping to change at page 4, line 16 skipping to change at page 4, line 16
a Renew message, a Rebind message or an Information-request message a Renew message, a Rebind message or an Information-request message
as indicated by the Reconfigure Message option (as defined in as indicated by the Reconfigure Message option (as defined in
Section 3). The client ignores the transaction-id field in the Section 3). The client ignores the transaction-id field in the
received Reconfigure message. While the transaction is in progress, received Reconfigure message. While the transaction is in progress,
the client silently discards any Reconfigure messages it receives. the client silently discards any Reconfigure messages it receives.
When responding to a Reconfigure, the client creates and sends the When responding to a Reconfigure, the client creates and sends the
Rebind message in exactly the same manner as outlined in section Rebind message in exactly the same manner as outlined in section
18.1.4 of RFC 3315, with the exception that the client copies the 18.1.4 of RFC 3315, with the exception that the client copies the
Option Request option and any IA options from the Reconfigure message Option Request option and any IA options from the Reconfigure message
into the Renew message. into the Rebind message.
If a client is currently sending Rebind messages, as described in
section 18.1.4 of RFC 3315, the client ignores any received
Reconfigure messages.
The client uses the same variables and retransmission algorithm as it The client uses the same variables and retransmission algorithm as it
does with Renew, Rebind or Information-request messages generated as does with Renew, Rebind or Information-request messages generated as
part of a client-initiated configuration exchange. See sections part of a client-initiated configuration exchange. See sections
18.1.3, 18.1.4 and 18.1.5 of RFC 3315for details. If the client does 18.1.3, 18.1.4 and 18.1.5 of RFC 3315 for details. If the client
not receive a response from the server by the end of the does not receive a response from the server by the end of the
retransmission process, the client ignores and discards the retransmission process, the client ignores and discards the
Reconfigure message. Reconfigure message.
5. Clarification of section 19.4.2, RFC 3315 5. Clarification of section 19.4.2, RFC 3315
When sending a Renew message in response to the receipt of a When sending a Renew message in response to the receipt of a
Reconfigure message, the client MUST include a Server Identifier Reconfigure message, the client MUST include a Server Identifier
option identifying the server the client most recently communicated option identifying the server the client most recently communicated
with. with.
6. Security Considerations 6. Security Considerations
This document adds no new security considerations beyond those This document adds no new security considerations beyond those
present in RFC 3315. present in RFC 3315.
7. IANA Considerations 7. IANA Considerations
There are no actions for IANA associated with this document. There are no actions for IANA associated with this document.
8. Normative References 8. Change log
This section MUST be removed before publication.
8.1. Revision -05
Clarified description of this feature in introduction.
Clarified action of client if it receives a Reconfigure while sending
Rebind messages.
9. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
Authors' Addresses Authors' Addresses
 End of changes. 8 change blocks. 
13 lines changed or deleted 29 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/