[dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header
Ralph Droms <rdroms@cisco.com> Tue, 28 August 2001 20:12 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20288; Tue, 28 Aug 2001 16:12:23 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24991; Tue, 28 Aug 2001 16:11:46 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id QAA24716 for <dhcwg@ns.ietf.org>; Tue, 28 Aug 2001 16:06:08 -0400 (EDT)
Received: from funnel.cisco.com (funnel.cisco.com [161.44.131.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20128 for <dhcwg@ietf.org>; Tue, 28 Aug 2001 16:04:47 -0400 (EDT)
Received: from rdroms-w2k.cisco.com (dhcp-161-44-149-90.cisco.com [161.44.149.90]) by funnel.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA10685 for <dhcwg@ietf.org>; Tue, 28 Aug 2001 16:05:36 -0400 (EDT)
Message-Id: <4.3.2.7.2.20010828160414.00b6c220@funnel.cisco.com>
X-Sender: rdroms@funnel.cisco.com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date: Tue, 28 Aug 2001 16:05:34 -0400
To: dhcwg@ietf.org
From: Ralph Droms <rdroms@cisco.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Subject: [dhcwg] Changes to remove "client-link-local-address" from the DHCPv6 header
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
I've completed the changes to remove the client-link-local-address
field from the DHCP message header. Relay agents and servers will now
use the source address from the IP header to reply to client messages.
The changes include:
* Message format and descriptions in section 8 to remove the
client-link-local-address field
* Relay agent message format and descriptions in section 9 to
accommodate the client-return-address field
* Address selection described in section 12 to allow for unicast
client messages
* The description of client behavior in sections 13 and 14
to remove the use of the client-link-local-address field and to
specify that the client must send the message through the interface
to be configure, to correctly set the source address in the IP
header
* The description of server behavior in sections 13 and 14 to remove
the use of the client-link-local-address and change the format of
the relay agent messages
* The description of relay behavior in section 15 based on the new
relay agent message format
Note that the relay agent message has to include information about:
1. The return address to which the server should send the Relay-reply
message
2. A link identifier/subnet selector that the server uses to select
configuration information for the client
3. An interface identifier and return address for the client that the
relay agent uses to forward the message from the server back to the
client
In DHCPv4, all of these functions are supplied by 'giaddr'. However,
the source address from the IP header isn't sufficient (which we had
discussed using for DHCPv6), because it may be awkward or impossible
(and, usually suboptimal) to force the message from the relay agent to
be sent to the server through the interface on which the message from
the client was received. So, I've retained the relay-address field
and added a client-return-address field in the Relay-forward for
2. and 3., and specified that the server use the source address from
the IP header for 1.
The text affected by these changes is included below. Please review
and follow up with comments.
- Ralph
=====
8. Message Formats
Each DHCP message has an identical fixed format header; some messages
also allow a variable format area for options. Not all fields in
the header are used in every message. In this section, every field
is described for every message and fields that are not used in a
message are marked as "unused". All unused fields in a message MUST
be transmitted as zeroes and ignored by the receiver of the message.
The DHCP message header:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| server-address |
| (16 octets) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. options .
. (variable) .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8.1. DHCP Solicit Message Format
msg-type SOLICIT
transaction-ID An unsigned integer generated by the client used
to identify this Solicit message.
server-address (unused) MUST be 0
options See section 18.
8.2. DHCP Advertise Message Format
msg-type ADVERTISE
transaction-ID An unsigned integer used to identify this
Advertise message. Copied from the client's
Solicit message.
server-address The IP address of the server that generated
this message. If the DHCP domain crosses
site boundaries, then this address MUST be
globally-scoped.
options See section 18.
8.3. DHCP Request Message Format
msg-type REQUEST
transaction-ID An unsigned integer generated by the client used
to identify this Request message.
server-address The IP address of the server to which the this
message is directed, copied from an Advertise
message.
options See section 18.
8.4. DHCP Confirm Message Format
msg-type CONFIRM
transaction-ID An unsigned integer generated by the client used
to identify this Confirm message.
server-address MUST be zero.
options See section 18.
8.5. DHCP Renew Message Format
msg-type RENEW
transaction-ID An unsigned integer generated by the client used
to identify this Renew message.
server-address The IP address of the server to which this Renew
message is directed, which MUST be the address
of the server from which the IAs in this message
were originally assigned.
options See section 18.
8.6. DHCP Rebind Message Format
msg-type REBIND
transaction-ID An unsigned integer generated by the client used
to identify this Rebind message.
server-address MUST be zero.
options See section 18.
8.7. DHCP Reply Message Format
msg-type REPLY
transaction-ID An unsigned integer used to identify this Reply
message. Copied from the client's Request,
Confirm, Renew or Rebind message.
server-address The IP address of the server. If the DHCP domain
crosses site boundaries, then this address MUST
be globally-scoped.
options See section 18.
8.8. DHCP Release Message Format
msg-type RELEASE
transaction-ID An unsigned integer generated by the client used
to identify this Release message.
server-address The IP address of the server that assigned the
IA.
options See section 18.
8.9. DHCP Decline Message Format
msg-type DECLINE
transaction-ID An unsigned integer generated by the client used
to identify this Decline message.
server-address The IP address of the server that assigned the
addresses.
options See section 18.
8.10. DHCP Reconfigure-init Message Format
msg-type RECONFIG-INIT
transaction-ID (unused) MUST be 0
server-address The IP address of the DHCP server issuing the
Reconfigure-init message. MUST be of sufficient
scope to be reachable by all clients.
options See section 18.
9. Relay messages
Relay agents exchange messages with servers to forward messages
between clients and servers that are not connected to the same link.
9.1. Relay-forward message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | |
+-+-+-+-+-+-+-+-+ |
| |
| relay-address |
| |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+-+-+-+-+-+-+-+-+ |
| |
| client-return-address |
| |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+-+-+-+-+-+-+-+-+ |
. .
. options (variable number and length) .... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type RELAY-FORW
prefix-length The length of the prefix in the
address in the "relay-address" field.
relay-address An address assigned to the interface
on which the message from the client
was received.
client-return-address The source address from the IP
datagram in which the message from the
client was received by the relay agent
options MUST include a "Client message
option"; see section 18.7.
9.2. Relay-reply message
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | |
+-+-+-+-+-+-+-+-+ |
| |
| relay-address |
| |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+-+-+-+-+-+-+-+-+ |
| |
| client-return-address |
| |
| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
+-+-+-+-+-+-+-+-+ |
. .
. options (variable number and length) .... .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
msg-type RELAY-REPL
prefix-length The length of the prefix in the address in the
"relay-address" field.
relay-address An address identifying the interface on the
relay agent through which the message from the
server should be forwarded; copied from the
"relay-forward" message.
client-return-address The source address from the IP
datagram in which the message from the
client was received by the relay agent
options MUST include a "Server message option"; see
section 18.8.
12. Selecting addresses for assignment to an IA
A server selects addresses to be assigned to an IA according to the
address assignment policies determined by the server administrator
and the specific information the server determines about the client
from the following sources:
- The link to which the client is attached:
* If the server receives the message directly from the client
and the source address in the IP datagram in which the
message was received is a link-local address, then the client
is on the same link to which the interface over which the
message was received is attached
* If the server receives the message directly from the client
and the source address in the IP datagram in which the
message was received is not link-local address, then the
client is on the link identified by the source address in the
IP datagram
* If the server receives the message from a forwarding relay
agent, then the client is on the same link as the one to
which the interface identified by the relay-address field in
the message from the relay is attached
- The DUID supplied by the client
- Other information in options supplied by the client
- Other information in options supplied by the relay agent
13. DHCP Server Solicitation
This section describes how a client locates servers. The behavior
of client and server implementations is discussed, along with the
messages they use.
13.1. Solicit Message Validation
Clients MUST silently discard any received Solicit messages.
13.2. Advertise Message Validation
Servers MUST discard any received Advertise messages.
Clients MUST discard any received Advertise messages in which the
"Transaction-ID" field value does not match the value the client used
in its Solicit message.
13.3. Client Behavior
A client uses the Solicit message to discover DHCP servers configured
to serve addresses on the link to which the client is attached.
13.3.1. Creation and sending of the Solicit message
The client sets the "msg-type" field to SOLICIT. The client generates
a transaction ID and inserts this value in the "transaction-ID"
field.
The client includes a DUID option to identify itself to the server.
The client MUST include options for any IAs to which it wants the
server to assign addresses. The client may include addresses in the
IAs as a hint to the server about addresses for which the client
may have a preference. 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
multicast address, destination port 547. The source port selection
can be arbitrary, although it SHOULD be possible using a client
configuration facility to set a specific source port value.
13.4. Server Behavior
A server sends an Advertise message in response to Solicit messages
it receives to announce the availability of the server to the client.
13.4.1. Receipt of Solicit messages
The server determines the information about the client and its
location as described in section 12. If administrative policy
permits the server to respond to the client, the server will generate
and send an Advertise message to the client.
13.4.2. Creation and sending of Advertise messages
The server sets the "msg-type" field to ADVERTISE and copies the
values of the transaction-ID field from the client's Solicit to the
Advertise message.
The server places one of its IP addresses (determined through
administrator setting) in the "server-address" field of the Advertise
message. The server MAY add a Preference option to carry the
preference value for the Advertise message.
The server implementation SHOULD allow the setting of a server
preference value by the administrator. The server preference value
MUST default to zero unless otherwise configured by the server
administrator.
The server MUST include options to the Advertise message containing
any addresses that would be assigned to IAs contained in the Solicit
message from the client. If the server will not assign any addresses
to IAs in a subsequent Request from the client, the server MAY choose
to send an Advertise message to the client that includes no IA
options. The server MAY include other options the server will return
to the client in a subsequent Reply message. The information in
these options will be used by the client in the selection of a server
if the client receives more than one Advertise message. The server
SHOULD include options specifying values for options requested by the
client in an Option Request Option included in the Solicit message.
If the Solicit message was received directly by the server, the
server unicasts the Advertise message directly to the client using
the address in the source address field from the IP datagram in
which the Solicit message was received. The Advertise message MUST
be unicast through the interface on which the Solicit message was
received.
If the Solicit message was received in a Relay-forward message,
the server constructs a Relay-reply message with the Advertise
message in the payload of a "server-message" option. The server
unicasts the Relay-reply message directly to the relay agent using
the address in the source address field from the IP datagram in which
the Relay-forward message was received.
14. DHCP Client-Initiated Configuration Exchange
A client initiates a message exchange with a server or servers to
acquire or update configuration information of interest. The client
may initiate the configuration exchange as part of the operating
system configuration process or when requested to do so by the
application layer.
The client uses the following messages to initiate a configuration
event:
Request Obtain initial configuration information (from a server
identified in a previously received Advertise message)
when the client has no assigned addresses
Confirm Confirm the validity of assigned addresses and other
configuration changes through the server from which the
configuration information was obtained when the client's
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
originally assigned the IA
Rebind Extend the lease on an IA through any server willing to
extend the lease
Release Release the lease on an IA and release all of the
addresses contained in the IA,
Decline Decline the assignment of one or more addresses in an
IA.
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
the released IA.
A client uses the Decline/Reply message exchange to indicate to the
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.
14.1. Client Message Validation
Clients MUST silently discard any received client messages (Request,
Confirm, Renew, Rebind, Release or Decline messages).
Servers MUST discard any received client messages in which the
"options" field contains an authentication option, and the server
cannot successfully authenticate the client.
Servers MUST discard any received Request, Renew, Release or Decline
message in which the "server-address" field value does not match any
of the server's addresses.
14.2. Server Message Validation
Servers MUST silently discard any received server messages
(Advertise, Reply or Reconfigure-init messages).
Clients MUST discard any server messages that meet any of the
following criteria:
o The "transaction-ID" field value in the server message does
not match the value the client used in its Request or Release
message.
o The server message contains an authentication option, and the
client's attempt to authenticate the message fails.
Relays MUST discard any Relay-reply message in which the
"client-link-local-address" field in the Relay-reply message does not
contain a valid link-local address.
14.3. Client Behavior
A client will use Request, Confirm, Renew and Rebind messages to
acquire and confirm the validity of configuration information. A
client may initiate such an exchange automatically in order to
acquire the necessary network parameters to communicate with nodes
off-link. The client uses the server address information from
previous Advertise message(s) for use in constructing Request and
Renew message(s). Note that a client may request configuration
information from one or more servers at any time.
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
expiration time since it is no longer needed.
A client uses the Decline message when the client has determined
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
client.
14.3.1. Creation and sending of Request messages
If a client has no valid IPv6 addresses of sufficient scope 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
Request message, to which the server assigns new addresses. The
server then returns IA(s) to the client in a Reply message.
The client generates a transaction ID and inserts this value in the
"transaction-ID" field.
The client places the address of the destination server in the
"server-address" field.
The client adds a DUID option to identify itself to the server. The
client adds any other appropriate options, including one or more IA
options (if the client is requesting that the server assign it some
network addresses). The list of addresses in each included IA MUST
be empty. If the client is not requesting that the server assign it
any addresses, the client omits the IA option.
The client sends the Request message to the All DHCP Agents multicast
address through the interface for which the client is interested in
obtaining configuration information, with the destination port set
to 547. The source port selection can be arbitrary, although it
SHOULD be possible using a client configuration facility to set a
specific source port value.
The server will respond to the Request message with a Reply
message. If no Reply message is received within REP_MSG_TIMEOUT
milliseconds, the client retransmits the Request with the same
transaction-ID, and doubles the REP_MSG_TIMEOUT value, and waits
again. The client continues this process until a Reply is received
or REQUEST_MSG_ATTEMPTS unsuccessful attempts have been made, at
which time the client MUST abort the configuration attempt. The
client SHOULD report the abort status to the application layer.
Default and initial values for REP_MSG_TIMEOUT and REQ_MSG_ATTEMPTS
are documented in section 7.5.
14.3.2. Creation and sending of Confirm messages
Whenever a client may have moved to a new link, its IPv6 addresses
may no longer be valid. Examples of times when a client may have
moved to a new link include:
o The client reboots
o The client is physically disconnected from a wired connection
o The client returns from sleep mode
o The client using a wireless technology changes cells
In any situation when a client may have moved to a new link, the
client MUST initiate a Confirm/Reply message exchange. The client
includes any IAs, along with the addresses associated with those IAs,
in its Confirm message. Any responding servers will indicate the
acceptability of the addresses with the status in the IA it returns
to the client.
The client sets the "msg-type" field to CONFIRM. The client generates
a transaction ID and inserts this value in the "transaction-ID"
field.
The client sets the "server-address" field to 0.
The client adds a DUID option to identify itself to the server. The
client adds any appropriate options, including one or more IA options
(if the client is requesting that the server confirm the validity of
some network addresses). If the client does include any IA options,
it MUST include the list of addresses the client currently has
associated with that IA.
The client sends the Confirm message to the All DHCP Agents multicast
address through the interface for which the client is interested in
obtaining configuration information, with the destination port set
to 547. The source port selection can be arbitrary, although it
SHOULD be possible using a client configuration facility to set a
specific source port value.
Servers will respond to the Confirm message with a Reply message. If
no Confirm message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Confirm with the same transaction-ID,
and doubles the REP_MSG_TIMEOUT value, and waits again. The client
continues this process until a Reply is received or QRY_MSG_ATTEMPTS
unsuccessful attempts have been made, at which time the client MUST
abort the configuration attempt. The client SHOULD report the abort
status to the application layer.
Default and initial values for REP_MSG_TIMEOUT and QRY_MSG_ATTEMPTS
are documented in section 7.5.
If the client receives no response to its Confirm message, it MAY
restart the configuration process by locating a DHCP server with an
Advertise message and sending a Request to that server, as described
in section 14.3.1.
14.3.3. Creation and sending of Renew messages
IPv6 addresses assigned to a client through an IA use the same
preferred and valid lifetimes as IPv6 addresses obtained through
stateless autoconfiguration. The server assigns preferred and valid
lifetimes to the IPv6 addresses it assigns to an IA. To extend those
lifetimes, the client sends a Request to the server containing an
"IA option" for the IA and its associated addresses. The server
determines new lifetimes for the addresses in the IA according to
the server's administrative configuration. The server may also add
new addresses to the IA. The server remove addresses from the IA by
setting the preferred and valid lifetimes of those addresses to zero.
The server controls the time at which the client contacts the server
to extend the lifetimes on assigned addresses through the T1 and
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
shortest preferred lifetime of any address assigned to the IA and
T2 defaults to 0.875 times the shortest preferred lifetime of any
address assigned to the IA.
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
client includes an IA option with all addresses currently assigned to
the IA in its Request message.
The client sets the "msg-type" field to RENEW. The client generates a
transaction ID and inserts this value in the "transaction-ID" field.
The client places the address of the destination server in the
"server-address" field.
The client adds a DUID option to identify itself to the server. The
client adds any appropriate options, including one or more IA options
(if the client is requesting that the server extend the lease on some
IAs; note that the client may check the status of other configuration
parameters without asking for lease extensions). If the client does
include any IA options, it MUST include the list of addresses the
client currently has associated with that IA.
The client sends the Renew message to the All DHCP Agents multicast
address through the interface for which the client is interested in
obtaining configuration information, with the destination port set
to 547. The source port selection can be arbitrary, although it
SHOULD be possible using a client configuration facility to set a
specific source port value.
The server will respond to the Renew message with a Reply message.
If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Renew with the same transaction-ID, and
doubles the REP_MSG_TIMEOUT value, and waits again. The client
continues this process until a Reply is received or until time T2 is
reached (see section 14.3.4).
Default and initial values for REP_MSG_TIMEOUT are documented in
section 7.5.
14.3.4. Creation and sending of Rebind messages
At time T2 for an IA (which will only be reached if the server to
which the Renew message was sent at time T1 has not responded),
the client initiates a Rebind/Reply message exchange. The client
includes an IA option with all addresses currently assigned to the IA
in its Rebind message. The client sends this message to the All DHCP
Agents multicast address.
The client sets the "msg-type" field to REBIND. The client generates
a transaction ID inserts this value in the "transaction-ID" field.
The client sets the "server-address" field to 0.
The client adds a DUID option to identify itself to the server.
The client adds any appropriate options, including one or more IA
options. If the client does include any IA options (if the client is
requesting that the server extend the lease on some IAs; note that
the client may check the status of other configuration parameters
without asking for lease extensions), it MUST include the list of
addresses the client currently has associated with that IA.
The client sends the Rebind message to the All DHCP Agents multicast
address through the interface for which the client is interested in
obtaining configuration information, with the destination port set
to 547. The source port selection can be arbitrary, although it
SHOULD be possible using a client configuration facility to set a
specific source port value.
The server will respond to the Rebind message with a Reply message.
If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Rebind with the same transaction-ID, and
doubles the REP_MSG_TIMEOUT value, and waits again. The client
continues this process until a Reply is received.
Default and initial values for REP_MSG_TIMEOUT are documented in
section 7.5.
The client has several alternatives to choose from if it receives no
response to its Rebind message.
- When the lease on the IA expires, the client may choose to use a
Solicit message to locate a new DHCP server and send a Request
for the expired IA to the new server
- Some addresses in the IA may have lifetimes that extend beyond
the lease of the IA, so the client may choose to continue to use
those addresses; once all of the addresses have expired, the
client may choose to locate a new DHCP server
- The client may have other addresses in other IAs, so the client
may choose to discard the expired IA and use the addresses in the
other IAs
14.3.5 (omitted)
14.3.6. Creation and sending of Release messages
The client sets the "msg-type" field to RELEASE. The client generates
a transaction ID and places this value in the "transaction-ID" field.
The client places the IP address of the server that allocated the
address(es) in the "server-address" field.
The client adds a DUID option to identify itself to the server. The
client includes options containing the IAs it is releasing in the
"options" field. The addresses to be released MUST be included in
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
generates the appropriate authentication option, and adds this option
to the "options" field. Note that the authentication option MUST be
the last option in the "options" field. See section 18.11 for more
details about the authentication option.
The client sends the Release message to the All DHCP Agents multicast
address through the interface for which the client is interested in
obtaining configuration information, with the destination port set
to 547. The source port selection can be arbitrary, although it
SHOULD be possible using a client configuration facility to set a
specific source port value.
14.3.7. (Omitted)
14.3.8. (Omitted)
14.3.9. Creation and sending of Decline messages
The client sets the "msg-type" field to DECLINE. The client generates
a transaction ID and places this value in the "transaction-ID" field.
The client places the IP address of the server that allocated the
address(es) in the "server-address" field.
The client adds a DUID option to identify itself to the server. The
client includes options containing the IAs it is declining in the
"options" field. The addresses to be released MUST be included in
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
generates the appropriate authentication option, and adds this option
to the "options" field. Note that the authentication option MUST be
the last option in the "options" field. See section 18.11 for more
details about the authentication option.
The client sends the Decline message to the All DHCP Agents multicast
address through the interface for which the client is interested in
obtaining configuration information, with the destination port set
to 547. The source port selection can be arbitrary, although it
SHOULD be possible using a client configuration facility to set a
specific source port value.
14.3.10. (Omitted)
If no Reply message is received within REP_MSG_TIMEOUT milliseconds,
the client retransmits the Decline, doubles the REP_MSG_TIMEOUT
value, and waits again. The client continues this process until a
Reply is received or REL_MSG_ATTEMPTS unsuccessful attempts have
been made, at which time the client SHOULD abort the attempt to
decline the address. The client SHOULD return the abort status to
the application, if an application initiated the release.
Default and initial values for REP_MSG_TIMEOUT and REL_MSG_ATTEMPTS
are documented in section 7.5.
14.3.11. Receipt of Reply message in response to a Release message
Upon receipt of a valid Reply message, the client can consider the
Release event successful, and SHOULD return the successful status to
the application layer, if an application initiated the release.
14.4. Server Behavior
For this discussion, the Server is assumed to have been configured in
an implementation specific manner with configuration of interest to
clients.
14.4.1. Receipt of Request messages
Upon the receipt of a valid Request message from a client the server
can respond to, (implementation-specific administrative policy
satisfied) the server scans the options field.
The server then constructs a Reply message and sends it to the
client.
The server SHOULD process each option for the client in an
implementation-specific manner. The server MUST construct a Reply
message containing the following values:
msg-type REPLY
transaction-ID The transaction-ID from the Request message.
server address One of the IP addresses assigned to the interface
through which the server received the message
from the client.
When the server receives a Request and IA option is included the
client is requesting the configuration of a new IA by the server.
The server MUST take the clients IA and associate a binding for that
client in an implementation-specific manner within the server's
configuration parameter database for DHCP clients.
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.
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,
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.
14.4.2. Receipt of Confirm messages
Upon the receipt of a valid Confirm message from a client the server
can respond to, (implementation-specific administrative policy
satisfied) the server scans the options field.
The server then constructs a Reply message and sends it to the
client.
The server SHOULD process each option for the client in an
implementation-specific manner. The server MUST construct a Reply
message containing the following values:
msg-type REPLY
transaction-ID The transaction-ID from the Confirm message.
server address One of the IP addresses assigned to the interface
through which the server received the message
from the client.
When the server receives a Confirm and an IA option is included the
client is requesting confirmation that the addresses in the IA are
valid. The server SHOULD locate the clients binding and verify the
information in the IA from the client matches the information stored
for that client.
If the server cannot find a client entry for this IA the server
SHOULD return an empty IA with status set to NoBinding.
If the server finds that the information for the client does not
match what is in the server's records for that client the server
should send back an empty IA with status set to Conf_NoMatch.
If the server finds a match to the Confirm then the server should
send back the IA to the client with status set to success.
14.4.3. Receipt of Renew messages
Upon the receipt of a valid Renew message from a client the server
can respond to, (implementation-specific administrative policy
satisfied) the server scans the options field.
The server then constructs a Reply message and sends it to the
client.
The server SHOULD process each option for the client in an
implementation-specific manner. The server MUST construct a Reply
message containing the following values:
msg-type REPLY
transaction-ID The transaction-ID from the Confirm message.
server address One of the IP addresses assigned to the interface
through which the server received the message
from the client.
When the server receives a Renew and IA option from a client it
SHOULD locate the clients binding and verify the information in the
IA from the client matches the information stored for that client.
If the server cannot find a client entry for this IA the server
SHOULD return an empty IA with status set to NoBinding.
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
with status set to Renw_NoMatch.
If the server cannot Renew addresses for the client it SHOULD send
back an empty IA to the client with the status field set to Unavail.
If the server finds the addresses in the IA for the client then the
server SHOULD send back the IA to the client with new lease times
and T1/T2 times if the default is not being used, and set status to
Success.
14.4.4. Receipt of Rebind messages
Upon the receipt of a valid Rebind message from a client the server
can respond to, (implementation-specific administrative policy
satisfied) the server scans the options field.
The server then constructs a Reply message and sends it to the
client.
The server SHOULD process each option for the client in an
implementation-specific manner. The server MUST construct a Reply
message containing the following values:
msg-type REPLY
transaction-ID The transaction-ID from the Confirm message.
server address One of the IP addresses assigned to the interface
through which the server received the message
from the client.
When the server receives a Rebind and IA option from a client it
SHOULD locate the clients binding and verify the information in the
IA from the client matches the information stored for that client.
If the server cannot find a client entry for this IA the server
SHOULD return an empty IA with status set to NoBinding.
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
with status set to Rebd_NoMatch.
If the server cannot Rebind addresses for the client it SHOULD send
back an empty IA to the client with the status field set to Unavail.
If the server finds the addresses in the IA for the client then the
server SHOULD send back the IA to the client with new lease times
and T1/T2 times if the default is not being used, and set status to
Success.
There is a significant difference between Renew and Rebind messages:
Because the Rebind message is processed by a single server, the
responding server can actually change the addresses in the IA.
However, because multiple servers may respond to a Rebind, all they
can safely do is update T1, T2 (for the IA) and lifetimes (for
individual addresses).
14.4.5. Receipt of Release messages
Upon the receipt of a valid Release message, the server examines the
IAs and the addresses in the IAs for validity. If the IAs in the
message are in a binding for the client and the addresses in the IAs
have been assigned by the server to those IA, the server deletes
the addresses from the IAs and makes the addresses available for
assignment to other clients.
The server then generates a Reply message. If all of the IAs were
valid and the addresses successfully released,, the server sets the
"status" field to "Success". If any of the IAs were invalid or if
any of the addresses were not successfully released, the server
releases none of the addresses in the message and sets the "status"
field to "NoBinding"(section 7.4).
If the client successfully releases some but not all of the addresses
in an IA, the IA continues to exist and holds the remaining,
unreleased addresses.
A client can send an option containing an IA with no listed addresses
to release implicitly all of the addresses in the IA.
A server is not required to (but may choose to as an implementation
strategy) retain any record of an IA from which all of the addresses
have been released.
14.4.6. Sending of Reply messages
If the Request, Confirm, Renew, Rebind or Release message from
the client was originally received was originally received in a
Relay-forward message from a relay, the server places the Reply
message in the options field of a Relay-response message and copies
the relay-address and client-link-local-address fields from the
Relay-forward message into the Relay-response message.
The server then unicasts the Reply or Relay-reply to the source
address from the IP datagram in which the original message was
received.
16. Relay Behavior
For this discussion, the Relay may be configured to use a list of
server destination addresses, which may include unicast addresses,
the All DHCP Servers multicast address, or other multicast addresses
selected by the network administrator. If the Relay has not been
explicitly configured, it MUST use the All DHCP Servers multicast
address as the default.
16.1. Relaying of client messages
When a Relay receives a valid client message, it constructs
a Relay-forward message. The relay places an address from
the interface on which the client message was received in the
"relay-address" field. This address will be used by the server to
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
the client.
The relay copies the source address from the IP datagram
in which the message was received from the client into the
client-link-local-address field in the Relay-forward message.
The relay constructs a "client-message" option 18.7 that contains
the entire message from the client in the data field of the
option. The relay places the "relay-message" option along with any
"relay-specific" options in the options field of the Relay-forward
message. The Relay then sends the Relay-forward message to the list
of server destination addresses that it has been configured with.
16.2. Relaying of server messages
When the relay receives a Relay-reply message, it extracts the server
message from the "server-message" option and forwards the message to
the address in the client-link-local-address field in the Relay-reply
message. The relay forwards the server message through the interface
identified in the "relay-address" field in the Relay-reply message.
_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
http://www1.ietf.org/mailman/listinfo/dhcwg
- [Dhcwg] Re: Change to 'seconds' field in DHCP mes… Ralph Droms
- RE: [Dhcwg] Re: Change to 'seconds' field in DHCP… Bernie Volz (EUD)
- [dhcwg] RE: Change to 'seconds' field in DHCP mes… Ralph Droms
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ted Lemon
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ralph Droms
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ted Lemon
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ted Lemon
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ralph Droms
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ralph Droms
- Re: [Dhcwg] Re: Change to 'seconds' field in DHCP… Ted Lemon
- [dhcwg] Changes to remove "client-link-local-addr… Ralph Droms
- Re: [dhcwg] Changes to remove "client-link-local-… Ted Lemon
- Re: [dhcwg] Changes to remove "client-link-local-… Ralph Droms
- Re: [dhcwg] Changes to remove "client-link-local-… Ted Lemon
- Re: Re[2]: [dhcwg] Lease database storage in DHCP… Thomas Narten
- Re: [dhcwg] Assigning DHCPv6 option codes Thomas Narten
- Re: [dhcwg] dhcpv6-24: randomization delay before… Thomas Narten
- Re: [dhcwg] dhcpv6-24: randomization delay before… Thomas Narten
- Re: [dhcwg] dhcpv6-24: movement detection and Con… Thomas Narten
- Re: [dhcwg] dhcpv6-24: use of anycast Thomas Narten
- Re: [dhcwg] dhcpv6-24: use of anycast Thomas Narten
- Re: [dhcwg] dhcpv6-24: vendor-specific issues Thomas Narten
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Thomas Narten
- Re: [dhcwg] status of draft-ietf-dhc-agent-subnet… Thomas Narten
- Re: [dhcwg] DHC WG charter Thomas Narten
- Re: [dhcwg] DHC WG charter Thomas Narten
- RE: [dhcwg] DHC WG charter Ralph Droms
- Re: [dhcwg] DHC WG charter Thomas Narten
- Re: [dhcwg] DHC WG charter Ralph Droms
- Re: [dhcwg] Agenda items for IETF-59, Seoul Naiming Shen
- Re: [dhcwg] *DRAFT* minutes from WG meeting in Se… Naiming Shen
- Re: [dhcwg] dhc wg last call on "DHCP Relay Agent… Thomas Narten