[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Internet Engineering Task Force                 Jerome Privat
INTERNET-DRAFT                                  BT
Date: March 2000                                Michael Borella
Expires: August 2000                            3Com Corp


                   DHCP Next Server Option
                  <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 two new DHCP options called the DHCP Next Server
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.


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 two new DHCP options 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 two new DHCP options called the DHCP Next Server
DNS name option and 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 these options is that they 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 Options

These options are DHCP options [RFC2131, RFC2489]. Next Server
Options 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;
it has 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 "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 server 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 a 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 server 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 server
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-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-05.txt>, Feb. 2000 (work in progress).

[DHC-AUTH] R. Droms, W. Arbaugh, "Authentication for DHCP Messages",
Internet Draft <draft-ietf-dhc-authentication-12.txt>, Oct. 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 606304
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 August 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.


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/