summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5175.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5175.txt')
-rw-r--r--doc/rfc/rfc5175.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc5175.txt b/doc/rfc/rfc5175.txt
new file mode 100644
index 0000000..e406ec6
--- /dev/null
+++ b/doc/rfc/rfc5175.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group B. Haberman, Ed.
+Request for Comments: 5175 JHU APL
+Obsoletes: 5075 R. Hinden
+Category: Standards Track Nokia
+ March 2008
+
+
+ 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 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 5175 IPv6 RA Flags Options March 2008
+
+
+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 5175 IPv6 RA Flags Options March 2008
+
+
+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 - 26
+
+ 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 5175 IPv6 RA Flags Options March 2008
+
+
+ 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 | [RFC5175] |
+ +------+---------------------------+-----------+
+
+ 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 5175 IPv6 RA Flags Options March 2008
+
+
+ +---------------+---------------------------------------+-----------+
+ | 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 5175 IPv6 RA Flags Options March 2008
+
+
+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 5175 IPv6 RA Flags Options March 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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]
+