doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc4649.txt b/doc/rfc/rfc4649.txt
new file mode 100644
index 0000000..b079e2f
--- /dev/null
+++ b/doc/rfc/rfc4649.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+Network Working Group                                            B. Volz
+Request for Comments: 4649                           Cisco Systems, Inc.
+Category: Standards Track                                    August 2006
+
+
+         Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
+                      Relay Agent Remote-ID Option
+
+
+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 (2006).
+
+Abstract
+
+   This memo defines a new Relay Agent Remote-ID option for the Dynamic
+   Host Configuration Protocol for IPv6 (DHCPv6).  This option is the
+   DHCPv6 equivalent for the Dynamic Host Configuration Protocol for
+   IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified
+   in RFC 3046.
+
+Table of Contents
+
+   1. Introduction ....................................................2
+   2. Requirements Terminology ........................................2
+   3. The Relay Agent Remote-ID Option ................................2
+   4. DHCPv6 Relay Agent Behavior .....................................3
+   5. DHCPv6 Server Behavior ..........................................3
+   6. Security Considerations .........................................3
+   7. IANA Considerations .............................................4
+   8. Acknowledgements ................................................4
+   9. References ......................................................4
+      9.1. Normative References .......................................4
+      9.2. Informative References .....................................4
+
+
+
+
+
+
+
+
+
+Volz                        Standards Track                     [Page 1]
+
+RFC 4649                 Relay Agent Remote-ID               August 2006
+
+
+1.  Introduction
+
+   DHCPv6 [1] provides IP addresses and configuration information for
+   IPv6 clients.  It includes a relay agent capability, in which
+   processes within the network infrastructure receive multicast
+   messages from clients and relay them to DHCPv6 servers.  In some
+   network environments, it will be useful for the relay agent to add
+   information to the DHCPv6 message before relaying it.
+
+   The information that relay agents supply can also be used in the
+   server's decision making about the addresses, delegated prefixes [4],
+   and configuration parameters that the client is to receive.
+
+   The memo specifies the DHCPv6 equivalent of the DHCPv4 Relay Agent
+   option's Remote-ID suboption as specified in [2].  The motivation and
+   usage scenarios are provided in [2].
+
+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 [3].
+
+3.  The Relay Agent Remote-ID Option
+
+   This option may be added by DHCPv6 relay agents that terminate
+   switched or permanent circuits and have mechanisms to identify the
+   remote host end of the circuit.
+
+   The format of the DHCPv6 Relay Agent Remote-ID option is shown below:
+
+        0                   1                   2                   3
+        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |       OPTION_REMOTE_ID        |         option-len            |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       |                       enterprise-number                       |
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+       .                                                               .
+       .                           remote-id                           .
+       .                                                               .
+       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+       option-code        OPTION_REMOTE_ID (37)
+
+       option-len         4 + the length, in octets, of the remote-id
+                          field.  The minimum option-len is 5 octets.
+
+
+
+
+Volz                        Standards Track                     [Page 2]
+
+RFC 4649                 Relay Agent Remote-ID               August 2006
+
+
+       enterprise-number  The vendor's registered Enterprise Number as
+                          registered with IANA [5].
+
+       remote-id          The opaque value for the remote-id.
+
+   The definition of the remote-id carried in this option is vendor
+   specific.  The vendor is indicated in the enterprise-number field.
+   The remote-id field may be used to encode, for instance:
+
+   o  a "caller ID" telephone number for dial-up connection
+   o  a "user name" prompted for by a Remote Access Server
+   o  a remote caller ATM address
+   o  a "modem ID" of a cable data modem
+   o  the remote IP address of a point-to-point link
+   o  a remote X.25 address for X.25 connections
+   o  an interface or port identifier
+
+   Each vendor must ensure that the remote-id is unique for its
+   enterprise-number, as the octet sequence of enterprise-number
+   followed by remote-id must be globally unique.  One way to achieve
+   uniqueness might be to include the relay agent's DHCP Unique
+   Identifier (DUID) [1] in the remote-id.
+
+4.  DHCPv6 Relay Agent Behavior
+
+   DHCPv6 relay agents may be configured to include a Remote-ID option
+   in relayed (RELAY-FORW) DHCPv6 messages.
+
+5.  DHCPv6 Server Behavior
+
+   This option provides additional information to the DHCPv6 server.
+   The DHCPv6 server, if it is configured to support this option, may
+   use this information to select parameters specific to particular
+   users, hosts, or subscriber modems.  The combined enterprise-number
+   and remote-id SHOULD be considered an opaque value, with policies
+   based on exact string match only; that is, the remote-id field SHOULD
+   NOT be internally parsed by the server.
+
+   There is no requirement that a server return this option and its data
+   in a RELAY-REPLY message.
+
+6.  Security Considerations
+
+   See [1] section 21.1, on securing DHCPv6 messages sent between
+   servers and relay agents, and section 23, on general DHCPv6 security
+   considerations.  [2] discusses how this information can be used to
+   enhance trust in some environments.
+
+
+
+
+Volz                        Standards Track                     [Page 3]
+
+RFC 4649                 Relay Agent Remote-ID               August 2006
+
+
+   Note that even if the DHCP server trusts the relay agent not to
+   modify information provided in this option, the confidence in that
+   information is no higher than the confidence that the relay agent has
+   in the information it puts in the option.  For example, in some
+   protocols it may be possible for a DHCP client to spoof or otherwise
+   choose port identifiers, caller ID information, or other information
+   carried in this option.  Sites should consider such possible spoofing
+   and how likely it is in their environment when deciding what uses of
+   this option are appropriate.
+
+7.  IANA Considerations
+
+   IANA has assigned the DHCPv6 option code 37 for the Relay Agent
+   Remote-ID Option.
+
+8.  Acknowledgements
+
+   Thanks to Michael Patrick for [2], from which I've liberally borrowed
+   text.
+
+9.  References
+
+9.1.  Normative References
+
+   [1]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
+        Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
+        RFC 3315, July 2003.
+
+   [2]  Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
+        January 2001.
+
+   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+9.2.  Informative References
+
+   [4]  Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host
+        Configuration Protocol (DHCP) version 6", RFC 3633, December
+        2003.
+
+   [5]  IANA, "Private Enterprise Numbers",
+        <http://www.iana.org/assignments/enterprise-numbers>.
+
+
+
+
+
+
+
+
+
+Volz                        Standards Track                     [Page 4]
+
+RFC 4649                 Relay Agent Remote-ID               August 2006
+
+
+Author's Address
+
+   Bernard Volz
+   Cisco Systems, Inc.
+   1414 Massachusetts Ave.
+   Boxborough, MA  01719
+   USA
+
+   Phone: +1 978 936 0382
+   EMail: volz@cisco.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Volz                        Standards Track                     [Page 5]
+
+RFC 4649                 Relay Agent Remote-ID               August 2006
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2006).
+
+   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 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.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is provided by the IETF
+   Administrative Support Activity (IASA).
+
+
+
+
+
+
+
+Volz                        Standards Track                     [Page 6]
+