ETT-R&D Publications E. Terrell IT Professional, Author / Researcher May 2002 Internet Draft Category: Proposed Standard Document: draft-terrell-iptx-dhcp-req-iptx-ip-add-spec-00.txt Expires November 24, 2002 The IPtX Dynamic Host Configuration Protocol (IPtX DHCP), and the Requirements for the 'IPtX' IP Addressing Protocol 'Family' Specification Status of this Memo This document is an Internet-Draft, and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsolete by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Conventions Please note, the font size for the Tables are smaller than the expected 12 pts. However, if you are using the most current Web Browser, the View Section of the Title bar provides you with the option to either increase or decrease the font size for comfort level of viewing. That is, provided that this is the HTML or PDF version. E Terrell [Page 1] The IPtX DHCP Services November 24, 2002 TABLE OF CONTENTS Abstract Chapter I: Current Specifications: The IPv4 DHCP Server and the IPt1 Specification Chapter II: The IPtX DHCP Specification, and the Implications of the 'Zone IP', and 'IP Area Code' Prefix Addresses Chapter III: Security Considerations References E Terrell [Page 2] The IPtX DHCP Services November 24, 2002 Abstract This document defines the changes when the IP Bit Mapped Header Size Specification Equals 64 Bits, as would be required for the Implementation Dynamic Host Configuration Protocol (DHCP) to support hosts defined by the IPtX IP Addressing Protocol Family Specification. Furthermore, while the underlining implications regarding any Change in the Header Size Specification maintains the possibility of having a Profound Cascading Affect upon other Protocols. Noting specifically, the affects upon the 'TCP' and 'UDP' Headers, and the corresponding affects upon the Growth in the Number of Available 'PORTS'. Nevertheless, while there is a noticeable growth occurring in each of these areas, they remain manageable, because the difference between the IPv4 and the IPtX Specification is minimal. In which case, it should be clearly understood, the Operations presently defined for the IPv4 IP Addressing System would be the same under the IPt1 Specification. And this is valid because the differences between their IP Addressing Schematic Design does not mandate a requirement for any change, and they both use the same 32Bit Header Size Specification. In other words, the implementation of the IPtX Specification has little or No affect, nor does it constitute an appreciable change in the Dynamic Host Configuration Protocol Specification, which is Currently used in the IPv4 IP Addressing System. Hence, this work should only be considered as an extension of the RFC(s) governing and supporting the Dynamic Host Configuration Protocol (DHCP) for the IPv4 Specification, because the only objective this paper maintains, is the development and presentation of the IPtX DHCP Specification, which only compliments the requirements in the current RFC(s) defining the DHCP Protocol Specification. "This work is Dedicated to my first and only child, 'Yahnay', who is; the Mover of Dreams, the Maker of Reality, and the 'Princess of the New Universe'. (E.T.)" E Terrell [Page 3] The IPtX DHCP Services November 24, 2002 Chapter I: Current Specifications: The IPv4 DHCP Server and the IPt1 Specification The acronym 'DHCP' is the abbreviation for 'Dynamic Host Configuration Protocol', which is an Application Protocol used to Automate the Assignment of the Network; Information, Connection, and Configuration of the Host, or Devices (Node) for their Connection to the Network representing their Network Domain. Nevertheless, quoting the current definitions from the Introduction given in RFC2131 [8]: "The Dynamic Host Configuration Protocol (DHCP) provides configuration parameters to Internet hosts. DHCP consists of two components: a protocol for delivering host-specific configuration parameters from a DHCP server to a host and a mechanism for allocation of network addresses to hosts. DHCP is built on a client-server model, where designated DHCP server hosts allocate network addresses and deliver configuration parameters to dynamically configured hosts. Throughout the remainder of this document, the term "server" refers to a host providing initialization parameters through DHCP, and the term "client" refers to a host requesting initialization parameters from a DHCP server." Nevertheless, while I could continue quoting from the various RFCs outlining the requirements for the DHCP Services [8]. The point to be made however, is that; since there is absolutely No change with the implementation of the IPt1 Specification from that required by the IPv4 Specification, it would be redundant to continue. In other words, barring the differences in their respective Addressing Schematics, these IP Addressing Specifications are Mirror Images, which represents an identity allowing for complete compatibility, because these IP Addressing Systems use the Same Default IP Addressing Structure / Format. E Terrell [Page 4] The IPtX DHCP Services November 24, 2002 Figure 1 IP Header for IPv4 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | VER | IHL | TYPE OF SERVICE | TOTAL LENGHT | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | IDENTIFICATION |FLA| FRAGMENT OFFSET | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | TIME TO LIVE | PROTOCOL | CHECK SUM HEADER | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | SOURCE ADDRESS | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | DESTINATION ADDRESS | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | OPTIONS | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | DATA | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| |-------------------------------------------------------------| Figure 2 IP Header for IPt1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | IPt1 | IHL | TYPE OF SERVICE | TOTAL LENGHT | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | IDENTIFICATION |FLA| FRAGMENT OFFSET | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | TIME TO LIVE | PROTOCOL | CHECK SUM HEADER | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | SOURCE ADDRESS | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | DESTINATION ADDRESS | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | OPTIONS | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | DATA | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| |-------------------------------------------------------------| E Terrell [Page 5] The IPtX DHCP Services November 24, 2002 Figure 3 DHCP or Bootp Header for IPv4 and IPt1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | Opcode | Hardware type |Hardware address length|Hop count | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Transaction ID | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Number of seconds | Flags | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Client IP Address | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Your IP Address | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Server IP Address | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Gateway IP Address | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Client Hardware Address | | ::: | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Server Host Name | | ::: | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Boot filename | | ::: | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Options OR Vendor specific info |<-| | DHCP ::: Bootp | | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | |-------------------------------------------------------------| | | |The only difference between the DHCP and Bootp Headers is the|<--| |Labeling of the Last Section within the Header, which has the| |Respective Name Listed below the Section Title. | E Terrell [Page 6] The IPtX DHCP Services November 24, 2002 Figure 4 UDP header for IPv4 and IPt1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 | Source Port = 16 BITS | Destination Port = 16 BITS | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Length = 16 BITS | Checksum = 16 BITS | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Data | | ::: | | ::: | |-------------------------------------------------------------| E Terrell [Page 7] The IPtX DHCP Services November 24, 2002 Chapter II: The IPtX DHCP Specification, and the Implications of the 'Zone IP', and 'IP Area Code' Prefix Addresses The IPtX DHCP Specification, using a 64 Bit Header Size Format, should only be viewed as an Extension and Enhancement of the current DHCP Services used in the IPv4 Specification. That is, while preserving the Foundational Functions and Definitions, which governs and services the IPv4 Specification. The implementation of the IPtX DHCP Specification should only be viewed as extending the Size Parameters, as would be necessary to accommodate the 64 Bit Header Size Specification. However, there are consequences, foreseen and unforeseen, which are Directly associated with the IP Header Size Specification, that can Directly and Indirectly maintain dire effects cascading across the entire system. In fact, it could quite easily be the conclusion; 'Any IP Header Size Specification beyond 64 bits, would have Unmanageable Consequences Prorogating throughout the entire IP Addressing System'. These consequences would maintain such a profound effect, that the only way to Reduce the Adverse Impact resulting from Changing the Header Size Specification, would be the development of New Specifications for the affected Areas within the IP Addressing System. Even still, this procedure might not Suffice. However, a Temporary Fix could sustain the overall Addressing System from a Cycle of Continuous Break-Downs and Repairs, Until the Entire System Could Be Re-Written. As an example nevertheless, consider the Growth in the Number of Ports Available, which is one of the consequences resulting from, and directly effected by the Header Size Specification, as shown in Table 1. Table 1 [5] 1. When the Header Size Specification equals 64 BITS A. Total Number of Available Ports using the Modern Binary System for the Current or IPtX Specification 255^4 = 255 x 255 x 255 x 255 = 4,228,250,625 B. Total Number of Available Ports using the New Binary System for the Current or IPtX Specification 256^4 = 256 x 256 x 256 x 256 = 4,294,967,296 E Terrell [Page 8] The IPtX DHCP Services November 24, 2002 2. When the Header Size Specification equals 128 BITS A. Total Number of Available Ports using the Modern Binary System for the Current or IPv6 Specification 255^8 = 255 x 255 x 255 x 255 x 255 x 255 x 255 x 255 = 1.787810 x 10^19 17,878,100,000,000,000,000 = Number of Available PORTS B. Total Number of Available Ports using the Modern Binary System for the Current or IPv6 Specification 256^8 = 256 x 256 x 256 x 256 x 256 x 256 x 256 x 256 = 1.844674 x 10^19 18,446,740,000,000,000,000 = Number of Available PORTS 3. When the Header Size Specification equals 32 BITS A. Total Number of Available Ports using the Modern Binary System for the Current or IPv4 Specification 255^2 = 255 x 255 = 65,025 B. Total Number of Available Ports using the New Binary System for the Current or IPv4 Specification 256^2 = 256 x 256 = 65,536 E Terrell [Page 9] The IPtX DHCP Services November 24, 2002 The ramifications comprising the consequences resulting from the effects of changing the HEADER Size Specifications, to say the very least, are clearly profound. And while Table 1 demonstrates the need to exercise caution when specifying the HEADER Size Specifications, there can still be benefits. That is, if the all of the parameters within or effected by the resulting Growth of the Header Specification [1], which are effected or Changed by a proportional amount, and remain Stable and Manageable. Then the benefits derived from the IPtX Specification, using only the 'Zone' IP Address for differentiation, provides the ability to Assigning Port Numbers for Private use by the Consumer, which could have the affect of providing additional Security to allow Secure and Private access to Control Networked Appliances (Household Appliances, and other Networked Devices), or linking Wireless Remotes for sharing the Carrier Wave of Radio Frequency Transmissions. This method, which is similar to the VPN, or ATM(s), could also provide Secure Links for Commercial, Governmental, Medical, Educational, Research, and Military uses within each Zone IP Address Location, because there are more than 4 Billion Ports available to each Zone IP Address Location. And while after configuration, these Ports could be invisible to the User(s), the flexibility for Access could still be controlled, and the level of Security they provide, could be greater than the Firewall Technology currently used today. Nevertheless, the IPtX DHCP Specification represents only the changes that are required by the 64 Bit Header Size Specification [1], which are reflected by Changes Noted in Table 2, and described in Figures 5 through 7 as being a proportional increase relative to the increase in the Header Size. In other words, the IPtX DHCP 64 Bit Header Size Specification reflects a uniform increase of the Controls within the Header itself, which provides an easy transition for backward compatibility with the IPv4 DHCP Specification. E Terrell [Page 10] The IPtX DHCP Services November 24, 2002 Table 2 CHANGES: IPtX DHCP and Bootp Services 64Bit Header DHCP Header for IPt2 | BootP Header for IPt2 UDP Header for IPt2 ------------------------|------------------------|---------------------------| | | Hardware |Hardware |Source Port = 32Bit Address Length = 16Bit |Address Length = 16Bit | | |Destination Port = 32Bit Opcode = 16it |Opcode = 16Bit | | |Length = 32Bit Hardware type = 16Bit |Hardware type = 16Bit | | |Checksum = 32Bit Hop Count = 16Bit |Hop Count = 16Bits | | |---------------------------| | Transaction ID = 48Bit*|Transaction ID = 48Bit* {48 Bit HEX Number} | Number of Seconds 32Bit|Number of Seconds 32Bit | Flags = 32Bit |Flags = 32Bit | *Network Security | *Network Security Identification Number = 'NSID' Identification | = 16Bit {16Bit Hidden Hex Number assigned by Operating Number = 'NSID' = 16Bit| System Server to Secure IPtX DHCP Services}* ------------------------|------------------------|---------------------------| E Terrell [Page 11] The IPtX DHCP Services November 24, 2002 Figure 5 64 Bit IP Header for IPt2 [1], [4] 0 2 4 6 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 |IPtX| IHL | TOS & NEXT HEADER | TL & DIRECTION BIT | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | ID & SECURITY BIT |FLA| FRAG OFFSET |:IP PBX Send |/XXXX:XX | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | TTL-HOP LIMIT | PROTOCOL |:IP PBX Recv | CHK SUM | ConfCall | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | S1 RESERVED: | S2 RESERVED:| S ZONE IP: | S IP AREA CODE:| |+ + 8 Bits + + + 8 Bits + + + + 8 Bits + + + + 8 Bits+++ + +| | SOURCE IP ADDRESS (32Bit) | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | D1 RESERVED: | D2 RESERVED:| D ZONE IP: | D IP AREA CODE:| |+ + 8 Bits + + + 8 Bits + + + + 8 Bits + + + + 8 Bits+++ + +| | DESTINATION IP ADDRESS (32Bit) | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | OPTIONS | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | DATA | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| |-------------------------------------------------------------| / Size Displacement IPt2 64 Bit Mapped Address Space \ / SOURCE and DESTINATION IP ADDRESSES \ / \ Prefix Address <---> (Or Trunk Identifier) CIDR \ / / | | \ \ 32 Bit IPt1 Network \ | 8 Bits | 8 Bits | 8 Bits | 8 Bits | Address Space |Descriptor\ +---------+---------+-----------------------+----------------------------+\ |Reserved:|Reserved:| Zone IP:|IP Area Code:| XXX.XXX.XXX.XXX | /XXXX:XX | +---------+---------+-----------------------+----------------------------+ E Terrell [Page 12] The IPtX DHCP Services November 24, 2002 Figure 5-B [1], [4] æReality of the IP Addressing Format in the 64 Bit HeaderÆ 'Whose Reserved Addresses would not be apart of the Software Program representing the Header' 1. Source Address Structure: (X.X.X):(X.X.X):256:256:256.256.000.000 2. Destination Address Structure: (X.X.X):(X.X.X):256:256:256.256.000.000 Note*: While the expansion of the IP Address within the Header, is incremented in '8 Bit' Segments. The increase in the Total Size of the IP Address beyond the Current Header Specifications, is accomplished using '32 Bit' increments, which increases the overall size of the Header itself. This is, as it should be, because it reflects the size of the 'Base IP Addressing Schematic'; 'IPt1'. Thus, preserving the Logic and Mathematical Continuity, which is the actual integrity of the System's Foundation, that was logically derived from the Mathematics of Quantification. E Terrell [Page 13] The IPtX DHCP Services November 24, 2002 Figure 6 DHCP or Bootp Header for IPtX 0 2 4 6 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 |Opcode|Hardware type 16Bit|HardwareAddrLgth16Bit|HopCount 16B| |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | 'NSID' 16Bit HEX Number | Transaction ID 48Bit HEX Number| |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Number of Seconds 32Bit | Flags 32Bit | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| |Reserved |Reserved | Client IP Address | |+ + ^ + + + + ^ + + + + + + + + + + + + + + + + + + + + + + +| | ::: | ::: | Your IP Address | |+ + | + + + + | + + + + + + + + + + + + + + + + + + + + + + +| | ::: | ::: | Server IP Address | |+ + | + + + + | + + + + + + + + + + + + + + + + + + + + + + +| | ::: | ::: | Gateway IP Address | |+ + V + + + + V + + + + + + + + + + + + + + + + + + + + + + +| |Reserved |Reserved | Client Hardware ( MAC ) Address | | 8 Bits | 8 Bits | 48 Bit HEX Notation | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Server Host Name | | ::: | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Boot filename | | ::: | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Options OR Vendor specific info |<-| | DHCP ::: Bootp | | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | |-------------------------------------------------------------| | | |The only difference between the DHCP and Bootp Headers is the|<--| |Labeling of the Last Section within the Header, which has the| |Respective Name Listed below the Section Title. | E Terrell [Page 14] The IPtX DHCP Services November 24, 2002 Figure 7 UDP header for IPtX 0 2 4 6 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 4 6 8 0 2 | Source Port = 32 BITS | Destination Port = 32 BITS | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Length = 32 BITS | Checksum = 32 BITS | |+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +| | Data | | ::: | | ::: | |-------------------------------------------------------------| Nevertheless, while triggering the Alarm, as shown by the analysis of the data in Table 1, might seem more like a scare tactic. It is in fact, a call for an investigation regarding the Size Limits, which should be imposed upon the Growth of the Header Size Specification used in any IP Addressing System. Furthermore, the data analysis resulting from Table 1 is indeed indicative of the Cascading Consequences effecting every Protocol, who's Length is Derived from the Header Size Specification. Moreover, while the IPtX IP Addressing Protocol Family Specification maintains an Unlimited IP Address Size Specification, the built in constraints it maintains, Limits the Header Size Specification to 64 Bits [1], which provides a more Rational, Stable, and Manageable approach to IP Addressing. In other words, once the Parameters has been Adjusted for the 64 Bit Header Specification, with the exception of IPt1, the parameters remain valid throughout the remaining IPtX Addressing Protocols contained in this IP Addressing Protocol Family Specification. E Terrell [Page 15] The IPtX DHCP Services November 24, 2002 Chapter III: Security Considerations [8] This document, whose primary objective was the Development of the IPtX DHCP Specification does not Challenge the Security Procedures specified for the Current DHCP Specification. However, DHCP was intended to make maintenance of remote and diskless Clients automatic. And while it may be difficult and inconvenient, the configuration of passwords and authorization keys, so far, remains the only option. Nevertheless, since the DHCP Services is inherently insecure. The provisions for a 'Network Security Identification' (NSID) Number, which is a Hidden 16Bit HEX Authorization Number Assigned by the Operating System Server to the DHCP Server, that could be verified and confirmed by the client during Logon with the Network Domain Server after configuration. Would clearly be a Boon for the prevention of the Rogue DHCP Services, which are masquerading as a DHCP Service attached to the Network Domain. Needless to say, this feature would be a significant enhancement over the Security features currently Specified for the IPv4 DHCP Specification, and could quite easily be employed in the New Specification for the IPtX DHCP Services. E Terrell [Page 16] The IPtX DHCP Services November 24, 2002 References 1. E. Terrell (ETT-R&D Publications, April 2002) "INTERNET PROTOCOL t1 and t2 ADDRESS SPACE" 'daft-terrell-internet-protocol- t1-t2-ad-sp-06.txt'. (work in progress) 2. E. Terrell (ETT-R&D Publications, June 13, 2002) "Logical Analysis of the Binary Representation and the IP Specifications for the IPv7 and IPv8 Addressing Systems" 'draft-terrell-logic-analy-bin-ip -spec-ipv7-ipv8-10.txt'. (work in progress) 3. E. Terrell (ETT-R&D Publications, February 2002) "The Mathematics of Quantification, and the New Paradigm, which Re-Defines Binary Mathematics" 'draft-terrell-math-quant-new-para-redefi-bin-math-03.txt'. (work in progress) 4. E. Terrell (ETT-R&D Publications, March 2002) "The Reality of the Schematic Design of the IPt1 and IPt2 Protocol Specifications: 'It is Just the Computer's Telephone Number" 'draft-terrell-schem-desgn-ipt1-ipt2-cmput-tel-numb-02.txt'. (work in progress) 5. E. Terrell (ETT-R&D Publications, May 2002) "The IPtX Domain Name System (DNS), and the DNS Requirements for the 'IPtX' IP Addressing Protocol 'Family' Specification" 'draft-terrell-iptx-dns-req-iptx-ip-add-spec-02.txt'. (work in progress) 6. E. Terrell (ETT-R&D Publications, August 2001) "The Simple Proof Supporting the Findings from the Logical Analysis of the Binary System Which disposes the Logical Dispute fostered by Modern Interpretation for Counting in Binary Notation" 'draft-terrell-simple-proof-support-logic-analy-bin-02.txt'. (work in progress) 7. R. Johnson, K. Kinnear, M. Stapp, J. Kumarasamy (Cisco Systems, Inc., November 2001) "DHCP VPN Information option" 'daft-ietf-dhc-vpn-option-01.txt'. (work in progress) 8. DHCP Implementation and Security RFCs: 3203, 2132, 1534, 2131, 2563, 1359, 1034, 1035, 1123, 2181, 2855, 1542, 1534, 2131, 2132, 2241, 2242, 2563, 2485, 2610, 2855, 2937, 2939, 3004, 3011, 3046, 3118, 3203, 3256, 1918, and 2489. E Terrell [Page 17] The IPtX DHCP Services November 24, 2002 Author Eugene Terrell 24409 Soto Road Apt. 7 Hayward, CA. 94544-1438 Voice: 510-537-2390 E-Mail: eterrell00@netzero.net "Copyright (C) The Internet Society (5/24/02). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind; except when such works are sold without the consent of the Author and are not freely distributed, and provided that the above copyright notice and this paragraph are included on all such copies and derivative works. Furthermore, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns, except that the Author is not bound by any of the provisions set forth herein, or outline by this Copyright. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." E Terrell [Page 18] The IPtX DHCP Services November 24, 2002