Internet Engineering Task Force Jerome Privat INTERNET-DRAFT BT Date:
JanuaryFebruary 2000 Michael Borella Expires: JuneJuly 2000 3Com Corp DHCP Next Server Option <draft-ietf-dhc-nextserver-00.txt><draft-ietf-dhc-nextserver-01.txt> Status of This Memo The document is an Internet-Draft and is in full conformance with all of the provisions of Section 10 of RFC 2026. 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 obsoleted by other documents at any time. It is inappropriate to use Intenet-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. Abstract This proposal allows host configuration to be split between two different address servers, potentially under different administration. This ability may be useful to satisfy specific regulatory, operational or business model requirements, as well as to provide support for secondary address servers. This draft proposes a new DHCP option called the DHCP Next Server option. A DHCP server can use this option to redirect clients to a secondary server. 1. Introduction The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a mechanism for the assignment of addressing and other parameters from a server to a client. In order to extend DHCP's abilities, a process for defining new DHCP options has been established [RFC2489]. This document defines a new DHCP option for redirecting requests to a secondary address server. This secondary server may or may not be a DHCP server. In particular, we consider DHCP redirect to an RSIP [RSIP-FRAME] server. 2. Terminology - DHCP client A DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address. - DHCP server A DHCP server is an Internet host that returns configuration parameters to DHCP clients. - Realm Specific IP (RSIP) A method through which a client from one addressing realm can assume and utilize addressing and configuration parameters from a second addressing realm [RSIP-FRAME]. - RSIP Server A router situated on the boundary between a private realm and a public realm and owns one or more public IP addresses. An RSIP server is responsible for public parameter management and assignment to RSIP clients. - RSIP Client A host within the private realm that assumes publicly unique parameter sets from an RSIP server through the use of RSIP. 3. Specification of Requirements The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this documents are to be interpreted as described in [RFC2119]. 4. Architecture Our proposed architecture is as follows. Client host configuration information is split between two different address servers, potentially under different administrative control. The primary (most local) address server is always a DHCP server. The secondary address server may or may not be DHCP. The primary server manages IP addresses. More precisely, it allocates an IP address, a network mask and a default router to clients. It MAY also manage other parts of the configuration. The secondary server manages the rest of the configuration. Partition of the configuration information (other than IP address, network mask and default router) between the two servers is a matter of policy and agreement between administrators of the two servers. It is out of the scope of this document. 5. Redirect to Secondary Server We define a new DHCP option called the Next Server Option. This option is used by a DHCP server to indicate to a DHCP client the IP address of a secondary server from where it can retrieve other parts of its configuration. The utility of this option is that it allows a client to discover a secondary configuration server even if that server is not on the same logical subnet as the client. For example, a client might use a UDP broadcast on a particular port number to discover a configuration server. However, these broadcasts, with the exception of DHCP/BOOTP traffic, will be dropped by first-hop routers. By allowing DHCP servers to provide a secondary server's address to a client, the client is able to contact that server directly, using whatever protocol is necessary. 6. Next Server Option This option is a DHCP option [RFC2131, RFC2489]. The Next Server Option is returned in DHCPOFFER and DHCPACK by a DHCP server. A DHCP client SHOULD contact the address indicated in theThe Next Server Option field to retrieve the restspecifies a list of its configuration.IP addresses for secondary servers (Multiple addresses of secondary servers MAY be provided for robustness). Secondary servers MUST be listed in order of preference, if there is an order of preference. The code for this option is TBD, and its length is 5. It containsN. The Length value must include one for the IP'Proto' byte and include four for each Secondary Server address which follows. Thus, the Length minus one of the secondary server tooption MUST always be useddivisible by 4 and has a minimum value of 5. The address of the clientSecondary Server is given in its configuration process, as well as the protocol that the client must use to contact the secondary server.network byte order. More than one Next Server Option MAY be provided to a client. However each of these options MUST contain different protocol fields. Code Len Proto Address +-----+-----+-----+-----+-----+-----+-----++-----+-----+-----+-----+-----+-----+-----+-----+ | TBD | 5N | p | a1 | a2 | a3 | a4 | +-----+-----+-----+-----+-----+-----+-----+ Values... | +-----+-----+-----+-----+-----+-----+-----+-----+ Initial values for p, the protocol to use to contact the secondary server, are defined below: 0 Reserved 1 DHCP 2 RSIP New values for p MAY be registered with IANA. If a client receives a Next Server Option with a protocol that it does not support, the client MUST silently ignore the fact that it has been referred to a secondary server. 7. DHCP Server as Secondary Server If a DHCP server is indicated by the protocol field of the Next Server Option, a DHCP client SHOULD send a DHCPINFORM to the address indicated in the Next Server Option field to retrieve the rest of its configuration via DHCP. A typical double-phase DHCP configuration using the DHCP next server option is: - A DHCP client broadcasts a DHCPDISCOVER. It receives a DHCPOFFER from the primary DHCP server containing (at least) a proposed IP address, a network mask and a default router. - Based on its local policy, the primary DHCP server returns a Next Server Option or not. This decision, as well as the address returned in the Next Server Option, MAY be based on some of the options in the client request such as the 'client identifier' option or the 'user class' option [DHC-UC]. - The DHCP client and the primary DHCP server finish their DHCP exchange in the standard way. - If the Next Server Option was present and it indicates that the secondary server is a DHCP server, then the DHCP client SHOULD send a DHCPINFORM to the IP address indicated in the option. Note that the two phases are independent of each other. In this way, a failure of the second phase does not affect the first one. The 'siaddr' field is used by a DHCP server to tell a DHCP client the IP address of the server to use in the next step of the client bootstrap process [RFC2131]. The proposed option differs from the 'siaddr' field in that the Next Server Option is used by the DHCP client not to retrieve a boot file, but other parts of its configuration. 8. RSIP Server as Secondary Server If an RSIP server is indicated in the Next Server Option, the client SHOULD contact the RSIP server using the RSIP protocol [RSIP-PROTO]. The typical double phase redirect configuration with RSIP is: - A DHCP client broadcasts a DHCPDISCOVER. It receives a DHCPOFFER from the primary DHCP server containing (at least) a proposed IP address, a network mask and a default router. - Based on its local policy, the primary DHCP server returns a Next Server Option or not. This decision, as well as the address returned in the Next Server Option, MAY be based on some of the options in the client request such as the 'client identifier' option or the 'user class' option [DHC-UC]. - The client and the primary DHCP server finish their DHCP exchange in the standard way. - If the Next Server Option was present and it indicates that the secondary server is an RSIP server, then the client SHOULD send an RSIP REGISTER_REQUEST message to the IP address indicated in the option. - The RSIP protocol continues as defined in [RSIP-PROTO]. Note that the two phases are independent of each other. In this way, a failure of the second phase does not affect the first one. 9. Security Considerations The IP address of the secondary server may depend on some options sent by the client such as the 'client identifier' option or the 'user class' option [DHC-UC]. A client giving false information in one of these options could have access to some configuration information to which it is not entitled. Authentication [DHC-AUTH] and policy at the DHCP server SHOULD be used to prevent that happening. 10. Acknowledgements Thanks to Nick Farrow, George Tsirtsis and Alan O'Neill for their review and comments. Thanks to Mike Henry for his comments. 11. References [RFC2119] S. Bradner, "Key words for use in RFCs to indicate requirement levels," RFC 2119, Mar. 1997. [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, Mar. 1997. [RFC2489] R. Droms, "Procedure for Defining New DHCP Options", RFC 2489, Jan. 1999. [RSIP-FRAME] M. Borella, J. Lo, D. Grabelsky and G. Montenegro, "Realm Specific IP: Framework" Internet Draft <draft-ietf-nat-rsip-framework-03.txt>, Dec.Oct. 1999 (work in progress). [RSIP-PROTO] M. Borella, D. Grabelsky, J. Lo and K. Taniguchi, "Realm Specific IP: Protocol Specification," Internet Draft <draft-ietf-nat-rsip-protocol-04.txt>,<draft-ietf-nat-rsip-protocol-03.txt>, Oct. 1999 (work in progress). [DHC-UC] G. Stump, R. Droms, Y. Gu, A. Demirtjis, B. Beser, and J. Privat, "The User Class Option for DHCP", Internet Draft <draft-ietf-dhc-userclass-04.txt>, Oct. 1999 (work in progress). [DHC-AUTH] R. Droms, W. Arbaugh, "Authentication for DHCP Messages", Internet Draft <draft-ietf-dhc-authentication-11.txt>, 1999 (work in progress). 12. Authors' Addresses Jerome Privat BT Advanced Communications Technology Centre Adastral Park, Martlesham Heath, IP5 3RE UK +44 1473 648910 firstname.lastname@example.org Michael Borella 3Com Corp. 1800 W. Central Rd. Mount Prospect IL 60056 USA (847) 342-6093 email@example.com 13. Expiration This document will expire on JuneJuly 2000. Copyright Statement Copyright (c) The Internet Society (1999). 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, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, 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. 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.