doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc5010.txt b/doc/rfc/rfc5010.txt
new file mode 100644
index 0000000..167c629
--- /dev/null
+++ b/doc/rfc/rfc5010.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                         K. Kinnear
+Request for Comments: 5010                                   M. Normoyle
+Category: Standards Track                                       M. Stapp
+                                                     Cisco Systems, Inc.
+                                                          September 2007
+
+
+      The Dynamic Host Configuration Protocol Version 4 (DHCPv4)
+                      Relay Agent Flags Suboption
+
+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.
+
+Abstract
+
+   This memo defines a new suboption of the Dynamic Host Configuration
+   Protocol (DHCP) relay agent information option that allows the DHCP
+   relay to specify flags for the forwarded packet.  One flag is defined
+   to indicate whether the DHCP relay received the packet via a unicast
+   or broadcast packet.  This information may be used by the DHCP server
+   to better serve clients based on whether their request was originally
+   broadcast or unicast.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Requirements Terminology  . . . . . . . . . . . . . . . . . . . 2
+   3.  The Flags Suboption . . . . . . . . . . . . . . . . . . . . . . 3
+   4.  DHCP Relay Agent Behavior . . . . . . . . . . . . . . . . . . . 3
+   5.  DHCP Server Behavior  . . . . . . . . . . . . . . . . . . . . . 4
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
+   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
+   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 5
+   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     9.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
+     9.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
+
+
+
+
+
+
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 1]
+
+RFC 5010              Relay Agent Flags Suboption         September 2007
+
+
+1.  Introduction
+
+   Any time a client's DHCP packet is broadcast, a local DHCP relay will
+   process its request and forward it on to the DHCP server.  When the
+   DHCP relay performs this function, it can be configured to use the
+   DHCP relay agent information option to forward additional information
+   to the DHCP server, which the server may then use to alter its
+   processing algorithms.  Once the lease has been granted, however,
+   future DHCP DHCPREQUEST/RENEWAL messages are unicast directly to the
+   DHCP Server [RFC2131] [RFC2132] [RFC3046].
+
+   In general, DHCP servers may also make subtle (and sometimes not so
+   subtle) changes in their processing algorithms depending on whether
+   or not the DHCP server received the message as a unicast packet from
+   the DHCP client directly, a broadcast packet from the DHCP client on
+   a locally connected network, or a unicast packet from a DHCP Relay
+   Agent, which has forwarded on a packet broadcast from a DHCP client
+   connected to a network local to the DHCP Relay Agent.
+
+   In some situations, DHCP Clients may unicast their DHCPREQUEST/RENEW
+   packets to the DHCP Relay Agent, which will forward the packet on to
+   the DHCP server.  In these cases, the DHCP server cannot tell whether
+   the packet was broadcast or unicast by the DHCP client, and so it may
+   be unable to process the DHCP client packets in the manner that it
+   would if it knew whether the original DHCP packet was broadcast or
+   unicast.  For example, a server might be willing to NAK a client in
+   the REBINDING state based on a determination that the client's
+   address does not match its location in the network, but might not be
+   willing to do so if the client is in the RENEWING state.
+
+   The purpose of the suboption described in this document is to allow
+   the DHCP relay to specify flags for the forwarded packet.  These
+   flags can be used to describe DHCP client attributes that are useful
+   to the DHCP server, but can only be detected by the local DHCP relay.
+   The DHCP server can use the information provided by the DHCP relay to
+   improve its processing algorithms.
+
+   One flag is defined to indicate whether the DHCP relay received the
+   packet via a unicast or broadcast packet.  This allows the DHCP
+   server to know if a packet forwarded on by a DHCP Relay Agent was
+   broadcast or unicast to the DHCP Relay Agent.
+
+2.  Requirements 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 [RFC2119].
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 2]
+
+RFC 5010              Relay Agent Flags Suboption         September 2007
+
+
+3.  The Flags Suboption
+
+   The Flags suboption provides an extensible suboption definition for
+   several possible flags.  The first flag defined is the unicast flag.
+
+   The format of the suboption is:
+
+          0                   1                   2
+          0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+         |     Code      |    Length     |    Flags      |
+         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+           Code     The suboption code (10).
+
+           Length   The suboption length, 1 octet.
+
+           Flags    The Relay Agent flags for this forwarded packet.
+
+                       0 1 2 3 4 5 6 7
+                      +-+-+-+-+-+-+-+-+
+                      |U|    MBZ      |
+                      +-+-+-+-+-+-+-+-+
+
+                      U:  UNICAST flag
+
+                           unicast = 1
+                           broadcast = 0
+
+                      MBZ:  MUST BE ZERO (reserved for future use)
+
+4.  DHCP Relay Agent Behavior
+
+   A DHCP relay agent that claims to conform to this specification MUST
+   include this suboption in every Relay Agent Information Option
+   [RFC3046] it adds to a forwarded DHCP request.  In this way, the DHCP
+   server can distinguish a request forwarded from a DHCP relay agent
+   that does not support the relay-agent-flags suboption from a request
+   forwarded by a DHCP relay agent that supports the relay-agent-flags
+   suboption, and which received the request that is being forwarded in
+   a broadcast packet.
+
+   To put this another way, A DHCP relay agent that supports the relay-
+   agent-flags suboption MUST always include it in every relay-agent-
+   information-option that it inserts into packets that it forwards on
+   to the DHCP server, whether the packet it is forwarding was received
+   as a broadcast or as a unicast.  This is because the DHCP server will
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 3]
+
+RFC 5010              Relay Agent Flags Suboption         September 2007
+
+
+   be dealing with DHCP relay agents that support the relay-agent-flags
+   suboption as well as DHCP relay agents that do not support the relay-
+   agent-flags suboption.
+
+5.  DHCP Server Behavior
+
+   This option provides additional information to the DHCP server.  The
+   DHCP server MAY use this information to make processing decisions
+   regarding the DHCP Client's packet that it is processing.  For
+   instance, knowledge of the broadcast or unicast reception of a packet
+   by a DHCP relay agent could be used when making the processing
+   decisions required to implement Load Balancing [RFC3074].  A load-
+   balancing server may be willing to respond to a REBINDING client, but
+   the server cannot determine the client's state without this
+   additional indication.
+
+   The option length is one octet.  If the DHCP server receives a relay-
+   agent-flags suboption that is longer than one octet, it MUST evaluate
+   the first octet.
+
+   Note to implementors: In specifying the behavior of new flags bits in
+   the future, careful attention must be paid to compatibility with
+   earlier implementations.  If additional flags values are defined in
+   the future, it will not always be possible to distinguish between
+   messages from relay agents who understand the new value and set its
+   value to 'zero', and relay agents who are simply setting a series of
+   unassigned bits to 'zero'.  It would be a mistake to specify
+   significant behavior changes based on 'zero' values of flags
+   specified in the future.
+
+6.  Security Considerations
+
+   Message authentication in DHCP for intradomain use, where the out-of-
+   band exchange of a shared secret is feasible, is defined in
+   [RFC3118].  Potential exposures to attack are discussed in Section 7
+   of the DHCP protocol specification in [RFC2131].
+
+   The DHCP Relay Agent option depends on a trusted relationship between
+   the DHCP relay agent and the server, as described in Section 5 of
+   [RFC3046].  While the introduction of fraudulent relay-agent options
+   can be prevented by a perimeter defense that blocks these options
+   unless the relay agent is trusted, a deeper defense using the
+   authentication option for relay agent options [RFC4030] SHOULD be
+   deployed as well.
+
+
+
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 4]
+
+RFC 5010              Relay Agent Flags Suboption         September 2007
+
+
+7.  IANA Considerations
+
+   IANA has assigned a suboption number (10) for the Flags Suboption
+   from the DHCP Relay Agent Information Option [RFC3046] suboption
+   number space.
+
+8.  Acknowledgements
+
+   Thanks to David Hankins for realizing the problems created by the
+   server-id-override option document and for helping us understand the
+   value of finally solving this problem in a way that has general
+   applicability.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              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 Vendor
+              Extensions", RFC 2132, March 1997.
+
+   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
+              RFC 3046, January 2001.
+
+   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
+              Messages", RFC 3118, June 2001.
+
+   [RFC4030]  Stapp, M. and T. Lemon, "The Authentication Suboption for
+              the Dynamic Host Configuration Protocol (DHCP) Relay Agent
+              Option", RFC 4030, March 2005.
+
+9.2.  Informative References
+
+   [RFC3074]  Volz, B., Gonczi, S., Lemon, T., and R. Stevens, "DHC Load
+              Balancing Algorithm", RFC 3074, February 2001.
+
+
+
+
+
+
+
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 5]
+
+RFC 5010              Relay Agent Flags Suboption         September 2007
+
+
+Authors' Addresses
+
+   Kim Kinnear
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave.
+   Boxborough, MA  01719
+   US
+
+   Phone: +1 978 936 0000
+   EMail: kkinnear@cisco.com
+
+
+   Marie Normoyle
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave.
+   Boxborough, MA  01719
+   US
+
+   Phone: +1 978 936 0000
+   EMail: mnormoyle@cisco.com
+
+
+   Mark Stapp
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave.
+   Boxborough, MA  01719
+   US
+
+   Phone: +1 978 936 0000
+   EMail: mjs@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 6]
+
+RFC 5010              Relay Agent Flags Suboption         September 2007
+
+
+Full Copyright Statement
+
+   Copyright (C) The IETF Trust (2007).
+
+   This document is subject to the rights, licenses and restrictions
+   contained in BCP 78, and except as set forth therein, the authors
+   retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
+   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at
+   ietf-ipr@ietf.org.
+
+
+
+
+
+
+
+
+
+
+
+
+Kinnear, et al.             Standards Track                     [Page 7]
+