Internet Engineering Task Force (IETF) D. Evans
Request for Comments: 6644 IPfonix, Inc.
Updates: 3315 R. Droms
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 S. Jiang
Huawei Technologies Co., Ltd
July 2012
Internet Engineering Task Force (IETF) D. Evans
Request for Comments: 6644 IPfonix, Inc.
Updates: 3315 R. Droms
Category: Standards Track Cisco Systems, Inc.
ISSN: 2070-1721 S. Jiang
Huawei Technologies Co., Ltd
July 2012
Rebind Capability in DHCPv6 Reconfigure Messages
DHCPv6重新配置消息中的重新绑定功能
Abstract
摘要
This document updates RFC 3315 (DHCPv6) to allow the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message. It extends the Reconfigure message to allow a DHCPv6 server to cause a DHCPv6 client to send a Rebind message. The document also clarifies how a DHCPv6 client responds to a received Reconfigure message.
本文档更新RFC 3315（DHCPv6），以允许重新绑定消息类型出现在重新配置消息的重新配置消息选项中。它扩展了重新配置消息，允许DHCPv6服务器使DHCPv6客户端发送重新绑定消息。本文档还阐明了DHCPv6客户机如何响应收到的重新配置消息。
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 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第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/rfc6644.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6644.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 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 ....................................................3
2. Terminology .....................................................3
3. The Reconfigure Message Option of the DHCPv6 Reconfigure
Message .........................................................3
4. Server Behavior .................................................4
5. Client Behavior .................................................7
6. Clarification of Section 19.4.2, RFC 3315 .......................8
7. Security Considerations .........................................8
8. Acknowledgements ................................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References.....................................9
1. Introduction ....................................................3
2. Terminology .....................................................3
3. The Reconfigure Message Option of the DHCPv6 Reconfigure
Message .........................................................3
4. Server Behavior .................................................4
5. Client Behavior .................................................7
6. Clarification of Section 19.4.2, RFC 3315 .......................8
7. Security Considerations .........................................8
8. Acknowledgements ................................................9
9. References ......................................................9
9.1. Normative References .......................................9
9.2. Informative References.....................................9
DHCPv6 [RFC3315] allows a server to send an unsolicited Reconfigure message to a client. The client's response to a Reconfigure message, according to Section 19 of RFC 3315, is either a Renew or an Information-request message, depending on the contents of the msg-type field in the Reconfigure Message option of the Reconfigure message. If the client sends a Renew message, it includes a Server Identifier option in the Renew message to specify the server that should respond to the Renew message. The specification defined in RFC 3315 is suitable only for scenarios in which the client would communicate with the same DHCPv6 servers.
DHCPv6[RFC3315]允许服务器向客户端发送未经请求的重新配置消息。根据RFC 3315第19节，客户端对重新配置消息的响应是续订消息或信息请求消息，具体取决于重新配置消息的重新配置消息选项中消息类型字段的内容。如果客户端发送续订消息，则会在续订消息中包含服务器标识符选项，以指定应响应续订消息的服务器。RFC 3315中定义的规范仅适用于客户端将与相同DHCPv6服务器通信的场景。
There are also scenarios where the client must communicate with a different server; for example, a network administrator may choose to shut down a DHCPv6 server and move the clients who most recently communicated with it to a different server. Hence, this document expands the allowed values of the message type field within the reconfiguration message to allow the server to indicate to the client to send a Rebind message, which does not include a Server Identifier option, and allows any server to respond to the client.
还有一些情况下，客户端必须与不同的服务器通信；例如，网络管理员可以选择关闭DHCPv6服务器，并将最近与其通信的客户端移动到其他服务器。因此，本文档扩展了重新配置消息中消息类型字段的允许值，以允许服务器指示客户端发送重新绑定消息（不包括服务器标识符选项），并允许任何服务器响应客户端。
RFC 3315 does not specify that a Reconfigure message must be sent from the server with which the client most recently communicated, and it does not specify which server the client should identify with a Server Identifier option when the client responds to the Reconfigure message. This document clarifies that the client should send a Renew message in response to a Reconfigure message with a Server Identifier option identifying the same server that the client would have identified if the client had sent the Renew message after expiration of the timer T1.
RFC 3315未指定必须从客户端最近与之通信的服务器发送重新配置消息，也未指定客户端在响应重新配置消息时应使用服务器标识符选项标识哪个服务器。本文档阐明，客户机应发送续订消息，以响应带有服务器标识符选项的重新配置消息，该选项标识了如果客户机在计时器T1过期后发送续订消息，则客户机将标识的同一服务器。
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]中所述进行解释。
This document uses IPv6 and DHCPv6 terms as defined in Section 4 of [RFC3315].
本文件使用[RFC3315]第4节中定义的IPv6和DHCPv6术语。
This section modifies Section 22.19 of RFC 3315 to allow the specification of the Rebind message in a Reconfigure message.
本节修改了RFC 3315第22.19节，以允许在重新配置消息中指定重新绑定消息。
A server includes a Reconfigure Message option in a Reconfigure message to indicate to the client whether the client responds with a Renew, an Information-request, or a Rebind message.
服务器在重新配置消息中包括重新配置消息选项，以向客户端指示客户端是以续订、信息请求还是重新绑定消息进行响应。
The format of this option is:
此选项的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |
+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_RECONF_MSG | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| msg-type |
+-+-+-+-+-+-+-+-+
option-code OPTION_RECONF_MSG (19). option-len 1. msg-type 5 for Renew message, 6 for Rebind, 11 for Information-request message.
选项代码选项识别信息（19）。选项1。消息类型5表示续订消息，6表示重新绑定，11表示信息请求消息。
This section updates specific text in Sections 19.1 and 19.2 of RFC 3315.
本节更新RFC 3315第19.1节和第19.2节中的具体文本。
Section 19.1.1:
第19.1.1节：
OLD:
旧的：
The server MUST include a Reconfigure Message option (defined in section 22.19) to select whether the client responds with a Renew message or an Information-Request message.
服务器必须包括一个重新配置消息选项（在第22.19节中定义），以选择客户端是使用续订消息还是信息请求消息进行响应。
The server MUST NOT include any other options in the Reconfigure except as specifically allowed in the definition of individual options.
服务器不得在重新配置中包含任何其他选项，除非在单个选项的定义中明确允许。
A server sends each Reconfigure message to a single DHCP client, using an IPv6 unicast address of sufficient scope belonging to the DHCP client. If the server does not have an address to which it can send the Reconfigure message directly to the client, the server uses a Relay-reply message (as described in section 20.3) to send the Reconfigure message to a relay agent that will relay the message to the client. The server may obtain the address of the client (and the appropriate relay agent, if required) through the information the server has about clients that have been in contact with the server, or through some external agent.
服务器使用属于DHCP客户端的足够范围的IPv6单播地址将每个重新配置消息发送到单个DHCP客户端。如果服务器没有地址可将重新配置消息直接发送至客户端，则服务器使用中继回复消息（如第20.3节所述）将重新配置消息发送至中继代理，中继代理将消息中继至客户端。服务器可以通过服务器拥有的关于与服务器接触的客户机的信息，或者通过一些外部代理来获取客户机（以及适当的中继代理，如果需要）的地址。
To reconfigure more than one client, the server unicasts a separate message to each client. The server may initiate the reconfiguration of multiple clients concurrently; for example, a server may send a Reconfigure message to additional clients while previous reconfiguration message exchanges are still in progress.
要重新配置多个客户端，服务器将向每个客户端单播一条单独的消息。服务器可同时启动多个客户端的重新配置；例如，当先前的重新配置消息交换仍在进行中时，服务器可能会向其他客户端发送重新配置消息。
The Reconfigure message causes the client to initiate a Renew/Reply or Information-request/Reply message exchange with the server. The server interprets the receipt of a Renew or Information-request message (whichever was specified in the original Reconfigure message) from the client as satisfying the Reconfigure message request.
重新配置消息导致客户端启动与服务器的续订/回复或信息请求/回复消息交换。服务器将从客户端接收到续订或信息请求消息（以原始重新配置消息中指定的为准）解释为满足重新配置消息请求。
NEW:
新的：
The server MUST include a Reconfigure Message option (as defined in Section 3 of RFC 6644) to select whether the client responds with a Renew message, a Rebind message, or an Information-request message. The server MUST NOT include any other options in the Reconfigure, except as specifically allowed in the definition of individual options.
服务器必须包括一个重新配置消息选项（如RFC 6644第3节中所定义），以选择客户端是使用续订消息、重新绑定消息还是信息请求消息进行响应。服务器不得在重新配置中包含任何其他选项，除非个别选项定义中明确允许。
A server sends each Reconfigure message to a single DHCP client, using an IPv6 unicast address of sufficient scope belonging to the DHCP client. If the server does not have an address to which it can send the Reconfigure message directly to the client, the server uses a Relay-reply message (as described in Section 20.3) to send the Reconfigure message to a relay agent that will relay the message to the client. The server may obtain the address of the client (and the appropriate relay agent, if required) through the information the server has about clients that have been in contact with the server, or through some external agent.
服务器使用属于DHCP客户端的足够范围的IPv6单播地址将每个重新配置消息发送到单个DHCP客户端。如果服务器没有地址可将重新配置消息直接发送至客户端，则服务器使用中继回复消息（如第20.3节所述）将重新配置消息发送至中继代理，中继代理将消息中继至客户端。服务器可以通过服务器拥有的关于与服务器接触的客户机的信息，或者通过一些外部代理来获取客户机（以及适当的中继代理，如果需要）的地址。
To reconfigure more than one client, the server unicasts a separate message to each client. The server may initiate the reconfiguration of multiple clients concurrently; for example, a server may send a Reconfigure message to additional clients while previous reconfiguration message exchanges are still in progress.
要重新配置多个客户端，服务器将向每个客户端单播一条单独的消息。服务器可同时启动多个客户端的重新配置；例如，当先前的重新配置消息交换仍在进行中时，服务器可能会向其他客户端发送重新配置消息。
The Reconfigure message causes the client to initiate a Renew/Reply, a Rebind/Reply message exchange, or an Information-request/Reply message exchange. The server interprets the receipt of a Renew, a Rebind, or an Information-request message (whichever was specified in the original Reconfigure message) from the client as satisfying the Reconfigure message request.
重新配置消息导致客户端启动续订/回复、重新绑定/回复消息交换或信息请求/回复消息交换。服务器将从客户端接收到续订、重新绑定或信息请求消息（以原始重新配置消息中指定的为准）解释为满足重新配置消息请求。
Section 19.1.2:
第19.1.2节：
OLD:
旧的：
If the server does not receive a Renew or Information-request message from the client in REC_TIMEOUT milliseconds, the server retransmits the Reconfigure message, doubles the REC_TIMEOUT value and waits again. The server continues this process until REC_MAX_RC unsuccessful attempts have been made, at which point the server SHOULD abort the reconfigure process for that client.
如果服务器在REC_超时毫秒内未收到来自客户端的续订或信息请求消息，服务器将重新传输重新配置消息，将REC_超时值加倍，然后再次等待。服务器将继续此过程，直到尝试REC_MAX_RC失败，此时服务器应中止该客户端的重新配置过程。
NEW:
新的：
If the server does not receive a Renew, Rebind, or Information-request message from the client in REC_TIMEOUT milliseconds, the server retransmits the Reconfigure message, doubles the REC_TIMEOUT value, and waits again. The server continues this process until REC_MAX_RC unsuccessful attempts have been made, at which point the server SHOULD abort the reconfigure process for that client.
如果服务器在REC_超时毫秒内未收到来自客户端的续订、重新绑定或信息请求消息，则服务器将重新传输重新配置消息，将REC_超时值加倍，然后再次等待。服务器将继续此过程，直到尝试REC_MAX_RC失败，此时服务器应中止该客户端的重新配置过程。
Section 19.2:
第19.2节：
OLD:
旧的：
19.2. Receipt of Renew or Rebind Messages
19.2. 接收续订或重新绑定邮件
The server generates and sends a Reply message to the client as described in sections 18.2.3 and 18.2.8, including options for configuration parameters.
服务器按照第18.2.3节和第18.2.8节所述生成回复消息并发送给客户端，包括配置参数选项。
The server MAY include options containing the IAs and new values for other configuration parameters in the Reply message, even if those IAs and parameters were not requested in the Renew message from the client.
服务器可能会在回复消息中包含包含IAs和其他配置参数的新值的选项，即使这些IAs和参数没有在来自客户端的续订消息中请求。
NEW:
新的：
19.2. Receipt of Renew Messages
19.2. 接收续订邮件
In response to a Renew message, the server generates and sends a Reply message to the client as described in Sections 18.2.3 and 18.2.8, including options for configuration parameters.
作为对续订消息的响应，服务器按照第18.2.3节和第18.2.8节所述生成回复消息并将其发送给客户端，包括配置参数选项。
In response to a Rebind message, the server generates and sends a Reply message to the client as described in Sections 18.2.4 and 18.2.8, including options for configuration parameters.
作为对重新绑定消息的响应，服务器按照第18.2.4节和第18.2.8节所述生成回复消息并发送给客户端，包括配置参数选项。
The server MAY include options containing the identity associations (IAs) and new values for other configuration parameters in the Reply message, even if those IAs and parameters were not requested in the Renew or Rebind message from the client.
服务器可以在回复消息中包括包含标识关联（IAs）和其他配置参数的新值的选项，即使这些IAs和参数没有在来自客户端的续订或重新绑定消息中被请求。
This section updates specific text in Section 19.4 of RFC 3315.
本节更新RFC 3315第19.4节中的具体文本。
Section 19.4.1:
第19.4.1节：
OLD:
旧的：
Upon receipt of a valid Reconfigure message, the client responds with either a Renew message or an Information-request message as indicated by the Reconfigure Message option (as defined in section 22.19). The client ignores the transaction-id field in the received Reconfigure message. While the transaction is in progress, the client silently discards any Reconfigure messages it receives.
在收到有效的重新配置消息后，客户机将按照重新配置消息选项（定义见第22.19节）的指示，以更新消息或信息请求消息进行响应。客户端忽略收到的重新配置消息中的事务id字段。当事务正在进行时，客户端会自动丢弃它接收到的任何重新配置消息。
NEW:
新的：
Upon receipt of a valid Reconfigure message, the client responds with a Renew message, a Rebind message, or an Information-request message as indicated by the Reconfigure Message option (as defined in Section 3 of RFC 6644). The client ignores the transaction-id field in the received Reconfigure message. While the transaction is in progress, the client silently discards any Reconfigure messages it receives.
在收到有效的重新配置消息后，客户机将以更新消息、重新绑定消息或信息请求消息进行响应，如重新配置消息选项所示（如RFC 6644第3节所定义）。客户端忽略收到的重新配置消息中的事务id字段。当事务正在进行时，客户端会自动丢弃它接收到的任何重新配置消息。
Section 19.4.2:
第19.4.2节：
ADD new second and third paragraphs:
增加新的第二和第三段：
When responding to a Reconfigure, the client creates and sends the Rebind message in exactly the same manner as outlined in Section 18.1.4 of RFC 3315, with the exception that the client copies the Option Request option and any IA options from the Reconfigure message into the Rebind message.
当响应重新配置时，客户机以RFC 3315第18.1.4节所述的完全相同的方式创建和发送重新绑定消息，但客户机将选项请求选项和任何IA选项从重新配置消息复制到重新绑定消息中的情况除外。
If a client is currently sending Rebind messages, as described in Section 18.1.4 of RFC 3315, the client ignores any received Reconfigure messages.
如RFC 3315第18.1.4节所述，如果客户端当前正在发送重新绑定消息，则客户端将忽略任何接收到的重新配置消息。
Section 19.4.4:
第19.4.4节：
OLD:
旧的：
The client uses the same variables and retransmission algorithm as it does with Renew or Information-request messages generated as part of a client-initiated configuration exchange. See sections 18.1.3 and 18.1.5 for details. If the client does not receive a response from the server by the end of the retransmission process, the client ignores and discards the Reconfigure message.
客户端使用的变量和重传算法与在客户端启动的配置交换中生成的续订或信息请求消息相同。详见第18.1.3节和第18.1.5节。如果客户端在重新传输过程结束时未收到来自服务器的响应，则客户端将忽略并丢弃重新配置消息。
NEW:
新的：
The client uses the same variables and retransmission algorithm as it does with Renew, Rebind, or Information-request messages generated as part of a client-initiated configuration exchange. See Sections 18.1.3, 18.1.4, and 18.1.5 of RFC 3315 for details. If the client does not receive a response from the server by the end of the retransmission process, the client ignores and discards the Reconfigure message.
客户机使用的变量和重传算法与作为客户机启动的配置交换的一部分生成的续订、重新绑定或信息请求消息相同。详见RFC 3315第18.1.3、18.1.4和18.1.5节。如果客户端在重新传输过程结束时未收到来自服务器的响应，则客户端将忽略并丢弃重新配置消息。
When sending a Renew message in response to the receipt of a Reconfigure message, the client MUST include a Server Identifier option, identifying the server with which the client most recently communicated.
当发送续订消息以响应收到的重新配置消息时，客户端必须包括服务器标识符选项，以标识客户端最近与之通信的服务器。
This document allows the Rebind message type to appear in the Reconfigure Message option of a Reconfigure message so that the client rebinds to a different DHCPv6 server. A malicious attacker may use a faked Reconfigure message to force the client to disconnect from the current server and relink to a faked server by quickly responding to the client's Rebind message. A similar attack is available in DHCPv6 by an attacker spoofing itself as a valid DHCPv6 server in response to a Solicit or Request message. These attacks can be prevented by using the AUTH option [RFC3315]. DHCPv6 clients that support Reconfigure-Rebind MUST implement the Reconfigure Key authentication protocol as described in [RFC3315], Section 21.5. Other authentication mechanisms may optionally be implemented. For example, the Secure DHCPv6 [SEC-DHCPv6], based on Cryptographically Generated Addresses (CGA) [RFC3972], can provide source address (for the DHCP server/relay) ownership validation, message origin authentication, and message integrity without requiring symmetric key pairs or support from a key management system.
此文档允许重新绑定消息类型出现在重新配置消息的重新配置消息选项中，以便客户端重新绑定到不同的DHCPv6服务器。恶意攻击者可使用伪造的重新配置消息，通过快速响应客户端的重新绑定消息，强制客户端断开与当前服务器的连接，并重新链接到伪造服务器。在DHCPv6中，攻击者可通过欺骗自己作为有效的DHCPv6服务器来响应请求或请求消息，从而发起类似的攻击。通过使用AUTH选项[RFC3315]可以防止这些攻击。支持重新配置重新绑定的DHCPv6客户端必须实现[RFC3315]第21.5节中所述的重新配置密钥身份验证协议。可以可选地实现其他认证机制。例如，基于加密生成地址（CGA）[RFC3972]的安全DHCPv6[SEC-DHCPv6]可以提供源地址（用于DHCP服务器/中继）所有权验证、消息源身份验证和消息完整性，而无需对称密钥对或密钥管理系统的支持。
Valuable comments were made by Jari Arkko, Sean Turner, Ted Lemon, and Stephen Farrell.
贾里·阿尔科、肖恩·特纳、特德·莱蒙和斯蒂芬·法雷尔发表了宝贵的评论。
[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月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[SEC-DHCPv6] Jiang, S. and S. Shen, "Secure DHCPv6 Using CGAs", Work in Progress, March 2012.
[SEC-DHCPv6]Jiang，S.和S.Shen，“使用CGAs保护DHCPv6”，正在进行的工作，2012年3月。
Authors' Addresses
作者地址
D. R. Evans IPfonix, Inc. 330 WCR 16 1/2 Longmont, CO 80504-9467 USA
D.R.Evans IPfonix，Inc.美国科罗拉多州朗蒙特市330 WCR 16 1/2号，邮编80504-9467
Phone: +1 303.682.2412
EMail: N7DR@ipfonix.com
Phone: +1 303.682.2412
EMail: N7DR@ipfonix.com
Ralph Droms Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Ralph Droms Cisco Systems，Inc.美国马萨诸塞州博克斯堡马萨诸塞大道1414号，邮编01719
Phone: +1 978.936.1674
EMail: rdroms@cisco.com
Phone: +1 978.936.1674
EMail: rdroms@cisco.com
Sheng Jiang Huawei Technologies Co., Ltd Q14, Huawei Campus, No.156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China
中国北京市海淀区北青路156号华为校园盛江华为技术有限公司Q14，邮编：100095
EMail: jiangsheng@huawei.com
EMail: jiangsheng@huawei.com