Internet Engineering Task Force Jerome Privat INTERNET-DRAFT BT Date:
FebruaryMarch 2000 Michael Borella Expires: JulyAugust 2000 3Com Corp DHCP Next Server Option <draft-ietf-dhc-nextserver-01.txt><draft-ietf-dhc-nextserver-02.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 atwo new DHCP optionoptions called the DHCP Next Server DNS name option and the DHCP Next Server IP address option. A DHCP server can use this optionthese options 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 atwo new DHCP optionoptions 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 atwo new DHCP optionoptions called the DHCP Next Server Option. ThisDNS name option isand the DHCP Next Server IP address option. These options are used by a DHCP server to indicate to a DHCP client respectively, the DNS name and the IP address of a secondary server from where it can retrieve other parts of its configuration. The utility of this optionthese options is that it allowsthey allow 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 or DNS name to a client, the client is able to contact that server directly, using whatever protocol is necessary. 6. Next Server Option This option is aOptions These options are DHCP optionoptions [RFC2131, RFC2489]. TheNext Server Option isOptions are returned in DHCPOFFER and DHCPACK by a DHCP server. 6.1. Next Server IP address option The Next Server IP address Option specifies a list of 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 N. The Length value must include one for the 'Proto' byte and include four for each Secondary Server address which follows. Thus, thefollows; it has has a minimum value of 5. The Length minus one of the option MUST always be divisible by 4 and has a minimum value of 5.4. The address of the Secondary Server is given in network byte order. The "Proto field" p indicates the protocol to use to contact the secondary server. More than one Next Server IP address Option MAY be provided to a client. However each of these options MUST contain different protocol fields. Code Len Proto Address +-----+-----+-----+-----+-----+-----+-----+-----+ | TBD | N | p | a1 | a2 | a3 | a4 | ... | +-----+-----+-----+-----+-----+-----+-----+-----+ 6.2. Next Server DNS name option This option specifies the DNS [RFC1035] name for the secondary server. The code for this option is TBD, and its length is N. The Length value is equal to one plus the length of the DNS name string. Thus the maximum length of the DNS name string is 254 octets. Code Len Proto DNS name of secondary server +-----+-----+-----+-----+-----+-----+-----+-----+-----+ | TBD | N | p | s1 | s2 | s3 | s4 | s5 | ... | +-----+-----+-----+-----+-----+-----+-----+-----+-----+ The "Proto field" p indicates the protocol to use to contact the secondary server. More than one Next Server DNS name Option MAY be provided to a client. However each of these options MUST contain different protocol fields. The reason for defining this option in addition to the Next Server IP address option is that it allows implementation of load-balancing by using an SRV [RFC2052] query. c. Protocol field 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. Note on the scope of these options: These options are meant to redirect the client in situations where further configuration transactions may be necessary but not to replace other options in general. Thus new values of p should only be attributed for protocols used by clients to retrieve part of their configuration. 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 In this section we use the term Next Server Option to mean either Next Server IP address option or Next Server DNS name option. 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 indicatedserver identified 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 or DNS name 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 thea 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 addressserver 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 In this section we use the term Next Server Option to mean either Next Server IP address option or Next Server DNS name option. 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 or domain name 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 addressserver 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. The introduction of the DHCP Next Server DNS name option was suggested by the use of a similar option defined in the DHCP option for SIP server draft by G. Nair and H. Schulzrinne. 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>, 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-03.txt>, Oct. 1999<draft-ietf-nat-rsip-protocol-05.txt>, Jan. 2000 (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<draft-ietf-dhc-userclass-05.txt>, Feb. 2000 (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). [RFC1035] P. V. Mockapetris, "Domain names - implementation and specification", RFC1035, Nov. 1997. [RFC2052] A. Gulbrandsen and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC2052, Oct. 1996. 12. Authors' Addresses Jerome Privat BT Advanced Communications Technology Centre Adastral Park, Martlesham Heath, IP5 3RE UK +44 1473 648910606304 email@example.com Michael Borella 3Com Corp. 1800 W. Central Rd. Mount Prospect IL 60056 USA (847) 342-6093 firstname.lastname@example.org 13. Expiration This document will expire on JulyAugust 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.