1<?xml version='1.0' ?> 2 3<!-- Id: References.xml,v 1.8 2012/01/05 00:03:17 sar Exp --> 4 5<?rfc private="ISC-DHCP-REFERENCES" ?> 6 7<?rfc toc="yes"?> 8 9<?rfc compact="yes"?> 10<?rfc subcompact="no"?> 11<?rfc tocompact="no"?> 12<?rfc symrefs="yes"?> 13 14<!DOCTYPE rfc SYSTEM 'rfc2629bis.dtd' [ 15 <!ENTITY rfc760 PUBLIC '' 16 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0760.xml'> 17 <!ENTITY rfc768 PUBLIC '' 18 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml'> 19 <!ENTITY rfc894 PUBLIC '' 20 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0894.xml'> 21 <!ENTITY rfc951 PUBLIC '' 22 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0951.xml'> 23 <!ENTITY rfc1035 PUBLIC '' 24 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'> 25 <!ENTITY rfc1188 PUBLIC '' 26 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1188.xml'> 27 <!ENTITY rfc1542 PUBLIC '' 28 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1542.xml'> 29 <!ENTITY rfc2131 PUBLIC '' 30 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'> 31 <!ENTITY rfc2132 PUBLIC '' 32 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml'> 33 <!ENTITY rfc2241 PUBLIC '' 34 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2241.xml'> 35 <!ENTITY rfc2242 PUBLIC '' 36 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2242.xml'> 37 <!ENTITY rfc2485 PUBLIC '' 38 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2485.xml'> 39 <!ENTITY rfc2610 PUBLIC '' 40 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2610.xml'> 41 <!ENTITY rfc2937 PUBLIC '' 42 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2937.xml'> 43 <!ENTITY rfc2939 PUBLIC '' 44 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2939.xml'> 45 <!ENTITY rfc3004 PUBLIC '' 46 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3004.xml'> 47 <!ENTITY rfc3011 PUBLIC '' 48 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3011.xml'> 49 <!ENTITY rfc3046 PUBLIC '' 50 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3046.xml'> 51 <!ENTITY rfc3074 PUBLIC '' 52 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3074.xml'> 53 <!ENTITY rfc3256 PUBLIC '' 54 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3256.xml'> 55 <!ENTITY rfc3315 PUBLIC '' 56 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'> 57 <!ENTITY rfc3319 PUBLIC '' 58 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3319.xml'> 59 <!ENTITY rfc3396 PUBLIC '' 60 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3396.xml'> 61 <!ENTITY rfc3397 PUBLIC '' 62 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3397.xml'> 63 <!ENTITY rfc3527 PUBLIC '' 64 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3527.xml'> 65 <!ENTITY rfc3633 PUBLIC '' 66 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml'> 67 <!ENTITY rfc3646 PUBLIC '' 68 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3646.xml'> 69 <!ENTITY rfc3679 PUBLIC '' 70 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3679.xml'> 71 <!ENTITY rfc3898 PUBLIC '' 72 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3898.xml'> 73 <!ENTITY rfc3925 PUBLIC '' 74 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3925.xml'> 75 <!ENTITY rfc3942 PUBLIC '' 76 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3942.xml'> 77 <!ENTITY rfc4075 PUBLIC '' 78 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4075.xml'> 79 <!ENTITY rfc4242 PUBLIC '' 80 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4242.xml'> 81 <!ENTITY rfc4361 PUBLIC '' 82 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4361.xml'> 83 <!ENTITY rfc4388 PUBLIC '' 84 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4388.xml'> 85 <!ENTITY rfc4580 PUBLIC '' 86 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4580.xml'> 87 <!ENTITY rfc4649 PUBLIC '' 88 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4649.xml'> 89 <!ENTITY rfc4701 PUBLIC '' 90 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4701.xml'> 91 <!ENTITY rfc4702 PUBLIC '' 92 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4702.xml'> 93 <!ENTITY rfc4703 PUBLIC '' 94 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4703.xml'> 95 <!ENTITY rfc5453 PUBLIC '' 96 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5453.xml'> 97 ]> 98 99 100 101<rfc ipr="none"> 102 <front> 103 <title>ISC DHCP References Collection</title> 104 105 <author initials="D.H." surname="Hankins" fullname="David W. Hankins"> 106 <organization abbrev="ISC">Internet Systems Consortium, 107 Inc. 108 </organization> 109 110 <address> 111 <postal> 112 <street>PO Box 360</street> 113 <city>Newmarket</city> 114 <region>NH</region> 115 <code>03857</code> 116 <country>USA</country> 117 </postal> 118 </address> 119 </author> 120 121 <author initials="T." surname="Mrugalski" fullname="Tomasz Mrugalski"> 122 <organization abbrev="ISC">Internet Systems Consortium, 123 Inc. 124 </organization> 125 126 <address> 127 <postal> 128 <street>PO Box 360</street> 129 <city>Newmarket</city> 130 <region>NH</region> 131 <code>03857</code> 132 <country>USA</country> 133 </postal> 134 </address> 135 </author> 136 137 <date day="04" month="January" year="2012"/> 138 139 <keyword>ISC</keyword> 140 <keyword>DHCP</keyword> 141 <keyword>Reference Implementation</keyword> 142 143 <abstract> 144 <t>This document describes a collection of reference material 145 to which ISC DHCP has been implemented as well as a more 146 complete listing of references for DHCP and DHCPv6 protocols.</t> 147 </abstract> 148 149 <note title="Copyright Notice"> 150 <t>Copyright (C) 2006-2022 Internet Systems 151 Consortium, Inc. ("ISC")</t> 152 153 <t>This Source Code Form is subject to the terms of the Mozilla Public 154 License, v. 2.0. If a copy of the MPL was not distributed with this 155 file, You can obtain one at http://mozilla.org/MPL/2.0/. 156 </t> 157 158 <t>THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES 159 WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF 160 MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR 161 ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES 162 WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN 163 ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT 164 OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.</t> 165 </note> 166 167 </front> 168 169 <middle> 170 <section title="Introduction"> 171 <t>As a little historical anecdote, ISC DHCP once packaged all the 172 relevant RFCs and standards documents along with the software 173 package. Until one day when a voice was heard from one of the 174 many fine institutions that build and distribute this software... 175 they took issue with the IETF's copyright on the RFC's. It 176 seems the IETF's copyrights don't allow modification of RFC's 177 (except for translation purposes).</t> 178 179 <t>Our main purpose in providing the RFCs is to aid in 180 documentation, but since RFCs are now available widely from many 181 points of distribution on the Internet, there is no real need to 182 provide the documents themselves. So, this document has been 183 created in their stead, to list the various IETF RFCs one might 184 want to read, and to comment on how well (or poorly) we have 185 managed to implement them.</t> 186 </section> 187 188 <section title="Definition: Reference Implementation"> 189 <t>ISC DHCP, much like its other cousins in ISC software, is 190 self-described as a 'Reference Implementation.' There has been 191 a great deal of confusion about this term. Some people seem to 192 think that this term applies to any software that once passed 193 a piece of reference material on its way to market (but may do 194 quite a lot of things that aren't described in any reference, or 195 may choose to ignore the reference it saw entirely). Other folks 196 get confused by the word 'reference' and understand that to mean 197 that there is some special status applied to the software - that 198 the software itself is the reference by which all other software 199 is measured. Something along the lines of being "The DHCP 200 Protocol's Reference Clock," it is supposed.</t> 201 202 <t>The truth is actually quite a lot simpler. Reference 203 implementations are software packages which were written 204 to behave precisely as appears in reference material. They 205 are written "to match reference."</t> 206 207 <t>If the software has a behaviour that manifests itself 208 externally (whether it be something as simple as the 'wire 209 format' or something higher level, such as a complicated 210 behaviour that arises from multiple message exchanges), that 211 behaviour must be found in a reference document.</t> 212 213 <t>Anything else is a bug, the only question is whether the 214 bug is in reference or software (failing to implement the 215 reference).</t> 216 217 <t>This means:</t> 218 219 <t> 220 <list style="symbols"> 221 <t>To produce new externally-visible behaviour, one must first 222 provide a reference.</t> 223 224 <t>Before changing externally visible behaviour to work around 225 simple incompatibilities in any other implementation, one must 226 first provide a reference.</t> 227 </list> 228 </t> 229 230 <t>That is the lofty goal, at any rate. It's well understood that, 231 especially because the ISC DHCP Software package has not always been 232 held to this standard (but not entirely due to it), there are many 233 non-referenced behaviours within ISC DHCP.</t> 234 235 <t>The primary goal of reference implementation is to prove the 236 reference material. If the reference material is good, then you 237 should be able to sit down and write a program that implements the 238 reference, to the word, and come to an implementation that 239 is distinguishable from others in the details, but not in the 240 facts of operating the protocol. This means that there is no 241 need for 'special knowledge' to work around arcane problems that 242 were left undocumented. No secret handshakes need to be learned 243 to be imparted with the necessary "real documentation".</t> 244 245 <t>Also, by accepting only reference as the guidebook for ISC 246 DHCP's software implementation, anyone who can make an impact on 247 the color texture or form of that reference has a (somewhat 248 indirect) voice in ISC DHCP's software design. As the IETF RFC's 249 have been selected as the source of reference, that means everyone 250 on the Internet with the will to participate has a say.</t> 251 </section> 252 253 <section title="Low Layer References"> 254 <t>It may surprise you to realize that ISC DHCP implements 802.1 255 'Ethernet' framing, Token Ring, and FDDI. In order to bridge the 256 gap there between these physical and DHCP layers, it must also 257 implement IP and UDP framing.</t> 258 259 <t>The reason for this stems from Unix systems' handling of BSD 260 sockets (the general way one might engage in transmission of UDP 261 packets) on unconfigured interfaces, or even the handling of 262 broadcast addressing on configured interfaces.</t> 263 264 <t>There are a few things that DHCP servers, relays, and clients all 265 need to do in order to speak the DHCP protocol in strict compliance 266 with <xref target="RFC2131"/>. 267 268 <list style="numbers"> 269 <t>Transmit a UDP packet from IP:0.0.0.0 Ethernet:Self, destined to 270 IP:255.255.255.255 LinkLayer:Broadcast on an unconfigured (no IP 271 address yet) interface.</t> 272 273 <t>Receive a UDP packet from IP:remote-system LinkLayer:remote-system, 274 destined to IP:255.255.255.255 LinkLayer:Broadcast, again on an 275 unconfigured interface.</t> 276 277 <t>Transmit a UDP packet from IP:Self, Ethernet:Self, destined to 278 IP:remote-system LinkLayer:remote-system, without transmitting a 279 single ARP.</t> 280 281 <t>And of course the simple case, a regular IP unicast that is 282 routed via the usual means (so it may be direct to a local system, 283 with ARP providing the glue, or it may be to a remote system via 284 one or more routers as normal). In this case, the interfaces are 285 always configured.</t> 286 </list></t> 287 288 <t>The above isn't as simple as it sounds on a regular BSD socket. 289 Many unix implementations will transmit broadcasts not to 290 255.255.255.255, but to x.y.z.255 (where x.y.z is the system's local 291 subnet). Such packets are not received by several known DHCP client 292 implementations - and it's not their fault, <xref target="RFC2131"/> 293 very explicitly demands that these packets' IP destination 294 addresses be set to 255.255.255.255.</t> 295 296 <t>Receiving packets sent to 255.255.255.255 isn't a problem on most 297 modern unixes...so long as the interface is configured. When there 298 is no IPv4 address on the interface, things become much more murky.</t> 299 300 <t>So, for this convoluted and unfortunate state of affairs in the 301 unix systems of the day ISC DHCP was manufactured, in order to do 302 what it needs not only to implement the reference but to interoperate 303 with other implementations, the software must create some form of 304 raw socket to operate on.</t> 305 306 <t>What it actually does is create, for each interface detected on 307 the system, a Berkeley Packet Filter socket (or equivalent), and 308 program it with a filter that brings in only DHCP packets. A 309 "fallback" UDP Berkeley socket is generally also created, a single 310 one no matter how many interfaces. Should the software need to 311 transmit a contrived packet to the local network the packet is 312 formed piece by piece and transmitted via the BPF socket. Hence 313 the need to implement many forms of Link Layer framing and above. 314 The software gets away with not having to implement IP routing 315 tables as well by simply utilizing the aforementioned 'fallback' 316 UDP socket when unicasting between two configured systems is 317 needed.</t> 318 319 <t>Modern unixes have opened up some facilities that diminish how 320 much of this sort of nefarious kludgery is necessary, but have not 321 found the state of affairs absolutely resolved. In particular, 322 one might now unicast without ARP by inserting an entry into the 323 ARP cache prior to transmitting. Unconfigured interfaces remain 324 the sticking point, however...on virtually no modern unixes is 325 it possible to receive broadcast packets unless a local IPv4 326 address has been configured, unless it is done with raw sockets.</t> 327 328 <section title="Ethernet Protocol References"> 329 <t>ISC DHCP Implements Ethernet Version 2 ("DIX"), which is a variant 330 of IEEE 802.2. No good reference of this framing is known to exist 331 at this time, but it is vaguely described in <xref target="RFC0894"/> 332 see the section titled "Packet format"), and 333 the following URL is also thought to be useful.</t> 334 335 <t><eref target="http://en.wikipedia.org/wiki/DIX_Ethernet">http://en.wikipedia.org/wiki/DIX_Ethernet</eref></t> 336 </section> 337 338 <section title="Token Ring Protocol References"> 339 <t>IEEE 802.5 defines the Token Ring framing format used by ISC 340 DHCP.</t> 341 </section> 342 343 <section title="FDDI Protocol References"> 344 <t><xref target="RFC1188"/> is the most helpful 345 reference ISC DHCP has used to form FDDI packets.</t> 346 </section> 347 348 <section title="Internet Protocol Version 4 References"> 349 <t><xref target="RFC0760">RFC760</xref> fundamentally defines the 350 bare IPv4 protocol which ISC DHCP implements.</t> 351 </section> 352 353 <section title="Unicast Datagram Protocol References"> 354 <t><xref target="RFC0768">RFC768</xref> defines the User Datagram 355 Protocol that ultimately carries the DHCP or BOOTP protocol. The 356 destination DHCP server port is 67, the client port is 68. Source 357 ports are irrelevant.</t> 358 </section> 359 </section> 360 361 <section title="BOOTP Protocol References"> 362 <t>The DHCP Protocol is strange among protocols in that it is 363 grafted over the top of another protocol - BOOTP (but we don't 364 call it "DHCP over BOOTP" like we do, say "TCP over IP"). BOOTP 365 and DHCP share UDP packet formats - DHCP is merely a conventional 366 use of both BOOTP header fields and the trailing 'options' space.</t> 367 368 <t>The ISC DHCP server supports BOOTP clients conforming to 369 <xref target="RFC0951">RFC951</xref> and <xref target="RFC1542"> 370 RFC1542</xref>.</t> 371 </section> 372 373 <section title="DHCPv4 Protocol References"> 374 <section title="DHCPv4 Protocol"> 375 <t>"The DHCP[v4] Protocol" is not defined in a single document. The 376 following collection of references of what ISC DHCP terms "The 377 DHCPv4 Protocol".</t> 378 379 <section title="Core Protocol References"> 380 <t><xref target="RFC2131">RFC2131</xref> defines the protocol format 381 and procedures. ISC DHCP is not known to diverge from this document 382 in any way. There are, however, a few points on which different 383 implementations have arisen out of vagueries in the document. 384 DHCP Clients exist which, at one time, present themselves as using 385 a Client Identifier Option which is equal to the client's hardware 386 address. Later, the client transmits DHCP packets with no Client 387 Identifier Option present - essentially identifying themselves using 388 the hardware address. Some DHCP Servers have been developed which 389 identify this client as a single client. ISC has interpreted 390 RFC2131 to indicate that these clients must be treated as two 391 separate entities (and hence two, separate addresses). Client 392 behaviour (Embedded Windows products) has developed that relies on 393 the former implementation, and hence is incompatible with the 394 latter. Also, RFC2131 demands explicitly that some header fields 395 be zeroed upon certain message types. The ISC DHCP Server instead 396 copies many of these fields from the packet received from the client 397 or relay, which may not be zero. It is not known if there is a good 398 reason for this that has not been documented.</t> 399 400 <t><xref target="RFC2132">RFC2132</xref> defines the initial set of 401 DHCP Options and provides a great deal of guidance on how to go about 402 formatting and processing options. The document unfortunately 403 waffles to a great extent about the NULL termination of DHCP Options, 404 and some DHCP Clients (Windows 95) have been implemented that rely 405 upon DHCP Options containing text strings to be NULL-terminated (or 406 else they crash). So, ISC DHCP detects if clients null-terminate the 407 host-name option and, if so, null terminates any text options it 408 transmits to the client. It also removes NULL termination from any 409 known text option it receives prior to any other processing.</t> 410 </section> 411 </section> 412 413 <section title="DHCPv4 Option References"> 414 <t><xref target="RFC2241">RFC2241</xref> defines options for 415 Novell Directory Services.</t> 416 417 <t><xref target="RFC2242">RFC2242</xref> defines an encapsulated 418 option space for NWIP configuration.</t> 419 420 <t><xref target="RFC2485">RFC2485</xref> defines the Open Group's 421 UAP option.</t> 422 423 <t><xref target="RFC2610">RFC2610</xref> defines options for 424 the Service Location Protocol (SLP).</t> 425 426 <t><xref target="RFC2937">RFC2937</xref> defines the Name Service 427 Search Option (not to be confused with the domain-search option). 428 The Name Service Search Option allows eg nsswitch.conf to be 429 reconfigured via dhcp. The ISC DHCP server implements this option, 430 and the ISC DHCP client is compatible...but does not by default 431 install this option's value. One would need to make their relevant 432 dhclient-script process this option in a way that is suitable for 433 the system.</t> 434 435 <t><xref target="RFC3004">RFC3004</xref> defines the User-Class 436 option. Note carefully that ISC DHCP currently does not implement 437 to this reference, but has (inexplicably) selected an incompatible 438 format: a plain text string.</t> 439 440 <t><xref target="RFC3011">RFC3011</xref> defines the Subnet-Selection 441 plain DHCPv4 option. Do not confuse this option with the relay agent 442 "link selection" sub-option, although their behaviour is 443 similar.</t> 444 445 <t><xref target="RFC3396">RFC3396</xref> documents both how long 446 options may be encoded in DHCPv4 packets, and also how multiple 447 instances of the same option code within a DHCPv4 packet will be 448 decoded by receivers.</t> 449 450 <t><xref target="RFC3397">RFC3397</xref> documents the Domain-Search 451 Option, which allows the configuration of the /etc/resolv.conf 452 'search' parameter in a way that is <xref target="RFC1035">RFC1035 453 </xref> wire format compatible (in fact, it uses the RFC1035 wire 454 format). ISC DHCP has both client and server support, and supports 455 RFC1035 name compression.</t> 456 457 <t><xref target="RFC3679">RFC3679</xref> documents a number of 458 options that were documented earlier in history, but were not 459 made use of.</t> 460 461 <t><xref target="RFC3925">RFC3925</xref> documents a pair of 462 Enterprise-ID delimited option spaces for vendors to use in order 463 to inform servers of their "vendor class" (sort of like 'uname' 464 or 'who and what am I'), and a means to deliver vendor-specific 465 and vendor-documented option codes and values.</t> 466 467 <t><xref target="RFC3942">RFC3942</xref> redefined the 'site local' 468 option space.</t> 469 470 <t><xref target="RFC4280" /> defines two BCMS server options 471 for each protocol family.</t> 472 473 <t><xref target="RFC4388">RFC4388</xref> defined the DHCPv4 474 LEASEQUERY message type and a number of suitable response messages, 475 for the purpose of sharing information about DHCP served addresses 476 and clients.</t> 477 478 <section title="Relay Agent Information Option Options"> 479 <t><xref target="RFC3046">RFC3046</xref> defines the Relay Agent 480 Information Option and provides a number of sub-option 481 definitions.</t> 482 483 <t><xref target="RFC3256">RFC3256</xref> defines the DOCSIS Device 484 Class sub-option.</t> 485 486 <t><xref target="RFC3527">RFC3527</xref> defines the Link Selection 487 sub-option.</t> 488 </section> 489 490 491 <section title="Dynamic DNS Updates References"> 492 <t>The collection of documents that describe the standards-based 493 method to update dns names of DHCP clients starts most easily 494 with <xref target="RFC4703">RFC4703</xref> to define the overall 495 architecture, travels through RFCs <xref target="RFC4702">4702</xref> 496 and <xref target="RFC4704">4704</xref> to describe the DHCPv4 and 497 DHCPv6 FQDN options (to carry the client name), and ends up at 498 <xref target="RFC4701">RFC4701</xref> which describes the DHCID 499 RR used in DNS to perform a kind of atomic locking.</t> 500 501 <t>ISC DHCP adopted early versions of these documents, and has not 502 yet synchronized with the final standards versions.</t> 503 504 <t>For RFCs 4702 and 4704, the 'N' bit is not yet supported. The 505 result is that it is always set zero, and is ignored if set.</t> 506 507 <t>For RFC4701, which is used to match client identities with names 508 in the DNS as part of name conflict resolution. Note that ISC DHCP's 509 implementation of DHCIDs vary wildly from this specification. 510 First, ISC DHCP uses a TXT record in which the contents are stored 511 in hexadecimal. Second, there is a flaw in the selection of the 512 'Identifier Type', which results in a completely different value 513 being selected than was defined in an older revision of this 514 document...also this field is one byte prior to hexadecimal 515 encoding rather than two. Third, ISC DHCP does not use a digest 516 type code. Rather, all values for such TXT records are reached 517 via an MD5 sum. In short, nothing is compatible, but the 518 principle of the TXT record is the same as the standard DHCID 519 record. However, for DHCPv6 FQDN, we do use DHCID type code '2', 520 as no other value really makes sense in our context.</t> 521 </section> 522 523 <section title="Experimental: Failover References"> 524 <t>The Failover Protocol defines means by which two DHCP Servers 525 can share all the relevant information about leases granted to 526 DHCP clients on given networks, so that one of the two servers may 527 fail and be survived by a server that can act responsibly.</t> 528 529 <t>Unfortunately it has been quite some years (2003) since the last 530 time this document was edited, and the authors no longer show any 531 interest in fielding comments or improving the document.</t> 532 533 <t>The status of this protocol is very unsure, but ISC's 534 implementation of it has proven stable and suitable for use in 535 sizable production environments.</t> 536 537 <t><xref target="draft-failover">draft-ietf-dhc-failover-12.txt</xref> 538 describes the Failover Protocol. In addition to what is described 539 in this document, ISC DHCP has elected to make some experimental 540 changes that may be revoked in a future version of ISC DHCP (if the 541 draft authors do not adopt the new behaviour). Specifically, ISC 542 DHCP's POOLREQ behaviour differs substantially from what is 543 documented in the draft, and the server also implements a form of 544 'MAC Address Affinity' which is not described in the failover 545 document. The full nature of these changes have been described on 546 the IETF DHC WG mailing list (which has archives), and also in ISC 547 DHCP's manual pages. Also note that although this document 548 references a RECOVER-WAIT state, it does not document a protocol 549 number assignment for this state. As a consequence, ISC DHCP has 550 elected to use the value 254.</t> 551 552 <t> An optimization described in the failover protocol draft 553 is included since 4.2.0a1. It permits a DHCP server 554 operating in communications-interrupted state to 'rewind' a 555 lease to the state most recently transmitted to its peer, 556 greatly increasing a server's endurance in 557 communications-interrupted. This is supported using a new 558 'rewind state' record on the dhcpd.leases entry for each 559 lease. 560 </t> 561 562 <t><xref target="RFC3074" /> describes the Load Balancing 563 Algorithm (LBA) that ISC DHCP uses in concert with the Failover 564 protocol. Note that versions 3.0.* are known to misimplement the 565 hash algorithm (it will only use the low 4 bits of every byte of 566 the hash bucket array).</t> 567 </section> 568 </section> 569 570 <section title="DHCP Procedures"> 571 <t><xref target="RFC2939" /> explains how to go about 572 obtaining a new DHCP Option code assignment.</t> 573 </section> 574 </section> 575 576 577 <section title="DHCPv6 Protocol References"> 578 579 <section title="DHCPv6 Protocol References"> 580 <t>For now there is only one document that specifies the base 581 of the DHCPv6 protocol (there have been no updates yet), 582 <xref target="RFC3315"/>.</t> 583 584 <t>Support for DHCPv6 was first added in version 4.0.0. The server 585 and client support only IA_NA. While the server does support multiple 586 IA_NAs within one packet from the client, our client only supports 587 sending one. There is no relay support.</t> 588 589 <t>DHCPv6 introduces some new and uncomfortable ideas to the common 590 software library.</t> 591 592 <t> 593 <list style="numbers"> 594 <t>Options sometimes may appear multiple times. The common 595 library used to treat all appearance of multiple options as 596 specified in RFC2131 - to be concatenated. DHCPv6 options 597 may sometimes appear multiple times (such as with IA_NA or 598 IAADDR), but often must not. As of 4.2.1-P1, multiple IA_NA, IA_PD 599 or IA_TA are not supported.</t> 600 601 <t>The same option space appears in DHCPv6 packets multiple times. 602 If the packet was got via a relay, then the client's packet is 603 stored to an option within the relay's packet...if there were two 604 relays, this recurses. At each of these steps, the root "DHCPv6 605 option space" is used. Further, a client packet may contain an 606 IA_NA, which may contain an IAADDR - but really, in an abstract 607 sense, this is again re-encapsulation of the DHCPv6 option space 608 beneath options it also contains.</t> 609 </list> 610 </t> 611 612 <t>Precisely how to correctly support the above conundrums has not 613 quite yet been settled, so support is incomplete.</t> 614 615 <t><xref target="RFC5453"/> creates a registry at IANA to reserve 616 interface identifiers and specifies a starting set. These IIDs should 617 not be used when constructing addresses to avoid possible conflicts.</t> 618 </section> 619 620 <section title="DHCPv6 Options References"> 621 <t><xref target="RFC3319"/> defines the SIP server 622 options for DHCPv6.</t> 623 624 <t><xref target="RFC3646"/> documents the DHCPv6 625 name-servers and domain-search options.</t> 626 627 <t><xref target="RFC3633"/> documents the Identity 628 Association Prefix Delegation for DHCPv6, which is included 629 here for protocol wire reference, but which is not supported 630 by ISC DHCP.</t> 631 632 <t><xref target="RFC3898"/> documents four NIS options 633 for delivering NIS servers and domain information in DHCPv6.</t> 634 635 <t><xref target="RFC4075"/> defines the DHCPv6 SNTP 636 Servers option.</t> 637 638 <t><xref target="RFC4242"/> defines the Information 639 Refresh Time option, which advises DHCPv6 Information-Request 640 clients to return for updated information.</t> 641 642 <t><xref target="RFC4280"/> defines two BCMS server options 643 for each protocol family.</t> 644 645 <t><xref target="RFC4580"/> defines a DHCPv6 646 subscriber-id option, which is similar in principle to the DHCPv4 647 relay agent option of the same name.</t> 648 649 <t><xref target="RFC4649"/> defines a DHCPv6 remote-id 650 option, which is similar in principle to the DHCPv4 relay agent 651 remote-id.</t> 652 653 </section> 654 </section> 655 656 </middle> 657 658 <back> 659 <references title="Published DHCPv4 References"> 660 &rfc760; 661 &rfc768; 662 &rfc894; 663 &rfc951; 664 &rfc1035; 665 &rfc1188; 666 &rfc1542; 667 &rfc2131; 668 &rfc2132; 669 &rfc2241; 670 &rfc2242; 671 &rfc2485; 672 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2563'?> 673 &rfc2610; 674 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2855'?> 675 &rfc2937; 676 &rfc2939; 677 &rfc3004; 678 &rfc3011; 679 &rfc3046; 680 &rfc3074; 681 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118'?> 682 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3203'?> 683 &rfc3256; 684 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3361'?> 685 &rfc3396; 686 &rfc3397; 687 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3442'?> 688 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3456'?> 689 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3495'?> 690 &rfc3527; 691 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3594'?> 692 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3634'?> 693 &rfc3679; 694 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3825'?> 695 &rfc3925; 696 &rfc3942; 697 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3993'?> 698 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4014'?> 699 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4030'?> 700 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4039'?> 701 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4174'?> 702 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4243'?> 703 &rfc4361; 704 &rfc4388; 705 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4390'?> 706 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4436'?> 707 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4701'?> 708 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4702'?> 709 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4703'?> 710 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5010'?> 711 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5071'?> 712 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5107'?> 713 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5192'?> 714 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5223'?> 715 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5859'?> 716 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5969'?> 717 718 <reference anchor='draft-failover'> 719 <front> 720 <title>DHCP Failover Protocol</title> 721 <author initials='R.' surname='Droms' fullname='Ralph Droms'> 722 <organization abbrev='Cisco'>Cisco Systems</organization> 723 </author> 724 <date month='March' year='2003'/> 725 </front> 726 <format type="TXT" octets="312151" target="https://www.isc.org/sw/dhcp/drafts/draft-ietf-dhc-failover-12.txt"/> 727 </reference> 728 729 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-dhcpv4-relay-encapsulation-00.xml'?> 730 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-dhcpv4-bulk-leasequery-03.xml'?> 731 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-leasequery-by-remote-id-09.xml'?> 732 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-relay-id-suboption-07.xml'?> 733 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mip6-hiopt-17.xml'?> 734 735 </references> 736 737 <references title="Published Common (DHCPv4/DHCPv6) References"> 738 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4280'?> 739 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4477'?> 740 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4578'?> 741 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4776'?> 742 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4833'?> 743 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5417'?> 744 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5678'?> 745 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5908'?> 746 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5970'?> 747 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5986'?> 748 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-vpn-option-12.xml'?> 749 750 </references> 751 752 <references title="Published DHCPv6 References"> 753 754 &rfc3315; 755 &rfc3319; 756 &rfc3633; 757 &rfc3646; 758 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3736'?> 759 &rfc3898; 760 &rfc4075; 761 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4076'?> 762 &rfc4242; 763 &rfc4580; 764 &rfc4649; 765 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4704'?> 766 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4994'?> 767 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5007'?> 768 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5453'?> 769 <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5460'?> 770 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mif-dhcpv6-route-option'?> 771 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv6-ldra'?> 772 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv6-relay-supplied-options'?> 773 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-pd-exclude-01.xml'?> 774 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-secure-dhcpv6-02.xml'?> 775 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mext-nemo-pd'?> 776 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-duid-uuid-03.xml'?> 777 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-softwire-ds-lite-tunnel-option-10.xml'?> 778 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mif-dns-server-selection-01.xml'?> 779 <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-geopriv-rfc3825bis-17.xml'?> 780 781 <reference anchor='draft-addr-params'> 782 <front> 783 <title>Address Parameters Option for DHCPv6</title> 784 <author initials='T.' surname='Mrugalski' fullname='Mrugalski'> 785 <organization abbrev='Cisco'>Gdansk University of Technology</organization> 786 </author> 787 <date month='April' year='2007'/> 788 </front> 789 <format type="TXT" target="http://klub.com.pl/dhcpv6/doc/draft-mrugalski-addropts-XX-2007-04-17.txt"/> 790 </reference> 791 792 </references> 793 </back> 794</rfc> 795