Internet Engineering Task Force (IETF) J. Snijders
Request for Comments: 8203 NTT
Updates: 4486 J. Heitz
Category: Standards Track Cisco
ISSN: 2070-1721 J. Scudder
Juniper
July 2017
Internet Engineering Task Force (IETF) J. Snijders
Request for Comments: 8203 NTT
Updates: 4486 J. Heitz
Category: Standards Track Cisco
ISSN: 2070-1721 J. Scudder
Juniper
July 2017
BGP Administrative Shutdown Communication
管理关闭通信
Abstract
摘要
This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486.
本文档增强了BGP停止通知消息“管理关闭”和“管理重置”子代码，供操作员传输简短的自由形式消息，以描述BGP会话关闭或重置的原因。本文档更新了RFC 4486。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8203.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8203.
Copyright Notice
版权公告
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2017 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Shutdown Communication . . . . . . . . . . . . . . . . . . . 2
3. Operational Considerations . . . . . . . . . . . . . . . . . 3
4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. Shutdown Communication . . . . . . . . . . . . . . . . . . . 2
3. Operational Considerations . . . . . . . . . . . . . . . . . 3
4. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 4
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
It can be troublesome for an operator to correlate a BGP-4 [RFC4271] session teardown in the network with a notice that was transmitted via offline methods such as email or telephone calls. This document updates [RFC4486] by specifying a mechanism to transmit a short freeform UTF-8 [RFC3629] message as part of a Cease NOTIFICATION message [RFC4271] to inform the peer why the BGP session is being shutdown or reset.
操作员将网络中的BGP-4[RFC4271]会话断开与通过离线方法（如电子邮件或电话）传输的通知关联起来可能会很麻烦。本文档通过指定一种机制来更新[RFC4486]，该机制将发送一条简短的自由格式UTF-8[RFC3629]消息作为停止通知消息[RFC4271]的一部分，以通知对等方BGP会话关闭或重置的原因。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
If a BGP speaker decides to terminate its session with a BGP neighbor, and it sends a NOTIFICATION message with the Error Code "Cease" and Error Subcode "Administrative Shutdown" or "Administrative Reset" [RFC4486], it MAY include an UTF-8 encoded string. The contents of the string are at the operator's discretion.
如果BGP演讲者决定终止其与BGP邻居的会话，并发送带有错误代码“stop”和错误子代码“Administrative Shutdown”或“Administrative Reset”[RFC4486]的通知消息，则可能包含UTF-8编码字符串。字符串的内容由操作员决定。
The Cease NOTIFICATION message with a Shutdown Communication is encoded as below:
带有停机通信的停止通知消息编码如下：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code 6 | Subcode | Length | ... \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
\ \
/ ... Shutdown Communication ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Code 6 | Subcode | Length | ... \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ /
\ \
/ ... Shutdown Communication ... /
\ \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1
图1
Subcode: the Error Subcode value MUST be one of the following values: 2 ("Administrative Shutdown") or 4 ("Administrative Reset").
子代码：错误子代码值必须是以下值之一：2（“管理关闭”）或4（“管理重置”）。
Length: this 8-bit field represents the length of the Shutdown Communication field in octets. The length value MUST range from 0 to 128 inclusive. When the length value is zero, no Shutdown Communication field follows.
长度：此8位字段表示关机通信字段的长度（以八位字节为单位）。长度值的范围必须为0到128（含0到128）。当长度值为零时，不会出现停机通信字段。
Shutdown Communication: to support international characters, the Shutdown Communication field MUST be encoded using UTF-8. A receiving BGP speaker MUST NOT interpret invalid UTF-8 sequences. Note that when the Shutdown Communication contains multibyte characters, the number of characters will be less than the length value. This field is not NUL terminated.
停机通信：为了支持国际字符，必须使用UTF-8对停机通信字段进行编码。接收BGP的扬声器不得解释无效的UTF-8序列。请注意，当关机通信包含多字节字符时，字符数将小于长度值。此字段未以NUL结尾。
Mechanisms concerning the reporting of information contained in the Shutdown Communication are implementation specific but SHOULD include methods such as Syslog [RFC5424].
关于报告停堆通信中包含的信息的机制是特定于实现的，但应包括Syslog[RFC5424]等方法。
Operators are encouraged to use the Shutdown Communication to inform their peers of the reason for the shutdown of the BGP session and include out-of-band reference materials. An example of a useful Shutdown Communication would be:
鼓励操作员使用关机通信通知其同行BGP会话关机的原因，并包括带外参考资料。有用的停机通信示例如下：
"[TICKET-1-1438367390] software upgrade; back in 2 hours"
“[TICKET-1-1438367390]软件升级；2小时后返回”
"[TICKET-1-1438367390]" is a ticket reference with significance to both the sender and receiver, followed by a brief human-readable message regarding the reason for the BGP session shutdown followed by
“[TICKET-1-1438367390]”是一个对发送方和接收方都具有重要意义的TICKET引用，后面是一条简短的人类可读消息，说明BGP会话关闭的原因，然后是
an indication about the length of the maintenance. The receiver can now use the string 'TICKET-1-1438367390' to search in their email archive to find more details.
关于维护时间长度的指示。接收者现在可以使用字符串“TICKET-1-1438367390”在其电子邮件存档中搜索，以查找更多详细信息。
If a Shutdown Communication with an invalid Length value, or an invalid UTF-8 sequence is received, a message indicating this event SHOULD be logged for the attention of the operator. An erroneous or malformed Shutdown Communication itself MAY be logged in a hexdump format.
如果接收到具有无效长度值或无效UTF-8序列的停机通信，则应记录指示此事件的消息，以供操作员注意。错误或格式错误的停机通信本身可能以hexdump格式记录。
IANA references this document (in addition to [RFC4486]) for subcodes "Administrative Shutdown" (2) and "Administrative Reset" (4) in the "Cease NOTIFICATION message subcodes" registry under the "Border Gateway Protocol (BGP) Parameters" group.
IANA在“边界网关协议（BGP）参数”组下的“停止通知消息子代码”注册表中的子代码“管理关闭”（2）和“管理重置”（4）中引用了本文件（除了[RFC4486]）。
This document uses UTF-8 encoding for the Shutdown Communication. There are a number of security issues with Unicode. Implementers and operators are advised to review Unicode Technical Report #36 [UTR36] to learn about these issues. UTF-8 "Shortest Form" encoding is REQUIRED to guard against the technical issues outlined in [UTR36].
本文件使用UTF-8编码进行停机通信。Unicode存在许多安全问题。建议实施者和运营商查看Unicode技术报告#36[UTR36]，了解这些问题。UTF-8“最短形式”编码是为了防止[UTR36]中概述的技术问题。
As BGP Shutdown Communications are likely to appear in syslog output, there is a risk that carefully constructed Shutdown Communication might be formatted by receiving systems in a way to make them appear as additional syslog messages. To limit the ability to mount such an attack, the BGP Shutdown Communication is limited to 128 octets in length.
由于BGP关机通信可能出现在系统日志输出中，因此接收系统可能会对精心构建的关机通信进行格式化，使其显示为附加系统日志消息。为了限制发起此类攻击的能力，BGP关机通信的长度限制为128个八位字节。
Users of this mechanism should be aware that unless a transport that provides integrity is used for the BGP session in question, a Shutdown Communication message could be forged. Unless a transport that provides confidentiality is used, a Shutdown Communication message could be snooped by an attacker. These issues are common to any BGP message but may be of greater interest in the context of this proposal since the information carried in the message is generally expected to be used for human-to-human communication. Refer to the related considerations in [RFC4271] and [RFC4272].
此机制的用户应注意，除非为相关BGP会话使用提供完整性的传输，否则可能伪造关机通信消息。除非使用提供机密性的传输，否则攻击者可能会窥探关机通信消息。这些问题在任何BGP报文中都是常见的，但在本提案中可能会引起更大的兴趣，因为报文中携带的信息通常用于人与人之间的通信。请参阅[RFC4271]和[RFC4272]中的相关注意事项。
Users of this mechanism should consider applying data minimization practices as outlined in Section 6.1 of [RFC6973] because a received Shutdown Communication may be used at the receiver's discretion.
该机制的用户应该考虑应用[RCF693]第6.1节中概述的数据最小化实践，因为接收到的关闭通信可以在接收机的胡理下使用。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <http://www.rfc-editor.org/info/rfc3629>.
[RFC3629]Yergeau，F.，“UTF-8，ISO 10646的转换格式”，STD 63，RFC 3629，DOI 10.17487/RFC3629，2003年11月<http://www.rfc-editor.org/info/rfc3629>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 4271，DOI 10.17487/RFC4271，2006年1月<http://www.rfc-editor.org/info/rfc4271>.
[RFC4486] Chen, E. and V. Gillet, "Subcodes for BGP Cease Notification Message", RFC 4486, DOI 10.17487/RFC4486, April 2006, <http://www.rfc-editor.org/info/rfc4486>.
[RFC4486]Chen，E.和V.Gillet，“BGP停止通知消息的子代码”，RFC 4486，DOI 10.17487/RFC4486，2006年4月<http://www.rfc-editor.org/info/rfc4486>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<http://www.rfc-editor.org/info/rfc8174>.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.
[RFC4272]Murphy，S.，“BGP安全漏洞分析”，RFC 4272，DOI 10.17487/RFC4272，2006年1月<http://www.rfc-editor.org/info/rfc4272>.
[RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, DOI 10.17487/RFC5424, March 2009, <http://www.rfc-editor.org/info/rfc5424>.
[RFC5424]Gerhards，R.，“系统日志协议”，RFC 5424DOI 10.17487/RFC54242009年3月<http://www.rfc-editor.org/info/rfc5424>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <http://www.rfc-editor.org/info/rfc6973>.
[RFC6973]Cooper，A.，Tschofenig，H.，Aboba，B.，Peterson，J.，Morris，J.，Hansen，M.，和R.Smith，“互联网协议的隐私考虑”，RFC 6973，DOI 10.17487/RFC6973，2013年7月<http://www.rfc-editor.org/info/rfc6973>.
[UTR36] Davis, M., Ed. and M. Suignard, Ed., "Unicode Security Considerations", Unicode Technical Report #36, August 2010, <http://unicode.org/reports/tr36/>.
[UTR36]Davis，M.，Ed.和M.Suignard，Ed.，“Unicode安全注意事项”，Unicode技术报告#36，2010年8月<http://unicode.org/reports/tr36/>.
Acknowledgements
致谢
The authors would like to gratefully acknowledge Tom Scholl, David Freedman, Jared Mauch, Jeff Haas, Peter Hessler, Bruno Decraene, John Heasley, Peter van Dijk, Arjen Zonneveld, James Bensley, Susan Hares, Saku Ytti, Lou Berger, Alvaro Retana, and Adam Roach.
作者要感谢汤姆·斯科尔、大卫·弗里德曼、贾里德·莫奇、杰夫·哈斯、彼得·赫斯勒、布鲁诺·德雷纳、约翰·希斯利、彼得·范·迪克、阿扬·佐内维尔德、詹姆斯·本斯利、苏珊·哈雷斯、萨库·伊蒂、卢·伯杰、阿尔瓦罗·雷塔纳和亚当·罗奇。
The authors would like to thank Enke Chen and Vincent Gillet for their work on [RFC4486] and granting the related rights to the IETF Trust per BCP 78.
作者要感谢Enke Chen和Vincent Gillet在[RFC4486]方面的工作，并根据BCP 78向IETF信托授予相关权利。
Authors' Addresses
作者地址
Job Snijders NTT Communications Theodorus Majofskistraat 100 Amsterdam 1065 SZ The Netherlands
Job Snijders NTT Communications Theodorus Majofskistraat 100阿姆斯特丹1065 SZ荷兰
Email: job@ntt.net
Email: job@ntt.net
Jakob Heitz Cisco 170 West Tasman Drive San Jose, CA 95134 United States of America
美国加利福尼亚州圣何塞西塔斯曼大道170号，邮编95134
Email: jheitz@cisco.com
Email: jheitz@cisco.com
John Scudder Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 United States of America
John Scudder Juniper Networks 1194 N.Mathilda Ave Sunnyvale，加利福尼亚州，美利坚合众国，邮编94089
Email: jgs@juniper.net
Email: jgs@juniper.net