Internet Engineering Task Force (IETF) T. Mrugalski
Request for Comments: 7031 ISC
Category: Informational K. Kinnear
ISSN: 2070-1721 Cisco
September 2013
Internet Engineering Task Force (IETF) T. Mrugalski
Request for Comments: 7031 ISC
Category: Informational K. Kinnear
ISSN: 2070-1721 Cisco
September 2013
DHCPv6 Failover Requirements
DHCPv6故障转移要求
Abstract
摘要
The DHCPv6 protocol, defined in RFC 3315, allows for multiple servers to operate on a single network; however, it does not define any way the servers could share information about currently active clients and their leases. Some sites are interested in running multiple servers in such a way as to provide increased availability in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information. RFC 3315 allows for, but does not define, any redundancy or failover mechanisms. This document outlines requirements for DHCPv6 failover, enumerates related problems, and discusses the proposed scope of work to be conducted. This document does not define a DHCPv6 failover protocol.
RFC 3315中定义的DHCPv6协议允许多台服务器在单个网络上运行；但是，它没有定义服务器共享当前活动客户端及其租约信息的任何方式。有些站点对运行多台服务器感兴趣，以便在服务器出现故障时提供更高的可用性。为了使其可靠地工作，协作的主服务器和辅助服务器必须维护租赁信息的一致数据库。RFC 3315允许但不定义任何冗余或故障切换机制。本文档概述了DHCPv6故障切换的要求，列举了相关问题，并讨论了拟执行的工作范围。本文档未定义DHCPv6故障切换协议。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc7031.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7031.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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 ....................................................3
2. Definitions .....................................................3
3. Scope of Work ...................................................5
3.1. Alternatives to Failover ...................................5
3.1.1. Short-Lived Addresses ...............................5
3.1.2. Redundant Servers ...................................6
3.1.3. Distributed Databases ...............................6
3.1.4. Load Balancing ......................................7
4. Failover Scenarios ..............................................7
4.1. Hot Standby Model ..........................................7
4.2. Geographically Distributed Failover ........................7
4.3. Load Balancing .............................................8
4.4. 1-to-1, m-to-1, and m-to-n Models ..........................8
4.5. Split Prefixes .............................................8
4.6. Long-Lived Connections .....................................8
4.7. Partial Server Communication Loss ..........................9
5. Principles of DHCPv6 Failover ...................................9
5.1. Failure Modes ..............................................9
5.1.1. Server Failure .....................................10
5.1.2. Network Partition ..................................10
5.2. Synchronization Mechanisms ................................11
5.2.1. Lockstep ...........................................11
5.2.2. Lazy Updates .......................................12
6. DHCPv4 and DHCPv6 Failover Comparison ..........................12
7. DHCPv6 Failover Requirements ...................................13
7.1. Features out of Scope .....................................14
8. Security Considerations ........................................15
9. Acknowledgements ...............................................15
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................16
1. Introduction ....................................................3
2. Definitions .....................................................3
3. Scope of Work ...................................................5
3.1. Alternatives to Failover ...................................5
3.1.1. Short-Lived Addresses ...............................5
3.1.2. Redundant Servers ...................................6
3.1.3. Distributed Databases ...............................6
3.1.4. Load Balancing ......................................7
4. Failover Scenarios ..............................................7
4.1. Hot Standby Model ..........................................7
4.2. Geographically Distributed Failover ........................7
4.3. Load Balancing .............................................8
4.4. 1-to-1, m-to-1, and m-to-n Models ..........................8
4.5. Split Prefixes .............................................8
4.6. Long-Lived Connections .....................................8
4.7. Partial Server Communication Loss ..........................9
5. Principles of DHCPv6 Failover ...................................9
5.1. Failure Modes ..............................................9
5.1.1. Server Failure .....................................10
5.1.2. Network Partition ..................................10
5.2. Synchronization Mechanisms ................................11
5.2.1. Lockstep ...........................................11
5.2.2. Lazy Updates .......................................12
6. DHCPv4 and DHCPv6 Failover Comparison ..........................12
7. DHCPv6 Failover Requirements ...................................13
7.1. Features out of Scope .....................................14
8. Security Considerations ........................................15
9. Acknowledgements ...............................................15
10. References ....................................................16
10.1. Normative References .....................................16
10.2. Informative References ...................................16
The DHCPv6 protocol, defined in [RFC3315], allows for multiple servers to be operating on a single network; however, it does not define how the servers can share the same address and prefix delegation pools and allow a client to seamlessly extend its existing leases when the original server is down. [RFC3315] provides for these capabilities but does not document how the servers cooperate and communicate to provide this capability. Some sites are interested in running multiple servers in such a way as to provide redundancy in case of server failure. In order for this to work reliably, the cooperating primary and secondary servers must maintain a consistent database of the lease information.
[RFC3315]中定义的DHCPv6协议允许多台服务器在单个网络上运行；但是，它没有定义服务器如何共享相同的地址和前缀委派池，并允许客户端在原始服务器关闭时无缝扩展其现有租约。[RFC3315]提供了这些功能，但未记录服务器如何合作和通信以提供此功能。一些站点对运行多台服务器感兴趣，以便在服务器出现故障时提供冗余。为了使其可靠地工作，协作的主服务器和辅助服务器必须维护租赁信息的一致数据库。
This document discusses failover implementations scenarios, failure modes, and synchronization approaches to provide background to the list of requirements for a DHCPv6 failover protocol. It then defines a minimum set of requirements that failover must provide to be useful, while acknowledging that additional features may be specified as extensions. This document does not define a DHCPv6 failover protocol.
本文档讨论故障转移实施场景、故障模式和同步方法，为DHCPv6故障转移协议的需求列表提供背景信息。然后，它定义了故障切换必须提供的一组最基本的有用需求，同时确认可以将其他功能指定为扩展。本文档未定义DHCPv6故障切换协议。
The failover model, to which these requirements apply, will initially be a pairwise "hot standby" model (see Section 4.1) with a primary server used in normal operation switching over to a backup secondary server in the event of failure. Optionally, a secondary server may provide failover service for multiple primary servers. However, the requirements will not preclude a future load-balancing extension where there is a symmetric failover relationship.
这些要求适用的故障切换模型最初将是一个成对的“热备用”模型（见第4.1节），在正常操作中使用的主服务器在发生故障时切换到备用辅助服务器。可选地，辅助服务器可以为多个主服务器提供故障切换服务。但是，这些要求不会排除将来存在对称故障切换关系的负载平衡扩展。
The DHCPv6 failover concept borrows heavily from its DHCPv4 counterpart [DHCPV4-FAILOVER] that never completed the standardization process but has several successful, operationally proven vendor-specific implementations. For a discussion about commonalities and differences, see Section 6.
DHCPv6故障切换概念大量借鉴了其对应的DHCPv4[DHCPv4-failover]，后者从未完成标准化过程，但有几个成功的、经操作验证的特定于供应商的实现。有关共性和差异的讨论，请参见第6节。
This section defines terms that are relevant to DHCPv6 failover.
本节定义了与DHCPv6故障切换相关的术语。
Definitions from [RFC3315] are included by reference. In particular, "client" means any device, e.g., end-user host, CPE (Customer Premises Equipment), or other router that implements client functionality of the DHCPv6 protocol. A "server" is a DHCPv6 server, unless explicitly noted otherwise. A "relay" is a DHCPv6 relay.
参考[RFC3315]中的定义。具体而言，“客户机”指实现DHCPv6协议的客户机功能的任何设备，例如终端用户主机、CPE（客户场所设备）或其他路由器。除非另有明确说明，“服务器”是DHCPv6服务器。“继电器”是DHCPv6继电器。
Binding (or client binding): a group of server data records containing the information the server has about the addresses in an IA (Identity Association, see Section 10 of [RFC3315]) or configuration information explicitly assigned to the client. Configuration information that has been returned to a client through a policy -- for example, the information returned to all clients on the same link -- does not require a binding.
绑定（或客户端绑定）：一组服务器数据记录，其中包含服务器关于IA（标识关联，请参见[RFC3315]第10节）中地址的信息或显式分配给客户端的配置信息。通过策略返回给客户端的配置信息（例如，返回给同一链接上所有客户端的信息）不需要绑定。
DNS Update: the capability to update a DNS server's name database using the on-the-wire protocol defined in [RFC2136]. Clients and servers can negotiate the scope of such updates as defined in [RFC4704].
DNS更新：使用[RFC2136]中定义的在线协议更新DNS服务器名称数据库的能力。客户机和服务器可以协商[RFC4704]中定义的此类更新的范围。
Failover: the ability of one partner to continue offering services provided by another partner, with minimal or no impact on clients.
故障转移：一个合作伙伴继续提供另一个合作伙伴提供的服务的能力，对客户端的影响最小或没有影响。
FQDN: a fully qualified domain name. A fully qualified domain name generally is a host name with at least one domain label under the top-level domain. For example, "dhcp.example.org" is a fully qualified domain name.
FQDN：完全限定的域名。完全限定域名通常是在顶级域下至少有一个域标签的主机名。例如，“dhcp.example.org”是一个完全限定的域名。
High Availability: a desired property of DHCPv6 servers to continue providing services despite experiencing unwanted events such as server crashes, link failures, or network partitions.
高可用性：DHCPv6服务器的一个理想属性，它可以在遇到服务器崩溃、链路故障或网络分区等意外事件时继续提供服务。
Load Balancing: the ability for two or more servers to each process some portion of the client request traffic in a conflict-free fashion.
负载平衡：两个或多个服务器以无冲突的方式处理客户端请求流量的一部分的能力。
Lease: an IPv6 address, an IPv6 prefix, or other resource that was assigned ("leased") by a server to a specific client. A lease may include additional information, like associated fully qualified domain name (FQDN) and/or information about associated DNS updates. A client obtains a lease for a specified period of time (valid lifetime).
租约：服务器分配（“租约”）给特定客户端的IPv6地址、IPv6前缀或其他资源。租约可能包括附加信息，如关联的完全限定域名（FQDN）和/或有关关联DNS更新的信息。客户获得指定期限（有效生存期）的租约。
Partner: A "partner", for the purpose of this document, refers to a failover server, typically the other failover server in a failover relationship.
合作伙伴：在本文档中，“合作伙伴”是指故障转移服务器，通常是故障转移关系中的其他故障转移服务器。
Stable Storage: each DHCP server is required to keep its lease database in some form of storage (known as "stable storage") that will be consistent throughout reboots, crashes, and power failures.
稳定存储：每个DHCP服务器都需要将其租约数据库保存在某种形式的存储中（称为“稳定存储”），以便在重新启动、崩溃和电源故障期间保持一致。
Partner Failure: A power outage, unexpected shutdown, crash, or other type of failure that renders a partner unable to continue its operation.
合作伙伴故障：导致合作伙伴无法继续运行的断电、意外关机、崩溃或其他类型的故障。
In order to fit within the IETF process effectively and efficiently, the standardization effort for DHCPv6 failover is expected to proceed with the creation of documents of increasing specificity.
为了有效地适应IETF流程，DHCPv6故障切换的标准化工作预计将继续进行，创建越来越具体的文档。
Requirements document: It begins with this document specifying the requirements for DHCPv6 failover.
需求文档：该文档首先指定DHCPv6故障切换的需求。
Design document: A later document is expected to address the design of the DHCPv6 failover protocol.
设计文档：稍后的文档将介绍DHCPv6故障切换协议的设计。
Protocol document: If sufficient interest exists, a later document is expected to address the protocol details required to implement the DHCPv6 failover protocol itself.
协议文档：如果有足够的兴趣，则稍后的文档将介绍实现DHCPv6故障切换协议本身所需的协议详细信息。
The goal of this partitioning is, in part, to ease the validation, review, and approval of the DHCPv6 failover protocol by presenting it in comprehensible parts to the larger community.
此分区的目标部分是通过将DHCPv6故障切换协议以可理解的部分呈现给更大的社区，从而简化DHCPv6故障切换协议的验证、审查和批准。
Additional documents describing extensions may also be defined.
还可以定义描述扩展的其他文档。
DHCPv6 failover requirements are presented in Section 7.
第7节介绍了DHCPv6故障切换要求。
There are many scenarios in which a failover capability would be useful. However, there are often much simpler approaches that will meet the required goals. This section documents examples where failover is not really needed.
在许多情况下，故障切换功能都很有用。然而，通常有更简单的方法可以实现所需的目标。本节介绍了实际上不需要故障切换的示例。
There are cases when IPv6 addresses are used only for a short time, but there is a need to have high degree of confidence that those addresses will be served. A notable example is PXE (Preboot eXecution Environment) [RFC5970]. This is a mechanism for obtaining configuration early in the process of bootstrapping over the network.
在某些情况下，IPv6地址只在短时间内使用，但需要对这些地址的服务具有高度的信心。一个显著的例子是PXE（预引导执行环境）[RFC5970]。这是一种在网络引导过程的早期获取配置的机制。
The PXE BIOS acquires an address in order to load the operating system image and continue booting. Address and possibly other configuration parameters are used during the boot process and are discarded thereafter. Any lack of available DHCPv6 service at this time will prevent such devices from booting.
PXE BIOS获取一个地址以加载操作系统映像并继续引导。在引导过程中使用地址和可能的其他配置参数，并在此后丢弃。此时缺少可用的DHCPv6服务将阻止此类设备启动。
Instead of deploying failover, it is better to use the much simpler preference mechanism, defined in [RFC3315]. For example, consider two or more servers with each having a distinct preference set (e.g., 10 and 20). Both will answer a client's request. The client should choose the one with the larger preference value. In case of failure of the most preferred server, the next server will keep responding to clients' queries. This approach is simple to deploy but does not offer lease stability, i.e., in case of server failure, clients' addresses and prefixes will change.
与其部署故障切换，不如使用[RFC3315]中定义的更简单的首选项机制。例如，考虑两个或多个服务器，每个服务器具有不同的偏好集（例如，10和20）。两者都将响应客户的请求。客户应选择偏好值较大的一个。如果最首选的服务器出现故障，下一个服务器将继续响应客户端的查询。此方法易于部署，但不提供租约稳定性，即，在服务器出现故障时，客户端的地址和前缀将发生变化。
In some cases, the desire to deploy failover is motivated by high availability, i.e., to continue providing services despite server failure. If there are no additional requirements, that goal may be fulfilled with simply deploying two or more independent servers on the same link.
在某些情况下，部署故障切换的动机是高可用性，即即使服务器出现故障也要继续提供服务。如果没有额外的需求，只需在同一链路上部署两个或多个独立的服务器就可以实现这一目标。
There are several well-documented approaches showing how such a deployment could work. They are discussed in detail in [RFC6853]. Each of those approaches is simpler to deploy and maintain than full failover.
有几种记录良好的方法可以说明这种部署是如何工作的。[RFC6853]中对其进行了详细讨论。这些方法中的每一种都比完全故障切换更易于部署和维护。
Some servers may allow their lease database to be stored in external databases. Another possible alternative to failover is to configure two servers to connect to the same distributed database.
某些服务器可能允许将其租约数据库存储在外部数据库中。故障转移的另一种可能的替代方法是配置两台服务器以连接到同一个分布式数据库。
Care should be taken to understand how inconsistencies are solved in such database backends and how such conflict resolutions affect DHCPv6 server operation.
应注意了解如何解决此类数据库后端中的不一致性，以及此类冲突解决方案如何影响DHCPv6服务器操作。
It is also essential to use only a database that provides equivalent reliability and failover capability. Otherwise, the single point of failure is only moved to a different location (database rather than DHCPv6 server). Such a configuration does not improve redundancy but significantly complicates deployment.
还必须只使用提供同等可靠性和故障切换能力的数据库。否则，单点故障只会移动到其他位置（数据库而不是DHCPv6服务器）。这种配置不会改善冗余，但会使部署大大复杂化。
A common misconception regarding database-based redundancy is the assumption that a conflict resolution after recovering from a network partition is not necessary. To explain that fallacy, let's consider an example where there is a very small pool with only one address. There are two servers, each connected to a co-located database node (i.e., running on the same hardware). Network partition occurs. Each server is operating but has lost connection to its partner. Two clients request an address, one from each server. Each server consults its database and discovers that only one address is
关于基于数据库的冗余的一个常见误解是，假设从网络分区恢复后不需要冲突解决。为了解释谬误，让我们考虑一个只有一个地址的非常小的池的例子。有两个服务器，每个服务器连接到一个位于同一位置的数据库节点（即，运行在同一硬件上）。发生网络分区。每台服务器都在运行，但与伙伴的连接已断开。两个客户端请求一个地址，每个服务器一个。每台服务器查阅其数据库，发现只有一个地址是可用的
available, so it is assigned to the client. Unfortunately, each server assigned the same address to a different client. Making the scenario more realistic (millions of addresses rather than one) just decreased failure probability, but it did not eliminate the underlying issue.
可用，因此将其分配给客户端。不幸的是，每台服务器都为不同的客户端分配了相同的地址。使场景更现实（数百万个地址而不是一个地址）只是降低了故障概率，但并没有消除根本问题。
Any solution that involves a distributed database implementation of DHCPv6 failover must take into account the requirements for security. See Section 8 for additional information.
任何涉及DHCPv6故障切换的分布式数据库实现的解决方案都必须考虑安全性要求。更多信息请参见第8节。
Sometimes the desire to deploy more than one server is based on the assumption that they will share the client traffic. Administrators that are interested in such a capability are advised to deploy a load-balancing mechanism, defined in [LOAD-BALANCING].
有时，部署多台服务器的愿望是基于这样一种假设，即它们将共享客户端流量。建议对此类功能感兴趣的管理员部署[负载平衡]中定义的负载平衡机制。
The following sections provide several examples of deployment scenarios and use cases that may be associated with capabilities commonly referred to as "failover". These scenarios may be in or out of scope for the DHCPv6 failover protocol to which this document's requirements apply; they are enumerated here to provide a common basis for discussion.
以下各节提供了几个可能与通常称为“故障切换”的功能相关联的部署场景和用例示例。这些场景可能在本文档要求适用的DHCPv6故障切换协议的范围之内或之外；这里列举它们是为了提供讨论的共同基础。
In the simplest case, there are two partners that are connected to the same network. Only one of the partners ("primary") provides services to clients. In case of its failure, the second partner ("secondary") continues handling services previously handled by the first partner. As both servers are connected to the same network, a partner that fails to communicate with its partner while also receiving requests from clients may assume with high probability that its partner is down and the network is functional. This assumption may affect its operation.
在最简单的情况下，有两个伙伴连接到同一网络。只有一个合作伙伴（“主要”）向客户提供服务。如果失败，第二合作伙伴（“第二合作伙伴”）将继续处理之前由第一合作伙伴处理的服务。由于两台服务器都连接到同一个网络，因此在接收客户端请求时未能与其合作伙伴通信的合作伙伴很有可能认为其合作伙伴已停机且网络正常工作。这一假设可能会影响其运作。
Servers may be physically located in separate locations. A common example of such a topology is where a service provider has at least a regional high performance network between geographically distributed data centers. In such a scenario, one server is located in one data center, and its failover partner is located in another remote data center. In this scenario, when one partner finds that it cannot communicate with the other partner, it does not necessarily mean that the other partner is down.
服务器可能位于不同的物理位置。这种拓扑结构的一个常见示例是，服务提供商在地理上分布的数据中心之间至少有一个区域高性能网络。在这种情况下，一台服务器位于一个数据中心，其故障切换伙伴位于另一个远程数据中心。在这种情况下，当一个合作伙伴发现无法与另一个合作伙伴通信时，并不一定意味着另一个合作伙伴停机。
A desire to have more than one server in a network may also be created by the desire to have incoming traffic be handled by several servers. This decreases the load each server must endure when all servers are operational. Although such a capability does not, strictly, require failover -- it is clear that failover makes such an architecture more straightforward.
一个网络中有多个服务器的愿望也可能是由多个服务器处理传入流量的愿望造成的。这降低了所有服务器运行时每个服务器必须承受的负载。尽管严格来说，这种功能不需要故障切换，但很明显，故障切换使这种体系结构更加简单。
Note that in a load-balancing situation that includes failover, each individual server must be able to handle the full load normally handled by both servers working together, or there is not a true increase in availability.
请注意，在包括故障切换的负载平衡情况下，每个服务器必须能够处理通常由两台服务器一起工作处理的全部负载，否则可用性不会真正提高。
A failover relationship for a specific network is provided by two failover partners. Those partners communicate with each other and back up all pools. This scenario is sometimes referred to as the 1-to-1 model and is considered relatively simple. In larger networks, one server may be participating in several failover relationships, i.e., it provides failover for several address or prefix pools, each served by separate partners. Such a scenario can be referred to as m-to-1. The most complex scenario, m-to-n, assumes that each partner participates in multiple failover relationships.
特定网络的故障切换关系由两个故障切换伙伴提供。这些合作伙伴相互通信并备份所有池。这种情况有时被称为1对1模型，被认为是相对简单的。在较大的网络中，一台服务器可能参与多个故障切换关系，即，它为多个地址或前缀池提供故障切换，每个地址或前缀池由单独的合作伙伴提供服务。这种情况可以称为m-to-1。最复杂的场景m-to-n假设每个合作伙伴参与多个故障切换关系。
Due to the extensive IPv6 address space, it is possible to provide semi-redundant service by splitting the available pool of addressees into two or more non-overlapping pools, with each server handling its own smaller pool. Several versions of such a scenario are discussed in [RFC6853].
由于IPv6地址空间很大，可以通过将可用的收件人池拆分为两个或多个非重叠池来提供半冗余服务，每个服务器处理自己的较小池。[RFC6853]中讨论了此类场景的几个版本。
Certain nodes may maintain long-lived connections. Since the IPv6 address space is large, techniques exist (e.g., [RFC6853]) that use the easy availability of IPv6 addresses in order to provide increased DHCPv6 availability. However, these approaches do not generally provide for stable IPv6 addresses for DHCPv6 clients should the server with which the client is interacting become unavailable.
某些节点可能会保持长期的连接。由于IPv6地址空间很大，因此存在一些技术（例如，[RFC6853]），这些技术利用IPv6地址的易用性来提供更高的DHCPv6可用性。但是，如果与DHCPv6客户端交互的服务器不可用，这些方法通常不会为DHCPv6客户端提供稳定的IPv6地址。
The obvious benefit of stable addresses is the ability to update DNS infrequently. While DNS can be updated every time an IPv6 address changes, it introduces delays, and (depending on DNS configuration) old entries may be cached for prolonged periods of time.
稳定地址的明显好处是能够不频繁地更新DNS。虽然每次IPv6地址更改时都可以更新DNS，但它会引入延迟，并且（取决于DNS配置）旧条目可能会被缓存较长时间。
The other benefit of having a stable address is that many monitoring solutions provide statistics on a per-IP basis, so IP changes make measuring characteristics of a given box more difficult.
拥有一个稳定的地址的另一个好处是，许多监控解决方案提供基于每个IP的统计信息，因此IP更改使得测量给定框的特性变得更加困难。
There is a scenario where the DHCPv6 server may be configured to serve clients on one network adapter and communicate with a partner server (server-to-server traffic) on a different network adapter. In this scenario, if the server loses connectivity on the network adapter used to communicate with the clients because of network adapter (hardware) failure, there is no intimation of the loss of service to the partner in the DHCPv6 failover protocol. Since the servers are able to communicate with each other, the partner remains ignorant of the loss of service to clients.
在一种情况下，DHCPv6服务器可以配置为在一个网络适配器上为客户端提供服务，并与另一个网络适配器上的伙伴服务器（服务器到服务器的通信量）通信。在这种情况下，如果服务器由于网络适配器（硬件）故障而失去用于与客户端通信的网络适配器上的连接，则DHCPv6故障切换协议中不会向合作伙伴通知服务丢失。由于服务器能够相互通信，合作伙伴仍然不知道客户端的服务丢失。
This section describes important issues that will affect any DHCPv6 failover protocol. This section is not intended to define implementation details but rather describes high-level concepts and issues that are important to DHCPv6 failover. These issues form a basis for later documents that will deal with the solutions to these issues.
本节介绍将影响任何DHCPv6故障切换协议的重要问题。本节不打算定义实现细节，而是描述对DHCPv6故障切换非常重要的高级概念和问题。这些问题构成了以后处理这些问题的解决方案的文件的基础。
The general failover concept assumes that there are backup servers that can provide service in case of a primary server failure. In theory, there could be more than one backup server that could take up the role if such a need arises. However, having more than two servers introduces a very difficult issue of synchronizing between partners. In the case of just a pair of cooperating servers, the notification and processes can result in only one of two states: fully successful (got response from a partner) and total failure (no response, failure event occurred). Were there more than two partners participating in a relationship, there would be intermediate, inconsistent states where some partners had updated their state and some had not. This would greatly complicate the protocol design and would give little advantage in return. Therefore, an approach that assumes a pair of cooperating servers was chosen.
一般的故障切换概念假定有备份服务器可以在主服务器发生故障时提供服务。从理论上讲，如果出现这种需要，可能会有多个备份服务器承担此角色。但是，拥有两台以上的服务器会带来一个非常困难的问题，即在合作伙伴之间进行同步。在只有一对协作服务器的情况下，通知和进程只能导致两种状态中的一种：完全成功（从合作伙伴获得响应）和完全失败（无响应，发生故障事件）。如果有两个以上的伙伴参与一种关系，就会出现中间的、不一致的状态，其中一些伙伴更新了自己的状态，而一些伙伴没有更新。这将极大地使协议设计复杂化，并不会带来什么好处。因此，选择了一种假设一对协作服务器的方法。
This section documents failure modes. This requirements document does not make any claims whether those two failures are distinguishable by a server.
本节记录了故障模式。本需求文档未声明服务器是否能够区分这两种故障。
Servers may become unresponsive due to a software crash, hardware failure, power outage, or any number of other reasons. The failover partner will detect such an event due to lack of responses from the down partner. In this failure mode, the assumption is that the server is the only equipment that is off-line and all other network equipment is operating normally. In particular, communication between other nodes is not interrupted.
服务器可能会由于软件崩溃、硬件故障、断电或任何其他原因而失去响应。故障切换伙伴将检测到这样的事件，因为故障切换伙伴没有响应。在此故障模式下，假设服务器是唯一离线的设备，并且所有其他网络设备都正常运行。特别是，其他节点之间的通信不会中断。
When working under the assumption that this is the only type of failure that can happen, the server may safely assume that its partner unreachability means that it is down, so other nodes (clients, in particular) are not able to reach it either, and no services are provided.
在假定这是唯一可能发生的故障类型的情况下工作时，服务器可以安全地假定其伙伴不可访问性意味着服务器已关闭，因此其他节点（尤其是客户端）也无法访问它，并且不提供任何服务。
It should be noted that recovery after the failed server is brought back on-line is straightforward, due to the fact that it just needs to download current information from the lease database of the healthy partner and there is no conflict resolution required.
需要注意的是，故障服务器恢复联机后的恢复非常简单，因为它只需要从健康合作伙伴的租约数据库下载当前信息，并且不需要冲突解决。
This is by far the most common failure mode between two failover partners.
这是两个故障切换伙伴之间最常见的故障模式。
When the two servers are located physically close to each other, possibly in the same room, the probability that a failure to communicate between failover partners is due to server failure is increased.
当两台服务器在物理上彼此靠近（可能在同一房间中）时，故障转移伙伴之间通信失败是由于服务器故障造成的概率会增加。
Another possible cause of partner unreachability is a failure in the network that connects the two servers. This may be caused by failure of any kind of network equipment: router, switch, physical cables, or optic fibers. As a result of such a failure, the network is split into two or more disjoint sections (partitions) that are not able to communicate with each other. Such an event is called "network partition". If failover partners are located in different partitions, they won't be able to communicate with each other. Nevertheless, each partner may still be able to serve clients that happen to be part of the same partition.
伙伴无法访问的另一个可能原因是连接两台服务器的网络出现故障。这可能是由任何类型的网络设备故障引起的：路由器、交换机、物理电缆或光纤。由于这种故障，网络被分成两个或多个不相交的部分（分区），这些部分（分区）不能相互通信。这样的事件称为“网络分区”。如果故障转移伙伴位于不同的分区中，它们将无法相互通信。尽管如此，每个合作伙伴仍然可以为恰好属于同一分区的客户机提供服务。
If this failure mode is taken into consideration, a server can't assume that partner unreachability automatically means that its partner is down. They must consider the fact that the partner may continue operating and interacting with a subset of the clients. The
如果将此故障模式考虑在内，服务器就不能假定伙伴不可访问性自动意味着其伙伴已停机。他们必须考虑这样的事实，即合作伙伴可以继续操作和与客户的子集交互。这个
only valid assumption is that the partner also detected the network partition event and follows procedures specified for such a situation.
唯一有效的假设是，合作伙伴还检测到网络分区事件，并遵循针对这种情况指定的过程。
It should be noted that recovery after a partitioned network is rejoined is significantly more complicated than recovery from a server failure event. As both servers may have kept serving clients, they have two separate lease databases, and they need to agree on the state of each lease (or follow any other algorithm to bring their lease databases into agreement).
应该注意的是，重新连接分区网络后的恢复比从服务器故障事件中恢复要复杂得多。由于这两台服务器可能一直在为客户端提供服务，因此它们有两个独立的租约数据库，并且它们需要就每个租约的状态达成一致（或者遵循任何其他算法使它们的租约数据库达成一致）。
This failure mode is more likely (though still rare) in the situation where two servers are in physically distant locations with multiple network elements between them. This is the case in geographically distributed failover (see Section 4.2).
这种故障模式在两台服务器位于物理距离较远的位置且它们之间有多个网元的情况下更可能出现（尽管仍然很少见）。地理分布故障切换就是这种情况（请参见第4.2节）。
Partners must exchange information about changes made to the lease database. There are at least two types of synchronization methods that may be used (see Sections 5.2.1 and 5.2.2). These concepts are related to distributed databases, so some familiarity with distributed database technology is useful to better understand this topic.
合作伙伴必须交换有关对租赁数据库所做更改的信息。至少可以使用两种类型的同步方法（见第5.2.1节和第5.2.2节）。这些概念与分布式数据库相关，因此熟悉分布式数据库技术有助于更好地理解此主题。
When a server receives a REQUEST message from a client, it consults its lease database and assigns requested addresses and/or prefixes. To make sure that its partner maintains a consistent database, it then sends information about a new or just updated lease to the partner and waits for the partner's response. After the response from its partner is received, the REPLY message is transmitted to the client.
当服务器接收到来自客户端的请求消息时，它会查阅其租约数据库并分配请求的地址和/或前缀。为了确保其合作伙伴维护一个一致的数据库，它然后向合作伙伴发送关于新租约或刚刚更新的租约的信息，并等待合作伙伴的响应。在接收到来自其伙伴的响应后，应答消息被传输到客户端。
This approach has the benefit of having a completely consistent lease database between partners at all times. Unfortunately, there is typically a significant performance penalty for this approach as each response sent to a client is delayed by the total sum of the delays caused by two transmissions between partners and the processing by the second partner. The second partner is expected to update its own copy of the lease database in permanent storage, so this delay is not negligible, even in fast networks.
这种方法的好处是在合作伙伴之间始终拥有完全一致的租赁数据库。不幸的是，这种方法通常会造成严重的性能损失，因为发送给客户机的每个响应都会延迟由合作伙伴之间的两次传输和第二个合作伙伴的处理引起的延迟的总和。第二个合作伙伴需要在永久存储中更新自己的租约数据库副本，因此即使在快速网络中，这种延迟也不可忽略。
Due to the advent of fast SSD (solid state disk) and battery-backed RAM (random access memory) disk technology, this write performance penalty can be limited to some degree.
由于快速SSD（固态磁盘）和电池备份RAM（随机存取存储器）磁盘技术的出现，这种写性能损失可以在一定程度上得到限制。
Another approach to synchronizing the lease databases is to transmit the REPLY message to the client before completing the update to the partner. The server sends the REPLY to the client immediately after assigning appropriate addresses and/or prefixes and initiates the partner update at a later time, depending on the algorithm chosen. Another variation of this approach is to initiate transmission to the partner but not wait for its response before sending the REPLY to the client.
同步租约数据库的另一种方法是在完成对合作伙伴的更新之前将回复消息发送给客户端。服务器在分配适当的地址和/或前缀后立即向客户机发送回复，并根据所选的算法在稍后启动合作伙伴更新。这种方法的另一个变体是启动到伙伴的传输，但在将应答发送到客户端之前不等待其响应。
This approach has the benefit of a minimal impact on server response times; it is thus much better from a performance perspective. However, it makes the lease databases loosely synchronized between partners. This makes the synchronization more complex (particularly the re-integration after a network partition event), as there may be cases where one client has been given a lease on an address or prefix of which the partner is not aware (e.g., if the server crashes after sending the REPLY to the client but before sending update information to its partner).
这种方法的优点是对服务器响应时间的影响最小；因此，从性能角度来看，它要好得多。但是，它使租赁数据库在合作伙伴之间松散地同步。这使得同步更加复杂（特别是在网络分区事件之后的重新集成），因为可能存在这样的情况，即一个客户机获得了一个伙伴不知道的地址或前缀的租约（例如，如果服务器在向客户端发送回复后但在向其合作伙伴发送更新信息之前崩溃）。
There are significant similarities between existing DHCPv4 and envisaged DHCPv6 failovers. In particular, both serve IP addresses to clients, require maintaining consistent databases among partners, need to perform consistent DNS updates, must be able take over bindings offered by a failed partner, and must be able to resume operation after the partner is recovered. DNS conflict resolution works on the same principles in both DHCPv4 and DHCPv6.
现有DHCPv4和设想的DHCPv6故障切换之间存在显著的相似性。特别是，两者都为客户端提供IP地址，需要在合作伙伴之间维护一致的数据库，需要执行一致的DNS更新，必须能够接管故障合作伙伴提供的绑定，并且必须能够在合作伙伴恢复后恢复操作。DNS冲突解决在DHCPv4和DHCPv6中的工作原理相同。
Nevertheless, there are significant differences. IPv6 introduced prefix delegation [RFC3633], which is a crucial element of the DHCPv6 protocol. IPv6 also introduced the concept of deprecated addresses with separate preferred and valid lifetimes, both configured via DHCPv6. Negative response (NACK) in DHCPv4 has been replaced with the ability in DHCPv6 to provide a corrected response in a REPLY message, which differs from a REQUEST.
尽管如此，也存在显著差异。IPv6引入了前缀委派[RFC3633]，这是DHCPv6协议的一个关键元素。IPv6还引入了不推荐使用的地址的概念，这些地址具有单独的首选和有效生存期，两者都是通过DHCPv6配置的。DHCPv4中的否定响应（NACK）已被DHCPv6中的功能所取代，DHCPv6能够在回复消息中提供更正的响应，这与请求不同。
Also, the typical large address space (close to 2^64 addresses on /64 prefixes expected to be available on most networks) may make managing address assignment significantly different from DHCPv4 failover. In DHCPv4, it was not possible to use a hash or calculated technique to divide the significantly more limited address space, and therefore, much of the protocol that deals with pool balancing and rebalancing might not be necessary and can be done mathematically. Also, because of the much lower degree of contention for IP addresses, the DHCPv6
此外，典型的大地址空间（在大多数网络上预期可用的/64前缀上接近2^64个地址）可能会使管理地址分配与DHCPv4故障切换明显不同。在DHCPv4中，不可能使用散列或计算技术来划分明显更有限的地址空间，因此，处理池平衡和再平衡的大部分协议可能没有必要，可以通过数学方法完成。此外，由于对IP地址的争用程度要低得多，DHCPv6
failover protocol does not need to be tuned to support rapid reclamation of IPv6 addresses following the loss of a failover peer's database.
故障转移协议不需要进行调优，以支持在故障转移对等方的数据库丢失后快速回收IPv6地址。
However, DHCPv6 prefix delegation is similar to IPv4 addressing in terms of the number of available leases, and therefore, techniques for pool balancing and rebalancing and more rapid reclamation of prefixes allocated by a failed peer will be needed.
然而，就可用租约的数量而言，DHCPv6前缀委派与IPv4寻址类似，因此需要池平衡和再平衡技术，以及更快速地回收故障对等方分配的前缀。
This section summarizes the requirements for DHCPv6 failover.
本节总结了DHCPv6故障切换的要求。
Certain capabilities may be useful in some, but not all, scenarios. Such additional features will be considered optional parts of failover and will be defined in separate documents. As such, this document can be considered an attempt to define requirements for the DHCPv6 failover "core" protocol.
某些功能在某些（但不是全部）场景中可能有用。这些附加功能将被视为故障切换的可选部分，并将在单独的文档中定义。因此，本文档可被视为试图定义DHCPv6故障切换“核心”协议的要求。
The core of the DHCPv6 failover protocol is expected to provide the following properties:
DHCPv6故障切换协议的核心预计将提供以下属性：
1. The number of supported partners must be exactly two, i.e., there are at most two servers that are aware of a specific lease.
1. 受支持的合作伙伴的数量必须正好是两个，即最多有两个服务器知道特定租约。
2. For each prefix or address pool, a server must not participate in more than one failover relationship.
2. 对于每个前缀或地址池，服务器不得参与多个故障转移关系。
3. The defined protocol must support the m-to-1 model (i.e., one server may form more than one relationship), but an implementation may choose to implement only the 1-to-1 model (i.e., everything from one server is backed on another).
3. 定义的协议必须支持m-to-1模型（即，一台服务器可以形成多个关系），但实现可以选择只实现1-to-1模型（即，一台服务器的所有内容都支持另一台服务器）。
4. One partner must be able to continue serving leases offered by the other partner. This property is also sometimes called "lease stability". The failure of either failover partner should have minimal or no impact on client connectivity. In particular, it must not force the client to change addresses and/or change prefixes delegated to it. Lease stability has the aim of avoiding disturbance to long-lived connections.
4. 一个合伙人必须能够继续履行另一个合伙人提供的租约。该物业有时也称为“租赁稳定性”。任一故障转移伙伴的故障对客户端连接的影响应最小或没有影响。特别是，它不能强制客户机更改地址和/或更改委托给它的前缀。租赁稳定性的目的是避免对长寿命连接的干扰。
5. Prefix delegation must be supported.
5. 必须支持前缀委派。
6. Use of the failover protocol must not introduce significant performance impact on server response times. Therefore, synchronization between partners must be done using some form of lazy updates (see Section 5.2.2).
6. 故障转移协议的使用不得对服务器响应时间产生显著的性能影响。因此，必须使用某种形式的延迟更新来完成合作伙伴之间的同步（参见第5.2.2节）。
7. The pair of failover servers must be able to recover from a server down failure (see Section 5.1.1).
7. 这对故障转移服务器必须能够从服务器停机故障中恢复（请参阅第5.1.1节）。
8. The pair of failover servers must be able to recover from a network partition event (see Section 5.1.2).
8. 这对故障转移服务器必须能够从网络分区事件中恢复（请参阅第5.1.2节）。
9. The design must allow secure communication between the failover partners.
9. 该设计必须允许故障切换伙伴之间的安全通信。
10. The definition of extensions to this core protocol should be allowed, when possible.
10. 在可能的情况下，应允许定义此核心协议的扩展。
Depending on the specific nature of the failure, the recovery procedures mentioned in points 7 and 8 may require manual intervention.
根据故障的具体性质，第7点和第8点中提到的恢复程序可能需要手动干预。
High availability is a property of the protocol that allows clients to receive DHCPv6 services despite the failure of individual DHCPv6 servers. In particular, it means the server that takes over providing service to clients from its failed partner will continue serving the same addresses and/or prefixes. This property is also called "lease stability".
高可用性是协议的一个属性，它允许客户端在单个DHCPv6服务器出现故障的情况下接收DHCPv6服务。特别是，这意味着从失败的合作伙伴处接管向客户端提供服务的服务器将继续提供相同的地址和/或前缀。该物业也称为“租赁稳定性”。
Although progress on a standardized interoperable DHCPv4 failover protocol has stalled, vendor-specific DHCPv4 failover protocols have been deployed that meet these requirements to a large extent. Accordingly, it would be appropriate to take into account the likely coexistence of DHCPv4 and DHCPv6 failover solutions. In particular, certain features that are common to both IPv4 and IPv6 implementations, such as the DNS Update mechanism, should be taken into consideration to ensure compatible operation.
尽管标准化的可互操作DHCPv4故障切换协议的进展已经停滞，但已经部署了特定于供应商的DHCPv4故障切换协议，在很大程度上满足了这些要求。因此，考虑DHCPv4和DHCPv6故障切换解决方案可能共存是合适的。特别是，应考虑IPv4和IPv6实现所共有的某些功能，如DNS更新机制，以确保兼容操作。
The following features are explicitly out of scope.
以下功能明显超出范围。
1. Load Balancing - This capability is considered an extension and may be defined in a separate document. It must not be part of the core protocol but rather defined as an extension. The primary reason for this the desire to limit the complexity of the core protocol. See [LOAD-BALANCING].
1. 负载平衡-此功能被视为一个扩展，可以在单独的文档中定义。它不能是核心协议的一部分，而是定义为一个扩展。其主要原因是希望限制核心协议的复杂性。请参阅[负载平衡]。
2. Configuration synchronization - Two failover partners are expected to maintain the same configuration. Mismatched configuration between partners is a frequent problem in failover solutions. Unfortunately, that is an open-ended problem, since different servers have very different configuration data models.
2. 配置同步-两个故障切换伙伴应保持相同的配置。合作伙伴之间的配置不匹配是故障切换解决方案中经常出现的问题。不幸的是，这是一个开放的问题，因为不同的服务器具有非常不同的配置数据模型。
3. m-to-n model (see Section 4.4).
3. m-to-n模型（见第4.4节）。
4. Servers participating in multiple failover relationships for any given prefix or address pool.
4. 参与任意给定前缀或地址池的多个故障转移关系的服务器。
The design must provide a mechanism whereby each peer in a failover relationship can identify the other peer, authenticate that identification, and validate that the identified peer is the one with which communication is intended. This mechanism should also optionally provide support for confidentiality.
设计必须提供一种机制，使故障转移关系中的每个对等方都可以识别另一个对等方，验证该标识，并验证所识别的对等方是否是预期通信的对等方。该机制还可以选择性地提供保密性支持。
The protocol specification, when it is written, should provide operational guidelines in the case of authentication mechanisms that require access to network servers that have the potential to be unreachable (e.g., what to do if a partner is reachable but the remote Certificate Authority is unreachable due to a network partition event).
在编写协议规范时，应在需要访问可能无法访问的网络服务器的身份验证机制的情况下提供操作指南（例如，如果可以访问合作伙伴，但由于网络分区事件无法访问远程证书颁发机构，该怎么办）。
The security considerations for the design itself will be discussed in the design document.
设计文件中将讨论设计本身的安全注意事项。
This document extensively uses concepts, definitions and other parts of [DHCPV4-FAILOVER]. Thanks to Bernie Volz and Shawn Routhier for their frequent reviews and substantial contributions. The authors would also like to thank Qin Wu, Jean-Francois Tremblay, Frank Sweetser, Jiang Sheng, Yu Fu, Greg Rabil, Vithalprasad Gaitonde, Krzysztof Nowicki, Steinar Haug, Elwyn Davies, Ted Lemon, Benoit Claise, Stephen Farrell, Michal Hoeft, and Krzysztof Gierlowski for their comments and feedback.
本文档广泛使用[DHCPV4-FAILOVER]的概念、定义和其他部分。感谢Bernie Volz和Shawn Routhier的频繁评论和大量贡献。作者还要感谢秦武、让·弗朗索瓦·特雷姆布雷、弗兰克·斯威瑟、姜生、余福、格雷格·拉比尔、维塔普拉萨德·盖通德、克尔兹托夫·诺维斯基、施泰纳·豪格、埃尔文·戴维斯、特德·莱蒙、贝诺伊特·克莱斯、斯蒂芬·法雷尔、迈克尔·霍夫特和克尔兹托夫·吉尔洛夫斯基的评论和反馈。
This work has been partially supported by the Department of Computer Communications (a division of Gdansk University of Technology) and the National Centre for Research and Development (Poland) under the European Regional Development Fund, Grant No. POIG.01.01.02-00-045 / 09-00 (Future Internet Engineering Project).
这项工作部分得到了计算机通信部（格但斯克技术大学的一个部门）和国家研究开发中心（波兰）在欧洲区域发展基金，批准号Poig.01.01.02-0-04/0900（未来互联网工程项目）下的支持。
[RFC3315] Droms, R., 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.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006.
[RFC4704]Volz，B.，“IPv6（DHCPv6）客户端完全限定域名（FQDN）选项的动态主机配置协议”，RFC 4704，2006年10月。
[DHCPV4-FAILOVER] Droms, R., Kinnear, K., Stapp, M., Volz, B., Gonczi, S., Rabil, G., Dooley, M., and A. Kapur, "DHCP Failover Protocol", Work in Progress, March 2003.
[DHCPV4-故障转移]Droms，R.，Kinnear，K.，Stapp，M.，Volz，B.，Gonczi，S.，Rabil，G.，Dooley，M.，和A.Kapur，“DHCP故障转移协议”，正在进行中的工作，2003年3月。
[LOAD-BALANCING] Kostur, A., "DHC Load Balancing Algorithm for DHCPv6", Work in Progress, December 2012.
[负载平衡]Kostur，A.，“DHCPv6的DHC负载平衡算法”，正在进行的工作，2012年12月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[RFC2136]Vixie，P.，Thomson，S.，Rekhter，Y.，和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 Options for Network Boot", RFC 5970, September 2010.
[RFC5970]Huth，T.，Freimann，J.，Zimmer，V.，和D.Thaler，“网络引导的DHCPv6选项”，RFC 59702010年9月。
[RFC6853] Brzozowski, J., Tremblay, J., Chen, J., and T. Mrugalski, "DHCPv6 Redundancy Deployment Considerations", BCP 180, RFC 6853, February 2013.
[RFC6853]Brzozowski，J.，Tremblay，J.，Chen，J.，和T.Mrugalski，“DHCPv6冗余部署注意事项”，BCP 180，RFC 6853，2013年2月。
Authors' Addresses
作者地址
Tomek Mrugalski Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA
美国加利福尼亚州红木市Charter Street 950号托梅克·姆鲁加尔斯基互联网系统联合公司，邮编94063
Phone: +1 650 423 1345
EMail: tomasz.mrugalski@gmail.com
Phone: +1 650 423 1345
EMail: tomasz.mrugalski@gmail.com
Kim Kinnear Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, Massachusetts 01719 USA
Kim Kinnear Cisco Systems，Inc.美国马萨诸塞州Boxborough马萨诸塞大道1414号，邮编01719
Phone: +1 (978) 936-0000
EMail: kkinnear@cisco.com
Phone: +1 (978) 936-0000
EMail: kkinnear@cisco.com