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)
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.
この文書は、インターネットエクスチェンジ（のIXP）でのIPv6の展開に関するガイダンスを提供します。これは、スイッチファブリックの設定、アドレス指定を計画して実行する必要がある一般的な組織のタスクに関する情報を含みます。 IXPは、多くの場合、最高の勧告は、IPv6データ、制御、および管理プレーンは、IPv4に比べて異なる方法で処理すべきではないことを示唆している、主にレイヤ2のインフラであり、。
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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.
ほとんどのインターネットエクスチェンジ（のIXP）は、IPv6の採用の簡単な作業を行う、レイヤ2レベルで動作します。しかし、のIXPは、通常のIPv6の実装によって影響を受ける可能性があるなど、統計、ルートサーバ、眼鏡を探して、ブロードキャスト制御などの追加サービスを実装します。この文書では、新規または既存のIXP上のIPv6の影響を明確にしています。他のレイヤ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.
[RFC2464]に記載されているように、イーサネットベースのIXPスイッチファブリックは、イーサネット上でIPv6を実装します。したがって、IPv6トラフィックの切り替えは、IPv4と同様に起こります。しかし、いくつかの管理機能（例えば、スイッチ管理としては、SNMP（簡易ネットワーク管理プロトコル）[RFC3411]のサポート、または分析輸出フロー）が下地層としてIPv6を必要とするかもしれない、これはIXPオペレータによって評価されるべきです。
There are two common configurations of IXP switch ports to support IPv6:
IPv6をサポートするためのIXPスイッチポートの2つの一般的な構成があります。
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のトラフィックのために別々の統計分析を行う）「デュアルスタック」構成が異なるさらにEthertypeに基づいてトラフィックを分類するようIPFIX（IPフロー情報エクスポート）としてフロー技術の使用[RFC5101]を必要とするであろう（0x0800でIPv4の、ARP（アドレス解決プロトコル）、およびIPv6の0x86DDのための0x0806）のために。
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.
地域インターネットレジストリ（RIRは）プロバイダ独立（PI）のIPv6のIXPにアドレスを割り当てるために、特定のアドレスポリシーを持っています。これらの割り当ては、通常は/ 48または短いプレフィックス[RIR_IXP_POLICIES]です。操作の国や地域によっては、アドレスの割り当てはのNIR（ナショナルインターネットレジストリ）によって行うことができます。ユニークローカルIPv6ユニキャストアドレス（[RFC4193]）は、通常、グローバルリバースDNS解決としてIXP LANで使用されていないと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.
IXPは、通常は手動アドレス設定を使用します。 IPv6アドレスの手動設定は、IXP参加者がボーダーゲートウェイプロトコル（BGP）のセッションの情報を再構成する必要なしに、ネットワークインターフェイスを交換することができ、そしてそれはまた、管理タスクを容易にします。アーキテクチャ[RFC4291]をアドレス指定のIPv6インタフェース識別子がプレフィックスが/ 64の最大プレフィックス長をもたらす、バイナリ000で開始しないため、サイズが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]に記載の影響を考慮する必要があります。 / 48プレフィックスは64分の65536 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の10進数は、IIDの上部のBCD（バイナリコード10進数）符号化として使用されます。
* 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.
この例では、我々は右正当化第百十二ビットから参加者のASN番号をされています。 32ビットのAS番号は最大10個の文字を必要とすることを忘れないでください。この例では、最大2 ^ 16のIPv6アドレスは、ASNごとに設定することができます。
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は以下の通りIIDの上部としてのASN番号の進符号化を使用することを好みます。
* IXP LAN prefix: 2001:db8::/64
* IXP LANの接頭辞：2001：DB8 :: / 64
* ASN: 64496 (DEC) or fbf0 (HEX)
* ASN：64496（DEC）またはfbf0（HEX）
* 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：：fbf0：0001/64またはそれと同等の表現2001：DB8 :: fbf0：0000 1/64
In this case, a maximum of 8 characters will be needed to represent 32-bit ASNs.
この場合には、8つの文字の最大値は、32ビットのAS番号を表すために必要とされるであろう。
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アドレスを割り当てるための第3の方式は、そのIPv4アドレスに参加者のIPv6アドレスのいくつかの部分に関連するかもしれません。次の例では、IPv4アドレスの最後の4つの小数点以下は、次の例のようにIIDの最後の3文字のBCDエンコードとして進数を使用して、IPv6アドレスの最後の進数にコピーされます。
* 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つの:: 64分の123
4. A fourth approach might be based on the IXPs ID for that participant.
4.第四のアプローチは、その参加者のためのIXP 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プレフィックスは、一般的に公によく知られており、異なるのRIRによって、この目的のために予約さIXP割り当てのための専用のIPv6ブロックから取得されます。これらのブロックは、通常は交換ファブリックに対処するためのものです、そして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が世界的にその参加者のAS（自律システム）境界にサービス拒否（DoS）攻撃の可能性起源を制限するためにルーティングされるべきではないと判断してもよいです。障害管理を実行するには、この構成では、参加者は彼らのネットワーク内のルートこれらのプレフィックス（例えば、BGP無エクスポートコミュニティを使用するか、参加者の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が（試みに）グローバルルーティングされるべきことを決定することができます。この場合、その参加者のAS境界外からのIXPのLANの監視が可能かもしれないが、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).
さらに、（例えばDNS、Webページ、FTPサーバなど）が可能IXP外部サービスをグローバルにルーティングする必要があります。これらは、上流プロバイダのアドレス空間または別の独立した割り当てのいずれかから、別のアドレスブロックから対処する必要があります。厳格なプレフィックス長フィルタリングをグローバルにルーティングされないかもしれないのIXP LANの1/48の割り当てやIXPのための異なる、非IXP / 48の割り当てを要求し、RIR（すなわちからより多くの1/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マルチキャストを検討する際に評価する必要がある2つの要素があります。
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ではそこにサポートを放送していないが、その代わりのIXPは、各LANにマルチキャストトラフィックを制御しようとすることがあります。アドレス解決、近隣到達不能検出、アドレス重複検出：ICMPv6の近隣探索[RFC4861]はIXPスイッチングファブリックで、次の必要な機能を実現します。 0：0：0：0：これらの機能を実行するために、近隣要請と近隣広告パケットは、リンクローカル全ノードマルチキャストアドレス（FF02 :: 1）及び/又は要請ノードマルチキャストアドレス（FF02を使用して交換されFF02に0000：1：FF00 0：0：0：0：1：FFFF：FFFF）。 [RFC4861]に記載されているように、ルータは、マルチキャストリスナ発見（MLD）[RFC2710]またはMLDv2の[RFC3810]のいずれかを使用して、それらの要請ノードマルチキャストアドレスを接合することによって、それらのインターフェイスを初期化します。 FF02 :: 2（MLD）またはFF02 :: 16（のMLDv2）：MLDメッセージは、対応するグループアドレスに送信されてもよいです。 IXPによって選択されたアドレス指定のプランによっては、各要請ノードマルチキャストグループは、アドレスの最後の3つのオクテットが選択されている方法によって調整参加者のサブセットで共有することができます。第3節で、例1では、同じ最後の2桁とAS番号との唯一の参加者が同じ要請ノードマルチキャストグループを共有しようとしています。
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ポリシーに対して通常です。 ICMPv6のルーターアドバタイズパケットが発行されなかったりIXPに接続されたルータによって受け入れられるべきどちらも。可能であれば、IXPオペレータは、IPv6 RA-GUARD [V6OPS-RA-GUARD]を使用してリンクローカルRA（ルータ広告）パケットをブロックすべきです。これが不可能な場合、IXPオペレータは[V6OPS-ROGUE-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 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.
IXPが同じLANをユニキャストIPv6トラフィック交換のために使用されているいずれかを使用することを決定してもよいIPv6マルチキャストトラフィックの交換のため、同一のLANは、IPv6マルチキャストトラフィックの交換のためのIPv4マルチキャストトラフィックの交換、または専用LANのために使用されています。マルチキャストのために、専用のLANを持つ理由は、マルチキャストをサポートしていない参加者に届くから、不要なマルチキャストトラフィックを防ぐためです。プロトコル独立マルチキャスト（PIM）[RFC4601]のメッセージが::リンクローカルIPv6 'ALL-PIM-ルータのマルチキャストグループFF02に選択されたLANでdは送信され、認められるべきです。実装のIPv6 PIMスヌーピングは、特定のグループに関連付けられている唯一の参加者がそのマルチキャストトラフィックを受信できるようになります。 IPv6マルチキャストアドレスファミリ（SAFI = 2）のためのBGP到達可能性情報は、通常、MP-BGP（マルチプロトコルBGP）[RFC4760]を使用して交換され、IPv6のPIMによって実行されるリバースパス転送（RPF）ルックアップのために使用されます。専用LANは、マルチキャスト、IPv6トラフィック交換のために構成されている場合は、IPv6マルチキャストアドレスファミリの到達可能性情報は、新しいBGPセッションで実行されるべきです。前の段落で説明したようにICMPv6の近隣探索は、マルチキャストIPv6のLANに許されるべきです。
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.
などのtracerouteなどのツールを使用する場合は特に「ip6.arpa」の下のIXP逆ゾーンの参加者に割り当てられたすべてのアドレスに対してPTRレコードを含めることは、トラブルシューティングを容易にします。リバースDNSが設定されている場合、DNSサーバは、完全なIPv6サポートのための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]).
IXPは、いずれかのマルチラテラル・ピアリング協定（MLPA）サービス、探してガラスサービス、またはルート・収集サービスのために、ルートサーバーサービスを提供することがあります。 IPv6のサポートは、BGPスピーキングルータに追加する必要があります。機器がIPv6トラフィックを転送することができるはずとIPv6アドレスファミリ（[RFC2545]と[RFC4760]）のためのMP-BGP拡張をサポートします。
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対応のWebページまたは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、ウェブ、ルートサーバ、および見ているガラスです。このよう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.
それは、IPv4、IPv6の、またはその両方を参照する場合、IPの一切の言及を明確にしなければならないようIXP方針や契約が改訂されなければなりません。
Policies for IPv6 traffic monitoring and filtering may be in place as described in Section 4.
セクション4で説明したように、IPv6トラフィックの監視およびフィルタリングのポリシーは、所定の位置にあってもよいです。
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.
このメモは、監視および/またはのIXPのLANで特定の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.
著者はアラン・アイナ、バーナード・トゥイ、スティグVenaas、マーティン・レヴィ、ニック・ヒリアード、マーチンペル、ビル・ウッドコック、カルロスFriacas、Arien Vijn、フェルナンドGont、ルイリーからの貢献に感謝したいと思います。
[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]プラマー、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]デアリング、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パケットのトランスミッション"、RFC 2464、1998年12月。
[RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[RFC2545]マルケス、P.およびF.デュポン、RFC 2545 "IPv6のドメイン間ルーティングのためのBGP-4マルチプロトコル拡張機能の使用"、1999年3月。
[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999.
[RFC2710]デアリング、S.、フェナー、W.、およびB.ハーバーマン、 "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]ハリントン、D.、Presuhn、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.
"IPv6のマルチキャストリスナ発見バージョン2（MLDv2の）" [RFC3810]ヴィーダ、R.とL.コスタ、RFC 3810、2004年6月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年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]フェナー、B.、ハンドリー、M.、ホルブルック、H.、およびI. Kouvelas、 "プロトコル独立マルチキャスト - スパースモード（PIM-SM）：プロトコル仕様（改訂）"、RFC 4601、2006年8月。
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, January 2007.
[RFC4760]ベイツ、T.、チャンドラ、R.、カッツ、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.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年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_POLICIES]数字リソース機構（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]レビー - Abegnoli、E.、ヴェルデ、G.、Popoviciu、C.、およびJ. Mohacsi、 "IPv6のRA-ガード"、進歩、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、 "ローグのIPv6ルータアドバタイズメントの問題に関する声明"、進歩、2010年6月での作業。
Author's Address
著者のアドレス
Roque Gagliano Cisco Systems Avenue des Uttins 5 Rolle, 1180 Switzerland
ロケガリアーノシスコシステムズアベニューデUttins 5ロル、1180年スイス
EMail: rogaglia@cisco.com
メールアドレス：rogaglia@cisco.com