draft-ietf-dhc-subnet-option-01.txt | draft-ietf-dhc-subnet-option-02.txt | |||
---|---|---|---|---|
Network Working Group G. Waters | Network Working Group G. Waters | |||
INTERNET-DRAFT Nortel Networks | INTERNET-DRAFT Nortel Networks | |||
March 1999 | June 1999 | |||
The Subnet Selection Option for DHCP | The Subnet Selection Option for DHCP | |||
<draft-ietf-dhc-subnet-option-01.txt> | <draft-ietf-dhc-subnet-option-02.txt> | |||
Tuesday, March 23, 1999, 4:35 PM | ||||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with all | This document is an Internet-Draft and is in full conformance with all | |||
provisions of Section 10 of RFC2026. | provisions of Section 10 of RFC2026. | |||
Internet-Drafts are working documents of the Internet Engineering Task | Internet-Drafts are working documents of the Internet Engineering Task | |||
Force (IETF), its areas, and its working groups. Note that other | Force (IETF), its areas, and its working groups. Note that other | |||
groups may also distribute working documents as Internet-Drafts. | groups may also distribute working documents as Internet-Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | 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. | ||||
To learn the current status of any Internet-Draft, please check the | To learn the current status of any Internet-Draft, please check the | |||
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow | "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow | |||
Directories on ds.internic.net (US East Coast), nic.nordu.net | Directories on ds.internic.net (US East Coast), nic.nordu.net | |||
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). | (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (1999). All Rights Reserved. | Copyright (C) The Internet Society (1999). All Rights Reserved. | |||
Abstract | Abstract | |||
This memo defines a new DHCP option for selecting the subnet on which | This memo defines a new DHCP option for selecting the subnet on which | |||
to allocate an address. This option would override a DHCP server's | to allocate an address. This option would override a DHCP server's | |||
normal methods of selecting which subnet on which to allocate an | normal methods of selecting the subnet on which to allocate an address | |||
address for a client. | for a client. | |||
Waters Expires: Jun 1999 + 6 months [Page 1] | ||||
Table of Contents | Table of Contents | |||
1. Introduction......................................................2 | 1. Introduction......................................................2 | |||
2. Subnet Selection Option...........................................3 | 2. Subnet Selection Option...........................................3 | |||
3. Intellectual Property.............................................4 | 3. Intellectual Property.............................................4 | |||
4. Acknowledgements..................................................4 | 4. Acknowledgements..................................................4 | |||
5. Security Considerations...........................................4 | 5. Security Considerations...........................................4 | |||
6. References........................................................4 | 6. References........................................................5 | |||
7. Editor's Addresses................................................5 | 7. Editor's Addresses................................................5 | |||
8. Full Copyright Statement..........................................5 | 8. Full Copyright Statement..........................................5 | |||
1. Introduction | 1. Introduction | |||
This memo was produced by the DHCP Working Group and defines a new | This memo was produced by the DHCP Working Group and defines a new | |||
DHCP option that specifies the subnet on which a DHCP server should | DHCP option that specifies the subnet that a DHCP server should use | |||
use when selecting an address. This option takes precedence over | when selecting an address. This option takes precedence over other | |||
other methods that the DHCP server may use to determine the subnet on | methods that the DHCP server may use to determine the subnet on which | |||
which to select an address. Two existing methods of determining the | to select an address. Two existing methods of determining the subnet | |||
subnet on which to select an address are: | on which to select an address are: | |||
o To use the subnet address of the giaddr field in the DHCP packet, | o To use the subnet address of the giaddr field in the DHCP packet, | |||
or if the giaddr field is zero; | or if the giaddr field is zero; | |||
o To use the subnet address of the local interface on which the | o To use the subnet address of the local interface on which the | |||
packet was received by the DHCP server. | packet was received by the DHCP server. | |||
Methods other than the two described above may exist. | Methods other than the two described above may exist. | |||
The subnet selection option is useful, but not limited to, the class | The subnet selection option is useful for, but not limited to, the | |||
of devices that have a packet-handling plane (e.g.: switching, routing | class of devices that have a packet-handling plane (e.g.: switching, | |||
functionality) and a control plane (e.g.: device management and | routing functionality) and a control plane (e.g.: device management | |||
control functionality). The control plane is network connected and | and control functionality). The control plane is network connected and | |||
there is a DHCP server connected to that network. The packet-handling | there is a DHCP server connected to that network. The packet-handling | |||
plane may or may not be network connected, however, in either case | plane may or may not be network connected, however, in either case | |||
there is no network connected DHCP server available to this plane. The | there is no network connected DHCP server available to this plane. The | |||
control plane is not network connected to the packet-handling plane, | control plane is not network connected to the packet-handling plane, | |||
although the two planes may communicate using some method (e.g.: an | although the two planes may communicate using some method (e.g.: an | |||
internal data bus). | internal data bus). | |||
For the networks to which the packet-handling plane is connected, | There is a requirement to allocate addresses for devices connected to | |||
there is a requirement to allocate addresses for devices connected to | the networks to which the packet-handling plane is connected. | |||
those networks. | ||||
Since there is no network connectivity between the DHCP server and the | Since there is no network connectivity between the DHCP server and the | |||
packet-handling plane, the control plane must allocate addresses using | packet-handling plane, the control plane must allocate addresses using | |||
the DHCP on behalf of the packet-handling plane. Because the control | the DHCP on behalf of the packet-handling plane. Since the control | |||
plane is requesting the addresses, the DHCP server would normally have | plane is requesting the address, the DHCP server would normally | |||
the undesired result of allocating the address on the subnet on which | ||||
the control plane is connected. | Waters Expires: Jun 1999 + 6 months [Page 2] | |||
allocate the address on the subnet on which the control plane is | ||||
connected, which would not be the desired result. | ||||
If the option specified by this memo is included in the | If the option specified by this memo is included in the | |||
DHCPDISCOVER/DHCPREQUEST message then the server should allocate an | DHCPDISCOVER/DHCPREQUEST message then the server should allocate an | |||
address on the subnet or network segment that is specified by this | address on the subnet or network segment that is specified by this | |||
option. The option would specify an address of one of the packet- | option. The option would specify an address on one of the packet- | |||
handling plane's subnets. | handling plane's subnets. | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
2. Subnet Selection Option | 2. Subnet Selection Option | |||
The subnet selection option is a DHCP option. The option contains a | The subnet selection option is a DHCP option. The option contains a | |||
single IP address that is the address of a subnet. The value for the | single IP address that is the address of a subnet. The value for the | |||
subnet address is determined by taking any IP address on the subnet | subnet address is determined by taking any IP address on the subnet | |||
and ANDing that address with the subnet mask (i.e.: the network and | and ANDing that address with the subnet mask (i.e.: the network and | |||
subnet bits are left alone and the remaining (address) bits are set to | subnet bits are left alone and the remaining (address) bits are set to | |||
zero). When this option is present, the DHCP server MUST use either | zero). When this option is present, the DHCP server MUST use either: | |||
the: | ||||
o The subnet specified in the option, or; | o The subnet specified in the option, or; | |||
o A subnet on the same network segment as the subnet specified in the | o A subnet on the same network segment as the subnet specified in the | |||
option; | option; | |||
on which to allocate an address. | on which to allocate an address. | |||
The format of the option is: | The format of the option is: | |||
Code Len IP Address | Code Len IP Address | |||
+-----+-----+-----+-----+-----+-----+ | +-----+-----+-----+-----+-----+-----+ | |||
| TBD | 4 | A1 | A2 | A3 | A4 | | | TBD | 4 | A1 | A2 | A3 | A4 | | |||
skipping to change at page 3, line 40 | skipping to change at line 132 | |||
The format of the option is: | The format of the option is: | |||
Code Len IP Address | Code Len IP Address | |||
+-----+-----+-----+-----+-----+-----+ | +-----+-----+-----+-----+-----+-----+ | |||
| TBD | 4 | A1 | A2 | A3 | A4 | | | TBD | 4 | A1 | A2 | A3 | A4 | | |||
+-----+-----+-----+-----+-----+-----+ | +-----+-----+-----+-----+-----+-----+ | |||
In order to ensure backwards compatibility of clients that do support | In order to ensure backwards compatibility of clients that do support | |||
this option when communicating with DHCP servers that do not support | this option when communicating with DHCP servers that do not support | |||
this option, the DHCP client SHOULD check that an allocated address in | this option, the DHCP client SHOULD check that an allocated address is | |||
on the requested subnet or network segment. The client SHOULD NOT | on the requested subnet or network segment. The client SHOULD NOT | |||
respond to a DHCPOFFER or DHCPACK of an address that is not on the | respond to a DHCPOFFER or DHCPACK of an address that is not on the | |||
requested subnet or network segment. | requested subnet or network segment. | |||
This option does not require any change to other operations or | Servers supporting this option MUST return the option to any client | |||
features of the DHCP server other than to select the subnet on which | that sends it, regardless of whether or not the client requests it in | |||
to allocate an address. For example, the handling of DHCPDISCOVER for | a parameter request list. Clients using this option must discard | |||
an unknown subnet may continue to operate unchanged. | DHCPOFFER or DHCPACK packets that do not contain this option. | |||
Waters Expires: Jun 1999 + 6 months [Page 3] | ||||
This option does not require changes to operations or features of the | ||||
DHCP server other than to select the subnet on which to allocate an | ||||
address. For example, the handling of DHCPDISCOVER for an unknown | ||||
subnet may continue to operate unchanged. | ||||
When this option is present and the server supports this option, the | When this option is present and the server supports this option, the | |||
server MUST NOT offer an address that is not on the requested subnet | server MUST NOT offer an address that is not on the requested subnet | |||
or network segment. | or network segment. | |||
Existing methods for determining where to send a reply to a DHCP | The IP address to which a DHCP server sends a reply to MUST be the | |||
client are not changed when this option is present in a request. | same as it would chose when this option is not present. | |||
3. Intellectual Property | 3. Intellectual Property | |||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
intellectual property or other rights that might be claimed to pertain | intellectual property or other rights that might be claimed to pertain | |||
to the implementation or use of the technology described in this | to the implementation or use of the technology described in this | |||
document or the extent to which any license under such rights might or | document or the extent to which any license under such rights might or | |||
might not be available; neither does it represent that it has made any | might not be available; neither does it represent that it has made any | |||
effort to identify any such rights. Information on the IETF's | effort to identify any such rights. Information on the IETF's | |||
procedures with respect to rights in standards-track and standards- | procedures with respect to rights in standards-track and standards- | |||
skipping to change at page 4, line 34 | skipping to change at line 181 | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights which may cover technology that may be required to practice | rights which may cover technology that may be required to practice | |||
this standard. Please address the information to the IETF Executive | this standard. Please address the information to the IETF Executive | |||
Director. | Director. | |||
4. Acknowledgements | 4. Acknowledgements | |||
This document is the result of work undertaken the by DHCP working | This document is the result of work undertaken the by DHCP working | |||
group. Thanks to Tim Aston and Ralph Droms for reviewing this memo. | group. Thanks to Ted Lemon, Tim Aston and Ralph Droms for their | |||
helpful comments in this work. | ||||
5. Security Considerations | 5. Security Considerations | |||
DHCP currently provides no authentication or security mechanisms. | DHCP currently provides no authentication or security mechanisms. | |||
Potential exposures to attack are discussed is section 7 of the | Potential exposures to attack are discussed is section 7 of the | |||
protocol specification [RFC2131]. | protocol specification [RFC2131]. | |||
Waters Expires: Jun 1999 + 6 months [Page 4] | ||||
6. References | 6. References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", RFC 2119, BCP 14, March 1997. | Requirement Levels", RFC 2119, BCP 14, March 1997. | |||
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, | [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, | |||
March 1997. | March 1997. | |||
[RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor | [RFC2132] Alexander, S. and Droms, R., "DHCP Options and BOOTP Vendor | |||
Extensions", RFC 2132, March 1997. | Extensions", RFC 2132, March 1997. | |||
skipping to change at line 225 | skipping to change at line 239 | |||
The limited permissions granted above are perpetual and will not be | The limited permissions granted above are perpetual and will not be | |||
revoked by the Internet Society or its successors or assigns. | revoked by the Internet Society or its successors or assigns. | |||
This document and the information contained herein is provided on an | This document and the information contained herein is provided on an | |||
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |||
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT | |||
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN | NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN | |||
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | |||
Waters Expires: Jun 1999 + 6 months [Page 5] | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |