As per Relevance of the word selection, we have this rfc below:
Network Working Group G.
Request for Comments: 3011 Nortel
Category: Standards Track November 2000
The IPv4 Subnet Selection Option for
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This memo defines a new Dynamic Host Configuration Protocol (DHCP
option for selecting the subnet on which to allocate an address
This option would override a DHCP server's normal methods
selecting the subnet on which to allocate an address for a client
Table of
1. Introduction..................................................1
1.1. Motivational Example........................................2
2. Subnet Selection Option Definition............................3
3. Intellectual Property.........................................4
4. IANA Considerations...........................................4
5. Acknowledgements..............................................5
6. Security Considerations.......................................5
7. References....................................................5
8. Editor's Addresses............................................6
9. Full Copyright Statement......................................7
1.
The Dynamic Host Configuration Protocol (DHCP) [RFC2131] provides
framework for passing configuration information to hosts on a TCP/
network. RFC 2132 [RFC2132] specifies DHCP option
information that may be carried in DHCP packets to/from the
server and the DHCP client. This document specifies a new
option
Waters Standards Track [Page 1]
RFC 3011 Subnet Selection Option November 2000
To select the subnet on which to allocate an address, the DHCP
determines the subnet from which the request originated, and
selects an address on the originating subnet or on a subnet that
on the same network segment as the originating subnet. The
from which the request originates can be determined by
o Using the subnet address of the giaddr field in the DHCP
header, or if the giaddr field is zero
o Using the subnet address of the local interface on which the
server received the packet
This memo defines a new DHCP option, the subnet selection option
which allows the DHCP client to specify the subnet on which
allocate an address. This option takes precedence over the
that the DHCP server uses to determine the subnet on which to
an address
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [RFC2119].
1.1. Motivational
An example of where this option could be useful is in a device (e.g.:
a RAS device) that is allocating addresses on behalf of its clients
In this case the device would be allocating addresses through
and then managing those addresses among its clients
In this scenario, the device is connected to a private "internal
network on which the DHCP server would be located. The device
also connected to one or more service providing "external"
(i.e.: the networks that the device's clients are connected to).
Furthermore, the internal network is not IP connected to the
networks, although inside the device there is connectivity
the internal and external networks (e.g.: though the backplane).
Recall that the device is allocating addresses for its clients on
external networks and that there is no IP connectivity between
internal network and the external networks. The DHCP requests
originate from the external networks since packets cannot be
between the external network and the internal network. Thus,
DHCP requests must originate from the internal network. The
with originating the DHCP requests from the internal network is
the DHCP server will allocate addresses on the internal network'
subnet, when what is required are addresses on the external subnets
The subnet selection option provides a solution to this problem
Waters Standards Track [Page 2]
RFC 3011 Subnet Selection Option November 2000
The device would send its DHCP request on the internal subnet,
would include the subnet selection option containing the address
the external subnet on which it requires the address. The
selection option instructs the DHCP server to allocate the address
the requested subnet as opposed to the normal operation of
the address on the subnet from which the DHCP request originated
2. Subnet Selection Option
The subnet selection option is a DHCP option. The option contains
single IPv4 address that is the address of a subnet. The value
the subnet address is determined by taking any IPv4 address on
subnet and ANDing that address with the subnet mask (i.e.:
network and subnet bits are left alone and the remaining (address
bits are set to zero). When the DHCP server is configured to
to this option, is allocating an address, and this option is
then the DHCP server MUST allocate the address on either
o the subnet specified in the subnet selection option, or
o a subnet on the same network segment as the subnet specified in
subnet selection option
The format of the option is
Code Len IPv4
+-----+-----+-----+-----+-----+-----+
| 118 | 4 | A1 | A2 | A3 | A4 |
+-----+-----+-----+-----+-----+-----+
Servers configured to support this option MUST return an
copy of the option to any client that sends it, regardless of
or not the client requests the option in a parameter request list
Clients using this option MUST discard DHCPOFFER or DHCPACK
that do not contain this option
This option does not require changes to operations or features of
DHCP server other than to select the subnet on which to allocate
address. For example, the handling of DHCPDISCOVER for an
subnet should continue to operate unchanged
When this option is present and the server is configured to
this option, the server MUST NOT offer an address that is not on
requested subnet or network segment. Servers that do not
this option will allocate an address using their normal
and will not return this option in the DHCPOFFER or DHCPACK. In
case the client will discard the DHCPOFFER or DHCPACK. Servers
understand this option but are administratively configured to
Waters Standards Track [Page 3]
RFC 3011 Subnet Selection Option November 2000
the option MUST ignore the option, use their normal algorithms
allocate an address, and MUST NOT return this option in the
or DHCPACK. In this case the client will discard the DHCPOFFER
DHCPACK
During an address renew, the DHCP server may send a DHCPACK
to the allocated address, however packets from the DHCP server
not be routable to the address. Thus, in all packets that the
client sends that contain the subnet selection option, the
field in the BOOTP header MUST be set to an IPv4 address on which
DHCP client will accept DHCP packets (e.g.: the address on the
connected to the internal network).
The IPv4 address to which a DHCP server sends a reply to MUST be
same as it would chose when this option is not present
3. Intellectual
The IETF takes no position regarding the validity or scope of
intellectual property or other rights that might be claimed
pertain to the implementation or use of the technology described
this document or the extent to which any license under such
might or might not be available; neither does it represent that
has made any effort to identify any such rights. Information on
IETF's procedures with respect to rights in standards-track
standards-related documentation can be found in BCP-11.
Copies of claims of rights made available for publication and
assurances of licenses to be made available, or the result of
attempt made to obtain a general license or permission for the use
such proprietary rights by implementers or users of
specification can be obtained from the IETF Secretariat
The IETF invites any interested party to bring to its attention
copyrights, patents or patent applications, or other
rights which may cover technology that may be required to
this standard. Please address the information to the IETF
Director
4. IANA
IANA has assigned a value of 118 for the DHCP option code
in this document
Waters Standards Track [Page 4]
RFC 3011 Subnet Selection Option November 2000
5.
This document is the result of work undertaken the by DHCP
group. Thanks to Ted Lemon, Tim Aston and Ralph Droms for
helpful comments in this work
W. Mark Townsley and Pratik Gupta originally published a
selection option Internet Draft in July 1997. The work in
document was not based on the original work but it does achieve
same goals
6. Security
DHCP currently provides no authentication or security mechanisms
Potential exposures to attack are discussed is section 7 of
protocol specification [RFC2131].
The subnet selection option allows for the DHCP client to specify
subnet on which to allocate an address. This would allow a client
perform a more complete address-pool exhaustion attack since
client would no longer be restricted to attacking address-pools
just its local subnet
Servers that implement the subnet selection option MUST by
disable use of the feature; it must specifically be enabled
configuration. Moreover, a server SHOULD provide the ability
selectively enable use of the feature under restricted conditions
e.g., by enabling use of the option only from explicitly
client-ids, enabling its use only by clients on a particular subnet
or restricting the subnets (as indicated in the subnet
option) from which addresses may be requested
7.
[RFC2119] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] Droms, R. "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP
Extensions", RFC 2132, March 1997.
Waters Standards Track [Page 5]
RFC 3011 Subnet Selection Option November 2000
8. Editor's
Glenn
Nortel
310-875 Carling Avenue
Ottawa, Ontario K1S 5P
Phone: +1 613-765-0249
EMail: gww@nortelnetworks.
Waters Standards Track [Page 6]
RFC 3011 Subnet Selection Option November 2000
9. Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Waters Standards Track [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
