Network Working Group J. Manner
Request for Comments: 5350 TKK
Updates: 2113, 3175 A. McDonald
Category: Standards Track Siemens/Roke
September 2008
Network Working Group J. Manner
Request for Comments: 5350 TKK
Updates: 2113, 3175 A. McDonald
Category: Standards Track Siemens/Roke
September 2008
IANA Considerations for the IPv4 and IPv6 Router Alert Options
IPv4和IPv6路由器警报选项的IANA注意事项
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
Abstract
摘要
This document updates the IANA allocation rules and registry of IPv4 and IPv6 Router Alert Option Values.
本文档更新了IPv4和IPv6路由器警报选项值的IANA分配规则和注册表。
Table of Contents
目录
1. Introduction ....................................................2
2. Use of the Router Alert Option Value Field ......................2
3. IANA Considerations .............................................4
3.1. IANA Considerations for IPv4 Router Alert Option Values ....4
3.2. IANA Considerations for IPv6 Router Alert Option Values ....5
4. Security Considerations .........................................5
5. Acknowledgements ................................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
1. Introduction ....................................................2
2. Use of the Router Alert Option Value Field ......................2
3. IANA Considerations .............................................4
3.1. IANA Considerations for IPv4 Router Alert Option Values ....4
3.2. IANA Considerations for IPv6 Router Alert Option Values ....5
4. Security Considerations .........................................5
5. Acknowledgements ................................................6
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
The IP Router Alert Option is defined for IPv4 in [RFC2113]. A similar IPv6 option is defined in [RFC2711]. When one of these options is present in an IP datagram, it indicates that the contents of the datagram may be interesting to routers. The Router Alert Option (RAO) is used by protocols such as the Resource Reservation Protocol (RSVP) [RFC2205] and IGMP [RFC3376].
[RFC2113]中为IPv4定义了IP路由器警报选项。[RFC2711]中定义了类似的IPv6选项。当这些选项之一出现在IP数据报中时，表示路由器可能对数据报的内容感兴趣。路由器警报选项（RAO）由诸如资源预留协议（RSVP）[RFC2205]和IGMP[RFC3376]等协议使用。
Both the IPv4 and IPv6 options contain a two-octet Value field to carry extra information. This information can be used, for example, by routers to determine whether or not the packet should be more closely examined by them.
IPv4和IPv6选项都包含两个八位字节的值字段以承载额外信息。例如，路由器可以使用该信息来确定是否应该更仔细地检查数据包。
There can be up to 65536 values for the RAO. Yet, currently there is only a registry for IPv6 values. No registry or allocation policies are defined for IPv4.
RAO最多可以有65536个值。然而，目前只有IPv6值的注册表。没有为IPv4定义注册表或分配策略。
This document updates the IANA registry for managing IPv4 and IPv6 Router Alert Option Values, and removes one existing IPv6 Router Alert Option Value.
本文档更新IANA注册表以管理IPv4和IPv6路由器警报选项值，并删除一个现有IPv6路由器警报选项值。
One difference between the specifications for the IPv4 and IPv6 Router Alert Options is the way values for the Value field are managed. In [RFC2113], the IPv4 Router Alert Option Value field has the value 0 assigned to "Router shall examine packet". All other values (1-65535) are reserved. Neither a management mechanism (e.g., an IANA registry) nor an allocation policy are provided for the IPv4 RAO values.
IPv4和IPv6路由器警报选项规范之间的一个区别是管理值字段值的方式。在[RFC2113]中，IPv4路由器警报选项值字段将值0分配给“路由器应检查数据包”。保留所有其他值（1-65535）。IPv4 RAO值既没有提供管理机制（例如IANA注册表），也没有提供分配策略。
The IPv6 Router Alert Option has an IANA-managed registry [IANA-IPv6RAO] containing allocations for the Value field.
IPv6路由器警报选项有一个IANA托管注册表[IANA-IPv6RAO]，其中包含对值字段的分配。
In [RFC3175], the IPv4 Router Alert Option Value is described as a parameter that provides "additional information" to the router in making its interception decision, rather than as a registry managed by IANA. As such, this aggregation mechanism makes use of the Value field to carry the reservation aggregation level. For the IPv6 option, IANA has assigned a set of 32 values to indicate reservation levels. However, since other registrations have already been made in that registry, these values are from 3-35 (which is actually a set of 33 values).
在[RFC3175]中，IPv4路由器警报选项值被描述为一个参数，该参数为路由器在做出拦截决策时提供“附加信息”，而不是由IANA管理的注册表。因此，此聚合机制利用值字段来承载保留聚合级别。对于IPv6选项，IANA分配了一组32个值来指示保留级别。但是，由于该注册表中已经进行了其他注册，因此这些值是3-35（实际上是33个值的集合）。
Although it might have been desirable to have the same values used in both the IPv4 and IPv6 registries, the initial allocations in [RFC2711] and the aggregation-level allocations in [RFC3175] have
虽然在IPv4和IPv6注册表中使用相同的值可能是可取的，但[RFC2711]中的初始分配和[RFC3175]中的聚合级别分配都是相同的
made this impossible. The following table shows the allocations in the IPv6 registry and the values used in the IPv4 registry, where the latter have been deduced from [RFC2113] and [RFC3175] with the assumption that the number of aggregation levels can be limited to 32 as in the IPv6 case. Entries for values 6 to 31 have been elided for brevity.
使这不可能。下表显示了IPv6注册表中的分配和IPv4注册表中使用的值，后者是根据[RFC2113]和[RFC3175]推导得出的，假设聚合级别的数量可以限制为32，就像在IPv6情况下一样。为简洁起见，删除了值6至31的条目。
+----------+-------------------------+------------------------------+
| Value | IPv4 RAO Meaning | IPv6 RAO Meaning |
+----------+-------------------------+------------------------------+
| 0 | Router shall examine | Datagram contains a |
| | packet [RFC2113] | Multicast Listener Discovery |
| | [RFC2205] [RFC3376] | message [RFC2711] [RFC2710] |
| | [RFC4286] | [RFC4286] |
| 1 | Aggregated Reservation | Datagram contains RSVP |
| | Nesting Level 1 | message [RFC2711] [RFC2205] |
| | [RFC3175] | |
| 2 | Aggregated Reservation | Datagram contains an Active |
| | Nesting Level 2 | Networks message [RFC2711] |
| | [RFC3175] | [Schwartz2000] |
| 3 | Aggregated Reservation | Aggregated Reservation |
| | Nesting Level 3 | Nesting Level 0 [RFC3175](*) |
| | [RFC3175] | |
| 4 | Aggregated Reservation | Aggregated Reservation |
| | Nesting Level 4 | Nesting Level 1 [RFC3175] |
| | [RFC3175] | |
| 5 | Aggregated Reservation | Aggregated Reservation |
| | Nesting Level 5 | Nesting Level 2 [RFC3175] |
| | [RFC3175] | |
| ... | ... | ... |
| 32 | Aggregated Reservation | Aggregated Reservation |
| | Nesting Level 32 | Nesting Level 29 [RFC3175] |
| | [RFC3175] | |
| 33 | Reserved | Aggregated Reservation |
| | | Nesting Level 30 [RFC3175] |
| 34 | Reserved | Aggregated Reservation |
| | | Nesting Level 31 [RFC3175] |
| 35 | Reserved | Aggregated Reservation |
| | | Nesting Level 32(*) |
| | | [RFC3175] |
| 36-65534 | Reserved | Reserved to IANA for future |
| | | assignment |
| 65535 | Reserved | Reserved [IANA-IPv6RAO] |
+----------+-------------------------+------------------------------+
+----------+-------------------------+------------------------------+
| Value | IPv4 RAO Meaning | IPv6 RAO Meaning |
+----------+-------------------------+------------------------------+
| 0 | Router shall examine | Datagram contains a |
| | packet [RFC2113] | Multicast Listener Discovery |
| | [RFC2205] [RFC3376] | message [RFC2711] [RFC2710] |
| | [RFC4286] | [RFC4286] |
| 1 | Aggregated Reservation | Datagram contains RSVP |
| | Nesting Level 1 | message [RFC2711] [RFC2205] |
| | [RFC3175] | |
| 2 | Aggregated Reservation | Datagram contains an Active |
| | Nesting Level 2 | Networks message [RFC2711] |
| | [RFC3175] | [Schwartz2000] |
| 3 | Aggregated Reservation | Aggregated Reservation |
| | Nesting Level 3 | Nesting Level 0 [RFC3175](*) |
| | [RFC3175] | |
| 4 | Aggregated Reservation | Aggregated Reservation |
| | Nesting Level 4 | Nesting Level 1 [RFC3175] |
| | [RFC3175] | |
| 5 | Aggregated Reservation | Aggregated Reservation |
| | Nesting Level 5 | Nesting Level 2 [RFC3175] |
| | [RFC3175] | |
| ... | ... | ... |
| 32 | Aggregated Reservation | Aggregated Reservation |
| | Nesting Level 32 | Nesting Level 29 [RFC3175] |
| | [RFC3175] | |
| 33 | Reserved | Aggregated Reservation |
| | | Nesting Level 30 [RFC3175] |
| 34 | Reserved | Aggregated Reservation |
| | | Nesting Level 31 [RFC3175] |
| 35 | Reserved | Aggregated Reservation |
| | | Nesting Level 32(*) |
| | | [RFC3175] |
| 36-65534 | Reserved | Reserved to IANA for future |
| | | assignment |
| 65535 | Reserved | Reserved [IANA-IPv6RAO] |
+----------+-------------------------+------------------------------+
Note (*): The entry in the above table for the IPv6 RAO Value of 35 (Aggregated Reservation Nesting Level 32) has been marked due to an inconsistency in the text of [RFC3175], and is consequently reflected
注（*）：上表中IPv6 RAO值35（聚合保留嵌套级别32）的条目由于[RFC3175]中的文本不一致而被标记，因此被反映出来
in the IANA registry. In that document, the values 3-35 (i.e., 33 values) are defined for nesting levels 0-31 (i.e., 32 levels). Similarly, value 3 is a duplicate, because aggregation level 0 means end-to-end signaling, and this already has an IPv6 RAO value "1" assigned.
在IANA注册中心。在该文档中，为嵌套级别0-31（即32个级别）定义了值3-35（即33个值）。类似地，值3是重复的，因为聚合级别0表示端到端信令，并且已经分配了IPv6 RAO值“1”。
Also note that nesting levels begin at 1 for IPv4 (described in Section 1.4.9 of [RFC3175]) and 0 for IPv6 (allocated in Section 6 of [RFC3175]).
还要注意的是，IPv4的嵌套级别从1开始（如[RFC3175]第1.4.9节所述），IPv6的嵌套级别从0开始（如[RFC3175]第6节所述）。
Section 3.2 of this document redefines these so that for IPv6, value 3 is no longer used and values 4-35 represent levels 1-32. This removes the above inconsistencies.
本文档第3.2节重新定义了这些值，因此对于IPv6，不再使用值3，值4-35表示级别1-32。这消除了上述不一致之处。
This section contains the new procedures for managing IPv4 Router Alert Option Values. IANA has created a registry for IPv4 Router Alert Option Values (described in Section 3.1) and has updated the IPv6 Router Alert Option Values (described in Section 3.2).
本节包含管理IPv4路由器警报选项值的新过程。IANA已为IPv4路由器警报选项值（如第3.1节所述）创建了注册表，并更新了IPv6路由器警报选项值（如第3.2节所述）。
IP Router Alert Option Values are currently managed separately for IPv4 and IPv6. This document does not change this, as there is little value in forcing the two registries to be aligned.
IP路由器警报选项值当前分别针对IPv4和IPv6进行管理。本文档并没有改变这一点，因为强制两个注册中心对齐没有什么价值。
The Value field, as specified in [RFC2113], is two octets in length. The Value field is registered and maintained by IANA. The initial contents of this registry are:
[RFC2113]中规定的值字段长度为两个八位字节。值字段由IANA注册和维护。此注册表的初始内容包括：
+-------------+--------------------------------------+-----------+
| Value | Description | Reference |
+-------------+--------------------------------------+-----------+
| 0 | Router shall examine packet | [RFC2113] |
| 1-32 | Aggregated Reservation Nesting Level | [RFC3175] |
| 33-65502 | Available for assignment by the IANA | |
| 65503-65534 | Available for experimental use | |
| 65535 | Reserved | |
+-------------+--------------------------------------+-----------+
+-------------+--------------------------------------+-----------+
| Value | Description | Reference |
+-------------+--------------------------------------+-----------+
| 0 | Router shall examine packet | [RFC2113] |
| 1-32 | Aggregated Reservation Nesting Level | [RFC3175] |
| 33-65502 | Available for assignment by the IANA | |
| 65503-65534 | Available for experimental use | |
| 65535 | Reserved | |
+-------------+--------------------------------------+-----------+
New values are to be assigned via IETF Review as defined in [RFC5226].
根据[RFC5226]中的定义，通过IETF评审分配新值。
The registry for IPv6 Router Alert Option Values continues to be maintained as specified in [RFC2711]. In addition, the following value has been removed from the IANA registry and reserved for possible future use (not to be allocated currently). The reason is that it is a duplicate value; aggregation level 0 means end-to-end signaling, and this already has an IPv6 RAO value "1" assigned.
IPv6路由器警报选项值的注册表将继续按照[RFC2711]中的规定进行维护。此外，以下值已从IANA注册表中删除，并保留供将来使用（目前不分配）。原因是它是一个重复值；聚合级别0表示端到端信令，并且已经分配了IPv6 RAO值“1”。
+-------+--------------------------+-----------+
| Value | Description | Reference |
+-------+--------------------------+-----------+
| 3 | RSVP Aggregation level 0 | [RFC3175] |
+-------+--------------------------+-----------+
+-------+--------------------------+-----------+
| Value | Description | Reference |
+-------+--------------------------+-----------+
| 3 | RSVP Aggregation level 0 | [RFC3175] |
+-------+--------------------------+-----------+
The following IPv6 RAO values are available for experimental use:
以下IPv6 RAO值可供实验使用：
+-------------+------------------+-----------+
| Value | Description | Reference |
+-------------+------------------+-----------+
| 65503-65534 | Experimental use | |
+-------------+------------------+-----------+
+-------------+------------------+-----------+
| Value | Description | Reference |
+-------------+------------------+-----------+
| 65503-65534 | Experimental use | |
+-------------+------------------+-----------+
Since this document is only concerned with the IANA management of the IPv4 and IPv6 Router Alert Option Values registry, it raises no new security issues beyond those identified in [RFC2113] and [RFC2711].
由于本文档仅涉及IPv4和IPv6路由器警报选项值注册表的IANA管理，因此除了[RFC2113]和[RFC2711]中确定的安全问题外，本文档不会提出任何新的安全问题。
Yet, as discussed in RFC 4727 [RFC4727], production networks do not necessarily support the use of experimental code points in IP option headers. The network scope of support for experimental values should be evaluated carefully before deploying any experimental RAO value across extended network domains, such as the public Internet. The potential to disrupt the stable operation of the network hosting the experiment through the use of unsupported experimental code points is a serious consideration when planning an experiment using such code points.
然而，正如RFC 4727[RFC4727]中所讨论的，生产网络不一定支持在IP选项头中使用实验性代码点。在跨扩展网络域（如公共互联网）部署任何实验RAO值之前，应仔细评估实验值的网络支持范围。在规划使用此类代码点的实验时，通过使用不受支持的实验代码点破坏承载实验的网络的稳定运行的可能性是一个严肃的考虑因素。
When experimental RAO values are deployed within an administratively self-contained network domain, the network administrators should ensure that each value is used consistently to avoid interference between experiments. When experimental values are used in traffic that crosses multiple administrative domains, the experimenters should assume that there is a risk that the same values will be used simultaneously by other experiments, and thus that there is a
当实验RAO值部署在管理自包含的网络域中时，网络管理员应确保一致使用每个值，以避免实验之间的干扰。当在跨多个管理域的流量中使用实验值时，实验者应假设存在其他实验同时使用相同值的风险，因此存在
possibility that the experiments will interfere. Particular attention should be given to security threats that such interference might create.
实验会干扰的可能性。应特别注意这种干扰可能造成的安全威胁。
Thanks to Robert Hancock, Martin Stiemerling, Alan Ford, and Francois Le Faucheur for their helpful comments on this document.
感谢Robert Hancock、Martin Stieemering、Alan Ford和Francois Le Faucheur对本文件的有益评论。
[RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[RFC2113]Katz，D.，“IP路由器警报选项”，RFC 21131997年2月。
[RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", RFC 2711, October 1999.
[RFC2711]帕特里奇，C.和A.杰克逊，“IPv6路由器警报选项”，RFC27111999年10月。
[RFC3175] Baker, F., Iturralde, C., Le Faucheur, F., and B. Davie, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, September 2001.
[RFC3175]Baker，F.，Iturralde，C.，Le Faucheur，F.，和B.Davie，“IPv4和IPv6保留的RSVP聚合”，RFC 3175，2001年9月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[IANA-IPv6RAO] "IANA Registry for Internet Protocol version 6 (IPv6) Router Alert Option Values", <http://www.iana.org>.
[IANA-IPv6RAO]“互联网协议版本6（IPv6）路由器警报选项值的IANA注册表”<http://www.iana.org>.
[RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2205]Braden，R.，Ed.，Zhang，L.，Berson，S.，Herzog，S.，和S.Jamin，“资源预留协议（RSVP）——版本1功能规范”，RFC 22052997年9月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
[RFC3376]Cain，B.，Deering，S.，Kouvelas，I.，Fenner，B.，和A.Thyagarajan，“互联网组管理协议，第3版”，RFC 3376，2002年10月。
[RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", RFC 4286, December 2005.
[RFC4286]Haberman，B.和J.Martin，“多播路由器发现”，RFC 4286，2005年12月。
[RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006.
[RFC4727]Fenner，B.，“IPv4、IPv6、ICMPv4、ICMPv6、UDP和TCP报头中的实验值”，RFC 4727，2006年11月。
[Schwartz2000] Schwartz, B., Jackson, A., Strayer, W., Zhou, W., Rockwell, D., and C. Partridge, "Smart Packets: Applying Active Networks to Network Management", ACM Transactions on Computer Systems (TOCS), Volume 18, Issue 1, February 2000.
[Schwartz2000]Schwartz，B.，Jackson，A.，Strayer，W.，Zhou，W.，Rockwell，D.，和C.Partridge，“智能数据包：将主动网络应用于网络管理”，ACM计算机系统交易（TOCS），第18卷，第1期，2000年2月。
Authors' Addresses
作者地址
Jukka Manner Department of Communications and Networking (Comnet) Helsinki University of Technology (TKK) P.O. Box 3000 Espoo FIN-02015 TKK Finland
尤卡通信与网络部（赫尔辛基工业大学）（3000）埃斯波FIN 02015 TKK芬兰
Phone: +358 9 451 2481
EMail: jukka.manner@tkk.fi
Phone: +358 9 451 2481
EMail: jukka.manner@tkk.fi
Andrew McDonald Roke Manor Research Ltd (a Siemens company) Old Salisbury Lane Romsey, Hampshire SO51 0ZN United Kingdom
安德鲁·麦克唐纳·罗克庄园研究有限公司（一家西门子公司）英国汉普郡老索尔兹伯里巷罗姆西SO51 0ZN
EMail: andrew.mcdonald@roke.co.uk
EMail: andrew.mcdonald@roke.co.uk
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.