Network Working Group B. Haberman, Ed.
Request for Comments: 5175 JHU APL
Obsoletes: 5075 R. Hinden
Category: Standards Track Nokia
March 2008
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
IPv6路由器播发标志选项
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
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.
IPv6邻居发现的路由器播发消息包含一个为单位标志保留的8位字段。一些协议在此字段中保留了标志，其他协议正准备保留足够数量的标志以耗尽该字段。本文档定义了路由器广告消息的一个选项，该选项扩展了可用标志位的数量。
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
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
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.
IPv6邻居发现协议（NDP）[RFC4861]路由器公告消息包含一个为单位标志保留的8位字段。一些协议在此字段中保留了标志，其他协议正准备保留足够数量的标志以耗尽该字段。
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.
本文档为路由器广告消息定义了一个选项，该选项通过向NDP消息添加额外的48个标志位来扩展可用的标志位数量。
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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Currently, the NDP Router Advertisement message contains the following one-bit flags defined in published RFCs:
目前，NDP路由器公告消息包含以下在已发布的RFC中定义的一位标志：
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|M|O|H|Prf|P|R|R|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
|M|O|H|Prf|P|R|R|
+-+-+-+-+-+-+-+-+
Figure 1: Router Advertisement Flags
图1：路由器广告标志
o M - Managed Address Configuration Flag [RFC4861]
o M-托管地址配置标志[RFC4861]
o O - Other Configuration Flag [RFC4861]
o O - Other Configuration Flag [RFC4861]translate error, please retry
o H - Mobile IPv6 Home Agent Flag [RFC3775]
o H-移动IPv6归属代理标志[RFC3775]
o Prf - Router Selection Preferences [RFC4191]
o Prf-路由器选择首选项[RFC4191]
o P - Neighbor Discovery Proxy Flag [RFC4389]
o P-邻居发现代理标志[RFC4389]
o R - Reserved
o R-保留
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.
由于其他协议（例如，检测网络连接）希望在NDP消息中使用标志，因此有必要定义扩展功能以支持新功能。
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.
邻居发现规范[RFC4861]包含定义NDP选项的功能。下面（图2）是NDP路由器广告消息的扩展标志选项（EFO）的定义。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
图2：路由器广告扩展标志选项
o Type - 26
o 类型-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 长度-处理选项时必须检查长度，以便将来扩展此选项。此规范的实现必须将长度设置为1，必须忽略任何无法识别的数据，并且必须能够识别特定长度，以便跳过无法识别的位。
o Bits - allocated by IANA
o 位-由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 必须仅出现在路由器广告消息中。
o MUST occur prior to any additional options associated with any flags set in this option.
o 必须在与此选项中设置的任何标志关联的任何其他选项之前发生。
o MUST only occur once in the Router Advertisement message.
o 在路由器公告消息中只能出现一次。
o MUST NOT be added to a Router Advertisement message if no flags in the option are set.
o 如果选项中未设置任何标志，则不得将其添加到路由器播发消息中。
o MUST set all unused flags to zero.
o 必须将所有未使用的标志设置为零。
Upon reception, a receiver processing NDP messages containing this option:
接收时，处理包含此选项的NDP消息的接收器：
o MUST ignore the option if it occurs in a message other than a Router Advertisement.
o 如果该选项出现在路由器公告以外的消息中，则必须忽略该选项。
o MUST ignore all instances of the option except the first one encountered in the Router Advertisement message.
o 必须忽略该选项的所有实例，路由器播发消息中遇到的第一个实例除外。
o MUST ignore the option if the Length is less than 1.
o 如果长度小于1，则必须忽略该选项。
o MUST ignore any unknown flag bits.
o 必须忽略任何未知的标志位。
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].
选项中的位字段从左到右、从8到55（从选项中的位偏移16开始）进行编号，并遵循图1中所述的RA选项中的标志位编号。标志位0至7位于[RFC4861]中定义的路由器公告消息头中。
IANA has defined a new IPv6 Neighbor Discovery option for the option defined in this document of the form:
IANA已为本文档中定义的选项定义了一个新的IPv6邻居发现选项，格式如下：
+------+---------------------------+-----------+
| Type | Description | Reference |
+------+---------------------------+-----------+
| 26 | RA Flags Extension Option | [RFC5175] |
+------+---------------------------+-----------+
+------+---------------------------+-----------+
| 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
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:
IANA已经为IPv6 ND路由器广告标志创建了一个新的注册表。这应包括本文档中定义的RA选项和扩展选项中的当前标志。新注册表已添加到icmpv6参数中，如上所示。注册表的格式为：
+---------------+---------------------------------------+-----------+
| 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 | |
+---------------+---------------------------------------+-----------+
+---------------+---------------------------------------+-----------+
| 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].
在RA选项标题中分配新的RA标志以及本文件中定义的RA扩展选项中定义的位需要标准行动或IESG批准[RFC2434]。
This protocol shares the security issues of NDP that are documented in the "Security Considerations" section of [RFC4861].
本协议共享NDP的安全问题，这些问题记录在[RFC4861]的“安全注意事项”一节中。
The inclusion of additional optional bit fields provides a potential covert channel that is useful for passing information.
附加可选位字段的包含提供了一个潜在的隐蔽通道，可用于传递信息。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191]Draves，R.和D.Thaler，“默认路由器首选项和更具体的路由”，RFC 41912005年11月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389]Thaler，D.，Talwar，M.，和C.Patel，“邻居发现代理（ND代理）”，RFC 4389，2006年4月。
Authors' Addresses
作者地址
Brian Haberman (editor) Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723-6099 USA
布莱恩·哈伯曼（编辑）约翰·霍普金斯大学应用物理实验室美国马里兰州劳雷尔市约翰·霍普金斯路11100号20723-6099
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Robert Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
Robert Hinden诺基亚313飞兆半导体山景大道，加利福尼亚州94043
Phone: +1 650 625 2004
EMail: bob.hinden@nokia.com
Phone: +1 650 625 2004
EMail: bob.hinden@nokia.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.