Network Working Group X. Li, Ed.
Request for Comments: 4925 CERNET
Category: Informational S. Dawkins, Ed.
Huawei
D. Ward, Ed.
Cisco Systems
A. Durand, Ed.
Comcast
July 2007
Network Working Group X. Li, Ed.
Request for Comments: 4925 CERNET
Category: Informational S. Dawkins, Ed.
Huawei
D. Ward, Ed.
Cisco Systems
A. Durand, Ed.
Comcast
July 2007
Softwire Problem Statement
软线问题陈述
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
摘要
This document captures the problem statement for the Softwires Working Group, which is developing standards for the discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks as well as IPv6 networks across IPv4-only networks. The standards will encourage multiple, inter-operable vendor implementations by identifying, and extending where necessary, existing standard protocols to resolve a selected set of "IPv4/IPv6" and "IPv6/IPv4" transition problems. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope.
本文档捕获了Softwires工作组的问题陈述，该工作组正在开发用于跨仅IPv6网络连接IPv4网络以及跨仅IPv4网络连接IPv6网络的发现、控制和封装方法的标准。这些标准将通过识别并在必要时扩展现有标准协议来解决选定的一组“IPv4/IPv6”和“IPv6/IPv4”转换问题，从而鼓励多个可互操作的供应商实施。本文件描述了软线工作组制定的标准将解决的具体问题（“轮毂和辐条”和“网格”）。还确定了一些需求（和非需求），以便更好地描述特定的问题范围。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Hubs and Spokes Problem . . . . . . . . . . . . . . . . . . . 6
2.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Non-Upgradable CPE Router . . . . . . . . . . . . . . . . 9
2.3. Network Address Translation (NAT) and Port Address
Translation (PAT) . . . . . . . . . . . . . . . . . . . . 10
2.4. Static Prefix Delegation . . . . . . . . . . . . . . . . . 10
2.5. Softwire Initiator . . . . . . . . . . . . . . . . . . . . 11
2.6. Softwire Concentrator . . . . . . . . . . . . . . . . . . 11
2.7. Softwire Concentrator Discovery . . . . . . . . . . . . . 12
2.8. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.9. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 12
2.11. Security . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.11.1. Authentication, Authorization, and Accounting
(AAA) . . . . . . . . . . . . . . . . . . . . . . . . 12
2.11.2. Privacy, Integrity, and Replay Protection . . . . . . 13
2.12. Operations and Management (OAM) . . . . . . . . . . . . . 13
2.13. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 13
3. Mesh Problem . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Persistence, Discovery, and Setup Time . . . . . . . . . . 16
3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5. Softwire Encapsulation . . . . . . . . . . . . . . . . . . 17
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. Principal Authors . . . . . . . . . . . . . . . . . . . . . . 18
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Hubs and Spokes Problem . . . . . . . . . . . . . . . . . . . 6
2.1. Description . . . . . . . . . . . . . . . . . . . . . . . 8
2.2. Non-Upgradable CPE Router . . . . . . . . . . . . . . . . 9
2.3. Network Address Translation (NAT) and Port Address
Translation (PAT) . . . . . . . . . . . . . . . . . . . . 10
2.4. Static Prefix Delegation . . . . . . . . . . . . . . . . . 10
2.5. Softwire Initiator . . . . . . . . . . . . . . . . . . . . 11
2.6. Softwire Concentrator . . . . . . . . . . . . . . . . . . 11
2.7. Softwire Concentrator Discovery . . . . . . . . . . . . . 12
2.8. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.9. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.10. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 12
2.11. Security . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.11.1. Authentication, Authorization, and Accounting
(AAA) . . . . . . . . . . . . . . . . . . . . . . . . 12
2.11.2. Privacy, Integrity, and Replay Protection . . . . . . 13
2.12. Operations and Management (OAM) . . . . . . . . . . . . . 13
2.13. Encapsulations . . . . . . . . . . . . . . . . . . . . . . 13
3. Mesh Problem . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.1. Description . . . . . . . . . . . . . . . . . . . . . . . 14
3.2. Scaling . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3. Persistence, Discovery, and Setup Time . . . . . . . . . . 16
3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5. Softwire Encapsulation . . . . . . . . . . . . . . . . . . 17
3.6. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17
4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5. Principal Authors . . . . . . . . . . . . . . . . . . . . . . 18
6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 20
The Softwires Working Group is specifying the standardization of discovery, control, and encapsulation methods for connecting IPv4 networks across IPv6-only networks and IPv6 networks across IPv4-only networks in a way that will encourage multiple, inter-operable vendor implementations. This document describes the specific problems ("Hubs and Spokes" and "Mesh") that will be solved by the standards developed by the Softwires Working Group. Some requirements (and non-requirements) are also identified to better describe the specific problem scope. A few generic assumptions are listed up front:
Softwires工作组正在指定用于跨纯IPv6网络连接IPv4网络和跨纯IPv4网络连接IPv6网络的发现、控制和封装方法的标准化，其方式将鼓励多个可互操作的供应商实施。本文件描述了软线工作组制定的标准将解决的具体问题（“轮毂和辐条”和“网格”）。还确定了一些需求（和非需求），以便更好地描述特定的问题范围。前面列出了一些通用假设：
o Local Area Networks will often support both protocol families in order to accommodate both IPv4-only and IPv6-only applications, in addition to dual-stack applications. Global reachability requires the establishment of softwire connectivity to transit across portions of the network that do not support both address families. Wide area networks that support one or both address families may be separated by transit networks that do not support all address families. Softwire connectivity is necessary to establish global reachability of both address families.
o 局域网通常支持这两种协议系列，以适应仅IPv4和仅IPv6的应用程序，以及双堆栈应用程序。全局可达性要求建立软线连接，以便在不同时支持两个地址族的网络部分进行传输。支持一个或两个地址族的广域网可能被不支持所有地址族的传输网分隔开。软线连接对于建立两个地址族的全局可达性是必要的。
o Softwires are to be used in IP-based networks to forward both unicast and multicast traffic.
o 软线将用于基于IP的网络，以转发单播和多播通信量。
o Softwires are assumed to be long-lived in nature.
o 软电线被认为是长寿命的。
o Although Softwires are long-lived, the setup time of a softwire is expected to be a very small fraction of the total time required for the startup of the Customer Premise Equipment (CPE)/Address Family Border Router (AFBR).
o 尽管软线寿命较长，但软线的设置时间预计只占启动用户端设备（CPE）/地址族边界路由器（AFBR）所需总时间的一小部分。
o The nodes that actually initiate softwires should support dual-stack (IPv4 and IPv6) functionality.
o 实际启动软连线的节点应支持双栈（IPv4和IPv6）功能。
o The goal of this effort is to reuse or extend existing technology. The 'time-to-market' requirement for solutions to the stated problems is very strict and existing, deployed technology must be very strongly considered in our solution selection.
o 这项工作的目标是重用或扩展现有技术。针对所述问题的解决方案的“上市时间”要求非常严格，我们在选择解决方案时必须充分考虑现有的、已部署的技术。
The solution to the stated problem should address the following points:
所述问题的解决方案应解决以下几点：
o Relation of the softwire protocols to other host mechanisms in the same layer of the network stack. Examples of mechanisms to consider are tunneling mechanisms, VPNs (Virtual Private Networks), mobility, multihoming (SHIM6 (Level 3 Shim for IPv6)),...
o 软线协议与网络堆栈同一层中的其他主机机制的关系。考虑机制的例子有隧道机制、VPN（虚拟专用网络）、移动性、多宿主（SIM6（IPv6的3级垫片））、…
o Operational brittleness introduced by softwire, e.g., potential single point of failure or difficulties to deploy redundant systems.
o 软线带来的操作脆性，例如潜在的单点故障或部署冗余系统的困难。
o Effects of softwires on the transport layer. Issue like packet losses, congestion control, and handling of QoS (Quality of Service) reservation and usage of on-path protocols such as RSVP (Resource Reservation Protocol).
o 软导线对传输层的影响。诸如数据包丢失、拥塞控制、QoS（服务质量）预留的处理以及RSVP（资源预留协议）等路径协议的使用等问题。
The history of IPv4 and IPv6 transition strategies at the IETF is very long and complex. Here we list out some steps we have taken to further the effort and it has lead to the creation of this document and a few 'working rules' for us to accomplish our work:
IETF的IPv4和IPv6过渡策略的历史非常漫长和复杂。在这里，我们列出了我们为进一步开展工作而采取的一些步骤，这些步骤为我们创建了本文件，并为我们完成工作制定了一些“工作规则”：
o At the IETF 63 "LightWeight Reachability softWires" (LRW) BOF meeting, attendees from several operators requested a very tight timeframe for the delivery of a solution, based on time-to-market considerations. This problem statement is narrowly scoped to accommodate near-term deployment.
o 在IETF 63“轻量级可达性软线”（LRW）BOF会议上，来自多家运营商的与会者基于上市时间的考虑，要求交付解决方案的时间非常紧迫。此问题陈述的范围很窄，以适应短期部署。
o At the Paris Softwires interim meeting in October, 2005, participants divided the overall problem space into two separate "sub-problems" to solve based on network topology. These two problems are referred to as "Hubs and Spokes" (described in Section 2) and "Mesh" (described in Section 3).
o 在2005年10月的巴黎Softwires临时会议上，与会者将整个问题空间划分为两个独立的“子问题”，以基于网络拓扑进行解决。这两个问题被称为“轮毂和辐条”（在第2节中描述）和“网格”（在第3节中描述）。
As stated, there are two scenarios that emerged when discussing the traversal of networks composed of differing address families. The scenarios are quite common in today's network deployments. The primary difference between "Spokes and Hubs" and "Mesh" is how many connections and associated routes are managed by each IPv4 or IPv6 "island". "Hubs and Spokes" is characterized with one connection and associated static default route, and "Mesh" is characterized by multiple connections and routing prefixes. In general, the two can be categorized as host or LAN connectivity and network (or VPN) connectivity problems. Looking at the history of multi-address family networking, the clear delineation of the two scenarios was never clearly illustrated but they are now the network norm, and both must be solved. Later, during the solution phase of the Work Group (WG), these problems will be treated as related, but separate, problem spaces. Similar protocols and mechanisms will be used when possible, but different protocols and mechanisms may be selected when necessary to meet the requirements of each given problem space.
如上所述，在讨论由不同地址族组成的网络的遍历时，出现了两种情况。这些场景在当今的网络部署中非常常见。“辐条和集线器”与“网格”之间的主要区别在于每个IPv4或IPv6“岛”管理多少个连接和相关路由。“集线器和辐条”的特征是一个连接和相关的静态默认路由，“网格”的特征是多个连接和路由前缀。通常，这两个问题可分为主机或LAN连接问题和网络（或VPN）连接问题。回顾多地址家庭网络的历史，这两种情况的清晰描述从未得到明确说明，但它们现在已成为网络规范，必须解决这两个问题。在工作组中，这些问题将被视为单独的解决方案，但在工作组的工作阶段，这些问题将被视为单独的解决方案。可能时，将使用类似的协议和机制，但必要时可选择不同的协议和机制，以满足每个给定问题空间的要求。
Address Family (AF) - IPv4 or IPv6. Presently defined values for this field are specified in
地址系列（AF）-IPv4或IPv6。此字段当前定义的值在中指定
http://www.iana.org/assignments/address-family-numbers.
http://www.iana.org/assignments/address-family-numbers.
Address Family Border Router (AFBR) - The router that interconnects two networks that use different address families.
地址族边界路由器（AFBR）-将使用不同地址族的两个网络互连的路由器。
Customer Premise Equipment (CPE) - Under the scope of this document, this refers to terminal and associated equipment and inside wiring located at a subscriber's premises and connected with a carrier's communication channel(s) at the demarcation point ("demarc"). The demarc is a point established in a building or complex to separate customer equipment from telephone, cable, or other service provider equipment. CPE can be a host or router, depending on the specific characteristics of the access network. The demarc point for IPv4 may or may not be the same as the demarc point for IPv6, thus there can be one CPE box acting for IPv4 and IPv6 or two separate ones, one for IPv4 and one for IPv6.
客户场所设备（CPE）-在本文件范围内，指位于用户场所并在分界点（“demarc”）与运营商通信信道相连的终端和相关设备以及内部布线。demarc是在建筑物或综合体中建立的一个点，用于将客户设备与电话、电缆或其他服务提供商设备分开。CPE可以是主机或路由器，这取决于接入网络的特定特性。IPv4的demarc点可能与IPv6的demarc点相同，也可能与IPv6的demarc点不同，因此可以有一个CPE盒用于IPv4和IPv6，也可以有两个单独的CPE盒，一个用于IPv4，一个用于IPv6。
Home gateway - Existing piece of equipment that connects the home network to the provider network. Usually act as CPE for one or both address families.
家庭网关-将家庭网络连接到提供商网络的现有设备。通常作为一个或两个地址系列的CPE。
Softwire (SW) - A "tunnel" that is created on the basis of a control protocol setup between softwire endpoints with a shared point-to-point or multipoint-to-point state. Softwires are generally dynamic in nature (they may be initiated and terminated on demand), but may be very long-lived.
Softwire（SW）-基于控制协议设置在具有共享点对点或多点对点状态的Softwire端点之间创建的“隧道”。软线本质上通常是动态的（它们可以根据需要启动和终止），但可能寿命很长。
Softwire Concentrator (SC) - The node terminating the softwire in the service provider network.
软线集中器（SC）-在服务提供商网络中终止软线的节点。
Softwire Initiator (SI) - The node initiating the softwire within the customer network.
软线启动器（SI）-在客户网络内启动软线的节点。
Softwire Transport Header AF (STH AF) - the address family of the outermost IP header of a softwire.
软线传输头AF（STH AF）-软线最外层IP头的地址族。
Softwire Payload Header AF (SPH AF) - the address family of the IP headers being carried within a softwire. Note that additional "levels" of IP headers may be present if (for example) a tunnel is carried over a softwire - the key attribute of SPH AF is that it is directly encapsulated within the softwire and the softwire endpoint will base forwarding decisions on the SPH AF when a packet is exiting the softwire.
软线有效负载头AF（SPH AF）-软线中承载的IP头的地址系列。注意，如果（例如）隧道通过软线承载，则可能存在IP报头的附加“级别”-SPH AF的关键属性是它直接封装在软线内，并且当分组离开软线时，软线端点将基于SPH AF做出转发决策。
Subsequent Address Family (SAF) - Additional information about the type of Network Layer Reachability Information (e.g., unicast or multicast).
后续地址族（SAF）-有关网络层可达性信息类型的附加信息（例如，单播或多播）。
The "Hubs and Spokes" problem is named in reference to the airline industry where major companies have established a relatively small number of well connected hubs and then serve smaller airports from those hubs.
“枢纽和辐条”问题是根据航空业命名的，在航空业中，大公司建立了数量相对较少的连接良好的枢纽，然后从这些枢纽为较小的机场提供服务。
Manually configured tunnels (as described in [RFC4213]) can be a sufficient transition mechanism in some situations. However, cases where Network Address Translation (NAT) traversal is a concern (see Section 2.3), or dynamic IP address configuration is required, another solution is necessary.
在某些情况下，手动配置的隧道（如[RFC4213]中所述）是一种足够的转换机制。但是，如果需要考虑网络地址转换（NAT）遍历（参见第2.3节），或者需要动态IP地址配置，则需要另一种解决方案。
There are four variant cases of the "Hubs and Spokes" problem which are shown in the following figures.
“轮毂和辐条”问题有四种不同的情况，如下图所示。
+-------+ +------------+ +--------+
| | |Softwire | | IPv6 |
+---------+ | IPv4 |--|concentrator|--| Network|=>Internet
|v4/v6 |--| | +------------+ +--------+
|Host CPE | | |
+---------+ |Network|
+-------+
_ _ _ _ _ _ __
()_ _ _ _ _ _ __() IPv6 SPH
"softwire"
|--------------||-------------------------|
IPv4-only IPv6 or dual-stack
+-------+ +------------+ +--------+
| | |Softwire | | IPv6 |
+---------+ | IPv4 |--|concentrator|--| Network|=>Internet
|v4/v6 |--| | +------------+ +--------+
|Host CPE | | |
+---------+ |Network|
+-------+
_ _ _ _ _ _ __
()_ _ _ _ _ _ __() IPv6 SPH
"softwire"
|--------------||-------------------------|
IPv4-only IPv6 or dual-stack
Case 1: IPv6 connectivity across an IPv4-only access network (STH). Softwire initiator is the host CPE (directly connected to a modem), which is dual-stack. There is no other gateway device. The IPv4 traffic should not traverse the softwire.
案例1：跨仅IPv4访问网络（STH）的IPv6连接。软线启动器是主机CPE（直接连接到调制解调器），它是双堆栈。没有其他网关设备。IPv4流量不应穿过软线。
Figure 1: Case 1
图1：案例1
+-------+ +-------------+ +--------+
| | | Softwire | | v6 |
+-----+ +------+ | v4 |--| concentrator|--| Network|=>Internet
|v4/v6|--|v4/v6 |--| | +-------------+ +--------+
|Host | |Router| |Network|
+-----+ |v4/v6 | | |
| CPE | +-------+
+------+
_ _ _ _ _ _ __
()_ _ _ _ _ _ __() IPv6 SPH
"softwire"
|--------------||--------------||-------------------------|
Dual-stack IPv4-only IPv6 or dual-stack
+-------+ +-------------+ +--------+
| | | Softwire | | v6 |
+-----+ +------+ | v4 |--| concentrator|--| Network|=>Internet
|v4/v6|--|v4/v6 |--| | +-------------+ +--------+
|Host | |Router| |Network|
+-----+ |v4/v6 | | |
| CPE | +-------+
+------+
_ _ _ _ _ _ __
()_ _ _ _ _ _ __() IPv6 SPH
"softwire"
|--------------||--------------||-------------------------|
Dual-stack IPv4-only IPv6 or dual-stack
Case 2: IPv6 connectivity across an IPv4-only access network (STH). Softwire initiator is the router CPE, which is a dual-stack device. The IPv4 traffic should not traverse the softwire.
案例2：跨仅IPv4访问网络（STH）的IPv6连接。软线启动器是路由器CPE，它是一个双栈设备。IPv4流量不应穿过软线。
Figure 2: Case 2
图2：案例2
+-------+ +-------------+ +--------+
| | | Softwire | | v6 |
+------+ +------+ | v4 |--| concentrator|--| Network|=>Internet
|v4/v6 |--|v4 |--| | +-------------+ +--------+
|Host | |Router| |Network|
|v6 CPE| |v4 CPE| | |
+------+ | | +-------+
+------+
_ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH
"softwire"
|-----------------------||-------------------------|
IPv4 only IPv6 or dual-stack
+-------+ +-------------+ +--------+
| | | Softwire | | v6 |
+------+ +------+ | v4 |--| concentrator|--| Network|=>Internet
|v4/v6 |--|v4 |--| | +-------------+ +--------+
|Host | |Router| |Network|
|v6 CPE| |v4 CPE| | |
+------+ | | +-------+
+------+
_ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH
"softwire"
|-----------------------||-------------------------|
IPv4 only IPv6 or dual-stack
Case 3: IPv6 connectivity across an IPv4-only access network (STH). The CPE is IPv4-only. Softwire initiator is a host, which act as an IPv6 host CPE. The IPv4 traffic should not traverse the softwire.
案例3：跨仅IPv4访问网络（STH）的IPv6连接。CPE仅为IPv4。Softwire启动器是一台主机，充当IPv6主机CPE。IPv4流量不应穿过软线。
Figure 3: Case 3
图3：案例3
+-----+
|v4/v6| +-------+ +------------+ +-------+
|Host | | | |Softwire | | v6 |
+-----+ +------+ | v4 |--|concentrator|--|Network|=>Internet
| |v4 |--| | +------------+ +-------+
|---------|Router| |Network|
| |v4 CPE| +-------+
+---------+ +------+
|Softwire |
|Initiator|
|v6 Router|
| CPE |
+---------+
_ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH
"softwire"
|--------||-----------------------||----------------------|
Dual IPv4 only IPv6 or dual-stack
stack
+-----+
|v4/v6| +-------+ +------------+ +-------+
|Host | | | |Softwire | | v6 |
+-----+ +------+ | v4 |--|concentrator|--|Network|=>Internet
| |v4 |--| | +------------+ +-------+
|---------|Router| |Network|
| |v4 CPE| +-------+
+---------+ +------+
|Softwire |
|Initiator|
|v6 Router|
| CPE |
+---------+
_ _ _ _ _ _ _ _ _ _ _ _
()_ _ _ _ _ _ _ _ _ _ _ _() IPv6 SPH
"softwire"
|--------||-----------------------||----------------------|
Dual IPv4 only IPv6 or dual-stack
stack
Case 4: IPv6 connectivity across an IPv4-only access network (STH). The routing CPE is IPv4-only. Softwire initiator is a device acting as an IPv6 CPE router inside the home network. The IPv4 traffic should not traverse the softwire.
案例4：跨仅IPv4访问网络（STH）的IPv6连接。路由CPE仅为IPv4。软线启动器是在家庭网络内充当IPv6 CPE路由器的设备。IPv4流量不应穿过软线。
Figure 4: Case 4
图4：案例4
The converse cases exist, replacing IPv4 by IPv6 and vice versa in the above figures.
相反的情况存在，在上图中，IPv4被IPv6取代，反之亦然。
In this scenario, carriers (or large enterprise networks acting as carriers for their internal networks) have an infrastructure that in at least one device on any given path supports only one address family, with customers who wish to support applications bound to an address family that cannot be routed end-to-end. The address family that must be "crossed" is called the Softwire Transport Header, or STH AF (which could be either IPv4 or IPv6).
在这种情况下，运营商（或作为其内部网络运营商的大型企业网络）的基础设施在任何给定路径上的至少一个设备中仅支持一个地址族，客户希望支持绑定到无法端到端路由的地址族的应用程序。必须“交叉”的地址族称为Softwire传输头或STH AF（可以是IPv4或IPv6）。
In order to support applications bound to another address family (the Softwire Payload Header Address Family, or SPH AF), it is necessary to establish a virtual dual-stack infrastructure (end-to-end), typically by means of automatically-established tunnels (Softwires). The traffic that can traverse the network via its native AF must not be forced to take the softwire path. Only the traffic that otherwise would not be able to be forwarded due to the AF mismatch should be
为了支持绑定到另一个地址系列（软线有效负载报头地址系列，或SPH AF）的应用程序，有必要建立虚拟双堆栈基础设施（端到端），通常通过自动建立的隧道（软线）来实现。可通过其本机AF穿越网络的流量不得强制采用软线路径。只有由于AF不匹配而无法转发的流量才应被删除
forwarded within the softwire. The goal is to avoid overwhelming the softwire concentrator (SC).
在软线内转发。目标是避免使软线集中器（SC）无法正常工作。
A network operator may choose to enable a single address family in one or several parts of this infrastructure for policy reasons (i.e., traffic on the network is dominant in one of the address families, a single address family is used to lower Operations and Management (OAM) cost, etc.) or for technical reasons (i.e., because one or more devices are not able to support both address families).
网络运营商可出于政策原因（即，网络上的流量在其中一个地址系列中占主导地位，单个地址系列用于降低运营和管理（OAM）成本等）或技术原因，选择在该基础设施的一个或多个部分中启用单个地址系列（即，因为一个或多个设备不能同时支持两个地址族）。
There are several obstacles that may preclude support for both address families:
有几个障碍可能妨碍对两个家庭的支持：
a) One or more devices (routers or some other media-specific aggregation point device) being used across the infrastructure (core, access) that supports only one address family. Typically the reasons for this situation include a lack of vendor support for one of the address families, the (perceived) cost of upgrading them, the (perceived) complexity of running both address families natively, operation/management reasons to avoid upgrades (perhaps temporarily), or economic reasons (such as a commercially insignificant amount of traffic with the non-supported address family).
a) 一个或多个设备（路由器或某些其他特定于媒体的聚合点设备）正在整个基础结构（核心、访问）中使用，只支持一个地址系列。通常情况下，出现这种情况的原因包括供应商对其中一个地址系列缺乏支持、升级它们的（感知）成本、以本机方式运行两个地址系列的（感知）复杂性、避免升级的操作/管理原因（可能是暂时的）或经济原因（例如，与不受支持的地址系列的通信量在商业上微不足道）。
b) The home gateway (CPE router or other equipment at the demarc point), cannot be easily upgraded to support both address families. Typically the reason for this is the lack of vendor support for one of the address families, commercial or operational reasons for not carrying out the upgrade (i.e., operational changes and/or cost may need to be supported by the carrier for all the customers, which can turn into millions of units), or customer reluctance to change/ upgrade CPE router (cost, "not broken, so don't change it"). Note that the impracticality of systematic upgrades of the CPE routers is also hindering the deployment of 6to4 based solutions [RFC3056] in IPv4 networks.
b) 家庭网关（CPE路由器或demarc点的其他设备）无法轻松升级以支持两个地址族。通常情况下，其原因是供应商对其中一个地址系列缺乏支持，不进行升级的商业或运营原因（即运营商可能需要为所有客户提供运营变更和/或成本支持，这可能会转化为数百万个单位），或者客户不愿意更改/升级CPE路由器（成本，“没有损坏，所以不要更改”）。请注意，CPE路由器系统升级的不切实际性也阻碍了基于6to4的解决方案[RFC3056]在IPv4网络中的部署。
Residential and small-office CPE equipment may be limited to support only one address family. Often, they are owned by a customer or carrier who is unwilling or unable to upgrade them to run in dual stack mode (as shown in Figure 3 and Figure 4).
住宅和小型办公室CPE设备可能仅限于支持一个地址系列。通常，它们由客户或运营商所有，他们不愿意或无法升级它们以双堆栈模式运行（如图3和图4所示）。
When the CPE router cannot run in dual-stack mode, a softwire will have to be established by a node located behind that CPE router. This can be accomplished either by a regular host in the home running softwire software (Figure 1 or Figure 3) or by a dedicated piece of hardware acting as the "IPv6 router" (Figure 4). Such a device is fairly simple in design and only requires one physical network
当CPE路由器无法在双堆栈模式下运行时，必须由位于该CPE路由器后面的节点建立软线。这可以通过家庭运行的softwire软件中的常规主机（图1或图3）或作为“IPv6路由器”的专用硬件（图4）来实现。这种设备在设计上相当简单，只需要一个物理网络
interface. Again, only the traffic of the mismatched AF will be forwarded via the softwire. Traffic that can otherwise be forwarded without a softwire should not be encapsulated.
界面同样，只有不匹配AF的通信量将通过软线转发。不应封装可以在没有软线的情况下转发的通信量。
2.3. Network Address Translation (NAT) and Port Address Translation (PAT)
2.3. 网络地址转换（NAT）和端口地址转换（PAT）
A typical case of non-upgradable CPE router is a pre-existing IPv4/ NAT home gateway, so the softwire solution must support NAT traversal.
不可升级CPE路由器的一个典型案例是预先存在的IPv4/NAT家庭网关，因此软线解决方案必须支持NAT穿越。
Establishing a Softwire through NAT or PAT must be supported without an explicit requirement to "autodetect" NAT or PAT presence during softwire setup. Simply enabling NAT traversal could be sufficient to meet this requirement.
必须支持通过NAT或PAT建立软线，而无需在软线设置期间“自动检测”NAT或PAT的存在。简单地启用NAT遍历就足以满足这一需求。
Although the tunneling protocol must be able to traverse NATs, tunneling protocols may have an optional capability to bypass UDP encapsulation if not traversing a NAT.
尽管隧道协议必须能够穿越NAT，但如果不穿越NAT，隧道协议可能具有绕过UDP封装的可选功能。
An important characteristic of this problem in IPv4 networks is that the carrier-facing CPE IP address is typically dynamically assigned. (The IP address of the node establishing the softwire behind the CPE router can also be dynamically assigned.)
IPv4网络中此问题的一个重要特征是，面向CPE IP地址的载波通常是动态分配的。（在CPE路由器后面建立软线的节点的IP地址也可以动态分配。）
Solutions like external dynamic DNS and dynamic NAT port forwarding have been deployed to deal with ever changing addresses, but it would be simpler if, in IPv6 networks, a static prefix was delegated to customers. Such a prefix would allow for the registration of stable addresses in the DNS and enable the use of solutions like RFC 3041 [RFC3041] privacy extension or cryptographically generated addresses (CGA) [RFC3972].
诸如外部动态DNS和动态NAT端口转发之类的解决方案已部署用于处理不断变化的地址，但如果在IPv6网络中，将静态前缀委托给客户，则会更简单。这样的前缀将允许在DNS中注册稳定地址，并允许使用诸如RFC 3041[RFC3041]隐私扩展或加密生成地址（CGA）[RFC3972]之类的解决方案。
The softwire protocol does not need to define a new method for prefix delegation; however, the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) prefix delegation [RFC3633] must be able to run over a softwire.
softwire协议不需要定义前缀委派的新方法；但是，IPv6（DHCPv6）前缀委派的动态主机配置协议[RFC3633]必须能够通过软线运行。
Link local addresses allocated at both ends of the tunnel are enough for packet forwarding, but for management purpose like traceroute, global addresses can be allocated using existing protocols such as stateless address auto-configuration [RFC2462] or DHCPv6 [RFC3315].
在隧道两端分配的链路本地地址足以进行数据包转发，但出于跟踪路由等管理目的，可以使用无状态地址自动配置[RFC2462]或DHCPv6[RFC3315]等现有协议分配全局地址。
The IP addresses of the softwire link itself do not need to be stable, the desire for stability only applies to the delegated prefix. Even if there is a single node attached behind a softwire
软线链路本身的IP地址不需要稳定，对稳定的渴望只适用于委派前缀。即使在软线后面连接了一个节点
link, nothing prevents a softwire concentrator to delegate it a /64 prefix.
链接，不阻止软线集中器将/64前缀委托给它。
Similarly, in the case of an IPv4 softwire, the address could be provided by means of DHCP [RFC2131]. In the case of an IPv4 softwire, a mechanism should be available in order to delegate an IPv4 prefix [SUBNET].
类似地，在IPv4软线的情况下，地址可以通过DHCP[RFC2131]提供。对于IPv4软线，应提供一种机制，以便委派IPv4前缀[子网]。
Note about 6to4: This is one of the main differences between Softwires and 6to4. 6to4 addresses will change every time the CPE router gets a new external address, where a DHCPv6 delegated prefix through a softwire link could be stable.
关于6to4的注意：这是软线和6to4之间的主要区别之一。每次CPE路由器获得新的外部地址时，6to4地址都会发生变化，其中通过软线链路的DHCPv6委托前缀可能是稳定的。
In the "Hubs and Spokes" problem, softwires are always initiated by the customer side. Thus, the node hosting the end of the softwire within the customer network is called the softwire initiator. It can run on any dual-stack node. As noted earlier, this can be the CPE access device, another dedicated CPE router behind the original CPE access device, or actually any kind of node (host, appliance, sensor, etc.).
在“集线器和辐条”问题中，软线总是由客户方发起。因此，在客户网络内托管软线末端的节点称为软线启动器。它可以在任何双堆栈节点上运行。如前所述，这可以是CPE接入设备、原始CPE接入设备后面的另一专用CPE路由器，或者实际上是任何类型的节点（主机、设备、传感器等）。
The softwire initiator node can change over time and may or may not be delegated the same IP address for the softwire endpoint. In particular, softwires should work in the nomadic case (e.g., a user opening up his laptop in various Wi-Fi hot-spots), where the softwire initiator could potentially obtain an IP address of one address family outside its original carrier network and still want to obtain the other address family addresses from its carrier.
软线发起方节点可以随时间而改变，并且可以或可以不被委派用于软线端点的相同IP地址。特别是，软线应在游牧情况下工作（例如，用户在各种Wi-Fi热点打开笔记本电脑），其中软线启动器可能在其原始运营商网络之外获得一个地址族的IP地址，并且仍然希望从其运营商处获得其他地址族地址。
If and when the IPv4 provider periodically changes the IPv4 address allocated to the gateway, the softwire initiator has to discover in a reasonable amount of time that the tunnel is down and restart it. This re-establishment should not change the IPv6 prefix and other parameters allocated to the site.
如果IPv4提供商定期更改分配给网关的IPv4地址，则软线启动器必须在合理的时间内发现隧道已关闭并重新启动。此重建不应更改分配给站点的IPv6前缀和其他参数。
On the carrier side, softwires are terminated on a softwire concentrator. A softwire concentrator is usually a dual-stack router connected to the dual-stack core of the carrier.
在载波侧，软线端接在软线集中器上。软线集中器通常是连接到载波的双栈核心的双栈路由器。
A carrier may deploy several softwire concentrators (for example one per POP) for scalability reasons.
出于可伸缩性的原因，运营商可以部署多个软线集中器（例如，每个POP一个）。
Softwire concentrators are usually not nomadic and have stable IP addresses.
软线集中器通常不是游牧式的，具有稳定的IP地址。
It may be the case that one of the address families is not natively supported on the interface facing the core of the carrier. Connectivity must then be provided by other tunnels, potentially using the softwire mesh model.
可能是其中一个地址族在面向载体核心的接口上不受本机支持。然后，必须由其他隧道提供连接，可能使用软线网格模型。
Softwire concentrator functionality will be based on existing standards for tunneling, prefixes, and addresses allocation, management. The working group must define a softwire concentrator architecture and interaction between these protocols and recommend profiles. These recommendations must take into account the distributed nature of the Softwires Concentrator in the provider network and the impact on core IPv6 networks (for instance: prefix aggregation).
软线集中器功能将基于隧道、前缀和地址分配、管理的现有标准。工作组必须定义软线集中器架构以及这些协议之间的交互，并推荐配置文件。这些建议必须考虑到提供商网络中软线集中器的分布式特性以及对核心IPv6网络的影响（例如：前缀聚合）。
The softwire initiator must know the DNS name or IP address of the softwire concentrator. An automated discovery phase may be used to return the IP address(s) or name(s) of the concentrator. Alternatively, this information may be configured by the user, or by the provider of the softwire initiator in advance. The details of this discovery problem are outside the scope of this document, however previous work could be taken in consideration. Examples include: [SERVICE-DIS], [RFC4891], and [TUN-AD].
软线启动器必须知道软线集中器的DNS名称或IP地址。自动发现阶段可用于返回集中器的IP地址或名称。可选地，该信息可以由用户或者由软线启动器的提供商预先配置。此发现问题的详细信息不在本文档的范围内，但是可以考虑以前的工作。示例包括：[SERVICE-DIS]、[RFC4891]和[TUN-AD]。
In a "Hubs and Spokes model", a carrier must be able to scale the solution to millions of softwire initiators by adding more hubs (i.e., softwire concentrators).
在“集线器和辐条模型”中，运营商必须能够通过添加更多集线器（即软线集中器）将解决方案扩展到数百万个软线启动器。
As customer networks are typically attached via a single link to their carrier, the minimum routing requirement is a default route for each of the address families.
由于客户网络通常通过单个链路连接到其运营商，因此最低路由要求是每个地址系列的默认路由。
Softwires must support multicast.
软线必须支持多播。
The softwire protocol must support customer authentication in the control plane, in order to authorize access to the service, and provide adequate logging of activity (accounting). However, a
softwire协议必须支持控制平面中的客户身份验证，以便授权访问服务，并提供足够的活动记录（记帐）。但是,
carrier may decide to turn it off in some circumstances, for instance, when the customer is already authenticated by some other means, such as closed networks, cellular networks, etc., in order to avoid unnecessary overhead.
在某些情况下，例如，当客户已经通过诸如封闭网络、蜂窝网络等其他方式进行身份验证时，运营商可以决定将其关闭，以避免不必要的开销。
The protocol should offer mutual authentication in scenarios where the initiator requires identity proof from the concentrator.
协议应在发起方要求集中器提供身份证明的情况下提供相互认证。
The softwire solution, at least for "Hubs and Spokes", must be integrable with commonly deployed AAA solutions (although extensions to those AAA solutions may be needed).
软线解决方案，至少对于“集线器和辐条”，必须与通常部署的AAA解决方案集成（尽管可能需要对这些AAA解决方案进行扩展）。
The softwire Control and/or Data plane must be able to provide full payload security (such as IPsec or SSL (Secure Socket Layer)) when desired. This additional protection must be separable from the tunneling aspect of the softwire mechanism itself. For IPsec, default profiles must be defined. [RFC4891] provides guidelines on this.
软线控制和/或数据平面必须能够在需要时提供完整的有效负载安全性（如IPsec或SSL（安全套接字层））。这种额外的保护必须与软线机制本身的隧道方面分开。对于IPsec，必须定义默认配置文件。[RFC4891]提供了这方面的指南。
As it is assumed that the softwire may have to go across NAT or PAT, a keepalive mechanism must be defined. Such a mechanism is also useful for dead peer detection. However in some circumstances (i.e., narrowband access, billing per traffic, etc.) the keepalive mechanism may consume unnecessary bandwidth, so turning it on or off, and modifying the periodicity, must be supported administrative options.
由于假定软线可能必须穿过NAT或PAT，因此必须定义保持机制。这种机制也适用于死点检测。但是，在某些情况下（即窄带访问、按流量计费等），keepalive机制可能会消耗不必要的带宽，因此必须支持打开或关闭该机制以及修改周期。
Other needed OAM features include:
其他需要的OAM功能包括：
- Logging
- 登录中
- Usage accounting
- 使用会计
- End-point failure detection (the detection mechanism must operate within the tunnel)
- 端点故障检测（检测机构必须在隧道内运行）
- Path failure detection (the detection mechanism must operate outside the tunnel)
- 路径故障检测（检测机构必须在隧道外运行）
IPv6/IPv4, IPv6/UDP/IPv4, and IPv4/IPv6 are on the critical path for "Hubs and Spokes" softwires. There is no intention to place limits on additional encapsulations beyond those explicitly mentioned in this specification.
IPv6/IPv4、IPv6/UDP/IPv4和IPv4/IPv6位于“集线器和辐条”软线的关键路径上。除了本规范中明确提到的封装之外，无意对其他封装进行限制。
We use the term "Mesh Problem" to describe the problem of supporting a general routed topology in which a backbone network that does not support a particular address family can be used as part of the path for packets that belong to that address family. For example, the path for an IPv4 packet might include a transit network that supports only IPv6. There might (or might not) be other paths that the IPv4 packet could take that do not use the IPv6 transit network; the actual path chosen will be determined by the IPv4 routing procedures.
我们使用术语“网格问题”来描述支持一般路由拓扑的问题，其中不支持特定地址族的主干网络可以用作属于该地址族的数据包的路径的一部分。例如，IPv4数据包的路径可能包括仅支持IPv6的传输网络。IPv4数据包可能（也可能不）采用不使用IPv6传输网络的其他路径；选择的实际路径将由IPv4路由过程确定。
By saying that the transit network supports only a single address family, we mean that the "core" routers of that network do not maintain routing information for other address families, and they may not even be able to understand the packet headers of other address families. We do suppose though that the core will have "edge routers" or "border routers", which maintain the routing information for both address families, and which can parse the headers of both address families. We refer to these as "Address Family Border Routers" (AFBRs).
如果说中转网络只支持一个地址族，我们的意思是，该网络的“核心”路由器不维护其他地址族的路由信息，甚至可能无法理解其他地址族的包头。我们确实假设核心将有“边缘路由器”或“边界路由器”，它们维护两个地址族的路由信息，并且可以解析两个地址族的头。我们称之为“地址家庭边界路由器”（AFBR）。
The following figure shows an AF2-only network connected to AF1-only networks, AF2-only networks, and dual stack networks. Note that in addition to paths through the AF2-only core, other paths may also exist between AF1 networks. The AFBRs that support AF1 would use BGP to exchange AF1 routing information between themselves, but such information would not be distributed to other core routers. The AFBRs would also participate in the exchange of AF2 routing information with the core nodes.
下图显示了连接到仅AF1网络、仅AF2网络和双堆栈网络的仅AF2网络。注意，除了通过仅AF2核心的路径外，AF1网络之间还可能存在其他路径。支持AF1的AFBR将使用BGP在它们之间交换AF1路由信息，但这些信息不会分发到其他核心路由器。AFBR还将参与与核心节点交换AF2路由信息。
+----------+ +----------+
|AF1 only | |AF1 only |
| | | |
+----------+ +----------+
| |
| |
Dual-Stack Dual-Stack
"AFBR" "AFBR"
| |
| |
+----------------------------+
| |
+-------+ | | +-------+
|AF2 | | AF2 only | |AF2 |
|only |-------| (but also providing |-------|only |
+-------+ | transit for AF1) | +-------+
| |
+----------------------------+
| / \ |
| / \ |
Dual-Stack Dual-Stack
"AFBR" "AFBR"
| | |
| | |
+--------+ +--------+
|AF1 and | |AF1 and |
|AF2 | |AF2 |
+--------+ +--------+
+----------+ +----------+
|AF1 only | |AF1 only |
| | | |
+----------+ +----------+
| |
| |
Dual-Stack Dual-Stack
"AFBR" "AFBR"
| |
| |
+----------------------------+
| |
+-------+ | | +-------+
|AF2 | | AF2 only | |AF2 |
|only |-------| (but also providing |-------|only |
+-------+ | transit for AF1) | +-------+
| |
+----------------------------+
| / \ |
| / \ |
Dual-Stack Dual-Stack
"AFBR" "AFBR"
| | |
| | |
+--------+ +--------+
|AF1 and | |AF1 and |
|AF2 | |AF2 |
+--------+ +--------+
Figure 5: Mesh Topology
图5：网格拓扑
The situation in which a pair of border routers use BGP to exchange routing information that is not known to the core routers is sometimes known, somewhat misleadingly, as a "BGP-free core". In this sort of scenario, the problems to be solved are (a) to make sure that the BGP-distributed routing updates for AF1 allow a given AFBR, say AFBR1, to see that the path for a given AF1 address prefix is through a second AFBR, say AFBR2, and (b) to provide a way in which AFBR1 can send AF1 packets through the AF2-only core to AFBR2. Of course, sending AF1 packets through an AF2-only core requires the AF1 packets to be encapsulated and sent through "tunnels"; these tunnels are the entities known as "softwires".
一对边界路由器使用BGP交换核心路由器不知道的路由信息的情况有时被称为“无BGP核心”，这有点误导。在这种情况下，需要解决的问题是（a）确保用于AF1的BGP分布式路由更新允许给定AFBR（例如AFBR1）查看给定AF1地址前缀的路径是通过第二个AFBR（例如AFBR2）的，以及（b）提供AFBR1可以通过仅AF2的核心向AFBR2发送AF1分组的方式。当然，通过仅AF2核心发送AF1分组需要封装AF1分组并通过“隧道”发送；这些隧道是被称为“软线”的实体。
One of the goals of the mesh problem is to provide a solution that does not require changes in any routers other than the AFBRs. This would allow a carrier (or large enterprise networks acting as carrier for their internal resources) with an AF2-only backbone to provide AF1 transit services for its clients, without requiring any changes
mesh问题的目标之一是提供一种解决方案，该解决方案不需要改变除afbr以外的任何路由器。这将允许具有仅AF2主干网的运营商（或作为其内部资源运营商的大型企业网络）为其客户提供AF1传输服务，而无需任何更改
whatsoever to the clients' routers, and without requiring any changes to the core routers. The AFBRs are the only devices that perform dual-stack operations, and the only devices that encapsulate and/or decapsulate the AF1 packets in order to send and/or receive them on softwires.
对客户端的路由器进行任何更改，而无需对核心路由器进行任何更改。AFBR是唯一执行双堆栈操作的设备，也是唯一封装和/或解除封装AF1数据包以便在软线上发送和/或接收数据包的设备。
It may be recognized that this scenario is very similar to the scenario handled by the Layer 3 Virtual Private Network (L3VPN) solution described in RFC 4364 [RFC4364]. The AFBRs correspond to the "Provider Edge Routers" (PE) of RFC 4364. In those L3VPN scenarios, the PEs exchange routing information in an address family (e.g., the VPN-IPv4 address family), but they send VPN data packets through a core which does not have the VPN routing information. However, the softwire problem is NOT focused on the situation in which the border routers maintain multiple private and/or overlapping address spaces. Techniques which are specifically needed to support multiple address spaces are in the domain of L3VPN, rather than in the domain of Softwires.
可以认识到，该场景与RFC 4364[RFC4364]中描述的第3层虚拟专用网络（L3VPN）解决方案处理的场景非常相似。AFBR对应于RFC 4364的“提供商边缘路由器”（PE）。在这些L3VPN方案中，PEs交换地址族（例如VPN-IPv4地址族）中的路由信息，但它们通过不具有VPN路由信息的核心发送VPN数据包。然而，软线问题并不集中于边界路由器维护多个私有和/或重叠地址空间的情况。专门用于支持多个地址空间的技术在L3VPN域中，而不是在软线域中。
Note that the AFBRs may be multiply connected to the core network, and also may be multiply connected to the client networks. Further, the client networks may have "backdoor connections" to each other, through private networks or through the Internet.
请注意，AFBR可以多路连接到核心网络，也可以多路连接到客户端网络。此外，客户端网络可以通过专用网络或通过因特网彼此具有“后门连接”。
In the mesh problem, the number of AFBRs that a backbone network supporting only AF2 will need is approximately on the order of the number of AF1 networks to which it connects. (This is really an upper limit, since a single AFBR can connect to many such networks).
在网状网问题中，仅支持AF2的主干网所需的AFBR数量大约等于其连接的AF1网络数量。（这实际上是一个上限，因为单个AFBR可以连接到许多这样的网络）。
An AFBR may need to exchange a "full Internet's" worth of routing information with each network to which it connects. If these networks are not VPNs, the scaling issues associated with the amount of routing information are just the usual scaling issues faced by the border routers of any network which is providing Internet transit services. (If the AFBRs are also attached to VPNs, the usual L3VPN scaling issues apply, as discussed in RFC 4364 [RFC4364] and RFC 4365 [RFC4365].) The number of BGP peering connections can be controlled through the usual methods, e.g., use of route reflectors.
AFBR可能需要与所连接的每个网络交换“完整互联网”的路由信息。如果这些网络不是VPN，则与路由信息量相关的扩展问题只是提供Internet传输服务的任何网络的边界路由器所面临的常见扩展问题。（如RFC 4364[RFC4364]和RFC 4365[RFC4365]中所述，如果AFBR也连接到VPN，则通常的L3VPN扩展问题适用）。BGP对等连接的数量可以通过通常的方法控制，例如使用路由反射器。
AFBRs may discover each other, and may obtain any necessary information about each other, as a byproduct of the exchange of routing information (essentially in the same way that PE routers discovery each other in L3VPNs). This may require the addition of new protocol elements or attributes to existing protocols.
作为路由信息交换的副产品，AFBR可以相互发现，并可以获得关于彼此的任何必要信息（基本上与PE路由器在L3VPN中相互发现的方式相同）。这可能需要向现有协议添加新的协议元素或属性。
The softwires needed to allow packets to be sent from one AFBR to another should be "always available", i.e., should not require any extended setup time that would impart an appreciable delay to the data packets.
允许包从一个AFBR发送到另一个AFBR所需的软线应该是“始终可用的”，即，不需要任何延长的设置时间，这将给数据包带来可观的延迟。
If the AF2 core does not provide native multicast services, multicast between AF1 client networks should still be possible, even though it may require replication at the AFBRs and unicasting of the replicated packets through Softwires. If native multicast services are enabled, it should be possible to use these services to optimize the multicast flow.
如果AF2核心不提供本机多播服务，则AF1客户端网络之间的多播仍然是可能的，即使它可能需要在AFBR处进行复制，并通过软线对复制的数据包进行单播。如果启用了本机多播服务，则应该可以使用这些服务来优化多播流。
The solution to the mesh problem must not require the use of any one encapsulation. Rather, it must accommodate the use of a variety of different encapsulation mechanisms, and a means for choosing the one to be used in any particular circumstance based on policy.
网格问题的解决方案不得要求使用任何一种封装。相反，它必须适应各种不同封装机制的使用，以及根据策略选择在任何特定情况下使用的封装机制的方法。
In particular, the solution to the mesh problem must allow for at least the following encapsulations to be used: Layer 2 Tunneling Protocol version 3 (L2TPv3), IP-in-IP, MPLS (LDP-based and RSVP-TE-based), Generic Routing Encapsulation (GRE), and IPsec. The choice of encapsulation is to be based on policy, and the policies themselves may be based on various characteristics of the packets, of the routes, or of the softwire endpoints themselves.
特别是，网状网问题的解决方案必须至少允许使用以下封装：第2层隧道协议版本3（L2TPv3）、IP-In-IP、MPLS（基于LDP和基于RSVP-TE）、通用路由封装（GRE）和IPsec。封装的选择将基于策略，并且策略本身可以基于分组、路由或软线端点本身的各种特征。
In the mesh problem, the routers are not advertising routes for individual users. So the mesh problem does not require the fine-grained authentication that is required by the "Hub and Spoke" problem. There should however be a way to provide various levels of security for the data packets being transmitted on a softwire. The softwire solution must support IPsec and an IPsec profile must be defined (see recommendations in [USEIPSEC]).
在网状网问题中，路由器不是为单个用户发布路由广告。因此，网格问题不需要“中心辐射”问题所需的细粒度身份验证。然而，应该有一种方法为在软线上传输的数据分组提供不同级别的安全性。softwire解决方案必须支持IPsec，并且必须定义IPsec配置文件（请参阅[USEIPSEC]中的建议）。
Security mechanisms for the control protocols are also required. It must be possible to protect control data from being modified in flight by an attacker, and to prevent an attacker from masquerading as a legitimate control protocol participant.
还需要控制协议的安全机制。必须能够防止攻击者在飞行中修改控制数据，并防止攻击者伪装成合法的控制协议参与者。
The verification of the reachability information exchanged and issues surrounding the security of routing protocols themselves is outside the scope of the specification.
交换的可达性信息的验证以及路由协议本身的安全性问题超出了规范的范围。
Security considerations specific to the "Hubs and Spokes" and "Mesh" models appear in those sections of the document.
“轮毂和辐条”和“网格”模型的特定安全注意事项出现在文档的这些部分中。
As with any tunneling protocol, using this protocol may introduce a security issue by circumventing a site security policy implemented as ingress filtering, since these filters will only be applied to STH AF IP headers.
与任何隧道协议一样，使用此协议可能会绕过作为入口过滤实现的站点安全策略，从而导致安全问题，因为这些过滤器将仅应用于IP头。
These are the principal authors for this document.
他们是本文件的主要作者。
Xing Li CERNET Room 225 Main Building, Tsinghua University Beijing 100084 China
中国北京清华大学兴利CERNET大楼225室，100084
Phone: +86 10 62785983
Fax: +86 10 62785933
Email: xing@cernet.edu.cn
Phone: +86 10 62785983
Fax: +86 10 62785933
Email: xing@cernet.edu.cn
Alain Durand Comcast 1500 Market st Philadelphia PA 19102 USA
美国宾夕法尼亚州费城市阿兰·杜兰德康卡斯特1500市场19102
Email: Alain_Durand@cable.comcast.com
Email: Alain_Durand@cable.comcast.com
Shin Miyakawa NTT Communications 3-20-2 TOC 21F, Nishi-shinjuku, Shinjuku Tokyo Japan
新宫川NTT通信3-20-2东京新宿西新宿TOC 21F
Phone: +81-3-6800-3262
Fax: +81-3-5365-2990
Email: miyakawa@nttv6.jp
Phone: +81-3-6800-3262
Fax: +81-3-5365-2990
Email: miyakawa@nttv6.jp
Jordi Palet Martinez Consulintel San Jose Artesano, 1 Alcobendas - Madrid E-28108 - Spain
Jordi Palet Martinez圣何塞Artesano领事馆，阿尔科本达斯1号-马德里E-28108-西班牙
Phone: +34 91 151 81 99
Fax: +34 91 151 81 98
Email: jordi.palet@consulintel.es
Phone: +34 91 151 81 99
Fax: +34 91 151 81 98
Email: jordi.palet@consulintel.es
Florent Parent Hexago 2875 boul. Laurier, suite 300 Sainte-Foy, QC G1V 2M2 Canada
弗洛伦特亲本Hexago 2875 boul。Laurier，加拿大QC G1V 2M2圣福伊300号套房
Phone: +1 418 266 5533
Email: Florent.Parent@hexago.com
Phone: +1 418 266 5533
Email: Florent.Parent@hexago.com
David Ward Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 USA
David Ward Cisco Systems 170 W.Tasman博士，加利福尼亚州圣何塞，美国95134
Phone: +1-408-526-4000
Email: dward@cisco.com
Phone: +1-408-526-4000
Email: dward@cisco.com
Eric C. Rosen Cisco Systems 1414 Massachusetts Avenue Boxborough, MA, 01716 USA
Eric C.Rosen Cisco Systems美国马萨诸塞州Boxborough马萨诸塞大道1414号，01716
Email: erosen@cisco.com
Email: erosen@cisco.com
The authors would like to acknowledge the following contributors who provided helpful inputs on earlier versions of this document: Alain Baudot, Hui Deng, Francis Dupont, Rob Evans, Ed Koehler Jr, Erik Nordmark, Soohong Daniel Park, Tom Pusateri, Pekka Savola, Bruno Stevant, Laurent Totain, Bill Storer, Maria (Alice) Dos Santos, Yong Cui, Chris Metz, Simon Barber, Skip Booth, Scott Wainner, and Carl Williams.
作者要感谢以下为本文件早期版本提供有用信息的贡献者：阿兰·博多、邓辉、弗朗西斯·杜邦、罗布·埃文斯、小埃德·科勒、埃里克·诺德马克、苏洪·丹尼尔·帕克、汤姆·普萨特里、佩卡·萨沃拉、布鲁诺·斯特万特、劳伦特·托坦、比尔·斯托尔、玛丽亚（爱丽丝）多斯桑托斯、崔勇、，克里斯·梅茨、西蒙·巴伯、斯基普·布斯、斯科特·韦纳和卡尔·威廉姆斯。
The authors would also like to acknowledge the participants in the Softwires interim meeting in Paris, France (October 11-12, 2005) (minutes are at http://bgp.nu/~dward/softwires/InterimMeetingMinutes.htm).
作者还想感谢在法国巴黎（2005年10月11日至12日）举行的软线临时会议的与会者（会议记录载于http://bgp.nu/~dward/softwires/interimetingminutes.htm）。
The authors would also like to express a special acknowledgement and thanks to Mark Townsley. Without his leadership, persistence, editing skills, and thorough suggestions for the document, we would have not have been successful.
作者还要特别感谢马克·汤斯利。如果没有他的领导、毅力、编辑技巧和对该文件的透彻建议，我们就不会成功。
Tunnel-based transition mechanisms have been under discussion in the IETF for more than a decade. Initial work related to softwire can be found in RFC 3053 [RFC3053]. The earlier "V6 Tunnel Configuration" BOF problem statement [GOALS-TUN] a reasonable pointer to prior work.
基于隧道的过渡机制已经在IETF中讨论了十多年。与软线相关的初始工作可在RFC 3053[RFC3053]中找到。早期的“V6隧道配置”BOF问题陈述[GOALS-TUN]是指向先前工作的合理指针。
The authors would like to acknowledge the work and support of Dr Jianping Wu of Tsinghua university.
作者要感谢清华大学吴建平博士的工作和支持。
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[RFC3041]Narten，T.和R.Draves，“IPv6中无状态地址自动配置的隐私扩展”，RFC 3041，2001年1月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053]Durand，A.，Fasano，P.，Guardini，I.，和D.Lento，“IPv6隧道代理”，RFC 3053，2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005.
[RFC3972]Aura，T.，“加密生成地址（CGA）”，RFC 39722005年3月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[GOALS-TUN] Palet, J., "Goals for Tunneling Configuration", Work in Progress, February 2005.
[GOALS-TUN]Palet，J.，“隧道配置的目标”，正在进行的工作，2005年2月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[RFC4364]Rosen，E.和Y.Rekhter，“BGP/MPLS IP虚拟专用网络（VPN）”，RFC 4364，2006年2月。
[RFC4365] Rosen, E., "Applicability Statement for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4365, February 2006.
[RFC4365]Rosen，E.“BGP/MPLS IP虚拟专用网络（VPN）的适用性声明”，RFC 4365，2006年2月。
[RFC4891] Graveman, R., Parthasarathy, M., Savola, P., and H. Tschofenig, "Using IPsec to Secure IPv6-in-IPv4 Tunnels", RFC 4891, May 2007.
[RFC4891]Graveman，R.，Parthasarathy，M.，Savola，P.，和H.Tschofenig，“使用IPsec保护IPv4隧道中的IPv6”，RFC 4891，2007年5月。
[SERVICE-DIS] Durand, A., "Service Discovery using NAPTR records in DNS", Work in Progress, October 2004.
[SERVICE-DIS]Durand，A.，“DNS中使用NAPTR记录的服务发现”，正在进行的工作，2004年10月。
[SUBNET] Johnson, R., "Subnet Allocation Option", Work in Progress, June 2007.
[子网]Johnson，R.，“子网分配选项”，正在进行的工作，2007年6月。
[TUN-AD] Palet, J. and M, "Analysis of IPv6 Tunnel End-point Discovery Mechanisms", Work in Progress, January 2005.
[TUN-AD]Palet，J.和M，“IPv6隧道端点发现机制的分析”，正在进行的工作，2005年1月。
[USEIPSEC] Bellovin, S., "Guidelines for Mandating the Use of IPsec", Work in Progress, February 2007.
[USEIPSEC]Bellovin，S.，“授权使用IPsec的指南”，正在进行的工作，2007年2月。
Authors' Addresses
作者地址
Xing Li (editor) CERNET Room 225 Main Building, Tsinghua University Beijing, 100084 China
邢莉（编辑）中国清华大学CERNET中心225室，北京，100084
Phone: +86 10 62785983
Fax: +86 10 62785933
EMail: xing@cernet.edu.cn
Phone: +86 10 62785983
Fax: +86 10 62785933
EMail: xing@cernet.edu.cn
Spencer Dawkins (editor) Huawei Technologies (USA) 1700 Alma Drive, Suite 100
斯宾塞·道金斯（编辑）华为技术（美国）阿尔玛大道1700号，100套房
Plano, TX 75075 US
德克萨斯州普莱诺75075美国
Phone: +1 972 509 0309
Fax: +1 469 229 5397
EMail: spencer@mcsr-labs.org
Phone: +1 972 509 0309
Fax: +1 469 229 5397
EMail: spencer@mcsr-labs.org
David Ward (editor) Cisco Systems 170 W. Tasman Dr. San Jose, CA 95134 US
David Ward（编辑）思科系统170 W.塔斯曼加利福尼亚州圣何塞博士95134美国
Phone: 1-408-526-4000 EMail: dward@cisco.com
电话：1-408-526-4000电子邮件：dward@cisco.com
Alain Durand (editor) Comcast 1500 Market St Philadelphia, PA 19102 US
Alain Durand（编辑）Comcast 1500 Market St Philadelphia，PA 19102美国
EMail: alain_durand@cable.comcast.com
EMail: alain_durand@cable.comcast.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编辑功能的资金目前由互联网协会提供。