Network Working Group C. Partridge
Request for Comments: 2711 BBN
Category: Standards Track A. Jackson
BBN
October 1999
Network Working Group C. Partridge
Request for Comments: 2711 BBN
Category: Standards Track A. Jackson
BBN
October 1999
IPv6 Router Alert 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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
Abstract
摘要
This memo describes a new IPv6 Hop-by-Hop Option type that alerts transit routers to more closely examine the contents of an IP datagram. This option is useful for situations where a datagram addressed to a particular destination contains information that may require special processing by routers along the path.
此备忘录描述了一种新的IPv6逐跳选项类型，用于提醒传输路由器更仔细地检查IP数据报的内容。此选项适用于寻址到特定目的地的数据报包含可能需要路由器沿路径进行特殊处理的信息的情况。
New protocols, such as RSVP, use control datagrams which, while addressed to a particular destination, contain information that needs to be examined, and in some case updated, by routers along the path between the source and destination. It is desirable to forward regular datagrams as rapidly as possible, while ensuring that the router processes these special control datagrams appropriately. Currently, however, the only way for a router to determine if it needs to examine a datagram is to at least partially parse upper layer data in all datagrams. This parsing is expensive and slow. This situation is undesirable.
新协议（如RSVP）使用控制数据报，这些控制数据报在发送到特定目的地时，包含需要由路由器沿着源和目的地之间的路径进行检查（在某些情况下进行更新）的信息。希望尽可能快地转发常规数据报，同时确保路由器适当地处理这些特殊控制数据报。然而，目前路由器确定是否需要检查数据报的唯一方法是至少部分解析所有数据报中的上层数据。这种解析既昂贵又缓慢。这种情况是不可取的。
This document defines a new option within the IPv6 Hop-by-Hop Header. The presence of this option in an IPv6 datagram informs the router that the contents of this datagram is of interest to the router and to handle any control data accordingly. The absence of this option in an IPv6 datagram informs the router that the datagram does not contain information needed by the router and hence can be safely
本文档在IPv6逐跳标头中定义了一个新选项。IPv6数据报中存在此选项会通知路由器该数据报的内容是路由器感兴趣的，并相应地处理任何控制数据。IPv6数据报中缺少此选项会通知路由器，该数据报不包含路由器所需的信息，因此可以安全访问
routed without further datagram parsing. Hosts originating IPv6 datagrams are required to include this option in certain circumstances.
无需进一步的数据报解析即可路由。在某些情况下，发起IPv6数据报的主机需要包括此选项。
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 [RFC-2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-2119]中所述进行解释。
The goal is to provide an efficient mechanism whereby routers can know when to intercept datagrams not addressed to them without having to extensively examine every datagram. The described solution is to define a new IPv6 Hop-by-Hop Header option having the semantic "routers should examine this datagram more closely" and require protocols such as RSVP to use this option. This approach incurs little or no performance penalty on the forwarding of normal datagrams. Not including this option tells the router that there is no need to closely examine the contents of the datagram.
其目标是提供一种有效的机制，使路由器能够知道何时拦截未发送给它们的数据报，而无需广泛检查每个数据报。所描述的解决方案是定义一个新的IPv6逐跳标头选项，该选项具有语义“路由器应更仔细地检查此数据报”，并要求诸如RSVP之类的协议使用此选项。这种方法在转发正常数据报时很少或没有性能损失。不包括此选项会告诉路由器不需要仔细检查数据报的内容。
The router alert option has the following format:
路由器警报选项具有以下格式：
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
length = 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0|0 0 1 0 1|0 0 0 0 0 0 1 0| Value (2 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
length = 2
The first three bits of the first byte are zero and the value 5 in the remaining five bits is the Hop-by-Hop Option Type number. [RFC-2460] specifies the meaning of the first three bits. By zeroing all three, this specification requires that nodes not recognizing this option type should skip over this option and continue processing the header and that the option must not change en route.
第一个字节的前三位为零，其余五位中的值5为逐跳选项类型编号。[RFC-2460]指定前三位的含义。通过将所有三个选项归零，此规范要求不识别此选项类型的节点跳过此选项并继续处理标头，并且该选项不得在路由中更改。
There MUST only be one option of this type, regardless of value, per Hop-by-Hop header.
这种类型的选项必须只有一个，无论值是多少，逐跳标头。
Value: A 2 octet code in network byte order with the following values:
值：网络字节顺序的2个八位组代码，具有以下值：
0 Datagram contains a Multicast Listener Discovery message [RFC-2710]. 1 Datagram contains RSVP message. 2 Datagram contains an Active Networks message. 3-65535 Reserved to IANA for future use.
0数据报包含多播侦听器发现消息[RFC-2710]。1数据报包含RSVP消息。2数据报包含活动网络消息。3-65535保留给IANA供将来使用。
Alignment requirement: 2n+0
对准要求：2n+0
Values are registered and maintained by the IANA. See section 5.0 for more details.
值由IANA注册和维护。详见第5.0节。
The option indicates that the contents of the datagram may be interesting to the router. The router's interest and the actions taken by employing Router Alert MUST be specified in the RFC of the protocol that mandates or allows the use of Router Alert.
该选项表示路由器可能对数据报的内容感兴趣。路由器的兴趣和通过使用路由器警报所采取的行动必须在协议的RFC中指定，该协议授权或允许使用路由器警报。
The final destination of the IPv6 datagram MUST ignore this option upon receipt to prevent multiple evaluations of the datagram. Unrecognized value fields MUST be silently ignored and the processing of the header continued.
IPv6数据报的最终目的地在收到时必须忽略此选项，以防止对数据报进行多次评估。无法识别的值字段必须以静默方式忽略，并继续处理标头。
Routers that recognize the option will examine datagrams carrying it more closely to determine whether or not further processing is necessary. The router only needs to parse the packet in sufficient detail to decide whether the packet contains something of interest. The value field can be used by an implementation to speed processing of the datagram within the transit router.
识别该选项的路由器将更仔细地检查携带该选项的数据报，以确定是否需要进一步处理。路由器只需要对数据包进行足够详细的解析，以确定数据包是否包含感兴趣的内容。值字段可由实现用于加速传输路由器内的数据报处理。
Observe that further processing can involve protocol layers above IPv6. E.g., for RSVP messages, the datagram will have to undergo UDP and RSVP protocol processing. Once the datagram leaves the IPv6 layer, there is considerable ambiguity about whether the router is acting as an IPv6 host or an IPv6 router. Precisely how the router handles the contents is value-field specific. However, if the processing required for the datagram involves examining the payload of the IPv6 datagram, then the interim router is performing a host function and SHOULD interpret the data as a host.
请注意，进一步的处理可能涉及IPv6之上的协议层。例如，对于RSVP消息，数据报必须经过UDP和RSVP协议处理。一旦数据报离开IPv6层，路由器是作为IPv6主机还是作为IPv6路由器存在相当大的不确定性。路由器处理内容的具体方式取决于值字段。但是，如果数据报所需的处理涉及检查IPv6数据报的有效负载，则临时路由器正在执行主机功能，并且应将数据解释为主机。
For this option to be effective, its use MUST be mandated in protocols that expect routers to perform significant processing on datagrams not directly addressed to them. Routers are not required to examine the datagrams not addressed to them unless the datagrams include the router alert option.
为了使此选项有效，必须在协议中强制要求路由器对未直接发送给它们的数据报执行重要处理。路由器不需要检查未发送给它们的数据报，除非数据报包含路由器警报选项。
All IPv6 datagrams containing an RSVP message MUST contain this option within the IPv6 Hop-by-Hop Options Header of such datagrams.
所有包含RSVP消息的IPv6数据报必须在此类数据报的IPv6逐跳选项标头中包含此选项。
Gratuitous use of this option can cause performance problems in routers. A more severe attack is possible in which the router is flooded by bogus datagrams containing router alert options.
无偿使用此选项可能会导致路由器出现性能问题。更严重的攻击可能是路由器被包含路由器警报选项的虚假数据报淹没。
The use of the option, if supported in a router, MAY therefore be limited by rate or other means by the transit router.
因此，如果路由器中支持该选项，则该选项的使用可能受到传输路由器的速率或其他方式的限制。
The value field described in Section 2.1 is registered and maintained by IANA. New values are to be assigned via IETF Consensus as defined in RFC 2434 [RFC-2434].
第2.1节中描述的值字段由IANA注册和维护。根据RFC 2434[RFC-2434]中的定义，通过IETF共识分配新值。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何努力来确定任何此类权利。有关IETF在标准跟踪和标准相关文件中权利的程序信息，请参见BCP-11。可从IETF秘书处获得可供发布的权利声明副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涉及实施本标准所需技术的专有权利。请将信息发送给IETF执行董事。
[RFC-2119] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", BCP 14, RFC 2119, March 1977.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1977年3月。
[RFC-2205] Braden, B. (ed.), Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation Protocol (RSVP)", RFC 2205, September 1997.
[RFC-2205]Braden，B.（编辑），Zhang，L.，Berson，S.，Herzog，S.和S.Jamin，“资源保留协议（RSVP）”，RFC 22052997年9月。
[RFC-2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC-2434]Narten，T.和H.Alvestrand，“在RFC中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC-2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC-2710] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC-2710]Deering，S.，Fenner，W.和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
Craig Partridge BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
美国马萨诸塞州剑桥莫尔顿街10号Craig Partridge BBN Technologies邮编：02138
Phone: +1 (617) 873-3000
EMail: craig@bbn.com
Phone: +1 (617) 873-3000
EMail: craig@bbn.com
Alden Jackson BBN Technologies 10 Moulton Street Cambridge, MA 02138 USA
美国马萨诸塞州剑桥莫尔顿街10号Alden Jackson BBN Technologies 02138
Phone: +1 (617) 873-3000
EMail: awjacks@bbn.com
Phone: +1 (617) 873-3000
EMail: awjacks@bbn.com
Copyright (C) The Internet Society (1999). All Rights Reserved.
版权所有（C）互联网协会（1999年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。