Internet Engineering Task Force                 Jerome Privat
INTERNET-DRAFT                                  BT
Date: January February 2000                             Michael Borella
Expires: June July 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 the
The Next Server Option
field to retrieve the rest specifies 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 contains N.
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 to option MUST always be used divisible
by 4 and has a minimum value of 5.

The address of the client Secondary 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 |  5  N  |  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
jerome.privat@bt.com

Michael Borella
3Com Corp.
1800 W. Central Rd.
Mount Prospect IL 60056
USA
(847) 342-6093
mike_borella@3com.com

13. Expiration

This document will expire on June July 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.