diff options
Diffstat (limited to 'doc/References.xml')
| -rw-r--r-- | doc/References.xml | 788 |
1 files changed, 788 insertions, 0 deletions
diff --git a/doc/References.xml b/doc/References.xml new file mode 100644 index 0000000..de19fd0 --- /dev/null +++ b/doc/References.xml @@ -0,0 +1,788 @@ +<?xml version='1.0' ?> + +<!-- $Id: References.xml,v 1.4.24.3 2011-07-05 16:57:20 sar Exp $ --> + +<?rfc private="ISC-DHCP-REFERENCES" ?> + +<?rfc toc="yes"?> + +<?rfc compact="yes"?> +<?rfc subcompact="no"?> +<?rfc tocompact="no"?> +<?rfc symrefs="yes"?> + +<!DOCTYPE rfc SYSTEM 'rfc2629bis.dtd' [ + <!ENTITY rfc760 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0760.xml'> + <!ENTITY rfc768 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0768.xml'> + <!ENTITY rfc894 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0894.xml'> + <!ENTITY rfc951 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.0951.xml'> + <!ENTITY rfc1035 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml'> + <!ENTITY rfc1188 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1188.xml'> + <!ENTITY rfc1542 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1542.xml'> + <!ENTITY rfc2131 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2131.xml'> + <!ENTITY rfc2132 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2132.xml'> + <!ENTITY rfc2241 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2241.xml'> + <!ENTITY rfc2242 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2242.xml'> + <!ENTITY rfc2485 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2485.xml'> + <!ENTITY rfc2610 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2610.xml'> + <!ENTITY rfc2937 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2937.xml'> + <!ENTITY rfc2939 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2939.xml'> + <!ENTITY rfc3004 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3004.xml'> + <!ENTITY rfc3011 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3011.xml'> + <!ENTITY rfc3046 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3046.xml'> + <!ENTITY rfc3074 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3074.xml'> + <!ENTITY rfc3256 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3256.xml'> + <!ENTITY rfc3315 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'> + <!ENTITY rfc3319 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3319.xml'> + <!ENTITY rfc3396 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3396.xml'> + <!ENTITY rfc3397 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3397.xml'> + <!ENTITY rfc3527 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3527.xml'> + <!ENTITY rfc3633 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml'> + <!ENTITY rfc3646 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3646.xml'> + <!ENTITY rfc3679 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3679.xml'> + <!ENTITY rfc3898 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3898.xml'> + <!ENTITY rfc3925 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3925.xml'> + <!ENTITY rfc3942 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3942.xml'> + <!ENTITY rfc4075 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4075.xml'> + <!ENTITY rfc4242 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4242.xml'> + <!ENTITY rfc4361 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4361.xml'> + <!ENTITY rfc4388 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4388.xml'> + <!ENTITY rfc4580 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4580.xml'> + <!ENTITY rfc4649 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4649.xml'> + <!ENTITY rfc4701 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4701.xml'> + <!ENTITY rfc4702 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4702.xml'> + <!ENTITY rfc4703 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4703.xml'> + ]> + + + +<rfc ipr="none"> + <front> + <title>ISC DHCP References Collection</title> + + <author initials="D.H." surname="Hankins" fullname="David W. Hankins"> + <organization abbrev="ISC">Internet Systems Consortium, + Inc. + </organization> + + <address> + <postal> + <street>950 Charter Street</street> + <city>Redwood City</city> + <region>CA</region> + <code>94063</code> + </postal> + </address> + </author> + + <author initials="T." surname="Mrugalski" fullname="Tomasz Mrugalski"> + <organization abbrev="ISC">Internet Systems Consortium, + Inc. + </organization> + + <address> + <postal> + <street>950 Charter Street</street> + <city>Redwood City</city> + <region>CA</region> + <code>94063</code> + </postal> + + <phone>+1 650 423 1345</phone> + <email>Tomasz_Mrugalski@isc.org</email> + </address> + </author> + + <date day="20" month="May" year="2011"/> + + <keyword>ISC</keyword> + <keyword>DHCP</keyword> + <keyword>Reference Implementation</keyword> + + <abstract> + <t>This document describes a collection of reference material + to which ISC DHCP has been implemented as well as a more + complete listing of references for DHCP and DHCPv6 protocols.</t> + </abstract> + + <note title="Copyright Notice"> + <t>Copyright (c) 2006-2007,2009,2011 by Internet Systems + Consortium, Inc. ("ISC")</t> + + <t>Permission to use, copy, modify, and distribute this software for + any purpose with or without fee is hereby granted, provided that the + above copyright notice and this permission notice appear in all + copies.</t> + + <t>THE SOFTWARE IS PROVIDED "AS IS" AND ISC DISCLAIMS ALL WARRANTIES + WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF + MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR + ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES + WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN + ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT + OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.</t> + </note> + + </front> + + <middle> + <section title="Introduction"> + <t>As a little historical anecdote, ISC DHCP once packaged all the + relevant RFCs and standards documents along with the software + package. Until one day when a voice was heard from one of the + many fine institutions that build and distribute this software... + they took issue with the IETF's copyright on the RFC's. It + seems the IETF's copyrights don't allow modification of RFC's + (except for translation purposes).</t> + + <t>Our main purpose in providing the RFCs is to aid in + documentation, but since RFCs are now available widely from many + points of distribution on the Internet, there is no real need to + provide the documents themselves. So, this document has been + created in their stead, to list the various IETF RFCs one might + want to read, and to comment on how well (or poorly) we have + managed to implement them.</t> + </section> + + <section title="Definition: Reference Implementation"> + <t>ISC DHCP, much like its other cousins in ISC software, is + self-described as a 'Reference Implementation.' There has been + a great deal of confusion about this term. Some people seem to + think that this term applies to any software that once passed + a piece of reference material on its way to market (but may do + quite a lot of things that aren't described in any reference, or + may choose to ignore the reference it saw entirely). Other folks + get confused by the word 'reference' and understand that to mean + that there is some special status applied to the software - that + the software itself is the reference by which all other software + is measured. Something along the lines of being "The DHCP + Protocol's Reference Clock," it is supposed.</t> + + <t>The truth is actually quite a lot simpler. Reference + implementations are software packages which were written + to behave precisely as appears in reference material. They + are written "to match reference."</t> + + <t>If the software has a behaviour that manifests itself + externally (whether it be something as simple as the 'wire + format' or something higher level, such as a complicated + behaviour that arises from multiple message exchanges), that + behaviour must be found in a reference document.</t> + + <t>Anything else is a bug, the only question is whether the + bug is in reference or software (failing to implement the + reference).</t> + + <t>This means:</t> + + <t> + <list style="symbols"> + <t>To produce new externally-visible behaviour, one must first + provide a reference.</t> + + <t>Before changing externally visible behaviour to work around + simple incompatibilities in any other implementation, one must + first provide a reference.</t> + </list> + </t> + + <t>That is the lofty goal, at any rate. It's well understood that, + especially because the ISC DHCP Software package has not always been + held to this standard (but not entirely due to it), there are many + non-referenced behaviours within ISC DHCP.</t> + + <t>The primary goal of reference implementation is to prove the + reference material. If the reference material is good, then you + should be able to sit down and write a program that implements the + reference, to the word, and come to an implementation that + is distinguishable from others in the details, but not in the + facts of operating the protocol. This means that there is no + need for 'special knowledge' to work around arcane problems that + were left undocumented. No secret handshakes need to be learned + to be imparted with the necessary "real documentation".</t> + + <t>Also, by accepting only reference as the guidebook for ISC + DHCP's software implementation, anyone who can make an impact on + the color texture or form of that reference has a (somewhat + indirect) voice in ISC DHCP's software design. As the IETF RFC's + have been selected as the source of reference, that means everyone + on the Internet with the will to participate has a say.</t> + </section> + + <section title="Low Layer References"> + <t>It may surprise you to realize that ISC DHCP implements 802.1 + 'Ethernet' framing, Token Ring, and FDDI. In order to bridge the + gap there between these physical and DHCP layers, it must also + implement IP and UDP framing.</t> + + <t>The reason for this stems from Unix systems' handling of BSD + sockets (the general way one might engage in transmission of UDP + packets) on unconfigured interfaces, or even the handling of + broadcast addressing on configured interfaces.</t> + + <t>There are a few things that DHCP servers, relays, and clients all + need to do in order to speak the DHCP protocol in strict compliance + with <xref target="RFC2131"/>. + + <list style="numbers"> + <t>Transmit a UDP packet from IP:0.0.0.0 Ethernet:Self, destined to + IP:255.255.255.255 LinkLayer:Broadcast on an unconfigured (no IP + address yet) interface.</t> + + <t>Receive a UDP packet from IP:remote-system LinkLayer:remote-system, + destined to IP:255.255.255.255 LinkLayer:Broadcast, again on an + unconfigured interface.</t> + + <t>Transmit a UDP packet from IP:Self, Ethernet:Self, destined to + IP:remote-system LinkLayer:remote-system, without transmitting a + single ARP.</t> + + <t>And of course the simple case, a regular IP unicast that is + routed via the usual means (so it may be direct to a local system, + with ARP providing the glue, or it may be to a remote system via + one or more routers as normal). In this case, the interfaces are + always configured.</t> + </list></t> + + <t>The above isn't as simple as it sounds on a regular BSD socket. + Many unix implementations will transmit broadcasts not to + 255.255.255.255, but to x.y.z.255 (where x.y.z is the system's local + subnet). Such packets are not received by several known DHCP client + implementations - and it's not their fault, <xref target="RFC2131"/> + very explicitly demands that these packets' IP destination + addresses be set to 255.255.255.255.</t> + + <t>Receiving packets sent to 255.255.255.255 isn't a problem on most + modern unixes...so long as the interface is configured. When there + is no IPv4 address on the interface, things become much more murky.</t> + + <t>So, for this convoluted and unfortunate state of affairs in the + unix systems of the day ISC DHCP was manufactured, in order to do + what it needs not only to implement the reference but to interoperate + with other implementations, the software must create some form of + raw socket to operate on.</t> + + <t>What it actually does is create, for each interface detected on + the system, a Berkeley Packet Filter socket (or equivalent), and + program it with a filter that brings in only DHCP packets. A + "fallback" UDP Berkeley socket is generally also created, a single + one no matter how many interfaces. Should the software need to + transmit a contrived packet to the local network the packet is + formed piece by piece and transmitted via the BPF socket. Hence + the need to implement many forms of Link Layer framing and above. + The software gets away with not having to implement IP routing + tables as well by simply utilizing the aforementioned 'fallback' + UDP socket when unicasting between two configured systems is + needed.</t> + + <t>Modern unixes have opened up some facilities that diminish how + much of this sort of nefarious kludgery is necessary, but have not + found the state of affairs absolutely resolved. In particular, + one might now unicast without ARP by inserting an entry into the + ARP cache prior to transmitting. Unconfigured interfaces remain + the sticking point, however...on virtually no modern unixes is + it possible to receive broadcast packets unless a local IPv4 + address has been configured, unless it is done with raw sockets.</t> + + <section title="Ethernet Protocol References"> + <t>ISC DHCP Implements Ethernet Version 2 ("DIX"), which is a variant + of IEEE 802.2. No good reference of this framing is known to exist + at this time, but it is vaguely described in <xref target="RFC0894"/> + see the section titled "Packet format"), and + the following URL is also thought to be useful.</t> + + <t><eref target="http://en.wikipedia.org/wiki/DIX_Ethernet">http://en.wikipedia.org/wiki/DIX_Ethernet</eref></t> + </section> + + <section title="Token Ring Protocol References"> + <t>IEEE 802.5 defines the Token Ring framing format used by ISC + DHCP.</t> + </section> + + <section title="FDDI Protocol References"> + <t><xref target="RFC1188"/> is the most helpful + reference ISC DHCP has used to form FDDI packets.</t> + </section> + + <section title="Internet Protocol Version 4 References"> + <t><xref target="RFC0760">RFC760</xref> fundamentally defines the + bare IPv4 protocol which ISC DHCP implements.</t> + </section> + + <section title="Unicast Datagram Protocol References"> + <t><xref target="RFC0768">RFC768</xref> defines the User Datagram + Protocol that ultimately carries the DHCP or BOOTP protocol. The + destination DHCP server port is 67, the client port is 68. Source + ports are irrelevant.</t> + </section> + </section> + + <section title="BOOTP Protocol References"> + <t>The DHCP Protocol is strange among protocols in that it is + grafted over the top of another protocol - BOOTP (but we don't + call it "DHCP over BOOTP" like we do, say "TCP over IP"). BOOTP + and DHCP share UDP packet formats - DHCP is merely a conventional + use of both BOOTP header fields and the trailing 'options' space.</t> + + <t>The ISC DHCP server supports BOOTP clients conforming to + <xref target="RFC0951">RFC951</xref> and <xref target="RFC1542"> + RFC1542</xref>.</t> + </section> + + <section title="DHCPv4 Protocol References"> + <section title="DHCPv4 Protocol"> + <t>"The DHCP[v4] Protocol" is not defined in a single document. The + following collection of references of what ISC DHCP terms "The + DHCPv4 Protocol".</t> + + <section title="Core Protocol References"> + <t><xref target="RFC2131">RFC2131</xref> defines the protocol format + and procedures. ISC DHCP is not known to diverge from this document + in any way. There are, however, a few points on which different + implementations have arisen out of vagueries in the document. + DHCP Clients exist which, at one time, present themselves as using + a Client Identifier Option which is equal to the client's hardware + address. Later, the client transmits DHCP packets with no Client + Identifier Option present - essentially identifying themselves using + the hardware address. Some DHCP Servers have been developed which + identify this client as a single client. ISC has interpreted + RFC2131 to indicate that these clients must be treated as two + separate entities (and hence two, separate addresses). Client + behaviour (Embedded Windows products) has developed that relies on + the former implementation, and hence is incompatible with the + latter. Also, RFC2131 demands explicitly that some header fields + be zeroed upon certain message types. The ISC DHCP Server instead + copies many of these fields from the packet received from the client + or relay, which may not be zero. It is not known if there is a good + reason for this that has not been documented.</t> + + <t><xref target="RFC2132">RFC2132</xref> defines the initial set of + DHCP Options and provides a great deal of guidance on how to go about + formatting and processing options. The document unfortunately + waffles to a great extent about the NULL termination of DHCP Options, + and some DHCP Clients (Windows 95) have been implemented that rely + upon DHCP Options containing text strings to be NULL-terminated (or + else they crash). So, ISC DHCP detects if clients null-terminate the + host-name option and, if so, null terminates any text options it + transmits to the client. It also removes NULL termination from any + known text option it receives prior to any other processing.</t> + </section> + </section> + + <section title="DHCPv4 Option References"> + <t><xref target="RFC2241">RFC2241</xref> defines options for + Novell Directory Services.</t> + + <t><xref target="RFC2242">RFC2242</xref> defines an encapsulated + option space for NWIP configuration.</t> + + <t><xref target="RFC2485">RFC2485</xref> defines the Open Group's + UAP option.</t> + + <t><xref target="RFC2610">RFC2610</xref> defines options for + the Service Location Protocol (SLP).</t> + + <t><xref target="RFC2937">RFC2937</xref> defines the Name Service + Search Option (not to be confused with the domain-search option). + The Name Service Search Option allows eg nsswitch.conf to be + reconfigured via dhcp. The ISC DHCP server implements this option, + and the ISC DHCP client is compatible...but does not by default + install this option's value. One would need to make their relevant + dhclient-script process this option in a way that is suitable for + the system.</t> + + <t><xref target="RFC3004">RFC3004</xref> defines the User-Class + option. Note carefully that ISC DHCP currently does not implement + to this reference, but has (inexplicably) selected an incompatible + format: a plain text string.</t> + + <t><xref target="RFC3011">RFC3011</xref> defines the Subnet-Selection + plain DHCPv4 option. Do not confuse this option with the relay agent + "link selection" sub-option, although their behaviour is + similar.</t> + + <t><xref target="RFC3396">RFC3396</xref> documents both how long + options may be encoded in DHCPv4 packets, and also how multiple + instances of the same option code within a DHCPv4 packet will be + decoded by receivers.</t> + + <t><xref target="RFC3397">RFC3397</xref> documents the Domain-Search + Option, which allows the configuration of the /etc/resolv.conf + 'search' parameter in a way that is <xref target="RFC1035">RFC1035 + </xref> wire format compatible (in fact, it uses the RFC1035 wire + format). ISC DHCP has both client and server support, and supports + RFC1035 name compression.</t> + + <t><xref target="RFC3679">RFC3679</xref> documents a number of + options that were documented earlier in history, but were not + made use of.</t> + + <t><xref target="RFC3925">RFC3925</xref> documents a pair of + Enterprise-ID delimited option spaces for vendors to use in order + to inform servers of their "vendor class" (sort of like 'uname' + or 'who and what am I'), and a means to deliver vendor-specific + and vendor-documented option codes and values.</t> + + <t><xref target="RFC3942">RFC3942</xref> redefined the 'site local' + option space.</t> + + <t><xref target="RFC4280" /> defines two BCMS server options + for each protocol family.</t> + + <t><xref target="RFC4388">RFC4388</xref> defined the DHCPv4 + LEASEQUERY message type and a number of suitable response messages, + for the purpose of sharing information about DHCP served addresses + and clients.</t> + + <section title="Relay Agent Information Option Options"> + <t><xref target="RFC3046">RFC3046</xref> defines the Relay Agent + Information Option and provides a number of sub-option + definitions.</t> + + <t><xref target="RFC3256">RFC3256</xref> defines the DOCSIS Device + Class sub-option.</t> + + <t><xref target="RFC3527">RFC3527</xref> defines the Link Selection + sub-option.</t> + </section> + + + <section title="Dynamic DNS Updates References"> + <t>The collection of documents that describe the standards-based + method to update dns names of DHCP clients starts most easily + with <xref target="RFC4703">RFC4703</xref> to define the overall + architecture, travels through RFCs <xref target="RFC4702">4702</xref> + and <xref target="RFC4704">4704</xref> to describe the DHCPv4 and + DHCPv6 FQDN options (to carry the client name), and ends up at + <xref target="RFC4701">RFC4701</xref> which describes the DHCID + RR used in DNS to perform a kind of atomic locking.</t> + + <t>ISC DHCP adopted early versions of these documents, and has not + yet synchronized with the final standards versions.</t> + + <t>For RFCs 4702 and 4704, the 'N' bit is not yet supported. The + result is that it is always set zero, and is ignored if set.</t> + + <t>For RFC4701, which is used to match client identities with names + in the DNS as part of name conflict resolution. Note that ISC DHCP's + implementation of DHCIDs vary wildly from this specification. + First, ISC DHCP uses a TXT record in which the contents are stored + in hexadecimal. Second, there is a flaw in the selection of the + 'Identifier Type', which results in a completely different value + being selected than was defined in an older revision of this + document...also this field is one byte prior to hexadecimal + encoding rather than two. Third, ISC DHCP does not use a digest + type code. Rather, all values for such TXT records are reached + via an MD5 sum. In short, nothing is compatible, but the + principle of the TXT record is the same as the standard DHCID + record. However, for DHCPv6 FQDN, we do use DHCID type code '2', + as no other value really makes sense in our context.</t> + </section> + + <section title="Experimental: Failover References"> + <t>The Failover Protocol defines means by which two DHCP Servers + can share all the relevant information about leases granted to + DHCP clients on given networks, so that one of the two servers may + fail and be survived by a server that can act responsibly.</t> + + <t>Unfortunately it has been quite some years (2003) since the last + time this document was edited, and the authors no longer show any + interest in fielding comments or improving the document.</t> + + <t>The status of this protocol is very unsure, but ISC's + implementation of it has proven stable and suitable for use in + sizable production environments.</t> + + <t><xref target="draft-failover">draft-ietf-dhc-failover-12.txt</xref> + describes the Failover Protocol. In addition to what is described + in this document, ISC DHCP has elected to make some experimental + changes that may be revoked in a future version of ISC DHCP (if the + draft authors do not adopt the new behaviour). Specifically, ISC + DHCP's POOLREQ behaviour differs substantially from what is + documented in the draft, and the server also implements a form of + 'MAC Address Affinity' which is not described in the failover + document. The full nature of these changes have been described on + the IETF DHC WG mailing list (which has archives), and also in ISC + DHCP's manual pages. Also note that although this document + references a RECOVER-WAIT state, it does not document a protocol + number assignment for this state. As a consequence, ISC DHCP has + elected to use the value 254.</t> + + <t> An optimization described in the failover protocol draft + is included since 4.2.0a1. It permits a DHCP server + operating in communications-interrupted state to 'rewind' a + lease to the state most recently transmitted to its peer, + greatly increasing a server's endurance in + communications-interrupted. This is supported using a new + 'rewind state' record on the dhcpd.leases entry for each + lease. + </t> + + <t><xref target="RFC3074" /> describes the Load Balancing + Algorithm (LBA) that ISC DHCP uses in concert with the Failover + protocol. Note that versions 3.0.* are known to misimplement the + hash algorithm (it will only use the low 4 bits of every byte of + the hash bucket array).</t> + </section> + </section> + + <section title="DHCP Procedures"> + <t><xref target="RFC2939" /> explains how to go about + obtaining a new DHCP Option code assignment.</t> + </section> + </section> + + + <section title="DHCPv6 Protocol References"> + + <section title="DHCPv6 Protocol References"> + <t>For now there is only one document that specifies the base + of the DHCPv6 protocol (there have been no updates yet), + <xref target="RFC3315"/>.</t> + + <t>Support for DHCPv6 was first added in version 4.0.0. The server + and client support only IA_NA. While the server does support multiple + IA_NAs within one packet from the client, our client only supports + sending one. There is no relay support.</t> + + <t>DHCPv6 introduces some new and uncomfortable ideas to the common + software library.</t> + + <t> + <list style="numbers"> + <t>Options sometimes may appear multiple times. The common + library used to treat all appearance of multiple options as + specified in RFC2131 - to be concatenated. DHCPv6 options + may sometimes appear multiple times (such as with IA_NA or + IAADDR), but often must not. As of 4.2.1-P1, multiple IA_NA, IA_PD + or IA_TA are not supported.</t> + + <t>The same option space appears in DHCPv6 packets multiple times. + If the packet was got via a relay, then the client's packet is + stored to an option within the relay's packet...if there were two + relays, this recurses. At each of these steps, the root "DHCPv6 + option space" is used. Further, a client packet may contain an + IA_NA, which may contain an IAADDR - but really, in an abstract + sense, this is again re-encapsulation of the DHCPv6 option space + beneath options it also contains.</t> + </list> + </t> + + <t>Precisely how to correctly support the above conundrums has not + quite yet been settled, so support is incomplete.</t> + </section> + + <section title="DHCPv6 Options References"> + <t><xref target="RFC3319"/> defines the SIP server + options for DHCPv6.</t> + + <t><xref target="RFC3646"/> documents the DHCPv6 + name-servers and domain-search options.</t> + + <t><xref target="RFC3633"/> documents the Identity + Association Prefix Delegation for DHCPv6, which is included + here for protocol wire reference, but which is not supported + by ISC DHCP.</t> + + <t><xref target="RFC3898"/> documents four NIS options + for delivering NIS servers and domain information in DHCPv6.</t> + + <t><xref target="RFC4075"/> defines the DHCPv6 SNTP + Servers option.</t> + + <t><xref target="RFC4242"/> defines the Information + Refresh Time option, which advises DHCPv6 Information-Request + clients to return for updated information.</t> + + <t><xref target="RFC4280"/> defines two BCMS server options + for each protocol family.</t> + + <t><xref target="RFC4580"/> defines a DHCPv6 + subscriber-id option, which is similar in principle to the DHCPv4 + relay agent option of the same name.</t> + + <t><xref target="RFC4649"/> defines a DHCPv6 remote-id + option, which is similar in principle to the DHCPv4 relay agent + remote-id.</t> + + </section> + </section> + + </middle> + + <back> + <references title="Published DHCPv4 References"> + &rfc760; + &rfc768; + &rfc894; + &rfc951; + &rfc1035; + &rfc1188; + &rfc1542; + &rfc2131; + &rfc2132; + &rfc2241; + &rfc2242; + &rfc2485; + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2563'?> + &rfc2610; + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.2855'?> + &rfc2937; + &rfc2939; + &rfc3004; + &rfc3011; + &rfc3046; + &rfc3074; + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3118'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3203'?> + &rfc3256; + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3361'?> + &rfc3396; + &rfc3397; + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3442'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3456'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3495'?> + &rfc3527; + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3594'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3634'?> + &rfc3679; + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3825'?> + &rfc3925; + &rfc3942; + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3993'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4014'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4030'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4039'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4174'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4243'?> + &rfc4361; + &rfc4388; + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4390'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4436'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4701'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4702'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4703'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5010'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5071'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5107'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5192'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5223'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5859'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5969'?> + + <reference anchor='draft-failover'> + <front> + <title>DHCP Failover Protocol</title> + <author initials='R.' surname='Droms' fullname='Ralph Droms'> + <organization abbrev='Cisco'>Cisco Systems</organization> + </author> + <date month='March' year='2003'/> + </front> + <format type="TXT" octets="312151" target="https://www.isc.org/sw/dhcp/drafts/draft-ietf-dhc-failover-12.txt"/> + </reference> + + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-dhcpv4-relay-encapsulation-00.xml'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-dhcpv4-bulk-leasequery-03.xml'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-leasequery-by-remote-id-09.xml'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-relay-id-suboption-07.xml'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mip6-hiopt-17.xml'?> + + </references> + + <references title="Published Common (DHCPv4/DHCPv6) References"> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4280'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4477'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4578'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4776'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4833'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5417'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5678'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5908'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5970'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5986'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-vpn-option-12.xml'?> + + </references> + + <references title="Published DHCPv6 References"> + + &rfc3315; + &rfc3319; + &rfc3633; + &rfc3646; + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.3736'?> + &rfc3898; + &rfc4075; + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4076'?> + &rfc4242; + &rfc4580; + &rfc4649; + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4704'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.4994'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5007'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml/reference.RFC.5460'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mif-dhcpv6-route-option'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv6-ldra'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-dhc-dhcpv6-relay-supplied-options'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-pd-exclude-01.xml'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-secure-dhcpv6-02.xml'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mext-nemo-pd'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dhc-duid-uuid-03.xml'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-softwire-ds-lite-tunnel-option-10.xml'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-mif-dns-server-selection-01.xml'?> + <?rfc include='http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-geopriv-rfc3825bis-17.xml'?> + + <reference anchor='draft-addr-params'> + <front> + <title>Address Parameters Option for DHCPv6</title> + <author initials='T.' surname='Mrugalski' fullname='Mrugalski'> + <organization abbrev='Cisco'>Gdansk University of Technology</organization> + </author> + <date month='April' year='2007'/> + </front> + <format type="TXT" target="http://klub.com.pl/dhcpv6/doc/draft-mrugalski-addropts-XX-2007-04-17.txt"/> + </reference> + + </references> + </back> +</rfc> |