WDIFF

draft-ietf-dhc-dhcpv6-03.txt --> draft-ietf-dhc-dhcpv6-04.txt

INTERNET-DRAFT

Internet Engineering Task Force J. Bound
INTERNET DRAFT Digital Equipment Corp.
DHC Working Group Digital Equipment Corp C. Perkins
Obsoletes: draft-ietf-dhc-dhcpv6-02.txt November 1995 draft-ietf-dhc-dhcpv6-03.txt IBM Research
12 February 1996

Dynamic Host Configuration Protocol for IPv6 (DHCPv6)

draft-ietf-dhc-dhcpv6-03.txt
draft-ietf-dhc-dhcpv6-04.txt

Status of this This Memo

This document is a submission to the DHC Working Group of the
Internet Engineering Task Force (IETF). Comments should be submitted
to the dhcp-v6@bucknell.edu mailing list.

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at
any time. It is inappropriate to use Internet- Internet Drafts as reference
material or to cite them other than as ``work in progress.''

To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet- Drafts
Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
ftp.isi.edu (US West Coast).

Distribution of this document is unlimited.

Abstract

This document is an Internet application protocol, for IP version 6
(IPv6), that specifies

The Dynamic Host Configuration Protocol (DHCP) provides a client/server model framework
for communications
between hosts passing configuration information, via options, to dynamically configure parameters for a network, and
autoconfigure IPv6 hosts.
It offers the capability of automatic allocation of reusable network
addresses within and additional configuration options. This protocol should
be considered a stateful model. This document
supports counterpart to the model for IPv6 Stateless Address Autoconfiguration,
where there are clear integration points between stateless and
stateful address autoconfiguration for IPv6.
Autoconfiguration protocol specification.

Bound, Perkins Expires May 12 August 1996 [Page 1]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

Table i]

Internet Draft DHCP Version 6 12 February 1996

Contents

Status of Contents: This Memo i

Abstract i

1. Introduction.................................................3 Introduction 1
1.1. Requirements...............................................3 Specification Language . . . . . . . . . . . . . . . . . 1

2. Terminology and Definitions..................................4 Definitions 2
2.1. IPv6 Terminology...........................................4 Terminology . . . . . . . . . . . . . . . . . . . . 2
2.2. DHCPv6 Terminology.........................................6 Terminology . . . . . . . . . . . . . . . . . . . 4

3. Protocol Design Model........................................9 Model 5
3.1. Design Goals...............................................9 Goals . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Request/Response Model....................................10 DHCPv6 Messages . . . . . . . . . . . . . . . . . . . . . 6
3.3. Leased Address Model......................................11
3.3.1. Address Lifetimes.......................................11
3.3.2. Duplicate Address Detection.............................12
3.3.3. Releasing Infinite Lifetime Addresses...................13
3.4. DNS Host Name Autoregistration Model......................13
4. Request/Response Processing.................................13
4.1. Processing when Server Address is not Known...............14 Model . . . . . . . . . . . . 7

4. DHCPv6 Message Formats and Field Definitions 8
4.1. UDP Ports used for DHCPv6 messages . . . . . . . . . . . 8
4.2. Processing when Server Address is Known...................16 DHCP Solicit Message Format . . . . . . . . . . . . . . . 8
4.3. Retransmission and Configuation Variables.................16 DHCP Advertise Message Format . . . . . . . . . . . . . . 9
4.4. DHCP Request Message Format . . . . . . . . . . . . . . . 10
4.5. DHCP Reply Message Format . . . . . . . . . . . . . . . . 12
4.6. DHCP Release Message Format . . . . . . . . . . . . . . . 13
4.7. DHCP Reconfigure Message Format . . . . . . . . . . . . . 14

5. Datagram and Field Definitions..............................18 DHCP Client Considerations 15
5.1. Datagram..................................................18 DHCP Solicit Message Processing . . . . . . . . . . . . . 15
5.2. Field Definitions.........................................19
6. Client/Server DHCP Advertise Message Processing . . . . . . . . . . . . 15
5.3. DHCP Request Message Processing . . . . . . . . . . . . . 16
5.4. DHCP Reply Message Formats...............................21 Processing . . . . . . . . . . . . . . 17
5.5. DHCP Release Message Processing . . . . . . . . . . . . . 18
5.6. DHCP Reconfigure Message Processing . . . . . . . . . . . 18

6. DHCP Server Considerations 19
6.1. Client/Server UDP Ports, Multicast Group, DHCP Solicit and Addresses...21 Advertise Message Processing . . . . . . 19
6.2. Client DISCOVER DHCP Request and CONF-REQUEST Messages.................21 Reply Message Processing . . . . . . . . 19
6.3. Server CONF-RESPONSE Message..............................23 DHCP Release Message Processing . . . . . . . . . . . . . 20
6.4. Client ACCEPT Message.....................................24
6.5. Server SERVER-ACK Message.................................25
6.6. Client RELEASE Message....................................27 DHCP Reconfigure Message Processing . . . . . . . . . . . 21

7. Relay-Agent Processing......................................28
8. Security Considerations.....................................29
Appendix A - Related Work in IPv6..............................29
Change History.................................................31
Acknowledgements...............................................33
References.....................................................33
Authors' Address...............................................34 DHCP Relay Considerations 22
7.1. DHCP Solicit and DHCP Advertise Message Processing . . . 22
7.2. DHCP Request Message Processing . . . . . . . . . . . . . 23

Bound, Perkins Expires May 12 August 1996 [Page 2]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

1. Introduction

DHCPv6 is an ii]

Internet application protocol, for IP version Draft DHCP Version 6 (IPv6),
that specifies 12 February 1996

7.3. DHCP Reply Message Processing . . . . . . . . . . . . . . 23
7.4. Retransmission and Configuation Variables . . . . . . . . 23

8. Security Considerations 25

9. Acknowledgements 25

A. Related Work in IPv6 26

B. Change History 27
B.1. Changes from November 95 to February 96 Drafts . . . . . 27

Chair's Address 29

Author's Address 29

Bound, Perkins Expires 12 August 1996 [Page iii]

Internet Draft DHCP Version 6 12 February 1996

1. Introduction

The Dynamic Host Configuration Protocol (DHCP) provides configuration
parameters to Internet hosts. DHCP consists of a client/server model protocol for communications between
delivering host-specific configuration parameters from a DHCP server
to a host, and a mechanism for allocation of network addresses and
other related parameters to IPv6 hosts.

DHCP is built on a client-server model, where designated DHCP
server hosts allocate network addresses and automatically deliver
configuration parameters to dynamically configure parameters for configured hosts. Throughout
the remainder of this document, the term "server" refers to a network, host
providing initialization parameters through DHCP, and autoconfigure
addresses within the term
"client" refers to a stateful model. host requesting initialization parameters from
a DHCP server. DHCPv6 supports the model servers maintain state for their clients,
in contrast to IPv6 Stateless Address Autoconfiguration [IPv6-ADDRCONF], [9],
where there
are clear integration points between stateless and stateful address IPv6 hosts should get the same results if they repeat the
autoconfiguration for IPv6. procedure multiple times.

DHCPv6 uses a set of request/response Request and Reply messages to support a
transaction client/server
processing model where a commit to the data can be
verified by whereby both the client and server. This affords DHCPv6 the
ability in the future to support dynamic updates to data located
within a sites network. In addition to the capability of verifying
commits to transactions a recovery mechanism is specified, should
commits need to be rolled back during server are assured that
requested configuration parameters have been received and accepted by
the course of a DHCPv6
transaction being processed. client. DHCPv6 supports optional configuration parameters and
processing for hosts through its companion document Options Extensions for
the Dynamic Host Configuration Protocol for IPv6 [DHCPv6-OPT]. [5].

The IPv6 Addressing Architecture [IPv6-ADDR] [3] and IPv6 Stateless Address
Autoconfiguration specifications provide new functionality features not present available
in IP version 4 (IPv4). This new IPv6 functionality
provides inherent benefits (IPv4) [8], which are used to autoconfigure IPv6 addresses for nodes.
In addition simplify and generalize
the IETF DNS Working Group has defined a method to
support Dynamic Updates to DNS [DYN-UPD], which can be used by a node
to add, delete, and change node names dynamically.

DHCPv6 used several of the architecture principles from DHCPv4
[DHCP-v4], but it is beyond the scope operation of this document to contrast
and compare DHCPv6 with DHCPv4. clients.

Section 2 provides definitions for terminology used throughout this
document. Section 3 provides a review overview of the protocol design model
parts
that are inherent in guides the specification. Section 4 provides design choices in the
request/response model and interaction between specification; section 3.2
briefly describes the set of protocol messages and the semantics for those messages. Section 5 provides the
datagram packet format and field definitions for that datagram. their semantics.
Section 6 4 provides the message formats and field contents definitions used for
processing the client
each message. Sections 5, 6, and server messages. Section 7 provides the
specification of specify how relay-agents and servers interact with clients,
when the server is not on the same link as the client. Section 8
provides the security specifications that can be used to support
security in DHCPv6. servers,
and relays interact. Appendix A provides a summary of summarizes related work in IPv6 that
will help put DHCPv6 in the context of IPv6 for the reader,
and provide helpful context; it is not part of this specification,
but here included for information informational purposes.

1.1. Requirements

Throughout Specification Language

In this document, the several words that are used to define signify the
significance requirements
of the particular requirements are capitalized. specification. These words are: are often capitalized.

Bound, Perkins Expires May 12 August 1996 [Page 3]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

o "MUST" 1]

Internet Draft DHCP Version 6 12 February 1996

MUST This word word, or the adjective "REQUIRED" "required", means
that the item definition is an absolute requirement
of this the specification.

o "MUST NOT"

MUST NOT This phrase means that the item definition is an
absolute prohibition of this the specification.

o "SHOULD"

SHOULD This word word, or the adjective "RECOMMENDED" "recommended",
means that there may exist valid reasons in
particular circumstances to ignore this item,
but the full implications should must be understood
and the case carefully weighed before choosing a
different course.

o "SHOULD NOT"

This phrase means that there Unexpected results may exist valid reasons in particular
circumstances when the listed behavior is acceptable or even
useful, but the full implications should be understood and the
case carefully weighted before implementing any behavior described
with this label.

o "MAY"
result otherwise.

MAY This word word, or the adjective "OPTIONAL" "optional", means
that this item is
truly optional. One vendor may choose one of an allowed set of
alternatives. An implementation which does
not include this option MUST be prepared to
interoperate with another implementation which
does include the item because
a particular marketplace requires it or because it enhances the
product, for example, another vendor may omit option.

silently discard The implementation discards the same item. datagram
without further processing, and without
indicating an error to the sender. The
implementation SHOULD provide the capability of
logging the error, including the contents of
the discarded datagram, and SHOULD record the
event in a statistics counter.

2. Terminology and Definitions

Relevant terminology from the IPv6 Protocol [IPv6-SPEC], [2], IPv6 Addressing
Architecture, and IPv6 Stateless Address Autoconfiguration will be
provided, and then the DHCPv6 terminology.

2.1. IPv6 Terminology

IP -

Internet Protocol Version 6 (IPv6). The terms IPv4 and IPv6
are used only in contexts where necessary to avoid ambiguity.

node -

A device that implements IPv6.

Bound, Perkins Expires 12 August 1996 [Page 2]

Internet Draft DHCP Version 6 12 February 1996

router -

A node that forwards IPv6 packets datagrams not explicitly addressed to
itself.

host -

Any node that is not a router.

upper-layer - A protocol layer immediately above IP. Examples are
transport protocols such as TCP and UDP, control
protocols such as ICMP, routing protocols such as
OSPF, and internet or lower-layer protocols being

Expires May 1996 [Page 4]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

"tunneled" over (e.g. encapsulated in) IP such as
IPX, Appletalk, or IP itself.

link -

A communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer immediately
below IPv6. Examples are Ethernet (simple or bridged); PPP
links, X.25, Frame Relay, or ATM networks; and internet (or
higher) layer "tunnels", such as tunnels over IPv4 or IPv6
itself.

link-layer identifier

a link-layer identifier for an interface. Examples include
IEEE 802 addresses for Ethernet links, and E.164 addresses for
ISDN links.

link-local address

An address having link-only scope that can be used to reach
neighboring nodes attached to the same link. All interfaces
have a link-local address.

neighbors -

Nodes attached to the same link.

interface -

A node's attachment to the link.

address -

An IP layer identifier for an interface or a set of interfaces.

packet -

message

The data exchanged between DHCP agents and clients; in this
specification, messages are delivered via IPv6 and UDP.

Bound, Perkins Expires 12 August 1996 [Page 3]

Internet Draft DHCP Version 6 12 February 1996

datagram

An IP header plus payload.

communication
- Any packet exchange between nodes that requires
that the address of each node used in the exchange
remain the same for the duration of the packet
exchange. Examples are a TCP connection or UDP
request/response.

unicast address
-

An identifier for a single interface. A packet datagram sent to a
unicast address is delivered to the interface identified by
that address.

multicast address
-

An identifier for a set of interfaces (typically belonging to
different nodes). A packet datagram sent to a multicast address is
delivered to all interfaces identified by that address.

link-layer identifier
- a link-layer identifier for an interface. Examples
include IEEE 802 addresses for Ethernet links,
and E.164 addresses for ISDN links.

link-local address
- An address having link-only scope

2.2. DHCPv6 Terminology

configuration parameter

Any parameter that can be used
to reach neighboring nodes attached to the same link.
All interfaces have by a link-local address.

preferred address
- An address assigned node to an interface whose use by
upper layer protocols is unrestricted. Preferred
addresses may be used as the source configure its
network environment and enable communication on a link or destination
address of packets sent
internetwork.

client

A host that initiates requests on a link to obtain
configuration parameters.

server

A server is a node that responds to requests from or clients on a
link to the interface.

deprecated address
- An address assigned provide: addresses, dynamic updates to an interface whose use is
discouraged, but not forbidden. DNS, or other
configuration parameters.

relay

A deprecated
address should no longer be used node that may advertise DHCP server addresses, or may act as a source address
in new communications. but packets sent
an intermediary to deliver DHCP messages between clients and
servers.

DHCP Agent

Either a DHCPv6 server or a DHCPv6 relay.

Bound, Perkins Expires May 12 August 1996 [Page 5]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

deprecated address are delivered as expected.
A deprecated 4]

Internet Draft DHCP Version 6 12 February 1996

agent address may continue to be used as a
source

The address for the duration of existing
communications.

valid address
- A preferred a neighboring DHCP relay or deprecated address. A valid address
may appear DHCP server on the
same link as the source or destination address of DHCP client.

msg-type

The msg-type defines the DHCPv6 protocol type for a
packet, and message.

transaction-ID

The transaction-ID is a monotonically increasing integer
identifier specified by the internet routing system client and is expected to
be able used by the client to deliver packets sent
match a DHCP Reply to a valid address.

invalid pending DHCP Request.

server address
- An

The server address that is not assigned specifies the address for the server
responding to any interface. a client.

binding

A
valid address becomes invalid when its valid
lifetime expires. Invalid addresses should not appear
as binding in DHCPv6 contains the source or destination of data which a packet.

preferred lifetime
- The length DHCPv6 server
MUST maintain for each of time that a valid address is preferred.
When the preferred lifetime expires, the address
becomes deprecated.

valid lifetime
- The length of time the address remains in the valid
state. The valid lifetime its clients. An implementation
MUST be greater than or
equal to the support bindings consisting of at least a client's
link-local address, agent address, preferred lifetime. When the lifetime and valid
lifetime expires, the address becomes invalid.

interface token
- A link-dependent identifier [9] for an interface that each client address, and the transaction-ID.

3. Protocol Design Model

This section is (at least) unique per link. Stateless Address
Autoconfiguration combines an interface token with
a prefix provided for implementors to form an address. From an address
autoconfiguration perspective, understand the DHCPv6
protocol design model from an interface token
is a bit string of known length. architectural perspective. The exact length
of an interface token goals,
conceptual models and the way it is created is
defined implementation examples presented in a separate link-specific document that
covers issues related to the transmission this
section do not specify requirements of IP
over a particular link type (e.g., [IPv6-ETHER]).
In many cases the token will DHCPv6 protocol.

3.1. Design Goals

The following list gives general design goals for this DHCPv6
specification.

- DHCPv6 should be the same as the
link-layer address.

2.2. a mechanism rather than a policy. DHCPv6 Terminology must
allow local system administrators control over configuration
parameters
- Is any parameter that can where desired; e.g., local system administrators
should be used by a node able to
configure their network environment so the node can
communicate on a link or on an internet.

client enforce local policies concerning allocation
and access to local resources where desired.

Bound, Perkins Expires 12 August 1996 [Page 5]

Internet Draft DHCP Version 6 12 February 1996

- A DHCPv6 MUST NOT introduce any requirement for manual
configuration of DHCPv6 client is a hosts, except possibly for
manually configured keys. Each host that initiates requests on a link
to obtain: addresses, dynamic updates should be able to DNS, or
other discover
appropriate local configuration parameters.

server parameters without user
intervention, and incorporate those parameters into its own
configuration.

- A server is DHCPv6 MUST NOT require a node that responds to requests from
clients server on a link to provide: addresses, dynamic
updates to DNS, or other configuration parameters.

Expires May 1996 [Page 6]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

relay-agent each link. To allow for
scale and economy, DHCPv6 must work across relay agents.

- A relay-agent is a node that listens on a link for DHCPv6 client requests, and then forwards the packet must be prepared to a
server on the network. The server will respond back receive multiple responses to the relay-agent, who will forward the response
solicitations for DHCP servers. Some installations may include
multiple, overlapping DHCPv6 servers to
the client on the relay-agents link.

message-type enhance reliability
and/or to increase performance.

- The message-type defines the DHCPv6 must coexist with statically configured, non-participating
hosts and with existing network protocol type for
this packet.

message-flag implementations.

- The message-flag defines an optional processing
notification for DHCPv6. The message-flag can also
be used by the Options for DHCPv6 specification.

error-code - The error-code specifies errors from a client or
server. The error-code can also MUST be used by the
Options for DHCPv6 specification.

total-addresses compatible with IPv6 Stateless Address
Autoconfiguration.

- The total-addresses specifies DHCPv6 must support the total number requirements of automated renumbering of
IPv6 addresses being provided from a [1].

- DHCPv6 servers should be able to support Dynamic Updates to
DNS [10].

- A DHCPv6 server to a client.
For each address there server protocol is a preferred and valid
lifetime.

completed-transaction NOT part of this DHCPv6
specification.

- A completed-transaction It is NOT a communications exchange
between a client and server, using the required set design goal of DHCPv6 request/response message-types, where the
final response message in to specify how a server
configuration parameter database is maintained or determined.
Methods for configuring DHCP servers are outside the request/response set
has been received by scope of
this document.

3.2. DHCPv6 Messages

Each DHCPv6 message contains a type, which defines whether the
message originated from a DHCPv6 server or client.

The message types are as follows:

01 DHCP Solicit

The DHCP Solicit message is a DHCPv6 multicast (or in special
circumstances unicast) message from a client and by the server.

transaction-ID
- to one or more
neighboring DHCPv6 Agents.

Bound, Perkins Expires 12 August 1996 [Page 6]

Internet Draft DHCP Version 6 12 February 1996

02 DHCP Advertise

The transaction-ID DHCP Advertise is an integer identifier specified
by the IPv6 unicast message from a DHCP Agent
in response to a client and DHCP Solicit.

03 DHCP Request

The DHCP Request is used by the client and server as an IPv6 unicast message from a transaction identifier client to define the set of
request/response messages between
a server, when the client and knows the IPv6 unicast address of a
server, for to request configuration parameters on a clients interface token.

client-link address
- The client-link address specifies the clients
link-local address. network.

04 DHCP Reply

The client-link address DHCP Reply is used an IPv6 unicast message sent by a relay-agent server to
respond to a client
on a link, after receiving a server response.

server address
- The server address specifies client's DHCP Request. Extensions [5] to the address for DHCP
Reply describe the
server responding to a client.

gateway address
- The gateway address specifies resources that the address of DHCP Server has committed
and allocated to the
relay-agent for a server, which client, and may be multiple
relay-agent hops away from contain other information
for use by the original relay-agent.

client address
- client.

05 DHCP Release

The client address specifies an address from a
server to be DHCP Release message is used by a client.

binding - A binding in DHCPv6 is an N-tuple that a client
and to inform
the server MUST maintain that the client is releasing a particular address,
or set of addresses or resources, even though the addresses or
resources may still be marked valid in DHCPv6 the server's binding for a

Expires May 1996 [Page 7]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

completed-transaction, where N
the client.

06 DHCP Reconfigure

The DHCP Reconfigure message is used by a DHCPv6 server
to inform the number of client that the server has new configuration parameters for a
information of importance to the client. An
implementation MUST support at least The client is
expected to initiate a 5-tuple
binding consisting new Request/Reply transaction.

3.3. Request/Response Processing Model

Processing details for the DHCP messages listed above are specified
in Sections 5, 6, and 7.

The request/response processing for DHCPv6 is transaction based
and uses a best-effort set of messages to guarantee a clients interface token,
client address, preferred lifetime completed
transaction. The timeout and valid
lifetime for each retransmission guidelines and
configuration variables are discussed in Section 7.4.

The request/response set is always started by a client address, with a DHCP
Request, which may be issued after the client knows the server's
address. The response message is from the server and is the
transaction-ID. DHCP

Bound, Perkins Expires May 12 August 1996 [Page 8]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

3. Protocol Design Model

This section is provided for implementors to understand the DHCPv6
protocol design model from an architectural perspective. Any
conceptual models presented in 7]

Internet Draft DHCP Version 6 12 February 1996

Reply. At this specification that point in the flow all data has been received. To
provide
implementation examples are not a requirement method of recovery if either the DHCPv6 protocol.

3.1. Design Goals

The following list gives general design goals for DHCPv6.

DHCPv6 should be a mechanism rather than client or server do not
receive the messages to complete the transaction, the client is
required to retransmit any DHCP Request message until it elicits a policy. DHCPv6 must
allow local system administrators control over configuration
parameters where desired; e.g., local system administrators should
DHCP Reply, or until it can be able to enforce local policies concerning allocation reasonably certain that the desired
DHCP Server is unavailable.

4. DHCPv6 Message Formats and access
to local resources where desired.

Hosts should require no manual configuration. Each host should Field Definitions

All fields in DHCPv6 messages MUST be
able initialized to discover appropriate local configuration parameters
without user intervention, and incorporate those parameters into
its own configuration.

Networks should require no hand configuration for individual
hosts. Under normal circumstances, binary zeroes by
both the network manager should not
have to enter any per-host configuration parameters. client and server unless otherwise noted. DHCPv6 should message
types not require a server on each link. To allow for
scale defined here (msg-types 0 and economy, DHCPv6 must work across relay agents.

A 7-255) are reserved.

All DHCP Agents MUST join the DHCPv6 Server/Relay-Agent multicast
group at the well-known multicast address FF02:0:0:0:0:0:1:0.

Servers on the same link as the client must be prepared to receive multiple responses to
a request MUST use the source address
in the IPv6 header from the client as the destination address in the
server's response datagrams.

4.1. UDP Ports used for configuration parameters. Some installations may
include multiple, overlapping DHCPv6 servers messages

DHCPv6 uses the UDP [7] protocol to enhance
reliability communicate between clients
and increase performance. servers. UDP is not reliable, but DHCPv6 must coexist with statically configured, non-participating
hosts provide some
reliability between clients and with existing network protocol implementations.

DHCPv6 should as much as possible be compatible with IPv6
Stateless Address Autoconfiguration.

DHCPv6 must support the requirements of automated renumbering servers. If a response is not
received after transmission of
IPv6 addresses.

DHCPv6 servers should a DHCP message, the message MUST be able
retransmitted according to support Dynamic Updates to DNS
[DYN-UPD].

It is NOT a design goal of the rules specified in 7.4.

A Client MUST transmit all messages over UDP using UDP port 547 as
the destination port. A client MUST receive all messages from UDP
port 546.

A DHCP Agent MUST transmit all messages over UDP using UDP port 546
as the destination port. A DHCP Agent MUST receive all messages over
UDP using UDP port 547.

4.2. DHCP Solicit Message Format

A DHCPv6 client transmits a DHCP Solicit message to specify obtain the
address of a server neighboring DHCP Agent, and to server
protocol.

It obtain one or more
addresses for DHCP servers which the DHCP Agent is NOT configured to
advertise. If a design goal of DHCPv6 client does not know any DHCP Agent address,
or wants to specify how locate a new server
configuration parameter database is maintained or determined.

The following list gives design goals specific to the transmission of
the network layer parameters.

Guarantee that any specific network address will not be in use by
more than one host at a time. receive configuration parameters,

Bound, Perkins Expires May 12 August 1996 [Page 9]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

Guarantee that client addresses that are not provided by DHCPv6
will not be added to a servers configuration parameter database or 8]

Internet Draft DHCP Version 6 12 February 1996

the servers binding for a clients interface token.

Retain host configuration parameters across client reboots. A
client should, whenever possible, be assigned SHOULD use, as the same
configuration parameters in response to a request.

Retain host configuration across server reboots, and, whenever
possible, a host should be assigned the same configuration
parameters despite restarts of the DHCPv6 mechanism,

Allow automatic assignment of configuration parameters to new
hosts to avoid hand configuration for new hosts.

Support fixed or permanent allocation of configuration parameters
to specific hosts.

3.2. Request/Response Model

DHCPv6 uses a message-type to define whether destination IP address, the packet originated
from a DHCPv6 server or client. The set of packets used to complete
a DHCPv6 transaction are defined as the request
Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0.

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 | msg-flags | RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and response set.

The message types length) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type 1

msg-flags 0

RESERVED 0

extensions No extensions are as follows:

01 DISCOVER

The DISCOVER message is a defined at this time.

4.3. DHCP Advertise Message Format

A DHCPv6 multicast packet from a client
to locate and request configuration parameters on a network,
when the client does not know the servers address.

02 CONF-REQUEST

The CONF-REQUEST is an IPv6 unicast packet from agent sends a client DHCP Advertise message to inform a
server, when the prospective
client knows about the IPv6 unicast address of a
server, to request configuration parameters on a network.

03 CONF-RESPONSE

The CONF-RESPONSE is an IPv6 unicast packet from a server in
response DHCP Agent to a client DISCOVER or CONF-REQUEST, which provides
the requested configuration parameters.

04 ACCEPT

The ACCEPT is a client response to a server CONF-RESPONSE. When
the client used DISCOVER to locate a server and request
configuration parameters on a network, the ACCEPT should DHCP Request
message may be
sent using the sent.

A DHCPv6 multicast address, which also serves to
inform other servers that responded agent MAY periodically transmit DHCP Advertise messages to
the DISCOVER they were
not selected. When the client used CONF-RESPONSE to request
configuration parameters from a server whose All-DHCPv6 Clients multicast address, no more often than once per
second, and with TTL == 1.

msg-type 2

S If set, the ACCEPT should be sent as an IPv6 unicast packet. The
ACCEPT agent address is also an implied acknowledgment to the a server selected
that the client has received the servers configuration
address.

Bound, Perkins Expires May 12 August 1996 [Page 10]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

parameters from 9]

Internet Draft DHCP Version 6 12 February 1996

msg-flags 0

server-count The number of addresses listed in the CONF-RESPONSE.

05 SERVER-ACK server
addresses field.

RESERVED 0

agent address The SERVER-ACK is an IPv6 unicast packet sent by address of a neighboring DHCP Agent
interface

server to
inform a client that it received an ACCEPT. addresses The SERVER-ACK is
used by the server to inform IPv6 address(es) of the client it has received an
acknowledgment that DHCPv6 server(s)
which the client DHCP Agent has received the configuration
parameters from the server, and denotes a completed-transaction been configured to
advertise.

extensions See [5].

Note that if a server. The neighboring DHCPv6 server at that point MUST commit its bindings
and any updates it may do for issues the client. The SERVER-ACK for DHCP Advertise,
then the client denotes a completed-transaction. The client at that
point MUST commit its bindings.

06 RELEASE

The RELEASE is used by agent address will be the client for two reasons:

1. To inform IPv6 address of one of the server that
server's interfaces, the client did not receive 'S' bit will be set, the
SERVER-ACK required to complete agent address will
be an address of the client transaction, server, and the server should delete that binding and any
updates it there may have done on behalf of the client.

2. To inform the be zero server that the client is releasing a
particular address or set of addresses, even though the
lifetimes for those addresses may not have become
invalid.

The processing and algorithms for the request/response set of
message-types will be discussed
sent in section 4.0.

3.3. Leased Address Model

The leased address model specifies a set of lifetimes associated with
addresses returned by the server. These lifetimes are meant to
support site renumbering, and are completely compatible with the
leasing model in IPv6 Stateless Address Autoconfiguration.

The DHCPv6 philosophy DHCP Advertise message. It is that the client has the responsibility to
renew a lease for an address that error for server-count
to be zero if the 'S' bit is about not set.

4.4. DHCP Request Message Format

In order to expire, or request parameters from a
new address or DHCP server, a client sends a
DHCP Request message and appends the same address before extensions which are appropriate
for obtaining the lease actually expires. needed parameters [5]. If the client does not request a new lease for an know
any DHCPv6 server address, the it must first obtain a server
MUST assume address by
multicasting a DHCP Solicit message (see Section 4.2). If the client
does not want have a new lease for that address.
The server MAY provide that valid IPv6 address to another which is reachable by the DHCPv6
server, the client requesting an
address, after all other addresses available to MUST use the server have been
exhausted.

3.3.1. Address Lifetimes

An unicast IP address returned to a client has of a preferred and valid lifetime.
The lifetimes represent the lease for addresses provided to local DHCPv6
relay as the
client, from destination IP address. Otherwise, the server.

The client MAY request a value for omit
the lifetimes returned by a
server, but server address in the DHCP Request message; in this case, the
client MUST use send the lifetimes provided by DHCP Request message directly to the server just

Bound, Perkins Expires May 12 August 1996 [Page 11]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

response.

When an address for a client interface becomes deprecated 10]

Internet Draft DHCP Version 6 12 February 1996

as it would any other datagram destined for the
processing of server, using the lease MUST be
server address as follows:

When the preferred lifetime of an IPv6 destination address expires, in the clients IPv6 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 |S|C| reserved | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) |
| server address becomes a deprecated address. A deprecated (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent address can be
used as a source |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link-local address in new communications |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and existing
communications. But a deprecated address means the node will soon
have an address whose valid lifetime will expire, when this
happens length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type 3

S If set, the address cannot be used in any communications.

An server address is a deprecated until its valid lifetime expires at
which point present

C If set, the address becomes an invalid address. An invalid
address MUST NOT be used as a source address in outgoing
communications, client requests the server to
clear all existing resources and MUST NOT be recognized bindings
currently associated with the client,
deallocating as a valid destination
address for incoming communications.

Once an address is deprecated an implementation SHOULD request a
new lease or address for needed.

reserved 0

transaction-ID A monotonically increasing number which the
client asks the server to copy into its DHCP
Reply, so that interface.

If the clients preferred lifetime is zero for an client can match Replies
with pending Requests.

server address If present, the IPv6 address
is immediately deprecated.

Implementors of the DHCPv6 would find it beneficial to coordinate
server which should receive the use client's DHCP
Request message.

agent address The IPv6 address of the preferred lifetime and valid lifetime for layers below the
DHCPv6 application layer with their implementation of Stateless
Address Autoconfiguration. It is suggested that implementations use relay or server
interface from which the same modules to configure addresses for stateless and stateful
address autoconfiguration. Implementors might want to consider an
option to stop all new communications for a deprecated address, to
support a very robust renumbering strategy, but this cannot be client received the
default behavior.

3.3.2. Duplicate Address Detection

DHCPv6 clients MUST support Duplicate Address Detection as specified
in
DHCP Advertise message

link-local address The IPv6 Stateless Address Autoconfiguration. This will provide a high
guarantee that DHCPv6 link-local address of the client addresses are not duplicated on a link.

It is an option for a
interface from which the the client issued
the DHCP Request message

Bound, Perkins Expires 12 August 1996 [Page 11]

Internet Draft DHCP Version 6 12 February 1996

extensions See [5].

4.5. DHCP Reply Message Format

The server sends a DHCP Reply message in response to inform every DHCP
Request received. If the request comes with the 'S' bit set, the
client it does could not have directly send the Request to
perform Duplicate Address Detection by the server setting and had to
use a value of
01 in the message-flag in client responses. neighboring relay agent. In this case it is
assumed that case, the server implementation is providing sends back
the guarantee
that DHCP Reply with the client addresses returned are unique on 'L' bit set, and the link. It DHCP Reply is
implementation defined how a server verifies addressed
to the uniqueness of client
addresses on a link.

A conceptual model of an implementation for DHCPv6 duplicate agent address
detection is that the client DHCPv6 module, which supports updating found in the network interfaces for a host, would use DHCP Request message. If the same application
configuration interface for DHCPv6 as
'L' bit is used for IPv6 Stateless
Address Autoconfiguration on an IPv6 conforming implementation. An
implementation can integrate and reuse the same modules in set, then the
network operating system kernel to spawn duplicate address detection, client's link-local address lifetime processing, and the processing of deprecated and
invalid addresses for existing and new connections.

Expires May 1996 [Page 12]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

3.3.3. Releasing Infinite Lifetime Addresses

DHCPv6 specifies no behavior which would require a client to listen
for asynchronous messages from servers on a well known UDP port. The
reason for this is that minimal implementations may not will also be able to
support such a feature in a client. But DHCPv6 does permit
present.

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 | error code | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| RESERVED |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (if present) |
| link-local address (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type 3

error code One of the
client to following values:

0 Success
1 Failure, reason unspecified
2 Authentication failed or nonexistent
3 Poorly formed request an infinite lease for addresses. The problem
4 Resources unavailable
5 Client record unavailable
16 Wrong phase of moon
32 Dogbert didn't like it
64 Server unreachable (ICMP error)

transaction-ID Copied from the transaction-ID which the
DHCPv6 server received in the DHCP Request.
to help the client match this case reply with an
outstanding Request.

L If set, the link-local address is that though present

Bound, Perkins Expires 12 August 1996 [Page 12]

Internet Draft DHCP Version 6 12 February 1996

RESERVED 0

link-local address If present, the server has permitted an infinite lease
for a client it may later be required that IPv6 address of the client give up that
lease or
interface which issued the addresses, for some organizational reason.

This specification leaves it as implementation defined how this
problem corresponding DHCP
Request message.

extensions See [5].

If the 'L' bit is set, and thus the link-local address is solved present in a DHCPv6 network environment.

One solution to
the problem Reply message, the Reply is to define an SNMP MIB for DHCPv6
clients that when set sent by a network management agent causes a client
to revalidate all of its addresses with the DHCPv6 server or issue a
RELEASE to the server.

3.4. DNS Host Name Autoregistration Model

It is important that DHCPv6 provide a server implementation set of
options for Dynamic Updates to DNS (DYNDNS), to support the
autoregistration of addresses to names in IPv6. DYNDNS SHOULD be
supported as a set of options in DHCPv6 as relay's
address which was specified in as the Options
for DHCPv6 specification. The minimum requirements to support DYNDNS agent address in DHCPv6 are as follows:

1. Clients SHOULD be able to request or change names for
addresses.

2. Servers SHOULD be able the DHCP Request
message, and the relay uses the link-local address to provide names for addresses
provided deliver the
Reply message to a the client.

3. If servers support DYNDNS then they MUST support

4.6. DHCP Release Message Format

The DHCP Release message is sent without the
following:

a) Create, Update, and Delete assistance of IPv6 AAAA Records
[IPv6-DNS] as specified in DYNDNS [DYN-UPD].

b) Create, Update, and Delete of IPv6 IP6.INT Domain PTR
records for any IPv6 AAAA addresses defined in DHCPv6
relay. When a client
DYNDNS request, or that the server automatically generated
for sends a client.

4. Request/Response Processing

The request/response processing for DHCPv6 Release message, it is transaction based and
uses a best-effort set of messages assumed to guarantee
have a completed-
transaction. The case where the client does not know the servers valid IPv6 address is depicted, and then the case where with sufficient scope to allow access to
the client does know target server. Only the
servers address is depicted. Then parameters which are specified in the timeout and retransmission
guidelines and configuration variables
extensions are discussed.

Expires May 1996 [Page 13]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

4.1. Processing when Server Address is not Known released. The processing for the DHCPv6 request/response model when the client
does not know the DHCP server address is as follows:

Server Client Server
(not selected) (selected)

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 |D| msg-flags | transaction-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| agent address | Transaction Complete
| (16 octets) | Client commits Bindings
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| link-local address |
| (16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IF extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type 5

DHCPv6 uses the UDP [RFC-768] protocol to communicate between clients
and servers. UDP is not reliable, but DHCPv6 must provide some
reliabilty between clients and servers. The network trade-off is
time versus the reliability that the completed set client, instead of
request/response messages were received by both
using the client given agent address and link-local
address to relay the Reply message.

msg-flags 0

Bound, Perkins Expires May 12 August 1996 [Page 14]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 13]

Internet Draft DHCP Version 6 12 February 1996

transaction-ID A monotonically increasing number which the
client asks the server to define a completed-transaction.

The request/response set is always started by a client either with a
DISCOVER when use in its DHCP
Reply, to help the client does not know match Replies with
outstanding Releases.

agent address The IPv6 address of the servers address, or a
CONF-REQUEST when agent interface to
which the client does know issued the servers address. The
second DHCP Request
message is

link-local address The IPv6 link-local address of the client
interface from which the server and is the CONF-RESPONSE. The client then acknowledges issued
the servers CONF-RESPONSE with an ACCEPT.
At this point DHCP Request message

extensions See [5]

If the client knows that the address it uses as the source IP address
in its IPv6 header will still be valid after the flow all data has been received and additional
messages are defined to insure server performs the transaction is completed, and
operations requested in the extensions to
provide a method of recovery if either the DHCP Release message,
the client or server do not
receive can then specify the messages to complete 'D' flag. When the 'D' flag is set,
the transaction.

The server after receiving MUST send the ACCEPT sends a SERVER-ACK, which is an
acknowledgment DHCP Reply back to the client client's address
as shown in the server has received source address of the clients
ACCEPT. At that point IPv6 header of the time vs reliability trade-off in DHCPv6 Release
message. Otherwise, when the 'D' bit is
for not set, the server to commit its bindings, MUST use
the agent address and perform link-local address in its DHCP Reply message to
forward the Reply message back to the releasing client.

4.7. DHCP Reconfigure Message Format

The DHCP Reconfigure message is sent without the assistance of any updates as
DHCPv6 relay. When a
result of server sends a Reconfigure message, the client messages (e.g. Update DNS). If
to which it is sent is assumed to have a valid IPv6 address with
sufficient scope to be accessible by the client
receives server. Only the SERVER-ACK, then parameters
which are specified in the extensions to the Reconfigure message need
be requested again by the client.

The client can commit its bindings.
But if SHOULD listen at UDP port 546 to receive possible DHCP
Reconfigure messages. If the client does not receive the SERVER-ACK then listen for DHCP
Reconfigure messages, it should send is possible that the client will not receive
notification that its DHCP server a RELEASE has deallocated the client's IPv6
address and/or other resources allocated to inform the server that any bindings should be
deleted client.

Bound, Perkins Expires 12 August 1996 [Page 14]

Internet Draft DHCP Version 6 12 February 1996

See discussion in 6.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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type | msg-flags | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| extensions (variable number and length) ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

msg-type 6

msg-flags 0

reserved 0

extensions See [5]

5. DHCP Client Considerations

A DHCPv6 client MUST silently discard any updates for the DHCP Solicit, DHCP Request,
or DHCP Release message it receives.

A DHCPv6 client should be rolled back. The retain its configured parameters and resources
across client RELEASE provides the final recovery check system reboots and DHCPv6 client program restarts.
However, in the these circumstances a DHCPv6
request/response set to complete client SHOULD also formulate
a transaction.

Retransmission DHCP Request message to verify that its configured parameters and
resources are still valid. This Request message MUST have the 'C'
bit set, to clear client binding information at the server, of messages is discussed in section 4.3.

The ACCEPT in which
the flow above is client may no longer have any record.

5.1. DHCP Solicit Message Processing

If a multicast packet which serves an
overloaded function, node wishes to respond become a new DHCPv6 client, it must first locate
a neighboring DHCP Agent. The client does this by multcasting
a DHCP Solicit message to the selected server, and well-known multicast address
FF02:0:0:0:0:0:1:0, setting the TTL == 1.

5.2. DHCP Advertise Message Processing

When a DHCPv6 client receives a DHCP Advertise message, it may
formulate a DHCP Request message to inform
other receive configuration information
and resources from the DHCP servers on listed in the network advertisement. If
the client is Advertise message has zero server addresses and does not selecting them. have the
'S' bit set, the client MUST silently discard the message.

Bound, Perkins Expires May 12 August 1996 [Page 15]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

4.2. Processing when Server Address is Known

The processing for the DHCPv6 request/response model when the client
does knows

Internet Draft DHCP Version 6 12 February 1996

If the server address 'S' bit is as follows (all packets are
Unicast):

Client Server

The processing above is the same as was discussed in 4.1, except the
CONF-REQUEST is used by Extensions; this might allow the DHCPv6 client to request select
the configuration parameters that best meets its needs from among several
prospective servers. Also in this case, the server, and client MUST use the CONF-REQUEST and ACCEPT are unicast packets.

4.3. Retransmission and Configuation Variables

Configuration variables
agent address as the address of its server for a future DHCPv6 message
transactions.

5.3. DHCP Request Message Processing

A DHCPv6 implementation that MUST be
configurable by a client or server are as follows:

Retranstimer - The time in seconds that obtains configuration information from a DHCPv6 client or
server
should wait before retransmitting by sending a DHCP Request message.

Expires May 1996 [Page 16]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

Default: 3 seconds.

Maxretrans - The maximum retransmissions that a DHCPv6 client
or server should retransmit, must know the
server's address before logging a
DHCPv6 System Error to sending the user.

Default: 3 retransmissions.

The problem with retransmissions occurs when they are continually
received by Request message. In addition,
the client must have acquired a valid DHCP agent address. If the
client or and server (e.g. duplicate bindings or updates).

To support informing a are on the same link, the agent address used by the
client or MUST be the same as the DHCP server's address.

If the client has no valid IPv6 address and the DHCP server that a retransmission is
being done a second
off-link, then the client MUST include the server address in the
appropriate field of the DHCP Request message and set the 'S' bit.
In this case, the IPv6 destination address of message-types are supported in DHCPv6 as
follows:

20 - DISCOVER-Retrans
21 - CONF-REQUEST-Retrans
22 - CONF-RESPONSE-Retrans
23 - ACCEPT-Retrans
24 - SERVER-ACK-Retrans
25 - RELEASE-Retrans

When a the Request message
MUST be the agent address.

Otherwise, if the client or server retransmits already has a DHCPv6 packet at valid IPv6 address and knows
the
application layer over UDP, they IPv6 address of a candidate IPv6 server, it MUST change send the message-type Request
message directly to the
same message-type with DHCPv6 server without requiring the Retrans suffix.

A response to a retransmission SHOULD be a duplicate services
of the local DHCPv6 relay.

If a previous
response client wishes to instruct a DHCP server to deallocate all
previous resources, configuration information, and bindings
associated with its agent address and link-local address, it sets the
'C' bit in the DHCP Request. A client or server. It is implementation defined how
this is accomplished.

One method of retransmitting duplicates MAY send in an implementation
conceptually such a Request
even when it is no longer attached to use the 5-Tuple binding for a link on which the relay
address is attached.

A client or MAY maintain information about which relay address and
server to
search address it has been using for use after a previous response. At a minimum reboot. When
the client interface
token and transaction-ID will be present in all messages; hence has a
binding can be searched (whether committed or pending DHCP Request and reboots before the
corresponding DHCP Reply is received, the client MUST issue its next
DHCP Request after rebooting with the 'C' bit set.

In any case, after choosing a transaction-ID which is numerically
greater than its previous transaction-ID, and filling in process) the
appropriate fields of the DHCP Request message, the client MAY append
various DHCPv6 Extensions to verify
if the message. These Extensions denote
specific requests by the client; for example, a previous response has been sent. client may request
a particular IP address, or request that the server send an update

Bound, Perkins Expires May 12 August 1996 [Page 17]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

5. Datagram and Field Definitions

5.1. Datagram 16]

Internet Draft DHCP Version 6 12 February 1996

containing the client's new IP address to a Domain Name Server. When
all Extensions have been applied, the DHCPv6 Datagram

For each pending DHCP Request message, a client MUST maintain the
following information:

- The agent address,

- The time at which the next retransmission will be multiple addresses and lifetimes present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| options (variable number attempted, and length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Expires May 1996 [Page 18]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

5.2. Field Definitions

- All fields in the datagram MUST be initialized Extensions appended to binary zeroes by
both the reply message.

If a client and server messages unless otherwise noted in Section
6.

msg-type - 1 octet integer value (message-type)

Value Description

01 DISCOVER
02 CONF-REQUEST
03 CONF-RESPONSE
04 ACCEPT
05 SERVER-ACK
06 RELEASE
07-19 RESERVED
20 DISCOVER-Retrans
21 CONF-REQUEST-Retrans
22 CONF-RESPONSE
23 ACCEPT-Retrans
24 SERVER-ACK-Retrans
25 RELEASE-Retrans
26-255 RESERVED

msg-flag - 1 octet integer value (message-flag)

Value Description

01 Server - Duplicate Address Detection not Required.
02-255 RESERVED

error-code - 1 octet integer value

Value Description

01 Server - Addresses are not available at this time.
02 Server - Address does not known by receive a DHCP Reply message with the Server
03-255 RESERVED

total-addrs - 1 octet integer value (total-addresses)

RESERVED - 2 octets Reserved for future use.
same transaction-ID - 2 octets integer value

interface token - 8 octets link-dependent identifier

server address - 16 octets address

gateway address - 16 octets address

client-link address - 16 octets link-local address

preferred lifetime - 4 octets integer value in seconds

valid lifetime - 4 octets integer value as a pending DHCP Request message within
REPLY_MSG_INITIAL_TIMEOUT seconds, it MUST retransmit the Request
with the same transaction-ID and continue to retransmit according to
the rules in seconds

Expires May 1996 [Page 19]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 Section 7.4.

Note that if a client address - 16 octets address

options - variable number of octets [DHCPv6-OPT]

Expires May 1996 [Page 20]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

6. Client/Server Message Formats

6.1. Client/Server UDP Ports, Multicast Group, crashes while its DHCP Request is still
pending, no state is maintained, and Addresses

A the client MUST transmit all messages over UDP using UDP Server Port 547.

A server or relay-agent MUST transmit all messages over UDP using UDP
Client Port 546.

A reissue a DHCP
Request after it restarts.

5.4. DHCP Reply Message Processing

When a client receives a DHCP Reply message, it MUST receive all messages over UDP using UDP Client Port 546.

A server or relay-agent check whether
the transaction-ID in the Reply message matches the transaction-ID
of a pending DHCP Request message. If no match is found, the Reply
message MUST receive all messages over UDP using UDP
Server Port 547.

A server or relay-agent be silently discarded, and an error SHOULD be logged.
If the transaction-ID matches that of a pending Request, and the 'L'
bit is set, but the source address in the IPv6 header does not match
the pending agent address, the client MUST join discard the DHCPv6 Server/Relay-Agent
multicast group well-known multicast message, and
SHOULD log the event. Likewise, if the transaction-ID matches that
of a pending Request, and the 'L' bit is not set, but the source
address FF02:0:0:0:0:0:1:0.

Servers on in the same link as IPv6 header does not match the pending server address,
the client MUST discard the message, and SHOULD log the event.

If the Reply message is acceptable, the client processes each
Extension [5], extracting the relevant configuration information and
parameters for its network operation.

Some configuration information extracted from the client MUST use Extensions to the source address in
DHCP Reply message must remain associated with the IPv6 header from DHCP server that

Bound, Perkins Expires 12 August 1996 [Page 17]

Internet Draft DHCP Version 6 12 February 1996

sent the client as message. The particular extensions that require this extra
measure of association with the destination address server are indicated in the
servers response packet. Servers DHCPv6
Extensions document [5]. These associations may be useful with DHCP
Release messages.

5.5. DHCP Release Message Processing

If a DHCPv6 client determines that respond some of its network configuration
parameters are no longer valid, it may enable the DHCPv6 server to relay-agents and
relay-agent processing
release allocated resources which are discussed no longer in section 7.

In the cases where use by sending a
DHCP Release message to the server. The client or server must retransmit messages the
msg-type codes in this section are used as stated consult its list
of resource-server associations in section 4.3 with
the values that represent the Retrans suffix for order to determine which server
should receive the msg-types.

6.2. Client DISCOVER and CONF-REQUEST Messages

msg-type: desired Release message. If the a client does not know wishes to
ask the server address or wants to locate a new
server release all information and resources relevent to receive configuration parameters
the client sets client, the msg-type client specifies no Extensions.

A client wishes to release resources which were granted to DISCOVER. it at
another link-local address. In this case that case, the client MUST use as must instruct
the destination
IP address server to send the DHCPv6 Server/Relay-Agent multicast address
FF02:0:0:0:0:0:1:0. DHCP Reply directly back to the client,
instead of performing the default processing of sending the DHCP
Reply back through the agent-address included in the DHCP Release.
This is done by setting the 'D' bit in the DHCP Release message.

5.6. DHCP Reconfigure Message Processing

DISCUSSION: On the one hand, clients REALLY SHOULD listen for
Reconfigure messages. On the other hand, some
implementors claim that requiring a client to
always listen at a port is asking too much. This
issue needs further discussion.

If a DHCPv6 client receives a DHCP Reconfigure message, it is
a request for the client knows to initiate a new DHCP Request/Reply
transaction with the server address which sent the client sets Reconfigure message.
The server sending the msg-type to
CONF-REQUEST. In this case Reconfigure message MAY be different than
the client MUST use as server which sent a DHCP Reply message containing the destination
IP address original
configuration information.

For each Extension which is present in the server address.

msg-flag:

Set Reconfigure message, the
client appends a matching Extension to binary zeroes.

error-code:

Set its DHCP Request message
which it formulates to binary zeroes.

total-addrs:

Set send to the number DHCPv6 server which is found in
the IP source address of addresses the message. The client also selects a
transaction-ID numerically greater than its last choice and inserts
it into the Request message. From then on, processing is requesting.

transaction-ID: the same as
specified above in Section 5.3.

Bound, Perkins Expires May 12 August 1996 [Page 21]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

Set to an integer value.

interface token:

Set to a unique link dependent identifier for the clients interface. 18]

Internet Draft DHCP Version 6 12 February 1996

6. DHCP Server Considerations

A server address:

Set to binary zeroes for DISCOVER.
Set to MUST ignore any DHCP Advertise, DHCP Reply, or DHCP
Reconfigure message it receives.

A server address for CONF-REQUEST.

gateway address:

Set to binary zeroes.

client-link address:

Set to the clients link-local address for the link on which the client
transmitted uses the packet.

preferred lifetime:

Set combination <link-local address, agent address> to binary zeroes if the
index into its records of client is not requesting bindings. A DHCPv6 server should
retain its client's bindings across server reboots, and, whenever
possible, a lifetime.
Set to the number of seconds the DHCPv6 client wants for should be assigned the lifetime.
Set same configuration
parameters despite server host system reboots and DHCPv6 server
program restarts. A DHCPv6 server MUST support fixed or permanent
allocation of configuration parameters to all 1's (oxffffffff) if the client wants an infinite lifetime.

The client must provide specific hosts.

6.1. DHCP Solicit and Advertise Message Processing

Upon receiving a preferred lifetime for each address
requested.

valid lifetime:

Set to binary zeroes if the client is not requesting DHCP Solicit message from a client, a server
constructs a lifetime.
Set DHCP Advertise message and transmits it to the number of seconds the
soliciting client wants for on the lifetime.
Set to all 1's (oxffffffff) if same link as the client wants an infinite lifetime. solicitation was received
from. The client must provide a valid lifetime for each destination address
requested. The valid lifetime must of the advertisement MUST be greater than or equal to the
preferred lifetime.

client address:

Set to binary zeroes if
source address of the client is not requesting solicitation. The DHCP server must use a renewal for an
existing IPv6
address of the interface on which it received from a server.
Set to an the client's DHCP
Solicit message as the source address field of the client previously received from a server when IPv6 header of the
client is requesting
message.

6.2. DHCP Request and Reply Message Processing

The DHCPv6 server MUST check to ensure that a new set valid link-local
address is present in the client's link-local address field of lifetimes the
Request message. If not, the message MUST be silently discarded.
Otherwise, it checks for the address.

A client presence of the 'S' bit. If the 'S' bit
is set, the server MUST NOT provide a check that the server with an address that was not given
to matches the client
destination IPv6 address at which the Request message was received
by a the server. DHCPv6 If the server address does not permit a match, the Request
message MUST be silently discarded.

If the message is accepted, the server extracts the client's
link-local address and the agent address, and uses the information to create
leases for manual configured addresses,
locate or update leases for addresses
created by IPv6 Stateless Address Autoconfiguration.

options:

See Options for DHCPv6 specification [DHCPv6-OPT].

Expires May 1996 [Page 22]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

6.3. Server CONF-RESPONSE Message

msg-type:

Set msg-type to CONF-RESPONSE.

msg-flag:

Set create an appropriate client record (called a binding) used
to 01 if store all the server knows addresses provided are verified relevant information, resources, and configuration
data which will be associated with the client. Each client record is
uniquely identifiable by the ordered pair <link-local address, agent
address>, since the link-local address is guaranteed to be
unique, otherwise set to binary zeroes.

error-code:

Set to 01 if unique [9]
on the server cannot provide any addresses to link identified by the client at
this time.
Set to 02 if agent address. If the server detects an received agent
address from the client it did and link-local address do not
provide correspond to the client.

total-addrs:

Set any binding known
to the number server, then the server MAY create a new binding for the

Bound, Perkins Expires 12 August 1996 [Page 19]

Internet Draft DHCP Version 6 12 February 1996

previously unknown client; otherwise, it SHOULD return a DHCP Reply
with a error code of addresses 5.

Before processing the Request, the server must determine whether or
not the Request is returning a retransmission of an earlier DHCP Request from
the same client.

transaction-ID:

Set to This is done by comparing the value transaction-ID to
all those transaction-IDs received from the same client provided in during the DISCOVER or CONF-REQUEST
msg-type.

interface token:

Set to a unique link dependent identifier for
previous TRANSACTION_ID_TIMEOUT seconds. If the clients interface transaction-ID is
the same as
provided in one received during that time, the clients DISCOVER or CONF-REQUEST msg-type. server address:

The address of MUST take the server responding.

gateway address:

Set
same action (e.g., retransmit the same DHCP Reply to the client)
as it did after processing the previous DHCP Request with the same value that existed
transaction-ID.

Otherwise (the transaction-ID has not been recently used), when the
server received has identified and allocated all the relevant information,
resources, and configuration data that is associated with the client,
it sends that information to its DHCPv6 client by constructing a
DHCP Reply message and including the packet.

client-link address:

Set client's information in DHCPv6
Extensions to the Reply message. The DHCP Reply message uses the
same value that existed when transaction-ID as found in the server received DHCP Request message.

If the packet.

preferred lifetime:

Set to DHCP Request message has the value requested by 'S' bit set in the client or message
header, the value required by DHCPv6 server MUST send the
server.

valid lifetime:

Set corresponding DHCP Reply
message to the value requested by agent address found in the Request.

The DHCP Request may contain Extensions, which are interpreted
as advisory (or mandatory) information from the client about its
configuration preferences. For instance, if the IP Address Extension
is present, the client DHCPv6 server SHOULD attempt to allocate or extend
the value required by the
server.

The valid lifetime MUST be greater than or equal to of the preferred
lifetime.

client address:

Expires May 1996 [Page 23]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

Set to an address provided indicated by the server if Extension.

6.3. DHCP Release Message Processing

If the client server receives a DHCP Release Message, it MUST verify that a
valid link-local address is not attempting
to renew existing addresses, meaning present in the link-local address fields from the client
have a value field
of binary zeroes. the message. If not, the error-code is set message MUST be silently discarded.

In response to 02 a DHCP Release Message with a valid link-local
address, the DHCPv6 server will only return the addresses formulates a DHCP Reply message that
will be sent back to the server can verify were provided releasing client by way of the server. If no addresses
could client's
link-local address. A DHCP Reply message sent in response to a DHCP
Release message MUST be verified sent to the total-addrs field, lifetimes, and client client's link-local address
will be via
the agent address in the Release message and set to binary zeroes. In the case as far as 'L' bit in the server is
concerned
Reply, (unless the DHCPv6 transaction 'D' bit is completed and set in the server will Release message).

Bound, Perkins Expires 12 August 1996 [Page 20]

Internet Draft DHCP Version 6 12 February 1996

If the received agent address and link-local address do not
expect a client ACCEPT message
correspond to its CONF-RESPONSE message.

options:

See Options for DHCPv6 specification [DHCPv6-OPT].

6.4. Client ACCEPT Message

msg-type:

Set msg-type any binding known to ACCEPT.

If the client sent server, then the server SHOULD
return a DHCP Reply with a error code of 5.

Otherwise, if the agent address and link-local address indicate a DISCOVER
binding known to request configuration parameters on the
link, server, then the client should use as the IP destination address server continues processing
for the DHCPv6
Server/Relay-Agent multicast address FF02:0:0:0:0:0:1:0. Release message. If there are any Extensions, the server
releases the particular configuration items specified in the
extensions. Otherwise, if there are no extensions, the client sent a CONF-REQUEST to request server
releases all configuration parameters on information in the link, then client's binding.

After performing the client should use as operations indicated in the IP destination address DHCP Release
message and its Extensions, the DHCPv6 server
address in formulates a DHCP
Reply message, copying the CONF-RESPONSE transaction-ID, from the server.

If DHCP Release
message. For each Extension in the client sees an error-code of 02 and DHCP Release message successfully
processed by the total-addrs field server, a matching Extension is
zero, appended to the server cannot process any of DHCP
Reply message. Extensions in the addresses requested and DHCP Release message which cannot
be successfully processed by the
client should not send an ACCEPT server MUST NOT correspond to any
Extension appended to the Reply by the server.

6.4. DHCP Reconfigure Message Processing

If a DHCPv6 server needs to change the client sees an
error-code configuration associated
to any of 02 and total-addrs does not equal zero its clients, it means the server
dropped addresses that constructs a DHCP Reconfigure message
and sends it could not locate requested by the client.

msg-flag:

Set to binary zeroes.

error-code:

Set to binary zeroes.

total-addrs:

Set to 1.

transaction-ID:

Set to each such client. The Reconfigure message MUST
contain the integer value that particular Extensions which inform the client used on its initial DISCOVER or
CONF-REQUEST msg-type about which
configuration information needs to the server.

interface token:

Set be changed.

DISCUSSION: Perhaps a DHCPv6 server should be allowed to the unique link dependent identifier for the clients interface
that was used for the clients initial DISCOVER or CONF-REQUEST msg-type

Expires May 1996 [Page 24]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995
multicast a DHCP Reconfigure message to the server.

server address:

Set its
clients. There are issues to the address provided by the be resolved here.
There is concern about encouraging servers CONF-RESPONSE.

gateway address:

Set to binary zeroes.

client-link address:

Set send
such messages to any DHCP-wide multicast address.

Perhaps a new extension should be defined so that
the server can ask (some of) its clients link-local address for the link on which the client
transmitted the packet.

preferred lifetime:

Set to the first or only preferred lifetime returned for an address by
the server.

valid lifetime:

Set to join a
specific multicast group. Then the first or only valid lifetime returned for an address by the
server.

The valid lifetime MUST be greater than or equal server could
efficiently multicast Reconfigure messages to
whatever group it wants.

This would have the preferred
lifetime.

client address:

Set additional advantage that
clients could receive Reconfigure messages without
listening to any specific UDP port.

If multiple clients can receive the first or only address provided by same
Reconfigure message, some algorithm must be
specified so that the server.

If clients stagger their

Bound, Perkins Expires 12 August 1996 [Page 21]

Internet Draft DHCP Version 6 12 February 1996

responses (i.e., their DHCP Requests) so that
the server isn't deluged all at once with some
arbitrarily large number of client did receive more than one address and lifetime, it MUST
store this data in an implementation defined manner, Requests.

7. DHCP Relay Considerations

The DHCPv6 protocol is constructed so that it can
issue a complete RELEASE for all addresses provided from the server
CONF-RESPONSE, if necessary later. But the ACCEPT relay does not need to carry
all those addresses have
to acknowledge the servers CONF-RESPONSE packet maintain any state in
an ACCEPT.

options:

No options are present.

6.5. Server SERVER-ACK Message

msg-type:

Set msg-type to SERVER-ACK.

If the client sent the ACCEPT order to acknowledge a servers CONF-RESPONSE
message on the facilitate DHCPv6 Server/Relay-Agent multicast address
FF02:0:0:0:0:0:1:0, the server client/server
interactions.

All relays MUST look at use the server IPv6 address in of the
packet to determine if interface from which the ACCEPT
DHCPv6 message is transmitted as the source address for them or not.

If the IP header
of that DHCPv6 message.

7.1. DHCP Solicit and DHCP Advertise Message Processing

Upon receiving a DHCP Solicit message is not for from a particular server then this is an indirect client, a relay
constructs a DHCP Advertise message to that particular server the client is not accepting them as

Expires May 1996 [Page 25]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

their server for this transaction, and MUST NOT send a SERVER-ACK to the
clients ACCEPT.

msg-flag:

Set to binary zeroes.

error-code:

Set to binary zeroes.

total-addrs:

Set to 1.

transaction-ID:

Set transmits it to the integer value that the
soliciting client used on its initial DISCOVER or
CONF-REQUEST msg-type to the server.

interface token:

Set to same link as the solicitation was received
from. The destination address of the advertisement MUST be the unique link dependent identifier for
source address of the clients interface
that was used for solicitation.

DISCUSSION: If the clients initial DISCOVER or CONF-REQUEST msg-type Solicit is delivered to a server and
the server. server address:

Set is allowed to send the servers address.

gateway address:

Set corresponding
Advertise back to the same value that existed when a client, the server received the packet.

client-link address:

Set could then
include some prospective information to the same value that existed when "entice" a
client to use its services. For instance, a server
could include proposed lifetime information, and a
client could pick the server received with the packet.

preferred lifetime:

Set best "terms".
Presumably, this forwarding behavior should be a
matter of relay configuration instead of client
request. I'll assume that for now and try to make
the value provided by protocol reflect the client.

valid lifetime:

Set ability of DHCP Advertise
messages to contain Extensions and come from DHCP
servers off-link. That may take a little more
doing which isn't in the value provided by the client.

The valid lifetime MUST protocol right now, be greater than or equal to the preferred
lifetime.

client address:

Set
patient.

When transmitting a DHCP Advertise message, a relay indicates how
many server addresses which it was configured to the advertise, and
includes each address provided by in the client.

At this point DHCP Advertise message. The DHCP
Advertise message must use a routeable IPv6 address in the server MUST commit source
address of the configuration parameters
provided to IPv6 header of the client from message. In particular, the servers CONF-RESPONSE.

options: source
address of any DHCP Advertise message sent by a DHCPv6 relay MUST NOT
be a link-local address.

Bound, Perkins Expires May 12 August 1996 [Page 26]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

No options are present.

6.6. Client RELEASE 22]

Internet Draft DHCP Version 6 12 February 1996

7.2. DHCP Request Message

msg-type:

Set msg-type to RELEASE.

If Processing

When a relay receives a DHCP Request message, it MUST check that the client had sent
message is received from a link-local address, that the link-local
address matches the link-local address field in the Request message
header, and that the agent address field of the message matches an ACCEPT
IPv6 address associated to the server and received a SERVER-ACK
for that message then interface from which the client DHCP Request
message was received. The relay MUST commit the configuration
parameters provided by also check whether the servers CONF-RESPONSE and a RELEASE message 'S'
bit is not required. But if the client did not receive a SERVER-ACK set in response to the clients ACCEPT, then message header. If any of these checks fail, the client
message is not acceptable and MUST issue a RELEASE
to the server. be silently discarded.

If the client no longer needs an address or has been notified to return
an address to received request message is acceptable, the server, relay then
transmits the client SHOULD issue a RELEASE DHCP Request message to the
server.

msg-flag:

Set to binary zeroes.

error-code:

Set to binary zeroes.

total-addrs:

Set to DHCPv6 server found in the total number
Server Address field of addresses the client is releasing. In the
case received DHCP Request message. All of a RELEASE where the client did not receive the SERVER-ACK this
value MUST equal
the total number fields of addresses for the servers
CONF-RESPONSE.

transaction-ID:

Set to DHCP Request message header transmitted by the integer value that relay
are copied over unchanged from the client used on its initial DISCOVER or
CONF-REQUEST msg-type to DHCP Request received from the server.

interface token:

Set to
client. Only the unique link dependent identifier for fields in the clients interface
that was used for IPv6 header will differ from the clients initial DISCOVER or CONF-REQUEST msg-type
to
datagram received from the server.

server address:

Set to binary zeroes.

gateway address:

Set to binary zeroes.

client-link address:

Set to client, not the clients link-local address for payload.

7.3. DHCP Reply Message Processing

When the link on which relay receives a DHCP Reply, it MUST check whether the client

Expires May 1996 [Page 27]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

transmitted
message has the packet.

preferred lifetime:

Set to 'L' bit set. It must check whether the valid lifetime returned for an link-local
address by the server.

valid lifetime:

Set to the valid lifetime returned for field contains an IPv6 address by the server.

The valid lifetime MUST be greater than or equal to that has prefix FE80::00 .
If all the preferred
lifetime.

client address:

Set checks are satisfied, the relay MUST send a DHCP Reply
message to the link-local address provided by listed in the server.

The client will return received Reply
message. Only the number of addresses and associated lifetimes
provided fields in the servers CONF-RESPONSE.

options:

No options are present.

7. Relay-Agent Processing

The relay-agent MUST use UDP DHCPv6 Server Port 547 as IPv6 header will differ from the UDP port to
accept client responses in an implementation.

The relay-agent MUST join
datagram received from the DHCP Server/Relay-Agent multicast group
well-known multicast address FF02:0:0:0:0:0:1:0. server, not the payload.

7.4. Retransmission and Configuation Variables

When a DHCPv6 Relay-Agent hears client does not receive a request from DHCP Reply in response to a DHCPv6 Client it MUST:

If
pending DHCP Request, the gateway address is NOT zero then client MUST retransmit the relay-agent MUST:

Put identical DHCP
Request to the relay-agents IP address in same server again until it can be reasonably sure that
the gateway address field of DHCPv6 server is unavailable and an alternative can be chosen.
It is important for the clients request packet.

All relay-agents MUST:

Put their relay-agent address as DHCP Server to be sure that its client has
received the source address for configuration information included with the IP
header.

Put Extensions
to the next relay-agent or known DHCP Reply message.

Likewise, but less commonly, when a DHCP server address as the
destination address does not receive a
DHCP Request message in the IP header.

Forward the packet response to the its DHCP Reconfigure message to
the next hop relay-agent or
known server.

When client, the remote server receives MUST retransmit the identical DHCP Reconfigure
to the client request until it is reasonably certain that the client is not
available for reconfiguration. If no corresponding DHCP Request
is ever received by the server, the server MAY erase or deallocate
information as needed from the relay-agent
it will know its client's binding.

Bound, Perkins Expires 12 August 1996 [Page 23]

Internet Draft DHCP Version 6 12 February 1996

These retransmissions occur using the following configuration
variables for a DHCPv6 implementation that MUST be configurable by a
client or server are as follows:

REPLY_MSG_INITIAL_TIMEOUT

The time in seconds that a remote DHCPv6 client request (not on the servers link),
because there is waits to receive a gateway address in
server's DHCP Reply before retransmitting a DHCP Request.

Default: 2 seconds.

REPLY_MSG_MIN_RETRANS

The minimum number of DHCP Request transmissions that a DHCPv6
client should retransmit, before aborting the request. So servers MUST
verify request, possibly
retrying the gateway address is not zero, Request with another Server, and logging DHCPv6
System Error.

Default: 10 retransmissions.

RECONF_MSG_INITIAL_TIMEOUT

The time in seconds that a DHCPv6 server waits to determine if the clients request
is from receive
a remote link.

Expires May 1996 [Page 28]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995 client's DHCP Request before retransmitting its DHCP
Reconfigure.

Default: 2 seconds.

RECONF_MSG_MIN_RETRANS

The minimum number of DHCP Reconfigure messages that a DHCPv6
server responds as specified in section 6.0, but uses the
gateway address as the destination address in should retransmit, before assuming the IP header.

When the relay-agent receives client is
unavailable and that the remote servers response, it MUST
forward server can proceed with the packet needed
reconfiguration of that client's resources, and logging DHCPv6
System Error.

Default: 10 retransmissions.

The following parameter specifies how long a DHCPv6 server has to the client, by
keep track of client transaction-IDs in order to make sure that
client retransmissions using the client-link address as
the source address for the IP Header. same transaction-ID are idempotent.

TRANSACTION_IT_TIMEOUT

Default: 10800 seconds

Bound, Perkins Expires 12 August 1996 [Page 24]

Internet Draft DHCP Version 6 12 February 1996

8. Security Considerations

Security for DHCPv6 can

It may often be used as specified in [IPv6-SA], [IPv6-AUTH],
and [IPv6-ESP], which are implementation requirements very important for IPv6.

Appendix A - Related Work in IPv6

The related work in IPv6 that would best serve an implementor to study
is the IPv6 Specification [IPv6-SPEC], the IPv6 Addressing Architecture
[IPv6-ADDR], IPv6 Stateless Address Autoconfiguration [IPv6-ADDRCONF],
IPv6 Neighbor Discovery Processing [IPv6-ND], DHCP clients and Dynamic Updates servers to DNS
[DYN-UPD]. These specifications afford DHCPv6 be
able to build upon authenticate the IPv6
work messages they exchange. For instance, a
DHCP server may wish to provide both robust stateful autoconfiguration and
autoregistration of DNS Host Names.

The IPv6 Specification provides be certain that a DHCP Request originated
from the base architecture and design of
IPv6. A key point client identified by the <link-local address, agent address>
fields included within the Request message header. Conversely,
it is often essential for DHCPv6 implementors a DHCP client to understand is that IPv6
requires be certain that every link in the internet have
configuration parameters and addresses it has received were sent to
it by an MTU authoritative DHCP server. Similarly, a DHCP server should
only accept a DHCP Release message which seems to be from one of 576 octets or
greater (in IPv4
its clients, if it has some assurance that the requirement client actually did
transmit the Release message. At the time of this writing, there
is 68 octets). This means no generally accepted mechanism useful with DHCPv4 that a
UDP datagram of 536 octets will always pass through an internet (less 40
octets can be
extended for use with DHCPv6.

There has been some discussion about the advisability and
desirability of using IPv6 header), as long as there are no IP options prior Authentication to
the UDP datagram allow DHCPv6 clients
and servers to authenticate messages which they exchange. However,
in the packet. But, IPv6 does not support
fragmentation at routers many circumstances a client has only a link-local address, and fragmentation must take place end-to-end
between hosts. If a DHCPv6 implementation needs
link-local address cannot be forwarded to send a packet
greater than 536 octets it can either fragment server which is off-link.
Thus, the UDP datagram in UDP
or use Path MTU Discovery [IPv6-SPEC] to determine DHCP relay _has_to be involved, for instance, with the size of DHCP
Request when the
packet that will traverse client has only a network path. It is implementation defined
how link-local address, and therefore
the DHCP Request (in this is accomplished in DHCPv6.

The IPv6 Addressing Architecture Specification provides circumstance) MUST have the relay's address
scope that can be used
in an IPv6 implementation, and the various
configuration architecture guidelines for network designers of the IPv6 destination address space. Two advantages of IPv6 is field.

That means that multicast addressing is well
defined and nodes can create link-local addresses during initialization
of the nodes environment. This authentication (in this circumstance) CANNOT be
end-to-end. That means that IPsec cannot apply. Thus, in order to
authenticate DHCP Request messages in many circumstances will require
a host immediately can configure
an IPv6 address at initialization more specialized technique for an interface, before communicating message authentication, as specified
in
any manner on the link. The host can then use a well-known multicast address DHCPv6 Extensions companion document [5].

One possibility is to begin communications allow relays to discover neighbors on encapsulate the link, or DHCP Request
before delivery to the server. Then the client could apply
end-to-end authentication (such as was
discussed in afforded by IPSec) which would
nevertheless remain untouched by the specification to locate a DHCPv6 server or relay-agent. relay. The IPv6 Stateless Address Autoconfiguration Specification (addrconf)
defines how a host can autoconfigure addresses based on neighbor discovery
router advertisements, and the use of a validation lifetime relay could, if
desired, apply its own authentication header to support
renumbering of addresses on the Internet. In addition encapsulated
datagrams.

9. Acknowledgements

Thanks to the addrconf
specification defines DHC Working Group for their time and input into the protocol interaction
specification. A special thanks for a host the consistent input, ideas,
and review by (in alphabetical order) Brian Carpenter, Ralph Droms,
Thomas Narten, Jack McCann, Yakov Rekhter, Matt Thomas, Sue Thomson,
and Phil Wells.

Bound, Perkins Expires 12 August 1996 [Page 25]

Internet Draft DHCP Version 6 12 February 1996

Thanks to begin stateless
or stateful autoconfiguration. DHCPv6 is one vehicle Steve Deering and Bob Hinden, who have consistently
taken the time to perform stateful
autoconfiguration. Compatibility with addrconf is a design goal discuss the more complex parts of the IPv6
specifications.

The authors MUST also thank their employers for the opportunity and
funding to work on DHCPv6

Expires May 1996 [Page 29]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

where possible. and IPv6 Neighbor Discovery (ND) is in general as an individual in the node discovery protocol
IETF.

A. Related Work in IPv6
(replaces and enhances functions of IPv4 ARP Model). To truly
understand

The related work in IPv6 and addrconf it is strongly recommended that
implementors understand would best serve an implementor
to study is the IPv6 ND. Specification [2], the IPv6 Addressing
Architecture [3], IPv6 Stateless Address Autoconfiguration [9], IPv6
Neighbor Discovery Processing [4], and Dynamic Updates to DNS is a specification that supports the
dynamic update of DNS records for both IPv4 and IPv6. [10].
These specifications afford DHCPv6 can use
the dynamic updates to DNS build upon the IPv6 work to now integrate addresses
provide both robust stateful autoconfiguration and name space to
not only support autoconfiguration, but also autoregistration in IPv6.

Expires May 1996 [Page 30]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

Change History

Changes from July 95 to November 95 Drafts:

Refined request/response codes
of DNS Host Names.

The IPv6 Specification provides the base architecture and processing design of
IPv6. A key point for DHCPv6 implementors to support transaction
processing model.

Permit multiple addresses and lifetimes understand is that IPv6
requires that every link in a request and response.

Moved Dynamic Updates to DNS as the internet have an Option to be defined in MTU of 576 octets or
greater (in IPv4 the requirement is 68 octets). This means that
specification.

Settled on using a
UDP as it supports DHCP client server model as opposed
to TCP which has overhead datagram of 536 octets will always pass through an internet (less
40 octets for this model.

Reformatted specification the IPv6 header), as long as there are no IP options
prior to the UDP header in the datagram. But, IPv6 does not support analysis, packet formats,
fragmentation at routers and
processing in their own sections fragmentation must take place end-to-end
between hosts. If a DHCPv6 implementation needs to make send a datagram
greater than 536 octets it easier for implementors can either fragment the UDP datagram
in UDP or use Path MTU Discovery [2] to
read.

Removed address count as it determine the size of the
datagram that will traverse a network path. It is not necessary for synchronization.

Added error-code, msg-flag, and total-addrs fields.

Made transaction-ID 2 octets.

Updated terminology to coordinate with IPv6 Stateless Address
Autoconfiguration.

Added more implementation notes.

Moved IPv6 Related Work to an Appendix.

Fixed various bugs
defined how this is accomplished in DHCPv6.

The IPv6 Addressing Architecture Specification provides the spec from DHC WG input.

Added Security reference pointers.

Removed options format, which will address
scope that can be used in an IPv6 implementation, and the options spec.

Added retransmission various
configuration variables, msg-types, and logic.

Changes from March 95 to July 95 Drafts:

Used integer values instead of bit values architecture guidelines for type and code fields.

Used message-type and message-code fields and rely on looking at
the fields in the datagram instead network designers of multiple over-lapping
request/response codes.

Added address-count field processing to be specified by the
client as opposed to
the server, IPv6 address space. Two advantages of IPv6 is that multicast
addressing is well defined and nodes can create link-local addresses
during initialization of the processing nodes environment. This means that a
host immediately can configure an IPv6 address at initialization
for when
client and server address-counts become disjoint.

Added Requirements wording for MUST, SHOULD, MAY, etc.

Added Design Goals section.

Redefined transaction-ID and interface-token.

Expires May 1996 [Page 31]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

Added Client/Server Binding definition and processing
section to handle those bindings.

Added more terminology, definitions, and rationale.

Added model an interface, before communicating in any manner on the link.
The host can then use a well-known multicast address to support Dynamic Updates begin
communications to DNS for Host Names.

Reduced discover neighbors on the request/response model link, or as was discussed
in the specification to 3 packets by not doing locate a DHCPv6 server confirm to or relay.

The IPv6 Stateless Address Autoconfiguration Specification [9]
defines how a clients confirm to host can autoconfigure addresses based on neighbor
discovery router advertisements, and the use of a servers response.

Added model validation lifetime

Bound, Perkins Expires 12 August 1996 [Page 26]

Internet Draft DHCP Version 6 12 February 1996

to support like lifetime fields renumbering of addresses on the Internet. In addition the
addrconf specification defines the protocol interaction for lease
management a host to coordinate with IPv6 Stateless Address
Autoconfiguration.

Added model and processing definitions for future
begin stateless or stateful autoconfiguration. DHCPv6 Options
Specification.

Added gateway-address and client-link-address for relay-agent
processing.

Removed excessive use is one vehicle
to perform stateful autoconfiguration. Compatibility with addrconf
is a design goal of DHCPv6.

IPv6 Neighbor Discovery (ND) [4] is the acronym DHCPv6 for section titles node discovery protocol in
IPv6 (replaces and when referencing clients enhances functions of IPv4 ARP Model [6]). To
truly understand IPv6 and servers.

Added Draft ***Open Issues*** Section for review by addrconf it is strongly recommended that
implementors understand IPv6 ND.

Dynamic Updates to DNS [10] is a specification that supports the DHC Working
Group.

Added Change History.

Expires May 1996 [Page 32]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

Acknowledgements

The DHC Working Group
dynamic update of DNS records for their time both IPv4 and input into the specification.
A special thanks for IPv6. DHCPv6 can use
the consistent input, ideas, and review by (in
alphabetical order) Brian Carpenter, Ralph Droms, Thomas Narten, Jack
Mccann, Charlie Perkins, Yakov Rekhter, Matt Thomas, Sue Thomson, dynamic updates to DNS to now integrate addresses and
Phil Wells.

The author would name space
to not only support autoconfiguration, but also like autoregistration in
IPv6.

B. Change History

B.1. Changes from November 95 to thank Steve Deering February 96 Drafts

Substituted use of client's link-local address for previous uses of
client's interface token.

Reorganized DHCP messages into Solicit/Advertise, Request/Reply,
Release, and Bob Hinden,
who have consistently taken the time to discuss the more complex
parts Reconfigure.

Made message-specific formats instead of using the IPv6 specifications.

The author MUST also thank his employer same DHCP header
for the opportunity each message.

Eliminated retransmission message types.

Server commits after receiving DHCP Request, and funding
to work optimistically
depends on DHCPv6 client retransmissions as negative acknowledgement.

Eliminated total-addrs.

Eliminated all definitions and most fields related to allocating IPv6 in general as an individual in
addresses (moved to the IETF. Extensions specification).

Renamed "gateway address" to be "agent address".

Bound, Perkins Expires 12 August 1996 [Page 27]

Internet Draft DHCP Version 6 12 February 1996

References

[DHCPv6-OPT]
C. Perkins, "Options

[1] S. Bradner and A. Mankin. The Recommendation for the Dynamic Host Configuration
Protocol for IPv6 (ODHCPv6)" Internet Draft, November 1995
<draft TBD>

[IPv6-SPEC] IP Next
Generation Protocol. RFC 1752, January 1995.

[2] S. Deering and R. Hinden, "Internet Protocol Hinden. Internet Protocol, Version 6
[IPv6] Specification" Internet Draft, June 1995
<draft-ietf-ipngwg-ipv6-spec-02.txt>

[IPv6-ADDR] (IPv6)
Specification. RFC 1883, December 1995.

[3] R. Hinden, Hinden and S. Deering, Editors, "IP Deering. IP Version 6 Addressing Architecture"
Internet Draft, June 1995
<draft-ietf-ipngwg-ipv6-addr-arch-03.txt>

[IPv6-ADDRCONF]
S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration"
Internet Draft, November 1995
<draft-ietf-addrconf-ipv6-auto-05.txt>

[IPv6-ND] Architecture.
RFC 1883, December 1995.

[4] T. Narten, E. Nordmark, and W. A. Simpson, "IPv6 Simpson. IPv6 Neighbor Discovery"
Internet Draft, September 1995
<draft-ietf-ipngwg-discovery-02.txt>

[IPv6-DNS]
S. Thompson and
Discovery. draft-ietf-ipngwg-discovery-03.txt -- work in
progress, November 1995.

[5] C. Huitema, "DNS Perkins. Extensions to support IP
version 6", DHCPv6. draft-ietf-dhc-dhcpv6ext-00.txt
-- work in progress, November 1995.

[6] David C. Plummer. An Ethernet Address Resolution Protocol:
Or Converting Network Protocol Addresses to 48.bit Ethernet
Addresses for Transmission on Ethernet Hardware. RFC 826,
November 1982.

[7] J. B. Postel. User Datagram Protocol. RFC 768, August 1980.

[8] J. B. Postel, editor. Internet Draft, March 1995
<draft-ietf-ipngwg-dns-00.txt>

[RFC-1034]
P. Mockapetris, "Domain Names - implementation Protocol. RFC 791, September
1981.

[9] S. Thomson and specification"
STD-13, 11/01/87

Expires May 1996 [Page 33]

INTERNET-DRAFT draft-ietf-dhc-dhcpv6-03.txt November 1995

[RFC-1035]
P. Mockapetris, "Domain Names T. Narten. IPv6 Stateless Address
Autoconfiguration. draft-ietf-addrconf-ipv6-auto-06.txt
- concepts and facilities"
STD-13, 11/01/87

[DYN-UPD] work in progress, November 1995.

[10] S. Thomson, Y. Rekhter, and J. Bound, "Dynamic Bound. Dynamic Updates in the
Domain Name System (DNS)" Internet Draft, March 1995
<draft-ietf-dnsind-dynDNS-01.txt>

[RFC-768]
J. Postel, "User Datagram Protocol"
STD-6, 08/28/80.

[DHCP-v4]
R. Droms, "Dynamic Host Configuration Protocol"
RFC 1541 Proposed Standard, October 1993

[IPv6-Ether]
M. Crawford, "A Method for the Transmission of IPv6 Packets over
Ethernet Networks", (DNS). draft-ietf-dnsind-dynDNS-06.txt --
work in progress, February 1996.

Bound, Perkins Expires 12 August 1996 [Page 28]

Internet Draft, October 1995
<draft-ietf-ipngwg-ethernet-ntwrks-01.txt>

[IPv6-SA]
R. Atkinson, "Security Architecture for Draft DHCP Version 6 12 February 1996

Chair's Address

The working group can be contacted via the Internet Protocol"
RFC 1825, August 1995

[IPv6-AUTH]
R. Atkinson, "IP Authentication Header"
RFC 1826, August 1995

[IPv6-ESP]
R. Atkinson, "IP Encapsulating Security Payload (ESP)"
RFC 1827, August 1995

Authors' current chair:

Ralph Droms
Computer Science Department
323 Dana Engineering
Bucknell University
Lewisburg, PA 17837

Phone: (717) 524-1145
E-mail: droms@bucknell.edu

Author's Address

Questions about this memo can be directed to:

Jim Bound Charles Perkins
Digital Equipment Corporation T. J. Watson Research Center
110 Spitbrook Road, ZKO3-3/U14 IBM Corporation
Nashua, NH 03062 30 Saw Mill River Rd., Rm J1-A25
Hawthorne, NY 10532
Phone: (603) 881-0400
Email: +1-603-881-0400 +1-914-784-7350
Fax: +1-914-784-6205
E-mail: bound@zk3.dec.com perk@watson.ibm.com

Bound, Perkins Expires May 12 August 1996 [Page 34] 29]

----