Network Working Group                                    G. Van de Velde
Request for Comments: 4864                                       T. Hain
Category: Informational                                         R. Droms
                                                           Cisco Systems
                                                            B. Carpenter
                                                                     IBM
                                                                E. Klein
                                                     Tel Aviv University
                                                                May 2007
        
Network Working Group                                    G. Van de Velde
Request for Comments: 4864                                       T. Hain
Category: Informational                                         R. Droms
                                                           Cisco Systems
                                                            B. Carpenter
                                                                     IBM
                                                                E. Klein
                                                     Tel Aviv University
                                                                May 2007
        

Local Network Protection for IPv6

IPv6的本地网络保护

Status of This Memo

关于下段备忘

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。

Copyright Notice

版权公告

Copyright (C) The IETF Trust (2007).

版权所有(C)IETF信托基金(2007年)。

Abstract

摘要

Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation.

虽然网络地址转换(NAT)有许多明显的好处,但IPv6不需要“放大”可用地址空间这一主要好处。除了NAT的许多严重缺点外,还有一种观点认为,NAT还有其他好处,例如各种管理和安全属性,这些属性可能对Internet协议站点有用。IPv6的设计意图是使NAT变得不必要,本文档说明了使用IPv6的本地网络保护(LNP)如何在不需要地址转换的情况下提供相同或更多的好处。

Table of Contents

目录

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Perceived Benefits of NAT and Its Impact on IPv4 . . . . . . .  6
     2.1.  Simple Gateway between Internet and Private Network  . . .  6
     2.2.  Simple Security Due to Stateful Filter Implementation  . .  6
     2.3.  User/Application Tracking  . . . . . . . . . . . . . . . .  7
     2.4.  Privacy and Topology Hiding  . . . . . . . . . . . . . . .  8
     2.5.  Independent Control of Addressing in a Private Network . .  9
     2.6.  Global Address Pool Conservation . . . . . . . . . . . . .  9
     2.7.  Multihoming and Renumbering with NAT . . . . . . . . . . . 10
   3.  Description of the IPv6 Tools  . . . . . . . . . . . . . . . . 11
     3.1.  Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 11
     3.2.  Unique Local Addresses . . . . . . . . . . . . . . . . . . 12
     3.3.  DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 13
     3.4.  Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 13
   4.  Using IPv6 Technology to Provide the Market Perceived
       Benefits of NAT  . . . . . . . . . . . . . . . . . . . . . . . 14
     4.1.  Simple Gateway between Internet and Internal Network . . . 14
     4.2.  IPv6 and Simple Security . . . . . . . . . . . . . . . . . 15
     4.3.  User/Application Tracking  . . . . . . . . . . . . . . . . 17
     4.4.  Privacy and Topology Hiding Using IPv6 . . . . . . . . . . 17
     4.5.  Independent Control of Addressing in a Private Network . . 20
     4.6.  Global Address Pool Conservation . . . . . . . . . . . . . 21
     4.7.  Multihoming and Renumbering  . . . . . . . . . . . . . . . 21
   5.  Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 22
     5.1.  Medium/Large Private Networks  . . . . . . . . . . . . . . 22
     5.2.  Small Private Networks . . . . . . . . . . . . . . . . . . 24
     5.3.  Single User Connection . . . . . . . . . . . . . . . . . . 25
     5.4.  ISP/Carrier Customer Networks  . . . . . . . . . . . . . . 26
   6.  IPv6 Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . 27
     6.1.  Simple Security  . . . . . . . . . . . . . . . . . . . . . 27
     6.2.  Subnet Topology Masking  . . . . . . . . . . . . . . . . . 28
     6.3.  Minimal Traceability of Privacy Addresses  . . . . . . . . 28
     6.4.  Site Multihoming . . . . . . . . . . . . . . . . . . . . . 28
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 29
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
   10. Informative References . . . . . . . . . . . . . . . . . . . . 30
   Appendix A.  Additional Benefits Due to Native IPv6 and
                Universal Unique Addressing . . . . . . . . . . . . . 32
     A.1.  Universal Any-to-Any Connectivity  . . . . . . . . . . . . 32
     A.2.  Auto-Configuration . . . . . . . . . . . . . . . . . . . . 32
     A.3.  Native Multicast Services  . . . . . . . . . . . . . . . . 33
     A.4.  Increased Security Protection  . . . . . . . . . . . . . . 33
     A.5.  Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 34
     A.6.  Merging Networks . . . . . . . . . . . . . . . . . . . . . 34
        
   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Perceived Benefits of NAT and Its Impact on IPv4 . . . . . . .  6
     2.1.  Simple Gateway between Internet and Private Network  . . .  6
     2.2.  Simple Security Due to Stateful Filter Implementation  . .  6
     2.3.  User/Application Tracking  . . . . . . . . . . . . . . . .  7
     2.4.  Privacy and Topology Hiding  . . . . . . . . . . . . . . .  8
     2.5.  Independent Control of Addressing in a Private Network . .  9
     2.6.  Global Address Pool Conservation . . . . . . . . . . . . .  9
     2.7.  Multihoming and Renumbering with NAT . . . . . . . . . . . 10
   3.  Description of the IPv6 Tools  . . . . . . . . . . . . . . . . 11
     3.1.  Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 11
     3.2.  Unique Local Addresses . . . . . . . . . . . . . . . . . . 12
     3.3.  DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 13
     3.4.  Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 13
   4.  Using IPv6 Technology to Provide the Market Perceived
       Benefits of NAT  . . . . . . . . . . . . . . . . . . . . . . . 14
     4.1.  Simple Gateway between Internet and Internal Network . . . 14
     4.2.  IPv6 and Simple Security . . . . . . . . . . . . . . . . . 15
     4.3.  User/Application Tracking  . . . . . . . . . . . . . . . . 17
     4.4.  Privacy and Topology Hiding Using IPv6 . . . . . . . . . . 17
     4.5.  Independent Control of Addressing in a Private Network . . 20
     4.6.  Global Address Pool Conservation . . . . . . . . . . . . . 21
     4.7.  Multihoming and Renumbering  . . . . . . . . . . . . . . . 21
   5.  Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 22
     5.1.  Medium/Large Private Networks  . . . . . . . . . . . . . . 22
     5.2.  Small Private Networks . . . . . . . . . . . . . . . . . . 24
     5.3.  Single User Connection . . . . . . . . . . . . . . . . . . 25
     5.4.  ISP/Carrier Customer Networks  . . . . . . . . . . . . . . 26
   6.  IPv6 Gap Analysis  . . . . . . . . . . . . . . . . . . . . . . 27
     6.1.  Simple Security  . . . . . . . . . . . . . . . . . . . . . 27
     6.2.  Subnet Topology Masking  . . . . . . . . . . . . . . . . . 28
     6.3.  Minimal Traceability of Privacy Addresses  . . . . . . . . 28
     6.4.  Site Multihoming . . . . . . . . . . . . . . . . . . . . . 28
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 29
   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 29
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
   10. Informative References . . . . . . . . . . . . . . . . . . . . 30
   Appendix A.  Additional Benefits Due to Native IPv6 and
                Universal Unique Addressing . . . . . . . . . . . . . 32
     A.1.  Universal Any-to-Any Connectivity  . . . . . . . . . . . . 32
     A.2.  Auto-Configuration . . . . . . . . . . . . . . . . . . . . 32
     A.3.  Native Multicast Services  . . . . . . . . . . . . . . . . 33
     A.4.  Increased Security Protection  . . . . . . . . . . . . . . 33
     A.5.  Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 34
     A.6.  Merging Networks . . . . . . . . . . . . . . . . . . . . . 34
        
1. Introduction
1. 介绍

There have been periodic claims that IPv6 will require a Network Address Translation (NAT), because network administrators use NAT to meet a variety of needs when using IPv4 and those needs will also have to be met when using IPv6. Although there are many perceived benefits to NAT, its primary benefit of "amplifying" available address space is not needed in IPv6. The serious disadvantages and impact on applications by ambiguous address space and Network Address Translation [1] [5] have been well documented [4] [6], so there will not be much additional discussion here. However, given its wide deployment NAT undoubtedly has some perceived benefits, though the bulk of those using it have not evaluated the technical trade-offs. Indeed, it is often claimed that some connectivity and security concerns can only be solved by using a NAT device, without any mention of the negative impacts on applications. This is amplified through the widespread sharing of vendor best practice documents and sample configurations that do not differentiate the translation function of address expansion from the state function of limiting connectivity.

有人定期声称IPv6将需要网络地址转换(NAT),因为网络管理员在使用IPv4时使用NAT来满足各种需求,而在使用IPv6时也必须满足这些需求。虽然NAT有许多明显的好处,但在IPv6中不需要“放大”可用地址空间这一主要好处。模糊地址空间和网络地址转换[1][5]的严重缺点和对应用程序的影响[4][6]已经有了很好的记录,因此这里不会有太多额外的讨论。然而,考虑到NAT的广泛部署,NAT无疑有一些明显的好处,尽管大部分使用它的人还没有评估技术权衡。事实上,人们经常声称,一些连接和安全问题只能通过使用NAT设备来解决,而没有提到对应用程序的负面影响。这一点通过广泛共享供应商最佳实践文档和示例配置得到了加强,这些文档和示例配置没有区分地址扩展的转换功能和限制连接性的状态功能。

This document describes the uses of a NAT device in an IPv4 environment that are regularly cited as 'solutions' for perceived problems. It then shows how the goals of the network manager can be met in an IPv6 network without using the header modification feature of NAT. It should be noted that this document is 'informational', as it discusses approaches that will work to accomplish the goals of the network manager. It is specifically not a Best Current Practice (BCP) that is recommending any one approach or a manual on how to configure a network.

本文档描述了在IPv4环境中使用NAT设备的情况,这些情况通常被称为感知问题的“解决方案”。然后展示了如何在IPv6网络中实现network manager的目标,而无需使用NAT的头修改功能。应该注意的是,本文档具有“信息性”,因为它讨论了实现network manager目标的方法。具体而言,就如何配置网络而言,推荐任何一种方法或手册并不是最佳现行做法(BCP)。

As far as security and privacy are concerned, this document considers how to mitigate a number of threats. Some are obviously external, such as having a hacker or a worm-infected machine outside trying to penetrate and attack the local network. Some are local, such as a disgruntled employee disrupting business operations or the unintentional negligence of a user downloading some malware, which then proceeds to attack from within. Some may be inherent in the device hardware ("embedded"), such as having some firmware in a domestic appliance "call home" to its manufacturer without the user's consent.

就安全和隐私而言,本文件考虑了如何缓解一些威胁。有些显然是外部的,例如有黑客或蠕虫感染的机器在外部试图渗透和攻击本地网络。有些是本地的,例如不满的员工扰乱了业务运营,或者用户无意中疏忽了下载某些恶意软件,然后从内部进行攻击。一些可能是设备硬件(“嵌入式”)中固有的,例如家用设备中的一些固件未经用户同意就向其制造商“呼叫总部”。

Another consideration discussed is the view that NAT can be used to fulfill the goals of a security policy. On the one hand, NAT does satisfy some policy goals, such as topology hiding; at the same time it defeats others, such as the ability to produce an end-to-end audit trail at network level. That said, there are artifacts of NAT devices that do provide some value.

讨论的另一个考虑因素是NAT可用于实现安全策略的目标。一方面,NAT确实满足一些策略目标,如拓扑隐藏;同时,它还击败了其他技术,例如在网络级别生成端到端审计跟踪的能力。也就是说,NAT设备的一些构件确实提供了一些价值。

1. The need to establish state before anything gets through from outside to inside solves one set of problems.

1. 在任何事情从外部进入内部之前建立状态的需要解决了一系列问题。

2. The expiration of state to stop receiving any packets when finished with a flow solves a set of problems.

2. 使用流结束时停止接收任何数据包的状态过期解决了一组问题。

3. The ability for nodes to appear to be attached at the edge of the network solves a set of problems.

3. 节点看起来连接在网络边缘的能力解决了一系列问题。

4. The ability to have addresses that are not publicly routed solves yet another set (mostly changes where the state is and scale requirements for the first one).

4. 拥有未公开路由的地址的能力解决了另一组问题(大多数情况下,第一组地址的状态和规模要求会发生变化)。

This document describes several techniques that may be combined in an IPv6 deployment to protect the integrity of its network architecture. It will focus on the 'how to accomplish a goal' perspective, leaving most of the 'why that goal is useful' perspective for other documents. These techniques, known collectively as Local Network Protection (LNP), retain the concept of a well-defined boundary between "inside" and "outside" the private network, while allowing firewalling, topology hiding, and privacy. LNP will achieve these security goals without address translation while regaining the ability for arbitrary any-to-any connectivity.

本文档描述了可在IPv6部署中结合使用的几种技术,以保护其网络体系结构的完整性。它将关注“如何实现目标”的视角,而将“为什么该目标有用”的视角留给其他文档。这些技术统称为本地网络保护(LNP),保留了私有网络“内部”和“外部”之间定义明确的边界概念,同时允许防火墙、拓扑隐藏和隐私。LNP将在不进行地址转换的情况下实现这些安全目标,同时恢复任意对任意连接的能力。

IPv6 Local Network Protection can be summarized in the following table. It presents the marketed benefits of IPv4+NAT with a cross-reference of how those are delivered in both the IPv4 and IPv6 environments.

下表总结了IPv6本地网络保护。它介绍了IPv4+NAT的市场优势,并交叉介绍了如何在IPv4和IPv6环境中提供这些优势。

          Goal                 IPv4                    IPv6
   +------------------+-----------------------+-----------------------+
   | Simple Gateway   |  DHCP - single        |  DHCP-PD - arbitrary  |
   | as default router|  address upstream     |  length customer      |
   | and address pool |  DHCP - limited       |  prefix upstream      |
   | manager          |  number of individual |  SLAAC via RA         |
   |                  |  devices downstream   |  downstream           |
   |                  |  see Section 2.1      |  see Section 4.1      |
   +------------------|-----------------------|-----------------------+
   |  Simple Security |  Filtering side       |  Explicit Context     |
   |                  |  effect due to lack   |  Based Access Control |
   |                  |  of translation state |  (Reflexive ACL)      |
   |                  |  see Section 2.2      |  see Section 4.2      |
   +------------------|-----------------------|-----------------------+
   |  Local Usage     |  NAT state table      |  Address uniqueness   |
   |  Tracking        |                       |                       |
   |                  |  see Section 2.3      |  see Section 4.3      |
   +------------------|-----------------------|-----------------------+
   |  End-System      |  NAT transforms       |  Temporary use        |
   |  Privacy         |  device ID bits in    |  privacy addresses    |
   |                  |  the address          |                       |
   |                  |  see Section 2.4      |  see Section 4.4      |
   +------------------|-----------------------|-----------------------+
   |  Topology Hiding |  NAT transforms       |  Untraceable addresses|
   |                  |  subnet bits in the   |  using IGP host routes|
   |                  |  address              |  /or MIPv6 tunnels    |
   |                  |  see Section 2.4      |  see Section 4.4      |
   +------------------|-----------------------|-----------------------+
   |  Addressing      |  RFC 1918             |  RFC 3177 & 4193      |
   |  Autonomy        |  see Section 2.5      |  see Section 4.5      |
   +------------------|-----------------------|-----------------------+
   |  Global Address  |  RFC 1918             |  17*10^18 subnets     |
   |  Pool            |  << 2^48 application  |  3.4*10^38 addresses  |
   |  Conservation    |  end points           | full port list / addr |
   |                  |  topology restricted  | unrestricted topology |
   |                  |  see Section 2.6      |  see Section 4.6      |
   +------------------|-----------------------|-----------------------+
   |  Renumbering and |  Address translation  |  Preferred lifetime   |
   |  Multihoming     |  at border            |  per prefix & multiple|
   |                  |                       |  addresses per        |
   |                  |                       |  interface            |
   |                  |  see Section 2.7      |  see Section 4.7      |
   +------------------+-----------------------+-----------------------+
        
          Goal                 IPv4                    IPv6
   +------------------+-----------------------+-----------------------+
   | Simple Gateway   |  DHCP - single        |  DHCP-PD - arbitrary  |
   | as default router|  address upstream     |  length customer      |
   | and address pool |  DHCP - limited       |  prefix upstream      |
   | manager          |  number of individual |  SLAAC via RA         |
   |                  |  devices downstream   |  downstream           |
   |                  |  see Section 2.1      |  see Section 4.1      |
   +------------------|-----------------------|-----------------------+
   |  Simple Security |  Filtering side       |  Explicit Context     |
   |                  |  effect due to lack   |  Based Access Control |
   |                  |  of translation state |  (Reflexive ACL)      |
   |                  |  see Section 2.2      |  see Section 4.2      |
   +------------------|-----------------------|-----------------------+
   |  Local Usage     |  NAT state table      |  Address uniqueness   |
   |  Tracking        |                       |                       |
   |                  |  see Section 2.3      |  see Section 4.3      |
   +------------------|-----------------------|-----------------------+
   |  End-System      |  NAT transforms       |  Temporary use        |
   |  Privacy         |  device ID bits in    |  privacy addresses    |
   |                  |  the address          |                       |
   |                  |  see Section 2.4      |  see Section 4.4      |
   +------------------|-----------------------|-----------------------+
   |  Topology Hiding |  NAT transforms       |  Untraceable addresses|
   |                  |  subnet bits in the   |  using IGP host routes|
   |                  |  address              |  /or MIPv6 tunnels    |
   |                  |  see Section 2.4      |  see Section 4.4      |
   +------------------|-----------------------|-----------------------+
   |  Addressing      |  RFC 1918             |  RFC 3177 & 4193      |
   |  Autonomy        |  see Section 2.5      |  see Section 4.5      |
   +------------------|-----------------------|-----------------------+
   |  Global Address  |  RFC 1918             |  17*10^18 subnets     |
   |  Pool            |  << 2^48 application  |  3.4*10^38 addresses  |
   |  Conservation    |  end points           | full port list / addr |
   |                  |  topology restricted  | unrestricted topology |
   |                  |  see Section 2.6      |  see Section 4.6      |
   +------------------|-----------------------|-----------------------+
   |  Renumbering and |  Address translation  |  Preferred lifetime   |
   |  Multihoming     |  at border            |  per prefix & multiple|
   |                  |                       |  addresses per        |
   |                  |                       |  interface            |
   |                  |  see Section 2.7      |  see Section 4.7      |
   +------------------+-----------------------+-----------------------+
        

This document first identifies the perceived benefits of NAT in more detail, and then shows how IPv6 LNP can provide each of them. It concludes with an IPv6 LNP case study and a gap analysis of standards work that remains to be done for an optimal LNP solution.

本文档首先更详细地确定了NAT的可感知好处,然后展示了IPv6 LNP如何提供每一个好处。最后给出了一个IPv6 LNP案例研究和标准工作的差距分析,这些工作有待于为最佳LNP解决方案完成。

2. Perceived Benefits of NAT and Its Impact on IPv4
2. NAT的感知优势及其对IPv4的影响

This section provides insight into the generally perceived benefits of the use of IPv4 NAT. The goal of this description is not to analyze these benefits or the accuracy of the perception (detailed discussions in [4]), but to describe the deployment requirements and set a context for the later descriptions of the IPv6 approaches for dealing with those requirements.

本节深入了解了使用IPv4 NAT的普遍好处。本说明的目的不是分析这些好处或感知的准确性(在[4]中进行详细讨论),而是描述部署需求,并为后面描述处理这些需求的IPv6方法设置上下文。

2.1. Simple Gateway between Internet and Private Network
2.1. Internet和专用网络之间的简单网关

A NAT device can connect a private network with addresses allocated from any part of the space (ambiguous [1]or global registered and unregistered addresses) towards the Internet, though extra effort is needed when the same range exists on both sides of the NAT. The address space of the private network can be built from globally unique addresses, from ambiguous address space, or from both simultaneously. In the simple case of private use addresses, without needing specific configuration the NAT device enables access between the client side of a distributed client-server application in the private network and the server side located in the public Internet.

NAT设备可以将具有从空间的任何部分(不明确[1]或全局注册和未注册地址)分配的地址的专用网络连接到Internet,但当NAT两侧存在相同范围时,需要额外的努力。专用网络的地址空间可以从全局唯一的地址、不明确的地址空间或同时从这两个地址构建。在私用地址的简单情况下,无需特定配置,NAT设备能够在私用网络中的分布式客户端-服务器应用程序的客户端和位于公共因特网中的服务器端之间进行访问。

Wide-scale deployments have shown that using NAT to act as a simple gateway attaching a private IPv4 network to the Internet is simple and practical for the non-technical end user. Frequently, a simple user interface or even a default configuration is sufficient for configuring both device and application access rights.

大规模部署表明,对于非技术终端用户来说,使用NAT作为将专用IPv4网络连接到Internet的简单网关既简单又实用。通常,一个简单的用户界面甚至默认配置就足以配置设备和应用程序访问权限。

This simplicity comes at a price, as the resulting topology puts restrictions on applications. The NAT simplicity works well when the applications are limited to a client/server model with the server deployed on the public side of the NAT. For peer-to-peer, multi-party, or servers deployed on the private side of the NAT, helper technologies must also be deployed. These helper technologies are frequently complex to develop and manage, creating a hidden cost to this 'simple gateway'.

这种简单性是有代价的,因为由此产生的拓扑对应用程序造成了限制。当应用程序局限于客户机/服务器模型,服务器部署在NAT的公共端时,NAT的简单性工作得很好。对于部署在NAT私有端的对等、多方或服务器,还必须部署助手技术。这些辅助技术的开发和管理往往很复杂,这给这个“简单网关”带来了隐藏的成本。

2.2. Simple Security Due to Stateful Filter Implementation
2.2. 由于有状态筛选器实现,因此具有简单的安全性

It is frequently believed that through its session-oriented operation, NAT puts in an extra barrier to keep the private network protected from outside influences. Since a NAT device typically keeps state only for individual sessions, attackers, worms, etc.,

人们通常认为,通过面向会话的操作,NAT增加了一个额外的屏障,以保护私有网络免受外部影响。由于NAT设备通常仅为单个会话、攻击者、蠕虫等保持状态。,

cannot exploit this state to attack a specific host on any other port. However, in the port overload case of Network Address Port Translation (NAPT) attacking all active ports will impact a potentially wide number of hosts. This benefit may be partially real; however, experienced hackers are well aware of NAT devices and are very familiar with private address space, and they have devised methods of attack (such as trojan horses) that readily penetrate NAT boundaries. While the stateful filtering offered by NAT offers a measure of protection against a variety of straightforward network attacks, it does not protect against all attacks despite being presented as a one-size-fits-all answer.

无法利用此状态攻击任何其他端口上的特定主机。但是,在端口过载的情况下,网络地址端口转换(NAPT)攻击所有活动端口将影响大量主机。这种好处可能部分是真实的;然而,经验丰富的黑客对NAT设备了如指掌,并且非常熟悉私有地址空间,他们已经设计出了能够轻易穿透NAT边界的攻击方法(如特洛伊木马)。虽然NAT提供的状态过滤提供了一种针对各种直接网络攻击的保护措施,但它并不能针对所有攻击提供保护,尽管它是一种一刀切的解决方案。

The act of translating address bits within the header does not provide security in itself. For example, consider a configuration with static NAT and all inbound ports translating to a single machine. In such a scenario, the security risk for that machine is identical to the case with no NAT device in the communication path, as any connection to the public address will be delivered to the mapped target.

在报头内转换地址位的行为本身并不提供安全性。例如,考虑具有静态NAT和所有入站端口的转换到单个机器的配置。在这种情况下,该机器的安全风险与通信路径中没有NAT设备的情况相同,因为到公共地址的任何连接都将传递到映射的目标。

The perceived security of NAT comes from the lack of pre-established or permanent mapping state. This is often used as a 'better than nothing' level of protection because it doesn't require complex management to filter out unwanted traffic. Dynamically establishing state in response to internal requests reduces the threat of unexpected external connections to internal devices, and this level of protection would also be available from a basic firewall. (A basic firewall, supporting clients accessing public side servers, would improve on that level of protection by avoiding the problem of state persisting as different clients use the same private side address over time.) This role, often marketed as a firewall, is really an arbitrary artifact, while a real firewall often offers explicit and more comprehensive management controls.

NAT的安全性来自于缺乏预先建立的或永久的映射状态。这通常被用作“比没有更好”的保护级别,因为它不需要复杂的管理来过滤掉不需要的流量。响应内部请求动态建立状态可减少意外外部连接到内部设备的威胁,并且基本防火墙也可提供此级别的保护。(支持客户端访问公共端服务器的基本防火墙可以通过避免不同客户端使用相同的私有端地址时状态持续的问题来提高保护级别。)这个角色通常被称为防火墙,实际上是一个任意的产物,而真正的防火墙通常提供明确和更全面的管理控制。

In some cases, NAT operators (including domestic users) may be obliged to configure quite complex port mapping rules to allow external access to local applications such as a multi-player game or web servers. In this case, the NAT actually adds management complexity compared to the simple router discussed in Section 2.1. In situations where two or more devices need to host the same application or otherwise use the same public port, this complexity shifts from difficult to impossible.

在某些情况下,NAT运营商(包括国内用户)可能必须配置相当复杂的端口映射规则,以允许外部访问本地应用程序,如多人游戏或web服务器。在这种情况下,与第2.1节中讨论的简单路由器相比,NAT实际上增加了管理复杂性。在两个或多个设备需要承载相同的应用程序或使用相同的公共端口的情况下,这种复杂性从困难变为不可能。

2.3. User/Application Tracking
2.3. 用户/应用程序跟踪

One usage of NAT is for the local network administrator to track user and application traffic. Although NATs create temporary state for active sessions, in general they provide limited capabilities for the

NAT的一个用途是让本地网络管理员跟踪用户和应用程序流量。虽然NAT为活动会话创建临时状态,但一般来说,NAT为活动会话提供的功能有限

administrator of the NAT to gather information about who in the private network is requesting access to which Internet location. This is done by periodically logging the network address translation details of the private and the public addresses from the NAT device's state database.

NAT管理员收集有关专用网络中谁请求访问哪个Internet位置的信息。这是通过定期记录NAT设备状态数据库中私有和公共地址的网络地址转换详细信息来完成的。

The subsequent checking of this database is not always a simple task, especially if Port Address Translation is used. It also has an unstated assumption that the administrative instance has a mapping between a private IPv4-address and a network element or user at all times, or the administrator has a time-correlated list of the address/port mappings.

该数据库的后续检查并不总是一项简单的任务,尤其是在使用端口地址转换的情况下。它还有一个未声明的假设,即管理实例始终具有专用IPv4地址与网元或用户之间的映射,或者管理员具有与时间相关的地址/端口映射列表。

2.4. Privacy and Topology Hiding
2.4. 隐私和拓扑隐藏

One goal of 'topology hiding' is to prevent external entities from making a correlation between the topological location of devices on the local network. The ability of NAT to provide Internet access to a large community of users by the use of a single (or a few) globally routable IPv4 address(es) offers a simple mechanism to hide the internal topology of a network. In this scenario, the large community will be represented in the Internet by a single (or a few) IPv4 address(es).

“拓扑隐藏”的一个目标是防止外部实体在本地网络上的设备拓扑位置之间建立关联。NAT能够通过使用单个(或几个)全局可路由IPv4地址向大量用户提供Internet访问,这提供了一种隐藏网络内部拓扑的简单机制。在这种情况下,大型社区将在Internet上由一个(或几个)IPv4地址表示。

By using NAT, a system appears to the Internet as if it originated inside the NAT box itself; i.e., the IPv4 address that appears on the Internet is only sufficient to identify the NAT so all internal nodes appear to exist at the demarcation edge. When concealed behind a NAT, it is impossible to tell from the outside which member of a family, which customer of an Internet cafe, or which employee of a company generated or received a particular packet. Thus, although NATs do nothing to provide application level privacy, they do prevent the external tracking and profiling of individual systems by means of their IP addresses, usually known as 'device profiling'.

通过使用NAT,一个系统在互联网上看起来就像它起源于NAT盒本身;i、 例如,Internet上出现的IPv4地址仅足以识别NAT,因此所有内部节点似乎都存在于分界边缘。当隐藏在NAT后面时,从外部无法分辨哪个家庭成员、网吧的哪个客户或公司的哪个员工生成或接收特定数据包。因此,尽管NAT不提供应用程序级隐私,但它们确实通过IP地址(通常称为“设备分析”)阻止了对单个系统的外部跟踪和分析。

There is a similarity with privacy based on application level proxies. When using an application level gateway for browsing the web for example, the 'privacy' of a web user can be provided by masking the true identity of the original web user towards the outside world (although the details of what is -- or is not -- logged at the NAT/proxy will be different).

与基于应用程序级代理的隐私有相似之处。例如,当使用应用程序级网关浏览web时,可以通过向外界屏蔽原始web用户的真实身份来提供web用户的“隐私”(尽管NAT/代理上记录或未记录的内容的详细信息会有所不同)。

Some network managers prefer to hide as much as possible of their internal network topology from outsiders as a useful precaution to mitigate scanning attacks. Mostly, this is achieved by blocking "traceroute", etc., though NAT entirely hides the internal subnet topology. Scanning is a particular concern in IPv4 networks because the subnet size is small enough that once the topology is known, it

一些网络管理者倾向于尽可能地向外界隐藏其内部网络拓扑结构,以此作为缓解扫描攻击的有效预防措施。大多数情况下,这是通过阻塞“跟踪路由”等来实现的,尽管NAT完全隐藏了内部子网拓扑。在IPv4网络中,扫描是一个特别值得关注的问题,因为子网的大小足够小,一旦知道拓扑结构,它就会

is easy to find all the hosts, then start scanning them for vulnerable ports. Once a list of available devices has been mapped, a port-scan on these IP addresses can be performed. Scanning works by tracking which ports do not receive unreachable errors from either the firewall or host. With the list of open ports, an attacker can optimize the time needed for a successful attack by correlating it with known vulnerabilities to reduce the number of attempts. For example, FTP usually runs on port 21, and HTTP usually runs on port 80. Any vulnerable open ports could be used for access to an end-system to command it to start initiating attacks on others.

很容易找到所有主机,然后开始扫描它们以查找易受攻击的端口。一旦映射了可用设备的列表,就可以对这些IP地址执行端口扫描。扫描的工作原理是跟踪哪些端口没有收到来自防火墙或主机的无法访问的错误。利用开放端口列表,攻击者可以通过将攻击与已知漏洞关联以减少尝试次数,从而优化成功攻击所需的时间。例如,FTP通常在端口21上运行,HTTP通常在端口80上运行。任何易受攻击的开放端口都可用于访问终端系统,以命令其开始对其他系统发起攻击。

2.5. Independent Control of Addressing in a Private Network
2.5. 专用网络中寻址的独立控制

Many private IPv4 networks make use of the address space defined in RFC 1918 to enlarge the available addressing space for their private network, and at the same time reduce their need for globally routable addresses. This type of local control of address resources allows a sufficiently large pool for a clean and hierarchical addressing structure in the local network.

许多专用IPv4网络利用RFC1918中定义的地址空间来扩大其专用网络的可用地址空间,同时减少对全局可路由地址的需求。这种类型的地址资源本地控制允许一个足够大的池,用于本地网络中干净的分层寻址结构。

Another benefit is the ability to change providers with minimal operational difficulty due to the usage of independent addresses on a majority of the network infrastructure. Changing the addresses on the public side of the NAT avoids the administrative challenge of changing every device in the network.

另一个好处是,由于在大多数网络基础设施上使用独立地址,因此能够以最小的操作难度更换提供商。更改NAT公共端的地址可以避免更改网络中每个设备的管理挑战。

Section 2.7 describes some disadvantages that appear if independent networks using ambiguous addresses [1] have to be merged.

第2.7节描述了必须合并使用不明确地址[1]的独立网络时出现的一些缺点。

2.6. Global Address Pool Conservation
2.6. 全局地址池保护

While the widespread use of IPv4+NAT has reduced the potential consumption rate, the ongoing depletion of the IPv4 address range has already taken the remaining pool of unallocated IPv4 addresses well below 20%. While mathematical models based on historical IPv4 prefix consumption periodically attempt to predict the future exhaustion date of the IPv4 address pool, a possible result of this continuous resource consumption is that the administrative overhead for acquiring globally unique IPv4 addresses will at some point increase noticeably due to tightening allocation policies.

虽然IPv4+NAT的广泛使用降低了潜在的消耗率,但IPv4地址范围的持续消耗已经使剩余的未分配IPv4地址池远远低于20%。基于历史IPv4前缀消耗的数学模型定期尝试预测IPv4地址池的未来耗尽日期,这种持续资源消耗的一个可能结果是,由于分配策略的收紧,获取全局唯一IPv4地址的管理开销将在某个时候显著增加。

In response to the increasing administrative overhead, many Internet Service Providers (ISPs) have already resorted to the ambiguous addresses defined in RFC 1918 behind a NAT for the various services they provide as well as connections for their end customers. This happens even though the private use address space is strictly limited in size. Some deployments have already outgrown that space and have begun cascading NAT to continue expanding, though this practice

为了应对日益增加的管理开销,许多互联网服务提供商(ISP)已经在NAT后面使用RFC1918中定义的模糊地址来提供各种服务以及为最终客户连接。即使私有地址空间的大小受到严格限制,也会发生这种情况。一些部署已经超出了这一范围,并开始级联NAT以继续扩展,尽管这种做法

eventually breaks down over routing ambiguity. Additionally, while we are unlikely to know the full extent of the practice (because it is hidden behind a NAT), service providers have been known to announce previously unallocated public space to their customers (to avoid the problems associated with the same address space appearing on both sides), only to find that once that space was formally allocated and being publicly announced, their customers couldn't reach the registered networks.

最终因路由模糊而崩溃。此外,虽然我们不太可能知道这种做法的全部范围(因为它隐藏在NAT后面),但已知服务提供商会向其客户宣布以前未分配的公共空间(以避免双方出现与相同地址空间相关的问题),结果发现,一旦该空间被正式分配并公开宣布,他们的客户就无法访问已注册的网络。

The number of and types of applications that can be deployed by these ISPs and their customers are restricted by the ability to overload the port range on the public side of the most public NAT in the path. The limit of this approach is something substantially less than 2^48 possible active *application* endpoints (approximately [2^32 minus 2^29] * [2* 2^16 minus well-known port space]), as distinct from addressable devices each with its own application endpoint range. Those who advocate layering of NAT frequently forget to mention that there are topology restrictions placed on the applications. Forced into this limiting situation, such customers can rightly claim that despite the optimistic predictions of mathematical models, the global pool of IPv4 addresses is effectively already exhausted.

这些ISP及其客户可以部署的应用程序的数量和类型受到路径中最公共NAT公共端端口范围过载能力的限制。这种方法的限制是大大少于2^48个可能的活动*应用程序*端点(大约[2^32减去2^29]*[2*2^16减去已知的端口空间]),这与每个具有自己的应用程序端点范围的可寻址设备不同。那些提倡NAT分层的人经常忘记提及应用程序上存在拓扑限制。迫于这种限制,这些客户可以正确地宣称,尽管数学模型的预测是乐观的,但IPv4地址的全球池实际上已经耗尽了。

2.7. Multihoming and Renumbering with NAT
2.7. 使用NAT进行多址和重新编号

Allowing a network to be multihomed and renumbering a network are quite different functions. However, these are argued together as reasons for using NAT, because making a network multihomed is often a transitional state required as part of network renumbering, and NAT interacts with both in the same way.

允许网络多址和对网络重新编号是完全不同的功能。然而,这些都是使用NAT的理由,因为作为网络重新编号的一部分,使网络多址通常是一种过渡状态,NAT以相同的方式与两者交互。

For enterprise networks, it is highly desirable to provide resiliency and load-balancing to be connected to more than one Internet Service Provider (ISP) and to be able to change ISPs at will. This means that a site must be able to operate under more than one Classless Inter-Domain Routing (CIDR) prefix [18] and/or readily change its CIDR prefix. Unfortunately, IPv4 was not designed to facilitate either of these maneuvers. However, if a site is connected to its ISPs via NAT boxes, only those boxes need to deal with multihoming and renumbering issues.

对于企业网络,提供弹性和负载平衡以连接到多个Internet服务提供商(ISP)并能够随意更改ISP是非常理想的。这意味着站点必须能够在多个无类别域间路由(CIDR)前缀[18]下运行和/或随时更改其CIDR前缀。不幸的是,IPv4的设计并不是为了促进这两种策略。但是,如果站点通过NAT盒连接到其ISP,则只有这些盒需要处理多址和重新编号问题。

Similarly, if two enterprise IPv4 networks need to be merged and RFC 1918 addresses are used, there is a high probability of address overlaps. In those situations, it may well be that installing a NAT box between them will avoid the need to renumber one or both. For any enterprise, this can be a short-term financial saving and allows more time to renumber the network components. The long-term solution is a single network without usage of NAT to avoid the ongoing operational complexity of overlapping addresses.

类似地,如果需要合并两个企业IPv4网络并使用RFC1918地址,则地址重叠的概率很高。在这些情况下,很可能在它们之间安装NAT盒将避免重新编号一个或两个。对于任何企业来说,这可能是一种短期的财务节约,并允许有更多的时间对网络组件重新编号。长期的解决方案是不使用NAT的单一网络,以避免重叠地址的持续操作复杂性。

The addition of an extra NAT as a solution may be sufficient for some networks; however, when the merging networks were already using address translation it will create major problems due to administrative difficulties of overlapping address spaces in the merged networks.

对于某些网络,添加额外的NAT作为解决方案可能就足够了;然而,当合并网络已经使用地址转换时,由于合并网络中地址空间重叠的管理困难,将产生重大问题。

3. Description of the IPv6 Tools
3. IPv6工具说明

This section describes several features that can be used as part of the LNP solution to replace the protection features associated with IPv4 NAT.

本节介绍了可作为LNP解决方案的一部分用于替换与IPv4 NAT关联的保护功能的若干功能。

The reader must clearly distinguish between features of IPv6 that were fully defined when this document was drafted and those that were potential features that still required more work to define them. The latter are summarized later in the 'Gap Analysis' section of this document. However, we do not distinguish in this document between fully defined features of IPv6 and those that were already widely implemented at the time of writing.

读者必须清楚地区分在起草本文档时已完全定义的IPv6功能和那些仍需要更多工作才能定义的潜在功能。后者将在本文件后面的“差距分析”部分进行总结。但是,在本文档中,我们没有区分IPv6的完全定义功能和在撰写本文时已经广泛实现的功能。

3.1. Privacy Addresses (RFC 3041)
3.1. 隐私地址(RFC3041)

There are situations where it is desirable to prevent device profiling, for example, by web sites that are accessed from the device as it moves around the Internet. IPv6 privacy addresses were defined to provide that capability. IPv6 addresses consist of a routing prefix, a subnet-id (SID) part, and an interface identifier (IID) part. As originally defined, IPv6 stateless address auto-configuration (SLAAC) will typically embed the IEEE Link Identifier of the interface as the IID part, though this practice facilitates tracking and profiling of a device through the consistent IID. RFC 3041 [7] describes an extension to SLAAC to enhance device privacy. Use of the privacy address extension causes nodes to generate global-scope addresses from interface identifiers that change over time, consistent with system administrator policy. Changing the interface identifier (thus the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when addresses used in different transactions actually correspond to the same node. A relatively short valid lifetime for the privacy address also has the effect of reducing the attack profile of a device, as it is not directly attackable once it stops answering at the temporary use address.

在某些情况下,需要防止设备分析,例如,当设备在Internet上移动时,从设备访问的网站。IPv6隐私地址的定义就是为了提供这种功能。IPv6地址由路由前缀、子网id(SID)部分和接口标识符(IID)部分组成。按照最初的定义,IPv6无状态地址自动配置(SLAAC)通常会将接口的IEEE链路标识符嵌入为IID部分,尽管这种做法有助于通过一致的IID跟踪和分析设备。RFC 3041[7]描述了SLAAC的扩展,以增强设备隐私。使用隐私地址扩展会导致节点根据随时间变化的接口标识符生成全局作用域地址,这与系统管理员策略一致。随着时间的推移,更改接口标识符(由此生成的全局作用域地址)会使窃听者和其他信息收集器更难识别不同事务中使用的地址何时实际对应于同一节点。隐私地址相对较短的有效生存期也会降低设备的攻击模式,因为一旦它在临时使用地址停止应答,就无法直接攻击。

While the primary implementation and source of randomized RFC 3041 addresses are expected to be from end-systems running stateless auto-configuration, there is nothing that prevents a Dynamic Host Configuration Protocol (DHCP) server from running the RFC 3041 algorithm for any new IEEE identifier it hears in a request, then

虽然随机RFC 3041地址的主要实现和来源预计来自运行无状态自动配置的终端系统,但没有任何东西阻止动态主机配置协议(DHCP)服务器针对其在请求中听到的任何新IEEE标识符运行RFC 3041算法,然后

remembering that for future queries. This would allow using them in DNS for registered services since the assumption of a DHCP server-based deployment would be a persistent value that minimizes DNS churn. A DHCP-based deployment would also allow for local policy to periodically change the entire collection of end-device addresses while maintaining some degree of central knowledge and control over which addresses should be in use at any point in time.

记住这一点,以便将来查询。这将允许在DNS中使用它们来注册服务,因为基于DHCP服务器的部署将是一个持久值,可以最大限度地减少DNS搅动。基于DHCP的部署还允许本地策略定期更改整个终端设备地址集合,同时保持一定程度的中心知识,并控制在任何时间点应使用哪些地址。

Randomizing the IID, as defined in RFC 3041, is effectively a sparse allocation technique that only precludes tracking of the lower 64 bits of the IPv6 address. Masking of the subnet ID will require additional approaches as discussed below in Section 3.4. Additional considerations are discussed in [19].

按照RFC 3041中的定义,对IID进行随机化是一种有效的稀疏分配技术,它仅排除对IPv6地址较低64位的跟踪。屏蔽子网ID将需要其他方法,如下文第3.4节所述。[19]中讨论了其他注意事项。

3.2. Unique Local Addresses
3.2. 唯一本地地址

Achieving the goal of autonomy, that many perceive as a value of NAT, is required for local network and application services stability during periods of intermittent connectivity or moving between one or more providers. Such autonomy in a single routing prefix environment would lead to massive expansion of the global routing tables (as seen in IPv4), so IPv6 provides for simultaneous use of multiple prefixes. The Unique Local Address (ULA) prefix [17] has been set aside for use in local communications. The ULA prefix for any network is routable over a locally defined collection of routers. These prefixes are not intended to be routed on the public global Internet as large-scale inter-domain distribution of routes for ULA prefixes would have a negative impact on global route aggregation.

为了在间歇性连接期间或在一个或多个提供商之间移动期间保持本地网络和应用程序服务的稳定性,需要实现许多人视为NAT价值的自治目标。单一路由前缀环境中的这种自主性将导致全局路由表的大规模扩展(如IPv4中所示),所以IPv6提供了同时使用多个前缀的功能。唯一本地地址(ULA)前缀[17]已预留用于本地通信。任何网络的ULA前缀都可以通过本地定义的路由器集合进行路由。这些前缀不打算在公共全球互联网上路由,因为ULA前缀路由的大规模域间分布将对全球路由聚合产生负面影响。

ULAs have the following characteristics:

ULA具有以下特点:

o For all practical purposes, a globally unique prefix

o 出于所有实际目的,一个全局唯一的前缀

* allows networks to be combined or privately interconnected without creating address conflicts or requiring renumbering of interfaces using these prefixes, and

* 允许在不产生地址冲突或不需要使用这些前缀对接口重新编号的情况下组合或私下互连网络,以及

* if accidentally leaked outside of a network via routing or DNS, is highly unlikely that there will be a conflict with any other addresses.

* 如果通过路由或DNS意外泄漏到网络外部,则极不可能与任何其他地址发生冲突。

o They are ISP independent and can be used for communications inside of a network without having any permanent or only intermittent Internet connectivity.

o 它们独立于ISP,可用于网络内部的通信,而无需任何永久或间歇性的Internet连接。

o They have a well-known prefix to allow for easy filtering at network boundaries preventing leakage of routes and packets that should remain local.

o 它们有一个众所周知的前缀,可以方便地在网络边界处进行过滤,防止本应保持本地的路由和数据包泄漏。

o In practice, applications may treat these addresses like global-scope addresses, but address selection algorithms may need to distinguish between ULAs and ordinary global-scope unicast addresses to ensure stability. The policy table defined in [11] is one way to bias this selection, by giving higher preference to FC00::/7 over 2001::/3. Mixing the two kinds of addresses may lead to undeliverable packets during times of instability, but that mixing is not likely to happen when the rules of RFC 3484 are followed.

o 实际上,应用程序可能将这些地址视为全局范围地址,但地址选择算法可能需要区分ULA和普通全局范围单播地址,以确保稳定性。[11]中定义的策略表是偏向此选择的一种方法,它比2001::/3更优先选择FC00::/7。在不稳定期间,混合这两种地址可能会导致无法传送的数据包,但当遵循RFC 3484的规则时,这种混合不太可能发生。

o ULAs have no intrinsic security properties. However, they have the useful property that their routing scope is limited by default within an administrative boundary. Their usage is suggested at several points in this document, as a matter of administrative convenience.

o ULA没有内在的安全属性。但是,它们有一个有用的特性,即它们的路由范围在默认情况下被限制在管理边界内。为了便于管理,本文件中有几点建议使用它们。

3.3. DHCPv6 Prefix Delegation
3.3. DHCPv6前缀委派

One of the functions of a simple gateway is managing the local use address range. The Prefix Delegation (DHCP-PD) options [12] provide a mechanism for automated delegation of IPv6 prefixes using the DHCP [10]. This mechanism (DHCP-PD) is intended for delegating a long-lived prefix from a delegating router (possibly incorporating a DHCPv6 server) to a requesting router, possibly across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.

简单网关的功能之一是管理本地使用地址范围。前缀委派(DHCP-PD)选项[12]提供了一种使用DHCP自动委派IPv6前缀的机制[10]。此机制(DHCP-PD)旨在将长寿命前缀从委派路由器(可能包含DHCPv6服务器)委派到请求路由器,可能跨越管理边界,其中委派路由器不需要了解前缀将被分配到的网络中链路的拓扑。

3.4. Untraceable IPv6 Addresses
3.4. 无法追踪的IPv6地址

The main goal of untraceable IPv6 addresses is to create an apparently amorphous network infrastructure, as seen from external networks, to protect the local infrastructure from malicious outside influences and from mapping of any correlation between the network activities of multiple devices from external networks. When using untraceable IPv6 addresses, it could be that two apparently sequential addresses are allocated to devices on very different parts of the local network instead of belonging to devices adjacent to each other on the same subnet.

不可追踪的IPv6地址的主要目标是创建一个表面上无定形的网络基础设施(从外部网络看),以保护本地基础设施免受恶意外部影响,并防止多个设备的网络活动与外部网络之间的任何关联映射。当使用不可跟踪的IPv6地址时,可能会将两个明显顺序的地址分配给本地网络中非常不同部分上的设备,而不是属于同一子网上彼此相邻的设备。

Since IPv6 addresses will not be in short supply even within a single /64 (or shorter) prefix, it is possible to generate them effectively at random when untraceability is required. They will be globally routable IPv6 addresses under the site's prefix, which can be

由于IPv6地址即使在单个/64(或更短)前缀内也不会短缺,因此在需要不可追踪性时,可以有效地随机生成它们。它们将是站点前缀下的全局可路由IPv6地址,该前缀可以是

randomly and independently assigned to IPv6 devices. The random assignment is intended to mislead the outside world about the structure of the local network. In particular, the subnet structure may be invisible in the address. Thus, a flat routing mechanism will be needed within the site. The local routers need to maintain a correlation between the topological location of the device and the untraceable IPv6 address. For smaller deployments, this correlation could be done by generating IPv6 host route entries, or for larger ones by utilizing an indirection device such as a Mobile IPv6 Home Agent. Additional details are in Section 4.7.

随机且独立地分配给IPv6设备。随机分配的目的是在本地网络的结构上误导外界。特别是,子网结构可能在地址中不可见。因此,站点内需要一个平面路由机制。本地路由器需要在设备的拓扑位置和不可追踪的IPv6地址之间保持关联。对于较小的部署,这种关联可以通过生成IPv6主机路由条目来实现,对于较大的部署,可以通过使用间接设备(如移动IPv6 Home Agent)来实现。更多详情见第4.7节。

4. Using IPv6 Technology to Provide the Market Perceived Benefits of NAT

4. 使用IPv6技术提供NAT的市场感知好处

The facilities in IPv6 described in Section 3 can be used to provide the protection perceived to be associated with IPv4 NAT. This section gives some examples of how IPv6 can be used securely.

第3节中描述的IPv6中的设施可用于提供与IPv4 NAT相关联的保护。本节给出了如何安全使用IPv6的一些示例。

4.1. Simple Gateway between Internet and Internal Network
4.1. Internet和内部网络之间的简单网关

As a simple gateway, the device manages both packet routing and local address management. A basic IPv6 router should have a default configuration to advertise inside the site a locally generated random ULA prefix, independently from the state of any external connectivity. This would allow local nodes in a topology more complex than a single link to communicate amongst themselves independent of the state of a global connection. If the network happened to concatenate with another local network, the randomness in ULA creation is highly unlikely to result in address collisions.

作为一个简单的网关,该设备同时管理数据包路由和本地地址管理。基本IPv6路由器应具有默认配置,以便在站点内部公布本地生成的随机ULA前缀,而不受任何外部连接状态的影响。这将允许比单个链路更复杂的拓扑中的本地节点独立于全局连接的状态在它们之间进行通信。如果该网络碰巧与另一个本地网络连接,则ULA创建中的随机性极不可能导致地址冲突。

With external connectivity, the simple gateway should use DHCP-PD to acquire a routing prefix from the service provider for use when connecting to the global Internet. End-system connections involving other nodes on the global Internet that follow the policy table in RFC 3484 will always use the global IPv6 addresses derived from this prefix delegation. It should be noted that the address selection policy table should be configured to prefer the ULA prefix range over the DHCP-PD prefix range when the goal is to keep local communications stable during periods of transient external connectivity.

通过外部连接,简单网关应使用DHCP-PD从服务提供商处获取路由前缀,以便在连接到全球互联网时使用。涉及全局Internet上遵循RFC 3484中策略表的其他节点的终端系统连接将始终使用从此前缀委派派生的全局IPv6地址。应注意,当目标是在瞬时外部连接期间保持本地通信稳定时,应将地址选择策略表配置为更喜欢ULA前缀范围而不是DHCP-PD前缀范围。

In the very simple case, there is no explicit routing protocol on either side of the gateway, and a single default route is used internally pointing out to the global Internet. A slightly more complex case might involve local internal routing protocols, but with the entire local network sharing a common global prefix there would

在非常简单的情况下,网关两侧都没有明确的路由协议,在内部使用一条默认路由指向全球互联网。稍微复杂一点的情况可能涉及本地内部路由协议,但如果整个本地网络共享一个通用的全局前缀,则可能会出现这种情况

still not be a need for an external routing protocol as the service provider could install a route for the prefix delegated via DHCP-PD pointing toward the connecting link.

仍然不需要外部路由协议,因为服务提供商可以为通过DHCP-PD委托的指向连接链路的前缀安装路由。

4.2. IPv6 and Simple Security
4.2. IPv6与简单安全

The vulnerability of an IPv6 host directly connected to the Internet is similar to that of an IPv4 host. The use of firewalls and Intrusion Detection Systems (IDSs) is recommended for those that want boundary protection in addition to host defenses. A proxy may be used for certain applications, but with the caveat that the end-to-end transparency is broken. However, with IPv6, the following protections are available without the use of NAT while maintaining end-to-end reachability:

直接连接到Internet的IPv6主机的漏洞类似于IPv4主机的漏洞。除了主机防御之外,对于那些需要边界保护的人,建议使用防火墙和入侵检测系统(IDSs)。代理可以用于某些应用程序,但需要注意的是,端到端的透明度已被破坏。但是,在IPv6中,在不使用NAT的情况下可以提供以下保护,同时保持端到端的可达性:

1. Short lifetimes on privacy extension suffixes reduce the attack profile since the node will not respond to the address once its lifetime becomes invalid.

1. 隐私扩展后缀的短生存期会减少攻击模式,因为一旦地址的生存期变为无效,节点将不会响应该地址。

2. IP security (IPsec) is often cited as the reason for improved security because it is a mandatory service for IPv6 implementations. Broader availability does not by itself improve security because its use is still regulated by the availability of a key infrastructure. IPsec functions to authenticate the correspondent, prevent session hijacking, prevent content tampering, and optionally mask the packet contents. While IPsec is commonly available in some IPv4 implementations and with extensions can support NAT traversals, NAT support has limitations and does not work in all situations. The use of IPsec with NATs requires an additional UDP encapsulation and keepalive overhead [13]. In the IPv4/NAT environment, the usage of IPsec has been largely limited to edge-to-edge Virtual Private Network (VPN) deployments. The potential for end-to-end IPsec use is significantly enhanced when NAT is removed from the network, as connections can be initiated from either end. It should be noted that encrypted IPsec traffic will bypass content-aware firewalls, which is presumed to be acceptable for parties with whom the site has established a security association.

2. IP安全性(IPsec)经常被认为是提高安全性的原因,因为它是IPv6实现的一项强制性服务。更广泛的可用性本身并不能提高安全性,因为它的使用仍然受到关键基础设施可用性的管制。IPsec功能用于验证通信方、防止会话劫持、防止内容篡改,以及选择性地屏蔽数据包内容。虽然IPsec通常在某些IPv4实现中可用,并且其扩展可以支持NAT遍历,但NAT支持有局限性,并且不能在所有情况下都起作用。在NAT中使用IPsec需要额外的UDP封装和keepalive开销[13]。在IPv4/NAT环境中,IPsec的使用主要局限于边缘到边缘虚拟专用网络(VPN)部署。当NAT从网络中移除时,端到端IPsec使用的可能性会显著增强,因为连接可以从任意一端启动。应该注意的是,加密的IPsec通信将绕过内容感知防火墙,这被认为是站点与之建立安全关联的各方可以接受的。

3. The size of the address space of a typical subnet (64 bits of IID) will make a complete subnet ping sweep usually significantly harder and more expensive than for IPv4 [20]. Reducing the security threat of port scans on identified nodes requires sparse distribution within the subnet to minimize the probability of scans finding adjacent nodes. This scanning protection will be nullified if IIDs are configured in any structured groupings within the IID space. Provided that IIDs are essentially randomly distributed across the available space, address

3. 典型子网的地址空间大小(IID的64位)将使完整的子网ping扫描通常比IPv4更困难、更昂贵[20]。要降低已识别节点上端口扫描的安全威胁,需要在子网内进行稀疏分布,以最小化扫描找到相邻节点的概率。如果在IID空间内的任何结构化分组中配置IID,则此扫描保护将无效。如果IID基本上是随机分布在可用空间中,地址

scanning-based attacks will effectively fail. This protection exists if the attacker has no direct access to the specific subnet and therefore is trying to scan it remotely. If an attacker has local access, then he could use Neighbor Discovery (ND) [3] and ping6 to the link-scope multicast ff02::1 to detect the IEEE-based address of local neighbors, then apply the global prefix to those to simplify its search (of course, a locally connected attacker has many scanning options with IPv4 as well).

基于扫描的攻击将有效地失败。如果攻击者无法直接访问特定子网,因此试图远程扫描该子网,则存在此保护。如果攻击者具有本地访问权限,那么他可以使用邻居发现(ND)[3]和ping6对链接作用域多播ff02::1检测本地邻居基于IEEE的地址,然后对这些地址应用全局前缀以简化搜索(当然,本地连接的攻击者也有许多IPv4扫描选项)。

Assuming the network administrator is aware of [20] the increased size of the IPv6 address will make topology probing much harder, and almost impossible for IPv6 devices. The intention of topology probing is to identify a selection of the available hosts inside an enterprise. This mostly starts with a ping sweep. Since the IPv6 subnets are 64 bits worth of address space, this means that an attacker has to simply send out an unrealistic number of pings to map the network, and virus/worm propagation will be thwarted in the process. At full-rate full-duplex 40 Gbps (400 times the typical 100 Mbps LAN, and 13,000 times the typical DSL/cable access link), it takes over 5,000 years to scan the entirety of a single 64-bit subnet.

假设网络管理员意识到[20]IPv6地址的增加将使拓扑探测变得更加困难,而且IPv6设备几乎不可能进行拓扑探测。拓扑探测的目的是确定企业内部可用主机的选择。这主要是从ping扫描开始的。由于IPv6子网的地址空间为64位,这意味着攻击者只需发送不切实际的ping数即可映射网络,在此过程中病毒/蠕虫传播将受阻。在全速全双工40 Gbps(400倍于典型的100 Mbps LAN,13000倍于典型的DSL/电缆接入链路)下,扫描单个64位子网需要5000多年的时间。

IPv4 NAT was not developed as a security mechanism. Despite marketing messages to the contrary, it is not a security mechanism, and hence it will offer some security holes while many people assume their network is secure due to the usage of NAT. IPv6 security best practices will avoid this kind of illusory security, but can only address the same threats if correctly configured firewalls and IDSs are used at the perimeter.

IPv4 NAT不是作为安全机制开发的。尽管营销信息与此相反,但它不是一种安全机制,因此它会提供一些安全漏洞,而许多人认为由于使用NAT,他们的网络是安全的。IPv6安全最佳实践将避免这种虚幻的安全性,但只有在周边使用正确配置的防火墙和IDS时,才能解决相同的威胁。

It must be noted that even a firewall doesn't fully secure a network. Many attacks come from inside or are at a layer higher than the firewall can protect against. In the final analysis, every system has to be responsible for its own security, and every process running on a system has to be robust in the face of challenges like stack overflows, etc. What a firewall does is prevent a network administration from having to carry unauthorized traffic, and in so doing reduce the probability of certain kinds of attacks across the protected boundary.

必须注意的是,即使是防火墙也不能完全保护网络。许多攻击来自内部或位于防火墙无法防御的更高层。归根结底,每个系统都必须对自己的安全负责,系统上运行的每个进程都必须在堆栈溢出等挑战面前保持健壮。防火墙所做的是防止网络管理部门携带未经授权的流量,这样做可以降低某些类型的攻击跨越受保护边界的概率。

To implement simple security for IPv6 in, for example, a DSL or cable modem-connected home network, the broadband gateway/router should be equipped with stateful firewall capabilities. These should provide a default configuration where incoming traffic is limited to return traffic resulting from outgoing packets (sometimes known as reflective session state). There should also be an easy interface that allows users to create inbound 'pinholes' for specific purposes such as online gaming.

为了在例如DSL或电缆调制解调器连接的家庭网络中实现简单的IPv6安全,宽带网关/路由器应配备有状态防火墙功能。这些应该提供一个默认配置,其中传入流量被限制为由传出数据包(有时称为反射会话状态)产生的返回流量。还应该有一个简单的界面,允许用户为在线游戏等特定目的创建入站“针孔”。

Administrators and the designers of configuration interfaces for simple IPv6 firewalls need to provide a means of documenting the security caveats that arise from a given set of configuration rules so that users (who are normally oblivious to such things) can be made aware of the risks. As rules are improved iteratively, the goal will be to make use of the IPv6 Internet more secure without increasing the perceived complexity for users who just want to accomplish a task.

简单IPv6防火墙配置界面的管理员和设计者需要提供一种记录由给定的一组配置规则引起的安全警告的方法,以便让用户(通常不知道这些事情的用户)意识到风险。随着规则的不断改进,我们的目标将是在不增加只想完成任务的用户感知的复杂性的情况下,使IPv6互联网的使用更加安全。

4.3. User/Application Tracking
4.3. 用户/应用程序跟踪

IPv6 enables the collection of information about data flows. Because all addresses used for Internet and intra-/inter-site communication are unique, it is possible for an enterprise or ISP to get very detailed information on any communication exchange between two or more devices. Unless privacy addresses [7] are in use, this enhances the capability of data-flow tracking for security audits compared with IPv4 NAT, because in IPv6 a flow between a sender and receiver will always be uniquely identified due to the unique IPv6 source and destination addresses.

IPv6允许收集有关数据流的信息。由于用于Internet和站点内/站点间通信的所有地址都是唯一的,因此企业或ISP可以获得有关两个或多个设备之间任何通信交换的非常详细的信息。除非使用隐私地址[7],否则与IPv4 NAT相比,这将增强安全审计的数据流跟踪能力,因为在IPv6中,由于唯一的IPv6源地址和目标地址,发送方和接收方之间的流将始终被唯一标识。

At the same time, this tracking is per address. In environments where the goal is tracking back to the user, additional external information will be necessary correlating a user with an address. In the case of short-lifetime privacy address usage, this external information will need to be based on more stable information such as the layer 2 media address.

同时,此跟踪是按地址进行的。在目标是回溯到用户的环境中,将用户与地址关联起来需要额外的外部信息。在短生命周期隐私地址使用的情况下,此外部信息需要基于更稳定的信息,如第2层媒体地址。

4.4. Privacy and Topology Hiding Using IPv6
4.4. 使用IPv6的隐私和拓扑隐藏

Partial host privacy is achieved in IPv6 using RFC 3041 pseudo-random privacy addresses [7] which are generated as required, so that a session can use an address that is valid only for a limited time. This only allows such a session to be traced back to the subnet that originates it, but not immediately to the actual host, where IPv4 NAT is only traceable to the most public NAT interface.

IPv6使用RFC 3041伪随机隐私地址[7]实现部分主机隐私,该地址根据需要生成,因此会话可以使用仅在有限时间内有效的地址。这只允许将此类会话追溯到发起它的子网,而不是立即追溯到实际主机,其中IPv4 NAT只能追溯到最公共的NAT接口。

Due to the large IPv6 address space available, there is plenty of freedom to randomize subnet allocations. By doing this, it is possible to reduce the correlation between a subnet and its location. When doing both subnet and IID randomization, a casual snooper won't be able to deduce much about the network's topology. The obtaining of a single address will tell the snooper very little about other addresses. This is different from IPv4 where address space limitations cause this not to be true. In most usage cases, this concept should be sufficient for address privacy and topology hiding, with the cost being a more complex internal routing configuration.

由于IPv6地址空间很大,因此可以自由地随机分配子网。通过这样做,可以降低子网与其位置之间的相关性。当同时进行子网和IID随机化时,一个不经意的窥探者将无法推断出网络的拓扑结构。获得一个地址将告诉窥探者关于其他地址的信息很少。这与IPv4不同,IPv4中的地址空间限制导致情况并非如此。在大多数使用情况下,这个概念对于地址隐私和拓扑隐藏应该足够了,代价是更复杂的内部路由配置。

As discussed in Section 3.1, there are multiple parts to the IPv6 address, and different techniques to manage privacy for each which may be combined to protect the entire address. In the case where a network administrator wishes to fully isolate the internal IPv6 topology, and the majority of its internal use addresses, one option is to run all internal traffic using Unique Local Addresses (ULAs). By definition, this prefix block is not to be advertised in the public routing system, so without a routing path external traffic will never reach the site. For the set of hosts that do in fact need to interact externally, by using multiple IPv6 prefixes (ULAs and one or more global addresses) all of the internal nodes that do not need external connectivity, and the internally used addresses of those that do, will be masked from the outside. The policy table defined in [11] provides a mechanism to bias the selection process when multiple prefixes are in use such that the ULA would be preferred when the correspondent is also local.

如第3.1节所述,IPv6地址有多个部分,以及管理每个部分隐私的不同技术,这些技术可以组合起来保护整个地址。如果网络管理员希望完全隔离内部IPv6拓扑及其大部分内部使用地址,一个选项是使用唯一本地地址(ULA)运行所有内部通信。根据定义,此前缀块不会在公共路由系统中公布,因此如果没有路由路径,外部流量将永远不会到达站点。对于实际上需要外部交互的主机集,通过使用多个IPv6前缀(ULA和一个或多个全局地址),所有不需要外部连接的内部节点以及需要外部连接的内部使用的地址都将从外部屏蔽。[11]中定义的策略表提供了一种机制,在使用多个前缀时使选择过程产生偏差,从而在对应方也是本地的情况下,首选ULA。

There are other scenarios for the extreme situation when a network manager also wishes to fully conceal the internal IPv6 topology. In these cases, the goal in replacing the IPv4 NAT approach is to make all of the topology hidden nodes appear from the outside to logically exist at the edge of the network, just as they would when behind a NAT. This figure shows the relationship between the logical subnets and the topology masking router discussed in the bullet points that follow.

当网络管理器还希望完全隐藏内部IPv6拓扑时,还有其他极端情况的场景。在这些情况下,替换IPv4 NAT方法的目标是使所有拓扑隐藏节点从外部显示为逻辑上存在于网络边缘,就像它们在NAT后面一样。此图显示了逻辑子网和拓扑屏蔽路由器之间的关系,这些关系在下面的要点中进行了讨论。

                             Internet
                                 |
                                 \
                                 |
                       +------------------+
                       |     topology     |-+-+-+-+-+-+-+-+--
                       |     masking      |  Logical subnets
                       |     router       |-+-+-+-+-+-+-+-+--
                       +------------------+  for topology
                                 |           hidden nodes
                                 |
               Real internal  -------------+-
               topology       |            |
                              |           -+----------
                   -----------+--------+
                                       |
                                       |
                                       |
        
                             Internet
                                 |
                                 \
                                 |
                       +------------------+
                       |     topology     |-+-+-+-+-+-+-+-+--
                       |     masking      |  Logical subnets
                       |     router       |-+-+-+-+-+-+-+-+--
                       +------------------+  for topology
                                 |           hidden nodes
                                 |
               Real internal  -------------+-
               topology       |            |
                              |           -+----------
                   -----------+--------+
                                       |
                                       |
                                       |
        

o One approach uses explicit host routes in the Interior Gateway Protocol (IGP) to remove the external correlation between physical topology attachment point and end-to-end IPv6 address. In the figure above the hosts would be allocated prefixes from one or more logical subnets, and would inject host routes into the IGP to internally identify their real attachment point. This solution does however show severe scalability issues and requires hosts to securely participate in the IGP, as well as have the firewall block all external to internal traceroutes for the logical subnet. The specific limitations are dependent on the IGP protocol, the physical topology, and the stability of the system. In any case, the approach should be limited to uses with substantially fewer than the maximum number of routes that the IGP can support (generally between 5,000 and 50,000 total entries including subnet routes). Hosts should also listen to the IGP for duplicate use before finalizing an interface address assignment as the duplicate address detection will only check for use on the attached segment, not the logical subnet.

o 一种方法是在内部网关协议(IGP)中使用显式主机路由来消除物理拓扑连接点和端到端IPv6地址之间的外部关联。在上图中,主机将从一个或多个逻辑子网分配前缀,并将主机路由注入IGP以在内部识别其真实连接点。但是,此解决方案确实存在严重的可扩展性问题,要求主机安全地参与IGP,并让防火墙阻止逻辑子网的所有外部到内部跟踪路由。具体限制取决于IGP协议、物理拓扑和系统稳定性。在任何情况下,该方法应限于使用大大少于IGP可支持的最大路由数(通常在5000到50000个总条目之间,包括子网路由)。在完成接口地址分配之前,主机还应侦听IGP的重复使用情况,因为重复地址检测将仅检查连接段上的使用情况,而不是逻辑子网上的使用情况。

o Another technical approach to fully hide the internal topology is use of a tunneling mechanism. Mobile IPv6 without route optimization is one approach for using an automated tunnel, as it always starts in tunnel mode via the Home Agent (HA). In this deployment model, the application perceived addresses of the nodes are routed via the edge HA acting as the topology masking router (above). This indirection method truly masks the internal topology, as from outside the local network all nodes with global access appear to share the prefix of one or more logical subnets attached to the HA rather than their real attachment point. Note that in this usage context, the HA is replacing the NAT function at the edge of the network, so concerns about additional latency for routing through a tunnel to the HA do not apply because it is effectively on the same path that the NAT traffic would have taken. Duplicate address detection is handled as a normal process of the HA binding update. While turning off all binding updates with the correspondent node would appear to be necessary to prevent leakage of topology information, that approach would also force all internal traffic using the home address to route via the HA tunnel, which may be undesirable. A more efficient method would be to allow internal route optimizations while dropping outbound binding update messages at the firewall. Another approach for the internal traffic would be to use the policy table of RFC 3484 to bias a ULA prefix as preferred internally, leaving the logical subnet Home Address external for use. The downside to a Mobile IPv6-based solution is that it requires a Home Agent in the network and the configuration of a security association with the HA for each hidden node, and it consumes some amount of bandwidth for tunnel overhead.

o 另一种完全隐藏内部拓扑的技术方法是使用隧道机制。无路由优化的移动IPv6是使用自动隧道的一种方法,因为它总是通过归属代理(HA)以隧道模式启动。在此部署模型中,节点的应用感知地址通过充当拓扑屏蔽路由器的边缘HA进行路由(如上)。这种间接方法真正屏蔽了内部拓扑,因为从本地网络外部来看,所有具有全局访问权限的节点似乎共享连接到HA的一个或多个逻辑子网的前缀,而不是它们的实际连接点。请注意,在此使用上下文中,HA正在网络边缘替换NAT功能,因此对通过隧道路由到HA的额外延迟的担忧不适用,因为它实际上位于NAT流量将采用的相同路径上。重复地址检测作为HA绑定更新的正常过程处理。虽然关闭与对应节点的所有绑定更新似乎是防止拓扑信息泄漏所必需的,但该方法还将强制使用归属地址的所有内部通信通过HA隧道路由,这可能是不需要的。更有效的方法是允许内部路由优化,同时在防火墙上删除出站绑定更新消息。内部通信量的另一种方法是使用RFC 3484的策略表在内部将ULA前缀作为首选,将逻辑子网主地址保留在外部以供使用。基于移动IPv6的解决方案的缺点是,它需要在网络中设置一个归属代理,并为每个隐藏节点配置与HA的安全关联,并且它会为隧道开销消耗一定的带宽。

o Another method (where the layer 2 topology allows) uses a virtual LAN approach to logically attach the devices to one or more subnets on the edge router. This approach leads the end nodes to believe they actually share a common segment. The downside of this approach is that all internal traffic would be directed over suboptimal paths via the edge router, as well as the complexity of managing a distributed logical LAN.

o 另一种方法(在第2层拓扑允许的情况下)使用虚拟LAN方法将设备逻辑连接到边缘路由器上的一个或多个子网。这种方法使终端节点相信它们实际上共享一个公共段。这种方法的缺点是,所有内部流量都将通过边缘路由器定向到次优路径上,并且管理分布式逻辑LAN非常复杂。

One issue to be aware of is that subnet scope multicast will not work for the logical hidden subnets, except in the VLAN case. While a limited scope multicast to a collection of nodes that are arbitrarily scattered makes no technical sense, care should be exercised to avoid deploying applications that expect limited scope multicast in conjunction with topology hiding.

需要注意的一个问题是,子网范围多播将不适用于逻辑隐藏子网,VLAN情况除外。虽然对任意分散的节点集合进行有限范围多播在技术上没有意义,但应注意避免部署期望有限范围多播与拓扑隐藏结合使用的应用程序。

Another issue that this document will not define is the mechanism for a topology hidden node to learn its logical subnet. While manual configuration would clearly be sufficient, DHCP could be used for address assignment, with the recipient node discovering it is in a hidden mode when the attached subnet prefix doesn't match the one assigned.

本文档将不定义的另一个问题是拓扑隐藏节点了解其逻辑子网的机制。虽然手动配置显然就足够了,但DHCP可用于地址分配,当连接的子网前缀与分配的子网前缀不匹配时,接收方节点会发现它处于隐藏模式。

4.5. Independent Control of Addressing in a Private Network
4.5. 专用网络中寻址的独立控制

IPv6 provides for autonomy in local use addresses through ULAs. At the same time, IPv6 simplifies simultaneous use of multiple addresses per interface so that an IPv6 NAT is not required between the ULA and the public Internet because nodes that need access to the public Internet will have a global use address as well. When using IPv6, the need to ask for more address space will become far less likely due to the increased size of the subnets, along with an allocation policy that recognizes that table fragmentation is also an important consideration. While global IPv6 allocation policy is managed through the Regional Internet Registries (RIRs), it is expected that they will continue with derivatives of [8] for the foreseeable future so the number of subnet prefixes available to an organization should not be a limitation that would create an artificial demand for NAT.

IPv6通过ULA在本地使用地址中提供自治。同时,IPv6简化了每个接口多个地址的同时使用,因此ULA和公共互联网之间不需要IPv6 NAT,因为需要访问公共互联网的节点也将具有全局使用地址。在使用IPv6时,由于子网规模的增加,以及认识到表碎片也是一个重要考虑因素的分配策略,请求更多地址空间的可能性将大大降低。虽然全球IPv6分配策略通过区域互联网注册中心(RIR)进行管理,但预计在可预见的未来,它们将继续使用[8]的衍生产品,因此组织可用的子网前缀数量不应成为一个限制,这将造成对NAT的人为需求。

Ongoing subnet address maintenance may become simpler when IPv6 technology is utilized. Under IPv4 address space policy restrictions, each subnet must be optimized, so one has to look periodically into the number of hosts on a segment and the subnet size allocated to the segment and rebalance. For example, an enterprise today may have a mix of IPv4 /28 - /23 size subnets, and may shrink/grow these as its network user base changes. For IPv6, all subnets have /64 prefixes, which will reduce the operational and configuration overhead.

使用IPv6技术时,正在进行的子网地址维护可能会变得更简单。在IPv4地址空间策略限制下,每个子网都必须进行优化,因此必须定期查看段上的主机数量以及分配给该段的子网大小并重新平衡。例如,今天的企业可能混合了IPv4/28-/23大小的子网,并且可能随着其网络用户群的变化而收缩/增长这些子网。对于IPv6,所有子网都有/64前缀,这将减少操作和配置开销。

4.6. Global Address Pool Conservation
4.6. 全局地址池保护

IPv6 provides sufficient space to completely avoid the need for overlapping address space. Since allocations in IPv6 are based on subnets rather than hosts, a reasonable way to look at the pool is that there are about 17*10^18 unique subnet values where sparse allocation practice within those provides for new opportunities such as SEcure Neighbor Discovery (SEND) [15]. As previously discussed, the serious disadvantages of ambiguous address space have been well documented, and with sufficient space there is no need to continue the increasingly aggressive conservation practices that are necessary with IPv4. While IPv6 allocation policies and ISP business practice will continue to evolve, the recommendations in RFC 3177 are based on the technical potential of the vast IPv6 address space. That document demonstrates that there is no resource limitation that will require the adoption of the IPv4 workaround of ambiguous space behind a NAT. As an example of the direct contrast, many expansion-oriented IPv6 deployment scenarios result in multiple IPv6 addresses per device, as opposed to the constriction of IPv4 scenarios where multiple devices are forced to share a scarce global address through a NAT.

IPv6提供了足够的空间,完全避免了重叠地址空间的需要。由于IPv6中的分配基于子网而非主机,因此查看池的一种合理方式是,有大约17*10^18个唯一子网值,其中这些子网中的稀疏分配实践提供了新的机会,例如安全邻居发现(SEND)[15]。正如前面所讨论的,含糊不清的地址空间的严重缺点已经得到了很好的证明,有了足够的空间,就没有必要继续进行IPv4所必需的日益激进的保护实践。虽然IPv6分配政策和ISP业务实践将继续发展,但RFC 3177中的建议基于巨大IPv6地址空间的技术潜力。该文档表明,不存在需要采用IPv4解决NAT后面不明确空间的资源限制。作为直接对比的一个示例,许多面向扩展的IPv6部署场景会导致每个设备具有多个IPv6地址,而IPv4场景的限制则相反,在IPv4场景中,多个设备被迫通过NAT共享一个稀缺的全局地址。

4.7. Multihoming and Renumbering
4.7. 多归宿和重新编号

IPv6 was designed to allow sites and hosts to run with several simultaneous CIDR-allocated prefixes, and thus with several simultaneous ISPs. An address selection mechanism [11] is specified so that hosts will behave consistently when several addresses are simultaneously valid. The fundamental difficulty that IPv4 has in regard to multiple addresses therefore does not apply to IPv6. IPv6 sites can and do run today with multiple ISPs active, and the processes for adding, removing, and renumbering active prefixes at a site have been documented in [16] and [21]. However, multihoming and renumbering remain technically challenging even with IPv6 with regards to session continuity across multihoming events or interactions with ingress filtering (see the Gap Analysis below).

IPv6的设计目的是允许站点和主机同时运行多个CIDR分配的前缀,从而同时运行多个ISP。指定了地址选择机制[11],以便当多个地址同时有效时,主机的行为一致。因此,IPv4在多个地址方面的根本困难不适用于IPv6。IPv6站点现在可以并且确实在多个ISP处于活动状态的情况下运行,站点上添加、删除和重新编号活动前缀的过程已在[16]和[21]中进行了说明。然而,即使使用IPv6,在多主事件的会话连续性或与入口过滤的交互方面,多主和重新编号在技术上仍然具有挑战性(请参见下面的差距分析)。

The IPv6 address space allocated by the ISP will be dependent upon the connecting service provider. This will likely result in a renumbering effort when the network changes between service providers. When changing ISPs or ISPs readjust their addressing pool, DHCP-PD [12] can be used as an almost zero-touch external mechanism for prefix change in conjunction with a ULA prefix for internal connection stability. With appropriate management of the lifetime values and overlap of the external prefixes, a smooth make-before-break transition is possible as existing communications will continue on the old prefix as long as it remains valid, while any new communications will use the new prefix.

ISP分配的IPv6地址空间将取决于连接的服务提供商。当服务提供商之间的网络发生变化时,这可能会导致重新编号。当更改ISP或ISP重新调整其寻址池时,DHCP-PD[12]可作为前缀更改的几乎零接触外部机制,与ULA前缀一起用于内部连接稳定性。通过对生存期值的适当管理和外部前缀的重叠,可以实现平滑的先通后断转换,因为只要旧前缀保持有效,现有通信将继续使用旧前缀,而任何新通信都将使用新前缀。

5. Case Studies
5. 案例研究

In presenting these case studies, we have chosen to consider categories of networks divided first according to their function either as carrier/ISP networks or end user (such as enterprise) networks with the latter category broken down according to the number of connected end hosts. For each category of networks, we can use IPv6 Local Network Protection to achieve a secure and flexible infrastructure, which provides an enhanced network functionality in comparison with the usage of address translation.

在提出这些案例研究中,我们选择考虑网络的类别,根据其功能首先划分为载波/ ISP网络或终端用户(如企业)网络,后者根据连接的终端主机的数量来分解。对于每种类型的网络,我们都可以使用IPv6本地网络保护来实现安全灵活的基础设施,与使用地址转换相比,它提供了增强的网络功能。

o Medium/Large Private Networks (typically >10 connections)

o 中型/大型专用网络(通常>10个连接)

o Small Private Networks (typically 1 to 10 connections)

o 小型专用网络(通常为1到10个连接)

o Single User Connection (typically 1 connection)

o 单用户连接(通常为1个连接)

o ISP/Carrier Customer Networks

o ISP/运营商客户网络

5.1. Medium/Large Private Networks
5.1. 中型/大型专用网络

The majority of private enterprise, academic, research, or government networks fall into this category. Many of these networks have one or more exit points to the Internet. Though these organizations have sufficient resources to acquire addressing independence when using IPv4, there are several reasons why they might choose to use NAT in such a network. For the ISP, there is no need to import the IPv4 address range from the remote end-customer, which facilitates IPv4 route summarization. The customer can use a larger IPv4 address range (probably with less administrative overhead) by the use of RFC 1918 and NAT. The customer also reduces the overhead in changing to a new ISP, because the addresses assigned to devices behind the NAT do not need to be changed when the customer is assigned a different address by a new ISP. By using address translation in IPv4, one avoids the expensive process of network renumbering. Finally, the customer can provide privacy for its hosts and the topology of its internal network if the internal addresses are mapped through NAT.

大多数私营企业、学术、研究或政府网络都属于这一类。其中许多网络都有一个或多个到Internet的出口点。尽管这些组织有足够的资源在使用IPv4时获得寻址独立性,但他们可能会选择在这样的网络中使用NAT有几个原因。对于ISP,不需要从远程终端客户导入IPv4地址范围,这有助于IPv4路由摘要。通过使用RFC1918和NAT,客户可以使用更大的IPv4地址范围(可能具有更少的管理开销)。客户还可以减少更换新ISP的开销,因为当新ISP为客户分配不同的地址时,分配给NAT后面设备的地址不需要更改。通过在IPv4中使用地址转换,可以避免昂贵的网络重新编号过程。最后,如果内部地址通过NAT映射,客户可以为其主机和内部网络拓扑提供隐私。

It is expected that there will be enough IPv6 addresses available for all networks and appliances for the foreseeable future. The basic IPv6 address range an ISP allocates for a private network is large enough (currently /48) for most of the medium and large enterprises, while for the very large private enterprise networks address ranges can be concatenated. The goal of this assignment mechanism is to decrease the total amount of entries in the public Internet routing table. A single /48 allocation provides an enterprise network with 65,536 different /64 subnet prefixes.

预计在可预见的未来,将有足够的IPv6地址可用于所有网络和设备。ISP为专用网络分配的基本IPv6地址范围对于大多数中型和大型企业来说足够大(目前为/48),而对于非常大的专用企业网络,地址范围可以连接起来。此分配机制的目标是减少公共Internet路由表中的条目总数。单个/48分配为企业网络提供65536个不同/64子网前缀。

To mask the identity of a user on a network of this type, the usage of IPv6 privacy extensions may be advised. This technique is useful when an external element wants to track and collect all information sent and received by a certain host with a known IPv6 address. Privacy extensions add a random time-limited factor to the host part of an IPv6 address and will make it very hard for an external element to keep correlating the IPv6 address to a specific host on the inside network. The usage of IPv6 privacy extensions does not mask the internal network structure of an enterprise network.

要在此类网络上屏蔽用户的身份,建议使用IPv6隐私扩展。当外部元素希望跟踪和收集由具有已知IPv6地址的特定主机发送和接收的所有信息时,此技术非常有用。隐私扩展为IPv6地址的主机部分添加了一个随机的时间限制因素,使得外部元素很难将IPv6地址与内部网络上的特定主机保持关联。IPv6隐私扩展的使用不会掩盖企业网络的内部网络结构。

When there is a need to mask the internal structure towards the external IPv6 Internet, then some form of 'untraceable' addresses may be used. These addresses will appear to exist at the external edge of the network, and may be assigned to those hosts for which topology masking is required or that want to reach the IPv6 Internet or other external networks. The technology to assign these addresses to the hosts could be based on DHCPv6 or static configuration. To complement the 'Untraceable' addresses, it is necessary to have at least awareness of the IPv6 address location when routing an IPv6 packet through the internal network. This could be achieved by 'host based route-injection' in the local network infrastructure. This route-injection could be done based on /128 host-routes to each device that wants to connect to the Internet using an untraceable address. This will provide the most dynamic masking, but will have a scalability limitation, as an IGP is typically not designed to carry many thousands of IPv6 prefixes. A large enterprise may have thousands of hosts willing to connect to the Internet.

当需要屏蔽外部IPv6 Internet的内部结构时,可能会使用某种形式的“不可追踪”地址。这些地址似乎存在于网络的外部边缘,并且可能被分配给需要拓扑屏蔽的主机或希望到达IPv6 Internet或其他外部网络的主机。将这些地址分配给主机的技术可以基于DHCPv6或静态配置。为了补充“不可追踪”地址,在通过内部网络路由IPv6数据包时,必须至少了解IPv6地址位置。这可以通过本地网络基础设施中的“基于主机的路由注入”实现。这种路由注入可以基于/128个主机路由来完成,这些主机路由到每个希望使用不可追踪地址连接到Internet的设备。这将提供最动态的屏蔽,但会有可伸缩性限制,因为IGP通常不设计为携带数千个IPv6前缀。一个大型企业可能有数千台主机愿意连接到Internet。

An alternative for larger deployments is to leverage the tunneling aspect of MIPv6 even for non-mobile devices. With the logical subnet being allocated as attached to the edge Home Agent, the real attachment and internal topology are masked from the outside. Dropping outbound binding updates at the firewall is also necessary to avoid leaking the attachment information.

大型部署的另一种选择是利用MIPv6的隧道特性,即使对于非移动设备也是如此。当逻辑子网被分配为连接到边缘归属代理时,实际的连接和内部拓扑将从外部屏蔽。为了避免附件信息泄漏,在防火墙上删除出站绑定更新也是必要的。

Less flexible masking could be to have time-based IPv6 prefixes per link or subnet. This may reduce the amount of route entries in the IGP by a significant factor, but has as a trade-off that masking is time and subnet based, which will complicate auditing systems. The dynamic allocation of 'Untraceable' addresses can also limit the IPv6 access between local and external hosts to those local hosts being authorized for this capability.

不太灵活的屏蔽可能是每个链路或子网都有基于时间的IPv6前缀。这可能会将IGP中的路由条目数量减少一个重要因素,但作为一种权衡,屏蔽是基于时间和子网的,这将使审计系统复杂化。“不可跟踪”地址的动态分配还可以将本地和外部主机之间的IPv6访问限制为授权使用此功能的本地主机。

The use of permanent ULA addresses on a site provides the benefit that even if an enterprise changes its ISP, the renumbering will only affect those devices that have a wish to connect beyond the site. Internal servers and services would not change their allocated IPv6 ULA address, and the service would remain available even during global address renumbering.

在站点上使用永久ULA地址的好处是,即使企业更改其ISP,重新编号也只会影响希望连接到站点以外的设备。内部服务器和服务不会更改其分配的IPv6 ULA地址,即使在全局地址重新编号期间,该服务也将保持可用。

5.2. Small Private Networks
5.2. 小型专用网络

Also known as SOHO (Small Office/Home Office) networks, this category describes those networks that have few routers in the topology and usually have a single network egress point. Typically, these networks:

也称为SOHO(小型办公室/家庭办公室)网络,这一类别描述了拓扑中路由器很少且通常只有一个网络出口点的网络。通常,这些网络:

o are connected via either a dial-up connection or broadband access,

o 通过拨号连接或宽带接入连接,

o don't have dedicated Network Operation Center (NOC), and

o 没有专用网络运营中心(NOC),以及

o today, typically use NAT as the cheapest available solution for connectivity and address management

o 如今,通常使用NAT作为最便宜的连接和地址管理解决方案

In most cases, the received global IPv4 prefix is not fixed over time and is too long (very often a /32 giving just a single address) to provide every node in the private network with a unique, globally usable address. Fixing either of those issues typically adds an administrative overhead for address management to the user. This category may even be limited to receiving ambiguous IPv4 addresses from the service provider based on RFC 1918. An ISP will typically pass along the higher administration cost attached to larger address blocks, or IPv4 prefixes that are static over time, due to the larger public address pool each of those requires.

在大多数情况下,接收到的全局IPv4前缀不是固定的,并且太长(通常a/32只给出一个地址),无法为专用网络中的每个节点提供唯一的、全局可用的地址。解决这两个问题通常会增加用户地址管理的管理开销。该类别甚至可能被限制为从基于RFC 1918的服务提供商接收不明确的IPv4地址。ISP通常会将更高的管理成本转嫁到更大的地址块或IPv4前缀上,这些地址块或前缀随着时间的推移是静态的,这是因为每个地址块都需要更大的公共地址池。

As a direct response to explicit charges per public address, most of this category has deployed NAPT (port demultiplexing NAT) to minimize the number of addresses in use. Unfortunately, this also limits the Internet capability of the equipment to being mainly a receiver of Internet data (client), and it makes it quite hard for the equipment to become a worldwide Internet server (HTTP, FTP, etc.) due to the stateful operation of the NAT equipment. Even when there is sufficient technical knowledge to manage the NAT to enable external access to a server, only one server can be mapped per protocol/port number per address, and then only when the address from the ISP is publicly routed. When there is an upstream NAT providing private address space to the ISP side of the private NAT, additional negotiation with the ISP will be necessary to provide an inbound mapping, if that is even possible.

作为对每个公共广播明确收费的直接响应,这类广播中的大多数都部署了NAPT(端口解复用NAT),以尽量减少使用的地址数量。不幸的是,这也限制了设备的互联网能力,使其主要成为互联网数据的接收器(客户端),并且由于NAT设备的有状态运行,使得设备很难成为全球互联网服务器(HTTP、FTP等)。即使有足够的技术知识来管理NAT以实现对服务器的外部访问,每个地址的每个协议/端口号只能映射一台服务器,并且只有当ISP的地址被公开路由时才能映射。当存在向专用NAT的ISP侧提供专用地址空间的上游NAT时,需要与ISP进行额外协商以提供入站映射(如果可能的话)。

When deploying IPv6 LNP in this environment, there are two approaches possible with respect to IPv6 addressing.

在此环境中部署IPv6 LNP时,有两种可能的IPv6寻址方法。

o DHCPv6 Prefix-Delegation (PD)

o DHCPv6前缀委派(PD)

o ISP provides a static IPv6 address range

o ISP提供了一个静态IPv6地址范围

For the DHCPv6-PD solution, a dynamic address allocation approach is chosen. By means of the enhanced DHCPv6 protocol, it is possible to have the ISP push down an IPv6 prefix range automatically towards the small private network and populate all interfaces in that small private network dynamically. This reduces the burden for administrative overhead because everything happens automatically.

对于DHCPv6 PD解决方案,选择了动态地址分配方法。通过增强的DHCPv6协议,ISP可以自动将IPv6前缀范围向下推至小型专用网络,并动态填充该小型专用网络中的所有接口。这减少了管理开销的负担,因为一切都是自动发生的。

For the static configuration, the mechanisms used could be the same as for the medium/large enterprises. Typically, the need for masking the topology will not be of high priority for these users, and the usage of IPv6 privacy extensions could be sufficient.

对于静态配置,使用的机制可能与中型/大型企业相同。通常,屏蔽拓扑的需要对于这些用户来说并不具有高优先级,使用IPv6隐私扩展就足够了。

For both alternatives, the ISP has the unrestricted capability for summarization of its RIR-allocated IPv6 prefix, while the small private network administrator has all flexibility in using the received IPv6 prefix to its advantage because it will be of sufficient size to allow all the local nodes to have a public address and full range of ports available whenever necessary.

对于这两种备选方案,ISP都可以不受限制地汇总其RIR分配的IPv6前缀,而小型专用网络管理员可以灵活地使用接收到的IPv6前缀,因为它的大小足以允许所有本地节点在必要时拥有公共地址和全部可用端口。

While a full prefix is expected to be the primary deployment model, there may be cases where the ISP provides a single IPv6 address for use on a single piece of equipment (PC, PDA, etc.). This is expected to be rare, though, because in the IPv6 world the assumption is that there is an unrestricted availability of a large amount of globally routable and unique address space. If scarcity was the motivation with IPv4 to provide RFC 1918 addresses, in this environment the ISP will not be motivated to allocate private addresses to the single user connection because there are enough global addresses available at essentially the same cost. Also, it will be likely that the single device wants to mask its identity to the called party or its attack profile over a shorter time than the life of the ISP attachment, so it will need to enable IPv6 privacy extensions. In turn, this leads to the need for a minimum allocation of a /64 prefix rather than a single address.

虽然完整前缀预计将是主要部署模式,但在某些情况下,ISP可能会提供单个IPv6地址以在单个设备(PC、PDA等)上使用。不过,这种情况预计很少见,因为在IPv6世界中,假设存在大量全球可路由和唯一地址空间的无限制可用性。如果IPv4提供RFC1918地址的动机是稀缺性,那么在这种环境中,ISP将不会被动机分配专用地址给单用户连接,因为有足够的全局地址可用,但成本基本相同。此外,单个设备可能希望在比ISP连接寿命更短的时间内向被叫方隐藏其身份或其攻击档案,因此需要启用IPv6隐私扩展。反过来,这就需要最小分配一个/64前缀,而不是一个地址。

5.3. Single User Connection
5.3. 单用户连接

This group identifies the users that are connected via a single IPv4 address and use a single piece of equipment (PC, PDA, etc.). This user may get an ambiguous IPv4 address (frequently imposed by the ISP) from the service provider that is based on RFC 1918. If

此组标识通过单个IPv4地址连接并使用单个设备(PC、PDA等)的用户。此用户可能从基于RFC 1918的服务提供商处获得不明确的IPv4地址(通常由ISP强制)。如果

ambiguous addressing is utilized, the service provider will execute NAT on the allocated IPv4 address for global Internet connectivity. This also limits the Internet capability of the equipment to being mainly a receiver of Internet data, and it makes it quite hard for the equipment to become a worldwide Internet server (HTTP, FTP, etc.) due to the stateful operation of the NAT equipment.

如果使用不明确的寻址,服务提供商将在分配的IPv4地址上执行NAT,以实现全球互联网连接。这也限制了设备的互联网能力,主要是互联网数据的接收器,并且由于NAT设备的有状态运行,使得设备很难成为全球互联网服务器(HTTP、FTP等)。

When using IPv6 LNP, this group will identify the users that are connected via a single IPv6 address and use a single piece of equipment (PC, PDA, etc.).

使用IPv6 LNP时,该组将识别通过单个IPv6地址连接并使用单个设备(PC、PDA等)的用户。

In the IPv6 world, the assumption is that there is unrestricted availability of a large amount of globally routable and unique IPv6 addresses. The ISP will not be motivated to allocate private addresses to the single user connection because he has enough global addresses available, if scarcity was the motivation with IPv4 to provide RFC 1918 addresses. If the single user wants to mask his identity, he may choose to enable IPv6 privacy extensions.

在IPv6世界中,假设存在大量全球可路由且唯一的IPv6地址的无限制可用性。如果IPv4提供RFC1918地址的动机是稀缺性,则ISP不会被激励为单用户连接分配专用地址,因为他有足够的全局地址可用。如果单个用户想要屏蔽其身份,他可以选择启用IPv6隐私扩展。

5.4. ISP/Carrier Customer Networks
5.4. ISP/运营商客户网络

This group refers to the actual service providers that are providing the IP access and transport services. They tend to have three separate IP domains that they support:

此组是指提供IP访问和传输服务的实际服务提供商。它们往往有三个各自支持的IP域:

o For the first, they fall into the medium/large private networks category (above) for their own internal networks, LANs, etc.

o 首先,它们属于中型/大型专用网络类别(上文),用于其内部网络、局域网等。

o The second is the Operations address domain, which addresses their backbone and access switches, and other hardware. This address domain is separate from the other address domains for engineering reasons as well as simplicity in managing the security of the backbone.

o 第二个是操作地址域,用于寻址其主干和访问交换机以及其他硬件。由于工程原因以及主干网安全管理的简单性,此地址域与其他地址域分开。

o The third is the IP addresses (single or blocks) that they assign to customers. These can be registered addresses (usually given to category 5.1 and 5.2 and sometimes 5.3) or can be from a pool of RFC 1918 addresses used with IPv4 NAT for single user connections. Therefore they can actually have two different NAT domains that are not connected (internal LAN and single user customers).

o 第三个是分配给客户的IP地址(单个或块)。这些地址可以是注册地址(通常为5.1和5.2类,有时为5.3类),也可以是用于单用户连接的IPv4 NAT的RFC 1918地址池。因此,它们实际上可以有两个未连接的不同NAT域(内部LAN和单用户客户)。

When IPv6 LNP is utilized in these three domains, then for the first category it will be possible to use the same solutions as described in Section 5.1. The second domain of the ISP/carrier is the Operations network. This environment tends to be a closed environment, and consequently communication can be done based on ULAs. However, in this environment, stable IPv6 Provider Independent addresses can be used. This would give a solid and scalable

在这三个域中使用IPv6 LNP时,对于第一类,可以使用第5.1节中描述的相同解决方案。ISP/运营商的第二个领域是运营网络。因此,ULAs环境往往是封闭的,因此可以基于此环境进行通信。但是,在此环境中,可以使用稳定的独立于IPv6提供程序的地址。这将提供一个可靠且可扩展的

configuration with respect to a local IPv6 address plan. By the usage of proper network edge filters, outside access to the closed environment can be avoided. The third is the IPv6 addresses that ISP/carrier network assign to customers. These will typically be assigned with prefix lengths terminating on nibble boundaries to be consistent with the DNS PTR records. As scarcity of IPv6 addresses is not a concern, it will be possible for the ISP to provide globally routable IPv6 prefixes without a requirement for address translation. An ISP may for commercial reasons still decide to restrict the capabilities of the end users by other means like traffic and/or route filtering, etc.

与本地IPv6地址计划相关的配置。通过使用适当的网络边缘过滤器,可以避免外部对封闭环境的访问。第三个是ISP/运营商网络分配给客户的IPv6地址。这些通常将被分配前缀长度,终止于半字节边界,以与DNS PTR记录一致。由于IPv6地址的稀缺性不是一个问题,ISP可以在不需要地址转换的情况下提供全局可路由的IPv6前缀。出于商业原因,ISP可能仍然决定通过其他方式(如流量和/或路由过滤等)限制最终用户的能力。

If the carrier network is a mobile provider, then IPv6 is encouraged in comparison with the combination of IPv4+NAT for Third Generation Partnership Project (3GPP)-attached devices. In Section 2.3 of RFC 3314, 'Recommendations for IPv6 in 3GPP Standards' [9], it is found that the IPv6 WG recommends that one or more /64 prefixes should be assigned to each primary Protocol Data Packet (PDP) context. This will allow sufficient address space for a 3GPP-attached node to allocate privacy addresses and/or route to a multi-link subnet, and it will discourage the use of NAT within 3GPP-attached devices.

如果运营商网络是移动提供商,那么与第三代合作伙伴关系项目(3GPP)连接设备的IPv4+NAT组合相比,IPv6是受鼓励的。在RFC 3314的第2.3节“3GPP标准中的IPv6建议”[9]中,发现IPv6工作组建议为每个主协议数据包(PDP)上下文分配一个或多个/64前缀。这将允许3GPP连接的节点有足够的地址空间来分配隐私地址和/或路由到多链路子网,并将阻止在3GPP连接的设备中使用NAT。

6. IPv6 Gap Analysis
6. IPv6差距分析

Like IPv4 and any major standards effort, IPv6 standardization work continues as deployments are ongoing. This section discusses several topics for which additional standardization, or documentation of best practice, is required to fully realize the benefits or provide optimizations when deploying LNP. From a standardization perspective, there is no obstacle to immediate deployment of the LNP approach in many scenarios, though product implementations may lag behind the standardization efforts. That said, the list below identifies additional work that should be undertaken to cover the missing scenarios.

与IPv4和任何主要标准一样,IPv6标准化工作也会随着部署的进行而继续进行。本节讨论了几个主题,在部署LNP时,需要对这些主题进行额外的标准化或最佳实践文档编制,以充分实现其好处或提供优化。从标准化的角度来看,在许多场景中,LNP方法的立即部署没有障碍,尽管产品实现可能落后于标准化工作。也就是说,下面的列表确定了为涵盖缺失场景而应开展的其他工作。

6.1. Simple Security
6.1. 简单安全

Firewall traversal by dynamic pinhole management requires further study. Several partial solutions exist including Interactive Connectivity Establishment (ICE) [23], and Universal Plug and Play (UPNP) [24]. Alternative approaches are looking to define service provider mediated pinhole management, where things like voice call signaling could dynamically establish pinholes based on predefined authentication rules. The basic security provided by a stateful firewall will require some degree of default configuration and automation to mask the technical complexity from a consumer who merely wants a secure environment with working applications. There is no reason a stateful IPv6 firewall product cannot be shipped with

通过动态针孔管理穿越防火墙需要进一步研究。存在几种部分解决方案,包括交互式连接建立(ICE)[23]和通用即插即用(UPNP)[24]。另一种方法是定义服务提供商介导的针孔管理,其中语音呼叫信令之类的东西可以基于预定义的身份验证规则动态地建立针孔。有状态防火墙提供的基本安全性将需要某种程度的默认配置和自动化,以掩盖消费者的技术复杂性,而消费者只需要一个具有工作应用程序的安全环境。没有理由不能随附有状态IPv6防火墙产品

default protection that is equal to or better than that offered by today's IPv4/NAT products.

默认保护等于或优于当今IPv4/NAT产品提供的保护。

6.2. Subnet Topology Masking
6.2. 子网拓扑屏蔽

There really is no functional standards gap here as a centrally assigned pool of addresses in combination with host routes in the IGP is an effective way to mask topology for smaller deployments. If necessary, a best practice document could be developed describing the interaction between DHCP and various IGPs that would in effect define Untraceable Addresses.

这里确实没有功能标准的差距,因为集中分配的地址池与IGP中的主机路由相结合是为较小的部署屏蔽拓扑的有效方法。如有必要,可以编写一份最佳实践文件,描述DHCP和各种IGP之间的交互,这些IGP实际上会定义不可追踪的地址。

As an alternative for larger deployments, there is no gap in the HA tunneling approach when firewalls are configured to block outbound binding update messages. A border Home Agent using internal tunneling to the logical mobile (potentially rack mounted) node can completely mask all internal topology, while avoiding the strain from a large number of host routes in the IGP. Some optimization work could be done in Mobile IP to define a policy message where a mobile node would learn from the Home Agent that it should not try to inform its correspondent about route optimization and thereby expose its real location. This optimization, which reduces the load on the firewall, would result in less optimal internal traffic routing as that would also transit the HA unless ULAs were used internally. Trade-offs for this optimization work should be investigated in the IETF.

作为大型部署的替代方案,当防火墙被配置为阻止出站绑定更新消息时,HA隧道方法中没有漏洞。使用到逻辑移动(可能安装在机架上)节点的内部隧道的border Home Agent可以完全屏蔽所有内部拓扑,同时避免IGP中大量主机路由带来的压力。可以在移动IP中进行一些优化工作,以定义一个策略消息,其中移动节点将从归属代理处了解到,它不应该试图通知其通信方路由优化,从而暴露其真实位置。这种优化减少了防火墙上的负载,将导致不太优化的内部流量路由,因为除非在内部使用ULA,否则也会传输HA。在IETF中应调查此优化工作的权衡。

6.3. Minimal Traceability of Privacy Addresses
6.3. 隐私地址的最小可追溯性

Privacy addresses [7] may certainly be used to limit the traceability of external traffic flows back to specific hosts, but lacking a topology masking component above they would still reveal the subnet address bits. For complete privacy, a best practice document describing the combination of privacy addresses and topology masking may be required. This work remains to be done and should be pursued by the IETF.

隐私地址[7]当然可以用来限制返回特定主机的外部通信流的可跟踪性,但如果上面没有拓扑屏蔽组件,它们仍然会显示子网地址位。对于完整的隐私,可能需要一份描述隐私地址和拓扑屏蔽组合的最佳实践文档。这项工作还有待完成,IETF应继续进行。

6.4. Site Multihoming
6.4. 站点多归宿

This complex problem has never been completely solved for IPv4, which is exactly why NAT has been used as a partial solution. For IPv6, after several years of work, the IETF has converged on an architectural approach intended with service restoration as initial aim [22]. When this document was drafted, the IETF was actively defining the details of this approach to the multihoming problem. The approach appears to be most suitable for small and medium sites, though it will conflict with existing firewall state procedures. At this time, there are also active discussions in the address

IPv4从未完全解决过这个复杂的问题,这正是NAT被用作部分解决方案的原因。对于IPv6,经过几年的工作,IETF已经融合到一种以服务恢复为初始目标的体系结构方法上[22]。在起草本文件时,IETF正在积极定义这种解决多宿问题方法的细节。这种方法似乎最适合中小型站点,尽管它会与现有的防火墙状态程序相冲突。此时,施政报告中也有积极的讨论

registries investigating the possibility of assigning provider-independent address space. Their challenge is finding a reasonable metric for limiting the number of organizations that would qualify for a global routing entry. Additional work appears to be necessary to satisfy the entire range of requirements.

研究分配独立于提供程序的地址空间的可能性的注册表。他们面临的挑战是找到一个合理的指标来限制符合全球路由条目的组织数量。额外的工作似乎是必要的,以满足整个范围的要求。

7. Security Considerations
7. 安全考虑

While issues that are potentially security related are discussed throughout the document, the approaches herein do not introduce any new security concerns. IPv4 NAT has been widely sold as a security tool, and suppliers have been implementing address translation functionality in their firewalls, though the true impact of NATs on security has been previously documented in [2] and [4].

虽然本文档中讨论了可能与安全相关的问题,但本文中的方法不会引入任何新的安全问题。IPv4 NAT作为一种安全工具已被广泛销售,供应商已在其防火墙中实现地址转换功能,尽管NAT对安全性的真正影响已在[2]和[4]中记录。

This document defines IPv6 approaches that collectively achieve the goals of the network manager without the negative impact on applications or security that are inherent in a NAT approach. While Section 6 identifies additional optimization work, to the degree that these techniques improve a network manager's ability to explicitly audit or control access, and thereby manage the overall attack exposure of local resources, they act to improve local network security.

本文档定义了IPv6方法,这些方法共同实现network manager的目标,而不会对NAT方法固有的应用程序或安全性产生负面影响。虽然第6节确定了额外的优化工作,但在一定程度上,这些技术提高了网络管理员明确审计或控制访问的能力,从而管理本地资源的整体攻击暴露,它们可以提高本地网络安全性。

8. Conclusion
8. 结论

This document has described a number of techniques that may be combined on an IPv6 site to protect the integrity of its network architecture. These techniques, known collectively as Local Network Protection, retain the concept of a well-defined boundary between "inside" and "outside" the private network and allow firewalling, topology hiding, and privacy. However, because they preserve address transparency where it is needed, they achieve these goals without the disadvantage of address translation. Thus, Local Network Protection in IPv6 can provide the benefits of IPv4 Network Address Translation without the corresponding disadvantages.

本文档描述了可在IPv6站点上组合的许多技术,以保护其网络体系结构的完整性。这些技术统称为本地网络保护,保留了私有网络“内部”和“外部”之间定义明确的边界概念,并允许防火墙、拓扑隐藏和隐私。然而,由于它们在需要时保持了地址的透明度,因此它们实现了这些目标,而不存在地址转换的缺点。因此,IPv6中的本地网络保护可以提供IPv4网络地址转换的好处,而不存在相应的缺点。

The document has also identified a few ongoing IETF work items that are needed to realize 100% of the benefits of LNP.

该文件还确定了实现LNP 100%效益所需的几个正在进行的IETF工作项目。

9. Acknowledgements
9. 致谢

Christian Huitema has contributed during the initial round table to discuss the scope and goal of the document, while the European Union IST 6NET project acted as a catalyst for the work documented in this note. Editorial comments and contributions have been received from: Fred Templin, Chao Luo, Pekka Savola, Tim Chown, Jeroen Massar, Salman Asadullah, Patrick Grossetete, Fred Baker, Jim Bound, Mark

Christian Huitema在最初的圆桌会议期间就讨论该文件的范围和目标做出了贡献,而欧盟IST 6NET项目则是本说明中所述工作的催化剂。编辑评论和稿件来自:弗雷德·坦普林、赵洛、佩卡·萨沃拉、蒂姆·乔恩、杰伦·马萨、萨尔曼·阿萨杜拉、帕特里克·格罗塞特、弗雷德·贝克、吉姆·邦德、马克

Smith, Alain Durand, John Spence, Christian Huitema, Mark Smith, Elwyn Davies, Daniel Senie, Soininen Jonne, Kurt Erik Lindqvist, Cullen Jennings, and other members of the v6ops WG and IESG.

史密斯、阿兰·杜兰德、约翰·斯彭斯、克里斯蒂安·惠特马、马克·史密斯、埃尔文·戴维斯、丹尼尔·塞尼、索尼宁·乔恩、库尔特·埃里克·林克维斯特、卡伦·詹宁斯以及v6ops工作组和IESG的其他成员。

10. Informative References
10. 资料性引用

[1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[1] Rekhter,Y.,Moskowitz,R.,Karrenberg,D.,Groot,G.,和E.Lear,“私人互联网地址分配”,BCP 5,RFC 1918,1996年2月。

[2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.

[2] Srisuresh,P.和M.Holdrege,“IP网络地址转换器(NAT)术语和注意事项”,RFC 2663,1999年8月。

[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.

[3] Narten,T.,Nordmark,E.,和W.Simpson,“IP版本6(IPv6)的邻居发现”,RFC24611998年12月。

[4] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.

[4] Hain,T.,“NAT的建筑含义”,RFC 2993,2000年11月。

[5] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.

[5] Srisuresh,P.和K.Egevang,“传统IP网络地址转换器(传统NAT)”,RFC 3022,2001年1月。

[6] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.

[6] Holdrege,M.和P.Srisuresh,“IP网络地址转换器的协议复杂性”,RFC 3027,2001年1月。

[7] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.

[7] Narten,T.和R.Draves,“IPv6中无状态地址自动配置的隐私扩展”,RFC3041,2001年1月。

[8] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.

[8] IAB和IESG,“IAB/IESG关于站点IPv6地址分配的建议”,RFC3177,2001年9月。

[9] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.

[9] Wasserman,M.,“第三代合作伙伴项目(3GPP)标准中IPv6的建议”,RFC 3314,2002年9月。

[10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

[10] Droms,R.,Bound,J.,Volz,B.,Lemon,T.,Perkins,C.,和M.Carney,“IPv6的动态主机配置协议(DHCPv6)”,RFC3315,2003年7月。

[11] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.

[11] Draves,R.,“因特网协议版本6(IPv6)的默认地址选择”,RFC 3484,2003年2月。

[12] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.

[12] Troan,O.和R.Droms,“动态主机配置协议(DHCP)版本6的IPv6前缀选项”,RFC 3633,2003年12月。

[13] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.

[13] Huttunen,A.,Swander,B.,Volpe,V.,DiBurro,L.,和M.Stenberg,“IPsec ESP数据包的UDP封装”,RFC 3948,2005年1月。

[14] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.

[14] Savola,P.和B.Haberman,“将集合点(RP)地址嵌入IPv6多播地址”,RFC 3956,2004年11月。

[15] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.

[15] Arkko,J.,Kempf,J.,Zill,B.,和P.Nikander,“安全邻居发现(SEND)”,RFC 39712005年3月。

[16] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.

[16] Baker,F.,Lear,E.和R.Droms,“在没有国旗日的情况下对IPv6网络重新编号的程序”,RFC 41922005年9月。

[17] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.

[17] Hinden,R.和B.Haberman,“唯一本地IPv6单播地址”,RFC4193,2005年10月。

[18] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.

[18] Fuller,V.和T.Li,“无类别域间路由(CIDR):互联网地址分配和聚合计划”,BCP 122,RFC 4632,2006年8月。

[19] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful", Work in Progress, June 2004.

[19] 杜邦,F.和P.萨沃拉,“RFC 3041被认为有害”,正在进行的工作,2004年6月。

[20] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", Work in Progress, October 2005.

[20] Chown,T.,“IPv6对TCP/UDP端口扫描的影响”,正在进行的工作,2005年10月。

[21] Chown, T., Tompson, M., Ford, A., and S. Venaas, "Things to think about when Renumbering an IPv6 network", Work in Progress, September 2006.

[21] Chown,T.,Tompson,M.,Ford,A.,和S.Venaas,“重新编号IPv6网络时需要考虑的事情”,正在进行的工作,2006年9月。

[22] Huston, G., "Architectural Commentary on Site Multi-homing using a Level 3 Shim", Work in Progress, July 2005.

[22] Huston,G.,“使用3级垫片的现场多主系统的建筑评论”,正在进行的工作,2005年7月。

[23] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2006.

[23] Rosenberg,J.,“交互式连接建立(ICE):提供/应答协议的网络地址转换器(NAT)遍历方法”,正在进行的工作,2006年10月。

[24] "Universal Plug and Play Web Site", July 2005, <http://www.upnp.org/>.

[24] “通用即插即用网站”,2005年7月<http://www.upnp.org/>.

Appendix A. Additional Benefits Due to Native IPv6 and Universal Unique Addressing

附录A.本机IPv6和通用唯一寻址带来的其他好处

The users of native IPv6 technology and globally unique IPv6 addresses have the potential to make use of the enhanced IPv6 capabilities, in addition to the benefits offered by the IPv4 technology.

本机IPv6技术和全球唯一IPv6地址的用户,除了IPv4技术提供的好处外,还有可能利用增强的IPv6功能。

A.1. Universal Any-to-Any Connectivity
A.1. 通用任意对任意连接

One of the original design points of the Internet was any-to-any connectivity. The dramatic growth of Internet-connected systems coupled with the limited address space of the IPv4 protocol spawned address conservation techniques. NAT was introduced as a tool to reduce demand on the limited IPv4 address pool, but the side effect of the NAT technology was to remove the any-to-any connectivity capability. By removing the need for address conservation (and therefore NAT), IPv6 returns the any-to-any connectivity model and removes the limitations on application developers. With the freedom to innovate unconstrained by NAT traversal efforts, developers will be able to focus on new advanced network services (i.e., peer-to-peer applications, IPv6-embedded IPsec communication between two communicating devices, instant messaging, Internet telephony, etc.) rather than focusing on discovering and traversing the increasingly complex NAT environment.

互联网最初的设计要点之一是任意对任意连接。互联网连接系统的急剧增长,加上IPv4协议有限的地址空间,催生了地址保护技术。NAT的引入是为了减少对有限的IPv4地址池的需求,但NAT技术的副作用是消除任意对任意连接能力。通过消除地址保护(因此NAT)的需要,IPv6将返回any-to-any连接模型,并消除了对应用程序开发人员的限制。通过不受NAT穿越工作限制的创新自由,开发人员将能够专注于新的高级网络服务(即,对等应用程序、两个通信设备之间的IPv6嵌入式IPsec通信、即时消息、互联网电话等)而不是专注于发现和穿越日益复杂的NAT环境。

It will also allow application and service developers to rethink the security model involved with any-to-any connectivity, as the current edge firewall solution in IPv4 may not be sufficient for any-to-any service models.

它还将允许应用程序和服务开发人员重新考虑任意对任意连接所涉及的安全模型,因为IPv4中当前的边缘防火墙解决方案可能不足以满足任意对任意服务模型。

A.2. Auto-Configuration
A.2. 自动配置

IPv6 offers a scalable approach to minimizing human interaction and device configuration. IPv4 implementations require touching each end system to indicate the use of DHCP vs. a static address and management of a server with the pool size large enough for the potential number of connected devices. Alternatively, IPv6 uses an indication from the router to instruct the end systems to use DHCP or the stateless auto-configuration approach supporting a virtually limitless number of devices on the subnet. This minimizes the number of systems that require human interaction as well as improves consistency between all the systems on a subnet. In the case that there is no router to provide this indication, an address for use only on the local link will be derived from the interface media layer address.

IPv6提供了一种可扩展的方法来最小化人机交互和设备配置。IPv4实现需要接触每个终端系统,以指示DHCP的使用与静态地址的对比,并管理池大小足以容纳潜在连接设备数量的服务器。或者,IPv6使用来自路由器的指示来指示终端系统使用DHCP或无状态自动配置方法,支持子网上几乎无限数量的设备。这将最大限度地减少需要人工交互的系统数量,并提高子网上所有系统之间的一致性。如果没有路由器提供此指示,则仅在本地链路上使用的地址将从接口媒体层地址派生。

A.3. Native Multicast Services
A.3. 本机多播服务

Multicast services in IPv4 were severely restricted by the limited address space available to use for group assignments and an implicit locally defined range for group membership. IPv6 multicast corrects this situation by embedding explicit scope indications as well as expanding to 4 billion groups per scope. In the source-specific multicast case, this is further expanded to 4 billion groups per scope per subnet by embedding the 64 bits of subnet identifier into the multicast address.

IPv4中的多播服务受到可用于组分配的有限地址空间和隐式本地定义的组成员范围的严格限制。IPv6多播通过嵌入明确的作用域指示以及将每个作用域扩展到40亿组来纠正这种情况。在源特定的多播情况下,通过将子网标识符的64位嵌入多播地址,这进一步扩展到每个子网的每个作用域40亿个组。

IPv6 allows also for innovative usage of the IPv6 address length and makes it possible to embed the multicast Rendezvous Point (RP) [14] directly in the IPv6 multicast address when using Any-Source Multicast (ASM). This is not possible with the limited size of the IPv4 address. This approach also simplifies the multicast model considerably, making it easier to understand and deploy.

IPv6还允许创新性地使用IPv6地址长度,并允许在使用任何源多播(ASM)时将多播集合点(RP)[14]直接嵌入IPv6多播地址。由于IPv4地址的大小有限,这是不可能的。这种方法还大大简化了多播模型,使其更易于理解和部署。

A.4. Increased Security Protection
A.4. 加强安全保护

The security protection offered by native IPv6 technology is more advanced than IPv4 technology. There are various transport mechanisms enhanced to allow a network to operate more securely with less performance impact:

本机IPv6技术提供的安全保护比IPv4技术更先进。增强了各种传输机制,使网络能够更安全地运行,而对性能的影响更小:

o IPv6 has the IPsec technology directly embedded into the IPv6 protocol. This allows for simpler peer-to-peer authentication and encryption, once a simple key/trust management model is developed, while the usage of some other less secure mechanisms is avoided (e.g., MD5 password hash for neighbor authentication).

o IPv6将IPsec技术直接嵌入到IPv6协议中。一旦开发了简单的密钥/信任管理模型,这就允许更简单的对等身份验证和加密,同时避免使用其他一些不太安全的机制(例如,用于邻居身份验证的MD5密码哈希)。

o While a firewall is specifically designed to disallow applications based on local policy, it does not interfere with those that are allowed. This is a security improvement over NAT, where the work-arounds to enable applications allowed by local policy are effectively architected man-in-the-middle attacks on the packets, which precludes end-to-end auditing or IP level identification.

o 虽然防火墙是专门设计来禁止基于本地策略的应用程序的,但它不会干扰那些被允许的应用程序。这是对NAT的安全性改进,在NAT中,使本地策略允许的应用程序能够有效地架构在数据包上的中间人攻击,从而排除端到端审计或IP级别识别。

o All flows on the Internet will be better traceable due to a unique and globally routable source and destination IPv6 address. This may facilitate an easier methodology for back-tracing Denial of Service (DoS) attacks and avoid illegal access to network resources by simpler traffic filtering.

o 互联网上的所有流量都将具有更好的可追踪性,因为有一个唯一且全球可路由的源和目标IPv6地址。这可能有助于采用更简单的方法来回溯拒绝服务(DoS)攻击,并通过更简单的流量过滤来避免非法访问网络资源。

o The usage of private address space in IPv6 is now provided by Unique Local Addresses, which will avoid conflict situations when merging networks and securing the internal communication on a local network infrastructure due to simpler traffic filtering policy.

o IPv6中专用地址空间的使用现在由唯一的本地地址提供,这将避免在合并网络和保护本地网络基础设施上的内部通信时发生冲突,因为更简单的流量过滤策略。

o The technology to enable source-routing on a network infrastructure has been enhanced to allow this feature to function, without impacting the processing power of intermediate network devices. The only devices impacted with the source-routing will be the source and destination node and the intermediate source-routed nodes. This impact behavior is different if IPv4 is used, because then all intermediate devices would have had to look into the source route header.

o 在网络基础设施上启用源路由的技术已得到增强,以允许此功能正常运行,而不会影响中间网络设备的处理能力。受源路由影响的唯一设备将是源和目标节点以及中间源路由节点。如果使用IPv4,这种影响行为是不同的,因为所有中间设备都必须查看源路由头。

A.5. Mobility
A.5. 流动性

Anytime, anywhere, universal access requires MIPv6 services in support of mobile nodes. While a Home Agent is required for initial connection establishment in either protocol version, IPv6 mobile nodes are able to optimize the path between them using the MIPv6 option header, while IPv4 mobile nodes are required to triangle route all packets. In general terms, this will minimize the network resources used and maximize the quality of the communication.

无论何时何地,universal access都需要支持移动节点的MIPv6服务。虽然在任一协议版本中初始连接建立都需要归属代理,但IPv6移动节点能够使用MIPv6选项标头优化它们之间的路径,而IPv4移动节点需要三角路由所有数据包。一般来说,这将最大限度地减少使用的网络资源,并最大限度地提高通信质量。

A.6. Merging Networks
A.6. 合并网络

When two IPv4 networks want to merge, it is not guaranteed that both networks are using different address ranges on some parts of the network infrastructure due to the usage of RFC 1918 private addressing. This potential overlap in address space may complicate a merging of two and more networks dramatically due to the additional IPv4 renumbering effort, i.e., when the first network has a service running (NTP, DNS, DHCP, HTTP, etc.) that needs to be accessed by the second merging network. Similar address conflicts can happen when two network devices from these merging networks want to communicate.

当两个IPv4网络要合并时,由于使用RFC 1918专用寻址,无法保证两个网络在网络基础设施的某些部分上使用不同的地址范围。由于额外的IPv4重新编号工作,地址空间中的这种潜在重叠可能会使两个或更多网络的合并大大复杂化,即,当第一个网络运行需要第二个合并网络访问的服务(NTP、DNS、DHCP、HTTP等)时。当来自这些合并网络的两个网络设备想要通信时,可能会发生类似的地址冲突。

With the usage of IPv6, the addressing overlap will not exist because of the existence of the Unique Local Address usage for private and local addressing.

使用IPv6时,由于存在专用和本地寻址的唯一本地地址用法,因此不会存在寻址重叠。

Authors' Addresses

作者地址

Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium

Gunter Van de Velde Cisco Systems de Kleetlaan 6a Diegem 1831比利时

   Phone: +32 2704 5473
   EMail: gunter@cisco.com
        
   Phone: +32 2704 5473
   EMail: gunter@cisco.com
        

Tony Hain Cisco Systems 500 108th Ave. NE Bellevue, Wa. USA

Tony Hain Cisco Systems 500,华盛顿州东北贝尔维尤第108大道。美国

   EMail: alh-ietf@tndh.net
        
   EMail: alh-ietf@tndh.net
        

Ralph Droms Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA

Ralph Droms Cisco Systems美国马萨诸塞州Boxborough马萨诸塞大道1414号,邮编01719

   EMail: rdroms@cisco.com
        
   EMail: rdroms@cisco.com
        

Brian Carpenter IBM 8 Chemin de Blandonnet 1214 Vernier, CH

Brian Carpenter IBM 8 Chemin de Blandnnet 1214 Vernier,CH

   EMail: brc@zurich.ibm.com
        
   EMail: brc@zurich.ibm.com
        

Eric Klein Tel Aviv University Tel Aviv, Israel

以色列特拉维夫特拉维夫大学埃里克·克莱因

   EMail: ericlklein.ipv6@gmail.com
        
   EMail: ericlklein.ipv6@gmail.com
        

Full Copyright Statement

完整版权声明

Copyright (C) The IETF Trust (2007).

版权所有(C)IETF信托基金(2007年)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

本文件受BCP 78中包含的权利、许可和限制的约束,除其中规定外,作者保留其所有权利。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

本文件及其包含的信息以“原样”为基础提供,贡献者、他/她所代表或赞助的组织(如有)、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保,包括但不限于任何保证,即使用本文中的信息不会侵犯任何权利,或对适销性或特定用途适用性的任何默示保证。

Intellectual Property

知识产权

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围,或此类权利下的任何许可可能或可能不可用的程度,不采取任何立场;它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息,请参见BCP 78和BCP 79。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

向IETF秘书处披露的知识产权副本和任何许可证保证,或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果,可从IETF在线知识产权存储库获取,网址为http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETF邀请任何相关方提请其注意任何版权、专利或专利申请,或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.

Acknowledgement

确认

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC编辑功能的资金目前由互联网协会提供。