Network Working Group A. Durand
Request for Comments: 3053 SUN Microsystems, Inc
Category: Informational P. Fasano
I. Guardini
CSELT S.p.A.
D. Lento
TIM
January 2001
Network Working Group A. Durand
Request for Comments: 3053 SUN Microsystems, Inc
Category: Informational P. Fasano
I. Guardini
CSELT S.p.A.
D. Lento
TIM
January 2001
IPv6 Tunnel Broker
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 Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
Abstract
摘要
The IPv6 global Internet as of today uses a lot of tunnels over the existing IPv4 infrastructure. Those tunnels are difficult to configure and maintain in a large scale environment. The 6bone has proven that large sites and Internet Service Providers (ISPs) can do it, but this process is too complex for the isolated end user who already has an IPv4 connection and would like to enter the IPv6 world. The motivation for the development of the tunnel broker model is to help early IPv6 adopters to hook up to an existing IPv6 network (e.g., the 6bone) and to get stable, permanent IPv6 addresses and DNS names. The concept of the tunnel broker was first presented at Orlando's IETF in December 1998. Two implementations were demonstrated during the Grenoble IPng & NGtrans interim meeting in February 1999.
到目前为止，IPv6全球互联网在现有IPv4基础设施上使用了许多隧道。这些隧道难以在大规模环境中进行配置和维护。6bone已经证明，大型站点和互联网服务提供商（ISP）可以做到这一点，但对于已经拥有IPv4连接并希望进入IPv6世界的孤立最终用户来说，这一过程过于复杂。开发隧道代理模型的动机是帮助早期IPv6采用者连接到现有IPv6网络（如6bone），并获得稳定、永久的IPv6地址和DNS名称。隧道经纪人的概念于1998年12月首次在奥兰多IETF上提出。1999年2月在格勒诺布尔IPng和NGtrans临时会议上演示了两种实现。
The growth of IPv6 networks started mainly using the transport facilities offered by the current Internet. This led to the development of several techniques to manage IPv6 over IPv4 tunnels. At present most of the 6bone network is built using manually configured tunnels over the Internet. The main drawback of this approach is the overwhelming management load for network administrators, who have to perform extensive manual configuration for each tunnel. Several attempts to reduce this management overhead
IPv6网络的发展主要是利用当前互联网提供的传输设施开始的。这导致了几种通过IPv4隧道管理IPv6的技术的发展。目前，6bone网络的大部分是通过互联网上手动配置的隧道构建的。这种方法的主要缺点是网络管理员的管理负担过重，他们必须为每个隧道执行大量的手动配置。减少此管理开销的几次尝试
have already been proposed and each of them presents interesting advantages but also solves different problems than the Tunnel Broker, or poses drawbacks not present in the Tunnel Broker:
已经提出，其中每一项都具有有趣的优点，但也解决了与隧道代理不同的问题，或者带来了隧道代理中不存在的缺点：
- the use of automatic tunnels with IPv4 compatible addresses [1] is a simple mechanism to establish early IPv6 connectivity among isolated dual-stack hosts and/or routers. The problem with this approach is that it does not solve the address exhaustion problem of IPv4. Also there is a great fear to include the complete IPv4 routing table into the IPv6 world because this would worsen the routing table size problem multiplying it by 5;
- 使用具有IPv4兼容地址的自动隧道[1]是在隔离的双栈主机和/或路由器之间建立早期IPv6连接的一种简单机制。这种方法的问题在于它不能解决IPv4的地址耗尽问题。此外，人们还非常担心将完整的IPv4路由表纳入IPv6世界，因为这会加剧路由表大小问题，将其乘以5；
- 6over4 [2] is a site local transition mechanism based on the use of IPv4 multicast as a virtual link layer. It does not solve the problem of connecting an isolated user to the global IPv6 Internet;
- 6over4[2]是一种基于使用IPv4多播作为虚拟链路层的站点本地转换机制。它不能解决将孤立用户连接到全球IPv6 Internet的问题；
- 6to4 [3] has been designed to allow isolated IPv6 domains, attached to a wide area network with no native IPv6 support (e.g., the IPv4 Internet), to communicate with other such IPv6 domains with minimal manual configuration. The idea is to embed IPv4 tunnel addresses into the IPv6 prefixes so that any domain border router can automatically discover tunnel endpoints for outbound IPv6 traffic.
- 6to4[3]的设计允许连接到广域网且不支持本机IPv6（如IPv4互联网）的独立IPv6域以最少的手动配置与其他此类IPv6域通信。其想法是将IPv4隧道地址嵌入IPv6前缀中，以便任何域边界路由器都可以自动发现出站IPv6流量的隧道端点。
The Tunnel Broker idea is an alternative approach based on the provision of dedicated servers, called Tunnel Brokers, to automatically manage tunnel requests coming from the users. This approach is expected to be useful to stimulate the growth of IPv6 interconnected hosts and to allow early IPv6 network providers to provide easy access to their IPv6 networks.
隧道代理思想是一种基于提供专用服务器（称为隧道代理）的替代方法，用于自动管理来自用户的隧道请求。预计这种方法将有助于刺激IPv6互连主机的增长，并使早期的IPv6网络提供商能够轻松访问其IPv6网络。
The main difference between the Tunnel Broker and the 6to4 mechanisms is that the they serve a different segment of the IPv6 community:
隧道代理和6to4机制之间的主要区别在于它们服务于IPv6社区的不同部分：
- the Tunnel Broker fits well for small isolated IPv6 sites, and especially isolated IPv6 hosts on the IPv4 Internet, that want to easily connect to an existing IPv6 network;
- 隧道代理非常适合小型孤立的IPv6站点，特别是IPv4 Internet上的孤立IPv6主机，这些站点希望轻松连接到现有IPv6网络；
- the 6to4 approach has been designed to allow isolated IPv6 sites to easily connect together without having to wait for their IPv4 ISPs to deliver native IPv6 services. This is very well suited for extranet and virtual private networks. Using 6to4 relays, 6to4 sites can also reach sites on the IPv6 Internet.
- 6to4方法的设计目的是允许隔离的IPv6站点轻松连接在一起，而无需等待其IPv4 ISP提供本机IPv6服务。这非常适合外联网和虚拟专用网络。使用6to4中继，6to4站点还可以连接到IPv6 Internet上的站点。
In addition, the Tunnel Broker approach allows IPv6 ISPs to easily perform access control on the users enforcing their own policies on network resources utilization.
此外，隧道代理方法允许IPv6 ISP轻松地对实施自己的网络资源利用策略的用户执行访问控制。
This document is intended to present a framework describing the guidelines for the provision of a Tunnel Broker service within the Internet. It does not specify any protocol but details the general architecture of the proposed approach. It also outlines a set of viable alternatives for implementing it. Section 2 provides an overall description of the Tunnel Broker model; Section 3 reports known limitations to the model; Section 4 briefly outlines other possible applications of the Tunnel Broker approach; Section 5 addresses security issues.
本文档旨在提供一个框架，描述在互联网中提供隧道代理服务的指南。它没有指定任何协议，但详细说明了拟议方法的总体架构。它还概述了一套可行的替代方案来实施它。第2节提供了隧道代理模型的总体描述；第3节报告了模型的已知限制；第4节简要概述了隧道代理法的其他可能应用；第5节涉及安全问题。
Tunnel brokers can be seen as virtual IPv6 ISPs, providing IPv6 connectivity to users already connected to the IPv4 Internet. In the emerging IPv6 Internet it is expected that many tunnel brokers will be available so that the user will just have to pick one. The list of the tunnel brokers should be referenced on a "well known" web page (e.g. on http://www.ipv6.org) to allow users to choose the "closest" one, the "cheapest" one, or any other one.
隧道代理可以被视为虚拟IPv6 ISP，为已经连接到IPv4 Internet的用户提供IPv6连接。在新兴的IPv6互联网中，预计将有许多隧道代理可用，因此用户只需选择一个即可。隧道经纪人名单应在“知名”网页（如http://www.ipv6.org)允许用户选择“最近的”、“最便宜的”或任何其他。
The tunnel broker model is based on the set of functional elements depicted in figure 1.
隧道代理模型基于图1所示的一组功能元素。
+------+
/|tunnel|
/ |server|
/ | |
/ +------+
+----------+ +------+/ +------+
|dual-stack| |tunnel| |tunnel|
| node |<--->|broker|<--->|server|
| (user) | | | | |
+----------+ +------+\ +------+
| \ +------+
tunnel end-point v \ |tunnel|
/\ +---+ \ |server|
|| |DNS| \| |
|| +---+ +------+
||
|| tunnel end-point
|| /\
|| ||
|+---------------------------+|
+-----------------------------+
IPv6 over IPv4 tunnel
+------+
/|tunnel|
/ |server|
/ | |
/ +------+
+----------+ +------+/ +------+
|dual-stack| |tunnel| |tunnel|
| node |<--->|broker|<--->|server|
| (user) | | | | |
+----------+ +------+\ +------+
| \ +------+
tunnel end-point v \ |tunnel|
/\ +---+ \ |server|
|| |DNS| \| |
|| +---+ +------+
||
|| tunnel end-point
|| /\
|| ||
|+---------------------------+|
+-----------------------------+
IPv6 over IPv4 tunnel
Figure 1: the Tunnel Broker model
图1：隧道代理模型
The TB is the place where the user connects to register and activate tunnels. The TB manages tunnel creation, modification and deletion on behalf of the user.
TB是用户连接以注册和激活隧道的地方。TB代表用户管理隧道的创建、修改和删除。
For scalability reasons the tunnel broker can share the load of network side tunnel end-points among several tunnel servers. It sends configuration orders to the relevant tunnel server whenever a tunnel has to be created, modified or deleted. The TB may also register the user IPv6 address and name in the DNS.
出于可伸缩性的原因，隧道代理可以在多个隧道服务器之间共享网络端隧道端点的负载。每当必须创建、修改或删除隧道时，它会向相关的隧道服务器发送配置命令。TB还可以在DNS中注册用户IPv6地址和名称。
A TB must be IPv4 addressable. It may also be IPv6 addressable, but this is not mandatory. Communications between the broker and the servers can take place either with IPv4 or IPv6.
TB必须是IPv4可寻址的。它也可以是IPv6可寻址的，但这不是强制性的。代理和服务器之间的通信可以通过IPv4或IPv6进行。
A TS is a dual-stack (IPv4 & IPv6) router connected to the global Internet. Upon receipt of a configuration order coming from the TB, it creates, modifies or deletes the server side of each tunnel. It may also maintain usage statistics for every active tunnel.
TS是连接到全球互联网的双栈（IPv4和IPv6）路由器。收到来自TB的配置命令后，它将创建、修改或删除每个隧道的服务器端。它还可以维护每个活动隧道的使用统计信息。
The client of the Tunnel Broker service is a dual-stack IPv6 node (host or router) connected to the IPv4 Internet. Approaching the TB, the client should be asked first of all to provide its identity and credentials so that proper user authentication, authorization and (optionally) accounting can be carried out (e.g., relying on existing AAA facilities such as RADIUS). This means that the client and the TB have to share a pre-configured or automatically established security association to be used to prevent unauthorized use of the service. With this respect the TB can be seen as an access-control server for IPv4 interconnected IPv6 users.
隧道代理服务的客户端是连接到IPv4 Internet的双堆栈IPv6节点（主机或路由器）。接近TB时，应首先要求客户提供其身份和凭证，以便进行适当的用户身份验证、授权和（可选）记帐（例如，依赖现有AAA设施，如RADIUS）。这意味着客户端和TB必须共享预配置或自动建立的安全关联，以防止未经授权使用服务。在这方面，TB可以被视为IPv4互连IPv6用户的访问控制服务器。
Once the client has been authorized to access the service, it should provide at least the following information:
一旦授权客户访问服务，它应至少提供以下信息：
- the IPv4 address of the client side of the tunnel;
- 隧道客户端的IPv4地址；
- a name to be used for the registration in the DNS of the global IPv6 address assigned to the client side of the tunnel;
- 用于在DNS中注册分配给隧道客户端的全局IPv6地址的名称；
- the client function (i.e., standalone host or router).
- 客户端功能（即独立主机或路由器）。
Moreover, if the client machine is an IPv6 router willing to provide connectivity to several IPv6 hosts, the client should be asked also to provide some information about the amount of IPv6 addresses required. This allows the TB to allocate the client an IPv6 prefix that fits its needs instead of a single IPv6 address.
此外，如果客户机是愿意提供到多个IPv6主机的连接的IPv6路由器，则还应要求客户机提供有关所需IPv6地址数量的一些信息。这允许TB为客户端分配符合其需要的IPv6前缀，而不是单个IPv6地址。
The TB manages the client requests as follows:
TB按如下方式管理客户端请求：
- it first designates (e.g., according to some load sharing criteria defined by the TB administrator) a Tunnel Server to be used as the actual tunnel end-point at the network side;
- 它首先指定（例如，根据TB管理员定义的一些负载共享标准）一个隧道服务器作为网络侧的实际隧道端点；
- it chooses the IPv6 prefix to be allocated to the client; the prefix length can be anything between 0 and 128, most common values being 48 (site prefix), 64 (subnet prefix) or 128 (host prefix);
- 选择要分配给客户端的IPv6前缀；前缀长度可以是0到128之间的任何值，最常见的值是48（站点前缀）、64（子网前缀）或128（主机前缀）；
- it fixes a lifetime for the tunnel;
- 它确定了隧道的寿命；
- it automatically registers in the DNS the global IPv6 addresses assigned to the tunnel end-points;
- 它自动在DNS中注册分配给隧道端点的全局IPv6地址；
- it configures the server side of the tunnel;
- 它配置隧道的服务器端；
- it notifies the relevant configuration information to the client, including tunnel parameters and DNS names.
- 它向客户端通知相关配置信息，包括隧道参数和DNS名称。
After the above configuration steps have been carried out (including the configuration of the client), the IPv6 over IPv4 tunnel between the client host/router and the selected TS is up and working, thus allowing the tunnel broker user to get access to the 6bone or any other IPv6 network the TS is connected to.
执行上述配置步骤（包括客户端的配置）后，客户端主机/路由器和所选TS之间的IPv6 over IPv4隧道启动并工作，从而允许隧道代理用户访问TS连接的6bone或任何其他IPv6网络。
The IPv6 addresses assigned to both sides of each tunnel must be global IPv6 addresses belonging to the IPv6 addressing space managed by the TB.
分配给每个隧道两侧的IPv6地址必须是属于TB管理的IPv6寻址空间的全局IPv6地址。
The lifetime of these IPv6 addresses should be relatively long and potentially longer than the lifetime of the IPv4 connection of the user. This is to allow the client to get semipermanent IPv6 addresses and associated DNS names even though it is connected to the Internet via a dial-up link and gets dynamically assigned IPv4 addresses through DHCP.
这些IPv6地址的生存期应该相对较长，并且可能比用户IPv4连接的生存期更长。这允许客户端获得半永久IPv6地址和相关DNS名称，即使它通过拨号链接连接到Internet，并通过DHCP获得动态分配的IPv4地址。
Active tunnels consume precious resources on the tunnel servers in terms of memory and processing time. For this reason it is advisable to keep the number of unused tunnels as small as possible deploying a well designed tunnel management mechanism.
活动隧道在内存和处理时间方面消耗隧道服务器上的宝贵资源。因此，建议使用设计良好的隧道管理机制，尽可能减少未使用隧道的数量。
Each IPv6 over IPv4 tunnel created by the TB should at least be assigned a lifetime and removed after its expiration unless an explicit lifetime extension request is submitted by the client.
TB创建的每个IPv6 over IPv4隧道应至少分配一个生存期，并在其到期后删除，除非客户端提交显式的生存期扩展请求。
Obviously this is not an optimal solution especially for users accessing the Internet through short-lived and dynamically addressed IPv4 connections (e.g., dial-up links). In this case a newly established tunnel is likely to be used just for a short time and then never again, in that every time the user reconnects he gets a new IPv4 address and is therefore obliged either to set-up a new tunnel or to update the configuration of the previous one. In such a situation a more effective tunnel management may be achieved by having the TS periodically deliver to the TB IPv6 traffic and reachability statistics for every active tunnel. In this way, the TB can enforce a tunnel deletion after a period of inactivity without waiting for the expiration of the related lifetime which can be relatively longer (e.g., several days).
显然，这不是一个最佳的解决方案，特别是对于通过短命和动态寻址的IPv4连接（例如拨号链接）访问Internet的用户而言。在这种情况下，新建立的隧道可能只使用一小段时间，然后再也不会使用，因为每次用户重新连接时，他都会获得一个新的IPv4地址，因此必须建立一个新的隧道或更新前一个隧道的配置。在这种情况下，可以通过让TS周期性地向TB发送每个活动隧道的IPv6流量和可达性统计数据来实现更有效的隧道管理。通过这种方式，TB可以在一段时间的不活动之后强制隧道删除，而无需等待相关生存期的到期，该相关生存期可以相对较长（例如，几天）。
Another solution may be to implement some kind of tunnel management protocol or keep-alive mechanism between the client and the TS (or between the client and the TB) so that each tunnel can be immediately released after the user disconnects (e.g., removing his tunnel end-point or tearing down his IPv4 connection to the Internet). The drawback of this policy mechanism is that it also requires a software upgrade on the client machine in order to add support for the ad-hoc keep-alive mechanism described above.
另一种解决方案可能是在客户端和TS（或客户端和TB）之间实施某种隧道管理协议或保持活动机制，以便在用户断开连接（例如，移除其隧道端点或断开其到Internet的IPv4连接）后立即释放每个隧道。此策略机制的缺点是，它还需要在客户端计算机上进行软件升级，以便添加对上述ad-hoc keep-alive机制的支持。
Moreover, keeping track of the tunnel configuration even after the user has disconnected from the IPv4 Internet may be worth the extra cost. In this way, in fact, when the user reconnects to the Internet, possibly using a different IPv4 address, he could just restart the tunnel by getting in touch with the TB again. The TB could then order a TS to re-create the tunnel using the new IPv4 address of the client but reusing the previously allocated IPv6 addresses. That way, the client could preserve a nearly permanent (static) IPv6 address even though its IPv4 address is dynamic. It could also preserve the associated DNS name.
此外，即使在用户已断开与IPv4 Internet的连接之后，也要跟踪隧道配置，这可能值得付出额外的成本。事实上，通过这种方式，当用户重新连接到Internet时（可能使用不同的IPv4地址），他可以通过再次联系TB重新启动隧道。然后，TB可以命令TS使用客户端的新IPv4地址重新创建隧道，但重用先前分配的IPv6地址。这样，客户机可以保留一个几乎永久（静态）的IPv6地址，即使其IPv4地址是动态的。它还可以保留关联的DNS名称。
As previously stated, the definition of a specific set of protocols and procedures to be used for the communication among the various entities in the Tunnel Broker architecture is outside of the scope of the present framework document. Nevertheless, in the reminder of this section some viable technical alternatives to support client-TB, TB-TS and TB-DNS interactions are briefly described in order to help future implementation efforts or standardization initiatives.
如前所述，用于隧道代理体系结构中各个实体之间通信的特定协议集和过程的定义不在本框架文档的范围内。然而，在本节的提醒中，简要介绍了一些支持客户端TB、TB-TS和TB-DNS交互的可行技术替代方案，以帮助未来的实施工作或标准化计划。
The interaction between the TB and the user could be based on http. For example the user could provide the relevant configuration information (i.e., the IPv4 address of the client side of the tunnel, etc.) by just filling up some forms on a Web server running on the TB. As a result the server could respond with an html page stating that the server end-point of the tunnel is configured and displaying all the relevant tunnel information.
TB和用户之间的交互可以基于http。例如，用户可以通过在TB上运行的Web服务器上填写一些表单来提供相关的配置信息（即隧道客户端的IPv4地址等）。因此，服务器可以响应一个html页面，说明已配置隧道的服务器端点，并显示所有相关的隧道信息。
After that, the most trivial approach would be to leave the user to configure the client end-point of the tunnel on his own. However, it should be highly valuable to support a mechanism to automate this procedure as much as possible.
之后，最简单的方法是让用户自己配置隧道的客户端端点。然而，支持一种尽可能自动化此过程的机制应该是非常有价值的。
Several options may be envisaged to assist the Tunnel Broker user in the configuration of his dual-stack equipment. The simplest option is that the TB could just prepare personalized activation and de-activation scripts to be run off-line on the client machine to achieve easy set-up of the client side tunnel end-point. This
可以设想几个选项来帮助隧道代理用户配置其双堆栈设备。最简单的选择是，TB只需准备个性化的激活和取消激活脚本，在客户端机器上离线运行，即可轻松设置客户端隧道端点。这
solution is clearly the easiest to implement and operate in that it does not require any software extension on the client machine. However, it raises several security concerns because it may be difficult for the user to verify that previously downloaded scripts do not perform illegal or dangerous operations once executed.
该解决方案显然是最容易实现和操作的，因为它不需要在客户机上进行任何软件扩展。但是，它会引起一些安全问题，因为用户可能很难验证以前下载的脚本在执行后是否不会执行非法或危险的操作。
The above described security issues could be elegantly overcome by defining a new MIME (Multipurpose Internet Mail Extension) content-type (e.g., application/tunnel) [4,5] to be used by the TB to deliver the tunnel parameters to the client. In this case, there must be a dedicated agent running on the client to process this information and actually set-up the tunnel end-point on behalf of the user. This is a very attractive approach which is worth envisaging. In particular, the definition of the new content-type might be the subject of a future ad-hoc document.
通过定义新的MIME（多用途Internet邮件扩展）内容类型（例如，应用程序/隧道）[4,5]供TB用于将隧道参数传递给客户端，可以优雅地克服上述安全问题。在这种情况下，必须在客户端上运行一个专用代理来处理此信息，并代表用户实际设置隧道端点。这是一个非常有吸引力的方法，值得设想。特别是，新内容类型的定义可能是未来特别文档的主题。
Several options are available also to achieve proper interaction between the broker and the Tunnel Servers. For example a set of simple RSH commands over IPsec could be used for this purpose. Another alternative could be to use SNMP or to adopt any other network management solution.
还有几个选项可用于在代理和隧道服务器之间实现适当的交互。例如，IPsec上的一组简单RSH命令可用于此目的。另一种选择是使用SNMP或采用任何其他网络管理解决方案。
Finally, the Dynamic DNS Update protocol [6] should be used for automatic DNS update (i.e., to add or delete AAAA, A6 and PTR records from the DNS zone reserved for Tunnel Broker users) controlled by the TB. A simple alternative would be for the TB to use a small set of RSH commands to dynamically update the direct and inverse databases on the authoritative DNS server for the Tunnel Broker users zone (e.g. broker.isp-name.com).
最后，动态DNS更新协议[6]应用于TB控制的自动DNS更新（即，从为隧道代理用户保留的DNS区域添加或删除AAAA、A6和PTR记录）。一个简单的替代方法是TB使用一小组RSH命令动态更新隧道代理用户区域（例如Broker.isp name.com）的权威DNS服务器上的直接和反向数据库。
Real usage of the TB service may require the introduction of accounting/billing functions.
TB服务的实际使用可能需要引入记帐/计费功能。
This mechanism may not work if the user is using private IPv4 addresses behind a NAT box.
如果用户在NAT箱后面使用专用IPv4地址，则此机制可能无法工作。
The Tunnel Broker approach might be efficiently exploited also to automatically set-up and manage any other kind of tunnel, such as a multicast tunnel (e.g., used to interconnect multicast islands within the unicast Internet) or an IPsec tunnel.
隧道代理方法还可以有效地用于自动设置和管理任何其他类型的隧道，例如多播隧道（例如，用于在单播因特网内互连多播岛）或IPsec隧道。
Moreover, the idea of deploying a dedicated access-control server, like the TB, to securely authorize and assist users that want to gain access to an IPv6 network might prove useful also to enhance other transition mechanisms. For example it would be possible to exploit a similar approach within the 6to4 model to achieve easy relay discovery. This would make life easier for early 6to4 adopters but would also allow the ISPs to better control the usage of their 6to4 relay facilities (e.g., setting up appropriate usage policies).
此外，部署一个专用的访问控制服务器（如TB）来安全地授权和帮助想要访问IPv6网络的用户的想法可能会被证明对增强其他转换机制也很有用。例如，可以在6to4模型中利用类似的方法来实现轻松的中继发现。这将使早期6to4采用者的生活更加轻松，但也将允许ISP更好地控制其6to4中继设施的使用（例如，制定适当的使用政策）。
All the interactions between the functional elements of the proposed architecture need to be secured:
所提议架构的功能元素之间的所有交互需要得到保护：
- the interaction between the client and TB;
- 客户与结核病之间的互动；
- the interaction between the TB and the Tunnel Server;
- TB与隧道服务器之间的交互；
- the interaction between the TB and the DNS.
- TB和DNS之间的交互。
The security techniques adopted for each of the required interactions is dependent on the implementation choices.
每个所需交互所采用的安全技术取决于实现选择。
For the client-TB interaction, the usage of http allows the exploitation of widely adopted security features, such as SSL (Secure Socket Layer) [7], to encrypt data sent to and downloaded from the web server. This also makes it possible to rely on a simple "username" and "password" authentication procedure and on existing AAA facilities (e.g., RADIUS) to enforce access-control.
对于客户端TB交互，http的使用允许利用广泛采用的安全特性，如SSL（安全套接字层）[7]，对发送到web服务器和从web服务器下载的数据进行加密。这也使得依靠简单的“用户名”和“密码”认证程序以及现有的AAA设施（如RADIUS）来实施访问控制成为可能。
For the TB-TS interaction secure SNMP could be adopted [8,9,10]. If the dynamic DNS update procedure is used for the TB-DNS interaction, the security issues are the same as discussed in [11]. Otherwise, if a simpler approach based on RSH commands is used, standard IPsec mechanisms can be applied [12].
对于TB-TS交互，可采用安全SNMP[8,9,10]。如果动态DNS更新过程用于TB-DNS交互，则安全问题与[11]中讨论的相同。否则，如果使用基于RSH命令的更简单方法，则可以应用标准IPsec机制[12]。
Furthermore, if the configuration of the client is achieved running scripts provided by the TB, these scripts must be executed with enough privileges to manage network interfaces, such as an administrator/root role. This can be dangerous and should be considered only for early implementations of the Tunnel Broker approach. Transferring tunnel configuration parameters in a MIME type over https is a more secure approach.
此外，如果客户机的配置是通过运行TB提供的脚本实现的，则必须以足够的权限执行这些脚本，以管理网络接口，例如管理员/根用户角色。这可能是危险的，应该只在隧道代理方法的早期实现中考虑。通过https以MIME类型传输隧道配置参数是一种更安全的方法。
In addition a loss of confidentiality may occur whenever a dial-up user disconnects from the Internet without tearing down the tunnel previously established through the TB. In fact, the TS keeps tunneling the IPv6 traffic addressed to that user to his old IPv4
此外，每当拨号用户断开与Internet的连接而不拆开先前通过TB建立的隧道时，可能会发生保密性损失。事实上，TS一直在通过隧道将发往该用户的IPv6流量传输到他的旧IPv4
address regardless of the fact that in the meanwhile that IPv4 address could have been dynamically assigned to another subscriber of the same dial-up ISP. This problem could be solved by implementing on every tunnel the keep-alive mechanism outlined in section 2.5 thus allowing the TB to immediately stop IPv6 traffic forwarding towards disconnected users.
地址，而不管同时IPv4地址可能已动态分配给同一拨号ISP的另一个订户。这个问题可以通过在每个隧道上实施第2.5节中概述的保持活动机制来解决，从而允许TB立即停止向断开连接的用户转发IPv6流量。
Finally TBs must implement protections against denial of service attacks which may occur whenever a malicious user exhausts all the resources available on the tunnels server by asking for a lot of tunnels to be established altogether. A possible protection against this attack could be achieved by administratively limiting the number of tunnels that a single user is allowed to set-up at the same time.
最后，TBs必须实施针对拒绝服务攻击的保护，当恶意用户通过请求建立大量隧道耗尽隧道服务器上的所有可用资源时，可能会发生拒绝服务攻击。通过管理性地限制允许单个用户同时设置的隧道数量，可以实现针对此攻击的可能保护。
Some of the ideas refining the tunnel broker model came from discussion with Perry Metzger and Marc Blanchet.
改进隧道经纪人模型的一些想法来自于与佩里·梅茨格（Perry Metzger）和马克·布兰切特（Marc Blanchet）的讨论。
[1] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[1] Gilligan，R.和E.Nordmark，“IPv6主机和路由器的过渡机制”，RFC 1933，1996年4月。
[2] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[2] Carpenter，B.和C.Jung，“无显式隧道的IPv4域上IPv6传输”，RFC 2529，1999年3月。
[3] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds without Explicit Tunnels", Work in Progress.
[3] Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域而无显式隧道”，工作正在进行中。
[4] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC 2045, November 1996.
[4] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第一部分：互联网邮件正文格式，RFC 20451996年11月。
[5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[5] Freed，N.和N.Borenstein，“多用途互联网邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[6] Vixie, P., Editor, Thomson, T., Rekhter, Y. and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[6] Vixie，P.，编辑，Thomson，T.，Rekhter，Y.和J.Bound，“域名系统中的动态更新（DNS更新）”，RFC 21361997年4月。
[7] Guttman, E., Leong, L. and G. Malkin, "Users' Security Handbook", FYI 34, RFC 2504, February 1999.
[7] Guttman，E.，Leong，L.和G.Malkin，“用户安全手册”，FYI 34，RFC 2504，1999年2月。
[8] Wijnen, B., Harrington, D. and R. Presuhn, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 1999.
[8] Wijnen，B.，Harrington，D.和R.Presuhn，“描述SNMP管理框架的体系结构”，RFC 2571，1999年4月。
[9] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 1999.
[9] Blumenthal，U.和B.Wijnen，“简单网络管理协议（SNMPv3）第3版的基于用户的安全模型（USM）”，RFC 2574，1999年4月。
[10] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.
[10] Wijnen，B.，Presuhn，R.和K.McCloghrie，“用于简单网络管理协议（SNMP）的基于视图的访问控制模型（VACM）”，RFC2575，1999年4月。
[11] Eastlake, D., "Secure Domain Name System Dynamic Update", RFC 2137, April 1997.
[11] Eastlake，D.，“安全域名系统动态更新”，RFC 2137，1997年4月。
[12] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[12] Kent，S.和R.Atkinson，“互联网协议的安全架构”，RFC 2401，1998年11月。
Alain Durand SUN Microsystems, Inc 901 San Antonio Road MPK17-202 Palo Alto, CA 94303-4900 USA
美国加利福尼亚州帕洛阿尔托市圣安东尼奥路901号Alain Durand SUN Microsystems，Inc.MPK17-202，邮编94303-4900
Phone: +1 650 786 7503
EMail: Alain.Durand@sun.com
Phone: +1 650 786 7503
EMail: Alain.Durand@sun.com
Paolo Fasano S.p.A. CSELT S.p.A. Switching and Network Services - Networking via G. Reiss Romoli, 274 10148 TORINO Italy
Paolo Fasano S.p.A.CSELT S.p.A.交换和网络服务-通过G.Reiss Romoli进行网络连接，意大利都灵274 10148
Phone: +39 011 2285071
EMail: paolo.fasano@cselt.it
Phone: +39 011 2285071
EMail: paolo.fasano@cselt.it
Ivano Guardini CSELT S.p.A. Switching and Network Services - Networking via G. Reiss Romoli, 274 10148 TORINO Italy
Ivano Guardini CSELT S.p.A.交换和网络服务-通过G.Reiss Romoli联网，274 10148意大利都灵
Phone: +39 011 2285424
EMail: ivano.guardini@cselt.it
Phone: +39 011 2285424
EMail: ivano.guardini@cselt.it
Domenico Lento TIM Business Unit Project Management via Orsini, 9 90100 Palermo Italy
Domenico Lento TIM事业部项目管理部via Orsini，9 90100意大利巴勒莫
Phone: +39 091 7583243
EMail: dlento@mail.tim.it
Phone: +39 091 7583243
EMail: dlento@mail.tim.it
Copyright (C) The Internet Society (2001). All Rights Reserved.
版权所有（C）互联网协会（2001年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。