idnits 2.17.1 draft-ietf-dhc-dhcpv6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 16 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 16 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 25 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([IPv6-ADDR], [DYN-DNS-UPD]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IPv6' is defined on line 679, but no explicit reference was found in the text == Unused Reference: 'IPv6-ICMP' is defined on line 682, but no explicit reference was found in the text == Unused Reference: 'RFC-1034' is defined on line 698, but no explicit reference was found in the text == Unused Reference: 'RFC-1035' is defined on line 702, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-ADDR' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-SPEC' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-ICMP' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-ADDRCONF' -- Possible downref: Non-RFC (?) normative reference: ref. 'DYN-DNS-UPD' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-DHCP-OPTIONS' Summary: 11 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT J. Bound 2 DHC Working Group Digital Equipment Corp 3 March 1995 Y. Rekhter 4 T.J. Watson Research Center IBM Corp 5 Sue Thomson 6 Bellcore 8 Dynamic Host Configuration Protocol for IPv6 10 draft-ietf-dhc-dhcpv6-01.txt 12 Status of this Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as ``work in progress.'' 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Discussion for this draft will take place on host- 31 conf@sol.cs.bucknell.edu. 33 Abstract 35 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6): provides a 36 mechanism to autoconfigure inter-link Host IPv6 addresseses [IPv6- 37 ADDR], provides parameters to autoregister [DYN-DNS-UPD] and receive 38 Domain Name System (DNS) [RFC-1034&1035] Host names, and provides a 39 mechanism to specify additional configuration options in the 40 protocol. 42 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 44 Table of Contents: 46 1. Introduction................................................3 47 2. Terminology.................................................3 48 3. DHCPv6 Protocol Design Model................................4 49 3.1 DHCPv6 Protocol Request/Response Model......................4 50 3.2 DHCPv6 Leased Address Model.................................4 51 3.3 DHCPv6 DNS Host Name Autoregistration Model.................5 52 3.4 DHCPv6 Client/Server Model..................................5 53 4. DHCPv6 Protocol Format......................................7 54 5. DHCPv6 Client/Server Processing.............................9 55 5.1 DHCPv6 Client Transmission..................................9 56 5.2 DHCPv6 Server Transmission..................................9 57 5.3 DHCPv6 Client Requests......................................9 58 5.4 DHCPv6 Client Responses....................................10 59 5.5 DHCPv6 Server Responses....................................11 60 5.6 DHCPv6 Server Lease Expiration.............................13 61 6. DHCPv6 Relay-Agent Processing..............................13 62 Acknowledgements...............................................15 63 References.....................................................15 64 Authors' Addresses.............................................16 66 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 68 1. Introduction 70 The Dynamic Host Configuration Protocol for IPv6 (DHCPv6): provides a 71 mechanism to autoconfigure inter-link Host IPv6 addresseses [IPv6- 72 ADDR], provides parameters to autoregister [DYN-DNS-UPD] and receive 73 Domain Name System (DNS) [RFC-1034&1035] Host names, and provides a 74 mechanism to specify additional configuration options in the 75 protocol. 77 DHCPv6 is an Internet application protocol that uses a Client/Server 78 model to communicate between Hosts. DHCPv6 executes over the UDP 79 [RFC-768] transport protocol, and the IPv6 Internet Protocol Version 80 6 [IPv6-SPEC]. DHCPv6 will need to request Server and Client Ports 81 from IANA. 83 DHCPv6 is the IPv6 specification for a statefull implementation of 84 address autoconfiguration as defined in IPv6 Stateless Address 85 Configuration [IPv6-ADDRCONF]. 87 2. Terminology 89 Configuration Data: Configuration Data is information a Host can use 90 to configure a Host on a network so that the Host can interoperate 91 with other Hosts on a network. 93 DHCPv6 Client: A DHCPv6 Client is a Host that initiates requests on a 94 network to obtain Configuration Data from a DHCPv6 server. 96 DHCPv6 Server: A DHCPv6 Server is a Host that responds to requests 97 from DHCPv6 clients to provide Configuration Data. 99 DHCPv6 Relay-Agent: A DHCPv6 Relay-Agent is a DHCPv6 Server that 100 listens on the network for DHCPv6 Clients requesting Configuration 101 Data, and then relays the request to a DHCPv6 Server and the reply 102 back to the DHCPv6 Client. 104 Transaction ID - This is used to uniquely identify a set of DHCPv6 105 request/response messages between DHCPv6 Servers and Clients. The 106 Transaction ID is generated by the DHCPv6 Client requests. 108 Interface-Token: An Interface Token is used to uniquely identify a 109 DHCPv6 Client network interface. 111 Lease: This is the address lifetime for a single address provided to 112 a DHCPv6 Client. 114 Expired Lease: An Expired Lease is one where the Lease duration of an 115 address has ended or because it has been mandated by a DHCPv6 Server 116 to a DHCPv6 Client. 118 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 120 3. DHCPv6 Protocol Design Model 122 3.1 DHCPv6 Protocol Request/Response Model 124 DHCPv6 uses a message type to define whether the packet orginated 125 from a DHCPv6 Server or Client, and a request message code to define 126 the operation requested, and a message response to define either a 127 response to a request or a confirmation/rejection to a response. 129 The request/response model is as follows: 131 1. Request (Client) 132 2. Response with configuration data (Server). 133 3. Confirmation Response with accept or reject (Client). 134 4. Confirmation Response for accept (Server). 136 The time out period for a DHCPv6 Host to wait for a response is 137 implementation defined. When a DHCPv6 Host times out waiting for a 138 response to a packet sent, the Host should not commit any state based 139 on the content of the packet sent. It is implementation defined if 140 the packet is retransmitted. 142 A DHCPv6 packet will only contain one address and one name, depending 143 on the message type, request, and response codes in a packet. 144 Because IPv6 supports multiple addresses per interface the DHCPv6 145 Server may also inform the DHCPv6 Client that there are multiple 146 addresses available for its use. This may be conveyed to the DHCPv6 147 Client in the Number of Address Fields provided in a response packet 148 by the DHCPv6 Server. 150 Multiple addresses and names may be specified as an extended 151 configuration option [IPv6-DHCP-OPTIONS]. A design objective of 152 DHCPv6 is to avoid fragmentation in IPv6, when possible. If the 153 DHCPv6 packet exceeds 576 octets then UDP must perform Path MTU 154 Discovery [PMTU]. The support of multiple names and addresses can be 155 a configuration option in DHCPv6. 157 If the DHCPv6 Host cannot match up any of the specified parameters, 158 as discussed in section 5 DHCPv6 Client/Server Processing, in this 159 protocol specification the packet should be silently discarded. 161 3.2 DHCPv6 Leased Address Model 163 A DHCPv6 address returned to a DHCPv6 Client has a Lease time. A 164 design objective of DHCPv6 is to support Dynamic Readdressing. To 165 accomplish this objective, addresses must be able to be reclaimed by 166 a network site. Hence, all addresses must be Leased in DHCPv6. 168 The DHCPv6 Client has the responsibility to renew a Lease for an 169 address that is about to expire or request a new address with a Lease 170 time. 172 In the case where it is necessary to Expire a Lease because of a 173 mandate in an organizations site, the DHCPv6 Server may send a Lease 175 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 177 Expired message with a grace period to a DHCPv6 Client. This will be 178 an asynchronous operation by the DHCPv6 Server to the DHCPv6 Client, 179 and the only case where the DHCPv6 request/response model is not used 180 in the protocol. 182 When a DHCPv6 Clients address for a network interface Lease expires, 183 it may attempt to complete all oustanding network connections using 184 that address, but must not use that address for new network 185 connections. 187 3.3 DHCPv6 DNS Host Name Autoregistration Model 189 DHCPv6 supports the autoregistration of DNS Host names and providing 190 DNS Host Names with addresses for DHCPv6 Clients. Autoregistration 191 is supported by fields in DHCPv6, which the DHCPv6 Client may provide 192 to the DHCPv6 Server in a request. In addition a DHCPv6 Server may 193 provide a DNS Host Name with an IPv6 address to a DHCPv6 Client in a 194 response. 196 DHCPv6 only specifies the parameters and action to be taken, and not 197 the actual protocol or primitives to interact with DNS. The 198 functions that the DHCPv6 Server uses to interact with the DNS to 199 provide autoregistration is defined in Dynamic Updates to DNS [IPv6- 200 DYN-UPD]. 202 This is not a Fully Qualified Domain Name (FQDN) but only the local- 203 part label and then only the Host Name [RFC-1034&1035]. It is 204 assumed the DHCPv6 Server implementation knows or can determine what 205 the domain name part is for any IPv6 subnet prefix for which it is 206 providing an address. If a DHCPv6 Client wants to know its domain 207 name then it will have to request this as specified in the DHCPv6 208 Options Specification [IPv6-DHCP-OPTIONS]. 210 3.4 DHCPv6 Client/Server Model 212 DHCPv6 supports a Transaction ID to uniquely identify a set of 213 request/response messages between DHCPv6 Clients and Servers. 215 DHCPv6 supports an Interface Token to uniquely identify a network 216 interface on a DHCPv6 Client. 218 DHCPv6 can support an extensible set of options as defined by a 219 Configuration Type. These options are specified in a DHCPv6 Options 220 specification [IPv6-DHCP-OPTIONS]. 222 The DHCPv6 Options provide a Configuration Type which defines the 223 option requested and then returned. A Next Type field is provided 224 which can be used by an application to know if there is more than one 225 option. If the Next Type field is NULL then this is the last option 226 present. The Length field provides the length of the data present 227 for that option. The Variable Configuration Data is the data to 228 provide that option. 230 DHCPv6 does not specify whether the DHCPv6 Server Configuration Data 231 provided to DHCPv6 Clients is synchronous across the sites network 232 information database (e.g. DNS), whether the DHCPv6 Server 234 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 236 Configuration Data is duplicated across DHCPv6 Servers, or how the 237 DHCPv6 Configuration Data is pre-configured on a DHCPv6 Server. 239 DHCPv6 does not specify conditions or results when multiple DHCPv6 240 Servers are located on an IPv6 subnet. The DHCPv6 Client may respond 241 to DHCPv6 Servers it does not want to communicate with by sending a 242 REJECT_PACKET confirmation response to a DHCPv6 Server. 244 DHCPv6 does not specify a DHCPv6 Server-to-Server protocol. 246 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 248 4. DHCPv6 Protocol Format 250 DHCPv6 Data Packet 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Msg Type | Msg Request | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | Msg Response | Addrs Avail | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Transaction ID | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Lease Time | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Interface Token | 262 | (8 Octets) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | IPv6 Address | 265 | (16 Octets) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | Host Name | 268 | (64 Octets) | 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | Server IPv6 Address | 271 | (16 Octets) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Config Type | Next Type | Length | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Variable Configuration Data | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 In the field definitions below bit position 0 is the high-order bit in 279 the sequence of Octets for each field. 281 Msg Type : 1 Octet 282 The field defines the operation to be performed by the packet. 284 Bit 0 = ON: Server Message Operation 285 Bit 1 = ON: Client Message Operation 286 Bit 2-7 RESERVED 288 Msg Request : 3 Octets 290 Bit 0 = ON: ADDRESS_REQUEST 291 Bit 1 = ON: NAME_REQUEST 292 Bit 2 = ON: CONFIG_REQUEST 293 Bit 3 = ON: ADDRESS_SUPPLIED 294 Bit 4 = ON: LEASE_EXPIRED 295 Bit 5-24 RESERVED 297 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 299 Msg Response : 3 Octets 300 Bit 0 = ON: ADDRESS_RETURNED 301 Bit 1 = ON: ADDRESS_ACCEPTED 302 Bit 2 = ON: ADDRESS_REJECTED 303 Bit 3 = ON: NAME_ACCEPTED 304 Bit 4 = ON: NAME_RETURNED 305 Bit 5 = ON: NAME_REJECTED 306 Bit 6 = ON: SERVER_ADDRESS 307 Bit 7 = ON: CONFIG_ACCEPTED 308 Bit 8 = ON: CONFIG_RETURNED 309 Bit 9 = ON: CONFIG_REJECTED 310 Bit 10 = ON: LEASE_ACCEPTED 311 Bit 11 = ON: LEASE_REJECTED 312 Bit 12 = ON: CONFIRM_PACKET 313 Bit 13 = ON: REJECT_PACKET 314 Bit 14-24 RESERVED 316 Addrs Avail : 1 Octet 317 Number of IPv6 addresses available to the DHCPv6 Client, that can be 318 provided by the DHCPv6 Server. Integer Number. 320 Transaction ID : 4 Octets 321 Identifies request/response messages and is a 32bit random 322 generated number by the DHCPv6 Client. Integer Number. 324 Lease Time : 4 Octets 325 This field is used to provide a Lease time for an address and a 326 renewal time period for an address that is being reclaimed. 327 Integer Number. Absolute time in seconds. 329 Interface Token : 8 Octets 330 This field is determined by the DHCPv6 Client and is a 64bit random 331 generated number. An Interface Token is defined by the DHCPv6 Client for 332 each network interface it configures on its Host. Integer Number. 334 IPv6 Address : 16 Octets 335 DHCPv6 Client IPv6 Address. 337 Host Name : 64 Octets 338 DHCPv6 Host Name. This is not the Fully Qualified Domain Name 339 (FQDN). 341 Server IPv6 Address : 16 Octets 342 DHCPv6 Server IPv6 Address. 344 Configuration Type : 1 Octet 345 This field defines the Configuration Data option in the packet. 346 The configuation types are specified in DHCPv6 Options 347 [IPv6-DHCP-OPTIONS]. 349 Configuration Next Type : 1 Octet 350 This field defines the Configuration Data Type that follows this 351 Configuration Data if multiple configuration requests are present. 352 A NULL value means that this is the only or last Configuration Data 353 Type provided. 355 Configuration Data Length : 2 Octets 356 This field is the Length of the Configuration Data. 358 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 360 Variable Configuration Data : 452 Octets 361 This is a variable length field where configuration data will be 362 supplied as options for DHCPv6 protocol. 364 If the Configuration Data provided causes the DHCPv6 packet to exceed 365 576 Octets then the implementation should verify through Path MTU 366 Discovery [IPv6-SPEC&ICMP,PMTU] that the packet will be able to reach its 367 destination without Fragmentation, or use the IPv6 Fragmentation Extended 368 Header [IPv6-SPEC]. 370 5. DHCPv6 Client/Server Processing 372 5.1 DHCPv6 Client Transmission 374 The DHCPv6 Client will set Client Msg Type to ON to transmit to 375 DHCPv6 Servers. UDP DHCPv6 Server Port (TBD) must be used to build 376 the sending packet in an implementation. A DHCPv6 Client may provide 377 multiple requests in a request packet and multiple responses in a 378 response packet, to a DHCPv6 Server in one packet. 380 If the DHCPv6 Client knows its IPv6 address it will be put in the 381 source address field of the IPv6 Header. Otherwise the DHCPv6 382 Clients link-local address [IPv6-ADDR] is used as the source address 383 field in the IPv6 Header. 385 If the DHCPv6 Client knows the address of a DHCPv6 Server it will put 386 that address in the destination field of the IPv6 Header. Otherwise 387 a well known IPv6 multicast address using intra-link scope [IPv6- 388 ADDR] is used as the destination address field in the IPv6 Header 389 [This multicast address will have to be supplied by IANA for DHCPv6]. 391 5.2 DHCPv6 Server Transmission 393 The DHCPv6 Server will set Server Msg Type ON to transmit to DHCPv6 394 Clients. UDP DHCPv6 Client Port (TBD) must be used to build the 395 sending packet in an implementation. A DHCPv6 Server may provide 396 multiple responses to a DHCPv6 Client in one packet. 398 The DHCPv6 Server will use the source address of the IPv6 Header from 399 the DHCPv6 Client as the destination address in the DHCPv6 Server 400 IPv6 Header address. The DHCPv6 Server IPv6 Header source addresses 401 will be the IPv6 address of the DHCPv6 Server responding. 403 5.3 DHCPv6 Client Requests 405 Msg Request field: 407 If ADDRESS_REQUEST is set, then a request is being made for an IPv6 408 address and Lease. If the Lease field does not equal zero then the 409 DHCPv6 Client is supplying a Lease time to the DHCPv6 Server. The DHCPv6 410 Client may also set ADDRESS_SUPPLIED and provide an IPv6 address to the 411 DHCPv6 Server for verification. 413 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 415 A DHCPv6 Client must send an ADDRESS_REQUEST to the DHCPv6 Server 416 to renew its Lease before it expires. The DHCPv6 Client may request 417 that the same address be used again by providing an IPv6 address and 418 having ADDRESS_SUPPLIED set in the request. If the DHCPv6 Clients 419 Lease on an address expires, then the DHCPv6 Server will expire the 420 Lease for that address. 422 If NAME_REQUEST is set, then a request is being made for a DNS Host Name. 423 supplied by the DHCPv6 Client. 425 If CONFIG_REQUEST is set, then a request is being made for an IPv6 426 Configuration Data return from the DHCPv6 Server. 428 Msg Response field: must be NULL. 430 Addrs Avail field: must be NULL. 432 Transaction ID field: must contain a random number generated Integer 433 determined by the DHCPv6 Client for this request packet. 435 Lease Time field: may contain a Lease time requested by the DHCPv6 436 Client or must be NULL. 438 Interface Token field: must contain a random number generated Integer 439 to identify addresses associated with a DHCPv6 Clients network 440 interface. 442 IPv6 Address field: must contain an IPv6 Address if ADDRESS_SUPPLIED 443 or NAME_REQUEST is set, otherwise NULL. 445 Host Name field: must contain a Host Name if NAME_REQUEST is set, 446 otherwise NULL. 448 Server IPv6 Address field: must be NULL. 450 Configuration Type field: must contain a valid Configuration Type as 451 defined in the DHCPv6 Options specification [IPv6-DHCP-OPTIONS], if 452 CONFIG_REQUEST is set, otherwise the Configuration fields are not 453 present in the packet. 455 Configuration Next Type field: If CONFIG_REQUEST set, and there is 456 more than one, then the value of the next configuration type should 457 be put into this field, otherwise NULL. 459 Configuration Data Length field: NULL. 461 Variable Configuration Data field: Not present in the packet. 463 5.4 DHCPv6 Client Responses 465 The Transaction ID from the DHCPv6 Server response must match one of 466 the DHCPv6 Clients Transaction IDs from a previous request. 468 Msg Request field: must be NULL. 470 Msg Response field: 472 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 474 If ADDRESS_ACCEPTED is set, the DHCPv6 Client is informing the DHCPv6 475 Server that it has received the address returned. 477 If CONFIG_ACCEPTED is set, the DHCPv6 Client is informing the DHCPv6 478 Server that it has received the Configuration Data returned. 480 If NAME_ACCEPT is set, the DHCPv6 Client is informing the DHCPv6 481 Server that it received the NAME_RETURNED returned, when the DHCPv6 482 Client supplied a Host Name with NAME_REQUEST set. 484 If REJECT_PACKET is set, the DHCPv6 Client is rejecting a response 485 from a DHCPv6 Server. 487 Addrs Avail field: must be NULL. 489 Transaction ID field: must contain a random number generated Integer 490 matching the DHCPv6 Server request or response. 492 Lease Time field: must be NULL. 494 Interface Token field: must contain a random number generated Integer 495 to identify addresses associated with a DHCPv6 Clients network 496 interface. 498 IPv6 Address field: must be NULL. 500 Host Name field: must be NULL. 502 Server IPv6 Address field: must be NULL. 504 Configuration Data Fields not present in the packet. 506 5.5 DHCPv6 Server Responses 508 The Transaction ID from a DHCPv6 Servers response must match one of 509 the DHCPv6 Clients Transaction IDs from a previous request. 511 Msg Request field: must be NULL. 513 Msg Response field: 515 If ADDRESS_RETURNED is set, the DHCPv6 Server is providing the DHCPv6 516 Client with an IPv6 Address. 518 If ADDRESS_ACCEPTED is set, the DHCPv6 Server has accepted the address 519 supplied by the DHCPv6 Client. 521 If ADDRESS_REJECTED is set, the DHCPv6 Server is not accepting the 522 address provided by the DHCPv6 Client. 524 Only one of the above settings must be present in a response to a DHCPv6 525 Client request. The IPv6 address provided will either be the one 526 presented by the DHCPv6 Client or an address provided by the DHCPv6 527 Server when ADDRESS_RETURNED is set. 529 If NAME_RETURNED is set, the DHCPv6 Server is providing a Host Name with 530 the address returned to the DHCPv6 Client either in response to a DHCPv6 532 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 534 Client NAME_REQUEST or because it is implementation defined to provide 535 Host Names with ADDRESS_RETURNED set. 537 If NAME_REJECTED is set, the DHCPv6 Server is informing the DHCPv6 538 Client that the NAME_REQUEST was rejected by DNS. The DHCPv6 Server 539 must also supply an address in the IPv6 Address field. 541 If CONFIG_RETURNED is set, the DHCPv6 Server is providing the 542 Configuration Data requested. 544 If CONFIG_REJECTED is set, the DHCPv6 Server is informing the DHCPv6 545 Client that the Configuration Data requested is not supported. 547 If LEASE_ACCEPTED is set, the DHCPv6 Server is informing the DHCPv6 548 Client that the Lease presented has been accepted. The Lease Time field 549 will contain the Lease requested by the DHCPv6 Client. 551 If LEASE_REJECTED is set, the DHCPv6 Server is rejecting the Lease Time 552 provided by the DHCPv6 Client and will return a Lease time specified 553 by the DHCPv6 Server. 555 If SERVER_ADDRESS is set, the DHCPv6 Server is returning its address 556 in the response. The DHCPv6 Server will do this when the destination 557 address in the IPv6 Header is an intra-link Multicast address, or has 558 a network prefix subnet value for which the DHCPv6 Server is 559 not a member. 561 If CONFIRM_PACKET is set, the DHCPv6 Server is informing the DHCPv6 562 Client it has received a response to the DHCPv6 Server response to the 563 DHCPv6 Clients initial request. This will be the only msg response 564 code set by the DHCPv6 Server in this response. 566 Addrs Avail field: If ADDRESS_RETURNED is set, the DHCPv6 Server is 567 informing the DHCPv6 Client that it has an integer number of 568 addresses available for the DHCPv6 Client less the address being 569 provided. When the DHCPv6 Client responds to this response with 570 ADDRESS_ACCEPTED the DHCPv6 Server must decrement the number of 571 addresses available for the DHCPv6 Client. If ADDRESS_ACCEPTED is 572 set, the DHCPv6 Server is informing the DHCPv6 Client that it has a 573 number of addresses available that can be used by the DHCPv6 Client. 574 Otherwise the Addrs Avail field is NULL. 576 Transaction ID field: must contain a random number generated Integer 577 determined by the DHCPv6 Clients request packet. 579 Lease Time field: must contain a Lease Time with any returned 580 addresses that were requested, otherwise NULL. 582 Interface Token field: must contain a random number generated Integer 583 to identify addresses associated with a DHCPv6 Clients network 584 interface. 586 IPv6 Address field: must contain an IPv6 Address. 588 Host Name field: must contain a Host Name if NAME_RETURNED is set 589 otherwise NULL. 591 Server IPv6 Address field: must contain an IPv6 address if 593 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 595 SERVER_ADDRESS is set, otherwise NULL. 597 Configuration Type field: must contain a valid Configuration Type as 598 defined in the DHCPv6 Options [IPv6-DHCP-OPTIONS] if CONFIG_RETURN or 599 CONFIG_REJECTED is set, otherwise the Configuration fields are not 600 present in the packet. 602 Configuration Next Type field: If CONFIG_RETURNED or CONFIG_REJECTED 603 is set, and if there is more than one Congfiguration Type present, 604 the value of the next configuration type should be put into this 605 field, otherwise NULL. 607 Configuration Data Length field: If CONFIG_RETURNED is set, then this 608 is the length of the Configuration Data present. If CONFIG_REJECTED 609 is set, then the DHCPv6 Server will set length to zero. 611 Variable Configuration Data field: Contains Configuration Data only 612 if CONFIG_RETURNED is set, otherwise there is no Configuration Data 613 present in the packet. 615 5.6 DHCPv6 Server Lease Expiration 617 The DHCPv6 may send an asynchronous LEASE_EXPIRED message with a 618 grace period if an organizations network site needs to reclaim 619 addresses when their Lease has not expired. 621 Msg Request field: 623 LEASE_EXPIRED is set. 625 Msg Response field: must be NULL. 627 Addrs Avail field: must be NULL. 629 Transaction ID field: NULL. 631 Lease Time field: must contain a grace period for the DHCPv6 Client 632 to renew a lease for an address. 634 Interface Token field: must contain a random number generated Integer 635 for the DHCPv6 Client IPv6 address. 637 IPv6 Address field: must contain an IPv6 Address being used for an 638 Interface Token by a DHCPv6 Client. 640 Host Name field: must be NULL. 642 IPv6 Server Address field: must be NULL. 644 Configuration fields: not present in the packet. 646 6. DHCPv6 Relay-Agent Processing 648 When a DHCPv6 Relay-Agent hears a request from a DHCPv6 Client it 649 should forward that request to a DHCPv6 Server as a DHCPv6 Client Msg 650 Type. 652 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 654 The DHCPv6 Relay-Agent upon receiving a response from the DHCPv6 655 Server should forward that response to the DHCPv6 Client. 657 When the DHCPv6 Relay-Agent forwards the request to the DHCPv6 Server 658 it puts the DHCPv6 Relay-Agent's IPv6 address in the source field of 659 the IPv6 Header. 661 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 663 Acknowledgements 665 Brian Carpenter, Alex Conta, Jack McCann, Ralph Droms for providing 666 input to the evolution of DHCPv6. 668 References 670 [IPv6-ADDR] 671 R. Hinden, Editor, "IP Version 6 Addressing Architecture" 672 674 Y. Rekhter, "An IPv6 Global Unicast Address Format" 675 677 [IPv6-SPEC] 678 S. Deering and R. Hinden, Editors, "Internet Protocol Version 6 679 [IPv6] Specification" Internet Draft, March 1995 680 682 [IPv6-ICMP] 683 A. Conta, S. Deering "ICMPv6 for the Internet Protocol 684 Version 6 [IPv6]" Internet Draft, March 1995 685 687 [PMTU] 688 J. Mogul, S. Deering "Path MTU Discovery" 689 RFC 1191, 11/16/90 691 [IPv6-ADDRCONF] 692 S. Thomson, "IPv6 Stateless Address Configuration" 693 Internet Draft, March 1995 695 W. A. Simpson "IPv6 Neighbor Discovery - Processing" 696 698 [RFC-1034] 699 P. Mockapetris, "Domain Names - implementation and specification" 700 STD-13, 11/01/87 702 [RFC-1035] 703 P. Mockapetris, "Domain Names - concepts and facilities" 704 STD-13, 11/01/87 706 [DYN-DNS-UPD] 707 S. Thomson, Y. Rekhter, J. Bound, "Dynamic Updates in the Domain 708 Name System (DNS)" Internet Draft, March 1995 709 711 INETERNET-DRAFT draft-ietf-dhc-dhcpv6-01.txt March 1995 713 [IPv6-DHCP-OPTIONS] 714 716 [RFC-768] 717 J. Postel, "User Datagram Protocol" 718 STD-6, 08/28/80. 720 Authors' Addresses 722 Jim Bound 723 Digital Equipment Corporation 724 110 Spitbrook Road, ZKO3-3/U14 725 Nashua, NH 03062 726 Phone: (603) 881-0400 727 Email: bound@zk3.dec.com 729 Yakov Rekhter 730 T.J. Watson Research Center, IBM Corporation 731 P.O. Box 570 732 Yorktown Heights, NY 10598 733 Phone: (914) 784-7361 734 Email: yakov@watson.ibm.com 736 Sue Thomson 737 Bellcore 738 445 South Street 739 Morristown, NJ 07960 740 Phone: (201) 829-4514 741 Email: set@thumper.bellcore.com