Internet Engineering Task Force (IETF) R. Gagliano
Request for Comments: 5963 Cisco Systems
Category: Informational August 2010
ISSN: 2070-1721
Internet Engineering Task Force (IETF) R. Gagliano
Request for Comments: 5963 Cisco Systems
Category: Informational August 2010
ISSN: 2070-1721
IPv6 Deployment in Internet Exchange Points (IXPs)
Internet交换点（IXP）中的IPv6部署
Abstract
摘要
This document provides guidance on IPv6 deployment in Internet Exchange Points (IXPs). It includes information regarding the switch fabric configuration, the addressing plan and general organizational tasks that need to be performed. IXPs are mainly a Layer 2 infrastructure, and, in many cases, the best recommendations suggest that the IPv6 data, control, and management plane should not be handled differently than in IPv4.
本文档提供了有关在Internet交换点（IXP）中部署IPv6的指导。它包括有关交换机结构配置、寻址计划和需要执行的一般组织任务的信息。IXP主要是第2层基础设施，在许多情况下，最好的建议是IPv6数据、控制和管理平面的处理方式不应与IPv4不同。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5963.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5963.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Switch Fabric Configuration .....................................2
3. Addressing Plan .................................................3
4. Multicast IPv6 ..................................................5
4.1. Multicast Support and Monitoring for Neighbor
Discovery at an IXP ........................................6
4.2. IPv6 Multicast Traffic Exchange at an IXP ..................6
5. Reverse DNS .....................................................7
6. Route-Server ....................................................7
7. External and Internal Support ...................................7
8. IXP Policies and IPv6 ...........................................8
9. Security Considerations .........................................8
10. Acknowledgements ...............................................8
11. Informative References .........................................8
1. Introduction ....................................................2
2. Switch Fabric Configuration .....................................2
3. Addressing Plan .................................................3
4. Multicast IPv6 ..................................................5
4.1. Multicast Support and Monitoring for Neighbor
Discovery at an IXP ........................................6
4.2. IPv6 Multicast Traffic Exchange at an IXP ..................6
5. Reverse DNS .....................................................7
6. Route-Server ....................................................7
7. External and Internal Support ...................................7
8. IXP Policies and IPv6 ...........................................8
9. Security Considerations .........................................8
10. Acknowledgements ...............................................8
11. Informative References .........................................8
Most Internet Exchange Points (IXPs) work at the Layer 2 level, making the adoption of IPv6 an easy task. However, IXPs normally implement additional services such as statistics, route servers, looking glasses, and broadcast controls that may be impacted by the implementation of IPv6. This document clarifies the impact of IPv6 on a new or an existing IXP. The document assumes an Ethernet switch fabric, although other Layer 2 configurations could be deployed.
大多数Internet交换点（IXP）都在第2层工作，因此采用IPv6非常容易。但是，IXP通常会实现额外的服务，如统计、路由服务器、窥镜和广播控制，这些服务可能会受到IPv6实现的影响。本文档阐明了IPv6对新IXP或现有IXP的影响。本文档假定使用以太网交换机结构，但也可以部署其他第2层配置。
An Ethernet-based IXP switch fabric implements IPv6 over Ethernet as described in [RFC2464] . Therefore, the switching of IPv6 traffic happens in the same way as in IPv4. However, some management functions (such as switch management, SNMP (Simple Network Management Protocol) [RFC3411] support, or flow analysis exportation) may require IPv6 as an underlying layer, and this should be assessed by the IXP operator.
基于以太网的IXP交换结构通过以太网实现IPv6，如[RFC2464]中所述。因此，IPv6流量的切换与IPv4中的切换方式相同。但是，某些管理功能（如交换机管理、SNMP（简单网络管理协议）[RFC3411]支持或流分析导出）可能需要IPv6作为底层，这应由IXP运营商进行评估。
There are two common configurations of IXP switch ports to support IPv6:
支持IPv6的IXP交换机端口有两种常见配置：
1. dual-stack LAN (Local Area Network): when both IPv4 and IPv6 traffic share a common LAN. No extra configuration is required in the switch.
1. 双栈LAN（局域网）：当IPv4和IPv6流量共享一个公共LAN时。交换机中不需要额外配置。
2. independent VLAN (Virtual Local Area Network)[IEEE.P802-1Q.1998]: when an IXP logically separates IPv4 and IPv6 traffic in different VLANs.
2. 独立VLAN（虚拟局域网）[IEEE.P802-1Q.1998]：当一个IXP在不同VLAN中从逻辑上分离IPv4和IPv6流量时。
In both configurations, IPv6 and IPv4 traffic can either share a common physical port or use independent physical ports. The use of independent ports can be more costly in both capital expenses (as new ports are needed) and operational expenses.
在这两种配置中，IPv6和IPv4通信既可以共享一个公共物理端口，也可以使用独立的物理端口。独立港口的使用在资本费用（因为需要新的港口）和运营费用方面都可能更加昂贵。
When using the same physical port for both IPv4 and IPv6 traffic, some changes may be needed at the participants' interfaces' configurations. If the IXP implements the "dual-stack configuration", IXP's participants will configure dual-stack interfaces. On the other hand, if the IXP implements the "independent VLAN configuration", IXP participants are required to pass one additional VLAN tag across the interconnection. In this case, if the IXP did not originally use VLAN tagging, VLAN tagging should be established and the previously configured LAN may continue untagged as a "native VLAN" or be transitioned to a tagged VLAN. The "independent VLAN" configuration provides a logical separation of IPv4 and IPv6 traffic, simplifying separate statistical analysis for IPv4 and IPv6 traffic. Conversely, the "dual-stack" configuration (when performing separate statistical analysis for IPv4 and IPv6 traffic) would require the use of flow techniques such as IPFIX (IP Flow Information Export) [RFC5101] to classify traffic based on the different Ethertypes (0x0800 for IPv4, 0x0806 for ARP (Address Resolution Protocol), and 0x86DD for IPv6).
当对IPv4和IPv6通信使用相同的物理端口时，可能需要在参与者的接口配置中进行一些更改。如果IXP实现“双堆栈配置”，IXP的参与者将配置双堆栈接口。另一方面，如果IXP实现“独立VLAN配置”，则IXP参与者需要在互连中传递一个额外的VLAN标记。在这种情况下，如果IXP最初没有使用VLAN标记，则应建立VLAN标记，并且先前配置的LAN可以继续未标记为“本机VLAN”或转换为标记的VLAN。“独立VLAN”配置提供了IPv4和IPv6流量的逻辑分离，简化了IPv4和IPv6流量的单独统计分析。相反，“双栈”配置（在对IPv4和IPv6流量执行单独的统计分析时）需要使用流技术，例如IPFIX（IP流信息导出）[RFC5101]来根据不同的以太网类型对流量进行分类（0x0800用于IPv4，0x0806用于ARP（地址解析协议），0x86DD用于IPv6）.
The only technical requirement for IPv6 referring link MTUs is that they need to be greater than or equal to 1280 octets [RFC2460]. The MTU size for every LAN in an IXP should be well known by all its participants.
IPv6参考链路MTU的唯一技术要求是它们需要大于或等于1280个八位字节[RFC2460]。IXP中每个LAN的MTU大小应该为其所有参与者所熟知。
Regional Internet Registries (RIRs) have specific address policies to assign Provider Independent (PI) IPv6 addresses to IXPs. Those allocations are usually /48 or shorter prefixes [RIR_IXP_POLICIES]. Depending on the country and region of operation, address assignments may be made by NIRs (National Internet Registries). Unique Local IPv6 Unicast Addresses ([RFC4193]) are normally not used in an IXP LAN as global reverse DNS resolution and whois services are required.
区域Internet注册中心（RIR）具有特定的地址策略，可将独立于提供商（PI）的IPv6地址分配给IXP。这些分配通常是/48或更短的前缀[RIR_IXP_策略]。根据运营的国家和地区，地址分配可能由NIRs（国家互联网注册中心）进行。唯一的本地IPv6单播地址（[RFC4193]）通常不在IXP LAN中使用，因为需要全局反向DNS解析和whois服务。
IXPs will normally use manual address configuration. The manual configuration of IPv6 addresses allows IXP participants to replace network interfaces with no need to reconfigure Border Gateway Protocol (BGP) sessions' information, and it also facilitates management tasks. The IPv6 Addressing Architecture [RFC4291] requires that interface identifiers are 64 bits in size for prefixes not starting with binary 000, resulting in a maximum prefix length of /64. Longer prefix lengths up to /127 have been used operationally.
IXPs通常使用手动地址配置。IPv6地址的手动配置允许IXP参与者更换网络接口，而无需重新配置边界网关协议（BGP）会话的信息，并且它还方便了管理任务。IPv6寻址体系结构[RFC4291]要求对于不以二进制000开头的前缀，接口标识符的大小为64位，从而导致最大前缀长度为/64。在操作上使用了长至/127的前缀长度。
If prefix lengths longer than 64 bits are chosen, the implications described in [RFC3627] need to be considered. A /48 prefix allows the addressing of 65536 /64 LANs.
如果选择的前缀长度大于64位，则需要考虑[RFC3627]中所述的含义。A/48前缀允许寻址65536/64 LAN。
When selecting the use of static Interface Identifiers (IIDs), there are different options on how to fill its 64 bits (or 16 hexadecimal characters). A non-exhaustive list of possible IID selection mechanisms is the following:
选择使用静态接口标识符（IID）时，对于如何填充其64位（或16个十六进制字符）有不同的选项。可能的IID选择机制的非详尽列表如下：
1. Some IXPs like to include the decimal encoding of each participant's ASN (Autonomous System Number) inside its correspondent IPv6 address. The ASN decimal number is used as the BCD (binary code decimal) encoding of the upper part of the IID such as shown in this example:
1. 一些IXP喜欢在其相应的IPv6地址中包含每个参与者的ASN（自治系统编号）的十进制编码。ASN十进制数用作IID上部的BCD（二进制代码十进制）编码，如本例所示：
* IXP LAN prefix: 2001:db8::/64
* IXP LAN前缀：2001:db8:：/64
* ASN: 64496
* ASN:64496
* IPv6 Address: 2001:db8:0000:0000:0000:0006:4496:0001/64 or its equivalent representation 2001:db8::6:4496:1/64
* IPv6地址：2001:db8:0000:0000:0000:0006:4496:0001/64或其等效表示形式2001:db8:：6:4496:1/64
In this example, we are right-justifying the participant's ASN number from the 112nd bit. Remember that 32-bit ASNs require a maximum of 10 characters. With this example, up to 2^16 IPv6 addresses can be configured per ASN.
在本例中，我们从第112位正确地证明了参与者的ASN编号。请记住，32位ASN最多需要10个字符。在本例中，每个ASN最多可以配置2^16个IPv6地址。
2. Although BCD encoding is more "human-readable", some IXPs prefer to use the hexadecimal encoding of the ASNs number as the upper part of the IID as follow:
2. 尽管BCD编码更“易于阅读”，但一些IXP更喜欢使用ASNs编号的十六进制编码作为IID的上半部分，如下所示：
* IXP LAN prefix: 2001:db8::/64
* IXP LAN前缀：2001:db8:：/64
* ASN: 64496 (DEC) or fbf0 (HEX)
* ASN:64496（DEC）或fbf0（十六进制）
* IPv6 Address: 2001:db8:0000:0000:0000:0000:fbf0:0001/64 or its equivalent representation 2001:db8::fbf0:1/64
* IPv6地址：2001:db8:0000:0000:0000:0000:fbf0:0001/64或其等效表示形式2001:db8:：fbf0:1/64
In this case, a maximum of 8 characters will be needed to represent 32-bit ASNs.
在这种情况下，最多需要8个字符来表示32位ASN。
3. A third scheme for statically assigning IPv6 addresses on an IXP LAN could be to relate some portions of a participant's IPv6 address to its IPv4 address. In the following example, the last four decimals of the IPv4 address are copied to the last hexadecimals of the IPv6 address, using the decimal number as the BCD encoding for the last three characters of the IID such as in the following example:
3. 在IXP LAN上静态分配IPv6地址的第三种方案是将参与者的IPv6地址的某些部分与其IPv4地址关联起来。在以下示例中，IPv4地址的最后四位小数复制到IPv6地址的最后十六位小数，使用十进制数作为IID最后三个字符的BCD编码，如以下示例中所示：
* IXP LAN prefix: 2001:db8::/64
* IXP LAN前缀：2001:db8:：/64
* IPv4 Address: 192.0.2.123/23
* IPv4地址：192.0.2.123/23
* IPv6 Address: 2001:db8:2::123/64
* IPv6地址：2001:db8:2:：123/64
4. A fourth approach might be based on the IXPs ID for that participant.
4. 第四种方法可能基于该参与者的IXPs ID。
IPv6 prefixes for IXP LANs are typically publicly well known and taken from dedicated IPv6 blocks for IXP assignments reserved for this purpose by the different RIRs. These blocks are usually only meant for addressing the exchange fabric, and may be filtered out by DFZ (Default Free Zone) operators. When considering the routing of the IXP LANs two options are identified:
IXP LAN的IPv6前缀通常是众所周知的，并取自专用IPv6块，用于不同RIR为此目的保留的IXP分配。这些块通常仅用于对exchange结构进行寻址，并且可能会被DFZ（默认自由区）操作符过滤掉。在考虑IXP LAN的路由时，确定了两个选项：
o IXPs may decide that LANs should not to be globally routed in order to limit the possible origins of a Denial-of-Service (DoS) attack to its participants' AS (Autonomous System) boundaries. In this configuration, participants may route these prefixes inside their networks (e.g., using BGP no-export communities or routing the IXP LANs within the participants' IGP) to perform fault management. Using this configuration, the monitoring of the IXP LANs from outside of its participants' AS boundaries is not possible.
o IXP可能会决定LAN不应进行全局路由，以便将拒绝服务（DoS）攻击的可能来源限制在其参与者的AS（自治系统）边界。在此配置中，参与者可在其网络内路由这些前缀（例如，使用BGP no export社区或在参与者的IGP内路由IXP LAN）以执行故障管理。使用此配置，无法从参与者的AS边界外部监视IXP LAN。
o IXP may decide that LANs should (attempt to) be globally routed. In this case, IXP LANs monitoring from outside its participants' AS boundaries may be possible, but the IXP LANs will be vulnerable to DoS from outside of those boundaries.
o IXP可以决定LAN应该（尝试）进行全局路由。在这种情况下，IXP LAN可能会从参与者的AS边界之外进行监视，但IXP LAN将容易受到来自这些边界之外的DoS的攻击。
Additionally, possible IXP external services (such as DNS, web pages, FTP servers) need to be globally routed. These should be addressed from separate address blocks, either from upstream providers' address space or separate independent assignments. Strict prefix length filtering could be a reason for requesting more than one /48 assignment from a RIR (i.e., requesting one /48 assignment for the IXPs LANs that may not be globally routed and a different, non-IXP /48 assignment for the IXP external services that will be globally routed).
此外，可能的IXP外部服务（如DNS、网页、FTP服务器）需要全局路由。这些应该从单独的地址块寻址，或者从上游提供者的地址空间，或者从单独的独立分配。严格的前缀长度筛选可能是从RIR请求多个/48分配的原因（即，为可能不全局路由的IXPs LAN请求一个/48分配，为将全局路由的IXP外部服务请求不同的非IXP/48分配）。
There are two elements that need to be evaluated when studying IPv6 multicast in an IXP: multicast support for neighbor discovery and multicast peering.
在IXP中研究IPv6多播时，需要评估两个要素：对邻居发现的多播支持和多播对等。
IXPs typically control broadcast traffic across the switching fabric in order to avoid broadcast storms by only allowing limited ARP [RFC0826] traffic for address resolution. In IPv6 there is not broadcast support, but IXPs may intend to control multicast traffic in each LAN instead. ICMPv6 Neighbor Discovery [RFC4861] implements the following necessary functions in an IXP switching fabric: Address Resolution, Neighbor Unreachability Detection, and Duplicate Address Detection. In order to perform these functions, Neighbor Solicitation and Neighbor Advertisement packets are exchanged using the link-local all-nodes multicast address (ff02::1) and/or solicited-node multicast addresses (ff02:0:0:0:0:1:ff00:0000 to ff02: 0:0:0:0:1:ffff:ffff). As described in [RFC4861], routers will initialize their interfaces by joining their solicited-node multicast addresses using either Multicast Listener Discovery (MLD) [RFC2710] or MLDv2 [RFC3810]. MLD messages may be sent to the corresponding group address: ff02::2 (MLD) or ff02::16 (MLDv2). Depending on the addressing plan selected by the IXP, each solicited-node multicast group may be shared by a sub-set of participants' conditioned by how the last three octets of the addresses are selected. In Section 3, example 1, only participants with ASNs with the same last two digits are going to share the same solicited-node multicast group.
IXP通常通过交换结构控制广播流量，通过仅允许有限的ARP[RFC0826]流量进行地址解析来避免广播风暴。在IPv6中不支持广播，但IXPs可能打算控制每个LAN中的多播流量。ICMPv6邻居发现[RFC4861]在IXP交换结构中实现以下必要功能：地址解析、邻居不可达性检测和重复地址检测。为了执行这些功能，使用链路本地所有节点多播地址（ff02:：1）和/或请求的节点多播地址（ff02:0:0:1:ff00:0000到ff02:0:0:0:0:0:1:ffff）交换邻居请求和邻居播发数据包。如[RFC4861]中所述，路由器将通过使用多播侦听器发现（MLD）[RFC2710]或MLDv2[RFC3810]加入其请求的节点多播地址来初始化其接口。MLD消息可以发送到相应的组地址：ff02:：2（MLD）或ff02:：16（MLDv2）。根据IXP选择的寻址计划，每个请求节点多播组可由参与者的子集共享，条件是如何选择地址的最后三个八位组。在第3节示例1中，只有具有最后两位数字相同的ASN的参与者才能共享同一请求节点多播组。
Similar to the ARP policy, an IXP may limit multicast traffic across the switching fabric in order to only allow ICMPv6 Neighbor Solicitation, Neighbor Advertisement, and MLD messages. Configuring default routes in an IXP LAN without an agreement between the parties is normally against IXP policies. ICMPv6 Router Advertisement packets should neither be issued nor accepted by routers connected to the IXP. Where possible, the IXP operator should block link-local RA (Router Advertisement) packets using IPv6 RA-GUARD [V6OPS-RA-GUARD] . If this is not possible, the IXP operator should monitor the exchange for rogue Router Advertisement packets as described in [V6OPS-ROGUE-RA] .
与ARP策略类似，IXP可以限制交换结构上的多播通信量，以便仅允许ICMPv6邻居请求、邻居广告和MLD消息。在没有各方协议的情况下在IXP LAN中配置默认路由通常是违反IXP策略的。连接到IXP的路由器不应发布或接受ICMPv6路由器广告数据包。在可能的情况下，IXP运营商应使用IPv6 RA-GUARD[V6OPS-RA-GUARD]阻止链路本地RA（路由器广告）数据包。如果这是不可能的，IXP运营商应按照[V6OPS-ROGE-RA]中所述，监控交换的恶意路由器广告数据包。
For IPv6 Multicast traffic exchange, an IXP may decide to use either the same LAN being used for unicast IPv6 traffic exchange, the same LAN being used for IPv4 Multicast traffic exchange, or a dedicated LAN for IPv6 Multicast traffic exchange. The reason for having a dedicated LAN for multicast is to prevent unwanted multicast traffic from reaching participants that do not have multicast support. Protocol Independent Multicast (PIM) [RFC4601] messages will be sent to the link-local IPv6 'ALL-PIM-ROUTERS' multicast group ff02::d in the selected LAN and should be allowed. Implementing IPv6 PIM snooping will allow only the participants associated with a
对于IPv6多播流量交换，IXP可以决定使用用于单播IPv6流量交换的同一LAN、用于IPv4多播流量交换的同一LAN或用于IPv6多播流量交换的专用LAN。使用专用LAN进行多播的原因是为了防止不需要的多播流量到达不支持多播的参与者。协议独立多播（PIM）[RFC4601]消息将被发送到所选LAN中的链路本地IPv6“ALL-PIM-ROUTERS”多播组ff02:：d，并且应被允许。实施IPv6 PIM窥探将只允许与
particular group to receive its multicast traffic. BGP reachability information for IPv6 multicast address family (SAFI=2) is normally exchanged using MP-BGP (Multi-Protocol BGP) [RFC4760] and is used for Reverse Path Forwarding (RPF) lookups performed by the IPv6 PIM. If a dedicated LAN is configured for Multicast IPv6 traffic exchange, reachability information for IPv6 Multicast address family should be carried in new BGP sessions. ICMPv6 Neighbor Discovery should be allowed in the Multicast IPv6 LAN as described in the previous paragraph.
要接收其多播流量的特定组。IPv6多播地址系列（SAFI=2）的BGP可达性信息通常使用MP-BGP（多协议BGP）[RFC4760]进行交换，并用于IPv6 PIM执行的反向路径转发（RPF）查找。如果为多播IPv6流量交换配置了专用LAN，则应在新的BGP会话中携带IPv6多播地址系列的可达性信息。如前一段所述，应允许在多播IPv6 LAN中发现ICMPv6邻居。
The inclusion of PTR records for all addresses assigned to participants in the IXP reverse zone under "ip6.arpa" facilitates troubleshooting, particularly when using tools such as traceroute. If reverse DNS is configured, DNS servers should be reachable over IPv6 transport for complete IPv6 support.
在“ip6.arpa”下为IXP反向区中的参与者分配的所有地址包含PTR记录有助于进行故障排除，特别是在使用诸如traceroute之类的工具时。如果配置了反向DNS，则应可通过IPv6传输访问DNS服务器，以获得完整的IPv6支持。
IXPs may offer a route-server service, either for Multi-Lateral Peering Agreements (MLPA) service, looking-glass service, or route-collection service. IPv6 support needs to be added to the BGP speaking router. The equipment should be able to transport IPv6 traffic and to support MP-BGP extensions for IPv6 address family ([RFC2545] and [RFC4760]).
IXPs可以提供路由服务器服务，用于多边对等协议（MLPA）服务、窥镜服务或路由收集服务。需要将IPv6支持添加到讲BGP的路由器。设备应能够传输IPv6流量，并支持IPv6地址系列的MP-BGP扩展（[RFC2545]和[RFC4760]）。
A good practice is that all BGP sessions used to exchange IPv6 network information are configured using IPv6 data transport. This configuration style ensures that both network reachability information and generic packet data transport use the same transport plane. Because of the size of the IPv6 space, limiting the maximum number of IPv6 prefixes in every session should be studied.
一个好的做法是，所有用于交换IPv6网络信息的BGP会话都使用IPv6数据传输进行配置。此配置样式确保网络可达性信息和通用分组数据传输使用相同的传输平面。由于IPv6空间的大小，应研究限制每个会话中IPv6前缀的最大数量。
External services should be available for external IPv6 access, either by an IPv6 enabled web page or an IPv6 enabled console interface.
通过启用IPv6的网页或启用IPv6的控制台界面，外部服务应可用于外部IPv6访问。
Some external services that need to have IPv6 support are traffic graphics, DNS, FTP, web, route server, and looking glass. Other external services such as NTP servers, or SIP Gateways need to be evaluated as well. In general, each service that is currently accessed through IPv4 or that handle IPv4 addresses should be evaluated for IPv6 support.
一些需要支持IPv6的外部服务包括流量图形、DNS、FTP、web、路由服务器和窥镜。还需要评估其他外部服务，如NTP服务器或SIP网关。通常，应评估当前通过IPv4访问或处理IPv4地址的每个服务是否支持IPv6。
Internal services are also important when considering IPv6 adoption at an IXP. Such services may not deal with IPv6 traffic, but may handle IPv6 addresses; that is the case of provisioning systems, logging tools and statistics analysis tools. Databases and tools should be evaluated for IPv6 support.
在IXP上考虑采用IPv6时，内部服务也很重要。此类服务可能不处理IPv6流量，但可能处理IPv6地址；这就是供应系统、日志工具和统计分析工具的情况。应评估数据库和工具是否支持IPv6。
IXP policies and contracts should be revised as any mention of IP should be clarified if it refers to IPv4, IPv6, or both.
应修订IXP政策和合同，因为如果提及IP是指IPv4、IPv6或两者，则应澄清提及IP的内容。
Policies for IPv6 traffic monitoring and filtering may be in place as described in Section 4.
IPv6流量监控和过滤的策略可能如第4节所述。
This memo includes references to procedures for monitoring and/or avoiding particular ICMPv6 traffic at IXPs' LANs. None of these procedures prevent Ethernet loops caused by mischief in the LAN. The document also mentions how to limit IPv6 DoS attacks to the IXP switch fabric by not globally announce the IXP LANs prefix.
本备忘录包括在IXPs局域网上监控和/或避免特定ICMPv6流量的程序参考。这些过程都不能防止LAN中的恶意破坏导致的以太网环路。该文档还提到如何通过不全局公布IXP LAN前缀来限制对IXP交换机结构的IPv6 DoS攻击。
The author would like to thank the contributions from Alain Aina, Bernard Tuy, Stig Venaas, Martin Levy, Nick Hilliard, Martin Pels, Bill Woodcock, Carlos Friacas, Arien Vijn, Fernando Gont, and Louis Lee.
作者要感谢Alain Aina、Bernard Tuy、Stig Venaas、Martin Levy、Nick Hilliard、Martin Pels、Bill Woodcock、Carlos Friacas、Arien Vijn、Fernando Gont和Louis Lee的贡献。
[IEEE.P802-1Q.1998] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Virtual Bridged Local Area Networks", IEEE Draft P802.1Q, March 1998.
[IEEE.P802-1Q.1998]电气和电子工程师协会，“局域网和城域网：虚拟桥接局域网”，IEEE P802.1Q草案，1998年3月。
[RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or converting network protocol addresses to 48.bit Ethernet address for transmission on Ethernet hardware", STD 37, RFC 826, November 1982.
[RFC0826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月。
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC2464，1998年12月。
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[RFC2545]Marques，P.和F.Dupont，“将BGP-4多协议扩展用于IPv6域间路由”，RFC 25451999年3月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]Deering，S.，Fenner，W.，和B.Haberman，“IPv6的多播侦听器发现（MLD）”，RFC 2710，1999年10月。
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for Describing Simple Network Management Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, December 2002.
[RFC3411]Harrington，D.，Presohn，R.，和B.Wijnen，“描述简单网络管理协议（SNMP）管理框架的体系结构”，STD 62，RFC 3411，2002年12月。
[RFC3627] Savola, P., "Use of /127 Prefix Length Between Routers Considered Harmful", RFC 3627, September 2003.
[RFC3627]Savola，P.，“在路由器之间使用/127前缀长度被认为是有害的”，RFC 3627，2003年9月。
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.和L.Costa，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193]Hinden，R.和B.Haberman，“唯一本地IPv6单播地址”，RFC 41932005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC4601]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 46012006年8月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]Bates，T.，Chandra，R.，Katz，D.，和Y.Rekhter，“BGP-4的多协议扩展”，RFC 4760，2007年1月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008.
[RFC5101]Claise，B.，“用于交换IP流量信息的IP流量信息导出（IPFIX）协议规范”，RFC 5101，2008年1月。
[RIR_IXP_POLICIES] Numbers Resource Organization (NRO)., "RIRs Allocations Policies for IXP. NRO Comparison matrix", 2009, <http://www.nro.net/documents/comp-pol.html#3-4-2>.
[RIR_IXP_策略]数字资源组织（NRO），“IXP.NRO比较矩阵的RIR分配策略”，2009年<http://www.nro.net/documents/comp-pol.html#3-4-2>.
[V6OPS-RA-GUARD] Levy-Abegnoli, E., Velde, G., Popoviciu, C., and J. Mohacsi, "IPv6 RA-Guard", Work in Progress, June 2010.
[V6OPS-RA-GUARD]Levy Abegnoli，E.，Velde，G.，Popoviciu，C.，和J.Mohacsi，“IPv6 RA-GUARD”，正在进行的工作，2010年6月。
[V6OPS-ROGUE-RA] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement Problem Statement", Work in Progress, June 2010.
[V6OPS-ROGUE-RA]Chown，T.和S.Venaas，“ROGUE IPv6路由器广告问题声明”，正在进行的工作，2010年6月。
Author's Address
作者地址
Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle, 1180 Switzerland
Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle，1180瑞士
EMail: rogaglia@cisco.com
EMail: rogaglia@cisco.com