doc: Add RFC documents

1 files changed, 395 insertions, 0 deletions

diff --git a/doc/rfc/rfc5075.txt b/doc/rfc/rfc5075.txt
new file mode 100644
index 0000000..1f4f8e7
--- /dev/null
+++ b/doc/rfc/rfc5075.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group                                   B. Haberman, Ed.
+Request for Comments: 5075                                       JHU APL
+Category: Standards Track                                      R. Hinden
+                                                                   Nokia
+                                                           November 2007
+
+
+                 IPv6 Router Advertisement Flags 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.
+
+Abstract
+
+   The IPv6 Neighbor Discovery's Router Advertisement message contains
+   an 8-bit field reserved for single-bit flags.  Several protocols have
+   reserved flags in this field and others are preparing to reserve a
+   sufficient number of flags to exhaust the field.  This document
+   defines an option to the Router Advertisement message that expands
+   the available number of flag bits available.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+   3.  Current Router Advertisement Flags  . . . . . . . . . . . . . . 2
+   4.  Flags Expansion Option  . . . . . . . . . . . . . . . . . . . . 3
+   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
+   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
+     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 6
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haberman & Hinden           Standards Track                     [Page 1]
+
+RFC 5075                 IPv6 RA Flags Options             November 2007
+
+
+1.  Introduction
+
+   The IPv6 Neighbor Discovery Protocol's (NDP) [RFC4861] Router
+   Advertisement message contains an 8-bit field reserved for single-bit
+   flags.  Several protocols have reserved flags in this field and
+   others are preparing to reserve a sufficient number of flags to
+   exhaust the field.
+
+   This document defines an option for the Router Advertisement message
+   that expands the available number of flag bits by adding an
+   additional 48 flag bits to NDP messages.
+
+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 [RFC2119].
+
+3.  Current Router Advertisement Flags
+
+   Currently, the NDP Router Advertisement message contains the
+   following one-bit flags defined in published RFCs:
+
+    0 1 2 3 4 5 6 7
+   +-+-+-+-+-+-+-+-+
+   |M|O|H|Prf|P|R|R|
+   +-+-+-+-+-+-+-+-+
+
+                   Figure 1: Router Advertisement Flags
+
+   o  M - Managed Address Configuration Flag [RFC4861]
+
+   o  O - Other Configuration Flag [RFC4861]
+
+   o  H - Mobile IPv6 Home Agent Flag [RFC3775]
+
+   o  Prf - Router Selection Preferences [RFC4191]
+
+   o  P - Neighbor Discovery Proxy Flag [RFC4389]
+
+   o  R - Reserved
+
+   With other protocols in the works (e.g., Detecting Network
+   Attachment) that want to use flags in the NDP messages, it is
+   necessary to define an expansion capability to support new features.
+
+
+
+
+
+
+Haberman & Hinden           Standards Track                     [Page 2]
+
+RFC 5075                 IPv6 RA Flags Options             November 2007
+
+
+4.  Flags Expansion Option
+
+   The Neighbor Discovery specification [RFC4861] contains the
+   capability to define NDP options.  The following (Figure 2) is the
+   definition of the Expanded Flags Option (EFO) for NDP Router
+   Advertisement messages.
+
+    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
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   |     Type      |    Length     |         Bit fields available ..
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   ... for assignment                                              |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+           Figure 2: Router Advertisement Expanded Flags Option
+
+   o  Type - TBD (to be assigned by IANA)
+
+   o  Length - The length MUST be checked when processing the option in
+      order to allow for future expansion of this option.  An
+      implementation of this specification MUST set the Length to 1,
+      MUST ignore any unrecognized data, and MUST be able to recognize
+      the specific length in order to skip over unrecognized bits.
+
+   o  Bits - allocated by IANA
+
+   The definition and usage of these bits is to be found in the document
+   requesting their allocation.
+
+   During the construction/transmission, this option:
+
+   o  MUST only occur in Router Advertisement messages.
+
+   o  MUST occur prior to any additional options associated with any
+      flags set in this option.
+
+   o  MUST only occur once in the Router Advertisement message.
+
+   o  MUST NOT be added to a Router Advertisement message if no flags in
+      the option are set.
+
+   o  MUST set all unused flags to zero.
+
+
+
+
+
+
+
+
+Haberman & Hinden           Standards Track                     [Page 3]
+
+RFC 5075                 IPv6 RA Flags Options             November 2007
+
+
+   Upon reception, a receiver processing NDP messages containing this
+   option:
+
+   o  MUST ignore the option if it occurs in a message other than a
+      Router Advertisement.
+
+   o  MUST ignore all instances of the option except the first one
+      encountered in the Router Advertisement message.
+
+   o  MUST ignore the option if the Length is less than 1.
+
+   o  MUST ignore any unknown flag bits.
+
+   The bit fields within the option are numbered from left to right,
+   from 8 to 55 (starting as bit offset 16 in the option) and follow the
+   numbering of the flag bits in the RA option described in Figure 1.
+   Flag bits 0 to 7 are found in the Router Advertisement message header
+   defined in [RFC4861].
+
+5.  IANA Considerations
+
+   IANA has defined a new IPv6 Neighbor Discovery option for the option
+   defined in this document of the form:
+
+             +------+---------------------------+-----------+
+             | Type | Description               | Reference |
+             +------+---------------------------+-----------+
+             | 26   | RA Flags Extension Option | [RFC5075] |
+             +------+---------------------------+-----------+
+
+   The registry for these options can be found at:
+   http://www.iana.org/assignments/icmpv6-parameters
+
+   IANA has created a new registry for IPv6 ND Router Advertisement
+   flags.  This should include the current flags in the RA option and in
+   the extension option defined in this document.  The new registry has
+   been added to the icmpv6-parameters as shown above.  The format for
+   the registry is:
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haberman & Hinden           Standards Track                     [Page 4]
+
+RFC 5075                 IPv6 RA Flags Options             November 2007
+
+
+   +---------------+---------------------------------------+-----------+
+   | RA Option Bit | Description                           | Reference |
+   +---------------+---------------------------------------+-----------+
+   | 0             | M - Managed Address Configuration     | [RFC4861] |
+   |               | Flag                                  |           |
+   | 1             | O - Other Configuration Flag          | [RFC4861] |
+   | 2             | H - Mobile IPv6 Home Agent Flag       | [RFC3775] |
+   | 3             | Prf - Router Selection Preferences    | [RFC4191] |
+   | 4             | Prf - Router Selection Preferences    | [RFC4191] |
+   | 5             | P - Neighbor Discovery Proxy Flag     | [RFC4389] |
+   | 6-53          | R - Reserved; Available for           |           |
+   |               | assignment                            |           |
+   | 54-55         | Private Experimentation               |           |
+   +---------------+---------------------------------------+-----------+
+
+   The assignment of new RA flags in the RA option header and the bits
+   defined in the RA extension option defined in this document require
+   standards action or IESG approval [RFC2434].
+
+6.  Security Considerations
+
+   This protocol shares the security issues of NDP that are documented
+   in the "Security Considerations" section of [RFC4861].
+
+   The inclusion of additional optional bit fields provides a potential
+   covert channel that is useful for passing information.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
+              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
+              October 1998.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              September 2007.
+
+
+
+
+
+
+
+
+
+
+Haberman & Hinden           Standards Track                     [Page 5]
+
+RFC 5075                 IPv6 RA Flags Options             November 2007
+
+
+7.2.  Informative References
+
+   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
+              in IPv6", RFC 3775, June 2004.
+
+   [RFC4191]  Draves, R. and D. Thaler, "Default Router Preferences and
+              More-Specific Routes", RFC 4191, November 2005.
+
+   [RFC4389]  Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
+              Proxies (ND Proxy)", RFC 4389, April 2006.
+
+Authors' Addresses
+
+   Brian Haberman (editor)
+   Johns Hopkins University Applied Physics Lab
+   11100 Johns Hopkins Road
+   Laurel, MD  20723-6099
+   USA
+
+   Phone: +1 443 778 1319
+   EMail: brian@innovationslab.net
+
+
+   Robert Hinden
+   Nokia
+   313 Fairchild Drive
+   Mountain View, CA  94043
+   USA
+
+   Phone: +1 650 625 2004
+   EMail: bob.hinden@nokia.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Haberman & Hinden           Standards Track                     [Page 6]
+
+RFC 5075                 IPv6 RA Flags Options             November 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Haberman & Hinden           Standards Track                     [Page 7]
+