INTERNET-DRAFT J. Bound
DHC Working Group Digital Equipment Corp
March 1995 Y. Rekhter
T.J. Watson Research Center IBM Corp
Sue Thomson
Bellcore
Dynamic Host Configuration Protocol for IPv6
draft-ietf-dhc-dhcpv6-01.txt
Status of this Memo
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-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).
Discussion for this draft will take place on host-
conf@sol.cs.bucknell.edu.
Abstract
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6): provides a
mechanism to autoconfigure inter-link Host IPv6 addresseses [IPv6-
ADDR], provides parameters to autoregister [DYN-DNS-UPD] and receive
Domain Name System (DNS) [RFC-1034&1035] Host names, and provides a
mechanism to specify additional configuration options in the
protocol.
Expires September 1995 [Page 1]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
Table of Contents:
1. Introduction................................................3
2. Terminology.................................................3
3. DHCPv6 Protocol Design Model................................4
3.1 DHCPv6 Protocol Request/Response Model......................4
3.2 DHCPv6 Leased Address Model.................................4
3.3 DHCPv6 DNS Host Name Autoregistration Model.................5
3.4 DHCPv6 Client/Server Model..................................5
4. DHCPv6 Protocol Format......................................7
5. DHCPv6 Client/Server Processing.............................9
5.1 DHCPv6 Client Transmission..................................9
5.2 DHCPv6 Server Transmission..................................9
5.3 DHCPv6 Client Requests......................................9
5.4 DHCPv6 Client Responses....................................10
5.5 DHCPv6 Server Responses....................................11
5.6 DHCPv6 Server Lease Expiration.............................13
6. DHCPv6 Relay-Agent Processing..............................13
Acknowledgements...............................................15
References.....................................................15
Authors' Addresses.............................................16
Expires September 1995 [Page 2]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
1. Introduction
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6): provides a
mechanism to autoconfigure inter-link Host IPv6 addresseses [IPv6-
ADDR], provides parameters to autoregister [DYN-DNS-UPD] and receive
Domain Name System (DNS) [RFC-1034&1035] Host names, and provides a
mechanism to specify additional configuration options in the
protocol.
DHCPv6 is an Internet application protocol that uses a Client/Server
model to communicate between Hosts. DHCPv6 executes over the UDP
[RFC-768] transport protocol, and the IPv6 Internet Protocol Version
6 [IPv6-SPEC]. DHCPv6 will need to request Server and Client Ports
from IANA.
DHCPv6 is the IPv6 specification for a statefull implementation of
address autoconfiguration as defined in IPv6 Stateless Address
Configuration [IPv6-ADDRCONF].
2. Terminology
Configuration Data: Configuration Data is information a Host can use
to configure a Host on a network so that the Host can interoperate
with other Hosts on a network.
DHCPv6 Client: A DHCPv6 Client is a Host that initiates requests on a
network to obtain Configuration Data from a DHCPv6 server.
DHCPv6 Server: A DHCPv6 Server is a Host that responds to requests
from DHCPv6 clients to provide Configuration Data.
DHCPv6 Relay-Agent: A DHCPv6 Relay-Agent is a DHCPv6 Server that
listens on the network for DHCPv6 Clients requesting Configuration
Data, and then relays the request to a DHCPv6 Server and the reply
back to the DHCPv6 Client.
Transaction ID - This is used to uniquely identify a set of DHCPv6
request/response messages between DHCPv6 Servers and Clients. The
Transaction ID is generated by the DHCPv6 Client requests.
Interface-Token: An Interface Token is used to uniquely identify a
DHCPv6 Client network interface.
Lease: This is the address lifetime for a single address provided to
a DHCPv6 Client.
Expired Lease: An Expired Lease is one where the Lease duration of an
address has ended or because it has been mandated by a DHCPv6 Server
to a DHCPv6 Client.
Expires September 1995 [Page 3]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
3. DHCPv6 Protocol Design Model
3.1 DHCPv6 Protocol Request/Response Model
DHCPv6 uses a message type to define whether the packet orginated
from a DHCPv6 Server or Client, and a request message code to define
the operation requested, and a message response to define either a
response to a request or a confirmation/rejection to a response.
The request/response model is as follows:
1. Request (Client)
2. Response with configuration data (Server).
3. Confirmation Response with accept or reject (Client).
4. Confirmation Response for accept (Server).
The time out period for a DHCPv6 Host to wait for a response is
implementation defined. When a DHCPv6 Host times out waiting for a
response to a packet sent, the Host should not commit any state based
on the content of the packet sent. It is implementation defined if
the packet is retransmitted.
A DHCPv6 packet will only contain one address and one name, depending
on the message type, request, and response codes in a packet.
Because IPv6 supports multiple addresses per interface the DHCPv6
Server may also inform the DHCPv6 Client that there are multiple
addresses available for its use. This may be conveyed to the DHCPv6
Client in the Number of Address Fields provided in a response packet
by the DHCPv6 Server.
Multiple addresses and names may be specified as an extended
configuration option [IPv6-DHCP-OPTIONS]. A design objective of
DHCPv6 is to avoid fragmentation in IPv6, when possible. If the
DHCPv6 packet exceeds 576 octets then UDP must perform Path MTU
Discovery [PMTU]. The support of multiple names and addresses can be
a configuration option in DHCPv6.
If the DHCPv6 Host cannot match up any of the specified parameters,
as discussed in section 5 DHCPv6 Client/Server Processing, in this
protocol specification the packet should be silently discarded.
3.2 DHCPv6 Leased Address Model
A DHCPv6 address returned to a DHCPv6 Client has a Lease time. A
design objective of DHCPv6 is to support Dynamic Readdressing. To
accomplish this objective, addresses must be able to be reclaimed by
a network site. Hence, all addresses must be Leased in DHCPv6.
The DHCPv6 Client has the responsibility to renew a Lease for an
address that is about to expire or request a new address with a Lease
time.
In the case where it is necessary to Expire a Lease because of a
mandate in an organizations site, the DHCPv6 Server may send a Lease
Expires September 1995 [Page 4]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
Expired message with a grace period to a DHCPv6 Client. This will be
an asynchronous operation by the DHCPv6 Server to the DHCPv6 Client,
and the only case where the DHCPv6 request/response model is not used
in the protocol.
When a DHCPv6 Clients address for a network interface Lease expires,
it may attempt to complete all oustanding network connections using
that address, but must not use that address for new network
connections.
3.3 DHCPv6 DNS Host Name Autoregistration Model
DHCPv6 supports the autoregistration of DNS Host names and providing
DNS Host Names with addresses for DHCPv6 Clients. Autoregistration
is supported by fields in DHCPv6, which the DHCPv6 Client may provide
to the DHCPv6 Server in a request. In addition a DHCPv6 Server may
provide a DNS Host Name with an IPv6 address to a DHCPv6 Client in a
response.
DHCPv6 only specifies the parameters and action to be taken, and not
the actual protocol or primitives to interact with DNS. The
functions that the DHCPv6 Server uses to interact with the DNS to
provide autoregistration is defined in Dynamic Updates to DNS [IPv6-
DYN-UPD].
This is not a Fully Qualified Domain Name (FQDN) but only the local-
part label and then only the Host Name [RFC-1034&1035]. It is
assumed the DHCPv6 Server implementation knows or can determine what
the domain name part is for any IPv6 subnet prefix for which it is
providing an address. If a DHCPv6 Client wants to know its domain
name then it will have to request this as specified in the DHCPv6
Options Specification [IPv6-DHCP-OPTIONS].
3.4 DHCPv6 Client/Server Model
DHCPv6 supports a Transaction ID to uniquely identify a set of
request/response messages between DHCPv6 Clients and Servers.
DHCPv6 supports an Interface Token to uniquely identify a network
interface on a DHCPv6 Client.
DHCPv6 can support an extensible set of options as defined by a
Configuration Type. These options are specified in a DHCPv6 Options
specification [IPv6-DHCP-OPTIONS].
The DHCPv6 Options provide a Configuration Type which defines the
option requested and then returned. A Next Type field is provided
which can be used by an application to know if there is more than one
option. If the Next Type field is NULL then this is the last option
present. The Length field provides the length of the data present
for that option. The Variable Configuration Data is the data to
provide that option.
DHCPv6 does not specify whether the DHCPv6 Server Configuration Data
provided to DHCPv6 Clients is synchronous across the sites network
information database (e.g. DNS), whether the DHCPv6 Server
Expires September 1995 [Page 5]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
Configuration Data is duplicated across DHCPv6 Servers, or how the
DHCPv6 Configuration Data is pre-configured on a DHCPv6 Server.
DHCPv6 does not specify conditions or results when multiple DHCPv6
Servers are located on an IPv6 subnet. The DHCPv6 Client may respond
to DHCPv6 Servers it does not want to communicate with by sending a
REJECT_PACKET confirmation response to a DHCPv6 Server.
DHCPv6 does not specify a DHCPv6 Server-to-Server protocol.
Expires September 1995 [Page 6]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
4. DHCPv6 Protocol Format
DHCPv6 Data Packet
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Type | Msg Request |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Msg Response | Addrs Avail |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transaction ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Lease Time |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface Token |
| (8 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 Address |
| (16 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Host Name |
| (64 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server IPv6 Address |
| (16 Octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Config Type | Next Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Variable Configuration Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In the field definitions below bit position 0 is the high-order bit in
the sequence of Octets for each field.
Msg Type : 1 Octet
The field defines the operation to be performed by the packet.
Bit 0 = ON: Server Message Operation
Bit 1 = ON: Client Message Operation
Bit 2-7 RESERVED
Msg Request : 3 Octets
Bit 0 = ON: ADDRESS_REQUEST
Bit 1 = ON: NAME_REQUEST
Bit 2 = ON: CONFIG_REQUEST
Bit 3 = ON: ADDRESS_SUPPLIED
Bit 4 = ON: LEASE_EXPIRED
Bit 5-24 RESERVED
Expires September 1995 [Page 7]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
Msg Response : 3 Octets
Bit 0 = ON: ADDRESS_RETURNED
Bit 1 = ON: ADDRESS_ACCEPTED
Bit 2 = ON: ADDRESS_REJECTED
Bit 3 = ON: NAME_ACCEPTED
Bit 4 = ON: NAME_RETURNED
Bit 5 = ON: NAME_REJECTED
Bit 6 = ON: SERVER_ADDRESS
Bit 7 = ON: CONFIG_ACCEPTED
Bit 8 = ON: CONFIG_RETURNED
Bit 9 = ON: CONFIG_REJECTED
Bit 10 = ON: LEASE_ACCEPTED
Bit 11 = ON: LEASE_REJECTED
Bit 12 = ON: CONFIRM_PACKET
Bit 13 = ON: REJECT_PACKET
Bit 14-24 RESERVED
Addrs Avail : 1 Octet
Number of IPv6 addresses available to the DHCPv6 Client, that can be
provided by the DHCPv6 Server. Integer Number.
Transaction ID : 4 Octets
Identifies request/response messages and is a 32bit random
generated number by the DHCPv6 Client. Integer Number.
Lease Time : 4 Octets
This field is used to provide a Lease time for an address and a
renewal time period for an address that is being reclaimed.
Integer Number. Absolute time in seconds.
Interface Token : 8 Octets
This field is determined by the DHCPv6 Client and is a 64bit random
generated number. An Interface Token is defined by the DHCPv6 Client for
each network interface it configures on its Host. Integer Number.
IPv6 Address : 16 Octets
DHCPv6 Client IPv6 Address.
Host Name : 64 Octets
DHCPv6 Host Name. This is not the Fully Qualified Domain Name
(FQDN).
Server IPv6 Address : 16 Octets
DHCPv6 Server IPv6 Address.
Configuration Type : 1 Octet
This field defines the Configuration Data option in the packet.
The configuation types are specified in DHCPv6 Options
[IPv6-DHCP-OPTIONS].
Configuration Next Type : 1 Octet
This field defines the Configuration Data Type that follows this
Configuration Data if multiple configuration requests are present.
A NULL value means that this is the only or last Configuration Data
Type provided.
Configuration Data Length : 2 Octets
This field is the Length of the Configuration Data.
Expires September 1995 [Page 8]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
Variable Configuration Data : 452 Octets
This is a variable length field where configuration data will be
supplied as options for DHCPv6 protocol.
If the Configuration Data provided causes the DHCPv6 packet to exceed
576 Octets then the implementation should verify through Path MTU
Discovery [IPv6-SPEC&ICMP,PMTU] that the packet will be able to reach its
destination without Fragmentation, or use the IPv6 Fragmentation Extended
Header [IPv6-SPEC].
5. DHCPv6 Client/Server Processing
5.1 DHCPv6 Client Transmission
The DHCPv6 Client will set Client Msg Type to ON to transmit to
DHCPv6 Servers. UDP DHCPv6 Server Port (TBD) must be used to build
the sending packet in an implementation. A DHCPv6 Client may provide
multiple requests in a request packet and multiple responses in a
response packet, to a DHCPv6 Server in one packet.
If the DHCPv6 Client knows its IPv6 address it will be put in the
source address field of the IPv6 Header. Otherwise the DHCPv6
Clients link-local address [IPv6-ADDR] is used as the source address
field in the IPv6 Header.
If the DHCPv6 Client knows the address of a DHCPv6 Server it will put
that address in the destination field of the IPv6 Header. Otherwise
a well known IPv6 multicast address using intra-link scope [IPv6-
ADDR] is used as the destination address field in the IPv6 Header
[This multicast address will have to be supplied by IANA for DHCPv6].
5.2 DHCPv6 Server Transmission
The DHCPv6 Server will set Server Msg Type ON to transmit to DHCPv6
Clients. UDP DHCPv6 Client Port (TBD) must be used to build the
sending packet in an implementation. A DHCPv6 Server may provide
multiple responses to a DHCPv6 Client in one packet.
The DHCPv6 Server will use the source address of the IPv6 Header from
the DHCPv6 Client as the destination address in the DHCPv6 Server
IPv6 Header address. The DHCPv6 Server IPv6 Header source addresses
will be the IPv6 address of the DHCPv6 Server responding.
5.3 DHCPv6 Client Requests
Msg Request field:
If ADDRESS_REQUEST is set, then a request is being made for an IPv6
address and Lease. If the Lease field does not equal zero then the
DHCPv6 Client is supplying a Lease time to the DHCPv6 Server. The DHCPv6
Client may also set ADDRESS_SUPPLIED and provide an IPv6 address to the
DHCPv6 Server for verification.
Expires September 1995 [Page 9]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
A DHCPv6 Client must send an ADDRESS_REQUEST to the DHCPv6 Server
to renew its Lease before it expires. The DHCPv6 Client may request
that the same address be used again by providing an IPv6 address and
having ADDRESS_SUPPLIED set in the request. If the DHCPv6 Clients
Lease on an address expires, then the DHCPv6 Server will expire the
Lease for that address.
If NAME_REQUEST is set, then a request is being made for a DNS Host Name.
supplied by the DHCPv6 Client.
If CONFIG_REQUEST is set, then a request is being made for an IPv6
Configuration Data return from the DHCPv6 Server.
Msg Response field: must be NULL.
Addrs Avail field: must be NULL.
Transaction ID field: must contain a random number generated Integer
determined by the DHCPv6 Client for this request packet.
Lease Time field: may contain a Lease time requested by the DHCPv6
Client or must be NULL.
Interface Token field: must contain a random number generated Integer
to identify addresses associated with a DHCPv6 Clients network
interface.
IPv6 Address field: must contain an IPv6 Address if ADDRESS_SUPPLIED
or NAME_REQUEST is set, otherwise NULL.
Host Name field: must contain a Host Name if NAME_REQUEST is set,
otherwise NULL.
Server IPv6 Address field: must be NULL.
Configuration Type field: must contain a valid Configuration Type as
defined in the DHCPv6 Options specification [IPv6-DHCP-OPTIONS], if
CONFIG_REQUEST is set, otherwise the Configuration fields are not
present in the packet.
Configuration Next Type field: If CONFIG_REQUEST set, and there is
more than one, then the value of the next configuration type should
be put into this field, otherwise NULL.
Configuration Data Length field: NULL.
Variable Configuration Data field: Not present in the packet.
5.4 DHCPv6 Client Responses
The Transaction ID from the DHCPv6 Server response must match one of
the DHCPv6 Clients Transaction IDs from a previous request.
Msg Request field: must be NULL.
Msg Response field:
Expires September 1995 [Page 10]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
If ADDRESS_ACCEPTED is set, the DHCPv6 Client is informing the DHCPv6
Server that it has received the address returned.
If CONFIG_ACCEPTED is set, the DHCPv6 Client is informing the DHCPv6
Server that it has received the Configuration Data returned.
If NAME_ACCEPT is set, the DHCPv6 Client is informing the DHCPv6
Server that it received the NAME_RETURNED returned, when the DHCPv6
Client supplied a Host Name with NAME_REQUEST set.
If REJECT_PACKET is set, the DHCPv6 Client is rejecting a response
from a DHCPv6 Server.
Addrs Avail field: must be NULL.
Transaction ID field: must contain a random number generated Integer
matching the DHCPv6 Server request or response.
Lease Time field: must be NULL.
Interface Token field: must contain a random number generated Integer
to identify addresses associated with a DHCPv6 Clients network
interface.
IPv6 Address field: must be NULL.
Host Name field: must be NULL.
Server IPv6 Address field: must be NULL.
Configuration Data Fields not present in the packet.
5.5 DHCPv6 Server Responses
The Transaction ID from a DHCPv6 Servers response must match one of
the DHCPv6 Clients Transaction IDs from a previous request.
Msg Request field: must be NULL.
Msg Response field:
If ADDRESS_RETURNED is set, the DHCPv6 Server is providing the DHCPv6
Client with an IPv6 Address.
If ADDRESS_ACCEPTED is set, the DHCPv6 Server has accepted the address
supplied by the DHCPv6 Client.
If ADDRESS_REJECTED is set, the DHCPv6 Server is not accepting the
address provided by the DHCPv6 Client.
Only one of the above settings must be present in a response to a DHCPv6
Client request. The IPv6 address provided will either be the one
presented by the DHCPv6 Client or an address provided by the DHCPv6
Server when ADDRESS_RETURNED is set.
If NAME_RETURNED is set, the DHCPv6 Server is providing a Host Name with
the address returned to the DHCPv6 Client either in response to a DHCPv6
Expires September 1995 [Page 11]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
Client NAME_REQUEST or because it is implementation defined to provide
Host Names with ADDRESS_RETURNED set.
If NAME_REJECTED is set, the DHCPv6 Server is informing the DHCPv6
Client that the NAME_REQUEST was rejected by DNS. The DHCPv6 Server
must also supply an address in the IPv6 Address field.
If CONFIG_RETURNED is set, the DHCPv6 Server is providing the
Configuration Data requested.
If CONFIG_REJECTED is set, the DHCPv6 Server is informing the DHCPv6
Client that the Configuration Data requested is not supported.
If LEASE_ACCEPTED is set, the DHCPv6 Server is informing the DHCPv6
Client that the Lease presented has been accepted. The Lease Time field
will contain the Lease requested by the DHCPv6 Client.
If LEASE_REJECTED is set, the DHCPv6 Server is rejecting the Lease Time
provided by the DHCPv6 Client and will return a Lease time specified
by the DHCPv6 Server.
If SERVER_ADDRESS is set, the DHCPv6 Server is returning its address
in the response. The DHCPv6 Server will do this when the destination
address in the IPv6 Header is an intra-link Multicast address, or has
a network prefix subnet value for which the DHCPv6 Server is
not a member.
If CONFIRM_PACKET is set, the DHCPv6 Server is informing the DHCPv6
Client it has received a response to the DHCPv6 Server response to the
DHCPv6 Clients initial request. This will be the only msg response
code set by the DHCPv6 Server in this response.
Addrs Avail field: If ADDRESS_RETURNED is set, the DHCPv6 Server is
informing the DHCPv6 Client that it has an integer number of
addresses available for the DHCPv6 Client less the address being
provided. When the DHCPv6 Client responds to this response with
ADDRESS_ACCEPTED the DHCPv6 Server must decrement the number of
addresses available for the DHCPv6 Client. If ADDRESS_ACCEPTED is
set, the DHCPv6 Server is informing the DHCPv6 Client that it has a
number of addresses available that can be used by the DHCPv6 Client.
Otherwise the Addrs Avail field is NULL.
Transaction ID field: must contain a random number generated Integer
determined by the DHCPv6 Clients request packet.
Lease Time field: must contain a Lease Time with any returned
addresses that were requested, otherwise NULL.
Interface Token field: must contain a random number generated Integer
to identify addresses associated with a DHCPv6 Clients network
interface.
IPv6 Address field: must contain an IPv6 Address.
Host Name field: must contain a Host Name if NAME_RETURNED is set
otherwise NULL.
Server IPv6 Address field: must contain an IPv6 address if
Expires September 1995 [Page 12]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
SERVER_ADDRESS is set, otherwise NULL.
Configuration Type field: must contain a valid Configuration Type as
defined in the DHCPv6 Options [IPv6-DHCP-OPTIONS] if CONFIG_RETURN or
CONFIG_REJECTED is set, otherwise the Configuration fields are not
present in the packet.
Configuration Next Type field: If CONFIG_RETURNED or CONFIG_REJECTED
is set, and if there is more than one Congfiguration Type present,
the value of the next configuration type should be put into this
field, otherwise NULL.
Configuration Data Length field: If CONFIG_RETURNED is set, then this
is the length of the Configuration Data present. If CONFIG_REJECTED
is set, then the DHCPv6 Server will set length to zero.
Variable Configuration Data field: Contains Configuration Data only
if CONFIG_RETURNED is set, otherwise there is no Configuration Data
present in the packet.
5.6 DHCPv6 Server Lease Expiration
The DHCPv6 may send an asynchronous LEASE_EXPIRED message with a
grace period if an organizations network site needs to reclaim
addresses when their Lease has not expired.
Msg Request field:
LEASE_EXPIRED is set.
Msg Response field: must be NULL.
Addrs Avail field: must be NULL.
Transaction ID field: NULL.
Lease Time field: must contain a grace period for the DHCPv6 Client
to renew a lease for an address.
Interface Token field: must contain a random number generated Integer
for the DHCPv6 Client IPv6 address.
IPv6 Address field: must contain an IPv6 Address being used for an
Interface Token by a DHCPv6 Client.
Host Name field: must be NULL.
IPv6 Server Address field: must be NULL.
Configuration fields: not present in the packet.
6. DHCPv6 Relay-Agent Processing
When a DHCPv6 Relay-Agent hears a request from a DHCPv6 Client it
should forward that request to a DHCPv6 Server as a DHCPv6 Client Msg
Type.
Expires September 1995 [Page 13]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
The DHCPv6 Relay-Agent upon receiving a response from the DHCPv6
Server should forward that response to the DHCPv6 Client.
When the DHCPv6 Relay-Agent forwards the request to the DHCPv6 Server
it puts the DHCPv6 Relay-Agent's IPv6 address in the source field of
the IPv6 Header.
Expires September 1995 [Page 14]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
Acknowledgements
Brian Carpenter, Alex Conta, Jack McCann, Ralph Droms for providing
input to the evolution of DHCPv6.
References
[IPv6-ADDR]
R. Hinden, Editor, "IP Version 6 Addressing Architecture"
Internet Draft, March 1995
<draft-ietf-ipngwg-ipv6-addr-arch-00.txt>
Y. Rekhter, "An IPv6 Global Unicast Address Format"
Internet Draft, March 1995
<draft-ietf-ipngwg-address-format-01.txt>
[IPv6-SPEC]
S. Deering and R. Hinden, Editors, "Internet Protocol Version 6
[IPv6] Specification" Internet Draft, March 1995
<draft-ietf-ipngwg-ipv6-spec-01.txt>
[IPv6-ICMP]
A. Conta, S. Deering "ICMPv6 for the Internet Protocol
Version 6 [IPv6]" Internet Draft, March 1995
<draft-ietf-ipngwg-icmp-02.txt>
[PMTU]
J. Mogul, S. Deering "Path MTU Discovery"
RFC 1191, 11/16/90
[IPv6-ADDRCONF]
S. Thomson, "IPv6 Stateless Address Configuration"
Internet Draft, March 1995 <draft-ietf-addrconf-ipv6-auto-01.txt>
W. A. Simpson "IPv6 Neighbor Discovery - Processing"
Internet Draft, November 1994
<draft-simpson-ipv6-discov-process-01.txt>
[RFC-1034]
P. Mockapetris, "Domain Names - implementation and specification"
STD-13, 11/01/87
[RFC-1035]
P. Mockapetris, "Domain Names - concepts and facilities"
STD-13, 11/01/87
[DYN-DNS-UPD]
S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates in the Domain
Name System (DNS)" Internet Draft, March 1995
<draft-ietf-dnsind-dynDNS-01.txt>
Expires September 1995 [Page 15]
INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995
[IPv6-DHCP-OPTIONS]
<TBD>
[RFC-768]
J. Postel, "User Datagram Protocol"
STD-6, 08/28/80.
Authors' Addresses
Jim Bound
Digital Equipment Corporation
110 Spitbrook Road, ZKO3-3/U14
Nashua, NH 03062
Phone: (603) 881-0400
Email: bound@zk3.dec.com
Yakov Rekhter
T.J. Watson Research Center, IBM Corporation
P.O. Box 570
Yorktown Heights, NY 10598
Phone: (914) 784-7361
Email: yakov@watson.ibm.com
Sue Thomson
Bellcore
445 South Street
Morristown, NJ 07960
Phone: (201) 829-4514
Email: set@thumper.bellcore.com
Expires September 1995 [Page 16]
