draft-ietf-dhc-nextserver-00.txt   draft-ietf-dhc-nextserver-01.txt 
Internet Engineering Task Force Jerome Privat Internet Engineering Task Force Jerome Privat
INTERNET-DRAFT BT INTERNET-DRAFT BT
Date: January 2000 Michael Borella Date: February 2000 Michael Borella
Expires: June 2000 3Com Corp Expires: July 2000 3Com Corp
DHCP Next Server Option DHCP Next Server Option
<draft-ietf-dhc-nextserver-00.txt> <draft-ietf-dhc-nextserver-01.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 127 skipping to change at line 127
broadcast on a particular port number to discover a configuration broadcast on a particular port number to discover a configuration
server. However, these broadcasts, with the exception of DHCP/BOOTP server. However, these broadcasts, with the exception of DHCP/BOOTP
traffic, will be dropped by first-hop routers. By allowing DHCP traffic, will be dropped by first-hop routers. By allowing DHCP
servers to provide a secondary server's address to a client, the servers to provide a secondary server's address to a client, the
client is able to contact that server directly, using whatever client is able to contact that server directly, using whatever
protocol is necessary. protocol is necessary.
6. Next Server Option 6. Next Server Option
This option is a DHCP option [RFC2131, RFC2489]. The Next Server This option is a DHCP option [RFC2131, RFC2489]. The Next Server
Option is returned in DHCPOFFER and DHCPACK by a DHCP server. A DHCP Option is returned in DHCPOFFER and DHCPACK by a DHCP server.
client SHOULD contact the address indicated in the Next Server Option The Next Server Option specifies a list of IP addresses for
field to retrieve the rest of its configuration. The code for this secondary servers (Multiple addresses of secondary servers
option is TBD, and its length is 5. It contains the IP address of MAY be provided for robustness). Secondary servers MUST be listed
the secondary server to be used by the client in its configuration in order of preference, if there is an order of preference.
process, as well as the protocol that the client must use to contact
the secondary server. 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, the Length minus one of the option MUST always be divisible
by 4 and has a minimum value of 5.
The address of the Secondary Server is given in network byte order.
More than one Next Server Option MAY be provided to a client. More than one Next Server Option MAY be provided to a client.
However each of these options MUST contain different protocol However each of these options MUST contain different protocol
fields. fields.
Code Len Proto Address Code Len Proto Address
+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
| TBD | 5 | p | a1 | a2 | a3 | a4 | | TBD | N | p | a1 | a2 | a3 | a4 | ... |
+-----+-----+-----+-----+-----+-----+-----+ +-----+-----+-----+-----+-----+-----+-----+-----+
Values for p, the protocol to use to contact the secondary server, Initial values for p, the protocol to use to contact the secondary server,
are defined below: are defined below:
0 Reserved 0 Reserved
1 DHCP 1 DHCP
2 RSIP 2 RSIP
New values for p MAY be registered with IANA.
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
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 address indicated 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
skipping to change at line 242 skipping to change at line 250
option or the 'user class' option [DHC-UC]. A client giving option or the 'user class' option [DHC-UC]. A client giving
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.
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>, Dec. 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-04.txt>, Oct. 1999 (work in progress). <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 [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-04.txt>, Oct. 1999 (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 Internet Draft <draft-ietf-dhc-authentication-11.txt>, 1999 (work in
progress). progress).
12. Authors' Addresses 12. Authors' Addresses
skipping to change at line 289 skipping to change at line 298
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 June 2000. This document will expire on July 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/