doc: Add RFC documents

1 files changed, 507 insertions, 0 deletions

diff --git a/doc/rfc/rfc3527.txt b/doc/rfc/rfc3527.txt
new file mode 100644
index 0000000..1fb131e
--- /dev/null
+++ b/doc/rfc/rfc3527.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group                                         K. Kinnear
+Request for Comments: 3527                                      M. Stapp
+Category: Standards Track                                     R. Johnson
+                                                           J. Kumarasamy
+                                                           Cisco Systems
+                                                              April 2003
+
+
+                       Link Selection sub-option
+           for the Relay Agent Information Option for DHCPv4
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2003).  All Rights Reserved.
+
+Abstract
+
+   This document describes the link selection sub-option of the relay-
+   agent-information option for the Dynamic Host Configuration Protocol
+   (DHCPv4).  The giaddr specifies an IP address which determines both a
+   subnet, and thereby a link on which a Dynamic Host Configuration
+   Protocol (DHCP) client resides as well as an IP address that can be
+   used to communicate with the relay agent.  The subnet-selection
+   option allows the functions of the giaddr to be split so that when
+   one entity is performing as a DHCP proxy, it can specify the
+   subnet/link from which to allocate an IP address, which is different
+   from the IP address with which it desires to communicate with the
+   DHCP server.  Analogous situations exist where the relay agent needs
+   to specify the subnet/link on which a DHCP client resides, which is
+   different from an IP address that can be used to communicate with the
+   relay agent.
+
+1.  Introduction
+
+   In RFC 2131, the giaddr specifies an IP address which determines a
+   subnet (and from there a link) on which a DHCP client resides as well
+   as an IP address which can be used to communicate with the relay
+   agent.  The subnet-selection option [RFC 3011] allows these functions
+   of the giaddr to be split, so that when one entity is performing as a
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 1]
+
+RFC 3527               Link Selection sub-option              April 2003
+
+
+   DHCP proxy, it can specify the subnet/link from which to allocate an
+   IP address that is different from the IP address with which it
+   desires to communicate with the DHCP server.
+
+   Analogous situations exist where the relay agent needs to specify the
+   subnet/link on which a DHCP client resides, which is different from
+   an IP address that can be used to communicate with the relay agent.
+   Consider the following architecture:
+
+      +--------+         +---------------+
+      |  DHCP  |     IP x|               |IP y
+      | Server |-.......-|  Relay Agent  |----+------------+
+      +--------+         |               |    |            |
+                         +---------------+    |         +------+
+                                              |         |Modem |
+                                              |         +------+
+                                              |          |    |
+                                           +-----+  +-----+ +-----+
+                                           |Host1|  |Host2| |Host3|
+                                           +-----+  +-----+ +-----+
+
+   In the usual approach, the relay agent would put IP address Y into
+   the giaddr of any packets that it forwarded to the DHCP server.
+   However, if for any reason, IP address Y is not accessible from the
+   DHCP server, this approach will fail.  There are several reasons why
+   IP y might be inaccessible from the DHCP server:
+
+      o  There might be some firewall capability in the network element
+         in which the relay agent resides that does not allow the DHCP
+         server to access the relay agent via IP y.
+
+      o  There might not be an IP y.  An example would be the case where
+         there was only one host and this was a point to point link.
+
+   In any of these or other cases, the relay agent needs to be able to
+   communicate to the DHCP server the subnet/link from which to allocate
+   an IP address.  The IP address, which will communicate to the DHCP
+   server the subnet/link information, cannot be used as a way to
+   communicate between the DHCP server and the relay agent.
+
+   Since the relay agent can modify the client's DHCP DHCPREQUEST in
+   only two ways, the giaddr and the relay-agent-info option, there is a
+   need to extend the relay-agent-info option with a new sub-option, the
+   link-selection sub-option, to allow separation of the specification
+   of the subnet/link from the IP address to use when communicating with
+   the relay agent.
+
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 2]
+
+RFC 3527               Link Selection sub-option              April 2003
+
+
+2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in BCP 14, RFC 2119 [RFC
+   2119].
+
+   This document uses the following terms:
+
+      o  "DHCP client"
+
+         A DHCP client is an Internet host using DHCP to obtain
+         configuration parameters such as a network address.
+
+      o  "DHCP relay agent"
+
+         A DHCP relay agent is a third-party agent that transfers BOOTP
+         and DHCP messages between clients and servers residing on
+         different subnets, per [RFC 951] and [RFC 1542].
+
+      o  "DHCP server"
+
+         A DHCP server is an Internet host that returns configuration
+         parameters to DHCP clients.
+
+      o  "link"
+
+         A link is a communications facility or medium over which nodes
+         can communicate at the link layer, i.e., the layer immediately
+         below IPv4.  Examples are Ethernets (simple or bridged); PPP
+         links; X.25, Frame Relay, or ATM networks; and internet (or
+         higher) layer "tunnels", such as tunnels over IPv4 or IPv6
+         itself.
+
+      o  "subnet"
+
+         A subnet (for the purposes of this document) consists of a
+         routable address range.  It may be one of several that exist on
+         a link at the same time.
+
+3.  Link selection sub-option definition
+
+   The link-selection sub-option is used by any DHCP relay agent that
+   desires to specify a subnet/link for a DHCP client request that it is
+   relaying but needs the subnet/link specification to be different from
+   the IP address the DHCP server should use when communicating with the
+   relay agent.
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 3]
+
+RFC 3527               Link Selection sub-option              April 2003
+
+
+   The sub-option contains a single IP address that is an address
+   contained in a subnet. The value for the 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 subnet bits are left alone and
+   the remaining (address) bits are set to zero).  This determines a
+   single subnet, and when allocating an IP address, all of the other
+   related subnets on the same link will also be considered in the same
+   way as currently specified for the processing of the giaddr in [RFC
+   2131, Section 4.3.1, first group of bullets, bullet 4].
+
+   In scenarios where this sub-option is needed, the relay agent adds it
+   whenever it sets the giaddr value (i.e., on all messages relayed to
+   the DHCP server).
+
+   When the DHCP server is allocating an address and this sub-option is
+   present, then the DHCP server MUST allocate the address on either:
+
+      o  the subnet specified in the link-selection sub-option, or;
+
+      o  a subnet on the same link (also known as a network segment) as
+         the subnet specified by the link-selection sub-option.
+
+   The format of the sub-option is:
+
+             SubOpt   Len     subnet IP address
+            +------+------+------+------+------+------+
+            |  5   |   4  |  a1  |  a2  |  a3  |  a4  |
+            +------+------+------+------+------+------+
+
+   A relay agent which uses this sub-option MUST assume that the server
+   receiving the sub-option supports the sub-option and uses the
+   information available in the sub-option to correctly allocate an IP
+   address.  A relay agent which uses this sub-option MUST NOT take
+   different actions based on whether this sub-option appears or does
+   not appear in the response packet from the server.
+
+   It is important to ensure, using administrative techniques, that any
+   relay agent employing this sub-option is directed to only send
+   packets to a server that supports this sub-option.
+
+   Support for this sub-option does not require changes to operations or
+   features of the DHCP server other than to select the subnet (and
+   link) on which to allocate an address.  For example, the handling of
+   DHCPDISCOVER for an unknown subnet should continue to operate
+   unchanged.
+
+
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 4]
+
+RFC 3527               Link Selection sub-option              April 2003
+
+
+   In the event that a DHCP server receives a packet that contains both
+   a subnet-selection option [RFC 3011], as well as a link-selection
+   sub-option, the information contained in the link-selection sub-
+   option MUST be used to control the allocation of an IP address in
+   preference to the information contained in the subnet-selection
+   option.
+
+   When this sub-option is present and the server supports this sub-
+   option, the server MUST NOT offer an address that is not on the
+   requested subnet or the link (network segment) with which that subnet
+   is associated.
+
+   The IP address to which a DHCP server sends a reply MUST be the same
+   as it would choose when this sub-option is not present.
+
+4.  Security Considerations
+
+   Potential attacks on DHCP are discussed in section 7 of the DHCP
+   protocol specification [RFC 2131], as well as in the DHCP
+   authentication specification [RFC 3118].
+
+   The link-selection sub-option allows a relay agent to specify the
+   subnet/link on which to allocate an address for a DHCP client.  Given
+   that the subnet-selection option already exists [RFC 3011], no
+   fundamental new security issues are raised by the existence of the
+   link-selection sub-option specified in this document beyond those
+   implied by the subnet-selection option [RFC 3011].
+
+   The existence of either the subnet-selection option or link-selection
+   sub-option documented here would allow a malicious DHCP client to
+   perform a more complete address-pool exhaustion attack than could be
+   performed without the use of these options, since the client would no
+   longer be restricted to attacking address-pools on just its local
+   subnet.
+
+   There is some minor protection against this form of attack using this
+   sub-option that is not present for the subnet-selection option, in
+   that a trusted relay agent that supports the relay-agent-info option
+   MUST discard a packet it receives with a zero giaddr and a relay-
+   agent-info option when that packet arrives on an "untrusted" circuit
+   [RFC 3046, section 2.1].
+
+5.  IANA Considerations
+
+   IANA has assigned a value of 5 from the DHCP Relay Agent sub-options
+   space [RFC 3046] for the link-selection sub-option defined in Section
+   3.
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 5]
+
+RFC 3527               Link Selection sub-option              April 2003
+
+
+6.  Acknowledgments
+
+   Eric Rosen helped the authors to understand the need for this sub-
+   option.  Much of this document was borrowed, with only minimal
+   modifications, from the document describing the subnet-selection
+   option [RFC 3011].
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
+              2131, March 1997.
+
+   [RFC 3011] Waters, G. "The IPv4 Subnet Selection Option for DHCP",
+              RFC 3011, November 2000.
+
+   [RFC 3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
+              3046, January 2001.
+
+7.2.  Informative References
+
+   [RFC 951]  Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951,
+              September 1985.
+
+   [RFC 1542] Wimer, W., "Clarifications and Extensions for the
+              Bootstrap Protocol", RFC 1542, October 1993.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 6]
+
+RFC 3527               Link Selection sub-option              April 2003
+
+
+8.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this 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 effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 7]
+
+RFC 3527               Link Selection sub-option              April 2003
+
+
+9.  Authors' Addresses
+
+   Kim Kinnear
+   Cisco Systems
+   1414 Massachusetts Ave
+   Boxborough, Ma. 01719
+
+   Phone: (978) 936-0000
+   EMail: kkinnear@cisco.com
+
+
+   Mark Stapp
+   Cisco Systems
+   1414 Massachusetts Ave
+   Boxborough, Ma. 01719
+
+   Phone: (978) 936-0000
+   EMail: mjs@cisco.com
+
+
+   Jay Kumarasamy
+   Cisco Systems
+   170 W. Tasman Dr.
+   San Jose, CA 95134
+
+   Phone: (408) 526-4000
+   EMail: jayk@cisco.com
+
+
+   Richard Johnson
+   Cisco Systems
+   170 W. Tasman Dr.
+   San Jose, CA 95134
+
+   Phone: (408) 526-4000
+   EMail: raj@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 8]
+
+RFC 3527               Link Selection sub-option              April 2003
+
+
+10.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2003).  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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 9]
+