draft-ietf-dhc-subnet-option-02.txt   draft-ietf-dhc-subnet-option-03.txt 
Network Working Group G. Waters Network Working Group G. Waters
INTERNET-DRAFT Nortel Networks INTERNET-DRAFT Nortel Networks
June 1999 June 1999
The Subnet Selection Option for DHCP The Subnet Selection Option for DHCP
<draft-ietf-dhc-subnet-option-02.txt> <draft-ietf-dhc-subnet-option-03.txt>
Thursday, June 24, 1999, 10:43 AM
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.
skipping to change at line 49 skipping to change at line 50
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 the subnet on which to allocate an address normal methods of selecting the subnet on which to allocate an address
for a client. for a client.
Waters Expires: Jun 1999 + 6 months [Page 1] 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 1.1. Motivational Example.........................................2
2. Subnet Selection Option Definition................................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........................................................5 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 To select the subnet on which to allocate an address, the DHCP server
DHCP option that specifies the subnet that a DHCP server should use determines the subnet from which the request originated, and then
when selecting an address. This option takes precedence over other selects an address on the originating subnet or on a subnet that is on
methods that the DHCP server may use to determine the subnet on which the same network segment as the originating subnet. The subnet from
to select an address. Two existing methods of determining the subnet which the request originates can be determined by:
on which to select an address are:
o To use the subnet address of the giaddr field in the DHCP packet, o Using the subnet address of the giaddr field in the DHCP packet
or if the giaddr field is zero; header, or if the giaddr field is zero;
o To use the subnet address of the local interface on which the o Using the subnet address of the local interface on which the DHCP
packet was received by the DHCP server. server received the packet.
Methods other than the two described above may exist. This memo defines a new DHCP option, the subnet selection option,
which allows the DHCP client to specify the subnet on which to
allocate an address. This option takes precedence over the methods
that the DHCP server uses to determine the subnet on which to select
an address.
The subnet selection option is useful for, but not limited to, the The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
class of devices that have a packet-handling plane (e.g.: switching, "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
routing functionality) and a control plane (e.g.: device management document are to be interpreted as described in [RFC2119].
and control functionality). The control plane is network connected and
there is a DHCP server connected to that network. The packet-handling
plane may or may not be network connected, however, in either case
there is no network connected DHCP server available to this plane. The
control plane is not network connected to the packet-handling plane,
although the two planes may communicate using some method (e.g.: an
internal data bus).
There is a requirement to allocate addresses for devices connected to 1.1. Motivational Example
the networks to which the packet-handling plane is connected.
Since there is no network connectivity between the DHCP server and the An example of where this option could be useful is in a device (e.g.:
packet-handling plane, the control plane must allocate addresses using a RAS device) that is allocating addresses on behalf of its clients.
the DHCP on behalf of the packet-handling plane. Since the control In this case the device would be allocating addresses through DHCP and
plane is requesting the address, the DHCP server would normally then managing those addresses among its clients.
Waters Expires: Jun 1999 + 6 months [Page 2] In this scenario, the device is connected to a private "internal"
allocate the address on the subnet on which the control plane is network on which the DHCP server would be located. The device is also
connected, which would not be the desired result. connected to one or more service providing "external" networks (i.e.:
the networks that the device's clients are connected to). Furthermore,
the internal network is not IP connected to the external networks,
although inside the device there is connectivity between the internal
and external networks (e.g.: though the backplane).
If the option specified by this memo is included in the Waters Expires: Jun 1999 + 6 months [Page 2]
DHCPDISCOVER/DHCPREQUEST message then the server should allocate an Recall that the device is allocating addresses for its clients on the
address on the subnet or network segment that is specified by this external networks and that there is no IP connectivity between the
option. The option would specify an address on one of the packet- internal network and the external networks. The DHCP requests cannot
handling plane's subnets. originate from the external networks since packets cannot be routed
between the external network and the internal network. Thus, the DHCP
requests must originate from the internal network. The problem with
originating the DHCP requests from the internal network is that the
DHCP server will allocate addresses on the internal network's subnet,
when what is required are addresses on the external subnets. The
subnet selection option provides a solution to this problem.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The device would send its DHCP request on the internal subnet, but
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this would include the subnet selection option containing the address of
document are to be interpreted as described in [RFC2119]. the external subnet on which it requires the address. The subnet
selection option instructs the DHCP server to allocate the address on
the requested subnet as opposed to the normal operation of allocating
the address on the subnet from which the DHCP request originated.
2. Subnet Selection Option 2. Subnet Selection Option Definition
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 the DHCP server is allocating an address and this option
is present then the DHCP server MUST allocate the address on either:
o The subnet specified in the option, or;
o A subnet on the same network segment as the subnet specified in the o the subnet specified in the subnet selection option, or;
option;
on which to allocate an address. o a subnet on the same network segment as the subnet specified in the
subnet selection option.
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 Servers supporting this option MUST return an identical copy of the
this option when communicating with DHCP servers that do not support option to any client that sends it, regardless of whether or not the
this option, the DHCP client SHOULD check that an allocated address is client requests the option in a parameter request list. Clients using
on the requested subnet or network segment. The client SHOULD NOT this option MUST discard DHCPOFFER or DHCPACK packets that do not
respond to a DHCPOFFER or DHCPACK of an address that is not on the contain this option.
requested subnet or network segment.
Servers supporting this option MUST return the option to any client
that sends it, regardless of whether or not the client requests it in
a parameter request list. Clients using this option must discard
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 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 DHCP server other than to select the subnet on which to allocate an
address. For example, the handling of DHCPDISCOVER for an unknown address. For example, the handling of DHCPDISCOVER for an unknown
subnet may continue to operate unchanged. subnet should continue to operate unchanged.
Waters Expires: Jun 1999 + 6 months [Page 3]
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.
During an address renew, the DHCP server may send a DHCPACK directly
to the allocated address, however packets from the DHCP server may not
be routable to the address. Thus, in all packets that the DHCP client
sends that contain the subnet selection option, the giaddr field in
the BOOTP header MUST be set to an IP address on which the DHCP client
will accept DHCP packets (e.g.: the address of the subnet connected to
the internal network).
The IP address to which a DHCP server sends a reply to MUST be the The IP address to which a DHCP server sends a reply to MUST be the
same as it would chose when this option is not present. 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
skipping to change at line 191 skipping to change at line 202
group. Thanks to Ted Lemon, Tim Aston and Ralph Droms for their group. Thanks to Ted Lemon, Tim Aston and Ralph Droms for their
helpful comments in this work. 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] Waters Expires: Jun 1999 + 6 months [Page 4]
The subnet selection option allows for the DHCP client to specify the
subnet on which to allocate an address. This would allow a client to
perform a more complete address-pool exhaustion attack since the
client would no longer be restricted to attacking address-pools on
just its local subnet. Under the current DHCP security model there is
no methods available to circumvent this type of attack.
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.
7. Editor's Addresses 7. Editor's Addresses
Glenn Waters Glenn Waters
Nortel Networks Nortel Networks
310-875 Carling Avenue, 310-875 Carling Avenue,
skipping to change at line 233 skipping to change at line 251
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to in the Internet Standards process must be followed, or as required to
translate it into languages other than English. translate it into languages other than English.
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.
Waters Expires: Jun 1999 + 6 months [Page 5]
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] Waters Expires: Jun 1999 + 6 months [Page 6]
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/