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