draft-ietf-dhc-dhcpv6-17.txt   draft-ietf-dhc-dhcpv6-18.txt 
Internet Engineering Task Force J. Bound Internet Engineering Task Force J. Bound
INTERNET DRAFT Nokia INTERNET DRAFT Nokia
DHC Working Group M. Carney DHC Working Group M. Carney
Obsoletes: draft-ietf-dhc-dhcpv6-16.txt Sun Microsystems, Inc Obsoletes: draft-ietf-dhc-dhcpv6-18.txt Sun Microsystems, Inc
C. Perkins C. Perkins
Nokia Research Center Nokia Research Center
R. Droms(ed.) R. Droms(ed.)
Cisco Systems Cisco Systems
1 March 2001 15 April 2001
Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
draft-ietf-dhc-dhcpv6-17.txt draft-ietf-dhc-dhcpv6-18.txt
Status of This Memo Status of This Memo
This document is a submission by the Dynamic Host Configuration This document is a submission by the Dynamic Host Configuration
Working Group of the Internet Engineering Task Force (IETF). Comments Working Group of the Internet Engineering Task Force (IETF). Comments
should be submitted to the dhcp-v6@bucknell.edu mailing list. should be submitted to the dhcp-v6@bucknell.edu mailing list.
Distribution of this memo is unlimited. Distribution of this memo is unlimited.
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
skipping to change at page 1, line 84 skipping to change at page 1, line 84
7.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 9 7.4. Error Values . . . . . . . . . . . . . . . . . . . . . . 9
7.4.1. Generic Error Values . . . . . . . . . . . . . . 9 7.4.1. Generic Error Values . . . . . . . . . . . . . . 9
7.4.2. Server-specific Error Values . . . . . . . . . . 9 7.4.2. Server-specific Error Values . . . . . . . . . . 9
7.5. Configuration Variables . . . . . . . . . . . . . . . . . 10 7.5. Configuration Variables . . . . . . . . . . . . . . . . . 10
8. Overview 10 8. Overview 10
8.1. How does a node know to use DHCP? . . . . . . . . . . . . 10 8.1. How does a node know to use DHCP? . . . . . . . . . . . . 10
8.2. What if the client and server(s) are on different links? 10 8.2. What if the client and server(s) are on different links? 10
8.3. How does a client request configuration parameters from 8.3. How does a client request configuration parameters from
servers? . . . . . . . . . . . . . . . . . . . . . . . 11 servers? . . . . . . . . . . . . . . . . . . . . . . . 11
8.4. How do clients and servers identify and manage addresses? 11 8.4. How do clients and servers identify and manage addresses? 12
8.5. Can a client release its assigned addresses before the lease 8.5. Can a client release its assigned addresses before the lease
expires? . . . . . . . . . . . . . . . . . . . . . . . 12 expires? . . . . . . . . . . . . . . . . . . . . . . . 12
8.6. What if the client determines one or more of its assigned 8.6. What if the client determines one or more of its assigned
addresses are already being used by another client? . 12 addresses are already being used by another client? . 12
8.7. How are clients notified of server configuration changes? 12 8.7. How are clients notified of server configuration changes? 12
9. Message Formats 13 9. Message Formats 13
9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 13 9.1. DHCP Solicit Message Format . . . . . . . . . . . . . . . 13
9.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 14 9.2. DHCP Advertise Message Format . . . . . . . . . . . . . . 14
9.3. DHCP Request Message Format . . . . . . . . . . . . . . . 14 9.3. DHCP Request Message Format . . . . . . . . . . . . . . . 14
9.4. DHCP Confirm Message Format . . . . . . . . . . . . . . . 14 9.4. DHCP Confirm Message Format . . . . . . . . . . . . . . . 15
9.5. DHCP Renew Message Format . . . . . . . . . . . . . . . . 15 9.5. DHCP Renew Message Format . . . . . . . . . . . . . . . . 15
9.6. DHCP Rebind Message Format . . . . . . . . . . . . . . . 15 9.6. DHCP Rebind Message Format . . . . . . . . . . . . . . . 15
9.7. DHCP Reply Message Format . . . . . . . . . . . . . . . . 16 9.7. DHCP Reply Message Format . . . . . . . . . . . . . . . . 16
9.8. DHCP Release Message Format . . . . . . . . . . . . . . . 16 9.8. DHCP Release Message Format . . . . . . . . . . . . . . . 16
9.9. DHCP Decline Message Format . . . . . . . . . . . . . . . 16 9.9. DHCP Decline Message Format . . . . . . . . . . . . . . . 17
9.10. DHCP Reconfigure-init Message Format . . . . . . . . . . 17 9.10. DHCP Reconfigure-init Message Format . . . . . . . . . . 17
10. Relay messages 17 10. Relay messages 17
10.1. Relay-forward message . . . . . . . . . . . . . . . . . . 17 10.1. Relay-forward message . . . . . . . . . . . . . . . . . . 18
10.2. Relay-reply message . . . . . . . . . . . . . . . . . . . 18 10.2. Relay-reply message . . . . . . . . . . . . . . . . . . . 18
11. Identity association 18 11. Identity association 19
12. DHCP Server Solicitation 19 12. DHCP Server Solicitation 19
12.1. Solicit Message Validation . . . . . . . . . . . . . . . 19 12.1. Solicit Message Validation . . . . . . . . . . . . . . . 19
12.2. Advertise Message Validation . . . . . . . . . . . . . . 19 12.2. Advertise Message Validation . . . . . . . . . . . . . . 19
12.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 19 12.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 19
12.3.1. Creation and sending of the Solicit message . . . 19 12.3.1. Creation and sending of the Solicit message . . . 20
12.3.2. Time out and retransmission of Solicit Messages . 20 12.3.2. Time out and retransmission of Solicit Messages . 20
12.3.3. Receipt of Advertise messages . . . . . . . . . . 20 12.3.3. Receipt of Advertise messages . . . . . . . . . . 20
12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 21 12.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 21
12.4.1. Receipt of Solicit messages . . . . . . . . . . . 21 12.4.1. Receipt of Solicit messages . . . . . . . . . . . 21
12.4.2. Creation and sending of Advertise messages . . . 21 12.4.2. Creation and sending of Advertise messages . . . 21
13. DHCP Client-Initiated Configuration Exchange 22 13. DHCP Client-Initiated Configuration Exchange 22
13.1. Client Message Validation . . . . . . . . . . . . . . . . 22 13.1. Client Message Validation . . . . . . . . . . . . . . . . 23
13.2. Server Message Validation . . . . . . . . . . . . . . . . 23 13.2. Server Message Validation . . . . . . . . . . . . . . . . 23
13.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 23 13.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 24
13.3.1. Creation and sending of Request messages . . . . 24 13.3.1. Creation and sending of Request messages . . . . 24
13.3.2. Creation and sending of Confirm messages . . . . 24 13.3.2. Creation and sending of Confirm messages . . . . 25
13.3.3. Creation and sending of Renew messages . . . . . 26 13.3.3. Creation and sending of Renew messages . . . . . 26
13.3.4. Creation and sending of Rebind messages . . . . . 27 13.3.4. Creation and sending of Rebind messages . . . . . 27
13.3.5. Receipt of Reply message in response to a Reply, 13.3.5. Receipt of Reply message in response to a Reply,
Confirm, Renew or Rebind message . . . . . 28 Confirm, Renew or Rebind message . . . . . 28
13.3.6. Creation and sending of Release messages . . . . 29 13.3.6. Creation and sending of Release messages . . . . 30
13.3.7. Time out and retransmission of Release Messages . 29 13.3.7. Time out and retransmission of Release Messages . 30
13.3.8. Creation and sending of Decline messages . . . . 30 13.3.8. Creation and sending of Decline messages . . . . 30
13.3.9. Time out and retransmission of Decline Messages . 30 13.3.9. Time out and retransmission of Decline Messages . 31
13.3.10. Receipt of Reply message in response to a Release 13.3.10. Receipt of Reply message in response to a Release
message . . . . . . . . . . . . . . . . . 31 message . . . . . . . . . . . . . . . . . 31
13.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 31 13.4. Server Behavior . . . . . . . . . . . . . . . . . . . . . 31
13.4.1. Receipt of Request messages . . . . . . . . . . . 31 13.4.1. Receipt of Request messages . . . . . . . . . . . 32
13.4.2. Receipt of Confirm messages . . . . . . . . . . . 32 13.4.2. Receipt of Confirm messages . . . . . . . . . . . 32
13.4.3. Receipt of Renew messages . . . . . . . . . . . . 32 13.4.3. Receipt of Renew messages . . . . . . . . . . . . 33
13.4.4. Receipt of Rebind messages . . . . . . . . . . . 33 13.4.4. Receipt of Rebind messages . . . . . . . . . . . 34
13.4.5. Receipt of Release messages . . . . . . . . . . . 34 13.4.5. Receipt of Release messages . . . . . . . . . . . 35
13.4.6. Sending of Reply messages . . . . . . . . . . . . 35 13.4.6. Sending of Reply messages . . . . . . . . . . . . 35
14. DHCP Server-Initiated Configuration Exchange 35 14. DHCP Server-Initiated Configuration Exchange 36
14.1. Reconfigure-init Message Validation . . . . . . . . . . . 35 14.1. Reconfigure-init Message Validation . . . . . . . . . . . 36
14.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 35 14.2. Server Behavior . . . . . . . . . . . . . . . . . . . . . 36
14.2.1. Creation and sending of Reconfigure-init messages 36 14.2.1. Creation and sending of Reconfigure-init messages 36
14.2.2. Time out and retransmission of unicast 14.2.2. Time out and retransmission of unicast
Reconfigure-init messages . . . . . . . . 37 Reconfigure-init messages . . . . . . . . 37
14.2.3. Time out and retransmission of multicast 14.2.3. Time out and retransmission of multicast
Reconfigure-init messages . . . . . . . . 37 Reconfigure-init messages . . . . . . . . 38
14.2.4. Receipt of Request messages . . . . . . . . . . . 37 14.2.4. Receipt of Request messages . . . . . . . . . . . 38
14.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 37 14.3. Client Behavior . . . . . . . . . . . . . . . . . . . . . 38
14.3.1. Receipt of Reconfigure-init messages . . . . . . 37 14.3.1. Receipt of Reconfigure-init messages . . . . . . 38
14.3.2. Creation and sending of Request messages . . . . 38 14.3.2. Creation and sending of Request messages . . . . 38
14.3.3. Time out and retransmission of Request messages . 38 14.3.3. Time out and retransmission of Request messages . 39
14.3.4. Receipt of Reply messages . . . . . . . . . . . . 38 14.3.4. Receipt of Reply messages . . . . . . . . . . . . 39
15. Relay Behavior 38 15. Relay Behavior 39
15.1. Relaying of Solicit messages . . . . . . . . . . . . . . 39 15.1. Relaying of client messages . . . . . . . . . . . . . . . 39
15.2. Relaying of Advertise messages . . . . . . . . . . . . . 39 15.2. Relaying of server messages . . . . . . . . . . . . . . . 40
16. DHCP options 39 16. DHCP options 40
16.1. Format of DHCP options . . . . . . . . . . . . . . . . . 40 16.1. Format of DHCP options . . . . . . . . . . . . . . . . . 40
16.2. Identity association option . . . . . . . . . . . . . . . 40 16.2. Identity association option . . . . . . . . . . . . . . . 41
16.3. Option request option . . . . . . . . . . . . . . . . . . 42 16.3. Option request option . . . . . . . . . . . . . . . . . . 43
16.4. Client message option . . . . . . . . . . . . . . . . . . 43 16.4. Client message option . . . . . . . . . . . . . . . . . . 43
16.5. Server message option . . . . . . . . . . . . . . . . . . 43 16.5. Server message option . . . . . . . . . . . . . . . . . . 44
16.6. Retransmission parameter option . . . . . . . . . . . . . 44 16.6. Retransmission parameter option . . . . . . . . . . . . . 44
16.7. Authentication option . . . . . . . . . . . . . . . . . . 44 16.7. Reconfigure-delay option . . . . . . . . . . . . . . . . 44
16.8. Reconfigure-delay option . . . . . . . . . . . . . . . . 44 16.8. DSTM Global IPv4 Address Option . . . . . . . . . . . . . 45
16.9. DSTM Global IPv4 Address Option . . . . . . . . . . . . . 44 16.9. Authentication option . . . . . . . . . . . . . . . . . . 46
17. DHCP Client Implementor Notes 45 17. DHCP Client Implementor Notes 46
17.1. Primary Interface . . . . . . . . . . . . . . . . . . . . 45 17.1. Primary Interface . . . . . . . . . . . . . . . . . . . . 46
17.2. Advertise Message and Configuration Parameter Caching . . 46 17.2. Advertise Message and Configuration Parameter Caching . . 46
17.3. Time out and retransmission variables . . . . . . . . . . 46 17.3. Time out and retransmission variables . . . . . . . . . . 47
17.4. Server Preference . . . . . . . . . . . . . . . . . . . . 46 17.4. Server Preference . . . . . . . . . . . . . . . . . . . . 47
18. DHCP Server Implementor Notes 46 18. DHCP Server Implementor Notes 47
18.1. Client Bindings . . . . . . . . . . . . . . . . . . . . . 46 18.1. Client Bindings . . . . . . . . . . . . . . . . . . . . . 47
18.2. Reconfigure-init Considerations . . . . . . . . . . . . . 47 18.2. Reconfigure-init Considerations . . . . . . . . . . . . . 47
18.2.1. Reliable transmission of multicast Reconfigure-init 18.2.1. Reliable transmission of multicast Reconfigure-init
messages . . . . . . . . . . . . . . . . . 47 messages . . . . . . . . . . . . . . . . . 48
18.3. Server Preference . . . . . . . . . . . . . . . . . . . . 47 18.3. Server Preference . . . . . . . . . . . . . . . . . . . . 48
18.4. Request Message Transaction-ID Cache . . . . . . . . . . 47 18.4. Request Message Transaction-ID Cache . . . . . . . . . . 48
19. DHCP Relay Implementor Notes 48 19. DHCP Relay Implementor Notes 48
20. Open Issues for Working Group Discussion 48 20. Open Issues for Working Group Discussion 49
20.1. Authentication . . . . . . . . . . . . . . . . . . . . . 48 20.1. Authentication . . . . . . . . . . . . . . . . . . . . . 49
20.2. Identification of IAs by servers . . . . . . . . . . . . 48 20.2. Identification of IAs by servers . . . . . . . . . . . . 49
20.3. DHCP-DNS interaction . . . . . . . . . . . . . . . . . . 48 20.3. DHCP-DNS interaction . . . . . . . . . . . . . . . . . . 49
20.4. Anonymous addresses . . . . . . . . . . . . . . . . . . . 48 20.4. Temporary addresses . . . . . . . . . . . . . . . . . . . 49
20.5. Use of term "agent" . . . . . . . . . . . . . . . . . . . 48 20.5. Use of term "agent" . . . . . . . . . . . . . . . . . . . 49
20.6. Client behavior when response to Rebind is not received . 49 20.6. Client behavior when response to Rebind is not received . 49
20.7. Additional options . . . . . . . . . . . . . . . . . . . 49 20.7. Additional options . . . . . . . . . . . . . . . . . . . 50
20.8. Operational parameters . . . . . . . . . . . . . . . . . 49 20.8. Operational parameters . . . . . . . . . . . . . . . . . 50
21. Security 49 21. Security 50
22. Year 2000 considerations 49 22. Year 2000 considerations 50
23. IANA Considerations 49 23. IANA Considerations 50
24. Acknowledgments 50 24. Acknowledgments 51
A. Comparison between DHCPv4 and DHCPv6 50 A. Comparison between DHCPv4 and DHCPv6 51
B. Full Copyright Statement 52 B. Full Copyright Statement 53
C. Changes in this draft 53 C. Changes in this draft 53
C.1. New messages for confirming addresses and extending the lease C.1. New messages for confirming addresses and extending the lease
on an IA . . . . . . . . . . . . . . . . . . . . . . . 53 on an IA . . . . . . . . . . . . . . . . . . . . . . . 54
C.2. New message formats . . . . . . . . . . . . . . . . . . . 53 C.2. New message formats . . . . . . . . . . . . . . . . . . . 54
C.3. Renamed Server-forward message . . . . . . . . . . . . . 53 C.3. Renamed Server-forward message . . . . . . . . . . . . . 54
C.4. Clarified relay forwarding of messages . . . . . . . . . 53 C.4. Clarified relay forwarding of messages . . . . . . . . . 54
C.5. Addresses and options in Advertise messages . . . . . . . 53 C.5. Addresses and options in Advertise messages . . . . . . . 54
C.6. Clarification of IA option format . . . . . . . . . . . . 53 C.6. Clarification of IA option format . . . . . . . . . . . . 54
C.7. Specification of transaction ID in Solicit message . . . 54 C.7. Specification of transaction ID in Solicit message . . . 54
C.8. Edits to definitions . . . . . . . . . . . . . . . . . . 54 C.8. Edits to definitions . . . . . . . . . . . . . . . . . . 55
C.9. Relay agent messages . . . . . . . . . . . . . . . . . . 54 C.9. Relay agent messages . . . . . . . . . . . . . . . . . . 55
C.10. Relay agent behavior . . . . . . . . . . . . . . . . . . 54 C.10. Relay agent behavior . . . . . . . . . . . . . . . . . . 55
C.11. Transmission of all client messages through relays . . . 54 C.11. Transmission of all client messages through relays . . . 55
C.12. Reconfigure-init messages . . . . . . . . . . . . . . . . 54 C.12. Reconfigure-init messages . . . . . . . . . . . . . . . . 55
C.13. Ordering of sections . . . . . . . . . . . . . . . . . . 54 C.13. Ordering of sections . . . . . . . . . . . . . . . . . . 55
C.14. DSTM option . . . . . . . . . . . . . . . . . . . . . . . 54 C.14. DSTM option . . . . . . . . . . . . . . . . . . . . . . . 55
C.15. Message and option numbering . . . . . . . . . . . . . . 55
C.16. Inclusion of IAs in Solicit message by client . . . . . . 56
C.17. Clarification of destination of client messages . . . . . 56
C.18. Clarification of client use of Confirm messages . . . . . 56
Chair's Address 57 Chair's Address 58
Author's Address 57 Author's Address 58
1. Introduction 1. Introduction
This document describes DHCP for IPv6 (DHCP), a UDP [12] This document describes DHCP for IPv6 (DHCP), a UDP [12]
client/server protocol designed to reduce the cost of management client/server protocol designed to reduce the cost of management
of IPv6 nodes in environments where network managers require more of IPv6 nodes in environments where network managers require more
control over the allocation of IPv6 addresses and configuration control over the allocation of IPv6 addresses and configuration
of network stack parameters than that offered by "IPv6 Stateless of network stack parameters than that offered by "IPv6 Stateless
Autoconfiguration" [13]. DHCP is a stateful counterpart to Autoconfiguration" [13]. DHCP is a stateful counterpart to
stateless autoconfiguration. Note that both stateful and stateless stateless autoconfiguration. Note that both stateful and stateless
skipping to change at page 7, line 54 skipping to change at page 7, line 54
for messages sent to agents. Used as the destination for messages sent to agents. Used as the destination
port by relays for messages sent to servers. port by relays for messages sent to servers.
7.3. DHCP message types 7.3. DHCP message types
DHCP defines the following message types. More detail on these DHCP defines the following message types. More detail on these
message types can be found in Section 9. Message types 0 and message types can be found in Section 9. Message types 0 and
TBD--255 are reserved and MUST be silently ignored. The message code TBD--255 are reserved and MUST be silently ignored. The message code
for each message type is shown with the message name. for each message type is shown with the message name.
TBD DHCP Solicit The DHCP Solicit (or Solicit) message SOLICIT (1) The DHCP Solicit (or Solicit) message is used by
is used by clients to locate servers. clients to locate servers.
TBD DHCP Advertise The DHCP Advertise (or Advertise) ADVERTISE (2) The DHCP Advertise (or Advertise) message is used
message is used by servers responding by servers responding to Solicits.
to Solicits.
TBD DHCP Request The DHCP Request (or Request) REQUEST (3) The DHCP Request (or Request) message is used by
message is used by clients to request clients to request configuration parameters from
configuration parameters from servers. servers.
TBD DHCP Confirm The DHCP Confirm (or Confirm) message CONFIRM (4) The DHCP Confirm (or Confirm) message is used by
is used by clients to confirm that clients to confirm that the addresses assigned
the addresses assigned to an IA and to an IA and the lifetimes for those addresses,
the lifetimes for those addresses, as well as the current configuration parameters
as well as the current configuration assigned by the server to the client are still
parameters assigned by the server to valid.
the client are still valid.
TBD DHCP Renew The DHCP Renew (or Renew) message RENEW (5) The DHCP Renew (or Renew) message is used by
is used by clients to obtain the clients to obtain the addresses assigned to an IA
addresses assigned to an IA and the and the lifetimes for those addresses, as well as
lifetimes for those addresses, as the current configuration parameters assigned by
well as the current configuration the server to the client. A client sends a Renew
parameters assigned by the server to message to the server that originally assigned the
the client. A client sends a Renew IA when the lease on an IA is about to expire.
message to the server that originally
assigned the IA when the lease on an
IA is about to expire.
TBD DHCP Rebind The DHCP Rebind (or Rebind) message REBIND (6) The DHCP Rebind (or Rebind) message is used by
is used by clients to obtain the clients to obtain the addresses assigned to an IA
addresses assigned to an IA and the and the lifetimes for those addresses, as well
lifetimes for those addresses, as as the current configuration parameters assigned
well as the current configuration by the server to the client. A clients sends a
parameters assigned by the server to Rebind message to all available DHCP servers when
the client. A clients sends a Rebind the lease on an IA is about to expire.
message to all available DHCP servers
when the lease on an IA is about to
expire.
TBD DHCP Reply The DHCP Reply (or Reply) message is REPLY (7) The DHCP Reply (or Reply) message is used by
used by servers responding to Request, servers responding to Request, Confirm, Renew,
Confirm, Renew, Rebind, Release and Rebind, Release and Decline messages. In the case
Decline messages. In the case of of responding to a Request, Confirm, Renew or
responding to a Request, Confirm, Rebind message, the Reply contains configuration
Renew or Rebind message, the Reply parameters destined for the client.
contains configuration parameters
destined for the client.
TBD DHCP Release The DHCP Release (or Release) message RELEASE (8) The DHCP Release (or Release) message is used by
is used by clients to return one or clients to return one or more IP addresses to
more IP addresses to servers. servers.
TBD DHCP Decline The DHCP Decline (or Decline) message DECLINE (9) The DHCP Decline (or Decline) message is used by
is used by clients to indicate that clients to indicate that the client has determined
the client has determined that one or that one or more addresses in an IA are already in
more addresses in an IA are already in use on the link to which the client is connected.
use on the link to which the client is
connected.
TBD DHCP Reconfigure-init The DHCP Reconfigure-init (or RECONFIG (10) The DHCP Reconfigure-init (or Reconfigure-init)
Reconfigure-init) message is set by message is sent by server(s) to inform
server(s) to inform client(s) that client(s) that the server(s) has new or updated
the server(s) has new or updated configuration parameters, and that the client(s)
configuration parameters, and that are to initiate a Request/Reply transaction with
the client(s) are to initiate a the server(s) in order to receive the updated
Request/Reply transaction with the information.
server(s) in order to receive the
updated information. RELAY-FORW (11) The DHCP Relay-forward (or Relay-forward) message
is used by relays to forward client messages to
servers. The client message is encapsulated in an
option in the Relay-forward message.
RELAY-REPL (12) The DHCP Relay-reply (or Relay-reply) message
is used by servers to send messages to clients
through a relay. The server encapsulates the
client message as an option in the Relay-reply
message, which the relay extracts and forwards to
the client.
7.4. Error Values 7.4. Error Values
This section describes error values exchanged between DHCP This section describes error values exchanged between DHCP
implementations. implementations.
7.4.1. Generic Error Values 7.4.1. Generic Error Values
The following symbolic names are used between client and server The following symbolic names are used between client and server
implementations to convey error conditions. The following table implementations to convey error conditions. The following table
skipping to change at page 10, line 53 skipping to change at page 10, line 53
router advertisements to determine if DHCP should be used to router advertisements to determine if DHCP should be used to
configure the interface. If there are no routers present, then configure the interface. If there are no routers present, then
the node MUST use DHCP to configure the interface. Detail on the node MUST use DHCP to configure the interface. Detail on
this process can be found in neighbor discovery [10] and stateless this process can be found in neighbor discovery [10] and stateless
autoconfiguration [13]. autoconfiguration [13].
8.2. What if the client and server(s) are on different links? 8.2. What if the client and server(s) are on different links?
Use of DHCP in such environments requires one or more DHCP relays Use of DHCP in such environments requires one or more DHCP relays
be set up on the client's link, because a client may only have a be set up on the client's link, because a client may only have a
link-local address. Relays receive the Solicit and Request messages link-local address. Relays receive messages from the client and
from the client and forward them to some set of servers within the forward them to some set of servers within the DHCP domain. The
DHCP domain. The client message is forwarded verbatim as the payload client message is forwarded verbatim as an option in the message
in a message from the relay to the server. A relay will include from the relay to the server. A relay will include one of its own
one of its own addresses (of sufficient scope) from the interface addresses (of sufficient scope) from the interface on the same link
on the same link as the client, as well as the prefix length of as the client, as well as the prefix length of that address, in its
that address, in its message to the server. Servers receiving message to the server. Servers receiving the forwarded traffic
the forwarded traffic use this information to aid in selecting use this information to aid in selecting configuration parameters
configuration parameters appropriate to the client's link. The appropriate to the client's link.
servers also use the relay's address as the destination to forward
client-destined messages for final delivery by the relay. Servers use relays to forward messages to clients. The message
intended for the client is carried as an option in the message to the
relay. The relay extracts the message from the optin and forwards it
to the client. Servers use the relay's address as the destination to
forward client-destined messages for final delivery by the relay.
Relays forward client messages to servers using some combination Relays forward client messages to servers using some combination
of the All DHCP Servers site-local multicast address, some other of the All DHCP Servers site-local multicast address, some other
(perhaps a combination) of site-local multicast addresses set up (perhaps a combination) of site-local multicast addresses set up
within the DHCP domain to include the servers in that domain, or a within the DHCP domain to include the servers in that domain, or a
list of unicast addresses for servers. The network administrator list of unicast addresses for servers. The network administrator
makes relay configuration decisions based upon the topological makes relay configuration decisions based upon the topological
requirements (scope) of the DHCP domain they are managing. Note requirements (scope) of the DHCP domain they are managing. Note
that if the DHCP domain spans more than the site-local scope, then that if the DHCP domain spans more than the site-local scope, then
the relays MUST be configured with global addresses for the client's the relays MUST be configured with global addresses for the client's
link so as to be reachable by servers outside the relays' site-local link so as to be reachable by servers outside the relays' site-local
environment. environment.
8.3. How does a client request configuration parameters from servers? 8.3. How does a client request configuration parameters from servers?
To request configuration parameters, the client forms a Request To request configuration parameters, the client forms a Request
message, and sends it to the server either directly (client has an message, and sends it to the server either directly (the server is
address of sufficient scope) or indirectly (through the on-link on the same link as the client) or indirectly (through the on-link
relay). The client MAY include a Option Request Option 16.3 (ORO) relay). The client MAY include a Option Request Option 16.3 (ORO)
along with other options to request specific information from the along with other options to request specific information from the
server. Note that the client MAY form multiple Request messages server. Note that the client MAY form multiple Request messages
and send each of them to different servers to request potentially and send each of them to different servers to request potentially
different information (perhaps based upon what was advertised) in different information (perhaps based upon what was advertised) in
order to satisfy its needs. As a client's needs may change over time order to satisfy its needs. As a client's needs may change over time
(perhaps based upon an application's requirements), the client may (perhaps based upon an application's requirements), the client may
form additional Request messages to request additional information as form additional Request messages to request additional information as
it is needed. it is needed.
skipping to change at page 12, line 31 skipping to change at page 12, line 39
server cannot be reached after a certain number of attempts (see server cannot be reached after a certain number of attempts (see
section 7.5), the client can abandon the Release attempt. In this section 7.5), the client can abandon the Release attempt. In this
case, the address(es) in the IA will be reclaimed by the server(s) case, the address(es) in the IA will be reclaimed by the server(s)
when the lifetimes on the addresses expire. when the lifetimes on the addresses expire.
8.6. What if the client determines one or more of its assigned addresses 8.6. What if the client determines one or more of its assigned addresses
are already being used by another client? are already being used by another client?
If the client determines through a mechanism like Duplicate Address If the client determines through a mechanism like Duplicate Address
Detection [13] that the address it was assigned by the server is Detection [13] that the address it was assigned by the server is
already in use by another client, the client will form a Release already in use by another client, the client will form a Decline
message, including the option carrying the in-use address. The message, including the option carrying the in-use address. The
option's status field MUST be set to the value reflecting the "in option's status field MUST be set to the value reflecting the "in
use" status of the address. use" status of the address.
8.7. How are clients notified of server configuration changes? 8.7. How are clients notified of server configuration changes?
There are two possibilities. Either the clients discover the new There are two possibilities. Either the clients discover the new
information when they revisit the server(s) to request additional information when they revisit the server(s) to request additional
configuration information/extend the lifetime on an address. or configuration information/extend the lifetime on an address. or
through a server-initiated event known as a reconfigure event. through a server-initiated event known as a reconfigure event.
skipping to change at page 13, line 40 skipping to change at page 13, line 46
| (16 octets) | | (16 octets) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . .
. options . . options .
| (variable) | | (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
9.1. DHCP Solicit Message Format 9.1. DHCP Solicit Message Format
msg-type TBD msg-type SOLICIT
preference (unused) MUST be 0 preference (unused) MUST be 0
transaction-ID An unsigned integer generated by the transaction-ID An unsigned integer generated by the
client used to identify this Solicit client used to identify this Solicit
message. message.
client-link-local-address The link-local address of the client-link-local-address The link-local address of the
interface for which the client is interface for which the client is
using DHCP. using DHCP.
skipping to change at page 14, line 4 skipping to change at page 14, line 10
transaction-ID An unsigned integer generated by the transaction-ID An unsigned integer generated by the
client used to identify this Solicit client used to identify this Solicit
message. message.
client-link-local-address The link-local address of the client-link-local-address The link-local address of the
interface for which the client is interface for which the client is
using DHCP. using DHCP.
server-address (unused) MUST be 0 server-address (unused) MUST be 0
options See section 16. options See section 16.
9.2. DHCP Advertise Message Format 9.2. DHCP Advertise Message Format
msg-type TBD msg-type ADVERTISE
preference An unsigned integer indicating a preference An unsigned integer indicating a
server's willingness to provide server's willingness to provide
service to the client. service to the client.
transaction-ID An unsigned integer used to identify transaction-ID An unsigned integer used to identify
this Advertise message. Copied from this Advertise message. Copied from
the client's Solicit message. the client's Solicit message.
client-link-local-address The IP link-local address of the client-link-local-address The IP link-local address of the
skipping to change at page 14, line 31 skipping to change at page 14, line 38
server-address The IP address of the server that server-address The IP address of the server that
generated this message. If the DHCP generated this message. If the DHCP
domain crosses site boundaries, then domain crosses site boundaries, then
this address MUST be globally-scoped. this address MUST be globally-scoped.
options See section 16. options See section 16.
9.3. DHCP Request Message Format 9.3. DHCP Request Message Format
msg-type TBD msg-type REQUEST
preference (unused) MUST be 0 preference (unused) MUST be 0
transaction-ID An unsigned integer generated by the transaction-ID An unsigned integer generated by the
client used to identify this Request client used to identify this Request
message. message.
client-link-local-address The link-local address of the client client-link-local-address The link-local address of the client
interface from which the client will interface from which the client will
issue the Request message. issue the Request message.
server-address The IP address of the server to which server-address The IP address of the server to which
the this message is directed, copied the this message is directed, copied
from an Advertise message. from an Advertise message.
options See section 16. options See section 16.
9.4. DHCP Confirm Message Format 9.4. DHCP Confirm Message Format
msg-type TBD msg-type CONFIRM
preference (unused) MUST be 0 preference (unused) MUST be 0
transaction-ID An unsigned integer generated by the transaction-ID An unsigned integer generated by the
client used to identify this Confirm client used to identify this Confirm
message. message.
client-link-local-address The link-local address of the client client-link-local-address The link-local address of the client
interface from which the client will interface from which the client will
issue the Request message. issue the Confirm message.
server-address MUST be zero. server-address MUST be zero.
options See section 16. options See section 16.
9.5. DHCP Renew Message Format 9.5. DHCP Renew Message Format
msg-type TBD msg-type RENEW
preference (unused) MUST be 0 preference (unused) MUST be 0
transaction-ID An unsigned integer generated by the transaction-ID An unsigned integer generated by the
client used to identify this Request client used to identify this Renew
message. message.
client-link-local-address The link-local address of the client client-link-local-address The link-local address of the client
interface from which the client will interface from which the client will
issue the Request message. issue the Renew message.
server-address The IP address of the server to which server-address The IP address of the server to which
this Renew message is directed, which this Renew message is directed, which
MUST be the address of the server from MUST be the address of the server from
which the IAs in this message were which the IAs in this message were
originally assigned. originally assigned.
options See section 16. options See section 16.
9.6. DHCP Rebind Message Format 9.6. DHCP Rebind Message Format
msg-type TBD msg-type REBIND
preference (unused) MUST be 0 preference (unused) MUST be 0
transaction-ID An unsigned integer generated by the transaction-ID An unsigned integer generated by the
client used to identify this Request client used to identify this Rebind
message. message.
client-link-local-address The link-local address of the client client-link-local-address The link-local address of the client
interface from which the client will interface from which the client will
issue the Request message. issue the Rebind message.
server-address MUST be zero. server-address MUST be zero.
options See section 16. options See section 16.
9.7. DHCP Reply Message Format 9.7. DHCP Reply Message Format
msg-type TBD msg-type REPLY
preference An unsigned integer indicating a preference An unsigned integer indicating a
server's willingness to provide server's willingness to provide
service to the client. service to the client.
transaction-ID An unsigned integer used to identify transaction-ID An unsigned integer used to identify
this Reply message. Copied from the this Reply message. Copied from the
client's Request message. client's Request, Confirm, Renew or
Rebind message.
client-link-local-address The link-local address of the client-link-local-address The link-local address of the
interface for which the client is interface for which the client is
using DHCP. using DHCP.
server-address The IP address of the server. server-address The IP address of the server.
If the DHCP domain crosses site If the DHCP domain crosses site
boundaries, then this address MUST be boundaries, then this address MUST be
globally-scoped. globally-scoped.
options See section 16. options See section 16.
9.8. DHCP Release Message Format 9.8. DHCP Release Message Format
msg-type TBD msg-type RELEASE
preference (unused) MUST be 0 preference (unused) MUST be 0
transaction-ID An unsigned integer generated by the transaction-ID An unsigned integer generated by the
client used to identify this Release client used to identify this Release
message. message.
client-link-local-address The client's link-local address for client-link-local-address The client's link-local address for
the interface from which the client the interface from which the client
issued the Release message. will send the Release message.
server-address The IP address of the server that server-address The IP address of the server that
assigned the addresses. assigned the IA.
options See section 16. options See section 16.
9.9. DHCP Decline Message Format 9.9. DHCP Decline Message Format
msg-type TBD msg-type DECLINE
preference (unused) MUST be 0 preference (unused) MUST be 0
transaction-ID An unsigned integer generated by the transaction-ID An unsigned integer generated by the
client used to identify this Release client used to identify this Decline
message. message.
client-link-local-address The client's link-local address for client-link-local-address The client's link-local address for
the interface from which the client the interface from which the client
issued the Release message. will send the Decline message.
server-address The IP address of the server that server-address The IP address of the server that
assigned the addresses. assigned the addresses.
options See section 16. options See section 16.
9.10. DHCP Reconfigure-init Message Format 9.10. DHCP Reconfigure-init Message Format
preference (unused) MUST be 0 preference (unused) MUST be 0
skipping to change at page 17, line 51 skipping to change at page 18, line 20
| msg-type | prefix length | | | msg-type | prefix length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| relay-address | | relay-address |
| | | |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| options (variable number and length) .... | | options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type TBD msg-type RELAY-FORW
prefix-length The length of the prefix in the address in the prefix-length The length of the prefix in the address in the
"relay-address" field. "relay-address" field.
relay-address An address assigned to the interface through which relay-address An address assigned to the interface through which
the message from the client was received. the message from the client was received.
options MUST include a "Client message option"; see options MUST include a "Client message option"; see
section 16.4. section 16.4.
10.2. Relay-reply message 10.2. Relay-reply message
skipping to change at page 18, line 28 skipping to change at page 18, line 46
| msg-type | prefix length | | | msg-type | prefix length | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
| relay-address | | relay-address |
| | | |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| | |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| options (variable number and length) .... | | options (variable number and length) .... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type TBD msg-type RELAY-REPL
prefix-length The length of the prefix in the address in the prefix-length The length of the prefix in the address in the
"relay-address" field. "relay-address" field.
relay-address An address identifying the interface through which relay-address An address identifying the interface through which
the message from the server should be forwarded; the message from the server should be forwarded;
copied from the "client-forward" message. copied from the "client-forward" message.
options MUST include a "Server message option"; see options MUST include a "Server message option"; see
section 16.5. section 16.5.
skipping to change at page 19, line 7 skipping to change at page 19, line 21
and a client can identify, group and manage IPv6 addresses. Each IA and a client can identify, group and manage IPv6 addresses. Each IA
consists of a DUID and a list of associated IPv6 addresses (the list consists of a DUID and a list of associated IPv6 addresses (the list
may be empty). A client associates an IA with one of its interfaces may be empty). A client associates an IA with one of its interfaces
and uses the IA to obtain IPv6 addresses for that interface from a and uses the IA to obtain IPv6 addresses for that interface from a
server. server.
See section 16.2 for the representation of an IA in a DHCP message. See section 16.2 for the representation of an IA in a DHCP message.
12. DHCP Server Solicitation 12. DHCP Server Solicitation
This section describes how a client locates servers. The behavior of This section describes how a client locates servers. The behavior
client, server, and relay implementations is discussed, along with of client and server implementations is discussed, along with the
the messages they use. messages they use.
12.1. Solicit Message Validation 12.1. Solicit Message Validation
Clients MUST silently discard any received Solicit messages. Clients MUST silently discard any received Solicit messages.
Agents MUST silently discard any received Solicit messages if the Agents MUST silently discard any received Solicit messages if the
"client-link-local-address" field does not contain a valid link-local "client-link-local-address" field does not contain a valid link-local
address. address.
12.2. Advertise Message Validation 12.2. Advertise Message Validation
skipping to change at page 19, line 40 skipping to change at page 20, line 7
link-local address of the interface upon which the client sent link-local address of the interface upon which the client sent
the Solicit message. the Solicit message.
12.3. Client Behavior 12.3. Client Behavior
Clients use the Solicit message to discover DHCP servers configured Clients use the Solicit message to discover DHCP servers configured
to serve addresses on the link to which the client is attached. to serve addresses on the link to which the client is attached.
12.3.1. Creation and sending of the Solicit message 12.3.1. Creation and sending of the Solicit message
The client sets the "msg-type" field to TBD, and places the The client sets the "msg-type" field to SOLICIT, and places the
link-local address of the interface it wishes to configure in the link-local address of the interface it wishes to configure in the
"client-link-local-address" field. "client-link-local-address" field.
The client generates a transaction ID inserts this value in the The client generates a transaction ID inserts this value in the
"transaction-ID" field. "transaction-ID" field.
The client MAY include an Option Request Option in the Solicit The client MUST include options for any IAs to which the client is
message. The client MUST NOT include any other options except those expecting to have the server assign addresses. Because the client
specifically allowed as defined by specific options. does not have any IAs with addresses when sending a Solicit message,
all of the IAs MUST be empty. The client MAY include an Option
Request Option in the Solicit message. The client MUST NOT include
any other options except those specifically allowed as defined by
specific options.
The client sends the Solicit message to the All DHCP Agents The client sends the Solicit message to the All DHCP Agents
multicast address, destination port 547. The source port selection multicast address, destination port 547. The source port selection
can be arbitrary, although it SHOULD be possible using a client can be arbitrary, although it SHOULD be possible using a client
configuration facility to set a specific source port value. configuration facility to set a specific source port value.
12.3.2. Time out and retransmission of Solicit Messages 12.3.2. Time out and retransmission of Solicit Messages
The client's first Solicit message on the interface MUST be delayed The client's first Solicit message on the interface MUST be delayed
by a random amount of time between the interval of MIN_SOL_DELAY and by a random amount of time between the interval of MIN_SOL_DELAY and
skipping to change at page 20, line 52 skipping to change at page 21, line 20
interest to the client. interest to the client.
Once a client has selected Advertise message(s), the client will Once a client has selected Advertise message(s), the client will
typically store information about each server, such as server typically store information about each server, such as server
preference value, addresses advertised, when the advertisement was preference value, addresses advertised, when the advertisement was
received, and so on. Depending on the requirements of the client's received, and so on. Depending on the requirements of the client's
invoking user, the client MAY initiate a configuration exchange with invoking user, the client MAY initiate a configuration exchange with
the server(s) immediately, or MAY defer this exchange until later. the server(s) immediately, or MAY defer this exchange until later.
If the client needs to select an alternate server in the case that a If the client needs to select an alternate server in the case that a
chosen server does not respond, the client choose the server with the chosen server does not respond, the client chooses the server with
next highest preference value. the next highest preference value.
The client MAY choose a less-preferred server if that server has a The client MAY choose a less-preferred server if that server has a
better set of advertised parameters. better set of advertised parameters, such as the available addresses
advertised in IAs.
12.4. Server Behavior 12.4. Server Behavior
For this discussion, the Server is assumed to have been configured in For this discussion, the server is assumed to have been configured in
an implementation specific manner. This configuration is assumed to an implementation specific manner. This configuration is assumed to
contain all network topology information for the DHCP domain, as well contain all network topology information for the DHCP domain, as well
as any necessary authentication information. as any necessary authentication information.
12.4.1. Receipt of Solicit messages 12.4.1. Receipt of Solicit messages
If the server receives a Solicit message, the client must be on the If the server receives a Solicit message, the client must be on the
same link as the server. If the server receives a Relay-forward same link as the server. If the server receives a Relay-forward
message containing a Solicit message, the client must be on the message containing a Solicit message, the client must be on the
link to which the prefix identified by the "relay-address" and link to which the prefix identified by the "relay-address" and
skipping to change at page 21, line 32 skipping to change at page 21, line 51
The server records the "relay-address" field from the Relay-forward The server records the "relay-address" field from the Relay-forward
message and extracts the solicit message from the "client-message" message and extracts the solicit message from the "client-message"
option. option.
If administrative policy permits the server to respond to a client on If administrative policy permits the server to respond to a client on
that link, the server will generate and send an Advertise message to that link, the server will generate and send an Advertise message to
the client. the client.
12.4.2. Creation and sending of Advertise messages 12.4.2. Creation and sending of Advertise messages
The server sets the "msg-type" field to TBD and copies the values The server sets the "msg-type" field to ADVERTISE and copies the
of the following fields from the client's Solicit to the Advertise values of the following fields from the client's Solicit to the
message: Advertise message:
o transaction-ID o transaction-ID
o client-link-local-address o client-link-local-address
The server places one of its IP addresses (determined through The server places one of its IP addresses (determined through
administrator setting) in the "server-address" field of the Advertise administrator setting) in the "server-address" field of the Advertise
message. The server sets the "preference" field according to its message. The server sets the "preference" field according to its
configuration information. See section 18.3 for a description of configuration information. See section 18.3 for a description of
server preference. server preference.
skipping to change at page 22, line 19 skipping to change at page 22, line 37
the Relay-forward message. the Relay-forward message.
If the Solicit message was received directly by the server, the If the Solicit message was received directly by the server, the
server unicasts the Advertise message directly to the client using server unicasts the Advertise message directly to the client using
the "client-link-local-address" field value as the destination the "client-link-local-address" field value as the destination
address. The Advertise message MUST be unicast through the interface address. The Advertise message MUST be unicast through the interface
on which the Solicit message was received. on which the Solicit message was received.
13. DHCP Client-Initiated Configuration Exchange 13. DHCP Client-Initiated Configuration Exchange
A client initiates a message exchange with the server to acquire A client initiates a message exchange with a server or servers to
or update configuration information of interest. The client may acquire or update configuration information of interest. The client
initiate the configuration exchange as part of the operating system may initiate the configuration exchange as part of the operating
configuration process or when requested to do so by the application system configuration process or when requested to do so by the
layer. application layer.
The client uses the following messages to initiate a configuration The client uses the following messages to initiate a configuration
event with the server: event with a server or servers:
Request Obtain initial configuration information when the client Request Obtain initial configuration information (from a server
has no assigned addresses identified in a previously received Advertise message)
when the client has no assigned addresses
Confirm Confirm the validity of assigned addresses and other Confirm Confirm the validity of assigned addresses and other
configuration changes when the client's assigned configuration changes through the server from which the
addresses may not be valid; for example, when the client configuration information was obtained when the client's
reboots or loses its connection to a link assigned addresses may not be valid; for example, when
the client reboots or loses its connection to a link
Renew Extend the lease on an IA through the server that Renew Extend the lease on an IA through the server that
originally assigned the IA originally assigned the IA
Rebind Extend the lease on an IA through any server willing to Rebind Extend the lease on an IA through any server willing to
extend the lease extend the lease
A client uses the Release-Reply message exchange to indicate to the A client uses the Release/Reply message exchange to indicate to the
DHCP server that the client will no longer be using the addresses in DHCP server that the client will no longer be using the addresses in
the released IA. the released IA.
A client uses the Decline-Reply message exchange to indicate to the A client uses the Decline/Reply message exchange to indicate to the
DHCP server that the client has detected that one or more addresses DHCP server that the client has detected that one or more addresses
assigned by the server is already in use on the client's link. assigned by the server is already in use on the client's link.
13.1. Client Message Validation 13.1. Client Message Validation
Clients MUST silently discard any received client messages (Request, Clients MUST silently discard any received client messages (Request,
Confirm, Renew, Rebind, Release or Decline messages). Confirm, Renew, Rebind, Release or Decline messages).
Agents MUST discard any received client messages in which the Agents MUST discard any received client messages in which the
"client-link-local-address" field does not contain a valid link-local "client-link-local-address" field does not contain a valid link-local
address. address.
Servers MUST discard any received client messages in which the Servers MUST discard any received client messages in which the
"options" field contains an authentication option, and the server "options" field contains an authentication option, and the server
cannot successfully authenticate the client. cannot successfully authenticate the client.
Servers MUST discard any received Request or Renew message in which Servers MUST discard any received Request, Renew, Release or Decline
the "server-address" field value does not match any of the server's message in which the "server-address" field value does not match any
addresses. of the server's addresses.
13.2. Server Message Validation 13.2. Server Message Validation
Servers MUST silently discard any received server messages (Reply Servers MUST silently discard any received server messages (Reply or
messages). Reconfigure-init messages).
Clients MUST discard any server messages that meet any of the Clients MUST discard any server messages that meet any of the
following criteria: following criteria:
o The "transaction-ID" field value in the server message does o The "transaction-ID" field value in the server message does
not match the value the client used in its Request or Release not match the value the client used in its Request or Release
message. message.
o The "client-link-local-address" field value in the server message o The "client-link-local-address" field value in the server message
does not match the link-local address of the interface upon which does not match the link-local address of the interface from which
the client sent in its Request or Release message. the client sent in its Request, Confirm, Renew, Rebind, Release
or Decline message.
o The server message contains an authentication option, and the o The server message contains an authentication option, and the
client's attempt to authenticate the message fails. client's attempt to authenticate the message fails.
Relays MUST discard any Relay-reply message in which the Relays MUST discard any Relay-reply message in which the
"client-link-local-address" in the encapsulated Reply message does "client-link-local-address" in the encapsulated Reply message does
not contain a valid link-local address. not contain a valid link-local address.
13.3. Client Behavior 13.3. Client Behavior
A client will use Request, Confirm, Renew and Rebind messages to A client will use Request, Confirm, Renew and Rebind messages to
acquire and confirm the validity of configuration information. acquire and confirm the validity of configuration information. A
A client may initiate such an exchange automatically in order client may initiate such an exchange automatically in order to
to acquire the necessary network parameters to communicate with acquire the necessary network parameters to communicate with nodes
nodes off-link. The client uses the server address information off-link. The client uses the server address information from
from previous Advertise message(s) for use in constructing Request previous Advertise message(s) for use in constructing Request and
message(s). Note that a client may request configuration information Renew message(s). Note that a client may request configuration
from one or more servers at any time. information from one or more servers at any time.
A client uses the Release message in the management of IAs when A client uses the Release message in the management of IAs when
the client has been instructed to release the IA prior to the IA the client has been instructed to release the IA prior to the IA
expiration time since it is no longer needed. expiration time since it is no longer needed.
A client uses the Decline message when the client has determined A client uses the Decline message when the client has determined
through DAD or some other method that one or more of the addresses through DAD or some other method that one or more of the addresses
assigned by the server in the IA is already in use by a different assigned by the server in the IA is already in use by a different
client. client.
13.3.1. Creation and sending of Request messages 13.3.1. Creation and sending of Request messages
If a client has no valid IPv6 addresses of sufficient scope to If a client has no valid IPv6 addresses of sufficient scope to
communicate with a DHCP server, it may send a Request message to communicate with a DHCP server, it may send a Request message to
obtain new addresses. The client includes one or more IAs in the obtain new addresses. The client includes one or more IAs in the
Request message, to which the server assigns new addresses. The Request message, to which the server assigns new addresses. The
server then returns to IA(s) to the client in a Reply message. server then returns IA(s) to the client in a Reply message.
The client sets the "msg-type" field to TBD, and places the The client sets the "msg-type" field to REQUEST, and places
link-local address of the interface it wishes to acquire the link-local address of the interface it wishes to acquire
configuration information for in the "client-link-local-address" configuration information for in the "client-link-local-address"
field. field.
The client generates a transaction ID inserts this value in the The client generates a transaction ID inserts this value in the
"transaction-ID" field. "transaction-ID" field.
The client places the address of the destination server in the The client places the address of the destination server in the
"server-address" field. "server-address" field.
The client adds any appropriate options, including one or more IA The client adds any appropriate options, including one or more IA
skipping to change at page 25, line 16 skipping to change at page 25, line 36
o The client is physically disconnected from a wired connection o The client is physically disconnected from a wired connection
o The client returns from sleep mode o The client returns from sleep mode
o The client using a wireless technology changes cells o The client using a wireless technology changes cells
In any situation when a client may have moved to a new link, the In any situation when a client may have moved to a new link, the
client MUST initiate a Confirm/Reply message exchange. The client client MUST initiate a Confirm/Reply message exchange. The client
includes any IAs, along with the addresses associated with those IAs, includes any IAs, along with the addresses associated with those IAs,
in its Request message. The server returns the IAs with updated list in its Confirm message. The server will indicate the acceptability
of addresses and associated lifetimes. of the addresses with the status in the IA it returns to the client.
The client sets the "msg-type" field to TBD, and places the DISCUSSION:
link-local address of the interface it wishes to acquire
This section used to allow servers to change the addresses
in an IA. Without some additional mechanism, servers
responding to Confirm messages can't change safely
change the addresses in IAs (although they can change
the lifetimes), because servers may send back different
addresses.
The client sets the "msg-type" field to CONFIRM, and places
the link-local address of the interface it wishes to acquire
configuration information for in the "client-link-local-address" configuration information for in the "client-link-local-address"
field. field.
The client generates a transaction ID inserts this value in the The client generates a transaction ID inserts this value in the
"transaction-ID" field. "transaction-ID" field.
The client sets the "server-address" field to 0. The client sets the "server-address" field to 0.
The client adds any appropriate options, including one or more IA The client adds any appropriate options, including one or more IA
options (if the client is requesting that the server confirm the options (if the client is requesting that the server confirm the
skipping to change at page 25, line 53 skipping to change at page 26, line 31
and doubles the REP_MSG_TIMEOUT value, and waits again. The client and doubles the REP_MSG_TIMEOUT value, and waits again. The client
continues this process until a Reply is received or QRY_MSG_ATTEMPTS continues this process until a Reply is received or QRY_MSG_ATTEMPTS
unsuccessful attempts have been made, at which time the client MUST unsuccessful attempts have been made, at which time the client MUST
abort the configuration attempt. The client SHOULD report the abort abort the configuration attempt. The client SHOULD report the abort
status to the application layer. status to the application layer.
Default and initial values for REP_MSG_TIMEOUT and QRY_MSG_ATTEMPTS Default and initial values for REP_MSG_TIMEOUT and QRY_MSG_ATTEMPTS
are documented in section 7.5. are documented in section 7.5.
If the client receives no response to its Confirm message, it MAY If the client receives no response to its Confirm message, it MAY
restart the configuration process by locating a different DHCP server restart the configuration process by locating a DHCP server with an
with an Advertise message and sending a Request to that server, as Advertise message and sending a Request to that server, as described
described in section 13.3.1. in section 13.3.1.
13.3.3. Creation and sending of Renew messages 13.3.3. Creation and sending of Renew messages
IPv6 addresses assigned to a client through an IA use the same IPv6 addresses assigned to a client through an IA use the same
preferred and valid lifetimes as IPv6 addresses obtained through preferred and valid lifetimes as IPv6 addresses obtained through
stateless autoconfiguration. The server assigns preferred and valid stateless autoconfiguration. The server assigns preferred and valid
lifetimes to the IPv6 addresses it assigns to an IA. To extend those lifetimes to the IPv6 addresses it assigns to an IA. To extend those
lifetimes, the client sends a Request to the server containing an lifetimes, the client sends a Request to the server containing an
"IA option" for the IA and its associated addresses. The server "IA option" for the IA and its associated addresses. The server
determines new lifetimes for the addresses in the IA according to determines new lifetimes for the addresses in the IA according to
skipping to change at page 26, line 28 skipping to change at page 27, line 7
The server controls the time at which the client contacts the server The server controls the time at which the client contacts the server
to extend the lifetimes on assigned addresses through the T1 and to extend the lifetimes on assigned addresses through the T1 and
T2 parameters assigned to an IA. If the server does not assign an T2 parameters assigned to an IA. If the server does not assign an
explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the explicit value to T1 or T2 for an IA, T1 defaults to 0.5 times the
shortest preferred lifetime of any address assigned to the IA and shortest preferred lifetime of any address assigned to the IA and
T2 defaults to 0.875 times the shortest preferred lifetime of any T2 defaults to 0.875 times the shortest preferred lifetime of any
address assigned to the IA. address assigned to the IA.
At time T1 for an IA, the client initiates a Request/Reply message At time T1 for an IA, the client initiates a Request/Reply message
exchange to extend the lifetimes on any addresses in the IA. The exchange to extend the lifetimes on any addresses in the IA. The
client includes an IA option with all addresses currently assigned client includes an IA option with all addresses currently assigned to
to the IA in its Request message. The client unicasts this Request the IA in its Request message. The client multicasts this Request
message to the server that originally assigned the addresses to the message to the All DHCP Agents multicast address.
IA.
The client sets the "msg-type" field to TBD, and places the The client sets the "msg-type" field to RENEW, and places
link-local address of the interface it wishes to acquire the link-local address of the interface it wishes to acquire
configuration information for in the "client-link-local-address" configuration information for in the "client-link-local-address"
field. field.
The client generates a transaction ID inserts this value in the The client generates a transaction ID inserts this value in the
"transaction-ID" field. "transaction-ID" field.
The client places the address of the destination server in the The client places the address of the destination server in the
"server-address" field. "server-address" field.
The client adds any appropriate options, including one or more IA The client adds any appropriate options, including one or more IA
skipping to change at page 27, line 15 skipping to change at page 27, line 47
doubles the REP_MSG_TIMEOUT value, and waits again. The client doubles the REP_MSG_TIMEOUT value, and waits again. The client
continues this process until a Reply is received or until time T2 is continues this process until a Reply is received or until time T2 is
reached (see section 13.3.4). reached (see section 13.3.4).
Default and initial values for REP_MSG_TIMEOUT are documented in Default and initial values for REP_MSG_TIMEOUT are documented in
section 7.5. section 7.5.
13.3.4. Creation and sending of Rebind messages 13.3.4. Creation and sending of Rebind messages
At time T2 for an IA (which will only be reached if the server to At time T2 for an IA (which will only be reached if the server to
which the Request message was sent at time T1 has not responded), which the Renew message was sent at time T1 has not responded),
the client initiates a Request/Reply message exchange. The client the client initiates a Rebind/Reply message exchange. The client
includes an IA option with all addresses currently assigned to the IA includes an IA option with all addresses currently assigned to the IA
in its Request message. The client multicasts this message to the in its Rebind message. The client multicasts this message to the All
All DHCP Agents multicast address. DHCP Agents multicast address.
The client sets the "msg-type" field to TBD, and places the The client sets the "msg-type" field to REBIND, and places
link-local address of the interface it wishes to acquire the link-local address of the interface it wishes to acquire
configuration information for in the "client-link-local-address" configuration information for in the "client-link-local-address"
field. field.
The client generates a transaction ID inserts this value in the The client generates a transaction ID inserts this value in the
"transaction-ID" field. "transaction-ID" field.
The client sets the "server-address" field to 0. The client sets the "server-address" field to 0.
The client adds any appropriate options, including one or more IA The client adds any appropriate options, including one or more IA
options. If the client does include any IA options (if the client is options. If the client does include any IA options (if the client is
skipping to change at page 28, line 22 skipping to change at page 28, line 53
addresses have expired, the client may choose to locate addresses have expired, the client may choose to locate
a new DHCP server a new DHCP server
- The client may have other addresses in other IAs, so the - The client may have other addresses in other IAs, so the
client may choose to discard the expired IA and use the client may choose to discard the expired IA and use the
addresses in the other IAs addresses in the other IAs
13.3.5. Receipt of Reply message in response to a Reply, Confirm, Renew 13.3.5. Receipt of Reply message in response to a Reply, Confirm, Renew
or Rebind message or Rebind message
Upon the receipt of a valid Reply, Confirm, Renew or Rebind message, Upon the receipt of a valid Reply message in response to a
the client extracts the configuration information contained in the Request, Confirm, Renew or Rebind message, the client extracts the
Reply. If the "status" field contains a non-zero value, the client configuration information contained in the Reply. If the "status"
reports the error status to the application layer. field contains a non-zero value, the client reports the error status
to the application layer.
The client records the T1 and T2 times for each IA in the Reply The client records the T1 and T2 times for each IA in the Reply
message. The client records any addresses included with IAs in message. The client records any addresses included with IAs in
the Reply message. The client updates the preferred and valid the Reply message. The client updates the preferred and valid
lifetimes for the addresses in the IA from the lifetime information lifetimes for the addresses in the IA from the lifetime information
in the IA option. The client leaves any addresses that the client in the IA option. The client leaves any addresses that the client
has associated with the IA that are not included in the IA option has associated with the IA that are not included in the IA option
unchanged. unchanged.
Management of the specific configuration information is detailed in Management of the specific configuration information is detailed in
the definition of each option, in section 16. the definition of each option, in section 16.
When the client receives an Unavail error status in an IA from the When the client receives an Unavail error status in an IA from the
server for a Request message the client will have to find a new server for a Request message the client will have to find a new
server to create an IA Association. server to create an IA.
When the client receives a NoBinding error status in an IA from the When the client receives a NoBinding error status in an IA from the
server for a Confirm message the client can assume it needs to send a server for a Confirm message the client can assume it needs to send a
Request to reestablish an IA Association with the server. Request to reestablish an IA with the server.
When the client receives a Conf_NoMatch error status in an IA from When the client receives a Conf_NoMatch error status in an IA from
the server for a Confirm message the client can send a Renew message the server for a Confirm message the client can send a Renew message
to the server to extend the lease for the addresses. to the server to extend the lease for the addresses.
When the client receives a NoBinding error status in an IA from the When the client receives a NoBinding error status in an IA from the
server for a Renew message the client can assume it needs to send a server for a Renew message the client can assume it needs to send a
Request to reestablish an IA Association with the server. Request to reestablish an IA with the server.
When the client receives a Renw_NoMatch error status in an IA from When the client receives a Renw_NoMatch error status in an IA from
the server for a Renew message the client can assume it needs to send the server for a Renew message the client can assume it needs to send
a Request to reestablish an IA Association with the server. a Request to reestablish an IA with the server.
When the client receives an Unavail error status in an IA from the When the client receives an Unavail error status in an IA from the
server for a Renew message the client can assume it needs to send a server for a Renew message the client can assume it needs to send a
Request to reestablish an IA Association set of addresses with the Request to reestablish an IA with the server.
server.
When the client receives a NoBinding error status in an IA from the When the client receives a NoBinding error status in an IA from the
server for a Rebind message the client can assume it needs to send server for a Rebind message the client can assume it needs to send a
a Request to reestablish an IA Association with the server or try Request to reestablish an IA with the server or try another server.
another server.
When the client receives a Rebd_NoMatch error status in an IA from When the client receives a Rebd_NoMatch error status in an IA from
the server for a Rebind message the client can assume it needs to the server for a Rebind message the client can assume it needs to
send a Request to reestablish an IA Association with the server or send a Request to reestablish an IA with the server or try another
try another server. server.
When the client receives an Unavail error status in an IA from the When the client receives an Unavail error status in an IA from the
server for a Rebind message the client can assume it needs to send a server for a Rebind message the client can assume it needs to send a
Request to reestablish an IA Association set of addresses with the Request to reestablish an IA with the server or try another server.
server or try another server.
13.3.6. Creation and sending of Release messages 13.3.6. Creation and sending of Release messages
The client sets the "msg-type" field to TBD, and places the The client sets the "msg-type" field to RELEASE, and places the
link-local address of the interface associated with the configuration link-local address of the interface associated with the configuration
information it wishes to release in the "client-link-local-address" information it wishes to release in the "client-link-local-address"
field. field.
The client generates a transaction ID and places this value in the The client generates a transaction ID and places this value in the
"transaction-ID" field. "transaction-ID" field.
The client places the IP address of the server that allocated the The client places the IP address of the server that allocated the
address(es) in the "server-address" field. address(es) in the "server-address" field.
The client includes options containing the IAs it is releasing in the The client includes options containing the IAs it is releasing in the
"options" field. The appropriate "status" field in the options MUST "options" field. The addresses to be released MUST be included in
be set to indicate the reason for the release. the IAs. The appropriate "status" field in the options MUST be set
to indicate the reason for the release.
If the client is configured to use authentication, the client If the client is configured to use authentication, the client
generates the appropriate authentication option, and adds this option generates the appropriate authentication option, and adds this option
to the "options" field. Note that the authentication option MUST be to the "options" field. Note that the authentication option MUST be
the last option in the "options" field. See section 16.7 for more the last option in the "options" field. See section 16.9 for more
details about the authentication option. details about the authentication option.
The client send the Release message to the All DHCP Agents multicast
address.
13.3.7. Time out and retransmission of Release Messages 13.3.7. Time out and retransmission of Release Messages
If no Reply message is received within REP_MSG_TIMEOUT milliseconds, If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Release, doubles the REP_MSG_TIMEOUT the client retransmits the Release, doubles the REP_MSG_TIMEOUT
value, and waits again. The client continues this process until a value, and waits again. The client continues this process until a
Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have been Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have been
made, at which time the client SHOULD abort the release attempt. made, at which time the client SHOULD abort the release attempt.
The client SHOULD return the abort status to the application, if an The client SHOULD return the abort status to the application, if an
application initiated the release. application initiated the release.
Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
are documented in section 7.5. are documented in section 7.5.
Note that if the client fails to release the IA, the addresses Note that if the client fails to release the IA, the addresses
assigned to the IA will be reclaimed by the server when the lease assigned to the IA will be reclaimed by the server when the lease
associated with it expires. associated with it expires.
skipping to change at page 30, line 17 skipping to change at page 30, line 51
Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
are documented in section 7.5. are documented in section 7.5.
Note that if the client fails to release the IA, the addresses Note that if the client fails to release the IA, the addresses
assigned to the IA will be reclaimed by the server when the lease assigned to the IA will be reclaimed by the server when the lease
associated with it expires. associated with it expires.
13.3.8. Creation and sending of Decline messages 13.3.8. Creation and sending of Decline messages
The client sets the "msg-type" field to TBD, and places the The client sets the "msg-type" field to DECLINE, and places the
link-local address of the interface associated with the configuration link-local address of the interface associated with the configuration
information it wishes to decline in the "client-link-local-address" information it wishes to decline in the "client-link-local-address"
field. field.
The client generates a transaction ID and places this value in the The client generates a transaction ID and places this value in the
"transaction-ID" field. "transaction-ID" field.
The client places the IP address of the server that allocated the The client places the IP address of the server that allocated the
address(es) in the "server-address" field. address(es) in the "server-address" field.
The client includes options containing the IAs it is declining in the The client includes options containing the IAs it is declining in the
"options" field. The appropriate "status" field in the options MUST "options" field. The addresses to be released MUST be included in
be set to indicate the reason for declining the address. the IAs. The appropriate "status" field in the options MUST be set
to indicate the reason for declining the address.
If the client is configured to use authentication, the client If the client is configured to use authentication, the client
generates the appropriate authentication option, and adds this option generates the appropriate authentication option, and adds this option
to the "options" field. Note that the authentication option MUST be to the "options" field. Note that the authentication option MUST be
the last option in the "options" field. See section 16.7 for more the last option in the "options" field. See section 16.9 for more
details about the authentication option. details about the authentication option.
The client send the Decline message to the All DHCP Agents multicast
address.
13.3.9. Time out and retransmission of Decline Messages 13.3.9. Time out and retransmission of Decline Messages
If no Reply message is received within REP_MSG_TIMEOUT milliseconds, If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Decline, doubles the REP_MSG_TIMEOUT the client retransmits the Decline, doubles the REP_MSG_TIMEOUT
value, and waits again. The client continues this process until a value, and waits again. The client continues this process until a
Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have
been made, at which time the client SHOULD abort the attempt to been made, at which time the client SHOULD abort the attempt to
decline the address. The client SHOULD return the abort status to decline the address. The client SHOULD return the abort status to
the application, if an application initiated the release. the application, if an application initiated the release.
skipping to change at page 31, line 30 skipping to change at page 32, line 18
can respond to, (implementation-specific administrative policy can respond to, (implementation-specific administrative policy
satisfied) the server scans the options field. satisfied) the server scans the options field.
The server then constructs a Reply message and sends it to the The server then constructs a Reply message and sends it to the
client. client.
The server SHOULD process each option for the client in an The server SHOULD process each option for the client in an
implementation-specific manner. The server MUST construct a Reply implementation-specific manner. The server MUST construct a Reply
message containing the following values: message containing the following values:
msg-type TBD msg-type REPLY
preference Enter the servers preference to preference Enter the servers preference to
provide services to the client. provide services to the client.
transaction-ID Enter the transaction-ID from the transaction-ID Enter the transaction-ID from the
Request message. Request message.
client-link-local address Enter the client-link-local address client-link-local address Enter the client-link-local address
from the Request message. from the Request message.
skipping to change at page 32, line 5 skipping to change at page 32, line 44
that client in an implementation-specific manner within the servers that client in an implementation-specific manner within the servers
configuration parameter database for DHCP clients. configuration parameter database for DHCP clients.
If the server cannot provide addresses to the client it SHOULD send If the server cannot provide addresses to the client it SHOULD send
back an empty IA to the client with the status field set to Unavail. back an empty IA to the client with the status field set to Unavail.
If the server can provide addresses to the client it MUST send back If the server can provide addresses to the client it MUST send back
the IA to the client with all fields entered and a status of Success, the IA to the client with all fields entered and a status of Success,
and add the IA as a new client binding. and add the IA as a new client binding.
The server adds options to the Reply message for any other
configuration information to be assigned to the client.
13.4.2. Receipt of Confirm messages 13.4.2. Receipt of Confirm messages
Upon the receipt of a valid Confirm message from a client the server Upon the receipt of a valid Confirm message from a client the server
can respond to, (implementation-specific administrative policy can respond to, (implementation-specific administrative policy
satisfied) the server scans the options field. satisfied) the server scans the options field.
The server then constructs a Reply message and sends it to the The server then constructs a Reply message and sends it to the
client. client.
The server SHOULD process each option for the client in an The server SHOULD process each option for the client in an
implementation-specific manner. The server MUST construct a Reply implementation-specific manner. The server MUST construct a Reply
message containing the following values: message containing the following values:
msg-type TBD msg-type REPLY
preference Enter the servers preference to preference Enter the servers preference to
provide services to the client. provide services to the client.
transaction-ID Enter the transaction-ID from the transaction-ID Enter the transaction-ID from the
Confirm message. Confirm message.
client-link-local address Enter the client-link-local address client-link-local address Enter the client-link-local address
from the Confirm message. from the Confirm message.
skipping to change at page 33, line 9 skipping to change at page 33, line 51
can respond to, (implementation-specific administrative policy can respond to, (implementation-specific administrative policy
satisfied) the server scans the options field. satisfied) the server scans the options field.
The server then constructs a Reply message and sends it to the The server then constructs a Reply message and sends it to the
client. client.
The server SHOULD process each option for the client in an The server SHOULD process each option for the client in an
implementation-specific manner. The server MUST construct a Reply implementation-specific manner. The server MUST construct a Reply
message containing the following values: message containing the following values:
msg-type TBD msg-type REPLY
preference Enter the servers preference to preference Enter the servers preference to
provide services to the client. provide services to the client.
transaction-ID Enter the transaction-ID from the transaction-ID Enter the transaction-ID from the
Confirm message. Confirm message.
client-link-local address Enter the client-link-local address client-link-local address Enter the client-link-local address
from the Confirm message. from the Confirm message.
skipping to change at page 33, line 54 skipping to change at page 34, line 45
can respond to, (implementation-specific administrative policy can respond to, (implementation-specific administrative policy
satisfied) the server scans the options field. satisfied) the server scans the options field.
The server then constructs a Reply message and sends it to the The server then constructs a Reply message and sends it to the
client. client.
The server SHOULD process each option for the client in an The server SHOULD process each option for the client in an
implementation-specific manner. The server MUST construct a Reply implementation-specific manner. The server MUST construct a Reply
message containing the following values: message containing the following values:
msg-type TBD msg-type REPLY
preference Enter the servers preference to preference Enter the servers preference to
provide services to the client. provide services to the client.
transaction-ID Enter the transaction-ID from the transaction-ID Enter the transaction-ID from the
Confirm message. Confirm message.
client-link-local address Enter the client-link-local address client-link-local address Enter the client-link-local address
from the Confirm message. from the Confirm message.
server address Enter the server's address. server address Enter the server's address.
When the server receives a Renew and IA option from a client it When the server receives a Rebind and IA option from a client it
SHOULD locate the clients binding and verify the information in the SHOULD locate the clients binding and verify the information in the
IA from the client matches the information stored for that client. IA from the client matches the information stored for that client.
If the server cannot find a client entry for this IA the server If the server cannot find a client entry for this IA the server
SHOULD return an empty IA with status set to NoBinding. SHOULD return an empty IA with status set to NoBinding.
If the server finds that the addresses in the IA for the client do If the server finds that the addresses in the IA for the client do
not match the clients binding the server should return an empty IA not match the clients binding the server should return an empty IA
with status set to Rebd_NoMatch. with status set to Rebd_NoMatch.
skipping to change at page 35, line 4 skipping to change at page 35, line 45
"status" field to "Success". If any of the IAs were invalid or if "status" field to "Success". If any of the IAs were invalid or if
any of the addresses were not successfully released, the server any of the addresses were not successfully released, the server
releases none of the addresses in the message and sets the "status" releases none of the addresses in the message and sets the "status"
field to "NoBinding"(section 7.4). field to "NoBinding"(section 7.4).
DISCUSSION: DISCUSSION:
What is the behavior of the server relative to a "partially What is the behavior of the server relative to a "partially
released" IA; i.e., an IA for which some but not all released" IA; i.e., an IA for which some but not all
addresses are released? addresses are released?
Can a client send an empty IA to release all addresses in Can a client send an empty IA to release all addresses in
the IA? the IA?
If the IA becomes empty - all addresses are released - can If the IA becomes empty - all addresses are released - can
the server discard any record of the IA? the server discard any record of the IA?
13.4.6. Sending of Reply messages 13.4.6. Sending of Reply messages
If the Request or Release message from the client was originally If the Request, Confirm, Renew, Rebind or Release message from
received by the server, the server unicasts the Reply message to the the client was originally received by the server, the server
link-local address in the "client-link-local-address" field. unicasts the Reply message to the link-local address in the
"client-link-local-address" field.
If the message was originally received in a Forward-request or If the message was originally received in a Forward-request or
Forward-release message from a relay, the server places the Reply Forward-release message from a relay, the server places the Reply
message in the options field of a Response-reply message and unicasts message in the options field of a Response-reply message and unicasts
the message to the relay's address from the original message. the message to the relay's address from the original message.
14. DHCP Server-Initiated Configuration Exchange 14. DHCP Server-Initiated Configuration Exchange
A server initiates a configuration exchange to force DHCP clients A server initiates a configuration exchange to force DHCP clients
to obtain new addresses and other configuration information. For to obtain new addresses and other configuration information. For
skipping to change at page 36, line 7 skipping to change at page 36, line 44
14.2. Server Behavior 14.2. Server Behavior
A server sends a Reconfigure-init message to trigger a client to A server sends a Reconfigure-init message to trigger a client to
initiate immediately a Request/Reply message exchange with the initiate immediately a Request/Reply message exchange with the
server. A server may unicast a Reconfigure-init message directly server. A server may unicast a Reconfigure-init message directly
to a single client or use multicast to deliver a Reconfigure-init to a single client or use multicast to deliver a Reconfigure-init
message to multiple clients. message to multiple clients.
14.2.1. Creation and sending of Reconfigure-init messages 14.2.1. Creation and sending of Reconfigure-init messages
The server sets the "msg-type" field to TBD. The server generates The server sets the "msg-type" field to RECONFIG. The server
a transaction-ID and inserts it in the "transaction-ID" field. generates a transaction-ID and inserts it in the "transaction-ID"
The server places its address (of appropriate scope) in the field. The server places its address (of appropriate scope) in the
"server-address" field. "server-address" field.
The server MAY include an ORO option to inform the client of what The server MAY include an ORO option to inform the client of what
information has been changed or new information that has been added. information has been changed or new information that has been added.
The server MUST include an authentication option with the appropriate The server MUST include an authentication option with the appropriate
settings and add that option as the last option in the "options" settings and add that option as the last option in the "options"
field of the Reconfigure-init message. field of the Reconfigure-init message.
The server MAY include a Reconfigure-delay option in a The server MAY include a Reconfigure-delay option in a
skipping to change at page 39, line 7 skipping to change at page 39, line 49
15. Relay Behavior 15. Relay Behavior
For this discussion, the Relay may be configured to use a list of For this discussion, the Relay may be configured to use a list of
server destination addresses, which may include unicast addresses, server destination addresses, which may include unicast addresses,
the All DHCP Servers multicast address, or other multicast addresses the All DHCP Servers multicast address, or other multicast addresses
selected by the network administrator. If the Relay has not been selected by the network administrator. If the Relay has not been
explicitly configured, it will use the All DHCP Servers multicast explicitly configured, it will use the All DHCP Servers multicast
address as the default. address as the default.
15.1. Relaying of Solicit messages 15.1. Relaying of client messages
When a Relay receives a valid Solicit message, it constructs When a Relay receives a valid client message, it constructs
a Relay-forward message. The relay places an address from a Relay-forward message. The relay places an address from
the interface on which the Solicit message was received in the the interface on which the client message was received in the
"relay-address" field and the prefix length for that address in the "relay-address" field and the prefix length for that address in the
"prefix-length" field. This address will be used by the server to "prefix-length" field. This address will be used by the server to
identify the link to which the client is connected and will be used identify the link to which the client is connected and will be used
by the relay to forward the Advertise message from the server back to by the relay to forward the Advertise message from the server back to
the client. the client.
The relay constructs a "relay-message" option 16.4 that contains The relay constructs a "client-message" option 16.4 that contains
the entire Solicit message from the client in the data field of the the entire message from the client in the data field of the
option. The relay places the "relay-message" option along with any option. The relay places the "relay-message" option along with any
"relay-specific" options in the options field of the Relay-forward "relay-specific" options in the options field of the Relay-forward
message. The Relay then sends the Relay-forward message to the list message. The Relay then sends the Relay-forward message to the list
of server destination addresses that it has been configured with. of server destination addresses that it has been configured with.
15.2. Relaying of Advertise messages 15.2. Relaying of server messages
When the relay receives a Relay-reply message, it extracts the When the relay receives a Relay-reply message, it extracts the server
Advertise message from the "server-message" option and forwards the message from the "server-message" option and forwards the message
server message to the address in the client-link-local-address field to the address in the client-link-local-address field in the server
in the Advertise message. The relay forwards the server message message. The relay forwards the server message through the interface
through the interface identified in the "relay-address" field in the identified in the "relay-address" field in the Relay-reply message.
Relay-reply message.
16. DHCP options 16. DHCP options
Options are used to carry additional information and parameters Options are used to carry additional information and parameters
in DHCP messages. Every option shares a common base format, as in DHCP messages. Every option shares a common base format, as
described in section 16.1. described in section 16.1.
this document describes the DHCP options defined as part of the base this document describes the DHCP options defined as part of the base
DHCP specification. Other options may be defined in the future in a DHCP specification. Other options may be defined in the future in a
separate document. separate document.
skipping to change at page 40, line 20 skipping to change at page 40, line 51
| option-code | option-len | | option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data | | option-data |
| (option-len octets) | | (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code An unsigned integer identifying the specific option option-code An unsigned integer identifying the specific option
type carried in this option. type carried in this option.
option-len An unsigned integer giving the length of the data in option-len An unsigned integer giving the length of the data in
this option in bytes. this option in octets.
option-data The data for the option; the format of this data option-data The data for the option; the format of this data
depends on the definition of the option. depends on the definition of the option.
16.2. Identity association option 16.2. Identity association option
The identity association option is used to carry an identity The identity association option is used to carry an identity
association, the parameters associated with the IA and the addresses association, the parameters associated with the IA and the addresses
assigned to the IA. assigned to the IA.
The format of the IA option is: The format of the IA option is:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD | option-len | | OPTION IA | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IA DUID | | IA DUID |
| (8 octets) | | (8 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 | | T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 | | T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IA status | num-addrs | addr status | prefix length | | IA status | num-addrs | addr status | prefix length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 41, line 42 skipping to change at page 41, line 53
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | preferred lifetime | | | preferred lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| pref. lifetime (cont.) | valid lifetime | | pref. lifetime (cont.) | valid lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| valid lifetime (cont.) | IPv6 address | | valid lifetime (cont.) | IPv6 address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code TBD option-code OPTION_IA (1)
option-len Variable; equal to 18 + num-addrs*25
option-len Variable; equal to 17 + num-addrs*25
IA DUID The unique identifier for this IA; chosen by the client IA DUID The unique identifier for this IA; chosen by the client
T1 The time at which the client contacts the server from T1 The time at which the client contacts the server from
which the addresses in the IA were obtained to extend which the addresses in the IA were obtained to extend
the lifetimes of the addresses assigned to the IA. the lifetimes of the addresses assigned to the IA.
T2 The time at which the client contacts any available T2 The time at which the client contacts any available
server to extend the lifetimes of the addresses assigned server to extend the lifetimes of the addresses assigned
to the IA. to the IA.
skipping to change at page 42, line 41 skipping to change at page 43, line 10
its own. When the lifetimes of all of the addresses in an IA have its own. When the lifetimes of all of the addresses in an IA have
expired, the IA can be considered as having expired. T1 and T2 expired, the IA can be considered as having expired. T1 and T2
are included to give servers explicit control over when a client are included to give servers explicit control over when a client
recontacts the server about a specific IA. recontacts the server about a specific IA.
16.3. Option request option 16.3. Option request option
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | OPTION_ORO | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| requested-option-code-1 | requested-option-code-2 | | requested-option-code-1 | requested-option-code-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code TBD. option-code OPTION_ORO (2)
option-len Variable; equal to twice the number of option codes option-len Variable; equal to twice the number of option codes
carried in this option. carried in this option.
option-data A list of the option codes for the options requested option-data A list of the option codes for the options requested
in this option. in this option.
16.4. Client message option 16.4. Client message option
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | OPTION_CLIENT_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP client message | | DHCP client message |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code TBD option-code OPTION_CLIENT_MSG (3)
option-len Variable; equal to the length of the forwarded DHCP option-len Variable; equal to the length of the forwarded DHCP
client message. client message.
option-data The message received from the client; forwarded option-data The message received from the client; forwarded
verbatim to the server. verbatim to the server.
16.5. Server message option 16.5. Server message option
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | OPTION_SERVER_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DHCP server message | | DHCP server message |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code TBD option-code OPTION_SERVER_MSG (4)
option-len Variable; equal to the length of the forwarded DHCP option-len Variable; equal to the length of the forwarded DHCP
server message. server message.
option-data The message received from the server; forwarded option-data The message received from the server; forwarded
verbatim to the client. verbatim to the client.
16.6. Retransmission parameter option 16.6. Retransmission parameter option
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | OPTION_RETRANS_PARM | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-data | | option-data |
| (option-len octets) | | (option-len octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code An unsigned integer identifying the specific option option-code OPTION_RETRANS_PARM (5)
type carried in this option.
option-len An unsigned integer giving the length of the data in option-len An unsigned integer giving the length of the data in
this option in bytes. this option in octets.
option-data The data for the option; the format of this data
depends on the definition of the option.
16.7. Authentication option
The authentication option is TBD. option-data TBD - The details of the operational parameters to be
set in the client
16.8. Reconfigure-delay option 16.7. Reconfigure-delay option
The Reconfigure-delay option specifies the amount of time a client The Reconfigure-delay option specifies the amount of time a client
should delay before sending a Request message in response to a should delay before sending a Request message in response to a
Reconfigure-init message. Reconfigure-init message.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len | | OPTION_RECONF_DELAY | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| minimum delay time (msec) | maximum delay time (msec) | | minimum delay time (msec) | maximum delay time (msec) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_RECONF_DELAY (6)
option-len An unsigned integer giving the length of the data in
this option in octets.
minimum delay time An unsigned integer giving the minimum delay
time in milliseconds
maximum delay time An unsigned integer giving the maximum delay
time in milliseconds
The client chooses a random number between the minimum delay time and The client chooses a random number between the minimum delay time and
the maximum delay time and delays that number of milliseconds before the maximum delay time and delays that number of milliseconds before
sending its Request message. sending its Request message.
16.9. DSTM Global IPv4 Address Option 16.8. DSTM Global IPv4 Address Option
The DSTM Global IPv4 Address Option informs a client or server that The DSTM Global IPv4 Address Option informs a client or server that
the Identity Association Option (IA) following this option will the Identity Association Option (IA) following this option will
contain an IPv4-Mapped IPv6 Address [?] in the case of a Client contain an IPv4-Mapped IPv6 Address [7] in the case of a Client
receiving the option, or is a Request for an IPv4-Mapped IPv6 Address receiving the option, or is a Request for an IPv4-Mapped IPv6 Address
from a client in the case of a DHCPv6 Server receiving the option. from a client in the case of a DHCPv6 Server receiving the option.
The option can also provide an IPv6 address to be used as the Tunnel The option can also provide an IPv6 address to be used as the Tunnel
Endpoint (TEP) to encapsulate an IPv4 packet within IPv6. Endpoint (TEP) to encapsulate an IPv4 packet within IPv6.
This option can be used with the Request, Reply, and Reconfigure-Init This option can be used with the Request, Reply, and Reconfigure-Init
Messages for cases where a server wants to assign to clients Messages for cases where a server wants to assign to clients
IPv4-Mapped IPv6 Addresses, thru the Option Request Option (ORO). IPv4-Mapped IPv6 Addresses, thru the Option Request Option (ORO).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length | | OPTION_DSTM | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel End Point (TEP) | | Tunnel End Point (TEP) |
| (If Present) | | (If Present) |
| (16 octets) | | (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option code OPTION_DSTM (7)
option-code: TBD option length Variable: 0 or 16
option-length: Variable: 0 or 16
Tunnel End Point: IPv6 Address if Present tunnel end point IPv6 Address if Present
A DSTM IPv4 Global Address Option MUST only apply to the IA following A DSTM IPv4 Global Address Option MUST only apply to the IA following
this option. this option.
16.9. Authentication option
The authentication option is TBD.
17. DHCP Client Implementor Notes 17. DHCP Client Implementor Notes
This section provides helpful information for the client implementor This section provides helpful information for the client implementor
regarding their implementations. The text described here is not part regarding their implementations. The text described here is not part
of the protocol, but rather a discussion of implementation features of the protocol, but rather a discussion of implementation features
we feel the implementor should consider during implementation. we feel the implementor should consider during implementation.
17.1. Primary Interface 17.1. Primary Interface
Since configuration parameters acquired through DHCP can be Since configuration parameters acquired through DHCP can be
skipping to change at page 48, line 38 skipping to change at page 49, line 29
Do servers identify an IA just by its DUID or by <prefix, DUID>? If Do servers identify an IA just by its DUID or by <prefix, DUID>? If
just by DUID, are DUIDs guaranteed unique (within the DHCP universe)? just by DUID, are DUIDs guaranteed unique (within the DHCP universe)?
If so, how is that guarantee implemented? If so, how is that guarantee implemented?
20.3. DHCP-DNS interaction 20.3. DHCP-DNS interaction
Interaction among DHCP servers, clients and DNS servers is not Interaction among DHCP servers, clients and DNS servers is not
discussed in this document. discussed in this document.
20.4. Anonymous addresses 20.4. Temporary addresses
How does DHCPv6 interact with anonymous addresses? If the server How does DHCPv6 interact with temporary addresses? If the server
assigns anonymous addresses (e.g., addresses with short lifetimes), assigns temporary addresses (e.g., addresses with short lifetimes),
how can a client application choose an anonymous address as a source how can a client application choose an temporary address as a source
address in preference to a non-anonymous address? address in preference to a non-temporary address?
20.5. Use of term "agent" 20.5. Use of term "agent"
The term "agent", taken to mean "relay agent or server", may be The term "agent", taken to mean "relay agent or server", may be
confusing. "relay agent or server" might be clearer. confusing. "relay agent or server" might be clearer.
20.6. Client behavior when response to Rebind is not received 20.6. Client behavior when response to Rebind is not received
Section 13.3.4 describes several plausible ways in which a client Section 13.3.4 describes several plausible ways in which a client
might respond when it does not receive a Reply to a Rebind message. might respond when it does not receive a Reply to a Rebind message.
skipping to change at page 49, line 28 skipping to change at page 50, line 21
Should servers have an option to set operational parameters - Should servers have an option to set operational parameters -
retransmission timeouts, number of retries - in clients? retransmission timeouts, number of retries - in clients?
21. Security 21. Security
This document references an "authentication option" which is TBD. This document references an "authentication option" which is TBD.
DISCUSSION: DISCUSSION:
Based on the discussion of security issues at the Based on the discussion of security issues at the 8/31/00
8/31/00 design team teleconference and subsequent design team teleconference and subsequent DHC WG mailing
DHC WG mailing list discussion, DHCPv6 will use list discussion, DHCPv6 will use the security model from
the security model from DHCPv4, as described in DHCPv4, as described in draft-ietf-dhc-authentication-16.txt
draft-ietf-dhc-authentication-15.txt. (which is soon to be an RFC).
22. Year 2000 considerations 22. Year 2000 considerations
Since all times are relative to the current time of the transaction, Since all times are relative to the current time of the transaction,
there is no problem within the DHCPv6 protocol related to any there is no problem within the DHCPv6 protocol related to any
hardcoded dates or two-digit representation of the current year. hardcoded dates or two-digit representation of the current year.
23. IANA Considerations 23. IANA Considerations
This document defines message types TBD to be received by UDP at port This document defines message types TBD to be received by UDP at port
skipping to change at page 51, line 23 skipping to change at page 52, line 16
o Multiple addresses per interface are inherently supported in o Multiple addresses per interface are inherently supported in
IPv6. IPv6.
o Some DHCPv4 options are unnecessary now because the configuration o Some DHCPv4 options are unnecessary now because the configuration
parameters are either obtained through IPv6 Neighbor Discovery or parameters are either obtained through IPv6 Neighbor Discovery or
the Service Location protocol [14]. the Service Location protocol [14].
DHCPv6 Architecture/Model Changes: DHCPv6 Architecture/Model Changes:
o The message type is the first byte in the packet. o The message type is the first octet in the packet.
o IPv6 Address allocations are now handled in a message option as o IPv6 Address allocations are now handled in a message option as
opposed to the message header. opposed to the message header.
o Client/Server bindings are now mandatory and take advantage of o Client/Server bindings are now mandatory and take advantage of
the client's link-local address to always permit communications the client's link-local address to always permit communications
either directly from an on-link server, or from a off-link server either directly from an on-link server, or from a off-link server
through an on-link relay. through an on-link relay.
o Servers are discovered by a client Solicit, followed by a server o Servers are discovered by a client Solicit, followed by a server
skipping to change at page 54, line 46 skipping to change at page 55, line 41
Hints about use of multicast and unicast for reliable reconfiguration Hints about use of multicast and unicast for reliable reconfiguration
have been added to server implementor's hints. have been added to server implementor's hints.
C.13. Ordering of sections C.13. Ordering of sections
Several sections have been re-ordered for clarity. Several sections have been re-ordered for clarity.
C.14. DSTM option C.14. DSTM option
The DSTM option has been added (section 16.9). The DSTM option has been added (section 16.8).
C.15. Message and option numbering
(In rev -18) Replaced TBD for message and option code numbering with
names and temporary values.
C.16. Inclusion of IAs in Solicit message by client
Added text to section 12.3.1 explaining that clients include empty
IA(s) in a Solicit message and to section 12.3.3 explaining that
server advertises addresses in client IAs.
C.17. Clarification of destination of client messages
Added text to section 13 clarifying the destination (specific server
or any available server) of client messages
C.18. Clarification of client use of Confirm messages
Changed text in section 13.3.2 to correctly describe behavior of
clients in response to Replay messages from servers.
References References
[1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor [1] S. Alexander and R. Droms. DHCP Options and BOOTP Vendor
Extensions. Request for Comments (Draft Standard) 2132, Extensions. Request for Comments (Draft Standard) 2132,
Internet Engineering Task Force, March 1997. Internet Engineering Task Force, March 1997.
[2] S. Bradner. Key words for use in RFCs to Indicate Requirement [2] S. Bradner. Key words for use in RFCs to Indicate Requirement
Levels. Request for Comments (Best Current Practice) 2119, Levels. Request for Comments (Best Current Practice) 2119,
Internet Engineering Task Force, March 1997. Internet Engineering Task Force, March 1997.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/