Internet Architecture Board (IAB) D. Thaler
Request for Comments: 5902 L. Zhang
Category: Informational G. Lebovitz
ISSN: 2070-1721 July 2010
Internet Architecture Board (IAB) D. Thaler
Request for Comments: 5902 L. Zhang
Category: Informational G. Lebovitz
ISSN: 2070-1721 July 2010
IAB Thoughts on IPv6 Network Address Translation
IPv6网络地址转换的IAB思考
Abstract
摘要
There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs). This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB's thoughts on the current open issues and the solution space.
关于IETF是否应该为IPv6网络地址转换器（NAT）制定标准的话题，最近有很多讨论。本文档阐述了IPv6 NAT提出的体系结构问题、使用IPv6 NAT的优缺点，并提供了IAB对当前开放问题和解决方案空间的想法。
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 Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网体系结构委员会（IAB）的产品，代表IAB认为有价值提供永久记录的信息。IAB批准发布的文件不适用于任何级别的互联网标准；见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/rfc5902.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5902.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. What is the problem? . . . . . . . . . . . . . . . . . . . . . 3
2.1. Avoiding Renumbering . . . . . . . . . . . . . . . . . . . 3
2.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 4
2.3. Homogenous Edge Network Configurations . . . . . . . . . . 4
2.4. Network Obfuscation . . . . . . . . . . . . . . . . . . . 5
2.4.1. Hiding Hosts . . . . . . . . . . . . . . . . . . . . . 5
2.4.2. Topology Hiding . . . . . . . . . . . . . . . . . . . 8
2.4.3. Summary Regarding NAT as a Tool for Network
Obfuscation . . . . . . . . . . . . . . . . . . . . . 8
2.5. Simple Security . . . . . . . . . . . . . . . . . . . . . 9
2.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Architectural Considerations of IPv6 NAT . . . . . . . . . . . 9
4. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IAB Members at the Time of Approval . . . . . . . . . . . . . 13
7. Informative References . . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. What is the problem? . . . . . . . . . . . . . . . . . . . . . 3
2.1. Avoiding Renumbering . . . . . . . . . . . . . . . . . . . 3
2.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 4
2.3. Homogenous Edge Network Configurations . . . . . . . . . . 4
2.4. Network Obfuscation . . . . . . . . . . . . . . . . . . . 5
2.4.1. Hiding Hosts . . . . . . . . . . . . . . . . . . . . . 5
2.4.2. Topology Hiding . . . . . . . . . . . . . . . . . . . 8
2.4.3. Summary Regarding NAT as a Tool for Network
Obfuscation . . . . . . . . . . . . . . . . . . . . . 8
2.5. Simple Security . . . . . . . . . . . . . . . . . . . . . 9
2.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Architectural Considerations of IPv6 NAT . . . . . . . . . . . 9
4. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IAB Members at the Time of Approval . . . . . . . . . . . . . 13
7. Informative References . . . . . . . . . . . . . . . . . . . . 14
In the past, the IAB has published a number of documents relating to Internet transparency and the end-to-end principle, and other IETF documents have also touched on these issues as well. These documents articulate the general principles on which the Internet architecture is based, as well as the core values that the Internet community seeks to protect going forward. Most recently, RFC 4924 [RFC4924] reaffirms these principles and provides a review of the various documents in this area.
在过去，IAB发布了许多与互联网透明度和端到端原则相关的文件，其他IETF文件也涉及这些问题。这些文件阐明了互联网架构所基于的一般原则，以及互联网社区今后寻求保护的核心价值观。最近，RFC 4924[RFC4924]重申了这些原则，并对该领域的各种文件进行了审查。
Facing imminent IPv4 address space exhaustion, recently there have been increased efforts in IPv6 deployment. However, since late 2008 there have also been increased discussions about whether the IETF should standardize network address translation within IPv6. People who are against standardizing IPv6 NAT argue that there is no fundamental need for IPv6 NAT, and that as IPv6 continues to roll out, the Internet should converge towards reinstallation of the end-to-end reachability that has been a key factor in the Internet's success. On the other hand, people who are for IPv6 NAT believe that NAT vendors would provide IPv6 NAT implementations anyway as NAT can be a solution to a number of problems, and that the IETF should avoid repeating the same mistake as with IPv4 NAT, where the lack of protocol standards led to different IPv4 NAT implementations, making NAT traversal difficult.
面对IPv4地址空间即将耗尽的问题，最近在IPv6部署方面加大了力度。然而，自2008年末以来，关于IETF是否应该在IPv6内标准化网络地址转换的讨论也越来越多。反对标准化IPv6 NAT的人认为，IPv6 NAT没有根本的必要，而且随着IPv6的继续推出，互联网应该朝着重新安装端到端可达性的方向发展，而端到端可达性一直是互联网成功的关键因素。另一方面，支持IPv6 NAT的人士认为，NAT供应商无论如何都会提供IPv6 NAT实现，因为NAT可以解决许多问题，IETF应该避免重蹈IPv4 NAT的覆辙，因为在IPv4 NAT中，缺乏协议标准导致了不同的IPv4 NAT实现，使NAT穿越变得困难。
An earlier effort, [RFC4864], provides a discussion of the real or perceived benefits of NAT and suggests alternatives for most of them, with the intent of showing that NAT is not required to get the desired benefits. However, it also identifies several gaps remaining to be filled.
先前的一项研究[RFC4864]讨论了NAT的实际或可感知的好处，并为大多数人提出了替代方案，旨在表明NAT不需要获得预期的好处。然而，它也确定了几个有待填补的空白。
This document provides the IAB's current thoughts on this debate. We believe that the issue at hand must be viewed from an overall architectural standpoint in order to fully assess the pros and cons of IPv6 NAT on the global Internet and its future development.
本文件提供了IAB对这场辩论的当前想法。我们认为，必须从总体架构的角度看待当前的问题，以便全面评估IPv6 NAT在全球互联网上的利弊及其未来发展。
The discussions on the desire for IPv6 NAT can be summarized as follows. Network address translation is viewed as a solution to achieve a number of desired properties for individual networks: avoiding renumbering, facilitating multihoming, making configurations homogenous, hiding internal network details, and providing simple security.
关于IPv6 NAT需求的讨论可以总结如下。网络地址转换被视为一种解决方案，可以为各个网络实现许多期望的属性：避免重新编号、促进多归属、使配置同质化、隐藏内部网络细节以及提供简单的安全性。
As discussed in [RFC4864], Section 2.5, the ability to change service providers with minimal operational difficulty is an important requirement in many networks. However, renumbering is still quite painful today, as discussed in [RFC5887]. Currently it requires reconfiguring devices that deal with IP addresses or prefixes, including DNS servers, DHCP servers, firewalls, IPsec policies, and potentially many other systems such as intrusion detection systems, inventory management systems, patch management systems, etc.
如[RFC4864]第2.5节所述，在许多网络中，以最小的操作难度更换服务提供商的能力是一项重要要求。然而，正如[RFC5887]中所讨论的，重新编号在今天仍然是相当痛苦的。目前，它需要重新配置处理IP地址或前缀的设备，包括DNS服务器、DHCP服务器、防火墙、IPsec策略，以及可能的许多其他系统，如入侵检测系统、资源清册管理系统、补丁管理系统等。
In practice today, renumbering does not seem to be a significant problem in consumer networks, such as home networks, where addresses or prefixes are typically obtained through DHCP and are rarely manually configured in any component. However, in managed networks, renumbering can be a serious problem.
在今天的实践中，在消费网络（如家庭网络）中，重新编号似乎不是一个重大问题，在家庭网络中，地址或前缀通常通过DHCP获得，并且很少在任何组件中手动配置。然而，在托管网络中，重新编号可能是一个严重的问题。
We also note that many, if not most, large enterprise networks avoid the renumbering problem by using provider-independent (PI) IP address blocks. The use of PI addresses is inherent in today's Internet operations. However, in smaller managed networks that cannot get provider-independent IP address blocks, renumbering remains a serious issue. Regional Internet Registries (RIRs) constantly receive requests for PI address blocks; one main reason that they hesitate in assigning PI address blocks to all users is the concern about the PI addresses' impact on the routing system scalability.
我们还注意到，许多（如果不是大多数的话）大型企业网络通过使用独立于提供商（PI）的IP地址块来避免重新编号问题。PI地址的使用是当今互联网运营中固有的。然而，在无法获得独立于提供商的IP地址块的较小的受管网络中，重新编号仍然是一个严重的问题。区域互联网注册中心（RIR）不断收到PI地址块的请求；他们在为所有用户分配PI地址块时犹豫不决的一个主要原因是担心PI地址对路由系统可伸缩性的影响。
Another important requirement in many networks is site multihoming. A multihomed site essentially requires that its IP prefixes be present in the global routing table to achieve the desired reliability in its Internet connectivity as well as load balancing. In today's practice, multihomed sites with PI addresses announce their PI prefixes to the global routing system; multihomed sites with provider-allocated (PA) addresses also announce the PA prefix they obtained from one service provider to the global routing system through another service provider, effectively disabling provider-based prefix aggregation. This practice makes the global routing table scale linearly with the number of multihomed user networks.
许多网络中的另一个重要要求是站点多址。多址站点本质上要求其IP前缀出现在全局路由表中，以实现其Internet连接和负载平衡的所需可靠性。在今天的实践中，具有PI地址的多址站点向全局路由系统宣布其PI前缀；具有提供商分配（PA）地址的多址站点也会通过另一个服务提供商将从一个服务提供商获得的PA前缀通知给全局路由系统，从而有效地禁用基于提供商的前缀聚合。这种做法使全局路由表与多宿用户网络的数量成线性比例。
This issue was identified in [RFC4864], Section 6.4. Unfortunately, no solution except NAT has been deployed today that can insulate the global routing system from the growing number of multihomed sites, where a multihomed site simply assigns multiple IPv4 addresses (one from each of its service providers) to its exit router, which is an IPv4 NAT box. Using address translation to facilitate multihoming support has one unique advantage: there is no impact on the routing system scalability, as the NAT box simply takes one address from each service provider, and the multihomed site does not inject its own routes into the system. Intuitively, it also seems straightforward to roll the same solution into multihoming support in the IPv6 deployment. However, one should keep in mind that this approach brings all the drawbacks of putting a site behind a NAT box, including the loss of reachability to the servers behind the NAT box.
该问题在[RFC4864]第6.4节中确定。不幸的是，除了NAT之外，目前还没有任何解决方案能够将全球路由系统与越来越多的多址站点隔离开来，其中多址站点只需将多个IPv4地址（每个服务提供商一个）分配给其出口路由器，即IPv4 NAT盒。使用地址转换来促进多宿支持有一个独特的优势：对路由系统的可伸缩性没有影响，因为NAT盒只从每个服务提供商获取一个地址，多宿站点不会将自己的路由注入系统。直观地说，在IPv6部署中将相同的解决方案应用到多宿主支持中似乎也很简单。但是，应该记住，这种方法带来了将站点放在NAT箱后面的所有缺点，包括NAT箱后面的服务器无法访问。
It is also important to point out that a multihomed site announcing its own prefix(es) achieves two important benefits that NAT-based multihoming support does not provide. First, end-to-end communications can be preserved in face of connectivity failures of individual service providers, as long as the site remains connected through at least one operational service provider. Second, announcing one's prefixes also gives a multihomed site the ability to perform traffic engineering and load balancing.
同样重要的是要指出，一个多址站点公布自己的前缀（es）可以实现两个基于NAT的多址支持无法提供的重要好处。首先，只要站点通过至少一个运营服务提供商保持连接，就可以在单个服务提供商连接失败时保持端到端通信。其次，公布自己的前缀也让多址站点能够执行流量工程和负载平衡。
Service providers supporting residential customers need to minimize support costs (e.g., help desk calls). Often a key factor in minimizing support costs is ensuring customers have homogenous configurations, including the addressing architecture. Today, when IPv4 NATs are provided by a service provider, all customers get the same address space on their home networks, and hence the home gateway
为住宅客户提供支持的服务提供商需要将支持成本降至最低（例如，服务台电话）。通常，将支持成本降至最低的一个关键因素是确保客户具有同质配置，包括寻址体系结构。如今，当IPv4 NAT由服务提供商提供时，所有客户在其家庭网络上都会获得相同的地址空间，因此也就是家庭网关
always has the same address. From a customer-support perspective, this perhaps represents the most important property of NAT usage today.
总是有相同的地址。从客户支持的角度来看，这可能代表了当今NAT使用最重要的特性。
In IPv6, link-local addresses can be used to ensure that all home gateways have the same address, and to provide homogenous addresses to any other devices supported by the service provider. Unlike IPv4, having a globally unique address does not prevent the use of a homogenous address within the subnet. It is only in the case of multi-subnet customers that IPv6 NAT would provide some homogeneity that wouldn't be provided by link-local addresses. For multi-subnet customers (e.g., a customer using a wireless access point behind the service provider router/modem), service providers today might only discuss problems (for IPv4 or IPv6) from computers connected directly to the service provider router.
在IPv6中，链路本地地址可用于确保所有家庭网关具有相同的地址，并向服务提供商支持的任何其他设备提供同质地址。与IPv4不同，具有全局唯一地址不会阻止在子网内使用同质地址。只有在多子网客户的情况下，IPv6 NAT才能提供一些链路本地地址无法提供的同质性。对于多子网客户（例如，使用服务提供商路由器/调制解调器后面的无线接入点的客户），服务提供商今天可能只讨论直接连接到服务提供商路由器的计算机的问题（对于IPv4或IPv6）。
It is currently unknown whether IPv6 link-local addresses provide sufficient homogeneity to minimize help desk calls. If they do not, providers might still desire IPv6 NATs in the residential gateways they provide.
目前还不清楚IPv6链路本地地址是否提供足够的同质性，以最大限度地减少服务台呼叫。如果他们不这样做，提供商可能仍然希望在他们提供的住宅网关中使用IPv6 NAT。
Most network administrators want to hide the details of the computing resources, information infrastructure, and communications networks within their borders. This desire is rooted in the basic security principle that an organization's assets are for its sole use and all information about those assets, their operation, and the methods and tactics of their use are proprietary secrets. Some organizations use their information and communication technologies as a competitive advantage in their industries. It is a generally held belief that measures must be taken to protect those secrets. The first layer of protection of those secrets is preventing access to the secrets or knowledge about the secrets whenever possible. It is understandable why network administrators would want to keep the details about the hosts on their network, as well as the network infrastructure itself, private. They believe that NAT helps achieve this goal.
大多数网络管理员希望隐藏其境内计算资源、信息基础设施和通信网络的详细信息。这种愿望植根于基本的安全原则，即一个组织的资产仅供其使用，有关这些资产的所有信息、其运作以及使用这些资产的方法和战术都是专有秘密。一些组织将其信息和通信技术作为其行业的竞争优势。人们普遍认为必须采取措施保护这些秘密。对这些秘密的第一层保护是尽可能防止接触这些秘密或了解这些秘密。网络管理员希望将其网络上的主机以及网络基础设施本身的详细信息保密是可以理解的。他们相信NAT有助于实现这一目标。
As a specific measure of network obfuscation, network administrators wish to keep secret any and all information about the computer systems residing within their network boundaries. Such computer systems include workstations, laptops, servers, function-specific end-points (e.g., printers, scanners, IP telephones, point-of-sale machines, building door access-control devices), and such. They want to prevent an external entity from counting the number of hosts on the network. They also want to prevent host fingerprinting, i.e.,
作为网络混淆的具体措施，网络管理员希望对其网络边界内的计算机系统的任何和所有信息保密。此类计算机系统包括工作站、笔记本电脑、服务器、特定功能端点（例如打印机、扫描仪、IP电话、销售点机器、楼宇门禁控制设备）等。他们希望防止外部实体计算网络上的主机数量。他们还希望防止主机指纹识别，即。，
gaining information about the constitution, contents, or function of a host. For example, they want to hide the role of a host, as whether it is a user workstation, a finance server, a source code build server, or a printer. A second element of host-fingerprinting prevention is to hide details that could aid an attacker in compromising the host. Such details might include the type of operating system, its version number, any patches it may or may not have, the make and model of the device hardware, any application software packages loaded, those version numbers and patches, and so on. With such information about hosts, an attacker can launch a more focused, targeted attack. Operators want to stop both host counting and host fingerprinting.
获取有关主机的组成、内容或功能的信息。例如，他们希望隐藏主机的角色，例如它是用户工作站、财务服务器、源代码生成服务器还是打印机。防止主机指纹识别的第二个要素是隐藏可能有助于攻击者破坏主机的详细信息。这些详细信息可能包括操作系统的类型、版本号、可能有或没有的任何修补程序、设备硬件的品牌和型号、加载的任何应用软件包、这些版本号和修补程序，等等。有了这些关于主机的信息，攻击者可以发起更具针对性的攻击。操作员希望停止主机计数和主机指纹识别。
Where host counting is a concern, it is worth pointing out some of the challenges in preventing it. [Bellovin] showed how one can successfully count the number of hosts behind a certain type of simple NAT box. More complex NAT deployments, e.g., ones employing Network Address Port Translators (NAPTs) with a pool of public addresses that are randomly bound to internal hosts dynamically upon receipt of any new connection, and do so without persistency across connections from the same host are more successful in preventing host counting. However, the more complex the NAT deployment, the less likely that complex connection types like the Session Initiation Protocol (SIP) [RFC3261] and the Stream Control Transmission Protocol (SCTP) [RFC4960] will be able to successfully traverse the NAT. This observation follows the age-old axiom for networked computer systems: for every unit of security you gain, you give up a unit of convenience, and for every unit of convenience you hope to gain, you must give up a unit of security.
在主机计数是一个问题的地方，值得指出防止主机计数的一些挑战。[Bellovin]展示了如何成功计算某种简单NAT盒背后的主机数量。更复杂的NAT部署，例如，采用网络地址端口转换器（NAPT）的NAT部署，在接收到任何新连接时，将一组公共地址随机动态绑定到内部主机，并且在不保持同一主机连接的情况下这样做，在防止主机计数方面更为成功。然而，NAT部署越复杂，像会话发起协议（SIP）[RFC3261]和流控制传输协议（SCTP）[RFC4960]这样的复杂连接类型成功穿越NAT的可能性就越小。这一观察遵循了网络计算机系统的古老公理：对于你获得的每一个安全单元，你放弃了一个便利单元；对于你希望获得的每一个便利单元，你必须放弃一个安全单元。
If fields such as fragment ID, TCP initial sequence number, or ephemeral port number are chosen in a predictable fashion (e.g., sequentially), then an attacker may correlate packets or connections coming from the same host.
如果以可预测的方式（例如，顺序）选择了片段ID、TCP初始序列号或临时端口号等字段，则攻击者可能会关联来自同一主机的数据包或连接。
To prevent counting hosts by counting addresses, one might be tempted to use a separate IP address for each transport-layer connection. Such an approach introduces other architectural problems, however. Within the host's subnet, various devices including switches, routers, and even the host's own hardware interface often have a limited amount of state available before causing communication that uses a large number of addresses to suffer significant performance problems. In addition, if an attacker can somehow determine an average number of connections per host, the attacker can still estimate the number of hosts based on the number of connections observed. Hence, such an approach can adversely affect legitimate communication at all times, simply to raise the bar for an attacker.
为了防止通过计算地址来计算主机数量，可能会尝试为每个传输层连接使用单独的IP地址。然而，这种方法会带来其他架构问题。在主机的子网中，各种设备（包括交换机、路由器，甚至主机自己的硬件接口）在导致使用大量地址的通信遭受重大性能问题之前，通常具有有限的可用状态。此外，如果攻击者能够以某种方式确定每个主机的平均连接数，则攻击者仍然可以根据观察到的连接数估计主机数。因此，这种方法可能会在任何时候都对合法通信产生不利影响，这只是为了提高攻击者的门槛。
Where host fingerprinting is concerned, even a complex NAT cannot prevent fingerprinting completely. The way that different hosts respond to different requests and sequences of events will indicate consistently the type of a host that it is, its OS, version number, and sometimes applications installed, etc. Products exist that do this for network administrators as a service, as part of a vulnerability assessment.
就主机指纹识别而言，即使是复杂的NAT也不能完全阻止指纹识别。不同主机响应不同请求和事件序列的方式将一致地指示主机的类型、其操作系统、版本号，有时还包括已安装的应用程序等。作为漏洞评估的一部分，现有的产品将网络管理员作为一项服务来执行此操作。
These scanning tools initiate connections of various types across a range of possible IP addresses reachable through that network. They observe what returns, and then send follow-up messages accordingly until they "fingerprint" the host thoroughly. When run as part of a network assessment process, these tools are normally run from the inside of the network, behind the NAT. If such a tool is set outside a network boundary (as part of an external vulnerability assessment or penetration test) along the path of packets, and is passively observing and recording connection exchanges, over time it can fingerprint hosts only if it has a means of determining which externally viewed connections are originating from the same internal host. If the NATing is simple and static, and each host's internal address is always mapped to the same external address and vice versa, the tool has 100% success fingerprinting the host. With the internal hosts mapped to their external IP addresses and fingerprinted, the attacker can launch targeted attacks into those hosts, or reliably attempt to hijack those hosts' connections. If the NAT uses a single external IP, or a pool of dynamically assigned IP addresses for each host, but does so in a deterministic and predictable way, then the operation of fingerprinting is more complex, but quite achievable.
这些扫描工具通过网络可访问的一系列可能的IP地址启动各种类型的连接。他们观察返回的内容，然后相应地发送后续消息，直到完全“识别”主机。当作为网络评估过程的一部分运行时，这些工具通常从网络内部NAT后面运行。如果该工具沿着数据包路径设置在网络边界之外（作为外部漏洞评估或渗透测试的一部分），并且被动地观察和记录连接交换，随着时间的推移，只有当它能够确定哪些外部查看的连接来自同一个内部主机时，它才能对主机进行指纹识别。如果本机是简单静态的，并且每个主机的内部地址始终映射到相同的外部地址，反之亦然，则该工具对主机进行指纹识别的成功率为100%。通过将内部主机映射到其外部IP地址并提取指纹，攻击者可以对这些主机发起有针对性的攻击，或者可靠地尝试劫持这些主机的连接。如果NAT使用单个外部IP或为每个主机动态分配的IP地址池，但以确定性和可预测的方式这样做，则指纹识别的操作更为复杂，但非常容易实现。
If the NAT uses dynamically assigned addresses, with short-term persistency, but no externally learnable determinism, then the problem gets harder for the attacker. The observer may be able to fingerprint a host during the lifetime of a particular IP address mapping, and across connections, but once that IP mapping is terminated, the observer doesn't immediately know which new mapping will be that same host. After much observation and correlation, the attacker could sometimes determine if an observed new connection in flight is from a familiar host. With that information, and a good set of man-in-the-middle attack tools, the attacker could attempt to compromise the host by hijacking a new connection of adequately long duration. If temporal persistency is not deployed on the NAT, then this tactic becomes almost impossible. As the difficulty and cost of the attack increases, the number of attackers attempting to employ it decreases. And certainly the attacker would not be able to initiate a connection toward a host for which the attacker does not know the current IP address binding. So, the attacker is limited to hijacking observed connections thought to be from a familiar host, or to blindly initiating attacks on connections in flight. This is why
如果NAT使用动态分配的地址，具有短期持久性，但没有外部可学习的决定论，那么攻击者的问题就更难解决。观察者可能能够在特定IP地址映射的生命周期内以及跨连接对主机进行指纹识别，但一旦IP映射终止，观察者就无法立即知道哪个新映射将是同一主机。经过多次观察和关联后，攻击者有时可以确定飞行中观察到的新连接是否来自熟悉的主机。有了这些信息，再加上一套好的中间人攻击工具，攻击者可以通过劫持一个持续时间足够长的新连接来试图破坏主机。如果NAT上没有部署时间持久性，那么这种策略几乎是不可能的。随着攻击难度和成本的增加，尝试使用该攻击的攻击者数量减少。当然，如果攻击者不知道当前的IP地址绑定，则攻击者将无法启动与主机的连接。因此，攻击者仅限于劫持被认为来自熟悉主机的观察到的连接，或者盲目地对飞行中的连接发起攻击。这就是为什么
network administrators appreciate complex NATs' ability to deter host counting and fingerprinting, but such deterrence comes at a cost of host reachability.
网络管理员欣赏复杂NAT阻止主机计数和指纹识别的能力，但这种阻止是以主机可达性为代价的。
It is perceived that a network operator may want to hide the details of the network topology, the size of the network, the identities of the internal routers, and the interconnection among the routers. This desire has been discussed in [RFC4864], Sections 4.4 and 6.2.
可以认为，网络运营商可能想要隐藏网络拓扑、网络大小、内部路由器的身份以及路由器之间的互连的细节。[RFC4864]第4.4节和第6.2节讨论了这一要求。
However, the success of topology hiding is dependent upon the complexity, dynamism, and pervasiveness of bindings the NAT employs (all of which were described above). The more complex, the more the topology will be hidden, but the less likely that complex connection types will successfully traverse the NAT barrier. Thus, the trade-off is reachability across applications.
然而，拓扑隐藏的成功取决于NAT使用的绑定的复杂性、动态性和普遍性（所有这些都已在上面描述）。拓扑越复杂，隐藏的拓扑越多，但复杂连接类型成功穿越NAT屏障的可能性越小。因此，取舍是跨应用程序的可达性。
Even if one can hide the actual addresses of internal hosts through address translation, this does not necessarily prove sufficient to hide internal topology. It may be possible to infer some aspects of topological information from passively observing packets. For example, based on packet timing, delay measurements, the Hop Limit field, or other fields in the packet header, one could infer the relative distance between multiple hosts. Once an observed session is believed to match a previously fingerprinted host, that host's distance from the NAT device may be learned, but not its exact location or particular internal subnet.
即使可以通过地址转换隐藏内部主机的实际地址，也不一定足以隐藏内部拓扑。可以从被动观察数据包推断拓扑信息的某些方面。例如，基于分组定时、延迟测量、跳数限制字段或分组报头中的其他字段，可以推断多个主机之间的相对距离。一旦一个观察到的会话被认为与先前的指纹主机匹配，就可以了解该主机与NAT设备的距离，但不能了解其确切位置或特定内部子网。
Host fingerprinting is required in order to do a thorough distance mapping. An attacker might then use message contents to lump certain types of devices into logical clusters, and take educated guesses at attacks. This is not, however, a thorough mapping. Some NATs change the TTL hop counts, much like an application-layer proxy would, while others don't; this is an administrative setting on more advanced NATs. The simpler and more static the NAT, the more possible this is. The more complex and dynamic and non-persistent the NAT bindings, the more difficult.
需要主机指纹才能进行彻底的距离映射。然后，攻击者可能会使用消息内容将某些类型的设备聚集到逻辑集群中，并对攻击进行有根据的猜测。然而，这并不是一个彻底的映射。一些NAT改变TTL跳数，很像应用层代理，而其他NAT则不改变；这是更高级NAT的管理设置。NAT越简单、越静态，这种情况就越可能发生。NAT绑定越复杂、动态和非持久性，就越困难。
The degree of obfuscation a NAT can achieve will be a function of its complexity as measured by:
NAT可以实现的混淆程度是其复杂性的函数，通过以下方式衡量：
o The use of one-to-many NAPT mappings;
o 使用一对多NAPT映射；
o The randomness over time of the mappings from internal to external IP addresses, i.e., non-deterministic mappings from an outsider's perspective;
o 从内部IP地址到外部IP地址的映射随时间的随机性，即，从局外人的角度来看，非确定性映射；
o The lack of persistence of mappings, i.e., the shortness of mapping lifetimes and not using the same mapping repeatedly;
o 缺乏映射的持久性，即映射生命周期短，不重复使用同一映射；
o The use of re-writing in IP header fields such as TTL.
o 在IP头字段（如TTL）中使用重写。
However, deployers be warned: as obfuscation increases, host reachability decreases. Mechanisms such as STUN [RFC5389] and Teredo [RFC4380] fail with the more complex NAT mechanisms.
但是，部署人员需要得到警告：随着混淆的增加，主机可达性降低。STUN[RFC5389]和Teredo[RFC4380]等机制在更复杂的NAT机制中失败。
It is commonly perceived that a NAT box provides one level of protection because external hosts cannot directly initiate communication with hosts behind a NAT. However, one should not confuse NAT boxes with firewalls. As discussed in [RFC4864], Section 2.2, the act of translation does not provide security in itself. The stateful filtering function can provide the same level of protection without requiring a translation function. For further discussion, see [RFC4864], Section 4.2.
通常认为，NAT盒提供一级保护，因为外部主机无法直接启动与NAT后面的主机的通信。但是，不应将NAT盒与防火墙混淆。如[RFC4864]第2.2节所述，翻译行为本身并不提供安全性。有状态过滤功能可以提供相同级别的保护，而不需要转换功能。有关进一步讨论，请参见[RFC4864]，第4.2节。
At present, the primary benefits one may receive from deploying NAT appear to be avoiding renumbering, facilitating multihoming without impacting routing scalability, and making edge consumer network configurations homogenous.
目前，部署NAT的主要好处似乎是避免重新编号，在不影响路由可伸缩性的情况下促进多归属，并使边缘消费者网络配置同质化。
Network obfuscation (host hiding, both counting and fingerprinting prevention, and topology hiding) may well be achieved with more complex NATs, but at the cost of losing some reachability and application success. Again, when it comes to security, this is often the case: to gain security one must give up some measure of convenience.
网络混淆（主机隐藏、计数和指纹预防以及拓扑隐藏）很可能通过更复杂的NAT实现，但代价是失去一些可达性和应用程序成功。同样，在安全问题上，情况往往如此：为了获得安全，必须放弃某种程度的便利。
First, it is important to distinguish between the effects of a NAT box vs. the effects of a firewall. A firewall is intended to prevent unwanted traffic [RFC4948] without impacting wanted traffic, whereas a NAT box also interferes with wanted traffic. In the remainder of this section, the term "reachability" is used with respect to wanted traffic.
首先，区分NAT盒和防火墙的效果是很重要的。防火墙旨在防止不需要的流量[RFC4948]，而不会影响想要的流量，而NAT盒也会干扰想要的流量。在本节的其余部分中，术语“可达性”用于所需流量。
The discussions on IPv6 NAT often refer to the wide deployment of IPv4 NAT, where people have both identified tangible benefits and gained operational experience. However, the discussions so far seem mostly focused on the potential benefits that IPv6 NAT may, or may not, bring. Little attention has been paid to the bigger picture, as we elaborate below.
关于ipv6nat的讨论通常涉及ipv4nat的广泛部署，在这方面，人们既发现了切实的好处，又获得了运营经验。然而，到目前为止的讨论似乎主要集中在IPv6 NAT可能带来或不可能带来的潜在好处上。正如我们在下面详细阐述的那样，人们很少关注全局。
When considering the benefits that IPv6 NAT may bring to a site that deploys it, we must not overlook a bigger question: if one site deploys IPv6 NAT, what is the potential impact it brings to the rest of the Internet that does not do IPv6 NAT? By "the rest of the Internet", we mean the Internet community that develops, deploys, and uses end-to-end applications and protocols and hence is affected by any loss of transparency (see [RFC2993] and [RFC4924] for further discussion). This important question does not seem to have been addressed, or addressed adequately.
在考虑IPv6 NAT可能给部署它的站点带来的好处时，我们不能忽视一个更大的问题：如果一个站点部署了IPv6 NAT，那么它给互联网上其他不使用IPv6 NAT的站点带来的潜在影响是什么？所谓“互联网的其余部分”，我们指的是开发、部署和使用端到端应用程序和协议的互联网社区，因此受到任何透明度损失的影响（进一步讨论请参见[RFC2993]和[RFC4924]）。这一重要问题似乎没有得到解决，也没有得到充分解决。
We believe that the discussions on IPv6 NAT should be put in the context of the overall Internet architecture. The foremost question is not how many benefits one may derive from using IPv6 NAT, but more fundamentally, whether a significant portion of parties on the Internet are willing to deploy IPv6 NAT, and hence whether we want to make IP address translation a permanent building block in the Internet architecture.
我们认为，关于IPv6 NAT的讨论应该放在整个互联网架构的背景下进行。最重要的问题不是使用IPv6 NAT可以带来多少好处，而是更根本的问题是，互联网上是否有很大一部分各方愿意部署IPv6 NAT，因此我们是否希望将IP地址转换作为互联网体系结构中的永久构建块。
One may argue that the answers to the above questions depend on whether we can find adequate solutions to the renumbering, site multihoming, and edge network configuration problems, and whether the solutions provide transparency or not. If transparency is not provided, making NAT a permanent building block in the Internet would represent a fundamental architectural change.
有人可能会说，上述问题的答案取决于我们是否能够找到适当的解决方案来解决重新编号、站点多归属和边缘网络配置问题，以及这些解决方案是否提供了透明度。如果不提供透明度，使NAT成为互联网中的永久构件将代表一个根本性的架构变化。
It is desirable that IPv6 users and applications be able to reach each other directly without having to worry about address translation boxes between the two ends. IPv6 application developers in general should be able to program based on the assumption of end-to-end reachability (of wanted traffic), without having to address the issue of traversing NAT boxes. For example, referrals and multi-party conversations are straightforward with end-to-end addressing, but vastly complicated in the presence of address translation. Similarly, network administrators should be able to run their networks without the added complexity of NATs, which can bring not only the cost of additional boxes, but also increased difficulties in network monitoring and problem debugging.
希望IPv6用户和应用程序能够直接相互联系，而不必担心两端之间的地址转换框。IPv6应用程序开发人员通常应该能够基于端到端可达性（所需流量）的假设进行编程，而不必解决穿越NAT盒的问题。例如，通过端到端寻址，转介和多方对话是简单的，但在地址转换的情况下则非常复杂。类似地，网络管理员应该能够在不增加NAT复杂性的情况下运行其网络，这不仅会带来额外机箱的成本，还会增加网络监控和问题调试的难度。
Given the diversity of the Internet user populations and the diversity in today's operational practice, it is conceivable that some parties may have a strong desire to deploy IPv6 NAT, and the Internet should accommodate different views that lead to different practices (i.e., some using IPv6 NAT, others not).
考虑到互联网用户群体的多样性和当今运营实践的多样性，可以想象，一些方面可能有部署IPv6 NAT的强烈愿望，互联网应该适应导致不同实践的不同观点（即，一些使用IPv6 NAT，另一些不使用）。
If we accept the view that some, but not all, parties want IPv6 NAT, then the real debate should not be on what benefits IPv6 NAT may bring to the parties who deploy it. It is undeniable that network address translation can bring certain benefits to its users. However, the real challenge we should address is how to design IPv6 NAT in such a way that it can hide its impact within some localized scope. If IPv6 NAT design can achieve this goal, then the Internet as a whole can strive for (reinstalling) the end-to-end reachability model.
如果我们接受这样一种观点，即一些（而不是所有）缔约方需要IPv6 NAT，那么真正的争论不应该是IPv6 NAT可能给部署它的缔约方带来什么好处。不可否认，网络地址翻译可以给用户带来一定的好处。然而，我们应该解决的真正挑战是如何设计IPv6 NAT，使其能够在某些本地化范围内隐藏其影响。如果IPv6 NAT设计能够实现这一目标，那么整个互联网可以争取（重新安装）端到端可达性模型。
From an end-to-end perspective, the solution space for renumbering and multihoming can be broadly divided into three classes:
从端到端的角度来看，用于重新编号和多重归宿的解决方案空间可大致分为三类：
1. Endpoints get a stable, globally reachable address: In this class of solutions, end sites use provider-independent addressing and hence endpoints are unaffected by changing service providers. For this to be a complete solution, provider-independent addressing must be available to all managed networks (i.e., all networks that use manual configuration of addresses or prefixes in any type of system). However, in today's practice, assigning provider-independent addresses to all networks, including small ones, raises concerns with the scalability of the global routing system. This is an area of ongoing research and experimentation. In practice, network administrators have also been developing short-term approaches to resolve today's gap between the continued routing table growth and limitations in existing router capacity [NANOG].
1. 端点获得稳定的、全局可访问的地址：在这类解决方案中，终端使用独立于提供商的寻址，因此端点不受服务提供商变化的影响。要使其成为一个完整的解决方案，所有受管网络（即，在任何类型的系统中使用地址或前缀的手动配置的所有网络）都必须提供独立于提供商的寻址。然而，在今天的实践中，为所有网络（包括小型网络）分配独立于提供商的地址会引起对全局路由系统可伸缩性的关注。这是一个正在进行的研究和实验领域。实际上，网络管理员也一直在开发短期方法，以解决当前路由表持续增长与现有路由器容量限制之间的差距[NANOG]。
2. Endpoints get a stable but non-globally-routable address on physical interfaces but a dynamic, globally routable address inside a tunnel: In this class of solutions, hosts use locally-scoped (and hence provider-independent) addresses for communication within the site using their physical interfaces. As a result, managed systems such as routers, DHCP servers, etc., all see stable addresses. Tunneling from the host to some infrastructure device is then used to communicate externally. Tunneling provides the host with globally routable addresses that may change, but address changes are constrained to systems that operate over or beyond the tunnel, including DNS servers and
2. 端点在物理接口上获得稳定但不可全局路由的地址，但在隧道内获得动态、全局路由的地址：在这类解决方案中，主机使用其物理接口在站点内使用本地范围（因此独立于提供商）的地址进行通信。因此，路由器、DHCP服务器等托管系统都可以看到稳定的地址。然后使用从主机到某些基础设施设备的隧道进行外部通信。隧道为主机提供可能更改的全局可路由地址，但地址更改仅限于在隧道上方或之外运行的系统，包括DNS服务器和服务器
applications. These systems, however, are the ones that often can already deal with changes today using mechanisms such as DNS dynamic update. However, if endpoints and the tunnel infrastructure devices are owned by different organizations, then solutions are harder to incrementally deploy due to the incentive and coordination issues involved.
应用。然而，这些系统通常已经可以使用诸如DNS动态更新之类的机制来处理当前的更改。但是，如果端点和隧道基础设施设备由不同的组织拥有，则由于涉及激励和协调问题，解决方案更难增量部署。
3. Endpoints get a stable address that gets translated in the network: In this class of solutions, end sites use non-globally-routable addresses within the site, and translate them to globally routable addresses somewhere in the network. In general, this causes the loss of end-to-end transparency, which is the subject of [RFC4924] and the documents it surveys. If the translation is reversible, and the translation is indeed reversed by the time it reaches the other end of communication, then end-to-end transparency can be provided. However, if the two translators involved are owned by different organizations, then solutions are harder to incrementally deploy due to the incentive and coordination issues involved.
3. 端点获得在网络中转换的稳定地址：在这类解决方案中，终端站点在站点内使用非全局可路由地址，并将其转换为网络中某个位置的全局可路由地址。一般来说，这会导致端到端透明度的丧失，这是[RFC4924]及其调查文件的主题。如果翻译是可逆的，并且当翻译到达通信的另一端时确实是可逆的，那么就可以提供端到端的透明度。但是，如果所涉及的两个翻译人员属于不同的组织，那么由于所涉及的激励和协调问题，解决方案更难逐步部署。
Concerning routing scalability, although there is no immediate danger, routing scalability has been a longtime concern in operational communities, and an effective and deployable solution must be found. We observe that the question at hand is not about whether some parties can run NAT, but rather, whether the Internet as a whole would be willing to rely on NAT to curtail the routing scalability problem, and whether we have investigated all the potential impacts of doing so to understand its cost on the overall architecture. If effective solutions can be deployed in time to allow assigning provider-independent IPv6 addresses to all user communities, the Internet can avoid the complexity and fragility and other unforeseen problems introduced by NAT.
关于路由可伸缩性，虽然没有直接的危险，但路由可伸缩性一直是运营社区长期关注的问题，必须找到一个有效且可部署的解决方案。我们观察到，目前的问题不是某些方面是否可以运行NAT，而是整个互联网是否愿意依赖NAT来减少路由可伸缩性问题，以及我们是否已经调查了这样做的所有潜在影响，以了解其对整体架构的成本。如果能够及时部署有效的解决方案，允许向所有用户社区分配独立于提供商的IPv6地址，那么互联网可以避免NAT带来的复杂性和脆弱性以及其他无法预见的问题。
As [RFC4924] states:
正如[RFC4924]所述：
A network that does not filter or transform the data that it carries may be said to be "transparent" or "oblivious" to the content of packets. Networks that provide oblivious transport enable the deployment of new services without requiring changes to the core. It is this flexibility that is perhaps both the Internet's most essential characteristic as well as one of the most important contributors to its success.
不过滤或转换其承载的数据的网络可以被称为对分组的内容“透明”或“不经意”。提供不经意传输的网络允许部署新服务，而无需更改核心。正是这种灵活性可能是互联网最基本的特征，也是互联网成功的最重要因素之一。
We believe that providing end-to-end transparency, as defined above, is key to the success of the Internet. While some fields of traffic (e.g., Hop Limit) are defined to be mutable, transparency requires
我们认为，如上所述，提供端到端的透明度是互联网成功的关键。虽然某些流量字段（例如跃点限制）定义为可变的，但透明度要求
that fields not defined as such arrive un-transformed. Currently, the source and destination addresses are defined as immutable fields, and are used as such by many protocols and applications.
未定义为未转换的字段。目前，源地址和目标地址被定义为不可变字段，并被许多协议和应用程序使用。
Each of the three classes of solution can be defined in a way that preserves end-to-end transparency.
三类解决方案中的每一类都可以以保持端到端透明度的方式定义。
While we do not consider IPv6 NATs to be desirable, we understand that some deployment of them is likely unless workable solutions to avoiding renumbering, facilitating multihoming without adversely impacting routing scalability, and homogeneity are generally recognized as useful and appropriate.
虽然我们不认为IPv6 NAT是可取的，但是我们理解，除非有可行的解决方案来避免重新编号，便于多个归巢，而不会对路由可扩展性产生不利影响，并且均匀性通常被认为是有用的和适当的，所以它们的部署是可能的。
As such, we strongly encourage the community to consider end-to-end transparency as a requirement when proposing any solution, whether it be based on tunneling or translation or some other technique. Solutions can then be compared based on other aspects such as scalability and ease of deployment.
因此，我们强烈鼓励社区在提出任何解决方案时考虑端到端透明性，无论是基于隧道技术还是翻译或其他技术。然后可以根据其他方面（如可伸缩性和部署的方便性）对解决方案进行比较。
Section 2 discusses potential privacy concerns as part of the Host Counting and Topology Hiding problems.
第2节讨论了作为主机计数和拓扑隐藏问题一部分的潜在隐私问题。
Marcelo Bagnulo Gonzalo Camarillo Stuart Cheshire Vijay Gill Russ Housley John Klensin Olaf Kolkman Gregory Lebovitz Andrew Malis Danny McPherson David Oran Jon Peterson Dave Thaler
马塞洛·巴格努洛·冈萨洛·卡马里洛·斯图尔特·切希尔·维杰·吉尔·罗斯·霍斯利·约翰·克莱森·奥拉夫·科尔克曼·格雷戈里·勒博维茨·安德鲁·马里·丹尼·麦克弗森·大卫·奥兰·乔恩·彼得森·戴夫·泰勒
[Bellovin] Bellovin, S., "A Technique for Counting NATted Hosts", Proc. Second Internet Measurement Workshop, November 2002, <http://www.cs.columbia.edu/~smb/papers/fnat.pdf>.
[Bellovin]Bellovin，S.，“计算NATED主机的技术”，Proc。第二次互联网测量研讨会，2002年11月<http://www.cs.columbia.edu/~smb/papers/fnat.pdf>。
[NANOG] "Extending the Life of Layer 3 Switches in a 256k+ Route World", NANOG 44, October 2008, <http://www.nanog.org/ meetings/nanog44/presentations/Monday/ Roisman_lightning.pdf>.
[NANOG]“在256k+线路世界中延长第3层交换机的寿命”，NANOG 442008年10月<http://www.nanog.org/ 会议/nanog44/presentations/Monday/Roisman_lightning.pdf>。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993]Hain，T.，“NAT的建筑含义”，RFC 29932000年11月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864]Van de Velde，G.，Hain，T.，Droms，R.，Carpenter，B.，和E.Klein，“IPv6的本地网络保护”，RFC 4864，2007年5月。
[RFC4924] Aboba, B. and E. Davies, "Reflections on Internet Transparency", RFC 4924, July 2007.
[RFC4924]Aboba，B.和E.Davies，“关于互联网透明度的思考”，RFC 49242007年7月。
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007.
[RFC4948]Andersson，L.，Davies，E.，和L.Zhang，“IAB 2006年3月9日至10日不必要交通研讨会报告”，RFC 4948，2007年8月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]Stewart，R.，“流控制传输协议”，RFC 49602007年9月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389]Rosenberg，J.，Mahy，R.，Matthews，P.，和D.Wing，“NAT的会话遍历实用程序（STUN）”，RFC 5389，2008年10月。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887]Carpenter，B.，Atkinson，R.，和H.Flinck，“重新编号仍然需要工作”，RFC 5887，2010年5月。
Authors' Addresses
作者地址
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Dave Thaler微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Lixia Zhang UCLA Computer Science Department 3713 Boelter Hall Los Angeles, CA 90095 USA
加州大学洛杉矶分校计算机科学系3713 Boelter Hall洛杉矶，加利福尼亚90095
Phone: +1 310 825 2695
EMail: lixia@cs.ucla.edu
Phone: +1 310 825 2695
EMail: lixia@cs.ucla.edu
Gregory Lebovitz Juniper Networks, Inc. 1194 North Mathilda Ave. Sunnyvale, CA 94089 USA
Gregory Lebovitz Juniper Networks，Inc.美国加利福尼亚州桑尼维尔北玛蒂尔达大道1194号，邮编94089
EMail: gregory.ietf@gmail.com
EMail: gregory.ietf@gmail.com
Internet Architecture Board
互联网架构委员会
EMail: iab@iab.org
EMail: iab@iab.org