diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/IANA-arp-parameters | 145 | ||||
| -rw-r--r-- | doc/Makefile | 44 | ||||
| -rw-r--r-- | doc/References.html | 1037 | ||||
| -rw-r--r-- | doc/References.txt | 1176 | ||||
| -rw-r--r-- | doc/References.xml | 795 | ||||
| -rw-r--r-- | doc/api+protocol | 436 | ||||
| -rw-r--r-- | doc/devel/arch.dox | 11 | ||||
| -rw-r--r-- | doc/devel/atf.dox | 218 | ||||
| -rw-r--r-- | doc/devel/contrib.dox | 12 | ||||
| -rw-r--r-- | doc/devel/debug.dox | 33 | ||||
| -rw-r--r-- | doc/devel/doxyfile.in | 1792 | ||||
| -rw-r--r-- | doc/devel/isc-logo.jpg | bin | 0 -> 4452 bytes | |||
| -rw-r--r-- | doc/devel/mainpage.dox | 41 | ||||
| -rw-r--r-- | doc/devel/omapi.dox | 15 | ||||
| -rw-r--r-- | doc/devel/qa.dox | 93 | ||||
| -rw-r--r-- | doc/examples/dhclient-dhcpv6.conf | 11 | ||||
| -rw-r--r-- | doc/examples/dhcpd-dhcpv6.conf | 106 | ||||
| -rw-r--r-- | doc/ja_JP.eucJP/dhclient-script.8 | 242 | ||||
| -rw-r--r-- | doc/ja_JP.eucJP/dhclient.8 | 365 | ||||
| -rw-r--r-- | doc/ja_JP.eucJP/dhclient.conf.5 | 625 | ||||
| -rw-r--r-- | doc/ja_JP.eucJP/dhclient.leases.5 | 62 | ||||
| -rw-r--r-- | doc/ja_JP.eucJP/dhcp-eval.5 | 488 | ||||
| -rw-r--r-- | doc/ja_JP.eucJP/dhcp-options.5 | 1582 |
23 files changed, 9329 insertions, 0 deletions
diff --git a/doc/IANA-arp-parameters b/doc/IANA-arp-parameters new file mode 100644 index 0000000..9fa8f11 --- /dev/null +++ b/doc/IANA-arp-parameters @@ -0,0 +1,145 @@ + + +ADDRESS RESOLUTION PROTOCOL PARAMETERS + +The Address Resolution Protocol (ARP) specified in [RFC826] has +several parameters. The assigned values for these parameters are +listed here. + +REVERSE ADDRESS RESOLUTION PROTOCOL OPERATION CODES + +The Reverse Address Resolution Protocol (RARP) specified in [RFC903] +uses the "Reverse" codes below. + +DYNAMIC REVERSE ARP + +The Dynamic Reverse Address Resolution Protocol (DRARP) uses the +"DRARP" codes below. For further information, contact: David Brownell +(suneast!helium!db@Sun.COM). + +INVERSE ADDRESS RESOULUTION PROTOCOL + +The Inverse Address Resolution Protocol (IARP) specified in [RFC1293] +uses the "InARP" codes below. + +Assignments: + +Number Operation Code (op) References +------ -------------------------- ---------- + 1 REQUEST [RFC826] + 2 REPLY [RFC826] + 3 request Reverse [RFC903] + 4 reply Reverse [RFC903] + 5 DRARP-Request [David Brownell] + 6 DRARP-Reply [David Brownell] + 7 DRARP-Error [David Brownell] + 8 InARP-Request [RFC1293] + 9 InARP-Reply [RFC1293] + 10 ARP-NAK [RFC1577] + 11 MARS-Request [Armitage] + 12 MARS-Multi [Armitage] + 13 MARS-MServ [Armitage] + 14 MARS-Join [Armitage] + 15 MARS-Leave [Armitage] + 16 MARS-NAK [Armitage] + 17 MARS-Unserv [Armitage] + 18 MARS-SJoin [Armitage] + 19 MARS-SLeave [Armitage] + 20 MARS-Grouplist-Request [Armitage] + 21 MARS-Grouplist-Reply [Armitage] + 22 MARS-Redirect-Map [Armitage] + 23 MAPOS-UNARP [Maruyama] + + +Number Hardware Type (hrd) References +------ ----------------------------------- ---------- + 1 Ethernet (10Mb) [JBP] + 2 Experimental Ethernet (3Mb) [JBP] + 3 Amateur Radio AX.25 [PXK] + 4 Proteon ProNET Token Ring [Doria] + 5 Chaos [GXP] + 6 IEEE 802 Networks [JBP] + 7 ARCNET [JBP] + 8 Hyperchannel [JBP] + 9 Lanstar [TU] + 10 Autonet Short Address [MXB1] + 11 LocalTalk [JKR1] + 12 LocalNet (IBM PCNet or SYTEK LocalNET) [JXM] + 13 Ultra link [RXD2] + 14 SMDS [GXC1] + 15 Frame Relay [AGM] + 16 Asynchronous Transmission Mode (ATM) [JXB2] + 17 HDLC [JBP] + 18 Fibre Channel [Yakov Rekhter] + 19 Asynchronous Transmission Mode (ATM) [RFC1577] + 20 Serial Line [JBP] + 21 Asynchronous Transmission Mode (ATM) [MXB1] + 22 MIL-STD-188-220 [Jensen] + 23 Metricom [Stone] + 24 IEEE 1394.1995 [Hattig] + 25 MAPOS [Maruyama] + +Protocol Type (pro) + +Use the same codes as listed in the section called "Ethernet Numbers +of Interest" (all hardware types use this code set for the protocol +type). + + +REFERENCES + +[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol or + Converting Network Protocol Addresses to 48-bit Ethernet + Addresses for Transmission on Ethernet Hardware", STD 37, RFC + 826, MIT-LCS, November 1982. + +[RFC903] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "A + Reverse Address Resolution Protocol", STD 38, RFC 903, + Stanford University, June 1984. + +[RFC1293] Bradley, T., and C. Brown, "Inverse Address Resolution + Protocol", RFC 1293, Wellfleet Communications, Inc., + January 1992. + + +PEOPLE + +[Armitage] Grenville Armitage, <gja@thumper.belcore.com>, April 1995. + +[AGM] Andy Malis <malis_a@timeplex.com> + +[GXC1] George Clapp <meritec!clapp@bellcore.bellcore.com> + +[Doria] Avri Doria <avri@peoteon.com> December 1994. + +[GXP] Gill Pratt <gill%mit-ccc@MC.LCS.MIT.EDU> + +[Jensen] Herb Jensen, <hwjensen@itt.com>, February 1995. + +[JBP] Jon Postel <postel@isi.edu> + +[JKR1] Joyce K. Reynolds <jkrey@isi.edu> + +[JXM] Joseph Murdock <---none---> + +[Hattig] Myron Hattig, <Myron_Hattig@ccm.jf.intel.com>, February 1997. + +[Maruyama] Mitsuru Maruyama, <mitsuru@ntt-20.ecl.net>, March 1997. + +[MXB1] Mike Burrows <burrows@SRC.DEC.COM> + +[PXK] Philip Koch <Philip.Koch@DARTMOUTH.EDU> + +[RXD2] Rajiv Dhingra <rajiv@ULTRA.COM> + +[Stone] Jonathan Stone, <jonathan@DSG.Stanford.edu>, May 1996. + +[TU] Tom Unger <tom@CITI.UMICH> + +[David Brownell] + +[Mark Laubach] + +[Yakov Rekhter] <Yakov@IBM.COM> + +[] diff --git a/doc/Makefile b/doc/Makefile new file mode 100644 index 0000000..60a48fd --- /dev/null +++ b/doc/Makefile @@ -0,0 +1,44 @@ +# Copyright (c) 2004-2006,2009 by Internet Systems Consortium, Inc. ("ISC") +# Copyright (c) 1995-2003 by Internet Software Consortium +# +# 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. +# +# 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. +# +# Internet Systems Consortium, Inc. +# 950 Charter Street +# Redwood City, CA 94063 +# <info@isc.org> +# https://www.isc.org/ + +all: References.txt References.html + +References.txt: References.xml + xml2txt References.xml + +References.html: References.xml + xml2html References.xml + +devel: + mkdir -p html + doxygen devel/doxyfile > html/doxygen.log 2>html/doxygen-warnings.log + +cppcheck: + mkdir -p html + cd .. && cppcheck --enable=all --inline-suppr \ + -f -v -j 2 -i tests/ -i dhcp-*/ \ + . 1> doc/html/cppcheck.log 2> doc/html/cppcheck-error.log + +# cppcheck can be extended with list of suppressions. +# --suppressions-list=doc/cppcheck-skip.txt \ + + +.PHONY: devel cppcheck
\ No newline at end of file diff --git a/doc/References.html b/doc/References.html new file mode 100644 index 0000000..b20b5aa --- /dev/null +++ b/doc/References.html @@ -0,0 +1,1037 @@ +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> +<html lang="en"><head><title>ISC-DHCP-REFERENCES: ISC DHCP References Collection</title> +<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> +<meta name="description" content="ISC DHCP References Collection"> +<meta name="keywords" content="ISC, DHCP, Reference Implementation"> +<meta name="generator" content="xml2rfc v1.36 (http://xml.resource.org/)"> +<style type='text/css'><!-- + body { + font-family: verdana, charcoal, helvetica, arial, sans-serif; + font-size: small; color: #000; background-color: #FFF; + margin: 2em; + } + h1, h2, h3, h4, h5, h6 { + font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif; + font-weight: bold; font-style: normal; + } + h1 { color: #900; background-color: transparent; text-align: right; } + h3 { color: #333; background-color: transparent; } + + td.RFCbug { + font-size: x-small; text-decoration: none; + width: 30px; height: 30px; padding-top: 2px; + text-align: justify; vertical-align: middle; + background-color: #000; + } + td.RFCbug span.RFC { + font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; + font-weight: bold; color: #666; + } + td.RFCbug span.hotText { + font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif; + font-weight: normal; text-align: center; color: #FFF; + } + + table.TOCbug { width: 30px; height: 15px; } + td.TOCbug { + text-align: center; width: 30px; height: 15px; + color: #FFF; background-color: #900; + } + td.TOCbug a { + font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif; + font-weight: bold; font-size: x-small; text-decoration: none; + color: #FFF; background-color: transparent; + } + + td.header { + font-family: arial, helvetica, sans-serif; font-size: x-small; + vertical-align: top; width: 33%; + color: #FFF; background-color: #666; + } + td.author { font-weight: bold; font-size: x-small; margin-left: 4em; } + td.author-text { font-size: x-small; } + + /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */ + a.info { + /* This is the key. */ + position: relative; + z-index: 24; + text-decoration: none; + } + a.info:hover { + z-index: 25; + color: #FFF; background-color: #900; + } + a.info span { display: none; } + a.info:hover span.info { + /* The span will display just on :hover state. */ + display: block; + position: absolute; + font-size: smaller; + top: 2em; left: -5em; width: 15em; + padding: 2px; border: 1px solid #333; + color: #900; background-color: #EEE; + text-align: left; + } + + a { font-weight: bold; } + a:link { color: #900; background-color: transparent; } + a:visited { color: #633; background-color: transparent; } + a:active { color: #633; background-color: transparent; } + + p { margin-left: 2em; margin-right: 2em; } + p.copyright { font-size: x-small; } + p.toc { font-size: small; font-weight: bold; margin-left: 3em; } + table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; } + td.toc { font-size: small; font-weight: bold; vertical-align: text-top; } + + ol.text { margin-left: 2em; margin-right: 2em; } + ul.text { margin-left: 2em; margin-right: 2em; } + li { margin-left: 3em; } + + /* RFC-2629 <spanx>s and <artwork>s. */ + em { font-style: italic; } + strong { font-weight: bold; } + dfn { font-weight: bold; font-style: normal; } + cite { font-weight: normal; font-style: normal; } + tt { color: #036; } + tt, pre, pre dfn, pre em, pre cite, pre span { + font-family: "Courier New", Courier, monospace; font-size: small; + } + pre { + text-align: left; padding: 4px; + color: #000; background-color: #CCC; + } + pre dfn { color: #900; } + pre em { color: #66F; background-color: #FFC; font-weight: normal; } + pre .key { color: #33C; font-weight: bold; } + pre .id { color: #900; } + pre .str { color: #000; background-color: #CFF; } + pre .val { color: #066; } + pre .rep { color: #909; } + pre .oth { color: #000; background-color: #FCF; } + pre .err { background-color: #FCC; } + + /* RFC-2629 <texttable>s. */ + table.all, table.full, table.headers, table.none { + font-size: small; text-align: center; border-width: 2px; + vertical-align: top; border-collapse: collapse; + } + table.all, table.full { border-style: solid; border-color: black; } + table.headers, table.none { border-style: none; } + th { + font-weight: bold; border-color: black; + border-width: 2px 2px 3px 2px; + } + table.all th, table.full th { border-style: solid; } + table.headers th { border-style: none none solid none; } + table.none th { border-style: none; } + table.all td { + border-style: solid; border-color: #333; + border-width: 1px 2px; + } + table.full td, table.headers td, table.none td { border-style: none; } + + hr { height: 1px; } + hr.insert { + width: 80%; border-style: none; border-width: 0; + color: #CCC; background-color: #CCC; + } +--></style> +</head> +<body> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1"> +<tr><td class="header">ISC-DHCP-REFERENCES</td><td class="header">D. Hankins</td></tr> +<tr><td class="header"> </td><td class="header">T. Mrugalski</td></tr> +<tr><td class="header"> </td><td class="header">ISC</td></tr> +<tr><td class="header"> </td><td class="header">January 04, 2012</td></tr> +</table></td></tr></table> +<h1><br />ISC DHCP References Collection</h1> + +<h3>Abstract</h3> + +<p>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. +</p> +<h3>Copyright Notice</h3> + +<p>Copyright (c) 2006-2007,2009,2011 by Internet Systems + Consortium, Inc. ("ISC") +</p> +<p>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. +</p> +<p>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. +</p><a name="toc"></a><br /><hr /> +<h3>Table of Contents</h3> +<p class="toc"> +<a href="#anchor1">1.</a> +Introduction<br /> +<br /> +<a href="#anchor2">2.</a> +Definition: Reference Implementation<br /> +<br /> +<a href="#anchor3">3.</a> +Low Layer References<br /> + <a href="#anchor4">3.1.</a> +Ethernet Protocol References<br /> + <a href="#anchor5">3.2.</a> +Token Ring Protocol References<br /> + <a href="#anchor6">3.3.</a> +FDDI Protocol References<br /> + <a href="#anchor7">3.4.</a> +Internet Protocol Version 4 References<br /> + <a href="#anchor8">3.5.</a> +Unicast Datagram Protocol References<br /> +<br /> +<a href="#anchor9">4.</a> +BOOTP Protocol References<br /> +<br /> +<a href="#anchor10">5.</a> +DHCPv4 Protocol References<br /> + <a href="#anchor11">5.1.</a> +DHCPv4 Protocol<br /> + <a href="#anchor12">5.1.1.</a> +Core Protocol References<br /> + <a href="#anchor13">5.2.</a> +DHCPv4 Option References<br /> + <a href="#anchor14">5.2.1.</a> +Relay Agent Information Option Options<br /> + <a href="#anchor15">5.2.2.</a> +Dynamic DNS Updates References<br /> + <a href="#anchor16">5.2.3.</a> +Experimental: Failover References<br /> + <a href="#anchor17">5.3.</a> +DHCP Procedures<br /> +<br /> +<a href="#anchor18">6.</a> +DHCPv6 Protocol References<br /> + <a href="#anchor19">6.1.</a> +DHCPv6 Protocol References<br /> + <a href="#anchor20">6.2.</a> +DHCPv6 Options References<br /> +<br /> +<a href="#rfc.references1">7.</a> +References<br /> + <a href="#rfc.references1">7.1.</a> +Published DHCPv4 References<br /> + <a href="#rfc.references2">7.2.</a> +Published Common (DHCPv4/DHCPv6) References<br /> + <a href="#rfc.references3">7.3.</a> +Published DHCPv6 References<br /> +<br /> +<a href="#rfc.authors">§</a> +Authors' Addresses<br /> +</p> +<br clear="all" /> + +<a name="anchor1"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.1"></a><h3>1. +Introduction</h3> + +<p>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). +</p> +<p>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. +</p> +<a name="anchor2"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.2"></a><h3>2. +Definition: Reference Implementation</h3> + +<p>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. +</p> +<p>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." +</p> +<p>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. +</p> +<p>Anything else is a bug, the only question is whether the + bug is in reference or software (failing to implement the + reference). +</p> +<p>This means: +</p> +<p> + </p> +<ul class="text"> +<li>To produce new externally-visible behaviour, one must first + provide a reference. +</li> +<li>Before changing externally visible behaviour to work around + simple incompatibilities in any other implementation, one must + first provide a reference. +</li> +</ul><p> + +</p> +<p>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. +</p> +<p>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". +</p> +<p>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. +</p> +<a name="anchor3"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.3"></a><h3>3. +Low Layer References</h3> + +<p>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. +</p> +<p>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. +</p> +<p>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 <a class='info' href='#RFC2131'>[RFC2131]<span> (</span><span class='info'>Droms, R., “Dynamic Host Configuration Protocol,” March 1997.</span><span>)</span></a>. + + </p> +<ol class="text"> +<li>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. +</li> +<li>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. +</li> +<li>Transmit a UDP packet from IP:Self, Ethernet:Self, destined to + IP:remote-system LinkLayer:remote-system, without transmitting a + single ARP. +</li> +<li>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. +</li> +</ol> + +<p>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, <a class='info' href='#RFC2131'>[RFC2131]<span> (</span><span class='info'>Droms, R., “Dynamic Host Configuration Protocol,” March 1997.</span><span>)</span></a> + very explicitly demands that these packets' IP destination + addresses be set to 255.255.255.255. +</p> +<p>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. +</p> +<p>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. +</p> +<p>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. +</p> +<p>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. +</p> +<a name="anchor4"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.3.1"></a><h3>3.1. +Ethernet Protocol References</h3> + +<p>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 <a class='info' href='#RFC0894'>[RFC0894]<span> (</span><span class='info'>Hornig, C., “Standard for the transmission of IP datagrams over Ethernet networks,” April 1984.</span><span>)</span></a> + see the section titled "Packet format"), and + the following URL is also thought to be useful. +</p> +<p><a href='http://en.wikipedia.org/wiki/DIX_Ethernet'>http://en.wikipedia.org/wiki/DIX_Ethernet</a> +</p> +<a name="anchor5"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.3.2"></a><h3>3.2. +Token Ring Protocol References</h3> + +<p>IEEE 802.5 defines the Token Ring framing format used by ISC + DHCP. +</p> +<a name="anchor6"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.3.3"></a><h3>3.3. +FDDI Protocol References</h3> + +<p><a class='info' href='#RFC1188'>[RFC1188]<span> (</span><span class='info'>Katz, D., “Proposed Standard for the Transmission of IP Datagrams over FDDI Networks,” October 1990.</span><span>)</span></a> is the most helpful + reference ISC DHCP has used to form FDDI packets. +</p> +<a name="anchor7"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.3.4"></a><h3>3.4. +Internet Protocol Version 4 References</h3> + +<p><a class='info' href='#RFC0760'>RFC760<span> (</span><span class='info'>Postel, J., “DoD standard Internet Protocol,” January 1980.</span><span>)</span></a> [RFC0760] fundamentally defines the + bare IPv4 protocol which ISC DHCP implements. +</p> +<a name="anchor8"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.3.5"></a><h3>3.5. +Unicast Datagram Protocol References</h3> + +<p><a class='info' href='#RFC0768'>RFC768<span> (</span><span class='info'>Postel, J., “User Datagram Protocol,” August 1980.</span><span>)</span></a> [RFC0768] 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. +</p> +<a name="anchor9"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.4"></a><h3>4. +BOOTP Protocol References</h3> + +<p>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. +</p> +<p>The ISC DHCP server supports BOOTP clients conforming to + <a class='info' href='#RFC0951'>RFC951<span> (</span><span class='info'>Croft, B. and J. Gilmore, “Bootstrap Protocol,” September 1985.</span><span>)</span></a> [RFC0951] and <a class='info' href='#RFC1542'>RFC1542<span> (</span><span class='info'>Wimer, W., “Clarifications and Extensions for the Bootstrap Protocol,” October 1993.</span><span>)</span></a> [RFC1542]. +</p> +<a name="anchor10"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.5"></a><h3>5. +DHCPv4 Protocol References</h3> + +<a name="anchor11"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.5.1"></a><h3>5.1. +DHCPv4 Protocol</h3> + +<p>"The DHCP[v4] Protocol" is not defined in a single document. The + following collection of references of what ISC DHCP terms "The + DHCPv4 Protocol". +</p> +<a name="anchor12"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.5.1.1"></a><h3>5.1.1. +Core Protocol References</h3> + +<p><a class='info' href='#RFC2131'>RFC2131<span> (</span><span class='info'>Droms, R., “Dynamic Host Configuration Protocol,” March 1997.</span><span>)</span></a> [RFC2131] 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. +</p> +<p><a class='info' href='#RFC2132'>RFC2132<span> (</span><span class='info'>Alexander, S. and R. Droms, “DHCP Options and BOOTP Vendor Extensions,” March 1997.</span><span>)</span></a> [RFC2132] 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. +</p> +<a name="anchor13"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.5.2"></a><h3>5.2. +DHCPv4 Option References</h3> + +<p><a class='info' href='#RFC2241'>RFC2241<span> (</span><span class='info'>Provan, D., “DHCP Options for Novell Directory Services,” November 1997.</span><span>)</span></a> [RFC2241] defines options for + Novell Directory Services. +</p> +<p><a class='info' href='#RFC2242'>RFC2242<span> (</span><span class='info'>Droms, R. and K. Fong, “NetWare/IP Domain Name and Information,” November 1997.</span><span>)</span></a> [RFC2242] defines an encapsulated + option space for NWIP configuration. +</p> +<p><a class='info' href='#RFC2485'>RFC2485<span> (</span><span class='info'>Drach, S., “DHCP Option for The Open Group's User Authentication Protocol,” January 1999.</span><span>)</span></a> [RFC2485] defines the Open Group's + UAP option. +</p> +<p><a class='info' href='#RFC2610'>RFC2610<span> (</span><span class='info'>Perkins, C. and E. Guttman, “DHCP Options for Service Location Protocol,” June 1999.</span><span>)</span></a> [RFC2610] defines options for + the Service Location Protocol (SLP). +</p> +<p><a class='info' href='#RFC2937'>RFC2937<span> (</span><span class='info'>Smith, C., “The Name Service Search Option for DHCP,” September 2000.</span><span>)</span></a> [RFC2937] 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. +</p> +<p><a class='info' href='#RFC3004'>RFC3004<span> (</span><span class='info'>Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A., Beser, B., and J. Privat, “The User Class Option for DHCP,” November 2000.</span><span>)</span></a> [RFC3004] 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. +</p> +<p><a class='info' href='#RFC3011'>RFC3011<span> (</span><span class='info'>Waters, G., “The IPv4 Subnet Selection Option for DHCP,” November 2000.</span><span>)</span></a> [RFC3011] 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. +</p> +<p><a class='info' href='#RFC3396'>RFC3396<span> (</span><span class='info'>Lemon, T. and S. Cheshire, “Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4),” November 2002.</span><span>)</span></a> [RFC3396] 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. +</p> +<p><a class='info' href='#RFC3397'>RFC3397<span> (</span><span class='info'>Aboba, B. and S. Cheshire, “Dynamic Host Configuration Protocol (DHCP) Domain Search Option,” November 2002.</span><span>)</span></a> [RFC3397] documents the Domain-Search + Option, which allows the configuration of the /etc/resolv.conf + 'search' parameter in a way that is <a class='info' href='#RFC1035'>RFC1035<span> (</span><span class='info'>Mockapetris, P., “Domain names - implementation and specification,” November 1987.</span><span>)</span></a> [RFC1035] wire format compatible (in fact, it uses the RFC1035 wire + format). ISC DHCP has both client and server support, and supports + RFC1035 name compression. +</p> +<p><a class='info' href='#RFC3679'>RFC3679<span> (</span><span class='info'>Droms, R., “Unused Dynamic Host Configuration Protocol (DHCP) Option Codes,” January 2004.</span><span>)</span></a> [RFC3679] documents a number of + options that were documented earlier in history, but were not + made use of. +</p> +<p><a class='info' href='#RFC3925'>RFC3925<span> (</span><span class='info'>Littlefield, J., “Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4),” October 2004.</span><span>)</span></a> [RFC3925] 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. +</p> +<p><a class='info' href='#RFC3942'>RFC3942<span> (</span><span class='info'>Volz, B., “Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options,” November 2004.</span><span>)</span></a> [RFC3942] redefined the 'site local' + option space. +</p> +<p><a class='info' href='#RFC4280'>[RFC4280]<span> (</span><span class='info'>Chowdhury, K., Yegani, P., and L. Madour, “Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers,” November 2005.</span><span>)</span></a> defines two BCMS server options + for each protocol family. +</p> +<p><a class='info' href='#RFC4388'>RFC4388<span> (</span><span class='info'>Woundy, R. and K. Kinnear, “Dynamic Host Configuration Protocol (DHCP) Leasequery,” February 2006.</span><span>)</span></a> [RFC4388] 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. +</p> +<a name="anchor14"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.5.2.1"></a><h3>5.2.1. +Relay Agent Information Option Options</h3> + +<p><a class='info' href='#RFC3046'>RFC3046<span> (</span><span class='info'>Patrick, M., “DHCP Relay Agent Information Option,” January 2001.</span><span>)</span></a> [RFC3046] defines the Relay Agent + Information Option and provides a number of sub-option + definitions. +</p> +<p><a class='info' href='#RFC3256'>RFC3256<span> (</span><span class='info'>Jones, D. and R. Woundy, “The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option,” April 2002.</span><span>)</span></a> [RFC3256] defines the DOCSIS Device + Class sub-option. +</p> +<p><a class='info' href='#RFC3527'>RFC3527<span> (</span><span class='info'>Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, “Link Selection sub-option for the Relay Agent Information Option for DHCPv4,” April 2003.</span><span>)</span></a> [RFC3527] defines the Link Selection + sub-option. +</p> +<a name="anchor15"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.5.2.2"></a><h3>5.2.2. +Dynamic DNS Updates References</h3> + +<p>The collection of documents that describe the standards-based + method to update dns names of DHCP clients starts most easily + with <a class='info' href='#RFC4703'>RFC4703<span> (</span><span class='info'>Stapp, M. and B. Volz, “Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients,” October 2006.</span><span>)</span></a> [RFC4703] to define the overall + architecture, travels through RFCs <a class='info' href='#RFC4702'>4702<span> (</span><span class='info'>Stapp, M., Volz, B., and Y. Rekhter, “The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option,” October 2006.</span><span>)</span></a> [RFC4702] + and <a class='info' href='#RFC4704'>4704<span> (</span><span class='info'>Volz, B., “The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option,” October 2006.</span><span>)</span></a> [RFC4704] to describe the DHCPv4 and + DHCPv6 FQDN options (to carry the client name), and ends up at + <a class='info' href='#RFC4701'>RFC4701<span> (</span><span class='info'>Stapp, M., Lemon, T., and A. Gustafsson, “A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR),” October 2006.</span><span>)</span></a> [RFC4701] which describes the DHCID + RR used in DNS to perform a kind of atomic locking. +</p> +<p>ISC DHCP adopted early versions of these documents, and has not + yet synchronized with the final standards versions. +</p> +<p>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. +</p> +<p>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. +</p> +<a name="anchor16"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.5.2.3"></a><h3>5.2.3. +Experimental: Failover References</h3> + +<p>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. +</p> +<p>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. +</p> +<p>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. +</p> +<p><a class='info' href='#draft-failover'>draft-ietf-dhc-failover-12.txt<span> (</span><span class='info'>Droms, R., “DHCP Failover Protocol,” March 2003.</span><span>)</span></a> [draft‑failover] + 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. +</p> +<p> 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. + +</p> +<p><a class='info' href='#RFC3074'>[RFC3074]<span> (</span><span class='info'>Volz, B., Gonczi, S., Lemon, T., and R. Stevens, “DHC Load Balancing Algorithm,” February 2001.</span><span>)</span></a> 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). +</p> +<a name="anchor17"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.5.3"></a><h3>5.3. +DHCP Procedures</h3> + +<p><a class='info' href='#RFC2939'>[RFC2939]<span> (</span><span class='info'>Droms, R., “Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types,” September 2000.</span><span>)</span></a> explains how to go about + obtaining a new DHCP Option code assignment. +</p> +<a name="anchor18"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.6"></a><h3>6. +DHCPv6 Protocol References</h3> + +<a name="anchor19"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.6.1"></a><h3>6.1. +DHCPv6 Protocol References</h3> + +<p>For now there is only one document that specifies the base + of the DHCPv6 protocol (there have been no updates yet), + <a class='info' href='#RFC3315'>[RFC3315]<span> (</span><span class='info'>Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” July 2003.</span><span>)</span></a>. +</p> +<p>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. +</p> +<p>DHCPv6 introduces some new and uncomfortable ideas to the common + software library. +</p> +<p> + </p> +<ol class="text"> +<li>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. +</li> +<li>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. +</li> +</ol><p> + +</p> +<p>Precisely how to correctly support the above conundrums has not + quite yet been settled, so support is incomplete. +</p> +<p><a class='info' href='#RFC5453'>[RFC5453]<span> (</span><span class='info'>Krishnan, S., “Reserved IPv6 Interface Identifiers,” February 2009.</span><span>)</span></a> creates a registry at IANA to reserve + interface identifiers and specifies a starting set. These IIDs should + not be used when constructing addresses to avoid possible conflicts. +</p> +<a name="anchor20"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.6.2"></a><h3>6.2. +DHCPv6 Options References</h3> + +<p><a class='info' href='#RFC3319'>[RFC3319]<span> (</span><span class='info'>Schulzrinne, H. and B. Volz, “Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers,” July 2003.</span><span>)</span></a> defines the SIP server + options for DHCPv6. +</p> +<p><a class='info' href='#RFC3646'>[RFC3646]<span> (</span><span class='info'>Droms, R., “DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” December 2003.</span><span>)</span></a> documents the DHCPv6 + name-servers and domain-search options. +</p> +<p><a class='info' href='#RFC3633'>[RFC3633]<span> (</span><span class='info'>Troan, O. and R. Droms, “IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6,” December 2003.</span><span>)</span></a> documents the Identity + Association Prefix Delegation for DHCPv6, which is included + here for protocol wire reference, but which is not supported + by ISC DHCP. +</p> +<p><a class='info' href='#RFC3898'>[RFC3898]<span> (</span><span class='info'>Kalusivalingam, V., “Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” October 2004.</span><span>)</span></a> documents four NIS options + for delivering NIS servers and domain information in DHCPv6. +</p> +<p><a class='info' href='#RFC4075'>[RFC4075]<span> (</span><span class='info'>Kalusivalingam, V., “Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6,” May 2005.</span><span>)</span></a> defines the DHCPv6 SNTP + Servers option. +</p> +<p><a class='info' href='#RFC4242'>[RFC4242]<span> (</span><span class='info'>Venaas, S., Chown, T., and B. Volz, “Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6),” November 2005.</span><span>)</span></a> defines the Information + Refresh Time option, which advises DHCPv6 Information-Request + clients to return for updated information. +</p> +<p><a class='info' href='#RFC4280'>[RFC4280]<span> (</span><span class='info'>Chowdhury, K., Yegani, P., and L. Madour, “Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers,” November 2005.</span><span>)</span></a> defines two BCMS server options + for each protocol family. +</p> +<p><a class='info' href='#RFC4580'>[RFC4580]<span> (</span><span class='info'>Volz, B., “Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option,” June 2006.</span><span>)</span></a> defines a DHCPv6 + subscriber-id option, which is similar in principle to the DHCPv4 + relay agent option of the same name. +</p> +<p><a class='info' href='#RFC4649'>[RFC4649]<span> (</span><span class='info'>Volz, B., “Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option,” August 2006.</span><span>)</span></a> defines a DHCPv6 remote-id + option, which is similar in principle to the DHCPv4 relay agent + remote-id. +</p> +<a name="rfc.references"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<a name="rfc.section.7"></a><h3>7. +References</h3> + +<a name="rfc.references1"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<h3>7.1. Published DHCPv4 References</h3> +<table width="99%" border="0"> +<tr><td class="author-text" valign="top"><a name="RFC0760">[RFC0760]</a></td> +<td class="author-text">Postel, J., “<a href="http://tools.ietf.org/html/rfc760">DoD standard Internet Protocol</a>,” RFC 760, January 1980 (<a href="http://www.rfc-editor.org/rfc/rfc760.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC0768">[RFC0768]</a></td> +<td class="author-text">Postel, J., “<a href="http://tools.ietf.org/html/rfc768">User Datagram Protocol</a>,” STD 6, RFC 768, August 1980 (<a href="http://www.rfc-editor.org/rfc/rfc768.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC0894">[RFC0894]</a></td> +<td class="author-text">Hornig, C., “<a href="http://tools.ietf.org/html/rfc894">Standard for the transmission of IP datagrams over Ethernet networks</a>,” STD 41, RFC 894, April 1984 (<a href="http://www.rfc-editor.org/rfc/rfc894.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC0951">[RFC0951]</a></td> +<td class="author-text">Croft, B. and J. Gilmore, “<a href="http://tools.ietf.org/html/rfc951">Bootstrap Protocol</a>,” RFC 951, September 1985 (<a href="http://www.rfc-editor.org/rfc/rfc951.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC1035">[RFC1035]</a></td> +<td class="author-text">Mockapetris, P., “<a href="http://tools.ietf.org/html/rfc1035">Domain names - implementation and specification</a>,” STD 13, RFC 1035, November 1987 (<a href="http://www.rfc-editor.org/rfc/rfc1035.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC1188">[RFC1188]</a></td> +<td class="author-text"><a href="mailto:dkatz@merit.edu">Katz, D.</a>, “<a href="http://tools.ietf.org/html/rfc1188">Proposed Standard for the Transmission of IP Datagrams over FDDI Networks</a>,” RFC 1188, October 1990 (<a href="http://www.rfc-editor.org/rfc/rfc1188.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC1542">[RFC1542]</a></td> +<td class="author-text"><a href="mailto:Walter.Wimer@CMU.EDU">Wimer, W.</a>, “<a href="http://tools.ietf.org/html/rfc1542">Clarifications and Extensions for the Bootstrap Protocol</a>,” RFC 1542, October 1993 (<a href="http://www.rfc-editor.org/rfc/rfc1542.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2131">[RFC2131]</a></td> +<td class="author-text"><a href="mailto:droms@bucknell.edu">Droms, R.</a>, “<a href="http://tools.ietf.org/html/rfc2131">Dynamic Host Configuration Protocol</a>,” RFC 2131, March 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2131.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2131.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2131.xml">XML</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2132">[RFC2132]</a></td> +<td class="author-text"><a href="mailto:sca@engr.sgi.com">Alexander, S.</a> and <a href="mailto:droms@bucknell.edu">R. Droms</a>, “<a href="http://tools.ietf.org/html/rfc2132">DHCP Options and BOOTP Vendor Extensions</a>,” RFC 2132, March 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2132.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2132.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2132.xml">XML</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2241">[RFC2241]</a></td> +<td class="author-text"><a href="mailto:donp@Novell.Com">Provan, D.</a>, “<a href="http://tools.ietf.org/html/rfc2241">DHCP Options for Novell Directory Services</a>,” RFC 2241, November 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2241.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2241.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2241.xml">XML</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2242">[RFC2242]</a></td> +<td class="author-text"><a href="mailto:droms@bucknell.edu">Droms, R.</a> and <a href="mailto:kfong@novell.com">K. Fong</a>, “<a href="http://tools.ietf.org/html/rfc2242">NetWare/IP Domain Name and Information</a>,” RFC 2242, November 1997 (<a href="http://www.rfc-editor.org/rfc/rfc2242.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2242.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2242.xml">XML</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2485">[RFC2485]</a></td> +<td class="author-text"><a href="mailto:drach@sun.com">Drach, S.</a>, “<a href="http://tools.ietf.org/html/rfc2485">DHCP Option for The Open Group's User Authentication Protocol</a>,” RFC 2485, January 1999 (<a href="http://www.rfc-editor.org/rfc/rfc2485.txt">TXT</a>, <a href="http://xml.resource.org/public/rfc/html/rfc2485.html">HTML</a>, <a href="http://xml.resource.org/public/rfc/xml/rfc2485.xml">XML</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2563">[RFC2563]</a></td> +<td class="author-text"><a href="mailto:rtroll@corp.home.net">Troll, R.</a>, “<a href="http://tools.ietf.org/html/rfc2563">DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients</a>,” RFC 2563, May 1999 (<a href="http://www.rfc-editor.org/rfc/rfc2563.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2610">[RFC2610]</a></td> +<td class="author-text"><a href="mailto:Charles.Perkins@Sun.Com">Perkins, C.</a> and <a href="mailto:Erik.Guttman@Sun.Com">E. Guttman</a>, “<a href="http://tools.ietf.org/html/rfc2610">DHCP Options for Service Location Protocol</a>,” RFC 2610, June 1999 (<a href="http://www.rfc-editor.org/rfc/rfc2610.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2855">[RFC2855]</a></td> +<td class="author-text">Fujisawa, K., “<a href="http://tools.ietf.org/html/rfc2855">DHCP for IEEE 1394</a>,” RFC 2855, June 2000 (<a href="http://www.rfc-editor.org/rfc/rfc2855.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2937">[RFC2937]</a></td> +<td class="author-text">Smith, C., “<a href="http://tools.ietf.org/html/rfc2937">The Name Service Search Option for DHCP</a>,” RFC 2937, September 2000 (<a href="http://www.rfc-editor.org/rfc/rfc2937.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC2939">[RFC2939]</a></td> +<td class="author-text">Droms, R., “<a href="http://tools.ietf.org/html/rfc2939">Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types</a>,” BCP 43, RFC 2939, September 2000 (<a href="http://www.rfc-editor.org/rfc/rfc2939.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3004">[RFC3004]</a></td> +<td class="author-text">Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, A., Beser, B., and J. Privat, “<a href="http://tools.ietf.org/html/rfc3004">The User Class Option for DHCP</a>,” RFC 3004, November 2000 (<a href="http://www.rfc-editor.org/rfc/rfc3004.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3011">[RFC3011]</a></td> +<td class="author-text">Waters, G., “<a href="http://tools.ietf.org/html/rfc3011">The IPv4 Subnet Selection Option for DHCP</a>,” RFC 3011, November 2000 (<a href="http://www.rfc-editor.org/rfc/rfc3011.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3046">[RFC3046]</a></td> +<td class="author-text">Patrick, M., “<a href="http://tools.ietf.org/html/rfc3046">DHCP Relay Agent Information Option</a>,” RFC 3046, January 2001 (<a href="http://www.rfc-editor.org/rfc/rfc3046.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3074">[RFC3074]</a></td> +<td class="author-text">Volz, B., Gonczi, S., Lemon, T., and R. Stevens, “<a href="http://tools.ietf.org/html/rfc3074">DHC Load Balancing Algorithm</a>,” RFC 3074, February 2001 (<a href="http://www.rfc-editor.org/rfc/rfc3074.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3118">[RFC3118]</a></td> +<td class="author-text">Droms, R. and W. Arbaugh, “<a href="http://tools.ietf.org/html/rfc3118">Authentication for DHCP Messages</a>,” RFC 3118, June 2001 (<a href="http://www.rfc-editor.org/rfc/rfc3118.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3203">[RFC3203]</a></td> +<td class="author-text">T'Joens, Y., Hublet, C., and P. De Schrijver, “<a href="http://tools.ietf.org/html/rfc3203">DHCP reconfigure extension</a>,” RFC 3203, December 2001 (<a href="http://www.rfc-editor.org/rfc/rfc3203.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3256">[RFC3256]</a></td> +<td class="author-text">Jones, D. and R. Woundy, “<a href="http://tools.ietf.org/html/rfc3256">The DOCSIS (Data-Over-Cable Service Interface Specifications) Device Class DHCP (Dynamic Host Configuration Protocol) Relay Agent Information Sub-option</a>,” RFC 3256, April 2002 (<a href="http://www.rfc-editor.org/rfc/rfc3256.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3361">[RFC3361]</a></td> +<td class="author-text">Schulzrinne, H., “<a href="http://tools.ietf.org/html/rfc3361">Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers</a>,” RFC 3361, August 2002 (<a href="http://www.rfc-editor.org/rfc/rfc3361.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3396">[RFC3396]</a></td> +<td class="author-text">Lemon, T. and S. Cheshire, “<a href="http://tools.ietf.org/html/rfc3396">Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)</a>,” RFC 3396, November 2002 (<a href="http://www.rfc-editor.org/rfc/rfc3396.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3397">[RFC3397]</a></td> +<td class="author-text">Aboba, B. and S. Cheshire, “<a href="http://tools.ietf.org/html/rfc3397">Dynamic Host Configuration Protocol (DHCP) Domain Search Option</a>,” RFC 3397, November 2002 (<a href="http://www.rfc-editor.org/rfc/rfc3397.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3442">[RFC3442]</a></td> +<td class="author-text">Lemon, T., Cheshire, S., and B. Volz, “<a href="http://tools.ietf.org/html/rfc3442">The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4</a>,” RFC 3442, December 2002 (<a href="http://www.rfc-editor.org/rfc/rfc3442.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3456">[RFC3456]</a></td> +<td class="author-text">Patel, B., Aboba, B., Kelly, S., and V. Gupta, “<a href="http://tools.ietf.org/html/rfc3456">Dynamic Host Configuration Protocol (DHCPv4) Configuration of IPsec Tunnel Mode</a>,” RFC 3456, January 2003 (<a href="http://www.rfc-editor.org/rfc/rfc3456.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3495">[RFC3495]</a></td> +<td class="author-text">Beser, B. and P. Duffy, “<a href="http://tools.ietf.org/html/rfc3495">Dynamic Host Configuration Protocol (DHCP) Option for CableLabs Client Configuration</a>,” RFC 3495, March 2003 (<a href="http://www.rfc-editor.org/rfc/rfc3495.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3527">[RFC3527]</a></td> +<td class="author-text">Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, “<a href="http://tools.ietf.org/html/rfc3527">Link Selection sub-option for the Relay Agent Information Option for DHCPv4</a>,” RFC 3527, April 2003 (<a href="http://www.rfc-editor.org/rfc/rfc3527.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3594">[RFC3594]</a></td> +<td class="author-text">Duffy, P., “<a href="http://tools.ietf.org/html/rfc3594">PacketCable Security Ticket Control Sub-Option for the DHCP CableLabs Client Configuration (CCC) Option</a>,” RFC 3594, September 2003 (<a href="http://www.rfc-editor.org/rfc/rfc3594.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3634">[RFC3634]</a></td> +<td class="author-text">Luehrs, K., Woundy, R., Bevilacqua, J., and N. Davoust, “<a href="http://tools.ietf.org/html/rfc3634">Key Distribution Center (KDC) Server Address Sub-option for the Dynamic Host Configuration Protocol (DHCP) CableLabs Client Configuration (CCC) Option</a>,” RFC 3634, December 2003 (<a href="http://www.rfc-editor.org/rfc/rfc3634.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3679">[RFC3679]</a></td> +<td class="author-text">Droms, R., “<a href="http://tools.ietf.org/html/rfc3679">Unused Dynamic Host Configuration Protocol (DHCP) Option Codes</a>,” RFC 3679, January 2004 (<a href="http://www.rfc-editor.org/rfc/rfc3679.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3825">[RFC3825]</a></td> +<td class="author-text">Polk, J., Schnizlein, J., and M. Linsner, “<a href="http://tools.ietf.org/html/rfc3825">Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information</a>,” RFC 3825, July 2004 (<a href="http://www.rfc-editor.org/rfc/rfc3825.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3925">[RFC3925]</a></td> +<td class="author-text">Littlefield, J., “<a href="http://tools.ietf.org/html/rfc3925">Vendor-Identifying Vendor Options for Dynamic Host Configuration Protocol version 4 (DHCPv4)</a>,” RFC 3925, October 2004 (<a href="http://www.rfc-editor.org/rfc/rfc3925.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3942">[RFC3942]</a></td> +<td class="author-text">Volz, B., “<a href="http://tools.ietf.org/html/rfc3942">Reclassifying Dynamic Host Configuration Protocol version 4 (DHCPv4) Options</a>,” RFC 3942, November 2004 (<a href="http://www.rfc-editor.org/rfc/rfc3942.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3993">[RFC3993]</a></td> +<td class="author-text">Johnson, R., Palaniappan, T., and M. Stapp, “<a href="http://tools.ietf.org/html/rfc3993">Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option</a>,” RFC 3993, March 2005 (<a href="http://www.rfc-editor.org/rfc/rfc3993.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4014">[RFC4014]</a></td> +<td class="author-text">Droms, R. and J. Schnizlein, “<a href="http://tools.ietf.org/html/rfc4014">Remote Authentication Dial-In User Service (RADIUS) Attributes Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option</a>,” RFC 4014, February 2005 (<a href="http://www.rfc-editor.org/rfc/rfc4014.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4030">[RFC4030]</a></td> +<td class="author-text">Stapp, M. and T. Lemon, “<a href="http://tools.ietf.org/html/rfc4030">The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option</a>,” RFC 4030, March 2005 (<a href="http://www.rfc-editor.org/rfc/rfc4030.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4039">[RFC4039]</a></td> +<td class="author-text">Park, S., Kim, P., and B. Volz, “<a href="http://tools.ietf.org/html/rfc4039">Rapid Commit Option for the Dynamic Host Configuration Protocol version 4 (DHCPv4)</a>,” RFC 4039, March 2005 (<a href="http://www.rfc-editor.org/rfc/rfc4039.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4174">[RFC4174]</a></td> +<td class="author-text">Monia, C., Tseng, J., and K. Gibbons, “<a href="http://tools.ietf.org/html/rfc4174">The IPv4 Dynamic Host Configuration Protocol (DHCP) Option for the Internet Storage Name Service</a>,” RFC 4174, September 2005 (<a href="http://www.rfc-editor.org/rfc/rfc4174.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4243">[RFC4243]</a></td> +<td class="author-text">Stapp, M., Johnson, R., and T. Palaniappan, “<a href="http://tools.ietf.org/html/rfc4243">Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option</a>,” RFC 4243, December 2005 (<a href="http://www.rfc-editor.org/rfc/rfc4243.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4361">[RFC4361]</a></td> +<td class="author-text">Lemon, T. and B. Sommerfeld, “<a href="http://tools.ietf.org/html/rfc4361">Node-specific Client Identifiers for Dynamic Host Configuration Protocol Version Four (DHCPv4)</a>,” RFC 4361, February 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4361.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4388">[RFC4388]</a></td> +<td class="author-text">Woundy, R. and K. Kinnear, “<a href="http://tools.ietf.org/html/rfc4388">Dynamic Host Configuration Protocol (DHCP) Leasequery</a>,” RFC 4388, February 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4388.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4390">[RFC4390]</a></td> +<td class="author-text">Kashyap, V., “<a href="http://tools.ietf.org/html/rfc4390">Dynamic Host Configuration Protocol (DHCP) over InfiniBand</a>,” RFC 4390, April 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4390.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4436">[RFC4436]</a></td> +<td class="author-text">Aboba, B., Carlson, J., and S. Cheshire, “<a href="http://tools.ietf.org/html/rfc4436">Detecting Network Attachment in IPv4 (DNAv4)</a>,” RFC 4436, March 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4436.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4701">[RFC4701]</a></td> +<td class="author-text">Stapp, M., Lemon, T., and A. Gustafsson, “<a href="http://tools.ietf.org/html/rfc4701">A DNS Resource Record (RR) for Encoding Dynamic Host Configuration Protocol (DHCP) Information (DHCID RR)</a>,” RFC 4701, October 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4701.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4702">[RFC4702]</a></td> +<td class="author-text">Stapp, M., Volz, B., and Y. Rekhter, “<a href="http://tools.ietf.org/html/rfc4702">The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option</a>,” RFC 4702, October 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4702.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4703">[RFC4703]</a></td> +<td class="author-text">Stapp, M. and B. Volz, “<a href="http://tools.ietf.org/html/rfc4703">Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients</a>,” RFC 4703, October 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4703.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5010">[RFC5010]</a></td> +<td class="author-text">Kinnear, K., Normoyle, M., and M. Stapp, “<a href="http://tools.ietf.org/html/rfc5010">The Dynamic Host Configuration Protocol Version 4 (DHCPv4) Relay Agent Flags Suboption</a>,” RFC 5010, September 2007 (<a href="http://www.rfc-editor.org/rfc/rfc5010.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5071">[RFC5071]</a></td> +<td class="author-text">Hankins, D., “<a href="http://tools.ietf.org/html/rfc5071">Dynamic Host Configuration Protocol Options Used by PXELINUX</a>,” RFC 5071, December 2007 (<a href="http://www.rfc-editor.org/rfc/rfc5071.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5107">[RFC5107]</a></td> +<td class="author-text">Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, “<a href="http://tools.ietf.org/html/rfc5107">DHCP Server Identifier Override Suboption</a>,” RFC 5107, February 2008 (<a href="http://www.rfc-editor.org/rfc/rfc5107.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5192">[RFC5192]</a></td> +<td class="author-text">Morand, L., Yegin, A., Kumar, S., and S. Madanapalli, “<a href="http://tools.ietf.org/html/rfc5192">DHCP Options for Protocol for Carrying Authentication for Network Access (PANA) Authentication Agents</a>,” RFC 5192, May 2008 (<a href="http://www.rfc-editor.org/rfc/rfc5192.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5223">[RFC5223]</a></td> +<td class="author-text">Schulzrinne, H., Polk, J., and H. Tschofenig, “<a href="http://tools.ietf.org/html/rfc5223">Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)</a>,” RFC 5223, August 2008 (<a href="http://www.rfc-editor.org/rfc/rfc5223.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5859">[RFC5859]</a></td> +<td class="author-text">Johnson, R., “<a href="http://tools.ietf.org/html/rfc5859">TFTP Server Address Option for DHCPv4</a>,” RFC 5859, June 2010 (<a href="http://www.rfc-editor.org/rfc/rfc5859.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5969">[RFC5969]</a></td> +<td class="author-text">Townsley, W. and O. Troan, “<a href="http://tools.ietf.org/html/rfc5969">IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification</a>,” RFC 5969, August 2010 (<a href="http://www.rfc-editor.org/rfc/rfc5969.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="draft-failover">[draft-failover]</a></td> +<td class="author-text">Droms, R., “<a href="https://www.isc.org/sw/dhcp/drafts/draft-ietf-dhc-failover-12.txt">DHCP Failover Protocol</a>,” March 2003.</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-dhc-dhcpv4-relay-encapsulation">[I-D.ietf-dhc-dhcpv4-relay-encapsulation]</a></td> +<td class="author-text">Lemon, T. and H. Deng, “<a href="http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-relay-encapsulation-00">Relay Agent Encapsulation for DHCPv4</a>,” draft-ietf-dhc-dhcpv4-relay-encapsulation-00 (work in progress), October 2010 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-relay-encapsulation-00.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-dhc-dhcpv4-bulk-leasequery">[I-D.ietf-dhc-dhcpv4-bulk-leasequery]</a></td> +<td class="author-text">Kinnear, K., Volz, B., Russell, N., Stapp, M., Rao, D., Joshi, B., and P. Kurapati, “<a href="http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-bulk-leasequery-03">Bulk DHCPv4 Lease Query</a>,” draft-ietf-dhc-dhcpv4-bulk-leasequery-03 (work in progress), October 2010 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv4-bulk-leasequery-03.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-dhc-leasequery-by-remote-id">[I-D.ietf-dhc-leasequery-by-remote-id]</a></td> +<td class="author-text">Kurapati, P. and B. Joshi, “<a href="http://tools.ietf.org/html/draft-ietf-dhc-leasequery-by-remote-id-09">DHCPv4 lease query by Relay Agent Remote ID</a>,” draft-ietf-dhc-leasequery-by-remote-id-09 (work in progress), December 2010 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-dhc-leasequery-by-remote-id-09.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-dhc-relay-id-suboption">[I-D.ietf-dhc-relay-id-suboption]</a></td> +<td class="author-text">Stapp, M., “<a href="http://tools.ietf.org/html/draft-ietf-dhc-relay-id-suboption-07">The DHCPv4 Relay Agent Identifier Suboption</a>,” draft-ietf-dhc-relay-id-suboption-07 (work in progress), July 2009 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-dhc-relay-id-suboption-07.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-mip6-hiopt">[I-D.ietf-mip6-hiopt]</a></td> +<td class="author-text">Jang, H., Yegin, A., Chowdhury, K., and J. Choi, “<a href="http://tools.ietf.org/html/draft-ietf-mip6-hiopt-17">DHCP Options for Home Information Discovery in MIPv6</a>,” draft-ietf-mip6-hiopt-17 (work in progress), May 2008 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-mip6-hiopt-17.txt">TXT</a>).</td></tr> +</table> + +<a name="rfc.references2"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<h3>7.2. Published Common (DHCPv4/DHCPv6) References</h3> +<table width="99%" border="0"> +<tr><td class="author-text" valign="top"><a name="RFC4280">[RFC4280]</a></td> +<td class="author-text">Chowdhury, K., Yegani, P., and L. Madour, “<a href="http://tools.ietf.org/html/rfc4280">Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers</a>,” RFC 4280, November 2005 (<a href="http://www.rfc-editor.org/rfc/rfc4280.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4477">[RFC4477]</a></td> +<td class="author-text">Chown, T., Venaas, S., and C. Strauf, “<a href="http://tools.ietf.org/html/rfc4477">Dynamic Host Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack Issues</a>,” RFC 4477, May 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4477.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4578">[RFC4578]</a></td> +<td class="author-text">Johnston, M. and S. Venaas, “<a href="http://tools.ietf.org/html/rfc4578">Dynamic Host Configuration Protocol (DHCP) Options for the Intel Preboot eXecution Environment (PXE)</a>,” RFC 4578, November 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4578.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4776">[RFC4776]</a></td> +<td class="author-text">Schulzrinne, H., “<a href="http://tools.ietf.org/html/rfc4776">Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information</a>,” RFC 4776, November 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4776.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4833">[RFC4833]</a></td> +<td class="author-text">Lear, E. and P. Eggert, “<a href="http://tools.ietf.org/html/rfc4833">Timezone Options for DHCP</a>,” RFC 4833, April 2007 (<a href="http://www.rfc-editor.org/rfc/rfc4833.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5417">[RFC5417]</a></td> +<td class="author-text">Calhoun, P., “<a href="http://tools.ietf.org/html/rfc5417">Control And Provisioning of Wireless Access Points (CAPWAP) Access Controller DHCP Option</a>,” RFC 5417, March 2009 (<a href="http://www.rfc-editor.org/rfc/rfc5417.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5678">[RFC5678]</a></td> +<td class="author-text">Bajko, G. and S. Das, “<a href="http://tools.ietf.org/html/rfc5678">Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery</a>,” RFC 5678, December 2009 (<a href="http://www.rfc-editor.org/rfc/rfc5678.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5908">[RFC5908]</a></td> +<td class="author-text">Gayraud, R. and B. Lourdelet, “<a href="http://tools.ietf.org/html/rfc5908">Network Time Protocol (NTP) Server Option for DHCPv6</a>,” RFC 5908, June 2010 (<a href="http://www.rfc-editor.org/rfc/rfc5908.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5970">[RFC5970]</a></td> +<td class="author-text">Huth, T., Freimann, J., Zimmer, V., and D. Thaler, “<a href="http://tools.ietf.org/html/rfc5970">DHCPv6 Options for Network Boot</a>,” RFC 5970, September 2010 (<a href="http://www.rfc-editor.org/rfc/rfc5970.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5986">[RFC5986]</a></td> +<td class="author-text">Thomson, M. and J. Winterbottom, “<a href="http://tools.ietf.org/html/rfc5986">Discovering the Local Location Information Server (LIS)</a>,” RFC 5986, September 2010 (<a href="http://www.rfc-editor.org/rfc/rfc5986.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-dhc-vpn-option">[I-D.ietf-dhc-vpn-option]</a></td> +<td class="author-text">Kinnear, K., Johnson, R., and M. Stapp, “<a href="http://tools.ietf.org/html/draft-ietf-dhc-vpn-option-12">Virtual Subnet Selection Options for DHCPv4 and DHCPv6</a>,” draft-ietf-dhc-vpn-option-12 (work in progress), October 2010 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-dhc-vpn-option-12.txt">TXT</a>).</td></tr> +</table> + +<a name="rfc.references3"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<h3>7.3. Published DHCPv6 References</h3> +<table width="99%" border="0"> +<tr><td class="author-text" valign="top"><a name="RFC3315">[RFC3315]</a></td> +<td class="author-text">Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, “<a href="http://tools.ietf.org/html/rfc3315">Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</a>,” RFC 3315, July 2003 (<a href="http://www.rfc-editor.org/rfc/rfc3315.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3319">[RFC3319]</a></td> +<td class="author-text">Schulzrinne, H. and B. Volz, “<a href="http://tools.ietf.org/html/rfc3319">Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers</a>,” RFC 3319, July 2003 (<a href="http://www.rfc-editor.org/rfc/rfc3319.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3633">[RFC3633]</a></td> +<td class="author-text">Troan, O. and R. Droms, “<a href="http://tools.ietf.org/html/rfc3633">IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6</a>,” RFC 3633, December 2003 (<a href="http://www.rfc-editor.org/rfc/rfc3633.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3646">[RFC3646]</a></td> +<td class="author-text">Droms, R., “<a href="http://tools.ietf.org/html/rfc3646">DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</a>,” RFC 3646, December 2003 (<a href="http://www.rfc-editor.org/rfc/rfc3646.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3736">[RFC3736]</a></td> +<td class="author-text">Droms, R., “<a href="http://tools.ietf.org/html/rfc3736">Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6</a>,” RFC 3736, April 2004 (<a href="http://www.rfc-editor.org/rfc/rfc3736.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC3898">[RFC3898]</a></td> +<td class="author-text">Kalusivalingam, V., “<a href="http://tools.ietf.org/html/rfc3898">Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</a>,” RFC 3898, October 2004 (<a href="http://www.rfc-editor.org/rfc/rfc3898.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4075">[RFC4075]</a></td> +<td class="author-text">Kalusivalingam, V., “<a href="http://tools.ietf.org/html/rfc4075">Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6</a>,” RFC 4075, May 2005 (<a href="http://www.rfc-editor.org/rfc/rfc4075.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4076">[RFC4076]</a></td> +<td class="author-text">Chown, T., Venaas, S., and A. Vijayabhaskar, “<a href="http://tools.ietf.org/html/rfc4076">Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</a>,” RFC 4076, May 2005 (<a href="http://www.rfc-editor.org/rfc/rfc4076.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4242">[RFC4242]</a></td> +<td class="author-text">Venaas, S., Chown, T., and B. Volz, “<a href="http://tools.ietf.org/html/rfc4242">Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</a>,” RFC 4242, November 2005 (<a href="http://www.rfc-editor.org/rfc/rfc4242.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4580">[RFC4580]</a></td> +<td class="author-text">Volz, B., “<a href="http://tools.ietf.org/html/rfc4580">Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option</a>,” RFC 4580, June 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4580.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4649">[RFC4649]</a></td> +<td class="author-text">Volz, B., “<a href="http://tools.ietf.org/html/rfc4649">Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Remote-ID Option</a>,” RFC 4649, August 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4649.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4704">[RFC4704]</a></td> +<td class="author-text">Volz, B., “<a href="http://tools.ietf.org/html/rfc4704">The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option</a>,” RFC 4704, October 2006 (<a href="http://www.rfc-editor.org/rfc/rfc4704.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC4994">[RFC4994]</a></td> +<td class="author-text">Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, “<a href="http://tools.ietf.org/html/rfc4994">DHCPv6 Relay Agent Echo Request Option</a>,” RFC 4994, September 2007 (<a href="http://www.rfc-editor.org/rfc/rfc4994.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5007">[RFC5007]</a></td> +<td class="author-text">Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, “<a href="http://tools.ietf.org/html/rfc5007">DHCPv6 Leasequery</a>,” RFC 5007, September 2007 (<a href="http://www.rfc-editor.org/rfc/rfc5007.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5453">[RFC5453]</a></td> +<td class="author-text">Krishnan, S., “<a href="http://tools.ietf.org/html/rfc5453">Reserved IPv6 Interface Identifiers</a>,” RFC 5453, February 2009 (<a href="http://www.rfc-editor.org/rfc/rfc5453.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="RFC5460">[RFC5460]</a></td> +<td class="author-text">Stapp, M., “<a href="http://tools.ietf.org/html/rfc5460">DHCPv6 Bulk Leasequery</a>,” RFC 5460, February 2009 (<a href="http://www.rfc-editor.org/rfc/rfc5460.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-mif-dhcpv6-route-option">[I-D.ietf-mif-dhcpv6-route-option]</a></td> +<td class="author-text">Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, “<a href="http://tools.ietf.org/html/draft-ietf-mif-dhcpv6-route-option-03">DHCPv6 Route Options</a>,” draft-ietf-mif-dhcpv6-route-option-03 (work in progress), September 2011 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-mif-dhcpv6-route-option-03.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-dhc-dhcpv6-ldra">[I-D.ietf-dhc-dhcpv6-ldra]</a></td> +<td class="author-text">Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, “<a href="http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-ldra-03">Lightweight DHCPv6 Relay Agent</a>,” draft-ietf-dhc-dhcpv6-ldra-03 (work in progress), October 2010 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-ldra-03.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-dhc-dhcpv6-relay-supplied-options">[I-D.ietf-dhc-dhcpv6-relay-supplied-options]</a></td> +<td class="author-text">Lemon, T. and W. Wu, “<a href="http://tools.ietf.org/html/draft-ietf-dhc-dhcpv6-relay-supplied-options-09">Relay-Supplied DHCP Options</a>,” draft-ietf-dhc-dhcpv6-relay-supplied-options-09 (work in progress), September 2011 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-relay-supplied-options-09.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-dhc-pd-exclude">[I-D.ietf-dhc-pd-exclude]</a></td> +<td class="author-text">Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, “<a href="http://tools.ietf.org/html/draft-ietf-dhc-pd-exclude-01">Prefix Exclude Option for DHCPv6-based Prefix Delegation</a>,” draft-ietf-dhc-pd-exclude-01 (work in progress), January 2011 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-dhc-pd-exclude-01.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-dhc-secure-dhcpv6">[I-D.ietf-dhc-secure-dhcpv6]</a></td> +<td class="author-text">Jiang, S., “<a href="http://tools.ietf.org/html/draft-ietf-dhc-secure-dhcpv6-02">Secure DHCPv6 Using CGAs</a>,” draft-ietf-dhc-secure-dhcpv6-02 (work in progress), December 2010 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-dhc-secure-dhcpv6-02.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-mext-nemo-pd">[I-D.ietf-mext-nemo-pd]</a></td> +<td class="author-text">Droms, R., Thubert, P., Dupont, F., Haddad, W., and C. Bernardos, “<a href="http://tools.ietf.org/html/draft-ietf-mext-nemo-pd-07">DHCPv6 Prefix Delegation for NEMO</a>,” draft-ietf-mext-nemo-pd-07 (work in progress), December 2010 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-mext-nemo-pd-07.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-dhc-duid-uuid">[I-D.ietf-dhc-duid-uuid]</a></td> +<td class="author-text">Narten, T. and J. Johnson, “<a href="http://tools.ietf.org/html/draft-ietf-dhc-duid-uuid-03">Definition of the UUID-based DHCPv6 Unique Identifier (DUID-UUID)</a>,” draft-ietf-dhc-duid-uuid-03 (work in progress), February 2011 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-dhc-duid-uuid-03.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-softwire-ds-lite-tunnel-option">[I-D.ietf-softwire-ds-lite-tunnel-option]</a></td> +<td class="author-text">Hankins, D. and T. Mrugalski, “<a href="http://tools.ietf.org/html/draft-ietf-softwire-ds-lite-tunnel-option-10">Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite</a>,” draft-ietf-softwire-ds-lite-tunnel-option-10 (work in progress), March 2011 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-softwire-ds-lite-tunnel-option-10.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-mif-dns-server-selection">[I-D.ietf-mif-dns-server-selection]</a></td> +<td class="author-text">Savolainen, T. and J. Kato, “<a href="http://tools.ietf.org/html/draft-ietf-mif-dns-server-selection-01">Improved DNS Server Selection for Multi-Homed Nodes</a>,” draft-ietf-mif-dns-server-selection-01 (work in progress), March 2011 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-mif-dns-server-selection-01.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="I-D.ietf-geopriv-rfc3825bis">[I-D.ietf-geopriv-rfc3825bis]</a></td> +<td class="author-text">Polk, J., Linsner, M., Thomson, M., and B. Aboba, “<a href="http://tools.ietf.org/html/draft-ietf-geopriv-rfc3825bis-17">Dynamic Host Configuration Protocol Options for Coordinate-based Location Configuration Information</a>,” draft-ietf-geopriv-rfc3825bis-17 (work in progress), February 2011 (<a href="http://www.ietf.org/internet-drafts/draft-ietf-geopriv-rfc3825bis-17.txt">TXT</a>).</td></tr> +<tr><td class="author-text" valign="top"><a name="draft-addr-params">[draft-addr-params]</a></td> +<td class="author-text">Mrugalski, T., “<a href="http://klub.com.pl/dhcpv6/doc/draft-mrugalski-addropts-XX-2007-04-17.txt">Address Parameters Option for DHCPv6</a>,” April 2007.</td></tr> +</table> + +<a name="rfc.authors"></a><br /><hr /> +<table summary="layout" cellpadding="0" cellspacing="2" class="TOCbug" align="right"><tr><td class="TOCbug"><a href="#toc"> TOC </a></td></tr></table> +<h3>Authors' Addresses</h3> +<table width="99%" border="0" cellpadding="0" cellspacing="0"> +<tr><td class="author-text"> </td> +<td class="author-text">David W. Hankins</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Internet Systems Consortium, + Inc.</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">950 Charter Street</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Redwood City, CA 94063</td></tr> +<tr cellpadding="3"><td> </td><td> </td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Tomasz Mrugalski</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Internet Systems Consortium, + Inc.</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">950 Charter Street</td></tr> +<tr><td class="author-text"> </td> +<td class="author-text">Redwood City, CA 94063</td></tr> +<tr><td class="author" align="right">Phone: </td> +<td class="author-text">+1 650 423 1345</td></tr> +<tr><td class="author" align="right">Email: </td> +<td class="author-text"><a href="mailto:Tomasz_Mrugalski@isc.org">Tomasz_Mrugalski@isc.org</a></td></tr> +</table> +</body></html> diff --git a/doc/References.txt b/doc/References.txt new file mode 100644 index 0000000..2872726 --- /dev/null +++ b/doc/References.txt @@ -0,0 +1,1176 @@ + + + +ISC-DHCP-REFERENCES D. Hankins + T. Mrugalski + ISC + January 04, 2012 + + + ISC DHCP References Collection + +Abstract + + 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. + +Copyright Notice + + Copyright (c) 2006-2007,2009,2011 by Internet Systems Consortium, + Inc. ("ISC") + + 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. + + 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. + + + + + + + + + + + + + + + + + + + + +Hankins & Mrugalski [Page 1] + + ISC DHCP References Collection January 2012 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + + 2. Definition: Reference Implementation . . . . . . . . . . . . . 3 + + 3. Low Layer References . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Ethernet Protocol References . . . . . . . . . . . . . . . 6 + 3.2. Token Ring Protocol References . . . . . . . . . . . . . . 6 + 3.3. FDDI Protocol References . . . . . . . . . . . . . . . . . 6 + 3.4. Internet Protocol Version 4 References . . . . . . . . . . 6 + 3.5. Unicast Datagram Protocol References . . . . . . . . . . . 6 + + 4. BOOTP Protocol References . . . . . . . . . . . . . . . . . . 6 + + 5. DHCPv4 Protocol References . . . . . . . . . . . . . . . . . . 7 + 5.1. DHCPv4 Protocol . . . . . . . . . . . . . . . . . . . . . 7 + 5.1.1. Core Protocol References . . . . . . . . . . . . . . . 7 + 5.2. DHCPv4 Option References . . . . . . . . . . . . . . . . . 7 + 5.2.1. Relay Agent Information Option Options . . . . . . . . 9 + 5.2.2. Dynamic DNS Updates References . . . . . . . . . . . . 9 + 5.2.3. Experimental: Failover References . . . . . . . . . . 9 + 5.3. DHCP Procedures . . . . . . . . . . . . . . . . . . . . . 10 + + 6. DHCPv6 Protocol References . . . . . . . . . . . . . . . . . . 10 + 6.1. DHCPv6 Protocol References . . . . . . . . . . . . . . . . 10 + 6.2. DHCPv6 Options References . . . . . . . . . . . . . . . . 11 + + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 7.1. Published DHCPv4 References . . . . . . . . . . . . . . . 12 + 7.2. Published Common (DHCPv4/DHCPv6) References . . . . . . . 17 + 7.3. Published DHCPv6 References . . . . . . . . . . . . . . . 18 + + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 + + + + + + + + + + + + + + + + + +Hankins & Mrugalski [Page 2] + + ISC DHCP References Collection January 2012 + + +1. Introduction + + 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). + + 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. + + +2. Definition: Reference Implementation + + 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. + + 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." + + 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. + + Anything else is a bug, the only question is whether the bug is in + reference or software (failing to implement the reference). + + This means: + + + +Hankins & Mrugalski [Page 3] + + ISC DHCP References Collection January 2012 + + + o To produce new externally-visible behaviour, one must first + provide a reference. + + o Before changing externally visible behaviour to work around simple + incompatibilities in any other implementation, one must first + provide a reference. + + 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. + + 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". + + 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. + + +3. Low Layer References + + 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. + + 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. + + 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 [RFC2131]. + + 1. 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 + + + +Hankins & Mrugalski [Page 4] + + ISC DHCP References Collection January 2012 + + + address yet) interface. + + 2. 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. + + 3. Transmit a UDP packet from IP:Self, Ethernet:Self, destined to + IP:remote-system LinkLayer:remote-system, without transmitting a + single ARP. + + 4. 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. + + 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, [RFC2131] very explicitly demands that + these packets' IP destination addresses be set to 255.255.255.255. + + 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. + + 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. + + 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. + + 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 + + + +Hankins & Mrugalski [Page 5] + + ISC DHCP References Collection January 2012 + + + 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. + +3.1. Ethernet Protocol References + + 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 [RFC0894] see the section + titled "Packet format"), and the following URL is also thought to be + useful. + + http://en.wikipedia.org/wiki/DIX_Ethernet + +3.2. Token Ring Protocol References + + IEEE 802.5 defines the Token Ring framing format used by ISC DHCP. + +3.3. FDDI Protocol References + + [RFC1188] is the most helpful reference ISC DHCP has used to form + FDDI packets. + +3.4. Internet Protocol Version 4 References + + RFC760 [RFC0760] fundamentally defines the bare IPv4 protocol which + ISC DHCP implements. + +3.5. Unicast Datagram Protocol References + + RFC768 [RFC0768] 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. + + +4. BOOTP Protocol References + + 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. + + The ISC DHCP server supports BOOTP clients conforming to RFC951 + [RFC0951] and RFC1542 [RFC1542]. + + + + +Hankins & Mrugalski [Page 6] + + ISC DHCP References Collection January 2012 + + +5. DHCPv4 Protocol References + +5.1. DHCPv4 Protocol + + "The DHCP[v4] Protocol" is not defined in a single document. The + following collection of references of what ISC DHCP terms "The DHCPv4 + Protocol". + +5.1.1. Core Protocol References + + RFC2131 [RFC2131] 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. + + RFC2132 [RFC2132] 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. + +5.2. DHCPv4 Option References + + RFC2241 [RFC2241] defines options for Novell Directory Services. + + RFC2242 [RFC2242] defines an encapsulated option space for NWIP + configuration. + + + + +Hankins & Mrugalski [Page 7] + + ISC DHCP References Collection January 2012 + + + RFC2485 [RFC2485] defines the Open Group's UAP option. + + RFC2610 [RFC2610] defines options for the Service Location Protocol + (SLP). + + RFC2937 [RFC2937] 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. + + RFC3004 [RFC3004] 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. + + RFC3011 [RFC3011] 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. + + RFC3396 [RFC3396] 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. + + RFC3397 [RFC3397] documents the Domain-Search Option, which allows + the configuration of the /etc/resolv.conf 'search' parameter in a way + that is RFC1035 [RFC1035] wire format compatible (in fact, it uses + the RFC1035 wire format). ISC DHCP has both client and server + support, and supports RFC1035 name compression. + + RFC3679 [RFC3679] documents a number of options that were documented + earlier in history, but were not made use of. + + RFC3925 [RFC3925] 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. + + RFC3942 [RFC3942] redefined the 'site local' option space. + + [RFC4280] defines two BCMS server options for each protocol family. + + RFC4388 [RFC4388] 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. + + + + +Hankins & Mrugalski [Page 8] + + ISC DHCP References Collection January 2012 + + +5.2.1. Relay Agent Information Option Options + + RFC3046 [RFC3046] defines the Relay Agent Information Option and + provides a number of sub-option definitions. + + RFC3256 [RFC3256] defines the DOCSIS Device Class sub-option. + + RFC3527 [RFC3527] defines the Link Selection sub-option. + +5.2.2. Dynamic DNS Updates References + + The collection of documents that describe the standards-based method + to update dns names of DHCP clients starts most easily with RFC4703 + [RFC4703] to define the overall architecture, travels through RFCs + 4702 [RFC4702] and 4704 [RFC4704] to describe the DHCPv4 and DHCPv6 + FQDN options (to carry the client name), and ends up at RFC4701 + [RFC4701] which describes the DHCID RR used in DNS to perform a kind + of atomic locking. + + ISC DHCP adopted early versions of these documents, and has not yet + synchronized with the final standards versions. + + 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. + + 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. + +5.2.3. Experimental: Failover References + + 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. + + Unfortunately it has been quite some years (2003) since the last time + + + +Hankins & Mrugalski [Page 9] + + ISC DHCP References Collection January 2012 + + + this document was edited, and the authors no longer show any interest + in fielding comments or improving the document. + + 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. + + draft-ietf-dhc-failover-12.txt [draft-failover] 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. + + 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. + + [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). + +5.3. DHCP Procedures + + [RFC2939] explains how to go about obtaining a new DHCP Option code + assignment. + + +6. DHCPv6 Protocol References + +6.1. DHCPv6 Protocol References + + For now there is only one document that specifies the base of the + DHCPv6 protocol (there have been no updates yet), [RFC3315]. + + 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 + + + +Hankins & Mrugalski [Page 10] + + ISC DHCP References Collection January 2012 + + + IA_NAs within one packet from the client, our client only supports + sending one. There is no relay support. + + DHCPv6 introduces some new and uncomfortable ideas to the common + software library. + + 1. 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. + + 2. 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. + + Precisely how to correctly support the above conundrums has not quite + yet been settled, so support is incomplete. + + [RFC5453] creates a registry at IANA to reserve interface identifiers + and specifies a starting set. These IIDs should not be used when + constructing addresses to avoid possible conflicts. + +6.2. DHCPv6 Options References + + [RFC3319] defines the SIP server options for DHCPv6. + + [RFC3646] documents the DHCPv6 name-servers and domain-search + options. + + [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. + + [RFC3898] documents four NIS options for delivering NIS servers and + domain information in DHCPv6. + + [RFC4075] defines the DHCPv6 SNTP Servers option. + + [RFC4242] defines the Information Refresh Time option, which advises + DHCPv6 Information-Request clients to return for updated information. + + + + +Hankins & Mrugalski [Page 11] + + ISC DHCP References Collection January 2012 + + + [RFC4280] defines two BCMS server options for each protocol family. + + [RFC4580] defines a DHCPv6 subscriber-id option, which is similar in + principle to the DHCPv4 relay agent option of the same name. + + [RFC4649] defines a DHCPv6 remote-id option, which is similar in + principle to the DHCPv4 relay agent remote-id. + + +7. References + +7.1. Published DHCPv4 References + + [RFC0760] Postel, J., "DoD standard Internet Protocol", RFC 760, + January 1980. + + [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, + August 1980. + + [RFC0894] Hornig, C., "Standard for the transmission of IP datagrams + over Ethernet networks", STD 41, RFC 894, April 1984. + + [RFC0951] Croft, B. and J. Gilmore, "Bootstrap Protocol", RFC 951, + September 1985. + + [RFC1035] Mockapetris, P., "Domain names - implementation and + specification", STD 13, RFC 1035, November 1987. + + [RFC1188] Katz, D., "Proposed Standard for the Transmission of IP + Datagrams over FDDI Networks", RFC 1188, October 1990. + + [RFC1542] Wimer, W., "Clarifications and Extensions for the + Bootstrap Protocol", RFC 1542, October 1993. + + [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", + RFC 2131, March 1997. + + [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor + Extensions", RFC 2132, March 1997. + + [RFC2241] Provan, D., "DHCP Options for Novell Directory Services", + RFC 2241, November 1997. + + [RFC2242] Droms, R. and K. Fong, "NetWare/IP Domain Name and + Information", RFC 2242, November 1997. + + [RFC2485] Drach, S., "DHCP Option for The Open Group's User + Authentication Protocol", RFC 2485, January 1999. + + + +Hankins & Mrugalski [Page 12] + + ISC DHCP References Collection January 2012 + + + [RFC2563] Troll, R., "DHCP Option to Disable Stateless Auto- + Configuration in IPv4 Clients", RFC 2563, May 1999. + + [RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service + Location Protocol", RFC 2610, June 1999. + + [RFC2855] Fujisawa, K., "DHCP for IEEE 1394", RFC 2855, June 2000. + + [RFC2937] Smith, C., "The Name Service Search Option for DHCP", + RFC 2937, September 2000. + + [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition + of New DHCP Options and Message Types", BCP 43, RFC 2939, + September 2000. + + [RFC3004] Stump, G., Droms, R., Gu, Y., Vyaghrapuri, R., Demirtjis, + A., Beser, B., and J. Privat, "The User Class Option for + DHCP", RFC 3004, November 2000. + + [RFC3011] Waters, G., "The IPv4 Subnet Selection Option for DHCP", + RFC 3011, November 2000. + + [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", + RFC 3046, January 2001. + + [RFC3074] Volz, B., Gonczi, S., Lemon, T., and R. Stevens, "DHC Load + Balancing Algorithm", RFC 3074, February 2001. + + [RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP + Messages", RFC 3118, June 2001. + + [RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP + reconfigure extension", RFC 3203, December 2001. + + [RFC3256] Jones, D. and R. Woundy, "The DOCSIS (Data-Over-Cable + Service Interface Specifications) Device Class DHCP + (Dynamic Host Configuration Protocol) Relay Agent + Information Sub-option", RFC 3256, April 2002. + + [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol + (DHCP-for-IPv4) Option for Session Initiation Protocol + (SIP) Servers", RFC 3361, August 2002. + + [RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the + Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, + November 2002. + + [RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration + + + +Hankins & Mrugalski [Page 13] + + ISC DHCP References Collection January 2012 + + + Protocol (DHCP) Domain Search Option", RFC 3397, + November 2002. + + [RFC3442] Lemon, T., Cheshire, S., and B. Volz, "The Classless + Static Route Option for Dynamic Host Configuration + Protocol (DHCP) version 4", RFC 3442, December 2002. + + [RFC3456] Patel, B., Aboba, B., Kelly, S., and V. Gupta, "Dynamic + Host Configuration Protocol (DHCPv4) Configuration of + IPsec Tunnel Mode", RFC 3456, January 2003. + + [RFC3495] Beser, B. and P. Duffy, "Dynamic Host Configuration + Protocol (DHCP) Option for CableLabs Client + Configuration", RFC 3495, March 2003. + + [RFC3527] Kinnear, K., Stapp, M., Johnson, R., and J. Kumarasamy, + "Link Selection sub-option for the Relay Agent Information + Option for DHCPv4", RFC 3527, April 2003. + + [RFC3594] Duffy, P., "PacketCable Security Ticket Control Sub-Option + for the DHCP CableLabs Client Configuration (CCC) Option", + RFC 3594, September 2003. + + [RFC3634] Luehrs, K., Woundy, R., Bevilacqua, J., and N. Davoust, + "Key Distribution Center (KDC) Server Address Sub-option + for the Dynamic Host Configuration Protocol (DHCP) + CableLabs Client Configuration (CCC) Option", RFC 3634, + December 2003. + + [RFC3679] Droms, R., "Unused Dynamic Host Configuration Protocol + (DHCP) Option Codes", RFC 3679, January 2004. + + [RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host + Configuration Protocol Option for Coordinate-based + Location Configuration Information", RFC 3825, July 2004. + + [RFC3925] Littlefield, J., "Vendor-Identifying Vendor Options for + Dynamic Host Configuration Protocol version 4 (DHCPv4)", + RFC 3925, October 2004. + + [RFC3942] Volz, B., "Reclassifying Dynamic Host Configuration + Protocol version 4 (DHCPv4) Options", RFC 3942, + November 2004. + + [RFC3993] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID + Suboption for the Dynamic Host Configuration Protocol + (DHCP) Relay Agent Option", RFC 3993, March 2005. + + + + +Hankins & Mrugalski [Page 14] + + ISC DHCP References Collection January 2012 + + + [RFC4014] Droms, R. and J. Schnizlein, "Remote Authentication + Dial-In User Service (RADIUS) Attributes Suboption for the + Dynamic Host Configuration Protocol (DHCP) Relay Agent + Information Option", RFC 4014, February 2005. + + [RFC4030] Stapp, M. and T. Lemon, "The Authentication Suboption for + the Dynamic Host Configuration Protocol (DHCP) Relay Agent + Option", RFC 4030, March 2005. + + [RFC4039] Park, S., Kim, P., and B. Volz, "Rapid Commit Option for + the Dynamic Host Configuration Protocol version 4 + (DHCPv4)", RFC 4039, March 2005. + + [RFC4174] Monia, C., Tseng, J., and K. Gibbons, "The IPv4 Dynamic + Host Configuration Protocol (DHCP) Option for the Internet + Storage Name Service", RFC 4174, September 2005. + + [RFC4243] Stapp, M., Johnson, R., and T. Palaniappan, "Vendor- + Specific Information Suboption for the Dynamic Host + Configuration Protocol (DHCP) Relay Agent Option", + RFC 4243, December 2005. + + [RFC4361] Lemon, T. and B. Sommerfeld, "Node-specific Client + Identifiers for Dynamic Host Configuration Protocol + Version Four (DHCPv4)", RFC 4361, February 2006. + + [RFC4388] Woundy, R. and K. Kinnear, "Dynamic Host Configuration + Protocol (DHCP) Leasequery", RFC 4388, February 2006. + + [RFC4390] Kashyap, V., "Dynamic Host Configuration Protocol (DHCP) + over InfiniBand", RFC 4390, April 2006. + + [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting + Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. + + [RFC4701] Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource + Record (RR) for Encoding Dynamic Host Configuration + Protocol (DHCP) Information (DHCID RR)", RFC 4701, + October 2006. + + [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host + Configuration Protocol (DHCP) Client Fully Qualified + Domain Name (FQDN) Option", RFC 4702, October 2006. + + [RFC4703] Stapp, M. and B. Volz, "Resolution of Fully Qualified + Domain Name (FQDN) Conflicts among Dynamic Host + Configuration Protocol (DHCP) Clients", RFC 4703, + October 2006. + + + +Hankins & Mrugalski [Page 15] + + ISC DHCP References Collection January 2012 + + + [RFC5010] Kinnear, K., Normoyle, M., and M. Stapp, "The Dynamic Host + Configuration Protocol Version 4 (DHCPv4) Relay Agent + Flags Suboption", RFC 5010, September 2007. + + [RFC5071] Hankins, D., "Dynamic Host Configuration Protocol Options + Used by PXELINUX", RFC 5071, December 2007. + + [RFC5107] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, + "DHCP Server Identifier Override Suboption", RFC 5107, + February 2008. + + [RFC5192] Morand, L., Yegin, A., Kumar, S., and S. Madanapalli, + "DHCP Options for Protocol for Carrying Authentication for + Network Access (PANA) Authentication Agents", RFC 5192, + May 2008. + + [RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering + Location-to-Service Translation (LoST) Servers Using the + Dynamic Host Configuration Protocol (DHCP)", RFC 5223, + August 2008. + + [RFC5859] Johnson, R., "TFTP Server Address Option for DHCPv4", + RFC 5859, June 2010. + + [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 + Infrastructures (6rd) -- Protocol Specification", + RFC 5969, August 2010. + + [draft-failover] + Droms, R., "DHCP Failover Protocol", March 2003. + + [I-D.ietf-dhc-dhcpv4-relay-encapsulation] + Lemon, T. and H. Deng, "Relay Agent Encapsulation for + DHCPv4", draft-ietf-dhc-dhcpv4-relay-encapsulation-00 + (work in progress), October 2010. + + [I-D.ietf-dhc-dhcpv4-bulk-leasequery] + Kinnear, K., Volz, B., Russell, N., Stapp, M., Rao, D., + Joshi, B., and P. Kurapati, "Bulk DHCPv4 Lease Query", + draft-ietf-dhc-dhcpv4-bulk-leasequery-03 (work in + progress), October 2010. + + [I-D.ietf-dhc-leasequery-by-remote-id] + Kurapati, P. and B. Joshi, "DHCPv4 lease query by Relay + Agent Remote ID", + draft-ietf-dhc-leasequery-by-remote-id-09 (work in + progress), December 2010. + + + + +Hankins & Mrugalski [Page 16] + + ISC DHCP References Collection January 2012 + + + [I-D.ietf-dhc-relay-id-suboption] + Stapp, M., "The DHCPv4 Relay Agent Identifier Suboption", + draft-ietf-dhc-relay-id-suboption-07 (work in progress), + July 2009. + + [I-D.ietf-mip6-hiopt] + Jang, H., Yegin, A., Chowdhury, K., and J. Choi, "DHCP + Options for Home Information Discovery in MIPv6", + draft-ietf-mip6-hiopt-17 (work in progress), May 2008. + +7.2. Published Common (DHCPv4/DHCPv6) References + + [RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host + Configuration Protocol (DHCP) Options for Broadcast and + Multicast Control Servers", RFC 4280, November 2005. + + [RFC4477] Chown, T., Venaas, S., and C. Strauf, "Dynamic Host + Configuration Protocol (DHCP): IPv4 and IPv6 Dual-Stack + Issues", RFC 4477, May 2006. + + [RFC4578] Johnston, M. and S. Venaas, "Dynamic Host Configuration + Protocol (DHCP) Options for the Intel Preboot eXecution + Environment (PXE)", RFC 4578, November 2006. + + [RFC4776] Schulzrinne, H., "Dynamic Host Configuration Protocol + (DHCPv4 and DHCPv6) Option for Civic Addresses + Configuration Information", RFC 4776, November 2006. + + [RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", + RFC 4833, April 2007. + + [RFC5417] Calhoun, P., "Control And Provisioning of Wireless Access + Points (CAPWAP) Access Controller DHCP Option", RFC 5417, + March 2009. + + [RFC5678] Bajko, G. and S. Das, "Dynamic Host Configuration Protocol + (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility + Services (MoS) Discovery", RFC 5678, December 2009. + + [RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) + Server Option for DHCPv6", RFC 5908, June 2010. + + [RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 + Options for Network Boot", RFC 5970, September 2010. + + [RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local + Location Information Server (LIS)", RFC 5986, + September 2010. + + + +Hankins & Mrugalski [Page 17] + + ISC DHCP References Collection January 2012 + + + [I-D.ietf-dhc-vpn-option] + Kinnear, K., Johnson, R., and M. Stapp, "Virtual Subnet + Selection Options for DHCPv4 and DHCPv6", + draft-ietf-dhc-vpn-option-12 (work in progress), + October 2010. + +7.3. Published DHCPv6 References + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration + Protocol (DHCPv6) Options for Session Initiation Protocol + (SIP) Servers", RFC 3319, July 2003. + + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic + Host Configuration Protocol (DHCP) version 6", RFC 3633, + December 2003. + + [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host + Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, + December 2003. + + [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol + (DHCP) Service for IPv6", RFC 3736, April 2004. + + [RFC3898] Kalusivalingam, V., "Network Information Service (NIS) + Configuration Options for Dynamic Host Configuration + Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004. + + [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) + Configuration Option for DHCPv6", RFC 4075, May 2005. + + [RFC4076] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering + Requirements for Stateless Dynamic Host Configuration + Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005. + + [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh + Time Option for Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 4242, November 2005. + + [RFC4580] Volz, B., "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6) Relay Agent Subscriber-ID Option", RFC 4580, + June 2006. + + [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 + (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, + + + +Hankins & Mrugalski [Page 18] + + ISC DHCP References Collection January 2012 + + + August 2006. + + [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for + IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) + Option", RFC 4704, October 2006. + + [RFC4994] Zeng, S., Volz, B., Kinnear, K., and J. Brzozowski, + "DHCPv6 Relay Agent Echo Request Option", RFC 4994, + September 2007. + + [RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, + "DHCPv6 Leasequery", RFC 5007, September 2007. + + [RFC5453] Krishnan, S., "Reserved IPv6 Interface Identifiers", + RFC 5453, February 2009. + + [RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, + February 2009. + + [I-D.ietf-mif-dhcpv6-route-option] + Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6 + Route Options", draft-ietf-mif-dhcpv6-route-option-03 + (work in progress), September 2011. + + [I-D.ietf-dhc-dhcpv6-ldra] + Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A. + Kavanagh, "Lightweight DHCPv6 Relay Agent", + draft-ietf-dhc-dhcpv6-ldra-03 (work in progress), + October 2010. + + [I-D.ietf-dhc-dhcpv6-relay-supplied-options] + Lemon, T. and W. Wu, "Relay-Supplied DHCP Options", + draft-ietf-dhc-dhcpv6-relay-supplied-options-09 (work in + progress), September 2011. + + [I-D.ietf-dhc-pd-exclude] + Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, + "Prefix Exclude Option for DHCPv6-based Prefix + Delegation", draft-ietf-dhc-pd-exclude-01 (work in + progress), January 2011. + + [I-D.ietf-dhc-secure-dhcpv6] + Jiang, S., "Secure DHCPv6 Using CGAs", + draft-ietf-dhc-secure-dhcpv6-02 (work in progress), + December 2010. + + [I-D.ietf-mext-nemo-pd] + Droms, R., Thubert, P., Dupont, F., Haddad, W., and C. + + + +Hankins & Mrugalski [Page 19] + + ISC DHCP References Collection January 2012 + + + Bernardos, "DHCPv6 Prefix Delegation for NEMO", + draft-ietf-mext-nemo-pd-07 (work in progress), + December 2010. + + [I-D.ietf-dhc-duid-uuid] + Narten, T. and J. Johnson, "Definition of the UUID-based + DHCPv6 Unique Identifier (DUID-UUID)", + draft-ietf-dhc-duid-uuid-03 (work in progress), + February 2011. + + [I-D.ietf-softwire-ds-lite-tunnel-option] + Hankins, D. and T. Mrugalski, "Dynamic Host Configuration + Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite", + draft-ietf-softwire-ds-lite-tunnel-option-10 (work in + progress), March 2011. + + [I-D.ietf-mif-dns-server-selection] + Savolainen, T. and J. Kato, "Improved DNS Server Selection + for Multi-Homed Nodes", + draft-ietf-mif-dns-server-selection-01 (work in progress), + March 2011. + + [I-D.ietf-geopriv-rfc3825bis] + Polk, J., Linsner, M., Thomson, M., and B. Aboba, "Dynamic + Host Configuration Protocol Options for Coordinate-based + Location Configuration Information", + draft-ietf-geopriv-rfc3825bis-17 (work in progress), + February 2011. + + [draft-addr-params] + Mrugalski, T., "Address Parameters Option for DHCPv6", + April 2007. + + +Authors' Addresses + + David W. Hankins + Internet Systems Consortium, Inc. + 950 Charter Street + Redwood City, CA 94063 + + + + + + + + + + + +Hankins & Mrugalski [Page 20] + + ISC DHCP References Collection January 2012 + + + Tomasz Mrugalski + Internet Systems Consortium, Inc. + 950 Charter Street + Redwood City, CA 94063 + + Phone: +1 650 423 1345 + Email: Tomasz_Mrugalski@isc.org + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Hankins & Mrugalski [Page 21] + diff --git a/doc/References.xml b/doc/References.xml new file mode 100644 index 0000000..634ef37 --- /dev/null +++ b/doc/References.xml @@ -0,0 +1,795 @@ +<?xml version='1.0' ?> + +<!-- $Id: References.xml,v 1.4.24.4 2012/01/05 00:02:51 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'> + <!ENTITY rfc5453 PUBLIC '' + 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5453.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="04" month="January" year="2012"/> + + <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> + + <t><xref target="RFC5453"/> creates a registry at IANA to reserve + interface identifiers and specifies a starting set. These IIDs should + not be used when constructing addresses to avoid possible conflicts.</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.5453'?> + <?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> diff --git a/doc/api+protocol b/doc/api+protocol new file mode 100644 index 0000000..48569f2 --- /dev/null +++ b/doc/api+protocol @@ -0,0 +1,436 @@ +This file documents the protocol that the ISC DHCP server and ISC +Object Management clients (clients that use the ISC Object Management +API) speak between one another. + +Protocol: + +All multi-byte numbers are represented in network byte order. + +On startup, each side sends a status message indicating what version +of the protocol they are speaking. The status message looks like +this: + ++---------+---------+ +| version | hlength | ++---------+---------+ + +version - a 32-bit fixed-point number with the decimal point between + the third and second decimal digits from the left, + representing the version of the protocol. The current + protocol version is 1.00. If the field were considered as + a 32-bit integer, this would correspond to a value of 100 + decimal, or 0x64. + +hlength - a 32-bit integer representing the length of the fixed-length + header in subsequent messages. This is normally 56, but + can be changed to a value larger than 56 by either side + without upgrading the revision number. + + +The startup message is not authenticated. Either side may reject the +other side's startup message as invalid by simply closing the +connection. The only fixed part of the startup message is the +version number - future versions may delete hlength, or add further +startup information. + +Following the startup message, all messages have the same format. +Currently, the format includes a fixed-length header (the length in +hlength, above) + ++--------+----+--------+----+-----+---------+------------+------------+-----+ +| authid | op | handle | id | rid | authlen | msg values | obj values | sig | ++--------+----+--------+----+-----+---------+------------+------------+-----+ + +The fixed-length header consists of: + +authid = a 32-bit authenticator handle. + For an original message (one not in response to some other + message), this will be chosen by the originator. For a + message in response to another message, the authenticator for + that message is used, except if the response is an error + message indicating that the authenticator used was unknown, + in which case the null authenticator is used. Messages that + are generated as the result of a notify registration use the + authenticator used in the original notify registration. + The authenticator itself is generated by having one side of + the connection send an object of type "authenticator" to the + other side with values that indicate what kind of + authentication mechanism to use and what key to use. The two + most likely things here are a Kerberos V principal name or the + name of a shared secret that can be used to calculate an MD5 + hash. The mechanism for doing this has yet to be finalized. + If authid is zero, the message is not authenticated. + +op = 32-bit opcode, one of: + open = 1 + refresh = 2 + update = 3 + notify = 4 + error = 5 + delete = 6 +handle = 32-bit object handle + A handle on the object being opened, created, refreshed or + updated. If no handle is yet available (e.g., with open and + new), then the value zero is sent. +id = 32-bit transaction id of the message - a monotonically increasing + number that starts with some randomly chosen number at the + beginning of the life of the connection. The value should never + be zero. +rid = 32-bit transaction ID of the message to which this message is a + response, or zero if this message is not in response to a + message from the other side. + +authlen = a 32-bit number representing the length of the authenticator + +msg values = a series of name+value pairs, specific to this message. + Each name+value pair starts with a 16-bit name length, + followed by that many bytes of name, followed by a 32-bit + value length, followed by that many bytes of value. If the + length is zero, this is a value of the blank string. If the + length is all ones (2^32-1), then there is no value - for an + update, this means the value for this name and the name + itself should be deleted from the object, which may or may + not be possible. The list of name/value pairs ends with a + zero-length name, which is not followed by a value + length/value pair. + +obj values = a series of name+value pairs, as above, specific to the + object being created, updated or refreshed. + +signature = authlen bytes of data signing the message. The signature + algorithm is a property of the authenticator handle. + +Message types: + +1: open + relevant input values: + object-type = the name of the type of object + open:create = boolean - create the object if it doesn't yet exist + open:exclusive = boolean - don't open the object if it does exist + open:update = boolean - update the object with included values + if it matches. + the handle should always be the null handle + + The input value must also contain key information for the type of + object being searched that uniquely identifies an object, or search + information that matches only one object. Each object has a key + specification (a key is something that uniquely identifies an + object), so see the key specification for that object to see + what to send here. An open message with the create flag set must + specify a key, and not merely matching criteria. Some objects may + allow more than one key, and it may be that the union of those keys + is required to uniquely identify the object, or it may be that any + one such key will uniquely identify the object. The documentation + for the type of object will specify this. + + An open message will result in an immediate response message whose + opcode will either be "error" or "update". The error message may + include an error:reason value containing a text string explaining + the error, and will always include an error:code value which will + be the numeric error code for what went wrong. Possible error + codes are: + + not found - no such object exists + already exists - object already exists, and exclusive flag was + set. + not unique - more than one object matching the specification + exists. + permission denied - the authenticator ID specified does not + have authorization to access this object, + or if the update flag was specified, to + update the object. + + If the response is an update message, the update message will + include the object handle and all of the name/value pairs + associated with that object. + +2: refresh + + no input values except the handle need be specified. The null + handle may not be specified. If the handle is valid, and the + authenticator ID specified has permission to examine the object, + then an update message will be sent for that object. Otherwise, + one of the following errors will be sent: + + invalid handle - the handle does not refer to a known object + permisson denied - the handle refers to an object that the + requestor does not have permission to + examine. + +3: update + + Requests that the contents of the specified object be updated with + the values included. Values that are not specified are not + updated. The response will be either an error message or an + update-ok message. If rid is nonzero, no response will be + generated, even if there was an error. Possible errors include: + + invalid handle - no such object was found + permission denied - the handle refers to an object that the + requestor does not have permission to + modify. + not confirmed - the update could not be committed due to some + kind of resource problem, for example + insufficient memory or a disk failure. + +4: notify + + Requests that whenever the object with the specified handle is + modified, an update be sent. If there is something wrong with the + request, an error message will be returned immediately. + Otherwise, whenever a change is made to the object, an update + message will be sent containing whatever changes were made (or + possibly all the values associated with the object, depending on + the implementation). Possible errors: + + invalid handle + permission denied - the handle refers to an object that the + requestor does not have permission to + examine. + not supported - the object implementation does not support + notifications + +5: status + + Sends a status code in response to a message. Always sent in + response to a message sent by the other side. There should never + be a response to this message. + +6: delete + + Deletes the specified object. Response will be either request-ok, + or error. Possible errors include: + + invalid handle - no such object was found + permission denied - the handle refers to an object that the + requestor does not have permission to + modify. + not confirmed - the deletion could not be committed due to + some kind of resource problem, for example + insufficient memory or a disk failure. + +7: notify-cancel + + Like notify, but requests that an existing notification be cancelled. + +8: notify-cancelled + + Indicates that because of a local change, a notification that had + been registered can no longer be performed. This could be as a + result of the permissions on a object changing, or an object being + deleted. There should never be a response to this message. + +internals: + +Both client and server use same protocol and infrastructure. There +are many object types, each of which is stored in a registry. +Objects whose type is not recognized can either be handled by the +generic object type, which is registered with the type "*". If no +generic object type is registered, then objects with unknown types are +simply not supported. On the client, there are probably no special +object handlers (although this is by no means forbidden). On the +server, probably everything is a special object. + +Each object type has the following methods: + + + + +dhcpctl_status dhcpctl_connect (dhcpctl_handle *connection, + char *server_name, int port, + dhcpctl_handle *authinfo) + synchronous + returns nonzero status code if it didn't connect, zero otherwise + stores connection handle through connection, which can be used + for subsequent access to the specified server. + server_name is the name of the server, and port is the TCP + port on which it is listening. + authinfo is the handle to an object containing authentication + information. + +dhcpctl_status dhcpctl_open_object (dhcpctl_handle h, + dhcpctl_handle connection, + int flags) + asynchronous - just queues the request + returns nonzero status code if open couldn't be queued + returns zero if open was queued + h is a handle to an object created by dhcpctl_new_object + connection is a connection to a DHCP server + flags include: + DHCPCTL_CREATE - if the object doesn't exist, create it + DHCPCTL_UPDATE - update the object on the server using the + attached parameters + DHCPCTL_EXCL - error if the object exists and DHCPCTL_CREATE + was also specified + +dhcpctl_status dhcpctl_new_object (dhcpctl_handle *h, + dhcpctl_handle connection, + char *object_type) + synchronous - creates a local handle for a host entry. + returns nonzero status code if the local host entry couldn't + be created + stores handle to host through h if successful, and returns zero. + object_type is a pointer to a NUL-terminated string containing + the ascii name of the type of object being accessed - e.g., "host" + +dhcpctl_status dhcpctl_set_callback (dhcpctl_handle h, void *data, + void (*callback) (dhcpctl_handle, + dhcpctl_status, void *)) + synchronous, with asynchronous aftereffect + handle is some object upon which some kind of process has been + started - e.g., an open, an update or a refresh. + data is an anonymous pointer containing some information that + the callback will use to figure out what event completed. + return value of 0 means callback was successfully set, a nonzero + status code is returned otherwise. + Upon completion of whatever task is in process, the callback + will be passed the handle to the object, a status code + indicating what happened, and the anonymous pointer passed to + +dhcpctl_status dhcpctl_wait_for_completion (dhcpctl_handle h, + dhcpctl_status *s) + synchronous + returns zero if the callback completes, a nonzero status if + there was some problem relating to the wait operation. The + status of the queued request will be stored through s, and + will also be either zero for success or nonzero for some kind + of failure. Never returns until completion or until the + connection to the server is lost. This performs the same + function as dhcpctl_set_callback and the subsequent callback, + for programs that want to do inline execution instead of using + callbacks. + +dhcpctl_status dhcpctl_get_value (data_string *result, + dhcpctl_handle h, char *value_name) + synchronous + returns zero if the call succeeded, a nonzero status code if + it didn't. + result is the address of an empty data string (initialized + with bzero or cleared with data_string_forget). On + successful completion, the addressed data string will contain + the value that was fetched. + dhcpctl_handle refers to some dhcpctl item + value_name refers to some value related to that item - e.g., + for a handle associated with a completed host lookup, value + could be one of "hardware-address", "dhcp-client-identifier", + "known" or "client-hostname". + +dhcpctl_status dhcpctl_get_boolean (int *result, + dhcpctl_handle h, char *value_name) + like dhcpctl_get_value, but more convenient for boolean + values, since no data_string needs to be dealt with. + +dhcpctl_status dhcpctl_set_value (dhcpctl_handle h, data_string value, + char *value_name) + Sets a value on an object referred to by a dhcpctl_handle. + The opposite of dhcpctl_get_value. Does not update the + server - just sets the value on the handle. + +dhcpctl_status dhcpctl_set_string_value (dhcpctl_handle h, char *value, + char *value_name) + Sets a NUL-terminated ASCII value on an object referred to by + a dhcpctl_handle. like dhcpctl_set_value, but saves the + trouble of creating a data_string for a NUL-terminated string. + Does not update the server - just sets the value on the handle. + +dhcpctl_status dhcpctl_set_boolean (dhcpctl_handle h, int value, + char *value_name) + Sets a boolean value on an object - like dhcpctl_set_value, + only more convenient for booleans. + +dhcpctl_status dhcpctl_object_update (dhcpctl_handle h) + Queues an update on the object referenced by the handle (there + can't be any other work in progress on the handle). An + update means local parameters will be sent to the server. + +dhcpctl_status dhcpctl_object_refresh (dhcpctl_handle h) + Queues an update on the object referenced by the handle (there + can't be any other work in progress on the handle). An + update means local parameters will be sent to the server. + +dhcpctl_status dhcpctl_object_delete (dhcpctl_handle h) + Queues a delete of the object referenced by the handle (there + can't be any other work in progress on the handle). A + delete means that the object will be permanently deleted on + the remote end, assuming the remote end supports object + persistence. + +So a sample program that would update a host declaration would look +something like this: + + /* Create a local object into which to store authentication + information. */ + if ((status = dhcpctl_new_object (&auth, dhcpctl_null_handle, + "authentication-information"))) + dhcpctl_error ("Can't create authentication information: %m"); + + /* Set up the authenticator with an algorithm type, user name and + password. */ + if ((status = dhcpctl_set_string_value (&auth, "mellon", "username"))) + dhcpctl_error ("Can't set username: %m", status); + if ((status = dhcpctl_set_string_value (&auth, "three blind mice", + "password"))) + dhcpctl_error ("Can't set password: %m", status); + if ((status = dhcpctl_set_string_value (&auth, "md5-hash", + "algorithm"))) + dhcpctl_error ("Can't set authentication algorithm: %m.", + status); + + /* Connect to the server. */ + if ((status = dhcpctl_connect (&c, "dhcp.server.com", 612, &auth))) + + dhcpctl_error ("Can't connect to dhcp.server.com: %m", + status); + + /* Create a host object. */ + if ((status = dhcpctl_new_object (&hp, c, "host"))) + dhcpctl_error ("Host create failed: %m", status); + + /* Create a data_string to contain the host's client + identifier, and set it. */ + if ((status = + data_string_create_from_hex (&client_id, + "1:08:00:2b:34:1a:c3"))) + dhcpctl_error ("Can't create client identifier: %m"); + if ((status = dhcpctl_set_value (hp, client_id, + "dhcp-client-identifier"))) + dhcpctl_error ("Host client identifier set failed."); + /* Set the known flag to 1. */ + if ((status = dhcpctl_set_boolean (hp, 1, "known"))) + dhcpctl_error ("Host known set failed."); + + /* Open an existing host object that matches the client identifier, + and update it from the local context, or if no host entry + yet exists matching the identifier, create one and + initialize it. */ + if ((status = dhcpctl_open_object (&hp, c, + DHCPCTL_CREATE | DHCPCTL_UPDATE))) + dhcpctl_error ("Can't open host: %m", status); + + /* Wait for the process to complete, check status. */ + if ((status = dhcpctl_wait_for_completion (hp, &wait_status))) + dhcpctl_error ("Host create/lookup wait failed: %m", status); + if (waitstatus) + dhcpctl_error ("Host create/lookup failed: %m", status); + +The API is a bit complicated, for a couple of reasons. I want to +make it general, so that there aren't a bazillion functions to call, +one for each data type. I want it to be thread-safe, which is why +each function returns a status and the error printer requires a status +code for input. I want it to be possible to make it asynchronous, so +that it can work in tandem with, for example, an X toolkit. If +you're just writing a simple update cgi program, you probably won't +want to bother to use the asynchronous callbacks, and indeed the above +example doesn't. + +I glossed over data strings above - basically, they're objects with a +pointer to a reference-counted buffer structure, an offset into that +buffer, and a length. These are used within the DHCP server, so you +can get an idea of how they work - basically, they're a convenient and +efficient way to store a string with a length such that substrings can +easily be taken and such that more than one user at a time can have a +pointer to the string. + +I will also probably add locking primitives, so that you can get the +value of something and be sure that some other updator process won't +modify it while you have the lock. diff --git a/doc/devel/arch.dox b/doc/devel/arch.dox new file mode 100644 index 0000000..6720f4a --- /dev/null +++ b/doc/devel/arch.dox @@ -0,0 +1,11 @@ +/** + +@page archSrv Server Architecture + +@todo: Describe high level server architecture here. + +@page archCli Client Architecture + +@todo: Describe high level client architecture here. + +*/
\ No newline at end of file diff --git a/doc/devel/atf.dox b/doc/devel/atf.dox new file mode 100644 index 0000000..dd59684 --- /dev/null +++ b/doc/devel/atf.dox @@ -0,0 +1,218 @@ +/** +@page tests Testing + +@section testsOverview Testing Overview + +In DHCP, a unit test exercises a particular piece of code in +isolation. There is a separate unit test per module or API. Each unit +test lives in a directory beneath the code it is designed to exercise. +So, we (will eventually) have: + +@verbatim +server/tests/ +client/tests/ +common/tests/ +dhcpctl/tests/ +... +@endverbatim + +And so on. + +Ideally each function would be invoked with every possible type of input, and +each branch of every function would be checked. In practice we try to be a bit +more pragmatic, and target the most basic operations, as well tricky code, and +areas we have seen bugs in the past. + +We are using <a href="http://code.google.com/p/kyua/wiki/ATF">ATF (Automated +Test Framework)</a> as a framework to run our unittests. + +@section testsAtf ATF unit-tests + +ATF stands for Automated Test Framework, and is the framework used for unit +tests in ISC DHCP and BIND9. ATF sources can be downloaded from +https://github.com/jmmv/kyua . ATF itself must be configured, compiled +and then installed to be available during the DHCP configure procedure. Please +follow INSTALL file supplied with ATF sources (it's essentially the typical +./configure && make && make install procedure). + +Beginning with ATF version 0.16, it is necessary to include the following +options --enable-tools and --disable-shared when configuring ATF: + +@verbatim + configure --prefix=<prefix> --enable-tools --disable-shared +@endverbatim + +ISC DHCP unittests will run with ATF releases upto 0.19. Beginning with +ATF 0.20, the tools, atf-run and atf-report required by ISC DHCP, were +deprecated and are no longer included with ATF. + +The ATF successor, called Kyua, is being developed. As of August 2012, the +latest available release of Kyua is 0.5. It claims to offer feature parity with +ATF. Migration to Kyua may be planned some time in the future, but DHCP uses ATF +for now. Such an upgrade should be done in coordination with BIND. + +To build and run the unit-tests, use the following: + +@verbatim +$ ./configure --with-atf +$ make +$ make check +@endverbatim + +This will traverse the source tree running the unit tests in each unit test +subdirectory. Note that if one or more tests in a unit test subdirectory fail +the make process will stop. To run all of the tests regardless of outcome, +use "make -k check" + +The following syntax is supported as well: +@verbatim +$ ./configure --with-atf=/path/to/your/atf/install +@endverbatim + +but it seems to have troubles sometimes detecting ATF installation, at least +with ATF 0.14 and Mac OS X 10.6.8. + +Each code directory (e.g. server/) that has unit-tests has a sub-directory +named tests (e.g. server/tests). You can execute "make check" in that +directory to run specific subset of tests. + +Unit-tests are grouped into suites, each suite being a separate +executable. The typical way to run tests is: + +@verbatim +$ atf-run | atf-report +(This assumes atf-run and atf-report are in your path) +or +$ sh ../../tests/unittests.sh +@endverbatim + +atf-run will read the Atffile in the current directory and execute all the tests +specified in it. Using atf-run - rather than calling the test binary directly - +has several major benefits. The main one is that atf-run is able to recover from +test segfault and continue execution from the next case onwards. Another is that +it is possible to specify a timeout for a test. atf-run will kill the test in +case of any infinite loops and will continue running next tests. + +It is possible to run atf-run without passing its output to atf-report, but its +output is somewhat convoluted. That is useful in some situations, e.g. when one +wants to see test output. + +It is possible to run test binary directly. The only required parameter is the +test case name. The binary will print out a warning that direct binary execution +is not recommended as it won't be able to recover from crash. However, such an +approach is convenient for running the test under the debugger. + +@section testsAtfAdding Adding new unit-tests + +There are a small number of unit-tests that are not ATF based. They will be +converted to ATF soon. Please do not use any other frameworks. + +Sadly, the DHCP code was not written with unit-testing in mind: often a +non-standard approach is required for writing unit-tests. The existing code +often has many dependencies that make testing a single piece of code awkward to +unit test. For example, to test hash tables, one needs to also include the +OMAPI code. Rather than significantly refactoring the code (a huge task that +could take months), we decided to link whatever is needed in the tests. If +developing new test suite, it is recommended that you take a look at existing +tests and just copy them as a starting point. + + +In particular, the following +things should be done for adding new tests: + +<b>1. Tests directory.</b> For each code component (server, client, common, +etc.) there should be a tests subdirectory. If it isn't there yet, then it must +be created. This can be done by: + +a). Creating the directory: + +@verbatim + $ mkdir $subdir/tests + $ cvs add tests +@endverbatim + +b). Adding the subdirectory to the build system: + + Add to $subdir/Makefile.am: + +@verbatim + SUBDIRS = tests +@endverbatim + + Add to the AC_OUTPUT macro in configure.ac: + +@verbatim + subdir/tests/Makefile +@endverbatim + +c. Create a Makefile.am in the new directory, something similar to this: + +@verbatim + AM_CPPFLAGS = -I../.. + + check_PROGRAMS = test_foo + + TESTS = test_foo + + test_foo_SOURCES = test_foo.c + test_foo_LDADD = ../../tests/libt_api.a # plus others... +@endverbatim + +See existing Makefile.am for examples, and the Automake documentation: + + http://www.gnu.org/software/automake/manual/html_node/Tests.html + +<b>2. Implement the test.</b> That typically means that you create a new file that will +hold test code. It is recommended you name it (tested_feature_name)_unittest.c +and put the file in specified tests directory. For example tests related to +hash tables used on the server side should be named +server/tests/hash_unittest.c. If in doubt, it is convenient to name the test +code after the file that holds tested code, e.g. server/mdb6.c is tested in +server/tests/mdb6_unittest.c. + +The file server/tests/simple_unittest.c holds a template explaining the basic +layout of the ATF tests. There may be many test cases in a single *_unittest.c +file. Make sure that you register all your test cases using ATF_TP_ADD_TC() +macro, and try to minimize modifications to the tested code if possible. Keep in +mind that we are using modernized \ref codingGuidelines for test +development. You are advised to also look at atf-c-api(3) man page. + +To add a new test, such as when a new module is added or when you want to start +testing existing code, you can copy the server/tests/simple_unittest.c as a new +new file, add the new file as a target in Makefile.am, and begin adding +tests. Reviewing that file is a good idea, even if you decide to write your test +from scratch, as it give you quick overview of the essential capabilities of the +ATF framework (how to write test, how to make checks, pass or fail test +etc.). Do not forget to add your new file to git via "git add +yourtest_unittest.c". + +<b>3. Extend Makefile.am</b> to build your test. In particular, add your binary +name to ATF_TESTS. The tests directory will be built only in case where +ATF is enabled, using --with-atf during configure phase. + +<b>4. Modify Atffile to include your new test</b>, if needed. Tests in the +specified directory must be registered in Atffile. See server/tests/Atffile for +an example. Currently every executable with name of the form *_unittest will be +executed automatically. If you followed naming convention proposed in a previous +step, your test will be included and will be included automatically. + +<b>5. Enjoy your improved confidence in the code</b>, as you can run the tests after +any change you may want to do: + +@verbatim +$ make check +@endverbatim + +to run all tests for all components. See \ref atfTests section for more details +on running tests. + +@section testsAtfCoding ATF Coding Guidelines + +As the unit-test code creates an evironment that works under a different +regime than the production code, there are slight differences to standard +coding guidelines. In particular: + +- The code is written using C99. Double slash comments are allowed. +- Please do not use tabs. Use 4 spaces for each indent level. + +*/ diff --git a/doc/devel/contrib.dox b/doc/devel/contrib.dox new file mode 100644 index 0000000..c978b88 --- /dev/null +++ b/doc/devel/contrib.dox @@ -0,0 +1,12 @@ +/** +@page contrib Contributing to DHCP + +@section contribDir 3rd party contributions in contrib/ directory + + @todo: Describe contrib/ dir + +@section codingGuidelines Coding Guidelines + + @todo: (... if people want to contribute significant code) + +*/ diff --git a/doc/devel/debug.dox b/doc/devel/debug.dox new file mode 100644 index 0000000..f9f4696 --- /dev/null +++ b/doc/devel/debug.dox @@ -0,0 +1,33 @@ +/** + @page debug Debugging + This page enumerates various techniques useful for debugging ISC DHCP software. + + @section debugTips Debugging Tips & Tricks + +ISC DHCP code is somewhat convoluted. Due to extensive macros use, it is often +difficult to even find whole function, much less to understand what they +actually do. One way to find such a macro-defined function is to compile the +code with debugging symbols (-g), load the binary into gdb and set a breakpoint +for such a function. gdb will print out exact place in the code where the +function is defined. Presumably one will find a macro at that specific location. +For example to find where \ref lease_reference function is defined do: + +@verbatim +gdb +file dhcpd +b lease_reference +@endverbatim + +DEBUG_MEMORY_LEAKAGE may be defined in includes/site.h to enable some debugging +code to help with debugging memory issues. This code keeps a running total +of the outstanding memory that has been allocated and a list of the outstanding +allocations. Both are updated whent he memory is freed. Status information is +printed when do_packet() and do_packet6() complete processing. The outstanding +value is expected to grow when new structures are used - for example when a new +IPv6 lease is created. It is not expected to grow when a structure is reused +for example when an IPv6 lease is renewed. + +DEBUG_RC_HISTORY and DEBUG_RC_HISTORY_EXHAUSTIVELY can also be defined to provide +more verbose information about reference counts on objects. + +*/ diff --git a/doc/devel/doxyfile.in b/doc/devel/doxyfile.in new file mode 100644 index 0000000..3ff0762 --- /dev/null +++ b/doc/devel/doxyfile.in @@ -0,0 +1,1792 @@ +# Doxyfile 1.8.1.1 + +# This file describes the settings to be used by the documentation system +# doxygen (www.doxygen.org) for a project. +# +# All text after a hash (#) is considered a comment and will be ignored. +# The format is: +# TAG = value [value, ...] +# For lists items can also be appended using: +# TAG += value [value, ...] +# Values that contain spaces should be placed between quotes (" "). + +#--------------------------------------------------------------------------- +# Project related configuration options +#--------------------------------------------------------------------------- + +# This tag specifies the encoding used for all characters in the config file +# that follow. The default is UTF-8 which is also the encoding used for all +# text before the first occurrence of this tag. Doxygen uses libiconv (or the +# iconv built into libc) for the transcoding. See +# http://www.gnu.org/software/libiconv for the list of possible encodings. + +DOXYFILE_ENCODING = UTF-8 + +# The PROJECT_NAME tag is a single word (or sequence of words) that should +# identify the project. Note that if you do not use Doxywizard you need +# to put quotes around the project name if it contains spaces. + +PROJECT_NAME = "ISC DHCP" + +# The PROJECT_NUMBER tag can be used to enter a project or revision number. +# This could be handy for archiving the generated documentation or +# if some version control system is used. + +PROJECT_NUMBER = @PACKAGE_VERSION@ + +# Using the PROJECT_BRIEF tag one can provide an optional one line description +# for a project that appears at the top of each page and should give viewer +# a quick idea about the purpose of the project. Keep the description short. + +PROJECT_BRIEF = "A reference DHCPv4 and DHCPv6 implementation" + +# With the PROJECT_LOGO tag one can specify an logo or icon that is +# included in the documentation. The maximum height of the logo should not +# exceed 55 pixels and the maximum width should not exceed 200 pixels. +# Doxygen will copy the logo to the output directory. + +PROJECT_LOGO = devel/isc-logo.jpg + +# The OUTPUT_DIRECTORY tag is used to specify the (relative or absolute) +# base path where the generated documentation will be put. +# If a relative path is entered, it will be relative to the location +# where doxygen was started. If left blank the current directory will be used. + +OUTPUT_DIRECTORY = + +# If the CREATE_SUBDIRS tag is set to YES, then doxygen will create +# 4096 sub-directories (in 2 levels) under the output directory of each output +# format and will distribute the generated files over these directories. +# Enabling this option can be useful when feeding doxygen a huge amount of +# source files, where putting all generated files in the same directory would +# otherwise cause performance problems for the file system. + +CREATE_SUBDIRS = YES + +# The OUTPUT_LANGUAGE tag is used to specify the language in which all +# documentation generated by doxygen is written. Doxygen will use this +# information to generate all constant output in the proper language. +# The default language is English, other supported languages are: +# Afrikaans, Arabic, Brazilian, Catalan, Chinese, Chinese-Traditional, +# Croatian, Czech, Danish, Dutch, Esperanto, Farsi, Finnish, French, German, +# Greek, Hungarian, Italian, Japanese, Japanese-en (Japanese with English +# messages), Korean, Korean-en, Lithuanian, Norwegian, Macedonian, Persian, +# Polish, Portuguese, Romanian, Russian, Serbian, Serbian-Cyrillic, Slovak, +# Slovene, Spanish, Swedish, Ukrainian, and Vietnamese. + +OUTPUT_LANGUAGE = English + +# If the BRIEF_MEMBER_DESC tag is set to YES (the default) Doxygen will +# include brief member descriptions after the members that are listed in +# the file and class documentation (similar to JavaDoc). +# Set to NO to disable this. + +BRIEF_MEMBER_DESC = YES + +# If the REPEAT_BRIEF tag is set to YES (the default) Doxygen will prepend +# the brief description of a member or function before the detailed description. +# Note: if both HIDE_UNDOC_MEMBERS and BRIEF_MEMBER_DESC are set to NO, the +# brief descriptions will be completely suppressed. + +REPEAT_BRIEF = YES + +# This tag implements a quasi-intelligent brief description abbreviator +# that is used to form the text in various listings. Each string +# in this list, if found as the leading text of the brief description, will be +# stripped from the text and the result after processing the whole list, is +# used as the annotated text. Otherwise, the brief description is used as-is. +# If left blank, the following values are used ("$name" is automatically +# replaced with the name of the entity): "The $name class" "The $name widget" +# "The $name file" "is" "provides" "specifies" "contains" +# "represents" "a" "an" "the" + +ABBREVIATE_BRIEF = + +# If the ALWAYS_DETAILED_SEC and REPEAT_BRIEF tags are both set to YES then +# Doxygen will generate a detailed section even if there is only a brief +# description. + +ALWAYS_DETAILED_SEC = NO + +# If the INLINE_INHERITED_MEMB tag is set to YES, doxygen will show all +# inherited members of a class in the documentation of that class as if those +# members were ordinary class members. Constructors, destructors and assignment +# operators of the base classes will not be shown. + +INLINE_INHERITED_MEMB = NO + +# If the FULL_PATH_NAMES tag is set to YES then Doxygen will prepend the full +# path before files name in the file list and in the header files. If set +# to NO the shortest path that makes the file name unique will be used. + +FULL_PATH_NAMES = YES + +# If the FULL_PATH_NAMES tag is set to YES then the STRIP_FROM_PATH tag +# can be used to strip a user-defined part of the path. Stripping is +# only done if one of the specified strings matches the left-hand part of +# the path. The tag can be used to show relative paths in the file list. +# If left blank the directory from which doxygen is run is used as the +# path to strip. + +STRIP_FROM_PATH = @abs_top_srcdir@ + +# The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of +# the path mentioned in the documentation of a class, which tells +# the reader which header file to include in order to use a class. +# If left blank only the name of the header file containing the class +# definition is used. Otherwise one should specify the include paths that +# are normally passed to the compiler using the -I flag. + +STRIP_FROM_INC_PATH = + +# If the SHORT_NAMES tag is set to YES, doxygen will generate much shorter +# (but less readable) file names. This can be useful if your file system +# doesn't support long names like on DOS, Mac, or CD-ROM. + +SHORT_NAMES = NO + +# If the JAVADOC_AUTOBRIEF tag is set to YES then Doxygen +# will interpret the first line (until the first dot) of a JavaDoc-style +# comment as the brief description. If set to NO, the JavaDoc +# comments will behave just like regular Qt-style comments +# (thus requiring an explicit @brief command for a brief description.) + +JAVADOC_AUTOBRIEF = NO + +# If the QT_AUTOBRIEF tag is set to YES then Doxygen will +# interpret the first line (until the first dot) of a Qt-style +# comment as the brief description. If set to NO, the comments +# will behave just like regular Qt-style comments (thus requiring +# an explicit \brief command for a brief description.) + +QT_AUTOBRIEF = NO + +# The MULTILINE_CPP_IS_BRIEF tag can be set to YES to make Doxygen +# treat a multi-line C++ special comment block (i.e. a block of //! or /// +# comments) as a brief description. This used to be the default behaviour. +# The new default is to treat a multi-line C++ comment block as a detailed +# description. Set this tag to YES if you prefer the old behaviour instead. + +MULTILINE_CPP_IS_BRIEF = NO + +# If the INHERIT_DOCS tag is set to YES (the default) then an undocumented +# member inherits the documentation from any documented member that it +# re-implements. + +INHERIT_DOCS = YES + +# If the SEPARATE_MEMBER_PAGES tag is set to YES, then doxygen will produce +# a new page for each member. If set to NO, the documentation of a member will +# be part of the file/class/namespace that contains it. + +SEPARATE_MEMBER_PAGES = NO + +# The TAB_SIZE tag can be used to set the number of spaces in a tab. +# Doxygen uses this value to replace tabs by spaces in code fragments. + +TAB_SIZE = 8 + +# This tag can be used to specify a number of aliases that acts +# as commands in the documentation. An alias has the form "name=value". +# For example adding "sideeffect=\par Side Effects:\n" will allow you to +# put the command \sideeffect (or @sideeffect) in the documentation, which +# will result in a user-defined paragraph with heading "Side Effects:". +# You can put \n's in the value part of an alias to insert newlines. + +ALIASES = + +# This tag can be used to specify a number of word-keyword mappings (TCL only). +# A mapping has the form "name=value". For example adding +# "class=itcl::class" will allow you to use the command class in the +# itcl::class meaning. + +TCL_SUBST = + +# Set the OPTIMIZE_OUTPUT_FOR_C tag to YES if your project consists of C +# sources only. Doxygen will then generate output that is more tailored for C. +# For instance, some of the names that are used will be different. The list +# of all members will be omitted, etc. + +OPTIMIZE_OUTPUT_FOR_C = YES + +# Set the OPTIMIZE_OUTPUT_JAVA tag to YES if your project consists of Java +# sources only. Doxygen will then generate output that is more tailored for +# Java. For instance, namespaces will be presented as packages, qualified +# scopes will look different, etc. + +OPTIMIZE_OUTPUT_JAVA = NO + +# Set the OPTIMIZE_FOR_FORTRAN tag to YES if your project consists of Fortran +# sources only. Doxygen will then generate output that is more tailored for +# Fortran. + +OPTIMIZE_FOR_FORTRAN = NO + +# Set the OPTIMIZE_OUTPUT_VHDL tag to YES if your project consists of VHDL +# sources. Doxygen will then generate output that is tailored for +# VHDL. + +OPTIMIZE_OUTPUT_VHDL = NO + +# Doxygen selects the parser to use depending on the extension of the files it +# parses. With this tag you can assign which parser to use for a given extension. +# Doxygen has a built-in mapping, but you can override or extend it using this +# tag. The format is ext=language, where ext is a file extension, and language +# is one of the parsers supported by doxygen: IDL, Java, Javascript, CSharp, C, +# C++, D, PHP, Objective-C, Python, Fortran, VHDL, C, C++. For instance to make +# doxygen treat .inc files as Fortran files (default is PHP), and .f files as C +# (default is Fortran), use: inc=Fortran f=C. Note that for custom extensions +# you also need to set FILE_PATTERNS otherwise the files are not read by doxygen. + +EXTENSION_MAPPING = + +# If MARKDOWN_SUPPORT is enabled (the default) then doxygen pre-processes all +# comments according to the Markdown format, which allows for more readable +# documentation. See http://daringfireball.net/projects/markdown/ for details. +# The output of markdown processing is further processed by doxygen, so you +# can mix doxygen, HTML, and XML commands with Markdown formatting. +# Disable only in case of backward compatibilities issues. + +MARKDOWN_SUPPORT = YES + +# If you use STL classes (i.e. std::string, std::vector, etc.) but do not want +# to include (a tag file for) the STL sources as input, then you should +# set this tag to YES in order to let doxygen match functions declarations and +# definitions whose arguments contain STL classes (e.g. func(std::string); v.s. +# func(std::string) {}). This also makes the inheritance and collaboration +# diagrams that involve STL classes more complete and accurate. + +BUILTIN_STL_SUPPORT = NO + +# If you use Microsoft's C++/CLI language, you should set this option to YES to +# enable parsing support. + +CPP_CLI_SUPPORT = NO + +# Set the SIP_SUPPORT tag to YES if your project consists of sip sources only. +# Doxygen will parse them like normal C++ but will assume all classes use public +# instead of private inheritance when no explicit protection keyword is present. + +SIP_SUPPORT = NO + +# For Microsoft's IDL there are propget and propput attributes to indicate getter +# and setter methods for a property. Setting this option to YES (the default) +# will make doxygen replace the get and set methods by a property in the +# documentation. This will only work if the methods are indeed getting or +# setting a simple type. If this is not the case, or you want to show the +# methods anyway, you should set this option to NO. + +IDL_PROPERTY_SUPPORT = YES + +# If member grouping is used in the documentation and the DISTRIBUTE_GROUP_DOC +# tag is set to YES, then doxygen will reuse the documentation of the first +# member in the group (if any) for the other members of the group. By default +# all members of a group must be documented explicitly. + +DISTRIBUTE_GROUP_DOC = NO + +# Set the SUBGROUPING tag to YES (the default) to allow class member groups of +# the same type (for instance a group of public functions) to be put as a +# subgroup of that type (e.g. under the Public Functions section). Set it to +# NO to prevent subgrouping. Alternatively, this can be done per class using +# the \nosubgrouping command. + +SUBGROUPING = YES + +# When the INLINE_GROUPED_CLASSES tag is set to YES, classes, structs and +# unions are shown inside the group in which they are included (e.g. using +# @ingroup) instead of on a separate page (for HTML and Man pages) or +# section (for LaTeX and RTF). + +INLINE_GROUPED_CLASSES = NO + +# When the INLINE_SIMPLE_STRUCTS tag is set to YES, structs, classes, and +# unions with only public data fields will be shown inline in the documentation +# of the scope in which they are defined (i.e. file, namespace, or group +# documentation), provided this scope is documented. If set to NO (the default), +# structs, classes, and unions are shown on a separate page (for HTML and Man +# pages) or section (for LaTeX and RTF). + +INLINE_SIMPLE_STRUCTS = NO + +# When TYPEDEF_HIDES_STRUCT is enabled, a typedef of a struct, union, or enum +# is documented as struct, union, or enum with the name of the typedef. So +# typedef struct TypeS {} TypeT, will appear in the documentation as a struct +# with name TypeT. When disabled the typedef will appear as a member of a file, +# namespace, or class. And the struct will be named TypeS. This can typically +# be useful for C code in case the coding convention dictates that all compound +# types are typedef'ed and only the typedef is referenced, never the tag name. + +TYPEDEF_HIDES_STRUCT = NO + +# The SYMBOL_CACHE_SIZE determines the size of the internal cache use to +# determine which symbols to keep in memory and which to flush to disk. +# When the cache is full, less often used symbols will be written to disk. +# For small to medium size projects (<1000 input files) the default value is +# probably good enough. For larger projects a too small cache size can cause +# doxygen to be busy swapping symbols to and from disk most of the time +# causing a significant performance penalty. +# If the system has enough physical memory increasing the cache will improve the +# performance by keeping more symbols in memory. Note that the value works on +# a logarithmic scale so increasing the size by one will roughly double the +# memory usage. The cache size is given by this formula: +# 2^(16+SYMBOL_CACHE_SIZE). The valid range is 0..9, the default is 0, +# corresponding to a cache size of 2^16 = 65536 symbols. + +SYMBOL_CACHE_SIZE = 0 + +# Similar to the SYMBOL_CACHE_SIZE the size of the symbol lookup cache can be +# set using LOOKUP_CACHE_SIZE. This cache is used to resolve symbols given +# their name and scope. Since this can be an expensive process and often the +# same symbol appear multiple times in the code, doxygen keeps a cache of +# pre-resolved symbols. If the cache is too small doxygen will become slower. +# If the cache is too large, memory is wasted. The cache size is given by this +# formula: 2^(16+LOOKUP_CACHE_SIZE). The valid range is 0..9, the default is 0, +# corresponding to a cache size of 2^16 = 65536 symbols. + +LOOKUP_CACHE_SIZE = 0 + +#--------------------------------------------------------------------------- +# Build related configuration options +#--------------------------------------------------------------------------- + +# If the EXTRACT_ALL tag is set to YES doxygen will assume all entities in +# documentation are documented, even if no documentation was available. +# Private class members and static file members will be hidden unless +# the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES + +EXTRACT_ALL = YES + +# If the EXTRACT_PRIVATE tag is set to YES all private members of a class +# will be included in the documentation. + +EXTRACT_PRIVATE = NO + +# If the EXTRACT_PACKAGE tag is set to YES all members with package or internal scope will be included in the documentation. + +EXTRACT_PACKAGE = NO + +# If the EXTRACT_STATIC tag is set to YES all static members of a file +# will be included in the documentation. + +EXTRACT_STATIC = NO + +# If the EXTRACT_LOCAL_CLASSES tag is set to YES classes (and structs) +# defined locally in source files will be included in the documentation. +# If set to NO only classes defined in header files are included. + +EXTRACT_LOCAL_CLASSES = YES + +# This flag is only useful for Objective-C code. When set to YES local +# methods, which are defined in the implementation section but not in +# the interface are included in the documentation. +# If set to NO (the default) only methods in the interface are included. + +EXTRACT_LOCAL_METHODS = NO + +# If this flag is set to YES, the members of anonymous namespaces will be +# extracted and appear in the documentation as a namespace called +# 'anonymous_namespace{file}', where file will be replaced with the base +# name of the file that contains the anonymous namespace. By default +# anonymous namespaces are hidden. + +EXTRACT_ANON_NSPACES = NO + +# If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all +# undocumented members of documented classes, files or namespaces. +# If set to NO (the default) these members will be included in the +# various overviews, but no documentation section is generated. +# This option has no effect if EXTRACT_ALL is enabled. + +HIDE_UNDOC_MEMBERS = NO + +# If the HIDE_UNDOC_CLASSES tag is set to YES, Doxygen will hide all +# undocumented classes that are normally visible in the class hierarchy. +# If set to NO (the default) these classes will be included in the various +# overviews. This option has no effect if EXTRACT_ALL is enabled. + +HIDE_UNDOC_CLASSES = NO + +# If the HIDE_FRIEND_COMPOUNDS tag is set to YES, Doxygen will hide all +# friend (class|struct|union) declarations. +# If set to NO (the default) these declarations will be included in the +# documentation. + +HIDE_FRIEND_COMPOUNDS = NO + +# If the HIDE_IN_BODY_DOCS tag is set to YES, Doxygen will hide any +# documentation blocks found inside the body of a function. +# If set to NO (the default) these blocks will be appended to the +# function's detailed documentation block. + +HIDE_IN_BODY_DOCS = NO + +# The INTERNAL_DOCS tag determines if documentation +# that is typed after a \internal command is included. If the tag is set +# to NO (the default) then the documentation will be excluded. +# Set it to YES to include the internal documentation. + +INTERNAL_DOCS = NO + +# If the CASE_SENSE_NAMES tag is set to NO then Doxygen will only generate +# file names in lower-case letters. If set to YES upper-case letters are also +# allowed. This is useful if you have classes or files whose names only differ +# in case and if your file system supports case sensitive file names. Windows +# and Mac users are advised to set this option to NO. + +CASE_SENSE_NAMES = YES + +# If the HIDE_SCOPE_NAMES tag is set to NO (the default) then Doxygen +# will show members with their full class and namespace scopes in the +# documentation. If set to YES the scope will be hidden. + +HIDE_SCOPE_NAMES = NO + +# If the SHOW_INCLUDE_FILES tag is set to YES (the default) then Doxygen +# will put a list of the files that are included by a file in the documentation +# of that file. + +SHOW_INCLUDE_FILES = YES + +# If the FORCE_LOCAL_INCLUDES tag is set to YES then Doxygen +# will list include files with double quotes in the documentation +# rather than with sharp brackets. + +FORCE_LOCAL_INCLUDES = NO + +# If the INLINE_INFO tag is set to YES (the default) then a tag [inline] +# is inserted in the documentation for inline members. + +INLINE_INFO = YES + +# If the SORT_MEMBER_DOCS tag is set to YES (the default) then doxygen +# will sort the (detailed) documentation of file and class members +# alphabetically by member name. If set to NO the members will appear in +# declaration order. + +SORT_MEMBER_DOCS = YES + +# If the SORT_BRIEF_DOCS tag is set to YES then doxygen will sort the +# brief documentation of file, namespace and class members alphabetically +# by member name. If set to NO (the default) the members will appear in +# declaration order. + +SORT_BRIEF_DOCS = NO + +# If the SORT_MEMBERS_CTORS_1ST tag is set to YES then doxygen +# will sort the (brief and detailed) documentation of class members so that +# constructors and destructors are listed first. If set to NO (the default) +# the constructors will appear in the respective orders defined by +# SORT_MEMBER_DOCS and SORT_BRIEF_DOCS. +# This tag will be ignored for brief docs if SORT_BRIEF_DOCS is set to NO +# and ignored for detailed docs if SORT_MEMBER_DOCS is set to NO. + +SORT_MEMBERS_CTORS_1ST = NO + +# If the SORT_GROUP_NAMES tag is set to YES then doxygen will sort the +# hierarchy of group names into alphabetical order. If set to NO (the default) +# the group names will appear in their defined order. + +SORT_GROUP_NAMES = NO + +# If the SORT_BY_SCOPE_NAME tag is set to YES, the class list will be +# sorted by fully-qualified names, including namespaces. If set to +# NO (the default), the class list will be sorted only by class name, +# not including the namespace part. +# Note: This option is not very useful if HIDE_SCOPE_NAMES is set to YES. +# Note: This option applies only to the class list, not to the +# alphabetical list. + +SORT_BY_SCOPE_NAME = NO + +# If the STRICT_PROTO_MATCHING option is enabled and doxygen fails to +# do proper type resolution of all parameters of a function it will reject a +# match between the prototype and the implementation of a member function even +# if there is only one candidate or it is obvious which candidate to choose +# by doing a simple string match. By disabling STRICT_PROTO_MATCHING doxygen +# will still accept a match between prototype and implementation in such cases. + +STRICT_PROTO_MATCHING = NO + +# The GENERATE_TODOLIST tag can be used to enable (YES) or +# disable (NO) the todo list. This list is created by putting \todo +# commands in the documentation. + +GENERATE_TODOLIST = YES + +# The GENERATE_TESTLIST tag can be used to enable (YES) or +# disable (NO) the test list. This list is created by putting \test +# commands in the documentation. + +GENERATE_TESTLIST = YES + +# The GENERATE_BUGLIST tag can be used to enable (YES) or +# disable (NO) the bug list. This list is created by putting \bug +# commands in the documentation. + +GENERATE_BUGLIST = YES + +# The GENERATE_DEPRECATEDLIST tag can be used to enable (YES) or +# disable (NO) the deprecated list. This list is created by putting +# \deprecated commands in the documentation. + +GENERATE_DEPRECATEDLIST= YES + +# The ENABLED_SECTIONS tag can be used to enable conditional +# documentation sections, marked by \if sectionname ... \endif. + +ENABLED_SECTIONS = + +# The MAX_INITIALIZER_LINES tag determines the maximum number of lines +# the initial value of a variable or macro consists of for it to appear in +# the documentation. If the initializer consists of more lines than specified +# here it will be hidden. Use a value of 0 to hide initializers completely. +# The appearance of the initializer of individual variables and macros in the +# documentation can be controlled using \showinitializer or \hideinitializer +# command in the documentation regardless of this setting. + +MAX_INITIALIZER_LINES = 30 + +# Set the SHOW_USED_FILES tag to NO to disable the list of files generated +# at the bottom of the documentation of classes and structs. If set to YES the +# list will mention the files that were used to generate the documentation. + +SHOW_USED_FILES = YES + +# Set the SHOW_FILES tag to NO to disable the generation of the Files page. +# This will remove the Files entry from the Quick Index and from the +# Folder Tree View (if specified). The default is YES. + +SHOW_FILES = YES + +# Set the SHOW_NAMESPACES tag to NO to disable the generation of the +# Namespaces page. +# This will remove the Namespaces entry from the Quick Index +# and from the Folder Tree View (if specified). The default is YES. + +SHOW_NAMESPACES = YES + +# The FILE_VERSION_FILTER tag can be used to specify a program or script that +# doxygen should invoke to get the current version for each file (typically from +# the version control system). Doxygen will invoke the program by executing (via +# popen()) the command <command> <input-file>, where <command> is the value of +# the FILE_VERSION_FILTER tag, and <input-file> is the name of an input file +# provided by doxygen. Whatever the program writes to standard output +# is used as the file version. See the manual for examples. + +FILE_VERSION_FILTER = + +# The LAYOUT_FILE tag can be used to specify a layout file which will be parsed +# by doxygen. The layout file controls the global structure of the generated +# output files in an output format independent way. To create the layout file +# that represents doxygen's defaults, run doxygen with the -l option. +# You can optionally specify a file name after the option, if omitted +# DoxygenLayout.xml will be used as the name of the layout file. + +LAYOUT_FILE = + +# The CITE_BIB_FILES tag can be used to specify one or more bib files +# containing the references data. This must be a list of .bib files. The +# .bib extension is automatically appended if omitted. Using this command +# requires the bibtex tool to be installed. See also +# http://en.wikipedia.org/wiki/BibTeX for more info. For LaTeX the style +# of the bibliography can be controlled using LATEX_BIB_STYLE. To use this +# feature you need bibtex and perl available in the search path. + +CITE_BIB_FILES = + +#--------------------------------------------------------------------------- +# configuration options related to warning and progress messages +#--------------------------------------------------------------------------- + +# The QUIET tag can be used to turn on/off the messages that are generated +# by doxygen. Possible values are YES and NO. If left blank NO is used. + +QUIET = NO + +# The WARNINGS tag can be used to turn on/off the warning messages that are +# generated by doxygen. Possible values are YES and NO. If left blank +# NO is used. + +WARNINGS = YES + +# If WARN_IF_UNDOCUMENTED is set to YES, then doxygen will generate warnings +# for undocumented members. If EXTRACT_ALL is set to YES then this flag will +# automatically be disabled. + +WARN_IF_UNDOCUMENTED = YES + +# If WARN_IF_DOC_ERROR is set to YES, doxygen will generate warnings for +# potential errors in the documentation, such as not documenting some +# parameters in a documented function, or documenting parameters that +# don't exist or using markup commands wrongly. + +WARN_IF_DOC_ERROR = YES + +# The WARN_NO_PARAMDOC option can be enabled to get warnings for +# functions that are documented, but have no documentation for their parameters +# or return value. If set to NO (the default) doxygen will only warn about +# wrong or incomplete parameter documentation, but not about the absence of +# documentation. + +WARN_NO_PARAMDOC = YES + +# The WARN_FORMAT tag determines the format of the warning messages that +# doxygen can produce. The string should contain the $file, $line, and $text +# tags, which will be replaced by the file and line number from which the +# warning originated and the warning text. Optionally the format may contain +# $version, which will be replaced by the version of the file (if it could +# be obtained via FILE_VERSION_FILTER) + +WARN_FORMAT = "$file:$line: $text" + +# The WARN_LOGFILE tag can be used to specify a file to which warning +# and error messages should be written. If left blank the output is written +# to stderr. + +WARN_LOGFILE = doxygen-warnings.log + +#--------------------------------------------------------------------------- +# configuration options related to the input files +#--------------------------------------------------------------------------- + +# The INPUT tag can be used to specify the files and/or directories that contain +# documented source files. You may enter file names like "myfile.cpp" or +# directories like "/usr/src/myproject". Separate the files or directories +# with spaces. + +INPUT = .. + +# This tag can be used to specify the character encoding of the source files +# that doxygen parses. Internally doxygen uses the UTF-8 encoding, which is +# also the default input encoding. Doxygen uses libiconv (or the iconv built +# into libc) for the transcoding. See http://www.gnu.org/software/libiconv for +# the list of possible encodings. + +INPUT_ENCODING = UTF-8 + +# If the value of the INPUT tag contains directories, you can use the +# FILE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp +# and *.h) to filter out the source-files in the directories. If left +# blank the following patterns are tested: +# *.c *.cc *.cxx *.cpp *.c++ *.d *.java *.ii *.ixx *.ipp *.i++ *.inl *.h *.hh +# *.hxx *.hpp *.h++ *.idl *.odl *.cs *.php *.php3 *.inc *.m *.mm *.dox *.py +# *.f90 *.f *.for *.vhd *.vhdl + +FILE_PATTERNS = *.c *.h *.dox + +# The RECURSIVE tag can be used to turn specify whether or not subdirectories +# should be searched for input files as well. Possible values are YES and NO. +# If left blank NO is used. + +RECURSIVE = YES + +# The EXCLUDE tag can be used to specify files and/or directories that should be +# excluded from the INPUT source files. This way you can easily exclude a +# subdirectory from a directory tree whose root is specified with the INPUT tag. +# Note that relative paths are relative to the directory from which doxygen is +# run. + +EXCLUDE = + +# The EXCLUDE_SYMLINKS tag can be used to select whether or not files or +# directories that are symbolic links (a Unix file system feature) are excluded +# from the input. + +EXCLUDE_SYMLINKS = NO + +# If the value of the INPUT tag contains directories, you can use the +# EXCLUDE_PATTERNS tag to specify one or more wildcard patterns to exclude +# certain files from those directories. Note that the wildcards are matched +# against the file with absolute path, so to exclude all test directories +# for example use the pattern */test/* + +EXCLUDE_PATTERNS = */tests/* */bind/* + +# The EXCLUDE_SYMBOLS tag can be used to specify one or more symbol names +# (namespaces, classes, functions, etc.) that should be excluded from the +# output. The symbol name can be a fully qualified name, a word, or if the +# wildcard * is used, a substring. Examples: ANamespace, AClass, +# AClass::ANamespace, ANamespace::*Test + +EXCLUDE_SYMBOLS = + +# The EXAMPLE_PATH tag can be used to specify one or more files or +# directories that contain example code fragments that are included (see +# the \include command). + +EXAMPLE_PATH = + +# If the value of the EXAMPLE_PATH tag contains directories, you can use the +# EXAMPLE_PATTERNS tag to specify one or more wildcard pattern (like *.cpp +# and *.h) to filter out the source-files in the directories. If left +# blank all files are included. + +EXAMPLE_PATTERNS = + +# If the EXAMPLE_RECURSIVE tag is set to YES then subdirectories will be +# searched for input files to be used with the \include or \dontinclude +# commands irrespective of the value of the RECURSIVE tag. +# Possible values are YES and NO. If left blank NO is used. + +EXAMPLE_RECURSIVE = NO + +# The IMAGE_PATH tag can be used to specify one or more files or +# directories that contain image that are included in the documentation (see +# the \image command). + +IMAGE_PATH = + +# The INPUT_FILTER tag can be used to specify a program that doxygen should +# invoke to filter for each input file. Doxygen will invoke the filter program +# by executing (via popen()) the command <filter> <input-file>, where <filter> +# is the value of the INPUT_FILTER tag, and <input-file> is the name of an +# input file. Doxygen will then use the output that the filter program writes +# to standard output. +# If FILTER_PATTERNS is specified, this tag will be +# ignored. + +INPUT_FILTER = + +# The FILTER_PATTERNS tag can be used to specify filters on a per file pattern +# basis. +# Doxygen will compare the file name with each pattern and apply the +# filter if there is a match. +# The filters are a list of the form: +# pattern=filter (like *.cpp=my_cpp_filter). See INPUT_FILTER for further +# info on how filters are used. If FILTER_PATTERNS is empty or if +# non of the patterns match the file name, INPUT_FILTER is applied. + +FILTER_PATTERNS = + +# If the FILTER_SOURCE_FILES tag is set to YES, the input filter (if set using +# INPUT_FILTER) will be used to filter the input files when producing source +# files to browse (i.e. when SOURCE_BROWSER is set to YES). + +FILTER_SOURCE_FILES = NO + +# The FILTER_SOURCE_PATTERNS tag can be used to specify source filters per file +# pattern. A pattern will override the setting for FILTER_PATTERN (if any) +# and it is also possible to disable source filtering for a specific pattern +# using *.ext= (so without naming a filter). This option only has effect when +# FILTER_SOURCE_FILES is enabled. + +FILTER_SOURCE_PATTERNS = + +#--------------------------------------------------------------------------- +# configuration options related to source browsing +#--------------------------------------------------------------------------- + +# If the SOURCE_BROWSER tag is set to YES then a list of source files will +# be generated. Documented entities will be cross-referenced with these sources. +# Note: To get rid of all source code in the generated output, make sure also +# VERBATIM_HEADERS is set to NO. + +SOURCE_BROWSER = YES + +# Setting the INLINE_SOURCES tag to YES will include the body +# of functions and classes directly in the documentation. + +INLINE_SOURCES = NO + +# Setting the STRIP_CODE_COMMENTS tag to YES (the default) will instruct +# doxygen to hide any special comment blocks from generated source code +# fragments. Normal C, C++ and Fortran comments will always remain visible. + +STRIP_CODE_COMMENTS = YES + +# If the REFERENCED_BY_RELATION tag is set to YES +# then for each documented function all documented +# functions referencing it will be listed. + +REFERENCED_BY_RELATION = NO + +# If the REFERENCES_RELATION tag is set to YES +# then for each documented function all documented entities +# called/used by that function will be listed. + +REFERENCES_RELATION = NO + +# If the REFERENCES_LINK_SOURCE tag is set to YES (the default) +# and SOURCE_BROWSER tag is set to YES, then the hyperlinks from +# functions in REFERENCES_RELATION and REFERENCED_BY_RELATION lists will +# link to the source code. +# Otherwise they will link to the documentation. + +REFERENCES_LINK_SOURCE = YES + +# If the USE_HTAGS tag is set to YES then the references to source code +# will point to the HTML generated by the htags(1) tool instead of doxygen +# built-in source browser. The htags tool is part of GNU's global source +# tagging system (see http://www.gnu.org/software/global/global.html). You +# will need version 4.8.6 or higher. + +USE_HTAGS = NO + +# If the VERBATIM_HEADERS tag is set to YES (the default) then Doxygen +# will generate a verbatim copy of the header file for each class for +# which an include is specified. Set to NO to disable this. + +VERBATIM_HEADERS = YES + +#--------------------------------------------------------------------------- +# configuration options related to the alphabetical class index +#--------------------------------------------------------------------------- + +# If the ALPHABETICAL_INDEX tag is set to YES, an alphabetical index +# of all compounds will be generated. Enable this if the project +# contains a lot of classes, structs, unions or interfaces. + +ALPHABETICAL_INDEX = YES + +# If the alphabetical index is enabled (see ALPHABETICAL_INDEX) then +# the COLS_IN_ALPHA_INDEX tag can be used to specify the number of columns +# in which this list will be split (can be a number in the range [1..20]) + +COLS_IN_ALPHA_INDEX = 5 + +# In case all classes in a project start with a common prefix, all +# classes will be put under the same header in the alphabetical index. +# The IGNORE_PREFIX tag can be used to specify one or more prefixes that +# should be ignored while generating the index headers. + +IGNORE_PREFIX = + +#--------------------------------------------------------------------------- +# configuration options related to the HTML output +#--------------------------------------------------------------------------- + +# If the GENERATE_HTML tag is set to YES (the default) Doxygen will +# generate HTML output. + +GENERATE_HTML = YES + +# The HTML_OUTPUT tag is used to specify where the HTML docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `html' will be used as the default path. + +HTML_OUTPUT = html + +# The HTML_FILE_EXTENSION tag can be used to specify the file extension for +# each generated HTML page (for example: .htm,.php,.asp). If it is left blank +# doxygen will generate files with .html extension. + +HTML_FILE_EXTENSION = .html + +# The HTML_HEADER tag can be used to specify a personal HTML header for +# each generated HTML page. If it is left blank doxygen will generate a +# standard header. Note that when using a custom header you are responsible +# for the proper inclusion of any scripts and style sheets that doxygen +# needs, which is dependent on the configuration options used. +# It is advised to generate a default header using "doxygen -w html +# header.html footer.html stylesheet.css YourConfigFile" and then modify +# that header. Note that the header is subject to change so you typically +# have to redo this when upgrading to a newer version of doxygen or when +# changing the value of configuration settings such as GENERATE_TREEVIEW! + +HTML_HEADER = + +# The HTML_FOOTER tag can be used to specify a personal HTML footer for +# each generated HTML page. If it is left blank doxygen will generate a +# standard footer. + +HTML_FOOTER = + +# The HTML_STYLESHEET tag can be used to specify a user-defined cascading +# style sheet that is used by each HTML page. It can be used to +# fine-tune the look of the HTML output. If the tag is left blank doxygen +# will generate a default style sheet. Note that doxygen will try to copy +# the style sheet file to the HTML output directory, so don't put your own +# style sheet in the HTML output directory as well, or it will be erased! + +HTML_STYLESHEET = + +# The HTML_EXTRA_FILES tag can be used to specify one or more extra images or +# other source files which should be copied to the HTML output directory. Note +# that these files will be copied to the base HTML output directory. Use the +# $relpath$ marker in the HTML_HEADER and/or HTML_FOOTER files to load these +# files. In the HTML_STYLESHEET file, use the file name only. Also note that +# the files will be copied as-is; there are no commands or markers available. + +HTML_EXTRA_FILES = + +# The HTML_COLORSTYLE_HUE tag controls the color of the HTML output. +# Doxygen will adjust the colors in the style sheet and background images +# according to this color. Hue is specified as an angle on a colorwheel, +# see http://en.wikipedia.org/wiki/Hue for more information. +# For instance the value 0 represents red, 60 is yellow, 120 is green, +# 180 is cyan, 240 is blue, 300 purple, and 360 is red again. +# The allowed range is 0 to 359. + +HTML_COLORSTYLE_HUE = 220 + +# The HTML_COLORSTYLE_SAT tag controls the purity (or saturation) of +# the colors in the HTML output. For a value of 0 the output will use +# grayscales only. A value of 255 will produce the most vivid colors. + +HTML_COLORSTYLE_SAT = 100 + +# The HTML_COLORSTYLE_GAMMA tag controls the gamma correction applied to +# the luminance component of the colors in the HTML output. Values below +# 100 gradually make the output lighter, whereas values above 100 make +# the output darker. The value divided by 100 is the actual gamma applied, +# so 80 represents a gamma of 0.8, The value 220 represents a gamma of 2.2, +# and 100 does not change the gamma. + +HTML_COLORSTYLE_GAMMA = 80 + +# If the HTML_TIMESTAMP tag is set to YES then the footer of each generated HTML +# page will contain the date and time when the page was generated. Setting +# this to NO can help when comparing the output of multiple runs. + +HTML_TIMESTAMP = YES + +# If the HTML_DYNAMIC_SECTIONS tag is set to YES then the generated HTML +# documentation will contain sections that can be hidden and shown after the +# page has loaded. + +HTML_DYNAMIC_SECTIONS = NO + +# With HTML_INDEX_NUM_ENTRIES one can control the preferred number of +# entries shown in the various tree structured indices initially; the user +# can expand and collapse entries dynamically later on. Doxygen will expand +# the tree to such a level that at most the specified number of entries are +# visible (unless a fully collapsed tree already exceeds this amount). +# So setting the number of entries 1 will produce a full collapsed tree by +# default. 0 is a special value representing an infinite number of entries +# and will result in a full expanded tree by default. + +HTML_INDEX_NUM_ENTRIES = 100 + +# If the GENERATE_DOCSET tag is set to YES, additional index files +# will be generated that can be used as input for Apple's Xcode 3 +# integrated development environment, introduced with OSX 10.5 (Leopard). +# To create a documentation set, doxygen will generate a Makefile in the +# HTML output directory. Running make will produce the docset in that +# directory and running "make install" will install the docset in +# ~/Library/Developer/Shared/Documentation/DocSets so that Xcode will find +# it at startup. +# See http://developer.apple.com/tools/creatingdocsetswithdoxygen.html +# for more information. + +GENERATE_DOCSET = NO + +# When GENERATE_DOCSET tag is set to YES, this tag determines the name of the +# feed. A documentation feed provides an umbrella under which multiple +# documentation sets from a single provider (such as a company or product suite) +# can be grouped. + +DOCSET_FEEDNAME = "Doxygen generated docs" + +# When GENERATE_DOCSET tag is set to YES, this tag specifies a string that +# should uniquely identify the documentation set bundle. This should be a +# reverse domain-name style string, e.g. com.mycompany.MyDocSet. Doxygen +# will append .docset to the name. + +DOCSET_BUNDLE_ID = org.doxygen.Project + +# When GENERATE_PUBLISHER_ID tag specifies a string that should uniquely identify +# the documentation publisher. This should be a reverse domain-name style +# string, e.g. com.mycompany.MyDocSet.documentation. + +DOCSET_PUBLISHER_ID = org.doxygen.Publisher + +# The GENERATE_PUBLISHER_NAME tag identifies the documentation publisher. + +DOCSET_PUBLISHER_NAME = Publisher + +# If the GENERATE_HTMLHELP tag is set to YES, additional index files +# will be generated that can be used as input for tools like the +# Microsoft HTML help workshop to generate a compiled HTML help file (.chm) +# of the generated HTML documentation. + +GENERATE_HTMLHELP = NO + +# If the GENERATE_HTMLHELP tag is set to YES, the CHM_FILE tag can +# be used to specify the file name of the resulting .chm file. You +# can add a path in front of the file if the result should not be +# written to the html output directory. + +CHM_FILE = + +# If the GENERATE_HTMLHELP tag is set to YES, the HHC_LOCATION tag can +# be used to specify the location (absolute path including file name) of +# the HTML help compiler (hhc.exe). If non-empty doxygen will try to run +# the HTML help compiler on the generated index.hhp. + +HHC_LOCATION = + +# If the GENERATE_HTMLHELP tag is set to YES, the GENERATE_CHI flag +# controls if a separate .chi index file is generated (YES) or that +# it should be included in the master .chm file (NO). + +GENERATE_CHI = NO + +# If the GENERATE_HTMLHELP tag is set to YES, the CHM_INDEX_ENCODING +# is used to encode HtmlHelp index (hhk), content (hhc) and project file +# content. + +CHM_INDEX_ENCODING = + +# If the GENERATE_HTMLHELP tag is set to YES, the BINARY_TOC flag +# controls whether a binary table of contents is generated (YES) or a +# normal table of contents (NO) in the .chm file. + +BINARY_TOC = NO + +# The TOC_EXPAND flag can be set to YES to add extra items for group members +# to the contents of the HTML help documentation and to the tree view. + +TOC_EXPAND = NO + +# If the GENERATE_QHP tag is set to YES and both QHP_NAMESPACE and +# QHP_VIRTUAL_FOLDER are set, an additional index file will be generated +# that can be used as input for Qt's qhelpgenerator to generate a +# Qt Compressed Help (.qch) of the generated HTML documentation. + +GENERATE_QHP = NO + +# If the QHG_LOCATION tag is specified, the QCH_FILE tag can +# be used to specify the file name of the resulting .qch file. +# The path specified is relative to the HTML output folder. + +QCH_FILE = + +# The QHP_NAMESPACE tag specifies the namespace to use when generating +# Qt Help Project output. For more information please see +# http://doc.trolltech.com/qthelpproject.html#namespace + +QHP_NAMESPACE = org.doxygen.Project + +# The QHP_VIRTUAL_FOLDER tag specifies the namespace to use when generating +# Qt Help Project output. For more information please see +# http://doc.trolltech.com/qthelpproject.html#virtual-folders + +QHP_VIRTUAL_FOLDER = doc + +# If QHP_CUST_FILTER_NAME is set, it specifies the name of a custom filter to +# add. For more information please see +# http://doc.trolltech.com/qthelpproject.html#custom-filters + +QHP_CUST_FILTER_NAME = + +# The QHP_CUST_FILT_ATTRS tag specifies the list of the attributes of the +# custom filter to add. For more information please see +# <a href="http://doc.trolltech.com/qthelpproject.html#custom-filters"> +# Qt Help Project / Custom Filters</a>. + +QHP_CUST_FILTER_ATTRS = + +# The QHP_SECT_FILTER_ATTRS tag specifies the list of the attributes this +# project's +# filter section matches. +# <a href="http://doc.trolltech.com/qthelpproject.html#filter-attributes"> +# Qt Help Project / Filter Attributes</a>. + +QHP_SECT_FILTER_ATTRS = + +# If the GENERATE_QHP tag is set to YES, the QHG_LOCATION tag can +# be used to specify the location of Qt's qhelpgenerator. +# If non-empty doxygen will try to run qhelpgenerator on the generated +# .qhp file. + +QHG_LOCATION = + +# If the GENERATE_ECLIPSEHELP tag is set to YES, additional index files +# will be generated, which together with the HTML files, form an Eclipse help +# plugin. To install this plugin and make it available under the help contents +# menu in Eclipse, the contents of the directory containing the HTML and XML +# files needs to be copied into the plugins directory of eclipse. The name of +# the directory within the plugins directory should be the same as +# the ECLIPSE_DOC_ID value. After copying Eclipse needs to be restarted before +# the help appears. + +GENERATE_ECLIPSEHELP = NO + +# A unique identifier for the eclipse help plugin. When installing the plugin +# the directory name containing the HTML and XML files should also have +# this name. + +ECLIPSE_DOC_ID = org.doxygen.Project + +# The DISABLE_INDEX tag can be used to turn on/off the condensed index (tabs) +# at top of each HTML page. The value NO (the default) enables the index and +# the value YES disables it. Since the tabs have the same information as the +# navigation tree you can set this option to NO if you already set +# GENERATE_TREEVIEW to YES. + +DISABLE_INDEX = YES + +# The GENERATE_TREEVIEW tag is used to specify whether a tree-like index +# structure should be generated to display hierarchical information. +# If the tag value is set to YES, a side panel will be generated +# containing a tree-like index structure (just like the one that +# is generated for HTML Help). For this to work a browser that supports +# JavaScript, DHTML, CSS and frames is required (i.e. any modern browser). +# Windows users are probably better off using the HTML help feature. +# Since the tree basically has the same information as the tab index you +# could consider to set DISABLE_INDEX to NO when enabling this option. + +GENERATE_TREEVIEW = YES + +# The ENUM_VALUES_PER_LINE tag can be used to set the number of enum values +# (range [0,1..20]) that doxygen will group on one line in the generated HTML +# documentation. Note that a value of 0 will completely suppress the enum +# values from appearing in the overview section. + +ENUM_VALUES_PER_LINE = 4 + +# If the treeview is enabled (see GENERATE_TREEVIEW) then this tag can be +# used to set the initial width (in pixels) of the frame in which the tree +# is shown. + +TREEVIEW_WIDTH = 250 + +# When the EXT_LINKS_IN_WINDOW option is set to YES doxygen will open +# links to external symbols imported via tag files in a separate window. + +EXT_LINKS_IN_WINDOW = NO + +# Use this tag to change the font size of Latex formulas included +# as images in the HTML documentation. The default is 10. Note that +# when you change the font size after a successful doxygen run you need +# to manually remove any form_*.png images from the HTML output directory +# to force them to be regenerated. + +FORMULA_FONTSIZE = 10 + +# Use the FORMULA_TRANPARENT tag to determine whether or not the images +# generated for formulas are transparent PNGs. Transparent PNGs are +# not supported properly for IE 6.0, but are supported on all modern browsers. +# Note that when changing this option you need to delete any form_*.png files +# in the HTML output before the changes have effect. + +FORMULA_TRANSPARENT = YES + +# Enable the USE_MATHJAX option to render LaTeX formulas using MathJax +# (see http://www.mathjax.org) which uses client side Javascript for the +# rendering instead of using prerendered bitmaps. Use this if you do not +# have LaTeX installed or if you want to formulas look prettier in the HTML +# output. When enabled you may also need to install MathJax separately and +# configure the path to it using the MATHJAX_RELPATH option. + +USE_MATHJAX = NO + +# When MathJax is enabled you need to specify the location relative to the +# HTML output directory using the MATHJAX_RELPATH option. The destination +# directory should contain the MathJax.js script. For instance, if the mathjax +# directory is located at the same level as the HTML output directory, then +# MATHJAX_RELPATH should be ../mathjax. The default value points to +# the MathJax Content Delivery Network so you can quickly see the result without +# installing MathJax. +# However, it is strongly recommended to install a local +# copy of MathJax from http://www.mathjax.org before deployment. + +MATHJAX_RELPATH = http://cdn.mathjax.org/mathjax/latest + +# The MATHJAX_EXTENSIONS tag can be used to specify one or MathJax extension +# names that should be enabled during MathJax rendering. + +MATHJAX_EXTENSIONS = + +# When the SEARCHENGINE tag is enabled doxygen will generate a search box +# for the HTML output. The underlying search engine uses javascript +# and DHTML and should work on any modern browser. Note that when using +# HTML help (GENERATE_HTMLHELP), Qt help (GENERATE_QHP), or docsets +# (GENERATE_DOCSET) there is already a search function so this one should +# typically be disabled. For large projects the javascript based search engine +# can be slow, then enabling SERVER_BASED_SEARCH may provide a better solution. + +SEARCHENGINE = YES + +# When the SERVER_BASED_SEARCH tag is enabled the search engine will be +# implemented using a PHP enabled web server instead of at the web client +# using Javascript. Doxygen will generate the search PHP script and index +# file to put on the web server. The advantage of the server +# based approach is that it scales better to large projects and allows +# full text search. The disadvantages are that it is more difficult to setup +# and does not have live searching capabilities. + +SERVER_BASED_SEARCH = NO + +#--------------------------------------------------------------------------- +# configuration options related to the LaTeX output +#--------------------------------------------------------------------------- + +# If the GENERATE_LATEX tag is set to YES (the default) Doxygen will +# generate Latex output. + +GENERATE_LATEX = NO + +# The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `latex' will be used as the default path. + +LATEX_OUTPUT = latex + +# The LATEX_CMD_NAME tag can be used to specify the LaTeX command name to be +# invoked. If left blank `latex' will be used as the default command name. +# Note that when enabling USE_PDFLATEX this option is only used for +# generating bitmaps for formulas in the HTML output, but not in the +# Makefile that is written to the output directory. + +LATEX_CMD_NAME = latex + +# The MAKEINDEX_CMD_NAME tag can be used to specify the command name to +# generate index for LaTeX. If left blank `makeindex' will be used as the +# default command name. + +MAKEINDEX_CMD_NAME = makeindex + +# If the COMPACT_LATEX tag is set to YES Doxygen generates more compact +# LaTeX documents. This may be useful for small projects and may help to +# save some trees in general. + +COMPACT_LATEX = NO + +# The PAPER_TYPE tag can be used to set the paper type that is used +# by the printer. Possible values are: a4, letter, legal and +# executive. If left blank a4wide will be used. + +PAPER_TYPE = a4 + +# The EXTRA_PACKAGES tag can be to specify one or more names of LaTeX +# packages that should be included in the LaTeX output. + +EXTRA_PACKAGES = + +# The LATEX_HEADER tag can be used to specify a personal LaTeX header for +# the generated latex document. The header should contain everything until +# the first chapter. If it is left blank doxygen will generate a +# standard header. Notice: only use this tag if you know what you are doing! + +LATEX_HEADER = + +# The LATEX_FOOTER tag can be used to specify a personal LaTeX footer for +# the generated latex document. The footer should contain everything after +# the last chapter. If it is left blank doxygen will generate a +# standard footer. Notice: only use this tag if you know what you are doing! + +LATEX_FOOTER = + +# If the PDF_HYPERLINKS tag is set to YES, the LaTeX that is generated +# is prepared for conversion to pdf (using ps2pdf). The pdf file will +# contain links (just like the HTML output) instead of page references +# This makes the output suitable for online browsing using a pdf viewer. + +PDF_HYPERLINKS = YES + +# If the USE_PDFLATEX tag is set to YES, pdflatex will be used instead of +# plain latex in the generated Makefile. Set this option to YES to get a +# higher quality PDF documentation. + +USE_PDFLATEX = YES + +# If the LATEX_BATCHMODE tag is set to YES, doxygen will add the \\batchmode. +# command to the generated LaTeX files. This will instruct LaTeX to keep +# running if errors occur, instead of asking the user for help. +# This option is also used when generating formulas in HTML. + +LATEX_BATCHMODE = NO + +# If LATEX_HIDE_INDICES is set to YES then doxygen will not +# include the index chapters (such as File Index, Compound Index, etc.) +# in the output. + +LATEX_HIDE_INDICES = NO + +# If LATEX_SOURCE_CODE is set to YES then doxygen will include +# source code with syntax highlighting in the LaTeX output. +# Note that which sources are shown also depends on other settings +# such as SOURCE_BROWSER. + +LATEX_SOURCE_CODE = NO + +# The LATEX_BIB_STYLE tag can be used to specify the style to use for the +# bibliography, e.g. plainnat, or ieeetr. The default style is "plain". See +# http://en.wikipedia.org/wiki/BibTeX for more info. + +LATEX_BIB_STYLE = plain + +#--------------------------------------------------------------------------- +# configuration options related to the RTF output +#--------------------------------------------------------------------------- + +# If the GENERATE_RTF tag is set to YES Doxygen will generate RTF output +# The RTF output is optimized for Word 97 and may not look very pretty with +# other RTF readers or editors. + +GENERATE_RTF = NO + +# The RTF_OUTPUT tag is used to specify where the RTF docs will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `rtf' will be used as the default path. + +RTF_OUTPUT = rtf + +# If the COMPACT_RTF tag is set to YES Doxygen generates more compact +# RTF documents. This may be useful for small projects and may help to +# save some trees in general. + +COMPACT_RTF = NO + +# If the RTF_HYPERLINKS tag is set to YES, the RTF that is generated +# will contain hyperlink fields. The RTF file will +# contain links (just like the HTML output) instead of page references. +# This makes the output suitable for online browsing using WORD or other +# programs which support those fields. +# Note: wordpad (write) and others do not support links. + +RTF_HYPERLINKS = NO + +# Load style sheet definitions from file. Syntax is similar to doxygen's +# config file, i.e. a series of assignments. You only have to provide +# replacements, missing definitions are set to their default value. + +RTF_STYLESHEET_FILE = + +# Set optional variables used in the generation of an rtf document. +# Syntax is similar to doxygen's config file. + +RTF_EXTENSIONS_FILE = + +#--------------------------------------------------------------------------- +# configuration options related to the man page output +#--------------------------------------------------------------------------- + +# If the GENERATE_MAN tag is set to YES (the default) Doxygen will +# generate man pages + +GENERATE_MAN = NO + +# The MAN_OUTPUT tag is used to specify where the man pages will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `man' will be used as the default path. + +MAN_OUTPUT = man + +# The MAN_EXTENSION tag determines the extension that is added to +# the generated man pages (default is the subroutine's section .3) + +MAN_EXTENSION = .3 + +# If the MAN_LINKS tag is set to YES and Doxygen generates man output, +# then it will generate one additional man file for each entity +# documented in the real man page(s). These additional files +# only source the real man page, but without them the man command +# would be unable to find the correct page. The default is NO. + +MAN_LINKS = NO + +#--------------------------------------------------------------------------- +# configuration options related to the XML output +#--------------------------------------------------------------------------- + +# If the GENERATE_XML tag is set to YES Doxygen will +# generate an XML file that captures the structure of +# the code including all documentation. + +GENERATE_XML = NO + +# The XML_OUTPUT tag is used to specify where the XML pages will be put. +# If a relative path is entered the value of OUTPUT_DIRECTORY will be +# put in front of it. If left blank `xml' will be used as the default path. + +XML_OUTPUT = xml + +# The XML_SCHEMA tag can be used to specify an XML schema, +# which can be used by a validating XML parser to check the +# syntax of the XML files. + +XML_SCHEMA = + +# The XML_DTD tag can be used to specify an XML DTD, +# which can be used by a validating XML parser to check the +# syntax of the XML files. + +XML_DTD = + +# If the XML_PROGRAMLISTING tag is set to YES Doxygen will +# dump the program listings (including syntax highlighting +# and cross-referencing information) to the XML output. Note that +# enabling this will significantly increase the size of the XML output. + +XML_PROGRAMLISTING = YES + +#--------------------------------------------------------------------------- +# configuration options for the AutoGen Definitions output +#--------------------------------------------------------------------------- + +# If the GENERATE_AUTOGEN_DEF tag is set to YES Doxygen will +# generate an AutoGen Definitions (see autogen.sf.net) file +# that captures the structure of the code including all +# documentation. Note that this feature is still experimental +# and incomplete at the moment. + +GENERATE_AUTOGEN_DEF = NO + +#--------------------------------------------------------------------------- +# configuration options related to the Perl module output +#--------------------------------------------------------------------------- + +# If the GENERATE_PERLMOD tag is set to YES Doxygen will +# generate a Perl module file that captures the structure of +# the code including all documentation. Note that this +# feature is still experimental and incomplete at the +# moment. + +GENERATE_PERLMOD = NO + +# If the PERLMOD_LATEX tag is set to YES Doxygen will generate +# the necessary Makefile rules, Perl scripts and LaTeX code to be able +# to generate PDF and DVI output from the Perl module output. + +PERLMOD_LATEX = NO + +# If the PERLMOD_PRETTY tag is set to YES the Perl module output will be +# nicely formatted so it can be parsed by a human reader. +# This is useful +# if you want to understand what is going on. +# On the other hand, if this +# tag is set to NO the size of the Perl module output will be much smaller +# and Perl will parse it just the same. + +PERLMOD_PRETTY = YES + +# The names of the make variables in the generated doxyrules.make file +# are prefixed with the string contained in PERLMOD_MAKEVAR_PREFIX. +# This is useful so different doxyrules.make files included by the same +# Makefile don't overwrite each other's variables. + +PERLMOD_MAKEVAR_PREFIX = + +#--------------------------------------------------------------------------- +# Configuration options related to the preprocessor +#--------------------------------------------------------------------------- + +# If the ENABLE_PREPROCESSING tag is set to YES (the default) Doxygen will +# evaluate all C-preprocessor directives found in the sources and include +# files. + +ENABLE_PREPROCESSING = YES + +# If the MACRO_EXPANSION tag is set to YES Doxygen will expand all macro +# names in the source code. If set to NO (the default) only conditional +# compilation will be performed. Macro expansion can be done in a controlled +# way by setting EXPAND_ONLY_PREDEF to YES. + +MACRO_EXPANSION = NO + +# If the EXPAND_ONLY_PREDEF and MACRO_EXPANSION tags are both set to YES +# then the macro expansion is limited to the macros specified with the +# PREDEFINED and EXPAND_AS_DEFINED tags. + +EXPAND_ONLY_PREDEF = NO + +# If the SEARCH_INCLUDES tag is set to YES (the default) the includes files +# pointed to by INCLUDE_PATH will be searched when a #include is found. + +SEARCH_INCLUDES = YES + +# The INCLUDE_PATH tag can be used to specify one or more directories that +# contain include files that are not input files but should be processed by +# the preprocessor. + +INCLUDE_PATH = + +# You can use the INCLUDE_FILE_PATTERNS tag to specify one or more wildcard +# patterns (like *.h and *.hpp) to filter out the header-files in the +# directories. If left blank, the patterns specified with FILE_PATTERNS will +# be used. + +INCLUDE_FILE_PATTERNS = + +# The PREDEFINED tag can be used to specify one or more macro names that +# are defined before the preprocessor is started (similar to the -D option of +# gcc). The argument of the tag is a list of macros of the form: name +# or name=definition (no spaces). If the definition and the = are +# omitted =1 is assumed. To prevent a macro definition from being +# undefined via #undef or recursively expanded use the := operator +# instead of the = operator. + +PREDEFINED = + +# If the MACRO_EXPANSION and EXPAND_ONLY_PREDEF tags are set to YES then +# this tag can be used to specify a list of macro names that should be expanded. +# The macro definition that is found in the sources will be used. +# Use the PREDEFINED tag if you want to use a different macro definition that +# overrules the definition found in the source code. + +EXPAND_AS_DEFINED = + +# If the SKIP_FUNCTION_MACROS tag is set to YES (the default) then +# doxygen's preprocessor will remove all references to function-like macros +# that are alone on a line, have an all uppercase name, and do not end with a +# semicolon, because these will confuse the parser if not removed. + +SKIP_FUNCTION_MACROS = YES + +#--------------------------------------------------------------------------- +# Configuration::additions related to external references +#--------------------------------------------------------------------------- + +# The TAGFILES option can be used to specify one or more tagfiles. For each +# tag file the location of the external documentation should be added. The +# format of a tag file without this location is as follows: +# +# TAGFILES = file1 file2 ... +# Adding location for the tag files is done as follows: +# +# TAGFILES = file1=loc1 "file2 = loc2" ... +# where "loc1" and "loc2" can be relative or absolute paths +# or URLs. Note that each tag file must have a unique name (where the name does +# NOT include the path). If a tag file is not located in the directory in which +# doxygen is run, you must also specify the path to the tagfile here. + +TAGFILES = + +# When a file name is specified after GENERATE_TAGFILE, doxygen will create +# a tag file that is based on the input files it reads. + +GENERATE_TAGFILE = + +# If the ALLEXTERNALS tag is set to YES all external classes will be listed +# in the class index. If set to NO only the inherited external classes +# will be listed. + +ALLEXTERNALS = NO + +# If the EXTERNAL_GROUPS tag is set to YES all external groups will be listed +# in the modules index. If set to NO, only the current project's groups will +# be listed. + +EXTERNAL_GROUPS = YES + +# The PERL_PATH should be the absolute path and name of the perl script +# interpreter (i.e. the result of `which perl'). + +PERL_PATH = /usr/bin/perl + +#--------------------------------------------------------------------------- +# Configuration options related to the dot tool +#--------------------------------------------------------------------------- + +# If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will +# generate a inheritance diagram (in HTML, RTF and LaTeX) for classes with base +# or super classes. Setting the tag to NO turns the diagrams off. Note that +# this option also works with HAVE_DOT disabled, but it is recommended to +# install and use dot, since it yields more powerful graphs. + +CLASS_DIAGRAMS = NO + +# You can define message sequence charts within doxygen comments using the \msc +# command. Doxygen will then run the mscgen tool (see +# http://www.mcternan.me.uk/mscgen/) to produce the chart and insert it in the +# documentation. The MSCGEN_PATH tag allows you to specify the directory where +# the mscgen tool resides. If left empty the tool is assumed to be found in the +# default search path. + +MSCGEN_PATH = + +# If set to YES, the inheritance and collaboration graphs will hide +# inheritance and usage relations if the target is undocumented +# or is not a class. + +HIDE_UNDOC_RELATIONS = YES + +# If you set the HAVE_DOT tag to YES then doxygen will assume the dot tool is +# available from the path. This tool is part of Graphviz, a graph visualization +# toolkit from AT&T and Lucent Bell Labs. The other options in this section +# have no effect if this option is set to NO (the default) + +HAVE_DOT = NO + +# The DOT_NUM_THREADS specifies the number of dot invocations doxygen is +# allowed to run in parallel. When set to 0 (the default) doxygen will +# base this on the number of processors available in the system. You can set it +# explicitly to a value larger than 0 to get control over the balance +# between CPU load and processing speed. + +DOT_NUM_THREADS = 0 + +# By default doxygen will use the Helvetica font for all dot files that +# doxygen generates. When you want a differently looking font you can specify +# the font name using DOT_FONTNAME. You need to make sure dot is able to find +# the font, which can be done by putting it in a standard location or by setting +# the DOTFONTPATH environment variable or by setting DOT_FONTPATH to the +# directory containing the font. + +DOT_FONTNAME = Helvetica + +# The DOT_FONTSIZE tag can be used to set the size of the font of dot graphs. +# The default size is 10pt. + +DOT_FONTSIZE = 10 + +# By default doxygen will tell dot to use the Helvetica font. +# If you specify a different font using DOT_FONTNAME you can use DOT_FONTPATH to +# set the path where dot can find it. + +DOT_FONTPATH = + +# If the CLASS_GRAPH and HAVE_DOT tags are set to YES then doxygen +# will generate a graph for each documented class showing the direct and +# indirect inheritance relations. Setting this tag to YES will force the +# CLASS_DIAGRAMS tag to NO. + +CLASS_GRAPH = YES + +# If the COLLABORATION_GRAPH and HAVE_DOT tags are set to YES then doxygen +# will generate a graph for each documented class showing the direct and +# indirect implementation dependencies (inheritance, containment, and +# class references variables) of the class with other documented classes. + +COLLABORATION_GRAPH = YES + +# If the GROUP_GRAPHS and HAVE_DOT tags are set to YES then doxygen +# will generate a graph for groups, showing the direct groups dependencies + +GROUP_GRAPHS = YES + +# If the UML_LOOK tag is set to YES doxygen will generate inheritance and +# collaboration diagrams in a style similar to the OMG's Unified Modeling +# Language. + +UML_LOOK = NO + +# If the UML_LOOK tag is enabled, the fields and methods are shown inside +# the class node. If there are many fields or methods and many nodes the +# graph may become too big to be useful. The UML_LIMIT_NUM_FIELDS +# threshold limits the number of items for each type to make the size more +# managable. Set this to 0 for no limit. Note that the threshold may be +# exceeded by 50% before the limit is enforced. + +UML_LIMIT_NUM_FIELDS = 10 + +# If set to YES, the inheritance and collaboration graphs will show the +# relations between templates and their instances. + +TEMPLATE_RELATIONS = NO + +# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDE_GRAPH, and HAVE_DOT +# tags are set to YES then doxygen will generate a graph for each documented +# file showing the direct and indirect include dependencies of the file with +# other documented files. + +INCLUDE_GRAPH = YES + +# If the ENABLE_PREPROCESSING, SEARCH_INCLUDES, INCLUDED_BY_GRAPH, and +# HAVE_DOT tags are set to YES then doxygen will generate a graph for each +# documented header file showing the documented files that directly or +# indirectly include this file. + +INCLUDED_BY_GRAPH = YES + +# If the CALL_GRAPH and HAVE_DOT options are set to YES then +# doxygen will generate a call dependency graph for every global function +# or class method. Note that enabling this option will significantly increase +# the time of a run. So in most cases it will be better to enable call graphs +# for selected functions only using the \callgraph command. + +CALL_GRAPH = NO + +# If the CALLER_GRAPH and HAVE_DOT tags are set to YES then +# doxygen will generate a caller dependency graph for every global function +# or class method. Note that enabling this option will significantly increase +# the time of a run. So in most cases it will be better to enable caller +# graphs for selected functions only using the \callergraph command. + +CALLER_GRAPH = NO + +# If the GRAPHICAL_HIERARCHY and HAVE_DOT tags are set to YES then doxygen +# will generate a graphical hierarchy of all classes instead of a textual one. + +GRAPHICAL_HIERARCHY = YES + +# If the DIRECTORY_GRAPH and HAVE_DOT tags are set to YES +# then doxygen will show the dependencies a directory has on other directories +# in a graphical way. The dependency relations are determined by the #include +# relations between the files in the directories. + +DIRECTORY_GRAPH = YES + +# The DOT_IMAGE_FORMAT tag can be used to set the image format of the images +# generated by dot. Possible values are svg, png, jpg, or gif. +# If left blank png will be used. If you choose svg you need to set +# HTML_FILE_EXTENSION to xhtml in order to make the SVG files +# visible in IE 9+ (other browsers do not have this requirement). + +DOT_IMAGE_FORMAT = png + +# If DOT_IMAGE_FORMAT is set to svg, then this option can be set to YES to +# enable generation of interactive SVG images that allow zooming and panning. +# Note that this requires a modern browser other than Internet Explorer. +# Tested and working are Firefox, Chrome, Safari, and Opera. For IE 9+ you +# need to set HTML_FILE_EXTENSION to xhtml in order to make the SVG files +# visible. Older versions of IE do not have SVG support. + +INTERACTIVE_SVG = NO + +# The tag DOT_PATH can be used to specify the path where the dot tool can be +# found. If left blank, it is assumed the dot tool can be found in the path. + +DOT_PATH = + +# The DOTFILE_DIRS tag can be used to specify one or more directories that +# contain dot files that are included in the documentation (see the +# \dotfile command). + +DOTFILE_DIRS = + +# The MSCFILE_DIRS tag can be used to specify one or more directories that +# contain msc files that are included in the documentation (see the +# \mscfile command). + +MSCFILE_DIRS = + +# The DOT_GRAPH_MAX_NODES tag can be used to set the maximum number of +# nodes that will be shown in the graph. If the number of nodes in a graph +# becomes larger than this value, doxygen will truncate the graph, which is +# visualized by representing a node as a red box. Note that doxygen if the +# number of direct children of the root node in a graph is already larger than +# DOT_GRAPH_MAX_NODES then the graph will not be shown at all. Also note +# that the size of a graph can be further restricted by MAX_DOT_GRAPH_DEPTH. + +DOT_GRAPH_MAX_NODES = 50 + +# The MAX_DOT_GRAPH_DEPTH tag can be used to set the maximum depth of the +# graphs generated by dot. A depth value of 3 means that only nodes reachable +# from the root by following a path via at most 3 edges will be shown. Nodes +# that lay further from the root node will be omitted. Note that setting this +# option to 1 or 2 may greatly reduce the computation time needed for large +# code bases. Also note that the size of a graph can be further restricted by +# DOT_GRAPH_MAX_NODES. Using a depth of 0 means no depth restriction. + +MAX_DOT_GRAPH_DEPTH = 0 + +# Set the DOT_TRANSPARENT tag to YES to generate images with a transparent +# background. This is disabled by default, because dot on Windows does not +# seem to support this out of the box. Warning: Depending on the platform used, +# enabling this option may lead to badly anti-aliased labels on the edges of +# a graph (i.e. they become hard to read). + +DOT_TRANSPARENT = NO + +# Set the DOT_MULTI_TARGETS tag to YES allow dot to generate multiple output +# files in one run (i.e. multiple -o and -T options on the command line). This +# makes dot run faster, but since only newer versions of dot (>1.8.10) +# support this, this feature is disabled by default. + +DOT_MULTI_TARGETS = NO + +# If the GENERATE_LEGEND tag is set to YES (the default) Doxygen will +# generate a legend page explaining the meaning of the various boxes and +# arrows in the dot generated graphs. + +GENERATE_LEGEND = YES + +# If the DOT_CLEANUP tag is set to YES (the default) Doxygen will +# remove the intermediate dot files that are used to generate +# the various graphs. + +DOT_CLEANUP = YES diff --git a/doc/devel/isc-logo.jpg b/doc/devel/isc-logo.jpg Binary files differnew file mode 100644 index 0000000..1ce1cfd --- /dev/null +++ b/doc/devel/isc-logo.jpg diff --git a/doc/devel/mainpage.dox b/doc/devel/mainpage.dox new file mode 100644 index 0000000..b6d5c43 --- /dev/null +++ b/doc/devel/mainpage.dox @@ -0,0 +1,41 @@ +/** + @mainpage + This is an ISC DHCP Developer's Guide. This documentation is intended for + developers, contributors and other programmers that are interested in + internal operation of the code. + + To download the latest version of the software, please go to the + http://www.isc.org/software/dhcp website. + + @section toc Table Of Contents + - Server + - @subpage ipv6structures + - @subpage tests + - @subpage testsOverview + - @subpage testsAtf + - @subpage testsAtfAdding + - @subpage testsAtfCoding + - @subpage qa + - @subpage qaTests + - @subpage cppcheck + - @subpage doxygen + - @subpage valgrind + - @subpage debug + + Pages planned to be written: + - @subpage archSrv + - @subpage archCli + - @subpage omapi + - @subpage omapiIntro + - @subpage omapiC + - @subpage dhcpctl + - @subpage contrib + - @subpage contribDir + - @subpage codingGuidelines + + Note: some of the links below may not work if corresponding logs are not available.<br/> + + Doxygen: <a href="doxygen.log">[generation log]</a> <a href="doxygen-warnings.log">[errors and warnings]</a> <br/> + cppcheck: <a href="cppcheck.log">[generation log]</a> <a href="cppcheck-error.log">[errors and warnings]</a> <br/> + + */
\ No newline at end of file diff --git a/doc/devel/omapi.dox b/doc/devel/omapi.dox new file mode 100644 index 0000000..c6423ce --- /dev/null +++ b/doc/devel/omapi.dox @@ -0,0 +1,15 @@ +/** +@page omapi OMAPI Interface + +@section omapiIntro Introduction + + @todo: Description of OMAPI and dhcpctl + +@section omapiC Object Management API + + @todo: Essentially omapi.3 + +@section dhcpctl dhcpctl Reference Guide + @todo: Essentially dhcpctl.3 + +*/ diff --git a/doc/devel/qa.dox b/doc/devel/qa.dox new file mode 100644 index 0000000..81a9e83 --- /dev/null +++ b/doc/devel/qa.dox @@ -0,0 +1,93 @@ +/** + @page qa Quality Assurance + +There is a wide scale effort in progress to improve the quality of the ISC +DHCP implementation. The following section describes the major aspects of +quality assurance that are being implemented. As this is a work in progress, +expect radical changes in this area. + + @section qaTests ATF Unit-tests + + See @ref tests Section for details description of ATF-based unit-tests. + + @section cppcheck cppcheck tool + +<a href="http://cppcheck.sourceforge.net/">cppcheck</a> is a static analysis tool +for C/C++ code. Unlike C/C++ compilers and many other analysis tools it does not +detect syntax errors in the code. Cppcheck primarily detects the types of bugs +that the compilers normally do not detect. To generate cppcheck report, you +must have cppcheck installed in your system. Generation is simple: + +@verbatim +cd doc/ +make cppcheck +@endverbatim + +The log files will be stored in doc/html/cppcheck.log and +doc/html/cppcheck-error.log. While the former is useful for verifying that all +sources were checked, the latter is much more useful. It contains a list of +problems that were detected by cppcheck. The goal is to correct all problems +and make this an empty file. + +In the unlikely event of cppcheck finding false positives it is possible to add +special comments formatted to instruct cppcheck to not report what it thinks is +an issue. make cppcheck target is configured to make cppcheck print out a +specific issue type reported. For example to disable the following error report: + +@verbatim +bind/bind-9.8.1/bin/dnssec/dnssec-keygen.c:522: check_fail: Memory leak: algname (error,memleak) +@endverbatim + +the following line could be added before line 522 in dnssec-keygen.c: +@verbatim +// cppcheck-suppress memleak +@endverbatim + +Please consult cppcheck manual for details. It is section 6.2 "Inline +suppressions" in cppcheck 1.54 manual. Section number may change in later +versions. + + @section doxygen Doxygen checks + +ISC DHCP Developer's Guide (the documentation you are reading now) is +generated with doxygen. Doxygen is an open source tool for generating +source code documentation. It is available from +<a href="http://www.doxygen.org">www.doxygen.org</a> website. Once Doxygen +is installed, ISC DHCP documentation can be generated with: + +@verbatim +cd doc +make devel +@endverbatim + +Note that cppcheck (see @ref cppcheck Section) reports are linked from +Developer's Guide. It is useful to generate both. + + @section systemTests System level tests + +ISC is developing a comprehensive set of system level tests. +They are described by a separate document called DHCP Test Plan. + + @section perfdhcp Performance tests using perfdhcp + +ISC is also developing a performance measurement tool, called +perfdhcp. Its main purpose is to measure performance of DHCPv4 and +DHCPv6 servers. It is being developed as part of the BIND10 project. +See tests/tools/perfdhcp directory in BIND10 source code. + + @section tahiTests Conformance tests using TAHI + +<a href="http://tahi.org">TAHI project</a> developed an extensive suite of <a +href="http://tahi.org/logo/dhcpv6/">DHCPv6 conformance tests</a>. ISC plans to +deploy and run them periodically in the near future. + + @section valgrind Memory correctness using valgrind + +<a href="http://valgrind.org/">Valgrind</a> is a powerful tool for dynamic code +analysis. It allows running existing code (often even without recompiling) in a +special environment that tracks memory operations. In particular, it is able to +detect: memory leaks, buffer overflows, usage of uninitialized memory, double +frees and similar errors. We currently do not use valgrind in ISC DHCP testing, +but there are plans for starting to use it. + +*/ diff --git a/doc/examples/dhclient-dhcpv6.conf b/doc/examples/dhclient-dhcpv6.conf new file mode 100644 index 0000000..6b63a1f --- /dev/null +++ b/doc/examples/dhclient-dhcpv6.conf @@ -0,0 +1,11 @@ +# Client configuration file example for DHCPv6 + +# The client side command to enable rapid-commit (2 packet exchange) +##send dhcp6.rapid-commit; + +# name-servers and domain-search are requested by default. +# here is the way to request sip-servers-addresses too +also request dhcp6.sip-servers-addresses; + +# Likely to be useful: the script path +script "/usr/local/etc/dhclient-script"; diff --git a/doc/examples/dhcpd-dhcpv6.conf b/doc/examples/dhcpd-dhcpv6.conf new file mode 100644 index 0000000..448a6a6 --- /dev/null +++ b/doc/examples/dhcpd-dhcpv6.conf @@ -0,0 +1,106 @@ +# Server configuration file example for DHCPv6 +# From the file used for TAHI tests - addresses chosen +# to match TAHI rather than example block. + +# IPv6 address valid lifetime +# (at the end the address is no longer usable by the client) +# (set to 30 days, the usual IPv6 default) +default-lease-time 2592000; + +# IPv6 address preferred lifetime +# (at the end the address is deprecated, i.e., the client should use +# other addresses for new connections) +# (set to 7 days, the usual IPv6 default) +preferred-lifetime 604800; + +# T1, the delay before Renew +# (default is 1/2 preferred lifetime) +# (set to 1 hour) +option dhcp-renewal-time 3600; + +# T2, the delay before Rebind (if Renews failed) +# (default is 3/4 preferred lifetime) +# (set to 2 hours) +option dhcp-rebinding-time 7200; + +# Enable RFC 5007 support (same than for DHCPv4) +allow leasequery; + +# Global definitions for name server address(es) and domain search list +option dhcp6.name-servers 3ffe:501:ffff:100:200:ff:fe00:3f3e; +option dhcp6.domain-search "test.example.com","example.com"; + +# Set preference to 255 (maximum) in order to avoid waiting for +# additional servers when there is only one +##option dhcp6.preference 255; + +# Server side command to enable rapid-commit (2 packet exchange) +##option dhcp6.rapid-commit; + +# The delay before information-request refresh +# (minimum is 10 minutes, maximum one day, default is to not refresh) +# (set to 6 hours) +option dhcp6.info-refresh-time 21600; + +# The path of the lease file +dhcpv6-lease-file-name "/usr/local/var/db/dhcpd6.leases"; + +# Static definition (must be global) +host myclient { + # The entry is looked up by this + host-identifier option + dhcp6.client-id 00:01:00:01:00:04:93:e0:00:00:00:00:a2:a2; + + # A fixed address + fixed-address6 3ffe:501:ffff:100::1234; + + # A fixed prefix + fixed-prefix6 3ffe:501:ffff:101::/64; + + # Override of the global definitions, + # works only when a resource (address or prefix) is assigned + option dhcp6.name-servers 3ffe:501:ffff:100:200:ff:fe00:4f4e; + + # For debug (to see when the entry statements are executed) + # (log "sol" when a matching Solicitation is received) + ##if packet(0,1) = 1 { log(debug,"sol"); } +} + +host otherclient { + # This host entry is hopefully matched if the client supplies a DUID-LL + # or DUID-LLT containing this MAC address. + hardware ethernet 01:00:80:a2:55:67; + + fixed-address6 3ffe:501:ffff:100::4321; +} + +# The subnet where the server is attached +# (i.e., the server has an address in this subnet) +subnet6 3ffe:501:ffff:100::/64 { + # Two addresses available to clients + # (the third client should get NoAddrsAvail) + range6 3ffe:501:ffff:100::10 3ffe:501:ffff:100::11; + + # Use the whole /64 prefix for temporary addresses + # (i.e., direct application of RFC 4941) + range6 3ffe:501:ffff:100:: temporary; + + # Some /64 prefixes available for Prefix Delegation (RFC 3633) + prefix6 3ffe:501:ffff:100:: 3ffe:501:ffff:111:: /64; +} + +# A second subnet behind a relay agent +subnet6 3ffe:501:ffff:101::/64 { + range6 3ffe:501:ffff:101::10 3ffe:501:ffff:101::11; + + # Override of the global definitions, + # works only when a resource (address or prefix) is assigned + option dhcp6.name-servers 3ffe:501:ffff:101:200:ff:fe00:3f3e; + +} + +# A third subnet behind a relay agent chain +subnet6 3ffe:501:ffff:102::/64 { + range6 3ffe:501:ffff:102::10 3ffe:501:ffff:102::11; +} + diff --git a/doc/ja_JP.eucJP/dhclient-script.8 b/doc/ja_JP.eucJP/dhclient-script.8 new file mode 100644 index 0000000..aeee19d --- /dev/null +++ b/doc/ja_JP.eucJP/dhclient-script.8 @@ -0,0 +1,242 @@ +.\" $Id: dhclient-script.8,v 1.3.24.1 2009/11/20 01:49:01 sar Exp $ +.\" +.\" Copyright (c) 2004,2009 by Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (c) 1996-2003 by Internet Software Consortium +.\" +.\" 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. +.\" +.\" 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. +.\" +.\" Internet Systems Consortium, Inc. +.\" 950 Charter Street +.\" Redwood City, CA 94063 +.\" <info@isc.org> +.\" https://www.isc.org/ +.\" +.\" This software has been written for Internet Systems Consortium +.\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc. +.\" To learn more about Internet Systems Consortium, see +.\" ``https://www.isc.org/''. To learn more about Vixie Enterprises, +.\" see ``http://www.vix.com''. To learn more about Nominum, Inc., see +.\" ``http://www.nominum.com''. +.\" +.\" %FreeBSD: src/contrib/isc-dhcp/client/dhclient-script.8,v 1.5.2.4 2002/04/11 10:16:45 murray Exp % +.\" +.\" $FreeBSD: doc/ja_JP.eucJP/man/man8/dhclient-script.8,v 1.13 2002/05/08 03:27:27 horikawa Exp $ +.TH dhclient-script 8 +.SH 名称 +dhclient-script - DHCP クライアントのネットワーク設定スクリプト +.SH 解説 +DHCP クライアントのネットワーク設定スクリプトは、 +時あるごとに \fBdhclient(8)\fR が呼び出します。 +DHCP クライアントは、本スクリプトを使用することにより、 +アドレス要求に先立つ各インタフェースの初期設定と、 +付与されたアドレスの検査と、 +リース獲得時のインタフェースの最終設定を行います。 +リースが獲得されなかった場合、 +定義済みのリースが存在するならばこれを検査するために本スクリプトは使用され、 +有効なリースが判明しなかった場合にももう 1 回このスクリプトが呼ばれます。 +.PP +本スクリプトは、エンドユーザにカスタマイズされることを意図していません。 +ローカルなカスタマイズが必要な場合、 +これは入 (enter) と出 (exit) というフックを使用することで可能となります +(詳細はフック参照)。 +これらのフックは、 +.B /etc/resolv.conf +作成時に、 +クライアントのデフォルト動作をユーザがオーバライドできるようにします。 +.PP +特定のオペレーティングシステムでは、 +クライアントの実体は動作するとしても、 +標準のスクリプトが動作しないかもしれません。 +先駆的なユーザが新規スクリプトを作成したり既存のものを修正したりする必要がある +ことはもっともなことです。 +一般的には、それぞれのコンピュータに固有のカスタマイズは +.B ETCDIR/dhclient.conf +スクリプトで行うべきです。 +.B ETCDIR/dhclient.conf +のカスタマイズ無しにできないカスタマイズや、 +入と出のフックの使用ではできないカスタマイズに気づいた場合には、 +バグレポートを送ってください。 +.SH フック +開始時に、クライアントスクリプトはまずシェル関数を定義します。その関数は +.B make_resolv_conf +であり、後に +.B /etc/resolv.conf +ファイルを作成するために使用されます。 +デフォルト動作をオーバライドするには、 +この関数を入のフックスクリプトで再定義してください。 +.PP +make_resolv_conf 関数の定義の後、クライアントスクリプトは +実行可能な +.B ETCDIR/dhclient-enter-hooks +スクリプトの存在を検査し、 +存在する場合には Bourne シェルの '.' コマンドを使用して +本スクリプトをインラインで起動します。 +操作で記述されているすべての環境が本スクリプトで使用可能であり、 +スクリプトの動作の変更が必要な場合には環境の修正が許されています。 +スクリプト実行中にエラーが発生した場合、 +exit_status 変数を非 0 値に設定することが可能であり、 +クライアントスクリプト終了直後に +.B CLIENTBINDIR/dhclient-script +はそのエラーコードで終了します。 +.PP +すべての処理の完了後に、 +.B CLIENTBINDIR/dhclient-script +は実行可能な +.B ETCDIR/dhclient-exit-hooks +スクリプトの存在を検査し、存在する場合には '.' コマンドでこれを起動します。 +dhclient-script の +終了状態は dhclient-exit-hooks の exit_status シェル変数に渡され、 +起動された仕事にスクリプトが成功した場合には値は常に 0 になります。 +dhclient-enter-hooks の項で前述したその他の環境も引き継がれます。 +.B ETCDIR/dhclient-exit-hooks +は exit_status に手を加えて +dhclient-script の戻り値を変更できます。 +.SH 操作 +dhclient がクライアント設定スクリプトを起動する必要があるとき、 +様々な変数を環境に定義してから +.B CLIENTBINDIR/dhclient-script +を起動します。 +すべての場合において、$reason にはスクリプトが起動される理由名が設定されます。 +次の理由が現在定義されています: +MEDIUM, PREINIT, BOUND, RENEW, REBIND, REBOOT, +EXPIRE, FAIL, TIMEOUT。 +.PP +.SH MEDIUM +DHCP クライアントは、インタフェースのメディアタイプの設定を求めています。 +インタフェース名は $interface で渡され、メディアタイプは $medium で渡されます。 +.SH PREINIT +DHCP クライアントは、 +実際のアドレスを受け取る前にパケットを送信する目的で、 +要求通りにインタフェースが設定されることを求めています。 +BSD のソケットライブラリを使用するクライアントでは、 +IP アドレス 0.0.0.0 かつブロードキャストアドレス 255.255.255.255 で、 +インタフェースを設定することを意味します。 +他のクライアントでは、 +実際に IP アドレスを与えることなく単にインタフェースを設定することで +実現されるでしょう。 +インタフェース名は $interface で渡され、メディアタイプは $medium で渡されます。 +.PP +IP エイリアスが dhclient.conf で宣言されている場合、 +このアドレスが $alias_ip_address で渡されます。 +本 IP アドレスへの経路とともに、 +本 IP アドレスを対象インタフェースから削除する必要があります。 +.SH BOUND +DHCP クライアントは、新アドレスへの初期の結合を完了しました。 +新しい IP アドレスは $new_ip_address で渡され、 +インタフェース名は $interface で渡されます。 +メディアタイプは $medium で渡されます。 +サーバから獲得したオプションは、\fBdhcp-options\fR で宣言されている +オプション名で渡されます。 +例外として、 有効なシェル変数とするために +ダッシュ ('-') はアンダスコア('_')で置き換えられ、 +変数名は new_ で開始します。 +例えば、新しいサブネットマスクは $new_subnet_mask で渡されます。 +.PP +アドレスを実際に設定する前に、dhclient-script は何らかの方法で +そのアドレスに対して ARP を行い、返事を受け取った場合には非 0 の値で +終了するべきです。この場合クライアントは DHCPDECLINE メッセージをサーバ +に送信し、違うアドレスを取得します。 +この作業は RENEW, REBIND, REBOOT 状態でも同様に行いますが、 +必ずしも必要ではなく、実際好ましくないでしょう。 +.PP +結合が完了すると、 +ネットワークに関する多くのパラメータを設定する必要があるでしょう。 +$new_domain_name および $new_domain_name_servers +(これには複数のサーバを空白で区切って列挙してあるかもしれません) を使用して、 +新しい /etc/resolv.conf を作成する必要があります。 +デフォルト経路は、$new_routers を使用して設定する必要があります。 +静的経路は、$new_static_routes を使用して設定する必要があるかもしれません。 +.PP +IP エイリアスが宣言されている場合、ここで設定する必要があります。 +エイリアスの IP アドレスは $alias_ip_address として記述され、 +エイリアス用に設定される他の DHCP オプション (例えばサブネットマスク) は +前述のように変数で渡されますが、 +$new_ で開始するのではなく $alias_ で開始します。 +エイリアスの IP アドレスが結合された IP アドレス ($new_ip_address) と +同じ場合、これを使用してはならないことに注意してください。 +なぜなら、この場合には他のエイリアスのパラメータが正しくない可能性がある +からです。 +.SH RENEW +結合が更新されると、スクリプトは BOUND と同様に呼ばれますが、 +$new_ で開始する全変数に加えて $old で開始する別の変数の組があるという +例外があります。 +変更された可能性がある永続的な設定は、削除する必要があります。 +例えば、結合されたアドレスに対するローカル経路が設定された場合、 +古いローカル経路を削除する必要があります。 +デフォルト経路が変更された場合、古いデフォルト経路を削除する必要があります。 +静的経路が変更された場合、古いものを削除する必要があります。 +その他については、BOUND と同様に処理可能です。 +.SH REBIND +DHCP クライアントが、新規 DHCP サーバに再結合されました。 +これは RENEW と同様に扱えますが、IP アドレスが変わった場合には、 +ARP 表をクリアする必要があります。 +.SH REBOOT +DHCP クライアントは、リブート後に元のアドレスを再獲得することに成功しました。 +これは BOUND と同様に処理可能です。 +.SH EXPIRE +DHCP クライアントはリース更新と新規リース獲得に失敗し、 +リースの期限が切れました。 +対象 IP アドレスを解放する必要があり、 +RENEW および REBIND と同様に、関連するパラメータを削除する必要があります。 +.SH FAIL +DHCP クライアントは DHCP サーバに接続できず、 +また検査した IP アドレスには有効なものはありませんでした。 +最後に検査したリースのパラメータは、設定解除する必要があります。 +これは、EXPIRE と同様に扱えます。 +.SH TIMEOUT +DHCP クライアントはどの DHCP サーバにも接続できませんでした。 +しかしながら、古いリースが識別され、 +BOUND と同様に、この古いリースのパラメータが渡されました。 +クライアントの設定スクリプトは、このパラメータを検査し、 +これが有効であると信じる理由があるならば、値 0 で終了すべきです。 +そうでないならば、非 0 の値で終了すべきです。 +.PP +リースを検査する通常の方法は、REBIND と同様にネットワークを設定して +(複数のリースを検査するために呼ばれることがあるからです)、 +$routers で定義される最初のルータに ping することです。 +応答を受信した場合、 +インタフェースが現在接続されているネットワークに対して、リースが有効です。 +$new_static_routers に加えて +$new_routers に列挙されている全ルータに ping を試すようになれば、 +完全性が増すでしょう。しかし、現在のスクリプトはそうなっていません。 +.SH 関連ファイル +類似したオペレーティングシステムに対するスクリプトファイルは +似ていたり全く同じかもしれませんが、一般には、 +各オペレーティングシステム用に各々のスクリプトファイルがあるべきです。 +Internet Systems Consortium の DHCP 配布に含まれるスクリプトファイルは、 +client/scripts 以下の配布ツリーにあり、 +動作対象オペレーティングシステム名になっています。 +.SH バグ +複数インタフェースを使用する場合、 +サーバが提供する設定パラメータ同士が +衝突しないようにする明確な方法はありません。 +例えば、 +標準の dhclient-script は /etc/resolv.conf を再度書き換えてしまいます。 +すなわち、複数のインタフェースが設定されている場合、 +あるサーバから提供される値に /etc/resolv.conf が初期化された後に、 +別のサーバから提供される値に初期化されるという動作を繰り返します。 +どちらのサーバから提供される情報も有効である場合には、 +実際上問題とはならないものの、混乱のもとになりえます。 +.SH 関連項目 +dhclient.conf(5), dhclient.leases(5), dhclient(8) +.SH 作者 +.B dhclient-script(8) +は Ted Lemon が +Vixie Enterprises と協力して Internet Systems Consortium のために +書きました。 +Internet Systems Consortium についてより詳しくは、 +.B https://www.isc.org +をご覧ください。 +Vixie Enterprises についてより詳しくは、 +.B http://www.vix.com +をご覧ください。 diff --git a/doc/ja_JP.eucJP/dhclient.8 b/doc/ja_JP.eucJP/dhclient.8 new file mode 100644 index 0000000..4bd0004 --- /dev/null +++ b/doc/ja_JP.eucJP/dhclient.8 @@ -0,0 +1,365 @@ +.\" $Id: dhclient.8,v 1.3.24.1 2009/11/20 01:49:01 sar Exp $ +.\" +.\" Copyright (c) 2004,2009 by Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (c) 1996-2003 by Internet Software Consortium +.\" +.\" 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. +.\" +.\" 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. +.\" +.\" Internet Systems Consortium, Inc. +.\" 950 Charter Street +.\" Redwood City, CA 94063 +.\" <info@isc.org> +.\" https://www.isc.org/ +.\" +.\" Portions copyright (c) 2000 David E. O'Brien. +.\" All rights reserved. +.\" %FreeBSD: src/contrib/isc-dhcp/client/dhclient.8,v 1.8.2.3 2002/04/11 10:16:45 murray Exp % +.\" +.\" $FreeBSD: doc/ja_JP.eucJP/man/man8/dhclient.8,v 1.8 2002/05/21 03:46:48 horikawa Exp $ +.\" WORD: Dynamic Host Configuration Protocol (DHCP) 動的ホスト設定プロトコル +.\" WORD: lease リース [dhclient.8] +.\" WORD: mobile host 移動ホスト +.\" WORD: limited broadcast address リミテッドブロードキャストアドレス +.\" WORD: networking framework ネットワーキングフレームワーク +.\" WORD: housekeeping chores 雑事 +.TH dhclient 8 +.SH 名称 +dhclient - 動的ホスト設定プロトコルのクライアント +.SH 書式 +.B dhclient +[ +.B -p +.I port +] +[ +.B -D +] +[ +.B -d +] +[ +.B -q +] +[ +.B -1 +] +[ +.B -r +] +[ +.B -lf +.B lease-file +] +[ +.B -pf +.I pid-file +] +[ +.B -cf +.I config-file +] +[ +.B -sf +.I script-file +] +[ +.B -s +server +] +[ +.B -g +relay +] +[ +.B -n +] +[ +.B -nw +] +[ +.B -w +] +[ +.I if0 +[ +.I ...ifN +] +] +.SH 解説 +Internet Systems Consortium の DHCP クライアントである dhclient +は動的ホスト設定プロトコル (DHCP: Dynamic Host Configuration Protocol) +または BOOTP プロトコルを用いて、あるいは +これらのプロトコルが失敗した場合にはアドレスを静的に割り当てて、 +1 つ以上のネットワークインタフェースを設定する方法を提供します。 +.SH 操作 +.PP +DHCP プロトコルでは、1 つ以上のサブネットに割り当てることのできる +IP アドレスのリストを管理する中央サーバに、ホストがアクセスできます。 +DHCP クライアントはこのリストからアドレスを要求して、 +それをネットワーク通信の一時的な土台に用いることができます。 +また DHCP プロトコルは、デフォルトルータの場所やネームサーバの場所など、 +クライアントが接続しているネットワークに関する重要な情報を +クライアントに詳細に知らせる機構も提供します。 +.PP +起動時に dhclient は +.IR dhclient.conf +から設定指示を読み取ります。 +それから現在のシステムに組み込まれている +すべてのネットワークインタフェースのリストを取得します。 +各インタフェースに対し dhclient は DHCP プロトコルを用いて設定を試みます。 +.PP +システムリブートやサーバ再起動の際にリースを失わないように、 +dhclient は割り当てられたリースのリストを +dhclient.leases(5) ファイルに保存します。 +起動時、dhclient.conf ファイルを読み取った後、 +dhclient は dhclient.leases ファイルを読み込んで、 +割り当てられたリースに関するメモリを更新します。 +.PP +新しいリースを取得すると、dhclient.leases ファイルの末尾に付け加えられます。 +ファイルが極端に大きくなるのを防ぐために、 +dhclient は時おりコア内部のリースデータベースから +新規に dhclient.leases ファイルを作成します。 +古い dhclient.leases ファイルは、 +dhclient が次にデータベースを作り替えるまで、 +.IR dhclient.leases~ +という名前で保存されます。 +.PP +dhclient が最初に起動されたとき +(一般的にはシステムブート初期過程の間) に DHCP サーバが利用できなければ、 +古いリースは残されます。 +その場合、dhclient.leases ファイルから +まだ期限の切れていない古いリースを検査し、 +有効であると判断されれば、それらの期限が切れるか +または DHCP サーバが利用できるようになるまで、そのリースを使います。 +.PP +DHCP サーバが存在しないネットワークに時おりアクセスする必要が +あるような移動ホストは、そのネットワーク上の固定アドレスのリースを +あらかじめ読み込んでおくことができます。 +DHCP サーバへのアクセスがどれも成功しなかった場合、 +dhclient はその静的なリースが有効であるか検証し、 +有効であれば次に再起動されるまでそのリースを使います。 +.PP +また移動ホストは、DHCP は利用できないが BOOTP なら利用できるような +ネットワークへ移動することもあるでしょう。 +そのような場合は、古いリースを順次試すよりも、 +そのネットワークの管理者と相談して +BOOTP データベースにエントリを作成してもらい、 +そのネットワーク上で素早くブートできるようにするとよいでしょう。 +.SH コマンドライン +.PP +dhclient が設定しようとするネットワークインタフェースの名前を +コマンドラインで指定できます。 +コマンドラインでインタフェース名が指定されなければ、 +dhclient はすべてのネットワークインタフェースを識別し、 +可能なら非ブロードキャストインタフェースは除いて、 +それぞれのインタフェースを設定しようとします。 +.PP +.B dhclient.conf(5) +ファイル中の名前でインタフェースを指定することも可能です。 +この方法でインタフェースを指定した場合、クライアントは、 +設定ファイル中で指定したインタフェースもしくはコマンド行で +指定したインタフェースのどちらかだけを設定するでしょう。 +.PP +.B -D +フラグを指定すると、 +.B dhclient +が +.B dhclient-script +と組み合わせて使用するために作成したスクリプトを、 +.IR /tmp +に保存させます。 +.PP +DHCP クライアントが標準ポート (ポート番号 68) 以外のポートで +待機および送信する必要がある場合には +.B -p +フラグが使えます。 +このフラグに続けて、dhclient が使う udp ポート番号を指定します。 +これは主としてデバッグ目的では有用です。 +クライアントが待機および送信するために使用するポートに +デフォルトとは違うポートを指定する場合、クライアントは +もう 1 つ別の送信先ポートも使用します。その送信先ポートは、 +指定した送信先ポートよりも大きな番号を持ったものです。 +.PP +DHCP クライアントは、通常 IP アドレスを獲得していない間 +任意のプロトコルメッセージをリミテッドブロードキャスト +アドレスである 255.255.255.255 へと送信します。 +デバッグ目的で、サーバがこれらのメッセージをどこか別のアドレスへ +送信した方が便利なことがあります。 +.B -s +フラグの後に送信先の IP アドレスもしくはドメイン名をつけて指定 +できます。 +テスト目的で、DHCP クライアントが送信する全てのパケットの +giaddr フィールドを +.B -g +フラグに送信先の IP アドレスを続けた形を使用することで設定する +ことができます。これはテスト目的の時のみ有用なものであり、 +堅実さや使いやすさを求める状況で動作することを想定しては +いけません。 +.PP +DHCP クライアントは、通常インタフェースを設定するまでは +フォアグラウンドで動作し、その後バックグラウンドで動作 +するようになります。dhclient を常にフォアグラウンドの +プロセスとして動作させるためには、 +.B -d +フラグを指定する必要があります。これは、DHCP クライアントが +デバッガのもとで動作している場合や、System V システムの +inittab の外側で動作している場合には有効なものです。 +.PP +このクライアントは、通常は起動メッセージを表示し、アドレスを +獲得するまで標準エラー出力にプロトコルシーケンスを +書き出します。アドレスを獲得した後は +.B syslog (3) +ファシリティを使用してメッセージのログを取るだけになります。 +.B -q +フラグを使用すると、エラー以外のメッセージを標準エラー出力に +書き出さないようになります。 +.PP +クライアントは、DHCP プロトコルで義務づけられていないため、 +通常は現在取得しているリースを開放することはありません。 +ただ、ケーブル ISP のなかには、クライアントが +割り当てられたIP アドレスを開放したい場合には、サーバに +通知するように義務づけているところもあります。 +.B -r +フラグを用いると、明示的に現在のリースを開放し、いったん +リースを開放するとクライアントは終了します。 +.PP +.B -1 +フラグを指定すると、 +dhclient はひとつのリースに対し 1 度だけしか取得を試みません。 +もし取得に失敗すれば dhclient は終了コード 2 で終了します。 +.PP +DHCP クライアントは、通常は設定情報を +.B ETCDIR/dhclient.conf +から、リースデータベースを +.B DBDIR/dhclient.leases +から取得し、自分のプロセス ID を +.B RUNDIR/dhclient.pid +という名前のファイルに保存し、 +そしてネットワークインタフェースを +.B CLIENTBINDIR/dhclient-script +を使用して設定します。 +これらのファイルに別の名前を指定したり、別の場所を +指定したりするには、それぞれ +.B -cf, +.B -lf, +.B -pf +および +.B -sf +フラグを、後ろにファイル名を続ける形で使用してください。 +この方法は、例えば DHCP クライアントが起動したときに +.B DBDIR +もしくは +.B RUNDIR +がまだマウントされていない場合には特に有用なものに +なり得ます。 +.PP +DHCP クライアントは、設定すべきネットワーク +インタフェースを同定できない場合、通常は終了します。 +ラップトップコンピュータやホットスワップ可能な I/O バスを +持ったコンピュータでは、ブロードキャストインタフェースが +システム起動後に追加されることがあり得ます。 +.B -w +フラグを用いると、そのようなインタフェースが 1 つも +見つからないときにもクライアントが終了しないようにできます。 +後で +.B omshell (8) +プログラムを使用して、ネットワークインタフェースが追加されたり +削除されたりしたことをクライアントに通知することができ、 +これによってクライアントがこのインタフェース上の +IP アドレスを設定するよう試みることができます。 +.PP +.B -n +フラグを用いることで、どのインタフェースも設定しようと +しないように DHCP クライアントを指示することができます。 +このフラグは、きっと +.B -w +フラグと共に使用すると有用でしょう。 +.PP +IP アドレスを獲得するまで待つのではなく、即座にデーモンと +なるようにクライアントを指示することもできます。 +.B -nw +フラグを与えると可能です。 +.SH 設定 +dhclient.conf(5) ファイルの書式は別に解説されています。 +.SH OMAPI +この DHCP クライアントは、動作中にその動作を停止させる +ことなく自分自身を制御できるようにするための機能を提供しています。 +この機能は、リモートオブジェクト操作 API である OMAPI を +用いて提供されています。OMAPI クライアントは、TCP/IP を +使用してこの DHCP クライアントに接続します。そして、 +DHCP クライアントの現在の状態を検査でき、その状態を変更することが +できます。 +.PP +ユーザプログラムでは、基礎にある OMAPI プロトコルを直接実装する +のではなく、dhcpctl API もしくは OMAPI そのものを使用すべきです。 +dhcpctl は、OMAPI が自動で行ってはくれない雑事のいくつかを扱う +ラッパです。dhcpctl および OMAPI については +\fBdhcpctl(3)\fR および \fBomapi(3)\fR に記述されています。 +クライアントを用いてやりたいことのほとんどは、特別なプログラムを +書かなくとも \fBomshell(1)\fR コマンドを使用して直接実現できる +ものです。 +.SH 制御オブジェクト +制御オブジェクトを使用すると、DHCP クライアントを終了させ、 +保持しているリースをすべて開放し、クライアントが追加した +DNS レコードをすべて消去することができるようになります。 +また、クライアントを一時停止させ、クライアントが使用している +インタフェースの設定を除くことができるようにもなります。 +その後で、DHCP クライアントを再起動させることができ、 +インタフェースを再設定することができます。通常、ハイバネーションに +入る前やラップトップコンピュータではスリープする前に +DHCP クライアントを一時停止させるでしょう。 +そして、電源が戻ってきた後で DHCP クライアントを回復させる +でしょう。こうすることで、コンピュータがハイバネーションや +スリープ中には PC カードを停止させておき、コンピュータが +ハイバネーションやスリープから復帰したら以前の状態に +再度初期化することができるようになるのです。 +.PP +制御オブジェクトには属性が 1 つあります。それは状態属性です。 +クライアントを終了させるには、クライアントの状態属性を 2 に +設定します。クライアントは自動的に DHCPRELEASE を行うでしょう。 +クライアントを一時停止させるには、クライアントの状態属性を +3 に設定します。クライアントを復帰させるには、クライアントの +状態属性を 4 に設定します。 +.SH 関連ファイル +.B CLIENTBINDIR/dhclient-script, +.B ETCDIR/dhclient.conf, DBDIR/dhclient.leases, RUNDIR/dhclient.pid, +.B DBDIR/dhclient.leases~ +.SH 関連項目 +dhclient.conf(5), dhclient.leases(5), dhclient-script(8) +.SH 作者 +.B dhclient(8) +は Ted Lemon が +Vixie Enterprises と協力して Internet Systems Consortium のために +書きました。 +Internet Systems Consortium についてより詳しくは、 +.B https://www.isc.org +をご覧ください。 +Vixie Enterprises についてより詳しくは、 +.B http://www.vix.com +をご覧ください。 +.PP +本クライアントは、Elliot Poger が +Stanford 大学の MosquitoNet プロジェクトに参加している間に、 +Linux での利用に際し大幅に修正、改良を行いました。 +.PP +現在のバージョンは、Elliot による Linux での改良に負うところが大きいですが、 +Internet Systems Consortium の DHCP サーバが使うものと同じ +ネットワーキングフレームワークを用いるように、Ted Lemon が +大幅な再編成や部分的な書き換えを行いました。 +システム特有の設定コードの大部分はシェルスクリプトに移されたので、 +より多くのオペレーティングシステムのサポートが加えられるにつれ、 +システム特有の設定コードをそのオペレーティングシステムに +移植したり管理したりする必要はなくなるでしょう。 +代わりに、シェルスクリプトが環境に合ったツールを呼び出して +その目的を果たしてくれます。 +.PP diff --git a/doc/ja_JP.eucJP/dhclient.conf.5 b/doc/ja_JP.eucJP/dhclient.conf.5 new file mode 100644 index 0000000..ffed330 --- /dev/null +++ b/doc/ja_JP.eucJP/dhclient.conf.5 @@ -0,0 +1,625 @@ +.\" $Id: dhclient.conf.5,v 1.3.24.1 2009/11/20 01:49:01 sar Exp $ +.\" +.\" Copyright (c) 2004,2009 by Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (c) 1996-2003 by Internet Software Consortium +.\" +.\" 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. +.\" +.\" 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. +.\" +.\" Internet Systems Consortium, Inc. +.\" 950 Charter Street +.\" Redwood City, CA 94063 +.\" <info@isc.org> +.\" https://www.isc.org/ +.\" +.\" This software has been written for Internet Systems Consortium +.\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc. +.\" To learn more about Internet Systems Consortium, see +.\" ``https://www.isc.org/''. To learn more about Vixie Enterprises, +.\" see ``http://www.vix.com''. To learn more about Nominum, Inc., see +.\" ``http://www.nominum.com''. +.\" +.\" %FreeBSD: src/contrib/isc-dhcp/client/dhclient.conf.5,v 1.7.2.1 2002/04/11 10:16:46 murray Exp % +.\" $FreeBSD: doc/ja_JP.eucJP/man/man5/dhclient.conf.5,v 1.6 2002/05/03 03:23:30 horikawa Exp $ +.\" WORD: lease リース(アドレスの貸与)[dhclient.conf.5] +.\" WORD: lease discovery request リース発見要求[dhclient.conf.5] +.\" WORD: offer (リース提供の)申し出、提供申し出[dhclient.conf.5] +.TH dhclient.conf 5 +.SH 名称 +dhclient.conf - DHCP クライアント設定ファイル +.SH 解説 +dhclient.conf ファイルには +Internet Systems Consortium の DHCP クライアントである +.IR dhclient +の設定情報が含まれます。 +.PP +dhclient.conf は自由形式の ASCII テキストファイルです。 +このファイルは dhclient に組み込まれた再帰下降パーザに解析されます。 +ファイルには、整形の目的でタブや改行を余分に含めることもできます。 +ファイル中のキーワードでは大文字小文字を区別しません。 +(クォート内は除いて) ファイル中のどこでもコメントを置くことができます。 +コメントは文字 # で始まり、行末で終わります。 +.PP +dhclient.conf ファイルで、クライアントのさまざまな動作を設定できます。 +それらには、プロトコルのタイミング、サーバに対して要求する情報、 +サーバに対して必須とされる情報、 +サーバが情報を提供しなかった場合に用いるデフォルト、 +サーバから提供された情報を上書きする値、 +サーバから提供された情報に前置や後置する値などがあります。 +また、DHCP サーバを持たないネットワークで使うアドレスであっても、 +あらかじめ設定ファイルで初期化することもできます。 +.SH プロトコルのタイミング +クライアントのタイミング動作は、ユーザが設定する必要はありません。 +ユーザがタイミング設定を行わなければ、 +サーバに無秩序に負荷を与えたりせず適時更新を行うような、 +充分に適切なタイミング動作がデフォルトで用いられます。 +.PP +しかし、必要に応じて、 +次の文を指定して DHCP クライアントのタイミング動作を調節できます: +.PP +.B timeout +.I 文 +.PP +.B timeout +.I time +.B ; +.PP +.I timeout +文は、クライアントがアドレスを決める試みを開始してから、 +サーバにアクセスすることが +できないと判断するまでに経過すべき時間を決めます。 +デフォルトではこのタイムアウト値は 60 秒です。 +このタイムアウト値が過ぎた後は、 +もし静的なリースが設定ファイルに定義されているか、 +リースデータベースにまだ期限切れになっていないリースが残っていれば、 +クライアントはそれらのリースをひとつずつ検証してみて、 +いずれかが有効なようであればそのリースのアドレスを使います。 +もし静的なリースも、リースデータベース内の期限の切れていないリースで +有効なものも存在しなければ、 +クライアントは定義された retry 間隔の後でプロトコルを再開させます。 +.PP +.B retry +.I 文 +.PP + \fBretry \fItime\fR\fB;\fR +.PP +.I retry +文は、クライアントが DHCP サーバが存在しないと判断してから +再び DHCP サーバにアクセスを試みるまでの間に、経過するべき時間を決めます。 +デフォルトでは、これは 5 分です。 +.PP +.B select-timeout +.I 文 +.PP + \fBselect-timeout \fItime\fR\fB;\fR +.PP +あるネットワーク上で、複数の DHCP サーバがサービスを提供することもできます +(その方が望ましいという意見もあります)。 +その場合、最初のリース発見メッセージ (lease discovery message) +への応答として、 +クライアントが複数のリース提供の申し出を受けることもあり得ます。 +それらのうち、ある提供が他の提供よりも好ましいかもしれません +(例えば、クライアントが以前使用していたアドレスがある提供に含まれているが、 +他の提供には含まれないなど)。 +.PP +.I select-timeout +はクライアントが最初のリース発見要求 +を送信して、 +少なくとも 1 つの提供申し出を受けた場合、 +サーバからの提供申し出待ちをやめるまでの時間です。 +もし +.I select-timeout +が切れるまでにどこからも提供申し出を受け取れなければ、 +クライアントはそのあと最初に到着する提供申し出を受け入れます。 +.PP +デフォルトでは、select-timeout 値は 0 秒です。 +つまりクライアントは最初に受け取る提供申し出を受け入れます。 +.PP +.B reboot +.I 文 +.PP + \fBreboot \fItime\fR\fB;\fR +.PP +クライアントは、再起動すると、 +最後に保持していたアドレスをまず取得し直そうとします。 +これを INIT-REBOOT (初期リブート) 状態と呼びます。 +最後に動作していたときと同じネットワークに +クライアントがまだ接続していれば、これが最も素早い起動法となります。 +.I reboot +文は、クライアントが最初に古いアドレスの再取得を試みてから、 +あきらめて新しいアドレスを発見しようとするまでに、 +経過すべき時間を設定します。 +デフォルトでは、reboot タイムアウト値は 10 秒です。 +.PP +.B backoff-cutoff +.I 文 +.PP + \fBbackoff-cutoff \fItime\fR\fB;\fR +.PP +クライアントは、指数的な一時退避 (backoff) アルゴリズムを、ある程度の +乱数付きで使用します。これは、多くのクライアントが同時に自分を設定しよう +としたときでも、リクエストがロックしてしまうことがないようにするためです。 +.I backoff-cutoff +文は、一時退避に許された最大時間を決定します。デフォルト値は 2 分です。 +.PP +.B initial-interval +.I 文 +.PP + \fBinitial-interval \fItime\fR\fB;\fR +.PP +.I initial-interval +文は、サーバへの最初のアクセスの試みから次の試みまでの間の時間を +設定します。メッセージの間隔は、メッセージを 1 回送信するたびに、 +現在の間隔に 0 から 1 の間の乱数値を乗じたものの 2 倍を、現在の間隔に +加えたものになります。 +この値が backoff-cutoff 値より大きくなると、この時間が設定されます。 +デフォルト値は 10 秒です。 +.SH リース要求とリクエスト +DHCP プロトコルでは、クライアントからサーバに対し、特定の情報を送るよう +要求したり、受け入れ準備のできていない他の情報は送らないように要求したり +できます。 +また、サーバからの提供申し出にクライアントの必要とする情報が含まれない +場合や、提供された情報が充分でない場合、クライアントが提供申し出を +拒否することもできます。 +.PP +DHCP サーバが DHCP クライアントに送る提供申し出に含まれるデータには、 +さまざまなものがあります。 +特に要求できるデータは \fIDHCP オプション\fR と呼ばれるものです。 +DHCP オプションは + \fBdhcp-options(5)\fR +に定義されています。 +.PP +.B request +.I 文 +.PP + \fBrequest [ \fIoption\fR ] [\fB,\fI ... \fIoption\fR ]\fB;\fR +.PP +request 文を指定することで、クライアントは、サーバに対し、その +クライアントに応答するならば、指定したオプションの値を送るよう +要求するようになります。 +request 文にはオプション名だけを指定し、オプションパラメータは指定しません。 +デフォルトでは DHCP クライアントは +subnet-mask, broadcast-address, time-offset, routers, +domain-name, domain-name-servers, host-name +オプションを要求します。 +.PP +場合によっては要求リストを全く送らないことが望ましいこともあります。 +そうするためには、単純にパラメータを指定しない request 文を書いて下さい: +.PP +.nf + request; +.fi +.PP +.B require +.I 文 +.PP + \fBrequire [ \fIoption\fR ] [\fB,\fI ... \fIoption ]\fB;\fR +.PP +require 文には、ある提供申し出をクライアントが受け入れるために +サーバが送るべきオプションを列挙します。 +列挙されたオプションすべてを含まない提供申し出は無視されます。 +.PP +.B send +.I 文 +.PP + \fBsend { [ \fIoption declaration\fR ] +[\fB,\fI ... \fIoption declaration\fR ]\fB}\fR +.PP +send 文を指定することで、クライアントは、 +指定したオプションを指定した値でサーバに送信するようになります。 +ここで指定できるオプションは、 +\fBdhcp-options(5)\fR で説明されているオプション宣言すべてです。 +DHCP プロトコルで常に送られるオプションは +ここに指定するべきではありません。但し、 +\fBrequested-lease-time\fR オプションをデフォルトのリース時間 (2 時間) +以外の値で指定することはできます。この文を使う他の場合として明らかな +ものは、自分と別の種類のクライアントとを区別できるような +情報を、サーバに対し送信する場合です。 +.SH 動的 DNS +現在、リースが獲得された際に DNS の更新を行うための、 +非常に限定的なサポートがクライアントにあります。 +これはプロトタイプ的なものであり、 +おそらくあなたが思っているようには動きません。 +もし、あなたが偶然にも自分のところの DNS サーバの管理者であるというなら、 +その場合に限っては動きます。とてもありそうにないことですが。 +.PP +これを動作させるためには、DHCP サーバの中で +鍵とゾーンを宣言する必要があります (詳細は \fBdhcpd.conf\fR(5) を参照)。 +また、次のようにクライアントで fqdn オプションを設定する必要があります: +.PP +.nf + send fqdn.fqdn "grosse.fugue.com."; + send fqdn.encoded on; + send fqdn.server-update off; +.fi +.PP +\fIfqdn.fqdn\fR オプションは \fB必ず\fR 完全なドメイン名でなければなりません。 +更新するゾーンに対するゾーン文を \fB必ず\fR 定義しなければなりません。 +\fIfqdn.encoded\fR オプションは、使用している DHCP サーバによっては、 +\fIon\fR か \fIoff\fR に設定する必要があるかもしれません。 +.PP +.B no-client-updates +.I 文 +.PP + \fBno-client-updates [ \fIflag\fR ] \fB;\fR +.PP +DHCP クライアントが直接 DNS の更新を行うよりも、 +DHCP クライアントスクリプト (\fBdhclient-script(8)\fR 参照) の中で +DNS の更新を行いたい場合 +(例えば、DHCP クライアントが直接サポートしていない +SIG(0) 認証を使用したい場合) +には、\fBno-client-updates\fR 文を使って、更新を行わないように +クライアントに教えることができます。 +DHCP クライアントが更新することを望まない場合は \fIflag\fR を \fBtrue\fR にし、 +更新することを望む場合は \fIflag\fR を \fBfalse\fR にすることになります。 +デフォルトでは DHCP クライアントは DNS の更新を行います。 +.PP +.SH オプション修飾子 +そのクライアントにとって実際には適切でない +オプションデータを受け取ったり、必要な情報を受け取らなかったり +する場合で、かつ、それらの情報に利用可能なデフォルトの値が +クライアント側に存在する場合があります。 +また、利用可能ではあるがローカルの情報で補う必要のある情報を +クライアントが受けとる場合もあります。 +こういう場合を扱うために、 +いくつかのオプション修飾子が利用できます。 +.PP +.B default +.I 文 +.PP + \fBdefault [ \fIoption declaration\fR ] \fB;\fR +.PP +あるオプションについて、 +サーバから提供される値をクライアントが使わなければならないが、 +もしサーバから値が提供されなければ +何らかのデフォルト値を使う必要がある場合、 +それらの値を +.B default +文で定義することができます。 +.PP +.B supersede +.I 文 +.PP + \fBsupersede [ \fIoption declaration\fR ] \fB;\fR +.PP +あるオプションについて、 +どのような値がサーバから提供されても、 +常にローカルで設定された値を使わなければならない場合、 +それらの値を +.B supersede +文で定義することができます。 +.PP +.B prepend +.I 文 +.PP + \fBprepend [ \fIoption declaration\fR ] \fB;\fR +.PP +あるオプションの集合について、まずユーザが提供する値を使い、 +その次にサーバから提供された値があればそれを使う場合、 +それらの値を +.B prepend +文で定義することができます。 +.B prepend +文は複数の値を取ることのできるオプションにのみ用いることができます。 +この制約は強制されるものではありませんが、 +これを無視した場合、どのような挙動になるかは予想できません。 +.PP +.B append +.I 文 +.PP + \fBappend [ \fIoption declaration\fR ] \fB;\fR +.PP +あるオプションの集合について、まずサーバから提供された値を使い、 +その次にユーザが提供する値があればそれも使う場合、 +それらの値を +.B append +文で定義することができます。 +.B append +文は複数の値を取ることのできるオプションにのみ用いることができます。 +この制約は強制されるものではありませんが、 +もし違反すると予期できない結果となります。 +.SH リース宣言 +.PP +.B lease +.I 宣言 +.PP + \fBlease {\fR \fIlease-declaration\fR [ ... \fIlease-declaration ] \fB}\fR +.PP +ある時間 (\fBプロトコルのタイミング\fR 参照) の後、DHCP クライアントは +サーバへのアクセスに成功しそうにないと判断する場合があります。 +その時点で、クライアントは自分が持っている、古いリースのデータベースを +見て、時間切れになっていないリースを順に調べ、そこに挙がっている +ルータに ping を行って、それが利用可能なリースかどうかを調べます。 +DHCP サービスや BOOTP サービスが存在しないネットワークのために、 +1 つ以上の \fI固定\fR リースをクライアント設定ファイルに定義しておいて、 +クライアントがアドレスを自動的に設定できるようにすることもできます。 +これは +.B lease +文で行います。 +.PP +注意: lease 文は、DHCP サーバから受け取ったリースを記録するために、 +dhclient.leases ファイルでも使われます。 +以下に説明するリース用のシンタックスには +dhclient.leases ファイルでのみ必要なものもあります。 +説明を完全なものにするため、そのようなシンタックスもここで記述します。 +.PP +lease 文は、リースキーワード、左中括弧、1 つ以上のリース宣言文、 +右中括弧が続いたもので構成されます。 +リース宣言として、次のものが可能です: +.PP + \fBbootp;\fR +.PP +.B bootp +文は、リースが DHCP プロトコルではなく、 +BOOTP プロトコルを用いて取得されたことを示します。 +この文をクライアント設定ファイルに指定する必要は全くありません。 +クライアントはこの構文をリースデータベースファイル内で使います。 +.PP + \fBinterface\fR \fB"\fR\fIstring\fR\fB";\fR +.PP +.B interface +リース文は、そのリースを有効とするインタフェースを示します。 +これが設定されている場合、このリースは、指定されたインタフェース +上でのみ使用されます。 +サーバからリースを受け取ったとき、 +クライアントは常にそのリースを受け取ったインタフェース番号を記録します。 +dhclient.conf ファイルで事前にリースを定義している場合、要求されてない +のですが、そのリースでインタフェースもあわせて指定しなければ +なりません。 +.PP + \fBfixed-address\fR \fIip-address\fR\fB;\fR +.PP +.B fixed-address +文は特定のリースの IP アドレスを指定する際に使います。 +これはすべての lease 文に必要です。 +IP アドレスは (12.34.56.78 のように) ドット付き 4 つ組形式で +指定しなければなりません。 +.PP + \fBfilename "\fR\fIstring\fR\fB";\fR +.PP +.B filename +文は使用するブートファイル名を指定します。 +これは標準的なクライアント設定スクリプトでは使われませんが、 +説明の完全を期すためにここに含めてあります。 +.PP + \fBserver-name "\fR\fIstring\fR\fB";\fR +.PP +.B server-name +文は使用するブートサーバ名を指定します。 +これも標準的なクライアント設定スクリプトでは使われません。 +.PP + \fBoption\fR \fIoption-declaration\fR\fB;\fR +.PP +.B option +文は、サーバから提供されるオプションの値を指定するのに使います。 +あるいは、dhclient.conf で事前定義リースが宣言されている場合には、 +その事前定義リースが使われる際にクライアント設定スクリプトで使用して +欲しい値を指定します。 +.PP + \fBscript "\fIscript-name\fB";\fR +.PP +.B script +文は dhcp クライアント設定スクリプトのパス名を指定するのに使います。 +このスクリプトは、アドレスを要求したり、以前に提供されたアドレスを +試したり、 +リースを取得してからインタフェースの最終設定を行ったりする前に、 +dhcp クライアントが各インタフェースの初期設定を行うのに使います。 +リースが取得できなかった場合には、 +事前定義リースが存在する場合、それらを試すためにこのスクリプトが使われます。 +また、有効なリースがひとつも得られなかった場合でも、このスクリプトは、 +1 回は呼び出されます。 +より詳しくは、 +.B dhclient-script(8) +を参照してください。 +.PP + \fBvendor option space "\fIname\fB";\fR +.PP +.B vendor option space +文は、vendor-encapsulate-options オプションを受信した場合、 +復号化にどのオプション空間を使用するべきかを指定するために使用されます。 +サーバからのベンダオプションの特定のクラスを要求するために、 +\fIdhcp-vendor-identifier\fR を使用することができます。 +詳細は +.B dhcp-options(5) +を参照してください。 +.PP + \fBmedium "\fImedia setup\fB";\fR +.PP +.B medium +文は、接続されているネットワークのタイプをネットワークインタフェースが +自動的に判断できないようなシステムで使うことができます。 +文字列 media setup はシステム依存のパラメータで、 +インタフェース初期化の際に dhcp クライアント設定スクリプトに渡されます。 +Unix および Unix 風のシステムでは、 +この引数はインタフェースを設定するときに ifconfig コマンドラインに +渡されます。 +.PP +リースを得るためにインタフェースを設定する +際に、dhcp クライアントがメディアタイプ ( +.B media +文を参照) を使用する場合、dhcp クライアントは、このパラメータを +自動的に宣言します。ネットワークインタフェースがメディアタイプの +設定を必要とする場合は (する場合に限り)、この文を事前定義リースで +使用しなければなりません。 +.PP + \fBrenew\fR \fIdate\fB;\fR +.PP + \fBrebind\fR \fIdate\fB;\fR +.PP + \fBexpire\fR \fIdate\fB;\fR +.PP +\fBrenew\fR 文は、現在使用中のリースを更新 (renew) するために、 +dhcp クライアントが使用中のリースを提供してくれたサーバへのアクセスの +試みを開始しなければならない日時を定義します。\fBrebind\fR 文は、 +リースを更新するために、dhcp クライアントが \fIいずれかの\fR dhcp +サーバへのアクセスの試みを開始しなければならない日時を定義します。 +\fBexpire\fR 文は、リースの更新のためにサーバにアクセスできなかった場合、 +dhcp クライアントがそのリースの使用を停止しなければならない日時を +定義します。 +.PP +これらの宣言は、DHCP クライアントが得たリース中では自動的に設定されます。 +事前定義リースのうち、DHCP クライアントに有効期限が過ぎたものを使用して +欲しくないものの中では、これらの宣言を設定しておく必要があります。 +.PP +date は以下のように指定します。 +.PP + \fI<weekday> <year>\fB/\fI<month>\fB/\fI<day> +<hour>\fB:\fI<minute>\fB:\fI<second>\fR +.PP +weekday は、人間が見てリース期限をわかりやすくするために存在します。 +これは、0 から 6 までの数字で指定します。0 は日曜日です。year は世紀 +込みで指定します。ですから、本当に長いリースを別にすると、必ず 4 桁に +なるはずです。month は 1 (1 月を表します) から始まる数字で指定します。 +day は同様に 1 から始まる (月における) 日として指定します。hour は、 +0 から 23 の間の数字です。minute と second はともに 0 から 59 の間の +数字を指定します。 +.SH エイリアス宣言 + \fBalias { \fI declarations ... \fB}\fR +.PP +DHCP クライアントが TCP/IP ローミング (roaming) プロトコルを実行して +いる場合、DHCP を用いて得られるリースだけでなく、事前に定義された +IP エイリアスも、自分が使用するインタフェースに設定する必要がある +場合があります。Internet Systems Consortium 版 DHCP クライアントは、 +固定アドレス直接指定のローミングをサポートしていませんが、その種の実験 +ができるように、この dhcp クライアントは、 +.B alias +宣言を使って IP エイリアスを設定する準備はできています。 +.PP +alias 宣言は lease 宣言に似ています。但し、標準の +クライアント設定スクリプトでは、subnet-mask オプション以外の +オプションと、各種有効期限 (expiry times) が無視される点が異なります。 +普通の alias 宣言では、 interface 宣言、IP エイリアスのための +固定アドレス宣言、subnet-mask オプションを含みます。alias 宣言には +medium 文は決して含まれてはなりません。 +.SH その他の宣言 + \fBreject \fIip-address\fB;\fR +.PP +.B reject +文により、DHCP クライアントは指定したアドレスをサーバ識別子として使用する +サーバからの提供申し出を拒否するようになります。標準に準拠しない dhcp +サーバや設定を間違えている dhcp サーバによってクライアントが設定されない +ようにするために、この文を使用することができます。しかしながら、これは +最後の武器とするべきです。これに先立ち、腐った DHCP サーバを追いかけて +それを直す方がよいです。 +.PP + \fBinterface "\fIname\fB" { \fIdeclarations ... \fB } +.PP +複数のネットワークインタフェースを持つクライアントの場合、DHCP で +設定されるインタフェースによって異なる動作をさせる必要がある場合が +あります。lease 宣言と alias 宣言を除くすべてのタイミングパラメータ +と宣言を、interface 宣言で囲むことができます。その場合、囲まれた +パラメータは指定した名前に合致するインタフェースにのみ適用されます。 +interface 宣言を持たないインタフェースは、すべての interface 宣言の +外側で宣言されたパラメータ、もしくはデフォルトの設定が適用されます。 +.PP + \fBpseudo "\fIname\fR" "\fIreal-name\fB" { \fIdeclarations ... \fB } +.PP +状況によっては仮想インタフェースを宣言し、 +DHCP クライアントがこのインタフェースのための設定を取得するようにすると +便利になり得ます。 +通常 DHCP クライアントがサポートしている各インタフェースは、 +そのリースを獲得し管理するために、 +DHCP クライアントの状態機械を実行しています。 +仮想インタフェースは、\fIreal-name\fR と名付けられたインタフェース上で +稼働している、まさしくもう一つの状態機械です。 +この機能を使用する場合、 +仮想インタフェースと実際のインタフェースの両方に対して +クライアント識別子を提供しなければなりません。 +また、使用したい IP アドレスに対する仮想インタフェース用に +分離されたクライアントスクリプトを提供しなければなりません。 +例えば次のようになります: +.PP +.nf + interface "ep0" { + send dhcp-client-identifier "my-client-ep0"; + } + pseudo "secondary" "ep0" { + send dhcp-client-identifier "my-client-ep0-secondary"; + script "/etc/dhclient-secondary"; + } +.fi +.PP +仮想インタフェースのためのクライアントスクリプトは +インタフェースを有効にしたり無効にしたりする設定をするべきではありません。 +特に、リースの獲得や更新の状態、そしてリースの期限切れの状態を +取り扱うためには、そのことが必要です。 +詳細は \fBdhclient-script(8)\fR を参照して下さい。 +.PP + \fBmedia "\fImedia setup\fB"\fI [ \fB, "\fImedia setup\fB", \fI... ]\fB;\fR +.PP +.B media +文は、IP アドレス取得中に使用が試みられる、メディア設定パラメータを 1 つ +以上定義します。dhcp クライアントは、リスト中の各 media setup 文字列を +順次使用し、あるインタフェースをそれで設定し、ブートを試みます。 +駄目ならば次の media setup 文字列を使用します。この文は、 +メディアタイプを検出する能力を持たないネットワークインタフェースに +対して利用できます。サーバへのリクエストができ応答が得られるもの +ならば、どのようなメディアタイプでもたぶん正当です (保証はしませんが)。 +.PP +media setup はアドレス取得の初期フェーズ (DHCPDISCOVER パケットと +DHCPOFFER パケット)でのみ使用されます。ひとたびアドレスが取得されると、 +dhcp クライアントはそのアドレスをリースデータベースに記録し、 +そのアドレスを得る際に用いたメディアタイプを記録します。クライアントが +リースを更新しようとする際には常に、それと同じメディアタイプを使用します。 +リースを期限切れにしてはじめて、クライアントはメディアタイプを順に試す +状態に戻ります。 +.\"X .SH SAMPLE ... man-jp 標準はなんだったっけ +.SH 使用例 +以下の設定ファイルは、NetBSD 1.3 を実行するあるラップトップマシンで +使用されているものです。このマシンは、IP エイリアスとして 192.5.5.213、 +インタフェース ep0 (3Com 3C589C) をひとつ持っています。このクライアント +は、DHCP 活動がほとんどないネットワークで時間の大部分を消費することが +わかっているので、ブート間隔はデフォルト値からいくぶん小さくして +あります。このマシンは複数ネットワーク間でローミング (移動) します。 + +.nf + +timeout 60; +retry 60; +reboot 10; +select-timeout 5; +initial-interval 2; +reject 192.33.137.209; + +interface "ep0" { + send host-name "andare.fugue.com"; + send dhcp-client-identifier 1:0:a0:24:ab:fb:9c; + send dhcp-lease-time 3600; + supersede domain-name "fugue.com rc.vix.com home.vix.com"; + prepend domain-name-servers 127.0.0.1; + request subnet-mask, broadcast-address, time-offset, routers, + domain-name, domain-name-servers, host-name; + require subnet-mask, domain-name-servers; + script "CLIENTBINDIR/dhclient-script"; + media "media 10baseT/UTP", "media 10base2/BNC"; +} + +alias { + interface "ep0"; + fixed-address 192.5.5.213; + option subnet-mask 255.255.255.255; +} +.fi +これは dhclient.conf ファイルとしては非常に複雑なものです。一般に、 +皆さんが使用するものははるかに簡単なはずです。多くの場合、dhclient.conf +ファイルとして空のファイルを生成するだけで十分なはずです。 +つまり、デフォルト値でよいのが普通です。 +.SH 関連項目 +dhcp-options(5), dhclient.leases(5), dhclient(8), RFC2132, +RFC2131 +.SH 作者 +.B dhclient(8) +は Vixie Labs との契約のもとで Ted Lemon が書きました。 +本プロジェクトの基金は Internet Systems Consortium が提供しました。 +Internet Systems Consortium に関する情報は、 +.B https://www.isc.org +にあります。 diff --git a/doc/ja_JP.eucJP/dhclient.leases.5 b/doc/ja_JP.eucJP/dhclient.leases.5 new file mode 100644 index 0000000..8b5e2b0 --- /dev/null +++ b/doc/ja_JP.eucJP/dhclient.leases.5 @@ -0,0 +1,62 @@ +.\" $Id: dhclient.leases.5,v 1.3.24.1 2009/11/20 01:49:01 sar Exp $ +.\" +.\" Copyright (c) 2004,2009 by Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (c) 1997-2003 by Internet Software Consortium +.\" +.\" 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. +.\" +.\" 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. +.\" +.\" Internet Systems Consortium, Inc. +.\" 950 Charter Street +.\" Redwood City, CA 94063 +.\" <info@isc.org> +.\" https://www.isc.org/ +.\" +.\" This software has been written for Internet Systems Consortium +.\" by Ted Lemon in cooperation with Vixie +.\" Enterprises. To learn more about Internet Systems Consortium, +.\" see ``https://www.isc.org/''. To learn more about Vixie +.\" Enterprises, see ``http://www.vix.com''. +.\" +.\" +.\" %FreeBSD: src/contrib/isc-dhcp/client/dhclient.leases.5,v 1.2.4.1 2002/04/11 10:16:46 murray Exp % +.\" +.\" $FreeBSD: doc/ja_JP.eucJP/man/man5/dhclient.leases.5,v 1.6 2002/05/05 20:40:23 horikawa Exp $ +.TH dhclient.leases 5 +.SH 名称 +dhclient.leases - DHCP クライアントのリースデータベース +.SH 解説 +Internet Systems Consortium の DHCP クライアントは、 +獲得したリースのうちまだ有効であるものを管理するための、 +永続的なデータベースを保持します。 +このデータベースは、自由形式の ASCII ファイルであり、 +リース 1 つにつき有効な宣言を 1 つ含みます。 +あるリースに対して複数の宣言が登場する場合、 +ファイル中の最後のものが使用されます。 +このファイルはログとして書き込まれますので、 +このような状態になることは異常ではありません。 +.PP +リース宣言の書式は、 +.B dhclient.conf(5) +に記述されています。 +.SH 関連ファイル +.B DBDIR/dhclient.leases +.SH 関連項目 +dhclient(8), dhcp-options(5), dhclient.conf(5), +RFC2132, RFC2131 +.SH 作者 +.B dhclient(8) +は、Vixie Labs との契約のもとで、Ted Lemon が記述しました。 +本プロジェクトの資金は、Internet Systems Consortium が提供しました。 +Internet Systems Consortium に関する情報は、 +.B https://www.isc.org +にあります。 diff --git a/doc/ja_JP.eucJP/dhcp-eval.5 b/doc/ja_JP.eucJP/dhcp-eval.5 new file mode 100644 index 0000000..499a961 --- /dev/null +++ b/doc/ja_JP.eucJP/dhcp-eval.5 @@ -0,0 +1,488 @@ +.\" $Id: dhcp-eval.5,v 1.4.24.1 2009/11/20 01:49:01 sar Exp $ +.\" +.\" Copyright (c) 2004,2009 by Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (c) 1996-2003 by Internet Software Consortium +.\" +.\" 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. +.\" +.\" 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. +.\" +.\" Internet Systems Consortium, Inc. +.\" 950 Charter Street +.\" Redwood City, CA 94063 +.\" <info@isc.org> +.\" https://www.isc.org/ +.\" +.\" This software has been written for Internet Systems Consortium +.\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc. +.\" To learn more about Internet Systems Consortium, see +.\" ``https://www.isc.org/''. To learn more about Vixie Enterprises, +.\" see ``http://www.vix.com''. To learn more about Nominum, Inc., see +.\" ``http://www.nominum.com''. +.\" $FreeBSD: doc/ja_JP.eucJP/man/man5/dhcp-eval.5,v 1.2 2002/05/23 04:17:13 horikawa Exp $ +.TH dhcp-eval 5 +.SH 名称 +dhcp-eval - ISC DHCP における条件付き評価 +.SH 解説 +Internet Systems Consortium の DHCP クライアントとサーバは、どちらも +受信するパケットに依存した条件付き動作を行う能力を持ちます。 +条件付き動作の文法をここに示します。 +.SH 参照: 条件付き動作 +条件付き動作は、if, else, elsif 文を使用して指定します。 +条件文は、通常文 (option 文) が登場可能な場所はどこにでも登場可能であり、 +またこのような文を括ることも可能です。 +サーバにおける条件文は次のようになることが多いでしょう: +.PP +.nf +if option dhcp-user-class = "accounting" { + max-lease-time 17600; + option domain-name "accounting.example.org"; + option domain-name-servers ns1.accounting.example.org, + ns2.accounting.example.org; +} elsif option dhcp-user-class = "sales" { + max-lease-time 17600; + option domain-name "sales.example.org"; + option domain-name-servers ns1.sales.example.org, + ns2.sales.example.org; +} elsif option dhcp-user-class = "engineering" { + max-lease-time 17600; + option domain-name "engineering.example.org"; + option domain-name-servers ns1.engineering.example.org, + ns2.engineering.example.org; +} else { + max-lease-time 600; + option domain-name "misc.example.org"; + option domain-name-servers ns1.misc.example.org, + ns2.misc.example.org; +} +.fi +.PP +クライアント側では、条件付き評価の例は次のようになるでしょう: +.PP +.nf +# example.org はファイヤウォールで DNS をフィルタするので、 +# example.org ネットワークに繋がるときのみ、その DNS サーバを使用します。 +# example.org に繋がるのではない場合、自己の DNS サーバを優先使用します。 +if not option domain-name = "example.org" { + prepend domain-name-servers 127.0.0.1; +} +.fi +.PP +.B if +文と +.B elsif +継続文は、引数としてブール式を取ります。 +つまり、これらの文は、評価されるとブール値の結果を生成する式を取ります。 +式の評価結果が真になると、 +.B if +文の直後のブレースで括られた文が実行され、後続する +.B elsif +と +.B else +の節はスキップされます。 +そうでない場合、評価結果が真になる elsif 節に出会うまで、後続する各 +.B elsif +節の式がチェックされます。 +そのような節が見付かると、直後のブレース中の文が実行され、後続する +.B elsif +と +.B else +の節はスキップされます。 +すべての +.B if +および +.B elsif +の節がチェックされたもののどの式も真にならない場合で、 +.B else +節が存在する場合、 +.B else +の直後のブレース中の文が評価されます。 +条件においては、評価結果が空になるブール式は偽として扱われます。 +.SH ブール式 +以下は、DHCP 配布物で現在サポートされているブール式の一覧です。 +.PP +.I data-expression-1 \fB=\fI data-expression-2\fR +.RS 0.25i +.PP +\fB=\fR オペレータは、2 個のデータ式を比較し、両者が同じ場合は真を返し、 +同一でない場合は偽を返します。 +左辺もしくは右辺のいずれかが空の場合、結果は空になります。 +.RE +.PP +.I boolean-expression-1 \fBand\fI boolean-expression-2\fR +.PP +.RS 0.25i +\fBand\fR オペレータは、左辺のブール式と右辺のブール式の両方の評価結果が +真の場合、真と評価されます。 +そうでない場合、偽と評価されます。 +左辺もしくは右辺のいずれかが空の場合、結果は空になります。 +.RE +.PP +.I boolean-expression-1 \fBor\fI boolean-expression-2\fR +.PP +.RS 0.25i +\fBor\fR オペレータは、左辺のブール式と右辺のブール式のいずれかの評価結果が +真の場合、真と評価されます。 +そうでない場合、偽と評価されます。 +左辺もしくは右辺のいずれかが空の場合、結果は空になります。 +.RE +.PP +.B not \fIboolean-expression +.PP +.RS 0.25i +\fBnot\fR オペレータは、\fIboolean-expression\fR の評価結果が偽の場合、 +真と評価されます。 +また、\fIboolean-expression\fR の評価結果が真の場合、偽と評価されます。 +\fIboolean-expression\fR の評価結果が空の場合、結果もまた空になります。 +.RE +.PP +.B exists \fIoption-name\fR +.PP +.RS 0.25i +\fBexists\fR 式は、処理対象の入力 DCHP パケット中に、 +指定されたオプションが存在する場合、真を返します。 +.RE +.B known +.PP +.RS 0.25i +\fBknown\fR 式は、要求対応中のクライアントが既知の場合、 +すなわちホスト宣言がある場合、真を返します。 +.RE +.B static +.PP +.RS 0.25i +\fBstatic\fR 式は、要求対応中のクライアントへのリース割り当てが、 +静的アドレス割り当てによるものであった場合、真を返します。 +.RE +.SH データ式 +前述のブール式は、データ式の評価結果に依存します。 +データ式をここに示します。 +.PP +.B substring (\fIdata-expr\fB, \fIoffset\fB, \fIlength\fB)\fR +.PP +.RS 0.25i +\fBsubstring\fR オペレータは、データ式を評価し、 +評価結果中の \fIoffset\fR バイトから開始して \fIlength\fR バイト継続する +サブストリングを返します。 +\fIoffset\fR と \fIlength\fR は共に数値式です。 +\fIdata-expr\fR, \fIoffset\fR, \fIlength\fR のいずれかが空と評価される場合、 +結果もまた空になります。 +\fIoffset\fR が、評価されたデータの長さ以上である場合、 +長さ 0 のデータ文字列が返されます。 +\fIlength\fI が、評価されたデータの \fIoffset\fR より後の長さより大きい場合、 +評価されたデータの \fIoffset\fR から終端までの全データを含む +データ文字列が返されます。 +.RE +.PP +.B suffix (\fIdata-expr\fB, \fIlength\fB)\fR +.PP +.RS 0.25i +\fBsuffix\fR オペレータは、\fIdata-expr\fR を評価し、 +評価結果の最後の \fIlength\fR バイトを返します。 +\fIlength\fR は数値式です。 +\fIdata-expr\fR または \fIlength\fR の評価結果が空の場合、 +結果もまた空になります。 +\fIsuffix\fR +(訳注: \fIlength\fR が正しいと思われます) +の評価結果が評価されたデータの長さより大きい場合、 +評価されたデータが返されます。 +.\" horikawa@jp.FreeBSD.org 2002/04/29 +.RE +.PP +.B option \fIoption-name\fR +.PP +.RS 0.25i +\fBoption\fR オペレータは、サーバが応答処理中のパケットの中の、 +指定したオプションの内容を返します。 +.RE +.PP +.B config-option \fIoption-name\fR +.PP +.RS 0.25i +\fBconfig-option\fR オペレータは、指定したオプションに対し、 +DHCP クライアントまたはサーバが送出するよう設定された値を返します。 +.RE +.PP +.B hardware +.PP +.RS 0.25i +\fBhardware\fR オペレータは、データストリングを返します。 +データストリングの最初の要素は、 +対象パケットが示すネットワークインタフェースのタイプであり、 +後続する要素は、クライアントのリンク層アドレスです。 +パケットが存在しない場合もしくは RFC2131 \fIhlen\fR フィールドが無効な場合、 +結果は空になります。 +ハードウェアタイプには、イーサネット (1)、トークンリング (6)、 +FDDI (8) が含まれます。 +ハードウェアタイプは IETF によって規定され、 +どのようにタイプの数値が定義されるかの詳細は RFC2131 +(ISC DHCP 配布物では、doc/ サブディレクトリにあります) を参照してください。 +.RE +.PP +.B packet (\fIoffset\fB, \fIlength\fB)\fR +.PP +.RS 0.25i +\fBpacket\fR オペレータは、対象パケットの指定部分を返すか、 +対象パケットが無い文脈では空を返します。 +\fIoffset\fR と \fIlength\fR は、 +\fBsubstring\fR オペレータと同様に、パケットの内容に適用されます。 +.RE +.PP +.I string +.PP +.RS 0.25i +クォートで括られたストリングはデータ式として指定可能であり、 +クォートの間を ASCII エンコードしたのテキストを返します。 +バックスラッシュ ('\\') 文字は C プログラムのように特別扱いされます: +すなわち '\\t' はタブを、'\\r' は復改を、'\\n' は改行を、'\\b' はベルを +意味します。 +8 進数値は '\\nnn' で指定可能であり、nnn は 0 以上 0377 以下の 8 進数値です。 +16 進数値は '\\xnn' で指定可能であり、nn は 0 以上 0xff 以下の 16 進数値です。 +.\" 値の範囲の誤りについては、Murray 経由でレポート済 +.\" horikawa@jp.FreeBSD.org 2002/05/01 +.RE +.PP +.I colon-separated hexadecimal list +.PP +.RS 0.25i +コロンで区切られた 16 進数のオクテット値のリストを、 +データ式として指定可能です。 +.RE +.PP +.B concat (\fIdata-expr1\fB, ..., \fIdata-exprN\fB)\fR +.RS 0.25i +式が評価され、各評価結果がサブ式の順番に連結されます。 +サブ式のいずれかの評価結果が空になる場合、連結の結果は空になります。 +.RE +.PP +.B reverse (\fInumeric-expr1\fB, \fIdata-expr2\fB)\fR +.RS 0.25i +2 個の式が評価され、データ式の評価結果がその場で反転されます。 +反転は、数値式で指定される大きさの単位で行われます。 +例えば、数値式の評価結果が 4 の場合で、 +データ式の評価結果が 12 バイトになる場合、 +reverse 式の評価結果は、次のような 12 バイトのデータになります。 +すなわち、入力の最後の 4 バイト、真中の 4バイト、最初の 4 バイトの +順になります。 +.RE +.PP +.B leased-address +.RS 0.25i +いかなる文脈においても、 +要求処理対象となっているクライアントに IP アドレスが割り当て済の場合、 +その IP アドレスが返されます。 +.RE +.PP +.B binary-to-ascii (\fInumeric-expr1\fB, \fInumeric-expr2\fB, +.B \fIdata-expr1\fB,\fR \fIdata-expr2\fB)\fR +.RS 0.25i +data-expr2 の評価結果をテキストストリングに変換します。 +このテキストストリング中では、 +data-expr2 の評価結果の各要素が、1 個の数値になります。 +各数値は、それぞれ、data-expr1 の評価結果によって区切られます。 +numeric-expr1 の評価結果は、基数 (2 から 16) であり、 +この基数に数値が変換されます。 +numeric-expr2 の評価結果は、各数値のビット幅であり、 +8, 16, 32 のいずれかです。 +.PP +最初の 3 個のタイプの式の例として、 +クライアントに割り当てられた IP アドレス用の +PTR レコードの名前を生成するために使用可能な式を示します +.RE +.PP +.nf + concat (binary-to-ascii (10, 8, ".", + reverse (1, leased-address)), + ".in-addr.arpa."); + +.fi +.PP +.B encode-int (\fInumeric-expr\fB, \fIwidth\fB)\fR +.RS 0.25i +数値式が評価され、指定された幅のデータストリングに +ネットワークバイト順 (最上位バイトが最初) でエンコードされます。 +数値式の評価結果が空の値になる場合、結果もまた空です。 +.RE +.\" この ".RE" が無いと、インデントが正しくないです +.\" horikawa@jp.FreeBSD.org 2002/04/29 +.PP +.B pick-first-value (\fIdata-expr1\fR [ ... \fIexpr\fRn ] \fB)\fR +.RS 0.25i +pick-first-value 関数は、任意個のデータ式を取り得ます。 +リストの先頭から各式が評価され、 +評価結果が空ではない式が見付かるまでこれが続きます。 +この式が返され、この式に後続する式は評価されません。 +すべての式の評価結果が空の場合、空の値が返されます。 +.RE +.PP +.B host-decl-name +.RS 0.25i +host-decl-name 関数は、現在要求処理対象となっているクライアントにマッチする、 +ホスト宣言の名前を返します。 +どのホスト宣言もマッチしない場合、結果は空になります。 +.RE +.SH 数値式 +数値式は、評価結果が整数になる式です。 +一般に、整数の最大サイズが 32 ビット未満であると仮定すべきではありませんが、 +整数の精度が 32 ビットを越えることはあり得ます。 +.PP +.B extract-int (\fIdata-expr\fB, \fIwidth\fB)\fR +.PP +.RS 0.25i +\fBextract-int\fR オペレータは、ネットワークバイト順の整数を、 +指定したデータ式の評価結果から取り出します。 +幅は、取り出す整数のビット幅です。 +現在、サポートされている幅は 8, 16, 32 のいずれかです。 +データ式の評価結果が、指定した大きさの整数と取り出すのに +十分なビットを提供しない場合、空の値が返されます。 +.RE +.PP +.B lease-time +.PP +.RS 0.25i +現在のリースの期間です。 +すなわち、現在の時刻とリースの期限が切れる時刻との差です。 +.RE +.PP +.I number +.PP +.RS 0.25i +0 から表現可能な最大サイズの範囲の任意の数値を、数値式として指定可能です。 +.RE +.PP +.B client-state +.PP +.RS 0.25i +処理対象のクライアントの現在の状態です。 +DHCP クライアント設定ファイルにおいてのみ有用です。 +取り得る値は次の通りです: +.TP 2 +.I \(bu +Booting - DHCP クライアントは INIT 状態であり、 +IP アドレスをまだ持ちません。 +次に送信されるメッセージは DHCPDISCOVER であり、 +これはブロードキャストされます。 +.TP +.I \(bu +Reboot - DHCP クライアントは INIT-REBOOT 状態です。 +IP アドレスを持ちますがまだ使用していません。 +次に送信されるメッセージは DHCPREQUEST であり、 +これはブロードキャストされます。 +応答が何も聞こえないと、クライアントはこのアドレスにバインドし、 +BOUND 状態に遷移します。 +.TP +.I \(bu +Select - DHCP クライアントは SELECTING 状態です。 +少なくとも 1 個の DHCPOFFER メッセージは受信しましたが、 +他の DHCPOFFER メッセージを他のサーバから受け取るかどうか待っています。 +SELECTING 状態ではメッセージは送信されません。 +.TP +.I \(bu +Request - DHCP クライアントは REQUESTING 状態です。 +少なくとも 1 個の DHCPOFFER メッセージを受信し、 +そのうちのどれを要求するか選択しました。 +次に送信されるメッセージは DHCPREQUEST メッセージであり、 +これはブロードキャストされます。 +.TP +.I \(bu +Bound - DHCP クライアントは BOUND 状態です。 +IP アドレスを所有しています。 +この状態ではメッセージは送信されません。 +.TP +.I \(bu +Renew - DHCP クライアントは RENEWING 状態です。 +IP アドレスを所有しており、これを更新するためにサーバに接続を試みています。 +次に送信されるメッセージは DHCPREQUEST メッセージであり、 +これはサーバに直接ユニキャストされます。 +.TP +.I \(bu +Rebind - DHCP クライアントは REBINDING 状態です。 +IP アドレスを所有しており、 +これを更新するために任意のサーバに接続を試みています。 +次に送信されるメッセージは DHCPREQUEST メッセージであり、 +これはブロードキャストされます。 +.RE +.SH 参照: ログ +ログ文を使用して、標準ログチャネルに情報を送信可能です。 +ログ文は、省略可能な priority +(\fBfatal\fR, \fBerror\fR, \fBinfo\fR, \fBdebug\fR のいずれか) と、 +データ式を取ります。 +.PP +.B log (\fIpriority\fB, \fIdata-expr\fB)\fR +.\" "\FB" は "\fB" が正しい +.\" horikawa@jp.FreeBSD.org 2002/04/29 +.PP +ログ文は、単一のデータ式引数のみ取ります。 +複数のデータ値を出力したい場合、 +\fBconcat\fR オペレータを使用してそれらを連結する必要があります。 +.RE +.SH 参照: 動的な DNS 更新 +.PP +DHCP クライアントとサーバは、 +動的にドメインネームシステムを更新する能力があります。 +設定ファイル中に、どのようにドメインネームシステムを更新して欲しいか、 +定義可能です。 +更新は RFC 2136 に従っているため、 +RFC 2136 をサポートする DNS サーバは、 +DHCP サーバからの更新を受け付け可能と思われます。 +.SH セキュリティ +TSIG および DNSSEC はまだサポートされていません。 +DHCP サーバまたはクライアントからの更新を受け付けるように +DNS サーバを設定する場合、権限の無い更新に対して +DNS サーバを晒すことになるかもしれません。 +これを避けるために今すぐできる最良の方法は、 +IP アドレスベースのパケットフィルタを使用して、 +権限の無いホストからの更新要求発行を抑止することです。 +明らかに、現状ではクライアントの更新に対するセキュリティを提供する方法は +ありません。 +このためには TSIG か DNSSEC が必要ですが、 +この DHCP 配布物にはまだ含まれていません。 +.PP +動的 DNS (DDNS) 更新は、\fBdns-update\fR 式を使用することで実行されます。 +\fBdns-update\fR 式は、ブール式であり、4 個のパラメータを取ります。 +更新に成功すると、結果は真になります。 +失敗すると、結果は偽になります。 +4 個のパラメータは、リソースレコードタイプ (RR)、 +RR の左辺、RR の右辺、レコードに適用されるべき ttl です。 +この関数の最も簡単な使用例は、dhcpd.conf ファイルの参照節にあり、 +なにが起きるか記述されています。 +この例では、複数の式が使用されて、 +\fBdns-update\fR 用の引数が作成されています。 +.PP +例の中では、最初の \fBdns-update\fR 式への 1 番目の引数は、 +A RR タイプに評価されるデータ式です。 +2 番目の引数は、DHCP host-name オプションと +ローカルドメイン、この場合 "ssd.example.net"、 +を含むテキストストリングを連結することで、構築されます。 +3 番目の引数は、クライアントに割り当てられたアドレスを、 +32 ビットの数値から各バイトを "." で区切った ASCII 文字列に変換することで、 +構築されます。 +4 番目の引数 TTL は、リースの残り時間です +(これは本当は正しくありません。 +なぜなら DNS サーバは、要求に対していつもこの TTL 値を出力してしまうからです。 +これは、リース期限切れの数秒前であってもです)。 +.PP +最初の \fBdns-update\fR 文が成功すると、 +引き続いて 2 番目の更新により PTR RR がインストールされます。 +PTR レコードのインストールは、A RR のインストールと同様ですが、 +レコードの左辺はリースされたアドレスを逆にして ".in-addr.arpa" と +結合されたものです。 +右辺は、アドレスのリース提供先クライアントの、完全な形でのドメイン名です。 +.SH 関連項目 +dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5), dhcp-eval(5), dhcpd(8), +dhclient(8), RFC2132, RFC2131 +.SH 作者 +Internet Systems Consortium DHCP Distribution +は、Vixie Labs との契約のもとで、Ted Lemon が記述しました。 +本プロジェクトの資金は、Internet Systems Consortium が提供しました。 +Internet Systems Consortium に関する情報は、 +.B https://www.isc.org +にあります。 diff --git a/doc/ja_JP.eucJP/dhcp-options.5 b/doc/ja_JP.eucJP/dhcp-options.5 new file mode 100644 index 0000000..1fe09d7 --- /dev/null +++ b/doc/ja_JP.eucJP/dhcp-options.5 @@ -0,0 +1,1582 @@ +.\" $Id: dhcp-options.5,v 1.3.24.3 2011/01/20 23:46:46 sar Exp $ +.\" +.\" Copyright (c) 2009-2010 by Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (c) 2004 by Internet Systems Consortium, Inc. ("ISC") +.\" Copyright (c) 1996-2003 by Internet Software Consortium +.\" +.\" 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. +.\" +.\" 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. +.\" +.\" Internet Systems Consortium, Inc. +.\" 950 Charter Street +.\" Redwood City, CA 94063 +.\" <info@isc.org> +.\" https://www.isc.org/ +.\" +.\" This software has been written for Internet Systems Consortium +.\" by Ted Lemon in cooperation with Vixie Enterprises and Nominum, Inc. +.\" To learn more about Internet Systems Consortium, see +.\" ``https://www.isc.org/''. To learn more about Vixie Enterprises, +.\" see ``http://www.vix.com''. To learn more about Nominum, Inc., see +.\" ``http://www.nominum.com''. +.\" +.\" %FreeBSD: src/contrib/isc-dhcp/common/dhcp-options.5,v 1.2.2.1 2002/04/11 10:16:46 murray Exp % +.\" $FreeBSD: doc/ja_JP.eucJP/man/man5/dhcp-options.5,v 1.11 2002/05/21 03:51:52 horikawa Exp $ +.\" WORD: Dynamic Host Configuration Protocol 動的ホスト構成プロトコル +.\" WORD: Path MTU Discovery パス MTU 探索 +.\" WORD: Router Discovery ルータ探索 +.\" WORD: Router Solicitation ルータ要請 +.\" WORD: Mask Discovery マスク探索 +.\" +.TH dhcp-options 5 +.SH 名称 +dhcp-options - 動的ホスト構成プロトコルのオプション +.SH 解説 +動的ホスト構成プロトコル (DHCP: Dynamic Host Configuration Protocol) を +使用することにより、クライアントは DHCP サーバから、ネットワーク設定や +ネットワーク上で利用可能な様々なサービスについて記述している +.B オプション +を受け取ることができます。 +.B dhcpd(8) +や +.B dhclient(8) +を設定するときに、しばしばオプションを宣言する必要があるでしょう。 +ここでは、オプションを宣言する文法、 +そして宣言可能なオプションの名前と書式を文書化しています。 +.SH リファレンス: オプション文 +.PP +DHCP \fIoption\fR 文は、常にキーワード \fIoption\fR で開始し、 +単一のオプション名が続き、オプションデータが続きます。 +オプションの名前とデータの書式は後述します。 +すべての DHCP オプションを網羅的に指定する必要はなく、 +クライアントに必要なオプションのみを指定します。 +.PP +オプションデータには、次のように様々な書式があります: +.PP +.B ip-address +データタイプは、明示的な IP アドレス (例えば 239.254.197.10) または +ドメイン名 (例えば haagen.isc.org) のどちらでも指定可能です。 +ドメイン名で指定する場合、 +そのドメイン名を解決すると単一の IP アドレスになるようにしてください。 +.PP +.B int32 +データタイプは符号付き 32 ビット整数を指定します。 +.B uint32 +データタイプは符号無し 32 ビット整数を指定します。 +.B int16 +および +.B uint16 +のデータタイプは、符号付きおよび符号無しの 16 ビット整数を指定します。 +.B int8 +および +.B uint8 +のデータタイプは、符号付きおよび符号無しの 8 ビット整数を指定します。 +符号無し 8 ビット整数は、オクテットと呼ばれることもあります。 +.PP +.B text +データタイプは NVT ASCII 文字列を指定します。 +文字列はダブルクォートで括る必要があります。 +例えば root-path オプションを指定する文法は、次のようになります。 +.nf +.sp 1 +option root-path "10.0.1.4:/var/tmp/rootfs"; +.fi +.PP +.B domain-name +データタイプはドメイン名を指定します。 +文字列をダブルクォートで括っていけません。 +このデータタイプは、他の既存の DHCP オプションには使われません。 +ドメイン名は、text オプションであるかのように保持されます。 +.\" text データタイプであるかのように? +.\" metal +.PP +.B flag +データタイプはブール値を指定します。 +ブール値は true または false のいずれかです +(もしくは、on または off の方が分かりやすければ、こちらでもかまいません)。 +.PP +.B string +データタイプは、ダブルクォートで括られる NVT ASCII 文字列か、 +コロン区切りの 16 進数で指定されるオクテットの連続のいずれかを指定します。 +例えば次のようになります: +.nf +.sp 1 + option dhcp-client-identifier "CLIENT-FOO"; +もしくは + option dhcp-client-identifier 43:4c:49:45:54:2d:46:4f:4f; +.fi +.SH 式を用いたオプション値の設定 +.\" metal +クライアントが送出するいくつかの値を、DHCP オプションの値を設定するのに +使えると便利なことがあります。 +これをするには式の評価が利用できます。 +.B dhcp-eval(5) +マニュアルページに式の書き方が述べられています。 +評価の結果をオプションに代入するには、オプションを次のように定義します: +.nf +.sp 1 + \fBoption \fImy-option \fB= \fIexpression \fB;\fR +.fi +.PP +例えば次のようにします: +.nf +.sp 1 + option hostname = binary-to-ascii (16, 8, "-", + substring (hardware, 1, 6)); +.fi +.SH 標準 DHCP オプション +次に示す様々なオプションに関する記述は、 +DHCP オプションに関する最新の IETF ドラフト文書からのものです。 +名前が掲載されていないオプションは、まだ実装されていないかもしれませんが、 +設定ファイルに定義することで、そのようなオプションを使えるかもしれません。 +詳しくは、この先の「新規オプションの定義」から続く記述を参照してください。 +.PP +ここに記述されているオプションのうちのいくつかは、DHCP サーバもしくは +クライアントによって自動的に生成されるもので、ユーザには設定できません。 +そのようなオプションの値は、受信側の DHCP プロトコルエージェント +(サーバもしくはクライアント) の設定ファイル中の、例えば条件式などで +使われます。 +しかしこのオプションの値は、送信側のエージェントの設定ファイル中では +使われることはありません。 +というのも、その値は、設定ファイルが処理された後に決定されるからです。 +以降の記述において、そのようなオプションには +「ユーザが設定することはできません」と記されます。 +.PP +標準オプションを示します: +.PP +.B option \fBall-subnets-local\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントが接続されている IP ネットワークの全サブネットが +使用する MTU が、クライアントが直接接続されているサブネットの MTU と +同じであると、クライアントが仮定してよいかを指定します。 +値 true は、全サブネットは同一の MTU であることを意味します。 +値 false は、直接接続されているネットワークのサブネットには、より小さな MTU を +持つものがあると、クライアントが仮定すべきであることを意味します。 +.RE +.PP +.B option \fBarp-cache-timeout\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、ARP キャッシュエントリのタイムアウトを秒数で指定します。 +.RE +.PP +.B option \fBbootfile-name\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、起動ファイルを指定するために使用します。 +クライアントによってサポートされている場合、 +これは \fBfilename\fR 宣言と同じ効果を持ちます。 +BOOTP クライアントで、このオプションをサポートしているものは少ないでしょう。 +DHCP クライアントによってはサポートするものがあり、 +実際必須としているものがあります。 +.RE +.PP +.B option \fBboot-size\fR \fIuint16\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアント用のデフォルトのブートイメージの長さを、 +512 オクテットブロック数で指定します。 +.RE +.PP +.B option \fBbroadcast-address\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントのサブネットで使用されている +ブロードキャストアドレスを指定します。 +正当なブロードキャストアドレスの値は、STD 3 (RFC1122) の 3.2.1.3 節に +規定されています。 +.RE +.PP +.B option \fBcookie-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +クッキーサーバオプションは、クライアントが利用可能な +RFC 865 クッキーサーバのリストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBdefault-ip-ttl\fR \fIuint8;\fR +.RS 0.25i +.PP +本オプションは、クライアントがデータグラムを送出するときに使用すべき、 +デフォルトの生存時間 (TTL) を指定します。 +.RE +.PP +.B option \fBdefault-tcp-ttl\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントが TCP セグメントを送出するときに使用すべき、 +デフォルトの TTL を指定します。 +最小値は 1 です。 +.RE +.PP +.B option \fBdhcp-client-identifier\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +本オプションを使って、ホスト宣言中で DHCP クライアント識別子を +指定することができます。 +このクライアント識別子で照合を行うことで、 +dhcpd はそのホストのレコードを発見することができます。 +.PP +.\" metal +DHCP クライアントの中には、ASCII テキストによってクライアント識別子が +設定された場合、その ASCII テキストの先頭に 0 をつけるものがあることに +注意してください。 +その場合、 +.nf + + option dhcp-client-identifier "foo"; + +ではなく、以下のように記述する必要があるでしょう。 + + option dhcp-client-identifier "\\0foo"; +.fi +.RE +.PP +.B option \fBdhcp-lease-time\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、クライアント要求 (DHCPDISCOVER または DHCPREQUEST) の中で、 +クライアントが IP アドレスのリース時間を要求するために使用されます。 +またサーバ応答 (DHCPOFFER) の中で、DHCP サーバが提示したいリース時間を +指定するのにも、このオプションは使われます。 +.PP +本オプションは、サーバではユーザが直接設定することはできません。 +.B dhcpd.conf(5) +の \fImax-lease-time\fR と \fidefault-lease-time\fR サーバオプションを +参照してください。 +.RE +.PP +.B option \fBdhcp-max-message-size\fR \fIuint16\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、クライアントから送出された場合、サーバがクライアントに +送出するすべての応答の最大サイズを指定します。 +サーバで設定された場合、クライアントが dhcp-max-message-size オプションを +送信してこなかった際に、このサーバで設定された値が使用されます。 +これは、BOOTP 応答でも DHCP 応答と同様に動作します。 +.RE +.PP +.B option \fBdhcp-message\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、障害が起きた時に、DHCP サーバが DHCPNAK メッセージ中で +DHCP クライアントへエラーメッセージを提供するのに使用します。 +またクライアントが、提示されたパラメータを拒否した理由を示すために、 +DHCPDECLINE メッセージ中で本オプションを使うこともあります。 +.PP +本オプションは、ユーザが設定することはできません。 +.RE +.PP +.B option \fBdhcp-message-type\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、クライアントとサーバの両者から送出され、 +DHCP パケットが含んでいる DHCP メッセージのタイプを指定します。 +本オプションが取り得る値は、以下のとおりです (RFC2132 よりそのまま抜粋)。 +.PP +.nf + 1 DHCPDISCOVER + 2 DHCPOFFER + 3 DHCPREQUEST + 4 DHCPDECLINE + 5 DHCPACK + 6 DHCPNAK + 7 DHCPRELEASE + 8 DHCPINFORM +.fi +.PP +本オプションは、ユーザが設定することはできません。 +.PP +.RE +.B option \fBdhcp-option-overload\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、DHCP 'sname' もしくは 'file' フィールドが、 +DHCP オプションを保持するために詰め込み過ぎになっていることを +示すのに使われます。 +DHCP サーバは、返却されたパラメータが、オプションに通常割り当てられた +空間を超過した場合、本オプションを挿入します。 +.PP +本オプションが存在した場合、クライアントは、標準のオプションフィールドの +解釈が終了した後、指定された付加フィールドの解釈を行います。 +.PP +本オプションの正当な値は、以下の通りです: +.PP +.nf + 1 'file' フィールドが、オプション保持に使用されてます + 2 'sname' フィールドが、オプション保持に使用されてます + 3 両方のフィールドが、オプション保持に使用されてます +.fi +.PP +本オプションは、ユーザが設定することはできません。 +.PP +.RE +.PP +.B option \fBdhcp-parameter-request-list\fR \fIuint16\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、クライアントから送出された場合、 +サーバに返答を希望するオプションをクライアントが指定します。 +通常 ISC DHCP クライアントでは、\fIrequest\fR 文を用いて行われます。 +本オプションがクライアントから指定されなかった場合、通常 DHCP サーバは、 +スコープ内で有効かつ応答に収まるすべてのオプションを返します。 +本オプションがサーバ上で指定された場合、サーバはその指定されたオプションを +返します。 +これは、クライアントが要求しなかったオプションを、クライアントに +強制するのに使用されます。 +また、通常サーバが返すオプションのセットをさらに制限する必要のある +クライアントに対して、DHCP サーバの応答を調整するのにも使用されます。 +.RE +.PP +.B option \fBdhcp-rebinding-time\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、クライアントがアドレスを取得してから REBINDING 状態に +移行するまでの時間を秒数で指定します。 +.PP +本オプションは、ユーザが設定することはできません。 +.PP +.RE +.PP +.B option \fBdhcp-renewal-time\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、クライアントがアドレスを取得してから RENEWING 状態に +移行するまでの時間を秒数で指定します。 +.PP +本オプションは、ユーザが設定することはできません。 +.PP +.RE +.PP +.B option \fBdhcp-requested-address\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、クライアントが、DHCPDISCOVER 内で特定の IP アドレスが +割り当てられることを要求するのに使用されます。 +.PP +本オプションは、ユーザが設定することはできません。 +.PP +.RE +.PP +.B option \fBdhcp-server-identifier\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、DHCPOFFER と DHCPREQUEST メッセージ中で使用され、 +また DHCPACK と DHCPNAK メッセージ中にも含まれることがあります。 +DHCP サーバは、クライアントが (訳注: 複数サーバからの) リースの提示を +区別できるよう、DHCPOFFER に本オプションを含めます。 +DHCP クライアントは、DHCP サーバへユニキャストするすべての DHCP メッセージの +宛先アドレスとして 'server identifier' フィールドの内容を使用します。 +また DHCP クライアントは、DHCPREQUEST メッセージ中に本オプションを含め、 +複数のリースの提示のどれを受け入れたかを示します。 +.PP +本オプションの値は、サーバの IP アドレスです。 +.PP +本オプションは、ユーザが直接設定することはできません。 +.B \fIdhcpd.conf(5) +の \fIserver-identifier\fR サーバオプションを参照してください。 +.PP +.RE +.PP +.B option \fBdomain-name\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、ドメインネームシステムを使用してホスト名を解決するときに +クライアントが使用すべきドメイン名を指定します。 +.RE +.PP +.B option \fBdomain-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +domain-name-servers オプションは、クライアントが利用可能な +ドメインネームシステム (STD 13, RFC 1035) のネームサーバのリストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBextensions-path\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、追加オプションを含むファイルのファイル名を指定します。 +この追加オプションは、RFC2132 で規定されている DHCP オプションの書式に沿って +解釈されます。 +.RE +.PP +.B option \fBfinger-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +Finger サーバオプションは、クライアントが利用可能な Finger のリストを +指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBfont-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントが利用可能な X Window System フォントサーバを +指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBhost-name\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントの名前を指定します。 +この名前は、ローカルドメイン名に修飾されていても、いなくてもかまいせん +(ドメイン名を指定するには、domain-name オプションの使用をお勧めします)。 +文字集合の制約については RFC 1035 を参照してください。 +クライアントマシンのホスト名が設定されていない場合 (すなわち +.B rc.conf(5) +で空文字列に設定されている場合) のみ、 +.B dhclient-script(8) +が本オプションを尊重します。 +.RE +.PP +.B option \fBieee802-3-encapsulation\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、インタフェースがイーサネットである場合に、 +クライアントがイーサネットバージョン 2 (RFC 894) と +IEEE 802.3 (RFC 1042) のどちらのカプセル化を使用すべきかを指定します。 +値 false は、クライアントが RFC 894 のカプセル化を使用すべきであることを +意味します。 +値 true は、クライアントが RFC 1042 のカプセル化を使用すべきであることを +意味します。 +.RE +.PP +.B option \fBien116-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]; +.RS 0.25i +.PP +ien116-name-servers オプションは、 +クライアントが利用可能な IEN 116 ネームサーバのリストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBimpress-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +impress-server オプションは、 +クライアントが利用可能な Imagen Impress サーバのリストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBinterface-mtu\fR \fIuint16\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、このインタフェースに対して使用する MTU を指定します。 +MTU に対する最小の正当値は 68 です。 +.RE +.PP +.B option \fBip-forwarding\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントが、パケットを転送するように +自分の IP 層を設定すべきかを指定します。 +値 false は IP 転送を無効にすることを意味し、 +値 true は IP 転送を有効にすることを意味します。 +.RE +.PP +.B option \fBirc-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +IRC サーバオプションは、クライアントが利用可能な IRC のリストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBlog-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +log-server オプションは、クライアントが利用可能な MIT-LCS UDP ログサーバの +リストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBlpr-servers\fR \fIip-address \fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +LPR サーバオプションは、 +クライアントが利用可能な RFC 1179 ラインプリンタサーバのリストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBmask-supplier\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、ICMP を使用したサブネットマスク要求に対して、 +クライアントが応答すべきかを指定します。 +値 false は、クライアントが応答すべきでないことを意味します。 +値 true は、クライアントが応答すべきであることを意味します。 +.RE +.PP +.B option \fBmax-dgram-reassembly\fR \fIuint16\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントが再組み立ての準備をすべき +最大データグラムサイズを指定します。 +最小の正当値は 576 です。 +.\" The minimum value legal value is 576. +.\" The minimum legal value is 576. かな (horikawa@jp.freebsd.org 19990404) +.RE +.PP +.B option \fBmerit-dump\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントがクラッシュするときの +クライアントのコアイメージがダンプされるファイルのパス名を指定します。 +パスの書式は、NVT ASCII 文字集合の文字からなる文字列です。 +.RE +.PP +.B option \fBmobile-ip-home-agent\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントが利用可能なモバイル IP ホームエージェントの +IP アドレスのリストを指定します。 +エージェントは、優先されるものから順にリストしてください。 +ただし、通常エージェントは 1 つでしょう。 +.RE +.PP +.B option \fBnds-context\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +nds-context オプションは、NDS クライアントのための最初の +NetWare ディレクトリサービスの名前を指定します。 +.RE +.PP +.B option \fBnds-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +.\" metal +nds-servers オプションは、NDS サーバの IP アドレスのリストを指定します。 +.RE +.PP +.B option \fBnds-tree-name\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +nds-tree-name オプションは、NDS クライアントが使用すべき NDS ツリーの +名前を指定します。 +.RE +.PP +.B option \fBnetbios-dd-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +NetBIOS データグラム配布サーバ (NBDD) オプションは、 +RFC 1001/1002 の NBDD サーバのリストを、優先されるものから順に指定します。 +.RE +.PP +.B option \fBnetbios-name-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR...]\fB;\fR +.RS 0.25i +.PP +NetBIOS ネームサーバ (NBNS) オプションは、 RFC 1001/1002 の +NBNS ネームサーバのリストを、優先されるものから順に指定します。 +現在では、NetBIOS ネームサービスは WINS と呼ばれることの方が多いです。 +netbios-name-servers オプションを使用して、WINS サーバを指定可能です。 +.RE +.PP +.B option \fBnetbios-node-type\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +NetBIOS ノードタイプオプションは、 +設定可能な NetBIOS over TCP/IP クライアントを、 +RFC 1001/1002 に記述されているように設定します。 +値は単一のオクテットとして指定され、クライアントタイプを意味します。 +.PP +使用可能なノードタイプは次の通りです: +.PP +.TP 5 +.I 1 +B ノード: ブロードキャスト - WINS 無し +.TP +.I 2 +P ノード: ピア - WINS のみ +.TP +.I 4 +M ノード: ミックス - ブロードキャスト後に WINS +.TP +.I 8 +H ノード: ハイブリッド - WINS 後にブロードキャスト +.RE +.PP +.B option \fBnetbios-scope\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +NetBIOS スコープオプションは、RFC 1001/1002 に規定されているように、 +クライアントの NetBIOS over TCP/IP スコープパラメータを指定します。 +文字集合の制約については RFC1001, RFC1002, RFC1035 を参照してください。 +.RE +.PP +.B option \fBnis-domain\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントの NIS (Sun Network Information Services) +ドメインを指定します。 +ドメインの書式は、NVT ASCII 文字集合の文字からなる文字列です。 +.RE +.PP +.B option \fBnis-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントが利用可能な NIS サーバを示す IP アドレスの +リストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBnisplus-domain\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントの NIS+ ドメインの名前を指定します。 +ドメインの書式は、NVT ASCII 文字集合の文字からなる文字列です。 +.RE +.PP +.B option \fBnisplus-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントが利用可能な NIS+ サーバを示す IP アドレスの +リストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBnntp-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +NNTP サーバオプションは、クライアントが利用可能な NNTP のリストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBnon-local-source-routing\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、非ローカルな指定経路 (non-local source route) を持つ +データグラムを転送するように、クライアントが自分の IP 層を設定すべきかを +指定します (本項目については [4] の 3.3.5 節を参照してください)。 +値 false はそのようなデータグラムの転送を許可しないことを意味し、 +値 true は転送許可を意味します。 +.RE +.PP +.B option \fBntp-servers\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントが利用可能な NTP (RFC 1035) サーバを示す +IP アドレスを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBnwip-domain\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +NetWare/IP クライアントが使用すべき NetWare/IP ドメインの名前です。 +.RE +.PP +.B option \fBnwip-suboptions\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +NetWare/IP クライアント用のサブオプションのシーケンスです。 +詳しくは RFC2242 を参照してください。 +通常、本オプションは特定の NetWare/IP サブオプションを指定することで +設定されます。 +さらなる情報は「NetWare/IP サブオプション」の章を参照してください。 +.RE +.PP +.B option \fBpath-mtu-aging-timeout\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、RFC 1191 で定義される機構で発見されたパス MTU 値の +エージングに使用するタイムアウト (秒単位) を指定します。 +.RE +.PP +.B option \fBpath-mtu-plateau-table\fR \fIuint16\fR [\fB,\fR \fIuint16\fR... +]\fB;\fR +.RS 0.25i +.PP +本オプションは、RFC 1191 で定義されるパス MTU 探索 (Path MTU Discovery) +実施時に使用される MTU のサイズの表を指定します。 +表の書式は、最小から順に最大までの、16 ビット符号無し整数のリストです。 +最小 MTU は 68 より小さくてはなりません。 +.RE +.PP +.B option \fBperform-mask-discovery\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントが ICMP を使用してサブネットマスク探索を +実施すべきかを指定します。 +値 false は、クライアントがマスク探索を実施すべきでないことを意味します。 +値 true は、クライアントがマスク探索を実施すべきであることを意味します。 +.RE +.PP +.nf +.B option \fBpolicy-filter\fR \fIip-address ip-address\fR + [\fB,\fR \fIip-address ip-address\fR...]\fB;\fR +.RE +.fi +.RS 0.25i +.PP +本オプションは、非ローカルな指定経路制御に対するポリシフィルタを指定します。 +フィルタは、IP アドレスとマスクの組のリストからなり、 +到着する指定経路制御されたデータグラム用のフィルタとなる +宛先/マスクの組を指定します。 +.PP +次ホップアドレスがフィルタのいずれにも適合しない指定経路制御された +データグラムは、クライアントが破棄すべきです。 +.PP +さらなる情報は STD 3 (RFC1122) を参照してください。 +.RE +.PP +.B option \fBpop-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +POP3 サーバオプションは、クライアントが利用可能な POP3 のリストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBresource-location-servers\fR \fIip-address\fR + [\fB, \fR\fIip-address\fR...]\fB;\fR +.fi +.RS 0.25i +.PP +本オプションは、クライアントが利用可能な +RFC 887 リソースロケーションサーバのリストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBroot-path\fR \fItext\fB;\fR\fR +.RS 0.25i +.PP +本オプションは、クライアントのルートディスクが含まれるパス名を指定します。 +パスの書式は、NVT ASCII 文字集合の文字からなる文字列です。 +.RE +.PP +.B option \fBrouter-discovery\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、RFC 1256 で定義されるルータ探索 (Router Discovery) 機構を +使用して、ルータを要請すべきかを指定します。 +値 false は、クライアントがルータ探索を実施すべきでないことを意味します。 +値 true は、クライアントはルータ探索を実施すべきであることを意味します。 +.RE +.PP +.B option \fBrouter-solicitation-address\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントのルータ要請の送出先アドレスを指定します。 +.RE +.PP +.B option routers \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +routers オプションは、クライアントのサブネット上にあるルータの +IP アドレスのリストを指定します。 +ルータは、優先されるものから順にリストしてください。 +.RE +.PP +.B option slp-directory-agent \fIboolean ip-address +[\fB,\fR \fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、2 つの項目を指定します: +1 つ以上のサービスロケーションプロトコルディレクトリエージェント +(Service Location Protocol Directory Agent) の IP アドレスと、 +これらのアドレスの使用が強制的かどうかです。 +最初のブール値が true であれば、SLP エージェントは、ただ与えられた +IP アドレスのみを使用すべきです。 +値が false であれば、SLP エージェントは、SLP エージェントの +能動的もしくは受動的なマルチキャスト探索を追加で行っても構いません +(詳しくは RFC2165 を参照してください)。 +.PP +本オプションと slp-service-scope オプションにおいて、 +「SLP エージェント」とは、DHCP プロトコルを用いて設定されたマシン上で +動作しているサービスロケーションプロトコルエージェントを指していることに +注意してください。 +.PP +また、いくつかの企業は SLP を NDS と呼んでいることも気を付けてください。 +もし NDS ディレクトリエージェントがあり、そのアドレスを設定する必要が +ある場合は、 slp-directory-agent オプションが利用できるはずです。 +.RE +.PP +.B option slp-service-scope \fIboolean text\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +サービスロケーションプロトコルのサービススコープオプションは、 +2 つの項目を指定します: +SLP 用のサービススコープのリストと、このリストの使用が強制的かどうかです。 +最初のブール値が true であれば、SLP エージェントは、本オプションにより +提供されるスコープのリストのみを使用すべきです。 +そうでなければ、このオプションで提供されるリストに優先して、 +それぞれの固有的の設定を使っても構いません。 +.PP +text 文字列は、SLP エージェントが使用すべきスコープの、コンマ区切りの +リストとしてください。 +これは省略可能で、その場合 SLP エージェントは、自分が知っている +すべてのディレクトリエージェントのスコープの一括リストを使います。 +.RE +.PP +.B option \fBsmtp-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +SMTP サーバオプションは、クライアントが利用可能な SMTP サーバのリストを +指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.nf +.B option \fBstatic-routes\fR \fIip-address ip-address\fR + [\fB,\fR \fIip-address ip-address\fR...]\fB;\fR +.fi +.RS 0.25i +.PP +本オプションは、クライアントが経路キャッシュに組み込むべき +静的経路のリストを指定します。 +同じ宛先に対して複数の経路が指定されている場合は、 +優先度が低くなる順序でリストされます。 +.PP +経路は IP アドレスの組のリストからなります。 +最初のアドレスは宛先アドレスであり、 +2 番目のアドレスはその宛先に対するルータのアドレスです。 +.PP +デフォルト経路 (0.0.0.0) は、静的経路に対しては不正な宛先です。 +デフォルト経路を指定するには、 +.B routers +オプションを使用してください。 +また、本オプションは、クラスレスな IP 経路制御を意図したものでは +ないことに注意して下さい。 +これはサブネットマスクを含んでいません。 +現在、クラスレスな IP 経路制御は、もっとも広く展開されている +経路制御標準なので、本オプションは実質的に無意味です。 +そして、マイクロソフト DHCP クライアントをはじめとするよく知られた +DHCP クライアントには実装されていません。 +.RE +.PP +.nf +.B option \fBstreettalk-directory-assistance-server\fR \fIip-address\fR + [\fB,\fR \fIip-address\fR...]\fB;\fR +.fi +.RS 0.25i +.PP +StreetTalk Directory Assistance (STDA) サーバオプションは、 +クライアントが利用可能な STDA のリストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBstreettalk-server\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +StreetTalk サーバオプションは、 +クライアントが利用可能な StreetTalk のリストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option subnet-mask \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +サブネットマスクオプションは、RFC 950 に従って、 +クライアントのサブネットマスクを指定します。 +スコープ中のどこにもサブネットマスクオプションが指定されていない場合、 +最終手段として、dhcpd は、アドレスを割り当てようとしている +ネットワークのサブネット宣言から、サブネットマスクを使用します。 +しかし、アドレスを割り当てようとしているネットワークのスコープ中の +.I どのような +サブネットマスクオプション宣言であっても、 +サブネット宣言で指定されたサブネットマスクに優先します。 +.RE +.PP +.B option \fBsubnet-selection\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +(要求が出されたサブネットにつながれたリレーサーバのアドレスに基づいて) +通常選択されるであろうものではないサブネットのアドレスが必要な場合、 +クライアントが送出します。 +RFC3011 を参照してください。 +このサーバにおいて使われるオプションナンバは 118 です。 +このナンバは以前からずっと定義されていたナンバではなく、 +違う値を使用するクライアントも存在することに注意してください。 +このオプションの使用は少々実験的であると考えるべきでしょう! +.PP +本オプションは、サーバではユーザが設定することはできません。 +.PP +.RE +.PP +.B option \fBswap-server\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントのスワップサーバの IP アドレスを指定します。 +.RE +.PP +.B option \fBtcp-keepalive-garbage\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、古い実装との互換性のために、ゴミのオクテットと一緒に、 +TCP キープアライブメッセージをクライアントが送るべきかを指定します。 +値 false は、ゴミのオクテットを送るべきでないことを意味します。 +値 true は、ゴミのオクテットを送るべきであることを意味します。 +.RE +.PP +.B option \fBtcp-keepalive-interval\fR \fIuint32\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントの TCP がキープアライブ (keepalive) +メッセージを TCP 接続上に送信する前に待つべき間隔 (秒単位) を指定します。 +時間は 32 ビット符号無し整数で指定します。 +値 0 は、アプリケーションが明示的に要求しない限り、クライアントが +接続上にキープアライブメッセージを生成すべきでないことを意味します。 +.RE +.PP +.B option \fBtftp-server-name\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +本オプションは TFTP サーバを指定するのに使用され、クライアントが +サポートしている場合には \fBserver-name\fR 宣言と同じ効果を持ちます。 +BOOTP クライアントは、本オプションをサポートしないでしょう。 +DHCP クライアントによってはサポートしているものがあり、 +実際必須としているものがあります。 +.RE +.PP +.B option time-offset \fIint32\fR\fB;\fR +.RS 0.25i +.PP +time-offset オプションは、協定世界時 (UTC) を基点として、 +クライアントのサブネットのオフセットを秒で指定します。 +.RE +.PP +.B option time-servers \fIip-address\fR [, \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +time-server オプションは、クライアントが利用可能な RFC 868 時刻サーバの +リストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBtrailer-encapsulation\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +本オプションは、ARP プロトコル使用時に、クライアントがトレイラ使用の +ネゴシエーション (RFC 893 [14]) をすべきかを指定します。 +値 false は、クライアントがトレイラ使用を試みるべきでないと意味します。 +値 true は、クライアントがトレイラ使用を試みるべきであると意味します。 +.RE +.PP +.B option \fBuap-servers\fR \fItext\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、ユーザ認証プロトコル (UAP) に包まれた認証要求を +処理する能力のあるユーザ認証サービスをそれぞれ指している +URL のリストを指定します。 +UAP サーバは HTTP 1.1 接続も SSLv3 接続も受け取ることができます。 +リストに含まれた URL にポート部分が含まれてない場合は、 +通常のデフォルトポートが仮定されます +(つまり http には 80 番、https には 443 番)。 +リストに含まれた URL にパスの部分が含まれてない場合は、 +パスは /uap と仮定されます。 +2 つ以上の URL がこのリストに指定された場合、URL は空白で区切られます。 +.RE +.PP +.B option \fBuser-class\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、ユーザが識別情報をクライアントに指定する手段として、 +いくつかの DHCP クライアントで使われます。 +これは vendor-class-identifier オプションと同様に使われますが、 +その値は、ベンダではなく、ユーザによって指定されます。 +最近のほとんどの DHCP クライアントは、この識別子に値を指定するための +ユーザインタフェースを備えています。 +この識別子は、通常テキスト文字列です。 +.RE +.PP +.B option \fBvendor-class-identifier\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +本オプションは、ベンダタイプや、可能であれば DHCP クライアントの設定を +識別するために、いくつかの DHCP クライアントで使われます。 +この情報の内容は、ベンダ固有のバイト文字列で、標準では規定されていません。 +クライアントが送出するベンダクラス識別子を確認するには、 +以下の設定を DHCP サーバ設定ファイルに加えてください: +.nf +.PP +set vendor-class option vendor-class-identifier; +.fi +.PP +この設定は、DHCP サーバのリースデータベースファイル中の、 +以下のような set 文を持つ vendor-class-identifier オプションを +送ってくるクライアントすべてのエントリに作用します。 +.nf +.PP +set vendor-class "SUNW.Ultra-5_10"; +.fi +.PP +vendor-class-identifier オプションは、通常 DHCP Server によって、 +.B vendor-encapsulated-options +オプション中で返されるオプションを決定するのに使われます。 +さらなる情報は、dhcpd.conf マニュアルページの VENDOR ENCAPSULATED OPTIONS の +章を参照してください。 +.RE +.PP +.B option \fBvendor-encapsulated-options\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +.\" metal +\fBvendor-encapsulated-options\fR オプションは、1 つのベンダ固有値、 +もしくは 1 つまたはそれ以上のベンダ固有サブオプションを含みます。 +本オプションは、通常 DHCP サーバの設定ファイルで設定されるものでは +ありません。 +通常は、ベンダクラスがベンダ毎に定義され、 +ベンダクラスサブオプションが定義され、そのサブオプションの値が +定義され、DHCP サーバはそれらをもとに応答を組み上げます。 +.PP +よく知られた DHCP クライアントベンダ (今のところ Microsoft Windows +2000 DHCP クライアント) 向けのいくつかのデフォルトの動作では、 +このオプションは自動的に設定されますが、その他のものに関しては、 +手動で設定しなければなりません。 +詳細は \fIdhcpd.conf\fI の VENDOR ENCAPSULATED OPTIONS の章を +参照してください。 +.RE +.PP +.B option \fBwww-server\fR \fIip-address\fR [\fB,\fR +\fIip-address\fR... ]\fB;\fR +.RS 0.25i +.PP +WWW サーバオプションは、クライアントが利用可能な WWW のリストを指定します。 +サーバは、優先されるものから順にリストしてください。 +.RE +.PP +.B option \fBx-display-manager\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... +]\fB;\fR +.RS 0.25i +.PP +本オプションは、クライアントが利用可能な X Window System +ディスプレイマネージャを実行しているシステムのリストを指定します。 +アドレスは、優先されるものから順にリストしてください。 +.RE +.SH リレーエージェント情報オプション +.\" metal +IETF ドラフト draft-ietf-dhc-agent-options-11.txt には、 +DHCP リレーエージェントが DHCP パケットを DHCP サーバに転送する際、 +DHCP パケットに付加することのできる一連のカプセル化されたオプションが +定義されています。 +サーバは、これらのオプションに基づき、アドレス割当の決定 +(や、その他の判断) を行うことができます。 +またサーバは、リレーエージェントを通して返されるどのパケットにも +これらのオプションを入れて返します。 +これによってリレーエージェントは、配送やアカウンティングなどを +行うために、これらのオプションに含まれる情報を利用できます。 +.PP +現在のドラフトには 2 つのオプションが定義されています。 +DHCP サーバでこれらのオプションを参照するには、オプション空間名 +"agent" のあとにピリオドをつけ、その後にオプション名を続けてください。 +サーバでこれらのオプションの値を定義することは、 +通常あまり有効ではありませんが、許容されています。 +これらのオプションは、クライアントではサポートされていません。 +.PP +.B option \fBagent.circuit-id\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +circuit-id サブオプションは、クライアントからサーバへの DHCP パケットを +受け取ったサーキットを示す、エージェントローカルなサーキット識別子を +エンコードしています。 +これは、DHCP 応答を適切なサーキットへと送り返せるよう、 +エージェントによって使われることを意図しています。 +現在、このオプションの書式の定義はベンダ依存となっており、 +多分このまま残されるでしょう。 +しかし将来この書式が標準化される可能性も、現在のドラフトには残されています。 +.RE +.PP +.B option \fBagent.remote-id\fR \fIstring\fR\fB;\fR +.RS 0.25i +.PP +remote-id サブオプションは、サーキットの終端のリモートホストの +情報をエンコードしています。 +これに含まれるであろう情報は、次のようなものです。 +呼出元 ID 情報、ユーザ名情報、リモート ATM アドレス、ケーブルモデム ID、 +その他の同様な情報。 +原則的には、このオプションの意味はちゃんと定義されていません。 +しかし通常、サーキットの特定のリモートエンドに対して一意であるよう +管理上保証された、なんらかのオブジェクトと考えるべきものです。 +.RE +.SH クライアント FQDN サブオプション +.\" metal +現在、インターネットドラフト draft-ietf-dhc-fqdn-option-00.txt で +定義されているクライアント FQDN オプションは、まだ標準となってはいません。 +しかしすでに十分広く利用されており、我々もこれを実装しています。 +オプションの書式が複雑なため、ここでは、単独のオプションではなく、 +サブオプション空間に実装しています。 +一般的には、本オプションは、ユーザによって設定されるものではなく、 +自動 DNS 更新システムの一部として使われるべきものです。 +.PP +.B option fqdn.no-client-update \fIflag\fB; +.RS 0.25i +.PP +本オプションがクライアントから送出された場合、これが true であれば、 +クライアントは自分の A レコードを更新しないことを意味します。 +サーバからクライアントに送出された場合は、クライアントは +自分の A レコードを更新する \fIべきではない\fR ことを意味します。 +.RE +.PP +.B option fqdn.server-update \fIflag\fB; +.RS 0.25i +.PP +本オプションがクライアントからサーバに送出された場合、 +サーバにクライアントの A レコードの更新を要求しています。 +サーバから送出された場合、サーバがクライアントの A レコードを +更新した (もしくはもうすぐ更新するところ) であることを意味します。 +.RE +.PP +.B option fqdn.encoded \fIflag\fB; +.RS 0.25i +.PP +true であった時、オプションに含まれるドメイン名が、 +ただの ASCII テキストではなく、DNS ワイヤフォーマットで +エンコードされていることを示してます。 +クライアントは、自分が FQDN オプションの DNS ワイヤフォーマットを +サポートしてない場合、通常このサブオプションを false に設定します。 +サーバは常に、クライアントが設定したのと同じ値を設定して返すべきです。 +この値が設定ファイルに設定されていた時は、\fIfqdn.fqdn\fR サブオプションを +エンコードするフォーマットを制御します。 +.RE +.PP +.B option fqdn.rcode1 \fIflag\fB; +.PP +.B option fqdn.rcode2 \fIflag\fB; +.RS 0.25i +.PP +これらのオプションはそれぞれ、A レコードと PTR レコードの更新結果を示します。 +これらは、DHCP サーバから DHCP クライアントへのみ送られます。 +これらのフィールドの値は、DNS プロトコル規格により定義されています。 +.RE +.PP +.B option fqdn.fqdn \fItext\fB; +.RS 0.25i +.PP +クライアントが使用を望むドメイン名を指定します。 +これは完全修飾されたドメイン名でも、単一のラベルでも構いません。 +もし名前に '.' 文字が含まれなければ、その名前は完全修飾されておらず、 +サーバは通常、ローカルに定義されたドメイン中のその名前を更新します。 +.RE +.PP +もしこれらのサブオプションを使用しようと思っているのであれば、 +クライアント FQDN オプションのドラフト (もしくは、標準になった時はその標準) +を参照することを強く推奨します。 +この文書は、そのドラフトに比べて大雑把で不完全であり、 +クライアント FQDN オプション規格をすでに理解している人に参照されることを +単に意図しているものです。 +.SH NetWare/IP サブオプション +.\" metal +RFC2242 は、Novell の NetWare/IP クライアント用のカプセル化された +オプションの組を定義しています。 +DHCP サーバにおいてこれらのオプションを使用するには、オプション空間名 +"nwip" の後にピリオドをつけ、その後にオプション名を続けてください。 +以下のオプションが指定できます: +.PP +.B option \fBnwip.nsq-broadcast\fR \fIflag\fR\fB;\fR +.RS 0.25i +.PP +true であった場合、クライアントは、NetWare/IP サーバの位置を +探すのに NetWare Nearest Server Query を使うべきです。 +本サブオプションが false であった場合、もしくは指定されなかった場合の +Novell クライアントの動作は規定されていません。 +.PP +.RE +.B option \fBnwip.preferred-dss\fR \fIip-address\fR [\fB,\fR \fIip-address\fR... ]\fR\fB;\fR +.RS 0.25i +.PP +本サブオプションには、5 つまでの IP アドレスのリストを指定します。 +それぞれのアドレスは、NetWare ドメイン SAP/RIP サーバ (DSS) の +IP アドレスです。 +.RE +.PP +.B option \fBnwip.nearest-nwip-server\fR \fI\fIip-address\fR + [\fB,\fR \fIip-address\fR...]\fR\fB;\fR +.RS 0.25i +.PP +本サブオプションには、5 つまでの IP アドレスのリストを指定します。 +それぞれのアドレスは、近接の NetWare IP サーバ +(Nearest NetWare IP Server) の IP アドレスです。 +.RE +.PP +.B option \fBnwip.autoretries\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +起動時に、NetWare/IP クライアントが、与えられた DSS サーバと +何回通信を試みるべきかを指定します。 +.RE +.PP +.B option \fBnwip.autoretry-secs\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +起動時に、NetWare/IP クライアントが、与えられた DSS サーバと +通信を確立する時に、リトライの間何秒待つべきかを指定します。 +.RE +.PP +.B option \fBnwip.nwip-1-1\fR \fIuint8\fR\fB;\fR +.RS 0.25i +.PP +true であった場合、NetWare/IP クライアントは NetWare/IP +バージョン 1.1 をサポートしているべきです。 +これは、クライアントが NetWare/IP バージョン 1.1 のサーバと +通信する時のみ必要です。 +.RE +.PP +.B option \fBnwip.primary-dss\fR \fIip-address\fR\fB;\fR +.RS 0.25i +.PP +NetWare/IP ドメインのプライマリドメイン SAP/RIP サービスサーバ +(DSS) の IP アドレスを指定します。 +セカンダリ DSS サーバの設定時に、NetWare/IP 管理ユーティリティは、 +この値をプライマリ DSS サーバとして使用します。 +.RE +.SH 新規オプションの定義 +.\" metal +Internet Systems Consortium DHCP クライアントとサーバは、 +新規オプションを定義する機構も提供しています。 +それぞれの DHCP オプションは、名前とコード、構造を持っています。 +名前は、使用者がオプションを参照するのに使用されます。 +コードは、DHCP サーバとクライアントがオプションを参照するのに +使用する番号です。 +構造は、オプションの内容がどのようなものかを記述しています。 +.PP +新規オプションを定義するには、他のオプションでは使われていない名前を +選ぶ必要があります。 +例えば、"host-name" と言う名前は使用できません。 +というのも、このマニュアルページに出てきたように、 +DHCP プロトコルが既に host-name オプションを定義しているからです。 +このマニュアルページに出てきていないオプション名ならば +使っても構いませんが、将来出てくるオプションと重ならないように、 +オプション名の最初に独自の文字列をつけることは、多分いい考えでしょう。 +例えば、公式の DHCP オプションには "local" で始まるものがないので、 +"local-host-name" と言う名前は、いくらか安心して定義できるでしょう。 +.PP +名前を選択したら、次はコードを選ばねばなりません。 +DHCP オプションの 128 から 256 までのコードは、 +サイトローカルオプション用として予約されているので、 +この中のコードならどれでも選ぶことができます。 +実際には、プロトコルを少々あいまいに解釈しているベンダがあり、 +128 より大きい値のオプションコードを使用しています。 +この問題を本当に回避する方法はありませんが、 +実際にはそう大きな問題を引き起こすものではないでしょう。 +.PP +オプションの構造とは、単にオプションのデータが表現されている形式です。 +現在 ISC DHCP サーバは、整数、ブール値、文字列そして IP アドレスといった、 +いくつかの単純なデータ型をサポートしており、 +また単一データ型の配列や固定順のデータ型列の配列を定義することもできます。 +.PP +新規オプションは、以下のように宣言されます: +.PP +.B option +.I new-name +.B code +.I new-code +.B = +.I definition +.B ; +.PP +.I new-name +と +.I new-code +の値は、新規オプション用にあなたが選んだものです。 +.I definition +は、オプションの構造の定義です。 +.PP +以下の単純なオプションの型定義がサポートされています: +.PP +.B ブール値 +.PP +.B option +.I new-name +.B code +.I new-code +.B = +.B boolean +.B ; +.PP +ブール型のオプションは、on または off (もしくは true か false) の値を +持つフラグです。 +ブール型の使用例は、以下のようになります: +.nf + +option use-zephyr code 180 = boolean; +option use-zephyr on; + +.fi +.B 整数 +.PP +.B option +.I new-name +.B code +.I new-code +.B = +.I sign +.B integer +.I width +.B ; +.PP +\fIsign\fR トークンは、空白、\fIunsigned\fR、\fIsigned\fR のいずれかです。 +width は 8, 16, 32 のいずれかで、整数の bit 数を示します。 +例えば、以下の 2 行は、sql-connection-max オプションの定義と +使用法を示します: +.nf + +option sql-connection-max code 192 = unsigned integer 16; +option sql-connection-max 1536; + +.fi +.B IP アドレス +.PP +.B option +.I new-name +.B code +.I new-code +.B = +.B ip-address +.B ; +.PP +IP アドレス型の構造を持つオプションは、ドメイン名もしくは +ドット区切りの 4 整数で表現されます。 +以下は、IP アドレス型の使用例です: +.nf + +option sql-server-address code 193 = ip-address; +option sql-server-address sql.example.com; + +.fi +.PP +.B テキスト +.PP +.B option +.I new-name +.B code +.I new-code +.B = +.B text +.B ; +.PP +テキスト型のオプションは、ASCII テキスト文字列をエンコードします。 +例えば: +.nf + +option sql-default-connection-name code 194 = text; +option sql-default-connection-name "PRODZA"; + +.fi +.PP +.B データ文字列 +.PP +.B option +.I new-name +.B code +.I new-code +.B = +.B string +.B ; +.PP +データ文字列型のオプションは、本質的には単なるバイトの集合体です。 +テキスト型のようにクオートされたテキストで指定されるか、 +もしくはコロン区切りの 16 進数のリストで指定されます。 +この時コロンで区切られた中身は、0 から FF の間の値でなければなりません。 +例えば: +.nf + +option sql-identification-token code 195 = string; +option sql-identification-token 17:23:19:a6:42:ea:99:7c:22; + +.fi +.PP +.B カプセル化 +.PP +.B option +.I new-name +.B code +.I new-code +.B = +.B encapsulate +.I identifier +.B ; +.PP +カプセル化型のオプションは、\fIidentifier\fR で指定された +オプション空間の中身をカプセル化します。 +現在 DHCP プロトコルに存在するカプセル化オプションの例は、 +vendor-encapsulated-options オプション、netware-suboptions オプション、 +relay-agent-information オプションなどです。 +.nf + +option space local; +option local.demo code 1 = text; +option local-encapsulation code 197 = encapsulate local; +option local.demo "demo"; + +.fi +.PP +.B 配列 +.PP +オプションは、テキスト型とデータ文字列型以外の上述のいかなるデータ型の +配列も含むことができます。 +テキスト型とデータ文字列型は、現在配列ではサポートされていません。 +配列定義の例は以下の通りです: +.nf + +option kerberos-servers code 200 = array of ip-address; +option kerberos-servers 10.20.10.1, 10.20.11.1; + +.fi +.B レコード +.PP +オプションは、データ型の列で構成されるデータ構造を含むこともできます。 +これはしばしばレコード型と呼ばれます。 +例えば: +.nf + +option contrived-001 code 201 = { boolean, integer 32, text }; +option contrived-001 on 1772 "contrivance"; + +.fi +またレコードの配列のオプションを持つこともできます。 +例えば: +.nf + +option new-static-routes code 201 = array of { + ip-address, ip-address, ip-address, integer 8 }; +option static-routes + 10.0.0.0 255.255.255.0 net-0-rtr.example.com 1, + 10.0.1.0 255.255.255.0 net-1-rtr.example.com 1, + 10.2.0.0 255.255.224.0 net-2-0-rtr.example.com 3; + +.fi +.SH ベンダカプセル化オプション +.\" metal +DHCP プロトコルには、\fB vendor-encapsulated-options\fR オプションが +定義されています。 +ベンダは、このオプションによって、ベンダ固有のオプションを +標準 DHCP オプションに含めて送出することができます。 +.B vendor-encapsulated-options +オプションの書式は、書式が規定されていない一連のバイト列、 +もしくは一連のオプション列です。 +オプション列中のそれぞれのオプションは、1 バイトのベンダ固有の +オプションコードの後に 1 バイトのデータ長、 +そしてそのデータ長で指定された大きさのデータが続いたもので構成されます +(データ長には、データ長自身やオプションコードは含まれません)。 +.PP +本オプションの値は、2 つの方法のいずれかで設定されます。 +1 番目の方法は、単にデータを直接指定するものです。 +データの指定には、テキスト文字列かコロンで区切られた 16 進数値を用います。 +例えば: +.PP +.nf +option vendor-encapsulated-options + 2:4:AC:11:41:1: + 3:12:73:75:6e:64:68:63:70:2d:73:65:72:76:65:72:31:37:2d:31: + 4:12:2f:65:78:70:6f:72:74:2f:72:6f:6f:74:2f:69:38:36:70:63; +.fi +.PP +本オプションを設定する 2 番目の方法は、DHCP サーバに +ベンダ固有オプションバッファを作成させるというものです。 +これをするには、以下の 4 つのことをする必要があります: +オプション空間を定義し、そのオプション空間内にオプションを定義し、 +それらへ値を割り振り、最後にそのオプション空間が +.B vendor-encapsulated-options +オプションの生成に使用されることを指定します。 +.PP +ベンダオプションが格納されるオプション空間を新規に定義するには、 +\fRoption space\fP 文を使用します: +.PP +.B option +.B space +.I name +.B ; +.PP +この文書にこれまで書かれているように、 +この name は、オプション定義で使用することができます。 +例えば: +.nf + +option space SUNW; +option SUNW.server-address code 2 = ip-address; +option SUNW.server-name code 3 = text; +option SUNW.root-path code 4 = text; + +.fi +一度、オプション空間とオプションの書式を定義したら、 +それらのオプションの値を定義するスコープを設定でき、 +それらのオプションをいつ使うかを指定することができます。 +例えば、2 つの異なるクラスのクライアントを扱いたいとしましょう。 +前述の例で示したオプション空間の定義を使って、以下のように、 +クライアントから送られてきた vendor-class-identifier オプションに基づいて、 +異なるオプションの値を異なるクライアントに送出することができます。 +.PP +.nf +class "vendor-classes" { + match option vendor-class-identifier; +} + +option SUNW.server-address 172.17.65.1; +option SUNW.server-name "sundhcp-server17-1"; + +subclass "vendor-classes" "SUNW.Ultra-5_10" { + vendor-option-space SUNW; + option SUNW.root-path "/export/root/sparc"; +} + +subclass "vendor-classes" "SUNW.i86pc" { + vendor-option-space SUNW; + option SUNW.root-path "/export/root/i86pc"; +} +.fi +.PP +先の例で見たように、通常のスコープルールを適用することで、 +グローバルな値をグローバルスコープ中に定義でき、 +特定のクラスに固有の値だけをローカルスコープに定義できます。 +\fBvendor-option-space\fR 宣言を使うことで、 +.B vendor-encapsulated-options +オプションを構成するのに、SUNW オプション空間内のオプションを使うよう +DHCP サーバに指示することができます。 +.SH 関連項目 +dhclient.conf(5), dhcp-eval(5), +dhclient(8), RFC2132, RFC2131 +.SH 作者 +Internet Systems Consortium DHCP Distribution +は、Vixie Labs との契約のもとで、Ted Lemon が記述しました。 +本プロジェクトの資金は、Internet Systems Consortium が提供しました。 +Internet Systems Consortium に関する情報は、 +.B https://www.isc.org +にあります。 |
