Internet Engineering Task Force                   Jerome Privat, BT
INTERNET-DRAFT
Date: August 1999
Expires: February 2000


                   Double Phase DHCP Configuration
                  <draft-privat-dhc-doublephase-00.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 DHCP servers, potentially under different administration.
This may be useful to satisfy specific regulatory, operational
or business model requirements.
This draft proposes two different approaches. In one approach, a
DHCP server redirects clients to a second DHCP server. In the other,
a DHCP server acts as a proxy to a second server.


1. Requirements Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1].


2. DHCP Terminology

o "DHCP client"
A DHCP client or "client" is an Internet host using DHCP to obtain
configuration parameters such as a network address.

o "DHCP server"
A DHCP server of "server"is an Internet host that returns
configuration parameters to DHCP clients.


3. Splitting the information between two DHCP servers

Our model is as follows.
- Configuration information is split between two different DHCP
servers, potentially under different administrative control.
- One DHCP server (server_1) manages IP addresses. It MAY also manage
other part of the configuration.
- Another DHCP server (server_2) manages the rest of the
configuration.
- Partition of the configuration information (other than IP address)
between the two DHCP servers is a matter of policy and agreement
between administrators of the two servers. It is out of the scope of
this document.


4. Redirect approach

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 second DHCP server from where it can retrieve
the remaining of its configuration.

4.1 Difference with the 'siaddr' field

The 'siaddr' field is used by a DHCP server to tell the client the
IP address of the server to use in the next step of the client
bootstrap process [2].
The proposed option differs from the 'siaddr' field in that the
Next Server is used by the DHCP client not to retrieve a boot
file but the rest of its DHCP configuration.

4.2 Next Server Option

This option is a DHCP option [2, 3].
The Next Server Option is returned in DHCPOFFER and DHCPACK by a
DHCP server.
A DHCP client SHOULD send a DHCPINFORM to the address indicated in
the Next Server Option field to retrieve the rest of its
configuration.
The code for this option is TBD, and its length is 4. It contains the
IP address of the next DHCP server to be used by a DHCP client in its
configuration process.

 Code   Len           Address
+-----+-----+-----+-----+-----+-----+
| TBD |  4  |  a1 |  a2 |  a3 |  a4 |
+-----+-----+-----+-----+-----+-----+

A typical double-phase configuration using the redirect approach is:
- A DHCP client broadcasts a DHCPDISCOVER. It receives a DHCPOFFER
from server_1 containing (at least) a proposed IP address.
- Based on its local policy, the server_1 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 [4].
- the DHCP client and server_1 finish their DHCP exchange in the
standard way.
- if the Next Server option was present, 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.


5. Proxy approach

In this approach, the client only communicates with server_1. Server_1
then retrieves some information from server_2 before answering
the client.

A typical double-phase configuration using the proxy approach is:
- A DHCP client broadcasts a DHCPDISCOVER.
- When server_1 receives it, it decides whether to send a DHCPOFFER
based on its local configuration information only or to retrieve
additional information from server_2.
This decision as well as the choice of server_2 MAY be based on some
of the options in the client request such as the 'client identifier'
option or the 'User Class' option [4].
- If server_1 decides to retrieve additional information from
server_2, then it sends a DHCPINFORM to server_2.
[Question: is it possible to have a server send a DHCPINFORM?
Or can only clients do it?]. 
- When server_1 receives the information from server_2, it sends a
DHCPOFFER back to the client. This DHCPOFFER message contains both
local information (at least the IP address) and information received
from server_2.
If server_1 does not receive an answer from server_2, it sends only
its local information (at least an IP address) in the DHCPOFFER to
the client.
- Server_1 and the client finish the DHCP exchange in the normal way.


6. Open Issues

- What is the better approach: redirect or proxy?
The proxy approach has the advantage of not requiring any change
in clients, and the proxy server takes responsibility for fully
completing the configuration process
Feedback from the list is welcome.
- Should we enable more than 2 phases?
- Should the sharing of information between the two DHCP servers be 
managed through exchanges between the corresponding databases instead
of through the DHCP protocol?


7. Security considerations

The IP address of server_2 may depend on some options sent by
the client such as the 'client identifier' option or the 'User Class'
option [4]. A client giving false information in one of these options
could have access to some configuration information to which it is
not entitled.
Authentication [5] and policy at the DHCP server could be used to
prevent that happening.


8. Acknowledgements

Thanks to Nick Farrow, George Tsirtsis and Alan O'Neill for their
review and comments.


9. References

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels," RFC 2119, March 1997.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
       March 1997.
[3] S. Alexander, R. Droms, "DHCP Options and BOOTP Vendor
       Extensions", RFC 2132, March 1997.
[4] G. Stump, R. Droms, "The User Class Option for DHCP",
       draft-ietf-dhc-userclass-03.txt, work in progress.
[5] R. Droms, W. Arbaugh, "Authentication for DHCP Messages",
       draft-ietf-dhc-authentication-11.txt, work in progress


10. Author information

Jerome Privat
BT Advanced Communications Technology Centre 
Adastral Park, Martlesham Heath, IP5 3RE
UK
Phone: +44 1473 648910
Email: jerome.privat@bt.com


11. Expiration

This document will expire on February 2000.