draft-ietf-dhc-nextserver-01.txt   draft-ietf-dhc-nextserver-02.txt 
Internet Engineering Task Force Jerome Privat Internet Engineering Task Force Jerome Privat
INTERNET-DRAFT BT INTERNET-DRAFT BT
Date: February 2000 Michael Borella Date: March 2000 Michael Borella
Expires: July 2000 3Com Corp Expires: August 2000 3Com Corp
DHCP Next Server Option DHCP Next Server Option
<draft-ietf-dhc-nextserver-01.txt> <draft-ietf-dhc-nextserver-02.txt>
Status of This Memo Status of This Memo
The document is an Internet-Draft and is in full conformance with all The document is an Internet-Draft and is in full conformance with all
of the provisions of Section 10 of RFC 2026. of the provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 38 skipping to change at line 38
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This proposal allows host configuration to be split between two This proposal allows host configuration to be split between two
different address servers, potentially under different different address servers, potentially under different
administration. administration.
This ability may be useful to satisfy specific regulatory, This ability may be useful to satisfy specific regulatory,
operational or business model requirements, as well as to operational or business model requirements, as well as to
provide support for secondary address servers. This draft provide support for secondary address servers. This draft
proposes a new DHCP option called the DHCP Next Server option. proposes two new DHCP options called the DHCP Next Server
A DHCP server can use this option to redirect clients to a DNS name option and the DHCP Next Server IP address option.
A DHCP server can use these options to redirect clients to a
secondary server. secondary server.
1. Introduction 1. Introduction
The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides a
mechanism for the assignment of addressing and other parameters from mechanism for the assignment of addressing and other parameters from
a server to a client. In order to extend DHCP's abilities, a a server to a client. In order to extend DHCP's abilities, a
process for defining new DHCP options has been established [RFC2489]. process for defining new DHCP options has been established [RFC2489].
This document defines a new DHCP option for redirecting requests to a This document defines two new DHCP options for redirecting requests
secondary address server. This secondary server may or may not be to a secondary address server. This secondary server may or may not
a DHCP server. In particular, we consider DHCP redirect to an RSIP be a DHCP server. In particular, we consider DHCP redirect to an
[RSIP-FRAME] server. RSIP [RSIP-FRAME] server.
2. Terminology 2. Terminology
- DHCP client - DHCP client
A DHCP client is an Internet host using DHCP to obtain configuration A DHCP client is an Internet host using DHCP to obtain configuration
parameters such as a network address. parameters such as a network address.
- DHCP server - DHCP server
skipping to change at line 109 skipping to change at line 110
MAY also manage other parts of the configuration. The secondary MAY also manage other parts of the configuration. The secondary
server manages the rest of the configuration. server manages the rest of the configuration.
Partition of the configuration information (other than IP address, Partition of the configuration information (other than IP address,
network mask and default router) between the two servers is a matter network mask and default router) between the two servers is a matter
of policy and agreement between administrators of the two servers. It of policy and agreement between administrators of the two servers. It
is out of the scope of this document. is out of the scope of this document.
5. Redirect to Secondary Server 5. Redirect to Secondary Server
We define a new DHCP option called the Next Server Option. This We define two new DHCP options called the DHCP Next Server
option is used by a DHCP server to indicate to a DHCP client the IP DNS name option and the DHCP Next Server IP address option.
address of a secondary server from where it can retrieve other These options are used by a DHCP server to indicate to a
parts of its configuration. 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 option is that it allows a client to discover a The utility of these options is that they allow a client to discover
secondary configuration server even if that server is not on the same a secondary configuration server even if that server is not on the
logical subnet as the client. For example, a client might use a UDP same logical subnet as the client. For example, a client might use
broadcast on a particular port number to discover a configuration a UDP broadcast on a particular port number to discover a
server. However, these broadcasts, with the exception of DHCP/BOOTP configuration server. However, these broadcasts, with the exception
traffic, will be dropped by first-hop routers. By allowing DHCP of DHCP/BOOTP traffic, will be dropped by first-hop routers. By
servers to provide a secondary server's address to a client, the allowing DHCP servers to provide a secondary server's address or
client is able to contact that server directly, using whatever DNS name to a client, the client is able to contact that server
protocol is necessary. directly, using whatever protocol is necessary.
6. Next Server Option 6. Next Server Options
This option is a DHCP option [RFC2131, RFC2489]. The Next Server These options are DHCP options [RFC2131, RFC2489]. Next Server
Option is returned in DHCPOFFER and DHCPACK by a DHCP server. Options are returned in DHCPOFFER and DHCPACK by a DHCP server.
The Next Server Option specifies a list of IP addresses for
secondary servers (Multiple addresses of secondary servers 6.1. Next Server IP address option
MAY be provided for robustness). Secondary servers MUST be listed
in order of preference, if there is an order of preference. 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 code for this option is TBD, and its length is N.
The Length value must include one for the 'Proto' byte and The Length value must include one for the 'Proto' byte and
include four for each Secondary Server address which follows. include four for each Secondary Server address which follows;
Thus, the Length minus one of the option MUST always be divisible it has has a minimum value of 5.
by 4 and has a minimum value of 5. The Length minus one of the option MUST always be divisible
by 4.
The address of the Secondary Server is given in network byte order. The address of the Secondary Server is given in network byte order.
More than one Next Server Option MAY be provided to a client. The "Proto field" p indicates the protocol to use to contact
However each of these options MUST contain different protocol the secondary server.
fields.
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 Code Len Proto Address
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| TBD | N | p | a1 | a2 | a3 | a4 | ... | | TBD | N | p | a1 | a2 | a3 | a4 | ... |
+-----+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Initial values for p, the protocol to use to contact the secondary server, 6.2. Next Server DNS name option
are defined below:
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 0 Reserved
1 DHCP 1 DHCP
2 RSIP 2 RSIP
New values for p MAY be registered with IANA. 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 If a client receives a Next Server Option with a protocol that it
does not support, the client MUST silently ignore the fact that does not support, the client MUST silently ignore the fact that
it has been referred to a secondary server. it has been referred to a secondary server.
7. DHCP Server as 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 If a DHCP server is indicated by the protocol field of the
Next Server Option, a DHCP client SHOULD send a DHCPINFORM to Next Server Option, a DHCP client SHOULD send a DHCPINFORM to
the address indicated in the Next Server Option field to the server identified in the Next Server Option field to
retrieve the rest of its configuration via DHCP. A typical retrieve the rest of its configuration via DHCP. A typical
double-phase DHCP configuration using the DHCP next server double-phase DHCP configuration using the DHCP next server
option is: option is:
- A DHCP client broadcasts a DHCPDISCOVER. It receives a - A DHCP client broadcasts a DHCPDISCOVER. It receives a
DHCPOFFER from the primary DHCP server containing (at least) DHCPOFFER from the primary DHCP server containing (at least)
a proposed IP address, a network mask and a default router. a proposed IP address, a network mask and a default router.
- Based on its local policy, the primary DHCP server - Based on its local policy, the primary DHCP server
returns a Next Server Option or not. This decision, as well returns a Next Server Option or not. This decision, as well
as the address returned in the Next Server Option, MAY be as the address or DNS name returned in the Next Server
based on some of the options in the client request such as Option, MAY be based on some of the options in the client
the 'client identifier' option or the 'user class' option request such as the 'client identifier' option or the
[DHC-UC]. 'user class' option [DHC-UC].
- The DHCP client and the primary DHCP server finish their - The DHCP client and the primary DHCP server finish their
DHCP exchange in the standard way. DHCP exchange in the standard way.
- If the Next Server Option was present and it indicates - If a Next Server Option was present and it indicates
that the secondary server is a DHCP server, then the DHCP that the secondary server is a DHCP server, then the DHCP
client SHOULD send a DHCPINFORM to the IP address indicated client SHOULD send a DHCPINFORM to the server indicated
in the option. in the option.
Note that the two phases are independent of each other. Note that the two phases are independent of each other.
In this way, a failure of the second phase does not affect In this way, a failure of the second phase does not affect
the first one. the first one.
The 'siaddr' field is used by a DHCP server to tell a DHCP 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 client the IP address of the server to use in the next step
of the client bootstrap process [RFC2131]. The proposed of the client bootstrap process [RFC2131]. The proposed
option differs from the 'siaddr' field in that the Next option differs from the 'siaddr' field in that the Next
Server Option is used by the DHCP client not to retrieve Server Option is used by the DHCP client not to retrieve
a boot file, but other parts of its configuration. a boot file, but other parts of its configuration.
8. RSIP Server as Secondary Server 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, If an RSIP server is indicated in the Next Server Option,
the client SHOULD contact the RSIP server using the RSIP the client SHOULD contact the RSIP server using the RSIP
protocol [RSIP-PROTO]. protocol [RSIP-PROTO].
The typical double phase redirect configuration with RSIP The typical double phase redirect configuration with RSIP
is: is:
- A DHCP client broadcasts a DHCPDISCOVER. It receives - A DHCP client broadcasts a DHCPDISCOVER. It receives
a DHCPOFFER from the primary DHCP server containing a DHCPOFFER from the primary DHCP server containing
(at least) a proposed IP address, a network mask and a (at least) a proposed IP address, a network mask and a
default router. default router.
- Based on its local policy, the primary DHCP server - Based on its local policy, the primary DHCP server
returns a Next Server Option or not. This decision, as returns a Next Server Option or not. This decision, as
well as the address returned in the Next Server Option, well as the address or domain name returned in the Next
MAY be based on some of the options in the client request Server Option, MAY be based on some of the options in
such as the 'client identifier' option or the 'user the client request such as the 'client identifier' option
class' option [DHC-UC]. or the 'user class' option [DHC-UC].
- The client and the primary DHCP server finish their DHCP - The client and the primary DHCP server finish their DHCP
exchange in the standard way. exchange in the standard way.
- If the Next Server Option was present and it indicates - If the Next Server Option was present and it indicates
that the secondary server is an RSIP server, then the client that the secondary server is an RSIP server, then the client
SHOULD send an RSIP REGISTER_REQUEST message to the IP SHOULD send an RSIP REGISTER_REQUEST message to the server
address indicated in the option. indicated in the option.
- The RSIP protocol continues as defined in [RSIP-PROTO]. - The RSIP protocol continues as defined in [RSIP-PROTO].
Note that the two phases are independent of each other. Note that the two phases are independent of each other.
In this way, a failure of the second phase does not affect In this way, a failure of the second phase does not affect
the first one. the first one.
9. Security Considerations 9. Security Considerations
The IP address of the secondary server may depend on some The IP address of the secondary server may depend on some
skipping to change at line 251 skipping to change at line 302
false information in one of these options could have access false information in one of these options could have access
to some configuration information to which it is not entitled. to some configuration information to which it is not entitled.
Authentication [DHC-AUTH] and policy at the DHCP server SHOULD Authentication [DHC-AUTH] and policy at the DHCP server SHOULD
be used to prevent that happening. be used to prevent that happening.
10. Acknowledgements 10. Acknowledgements
Thanks to Nick Farrow, George Tsirtsis and Alan O'Neill for their Thanks to Nick Farrow, George Tsirtsis and Alan O'Neill for their
review and comments. review and comments.
Thanks to Mike Henry for his 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 11. References
[RFC2119] S. Bradner, "Key words for use in RFCs to indicate [RFC2119] S. Bradner, "Key words for use in RFCs to indicate
requirement levels," RFC 2119, Mar. 1997. requirement levels," RFC 2119, Mar. 1997.
[RFC2131] R. Droms, "Dynamic Host Configuration Protocol", [RFC2131] R. Droms, "Dynamic Host Configuration Protocol",
RFC 2131, Mar. 1997. RFC 2131, Mar. 1997.
[RFC2489] R. Droms, "Procedure for Defining New DHCP Options", [RFC2489] R. Droms, "Procedure for Defining New DHCP Options",
RFC 2489, Jan. 1999. RFC 2489, Jan. 1999.
[RSIP-FRAME] M. Borella, J. Lo, D. Grabelsky and G. Montenegro, [RSIP-FRAME] M. Borella, J. Lo, D. Grabelsky and G. Montenegro,
"Realm Specific IP: Framework" Internet Draft "Realm Specific IP: Framework" Internet Draft
<draft-ietf-nat-rsip-framework-03.txt>, Oct. 1999 (work in progress). <draft-ietf-nat-rsip-framework-03.txt>, Oct. 1999 (work in progress).
[RSIP-PROTO] M. Borella, D. Grabelsky, J. Lo and K. Taniguchi, [RSIP-PROTO] M. Borella, D. Grabelsky, J. Lo and K. Taniguchi,
"Realm Specific IP: Protocol Specification," Internet Draft "Realm Specific IP: Protocol Specification," Internet Draft
<draft-ietf-nat-rsip-protocol-03.txt>, Oct. 1999 (work in progress). <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 [DHC-UC] G. Stump, R. Droms, Y. Gu, A. Demirtjis, B. Beser, and
J. Privat, "The User Class Option for DHCP", Internet Draft J. Privat, "The User Class Option for DHCP", Internet Draft
<draft-ietf-dhc-userclass-04.txt>, Oct. 1999 (work in progress). <draft-ietf-dhc-userclass-05.txt>, Feb. 2000 (work in progress).
[DHC-AUTH] R. Droms, W. Arbaugh, "Authentication for DHCP Messages", [DHC-AUTH] R. Droms, W. Arbaugh, "Authentication for DHCP Messages",
Internet Draft <draft-ietf-dhc-authentication-11.txt>, 1999 (work in
progress). (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 12. Authors' Addresses
Jerome Privat Jerome Privat
BT Advanced Communications Technology Centre BT Advanced Communications Technology Centre
Adastral Park, Martlesham Heath, IP5 3RE Adastral Park, Martlesham Heath, IP5 3RE
UK UK
+44 1473 648910 +44 1473 606304
jerome.privat@bt.com jerome.privat@bt.com
Michael Borella Michael Borella
3Com Corp. 3Com Corp.
1800 W. Central Rd. 1800 W. Central Rd.
Mount Prospect IL 60056 Mount Prospect IL 60056
USA USA
(847) 342-6093 (847) 342-6093
mike_borella@3com.com mike_borella@3com.com
13. Expiration 13. Expiration
This document will expire on July 2000. This document will expire on August 2000.
Copyright Statement Copyright Statement
Copyright (c) The Internet Society (1999). All Rights Reserved. Copyright (c) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/