Internet Engineering Task Force (IETF) B. Volz
Request for Comments: 8213 Y. Pal
Category: Standards Track Cisco Systems
ISSN: 2070-1721 August 2017
Internet Engineering Task Force (IETF) B. Volz
Request for Comments: 8213 Y. Pal
Category: Standards Track Cisco Systems
ISSN: 2070-1721 August 2017
Security of Messages Exchanged between Servers and Relay Agents
服务器和中继代理之间交换的消息的安全性
Abstract
摘要
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) states that IPsec should be used to secure messages exchanged between servers and relay agents but does not require encryption. With recent concerns about pervasive monitoring and other attacks, it is appropriate to require securing relay-to-relay and relay-to-server communication for DHCPv6 and relay-to-server communication for DHCPv4.
IPv4的动态主机配置协议（DHCPv4）没有指导如何保护服务器和中继代理之间交换的消息。IPv6的动态主机配置协议（DHCPv6）规定，应使用IPsec保护服务器和中继代理之间交换的消息，但不需要加密。鉴于最近对普遍监控和其他攻击的担忧，对于DHCPv6，需要保护中继到中继和中继到服务器的通信，对于DHCPv4，需要保护中继到服务器的通信。
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/rfc8213.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc8213.
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许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................2
2. Requirements Language and Terminology ...........................3
3. Security of Messages Exchanged between Servers and Relay
Agents ..........................................................3
4. Security Considerations .........................................5
5. IANA Considerations .............................................5
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
Acknowledgments ....................................................8
Authors' Addresses .................................................8
1. Introduction ....................................................2
2. Requirements Language and Terminology ...........................3
3. Security of Messages Exchanged between Servers and Relay
Agents ..........................................................3
4. Security Considerations .........................................5
5. IANA Considerations .............................................5
6. References ......................................................6
6.1. Normative References .......................................6
6.2. Informative References .....................................6
Acknowledgments ....................................................8
Authors' Addresses .................................................8
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) [RFC2131] and the Bootstrap Protocol [RFC1542] have no guidance for how to secure messages exchanged between servers and relay agents. The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] states that IPsec should be used to secure messages exchanged between servers and relay agents but does not recommend encryption. With recent concerns about pervasive monitoring [RFC7258], it is appropriate to require use of IPsec with encryption for relay-to-server communication for DHCPv4 and require use of IPsec with encryption for relay-to-relay and relay-to-server communication for DHCPv6.
IPv4的动态主机配置协议（DHCPv4）[RFC2131]和引导协议[RFC1542]对于如何保护服务器和中继代理之间交换的消息没有指导。IPv6的动态主机配置协议（DHCPv6）[RFC3315]规定，应使用IPsec保护服务器和中继代理之间交换的消息，但不建议加密。考虑到最近对普适监控的担忧[RFC7258]，对于DHCPv4，要求使用带加密的IPsec进行中继到服务器的通信，对于DHCPv6，要求使用带加密的IPsec进行中继到中继和中继到服务器的通信。
This document specifies the optional requirements for relay agent and server implementations to support IPsec authentication and encryption and recommends that operators enable this IPsec support.
本文档规定了中继代理和服务器实现支持IPsec身份验证和加密的可选要求，并建议运营商启用此IPsec支持。
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]所述进行解释。
This document uses terminology from [RFC1542], [RFC2131], and [RFC3315].
本文件使用[RFC1542]、[RFC2131]和[RFC3315]中的术语。
For DHCPv6 [RFC3315], this specification REQUIRES relay and server implementations to support IPsec encryption of relay-to-relay and relay-to-server communication as documented below. The remainder of this section replaces the text in Section 21.1 of [RFC3315] when this specification is followed.
对于DHCPv6[RFC3315]，本规范要求中继和服务器实现支持中继到中继和中继到服务器通信的IPsec加密，如下所述。当遵循本规范时，本节剩余部分将取代[RFC3315]第21.1节中的文本。
For DHCPv4 [RFC2131], this specification REQUIRES relay and server implementations to support IPsec encryption of relay-to-server communication as documented below.
对于DHCPv4[RFC2131]，本规范要求中继和服务器实现支持中继到服务器通信的IPsec加密，如下所述。
This specification RECOMMENDS that operators enable IPsec for this communication.
此规范建议操作员为此通信启用IPsec。
By using IPsec with encryption for this communication, potentially sensitive client message and relay included information, such as the DHCPv4 Relay Agent Information option (82) [RFC3046], vendor-specific information (for example, the options defined in [CableLabs-DHCP]), and Access-Network-Identifier option(s) [RFC7839], are protected from pervasive monitoring and other attacks.
通过对此通信使用带加密的IPsec，潜在敏感的客户端消息和中继包含信息，例如DHCPv4中继代理信息选项（82）[RFC3046]、供应商特定信息（例如，[CableLabs DHCP]中定义的选项）和访问网络标识符选项[RFC7839]，受到保护，免受无处不在的监视和其他攻击。
Relay agents and servers MUST be able to exchange messages using the IPsec mechanisms described in [RFC4301] with the conditions below. If a client message is relayed through multiple relay agents (relay chain), each of the relay agents MUST have established independent, pairwise trust relationships. That is, if messages from client C will be relayed by relay agent A to relay agent B and then to the server, relay agents A and B MUST be configured to use IPsec for the messages they exchange, and relay agent B and the server MUST be configured to use IPsec for the messages they exchange.
中继代理和服务器必须能够使用[RFC4301]中描述的IPsec机制在以下条件下交换消息。如果客户端消息通过多个中继代理（中继链）中继，则每个中继代理必须建立独立的成对信任关系。也就是说，如果来自客户端C的消息将由中继代理A中继到中继代理B，然后再中继到服务器，则中继代理A和B必须配置为对其交换的消息使用IPsec，并且中继代理B和服务器必须配置为对其交换的消息使用IPsec。
Relay agents and servers use IPsec with the following conditions:
中继代理和服务器在以下条件下使用IPsec：
Selectors Relay agents are manually configured with the addresses of the relay agent or server to which DHCP messages are to be forwarded. Each relay agent and server that will be using IPsec for securing DHCP messages MUST also be configured with a list of the relay agents to which messages will be returned. The selectors for the relay agents and servers will be the pairs of addresses defining relay agents and servers and the direction of DHCP message exchange on DHCPv4 UDP port 67 or DHCPv6 UDP port 547.
选择器中继代理手动配置有要转发DHCP消息的中继代理或服务器的地址。每个将使用IPsec保护DHCP消息的中继代理和服务器还必须配置一个消息将返回到的中继代理列表。中继代理和服务器的选择器将是定义中继代理和服务器的地址对，以及DHCPv4 UDP端口67或DHCPv6 UDP端口547上DHCP消息交换的方向。
Mode Relay agents and servers MUST use IPsec in transport mode and use Encapsulating Security Payload (ESP).
模式中继代理和服务器必须在传输模式下使用IPsec，并使用封装安全有效负载（ESP）。
Encryption and authentication algorithms This document REQUIRES combined mode algorithms for ESP authenticated encryption, ESP encryption algorithms, and ESP authentication algorithms as per Sections 2.1, 2.2, and 2.3 of [RFC7321], respectively. Encryption is required as relay agents may forward unencrypted client messages as well as include additional sensitive information, such as vendor-specific information (for example, the options defined in [CableLabs-DHCP]) and the Access-Network-Identifier Option defined in [RFC7839].
加密和认证算法本文件要求分别按照[RFC7321]第2.1节、第2.2节和第2.3节，组合模式算法用于ESP认证加密、ESP加密算法和ESP认证算法。需要加密，因为中继代理可能转发未加密的客户端消息，并包括其他敏感信息，如供应商特定信息（例如，[CableLabs DHCP]中定义的选项）和[RFC7839]中定义的访问网络标识符选项。
Key management Because both relay agents and servers tend to be managed by a single organizational entity, public key schemes MAY be optional. Manually configured key management MAY suffice but does not provide defense against replayed messages. Accordingly, Internet Key Exchange Protocol Version 2 (IKEv2) [RFC7296] with pre-shared secrets SHOULD be supported. IKEv2 with public keys MAY be supported. Additional information on manual vs. automated key management and when one should be used over the other can be found in [RFC4107].
密钥管理因为中继代理和服务器都倾向于由单个组织实体管理，所以公钥方案可能是可选的。手动配置的密钥管理可能就足够了，但不能防止重播消息。因此，应支持具有预共享秘密的Internet密钥交换协议版本2（IKEv2）[RFC7296]。可能支持带有公钥的IKEv2。有关手动与自动密钥管理的更多信息，以及何时应使用其中一种密钥管理，请参见[RFC4107]。
Security policy DHCP messages between relay agents and servers MUST only be accepted from DHCP peers as identified in the local configuration.
中继代理和服务器之间的安全策略DHCP消息必须仅从本地配置中标识的DHCP对等方接受。
Authentication Shared keys, indexed to the source IP address of the received DHCP message, are adequate in this application.
根据接收到的DHCP消息的源IP地址编制索引的身份验证共享密钥在此应用程序中已足够。
Note: As using IPsec with multicast has additional complexities (see [RFC5374]), relay agents SHOULD be configured to forward DHCP messages to unicast addresses.
注意：由于将IPsec与多播一起使用具有额外的复杂性（请参见[RFC5374]），因此应将中继代理配置为将DHCP消息转发到单播地址。
The security model specified in this document is hop by hop. For DHCPv6, there could be multiple relay agents between a client and server, and each of these hops needs to be secured. For DHCPv4, there is no support for multiple relays.
本文档中指定的安全模型是逐跳的。对于DHCPv6，客户机和服务器之间可能有多个中继代理，并且每个跃点都需要得到保护。对于DHCPv4，不支持多个继电器。
As this document only mandates securing messages exchanged between relay agents and servers, the message exchanges between clients and the first-hop relay agent or server are not secured. Clients may follow the recommendations in [RFC7844] to minimize what information they expose or make use of secure DHCPv6 [SEC-DHCPv6] to secure communication between the client and server.
由于本文档仅要求保护中继代理和服务器之间交换的消息，因此客户端和第一跳中继代理或服务器之间的消息交换不安全。客户机可以遵循[RFC7844]中的建议，尽量减少公开的信息，或者利用安全DHCPv6[SEC-DHCPv6]来保护客户机和服务器之间的通信。
As mentioned in Section 14 of [RFC4552], the following are known limitations of the usage of manual keys:
如[RFC4552]第14节所述，以下是使用手动钥匙的已知限制：
o As the sequence numbers cannot be negotiated, replay protection cannot be provided. This leaves DHCP insecure against all the attacks that can be performed by replaying DHCP packets.
o 由于无法协商序列号，因此无法提供重播保护。这使得DHCP对所有可以通过重播DHCP数据包执行的攻击都不安全。
o Manual keys are usually long lived (changing them often is a tedious task). This gives an attacker enough time to discover the keys.
o 手动钥匙通常寿命很长（经常更换它们是一项乏味的任务）。这使攻击者有足够的时间发现密钥。
It should be noted that if the requirements in this document are followed, while the DHCP traffic on the wire between relays and servers is encrypted, the unencrypted data may still be available through other attacks on the DHCP servers, relays, and related systems. Securing these systems and the data in databases and logs also needs to be considered on both the systems themselves and when transferred over a network (i.e., to network attached storage for backups or to operational support systems).
应该注意的是，如果遵循本文档中的要求，而中继和服务器之间的线路上的DHCP通信是加密的，则未加密的数据可能仍然可以通过对DHCP服务器、中继和相关系统的其他攻击获得。保护这些系统以及数据库和日志中的数据的安全还需要在系统本身以及通过网络传输时（即，到网络连接存储进行备份或到操作支持系统）加以考虑。
Use of IPsec as described herein is also applicable to Lightweight DHCPv6 Relay Agents [RFC6221], as they have a link-local address that can be used to secure communication with their next-hop relay(s).
本文所述的IPsec的使用也适用于轻型DHCPv6中继代理[RFC6221]，因为它们具有可用于保护与其下一跳中继的通信的链路本地地址。
This document makes no request of IANA.
本文件未向IANA提出任何要求。
[RFC1542] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, DOI 10.17487/RFC1542, October 1993, <http://www.rfc-editor.org/info/rfc1542>.
[RFC1542]Wimer，W.，“引导协议的澄清和扩展”，RFC 1542，DOI 10.17487/RFC1542，1993年10月<http://www.rfc-editor.org/info/rfc1542>.
[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>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, <http://www.rfc-editor.org/info/rfc2131>.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC 2131，DOI 10.17487/RFC2131，1997年3月<http://www.rfc-editor.org/info/rfc2131>.
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC 3315，DOI 10.17487/RFC3315，2003年7月<http://www.rfc-editor.org/info/rfc3315>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<http://www.rfc-editor.org/info/rfc4301>.
[RFC7321] McGrew, D. and P. Hoffman, "Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)", RFC 7321, DOI 10.17487/RFC7321, August 2014, <http://www.rfc-editor.org/info/rfc7321>.
[RFC7321]McGrew，D.和P.Hoffman，“封装安全有效载荷（ESP）和身份验证头（AH）的密码算法实现要求和使用指南”，RFC 7321，DOI 10.17487/RFC7321，2014年8月<http://www.rfc-editor.org/info/rfc7321>.
[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>.
[CableLabs-DHCP] CableLabs, "CableLabs' DHCP Options Registry", <https://apps.cablelabs.com/specification/CL-SP-CANN-DHCP-Reg>.
[CableLabs DHCP]CableLabs，“CableLabs的DHCP选项注册表”<https://apps.cablelabs.com/specification/CL-SP-CANN-DHCP-Reg>.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, DOI 10.17487/RFC3046, January 2001, <http://www.rfc-editor.org/info/rfc3046>.
[RFC3046]Patrick，M.，“DHCP中继代理信息选项”，RFC 3046，DOI 10.17487/RFC3046，2001年1月<http://www.rfc-editor.org/info/rfc3046>.
[RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic Key Management", BCP 107, RFC 4107, DOI 10.17487/RFC4107, June 2005, <http://www.rfc-editor.org/info/rfc4107>.
[RFC4107]Bellovin，S.和R.Housley，“加密密钥管理指南”，BCP 107，RFC 4107，DOI 10.17487/RFC4107，2005年6月<http://www.rfc-editor.org/info/rfc4107>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, <http://www.rfc-editor.org/info/rfc4552>.
[RFC4552]Gupta，M.和N.Melam，“OSPFv3的认证/保密”，RFC 4552，DOI 10.17487/RFC4552，2006年6月<http://www.rfc-editor.org/info/rfc4552>.
[RFC5374] Weis, B., Gross, G., and D. Ignjatic, "Multicast Extensions to the Security Architecture for the Internet Protocol", RFC 5374, DOI 10.17487/RFC5374, November 2008, <http://www.rfc-editor.org/info/rfc5374>.
[RFC5374]Weis，B.，Gross，G.和D.Ignjatic，“互联网协议安全架构的多播扩展”，RFC 5374，DOI 10.17487/RFC5374，2008年11月<http://www.rfc-editor.org/info/rfc5374>.
[RFC6221] Miles, D., Ed., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, DOI 10.17487/RFC6221, May 2011, <http://www.rfc-editor.org/info/rfc6221>.
[RFC6221]Miles，D.，Ed.，Ooghe，S.，Dec，W.，Krishnan，S.，和A.Kavanagh，“轻型DHCPv6中继代理”，RFC 6221DOI 10.17487/RFC6221，2011年5月<http://www.rfc-editor.org/info/rfc6221>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[RFC7258]Farrell，S.和H.Tschofenig，“普遍监控是一种攻击”，BCP 188，RFC 7258，DOI 10.17487/RFC7258，2014年5月<http://www.rfc-editor.org/info/rfc7258>.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, <http://www.rfc-editor.org/info/rfc7296>.
[RFC7296]Kaufman，C.，Hoffman，P.，Nir，Y.，Eronen，P.，和T.Kivinen，“互联网密钥交换协议版本2（IKEv2）”，STD 79，RFC 7296，DOI 10.17487/RFC72962014年10月<http://www.rfc-editor.org/info/rfc7296>.
[RFC7839] Bhandari, S., Gundavelli, S., Grayson, M., Volz, B., and J. Korhonen, "Access-Network-Identifier Option in DHCP", RFC 7839, DOI 10.17487/RFC7839, June 2016, <http://www.rfc-editor.org/info/rfc7839>.
[RFC7839]Bhandari，S.，Gundavelli，S.，Grayson，M.，Volz，B.，和J.Korhonen，“DHCP中的接入网络标识符选项”，RFC 7839，DOI 10.17487/RFC7839，2016年6月<http://www.rfc-editor.org/info/rfc7839>.
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <http://www.rfc-editor.org/info/rfc7844>.
[RFC7844]Huitema，C.，Mrugalski，T.，和S.Krishnan，“DHCP客户端的匿名配置文件”，RFC 7844，DOI 10.17487/RFC7844，2016年5月<http://www.rfc-editor.org/info/rfc7844>.
[SEC-DHCPv6] Li, L., Jiang, S., Cui, Y., Jinmei, T., Lemon, T., and D. Zhang, "Secure DHCPv6", Work in Progress, draft-ietf-dhc-sedhcpv6-21, February 2017.
[SEC-DHCPv6]Li，L.，Jiang，S.，Cui，Y.，Jinmei，T.，Lemon，T.，和D.Zhang，“安全DHCPv6”，正在进行的工作，草案-ietf-dhc-sedhcpv6-212017年2月。
Acknowledgments
致谢
The motivation for this document was several IESG DISCUSSes on recent DHCP relay agent options.
本文档的动机是IESG对最近DHCP中继代理选项的几次讨论。
Thanks to Kim Kinnear, Jinmei Tatuya, Francis Dupont, and Tomek Mrugalski for reviewing and helping to improve the document. Thanks to the authors of [RFC3315] for the original Section 21.1 text.
感谢Kim Kinnear、Jinmei Tatuya、Francis Dupont和Tomek Mrugalski审查并帮助改进该文件。感谢[RFC3315]的作者提供原始第21.1节文本。
Authors' Addresses
作者地址
Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 United States of America
Bernie Volz Cisco Systems，Inc.美国马萨诸塞州Boxborough大道1414号，邮编01719
Email: volz@cisco.com
Email: volz@cisco.com
Yogendra Pal Cisco Systems Cessna Business Park Varthur Hobli, Outer Ring Road Bangalore, Karnataka 560103 India
印度卡纳塔克邦班加罗尔外环路瓦尔图尔霍布里商业园Yogendra Pal Cisco Systems Cessna 560103
Email: yogpal@cisco.com
Email: yogpal@cisco.com