RFC 5963 - IPv6 Deployment in Internet Exchange Points (IXPs) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5963
タイトル : RFC 5963 - インターネット交換ポイント（IXPS）でのIPv6の展開
翻訳編集 : 自動生成

[要約] RFC 5963は、インターネット交換ポイント（IXP）でのIPv6の展開に関するガイドラインです。その目的は、IXPコミュニティにIPv6の採用を促進し、IPv6トラフィックの効率的なルーティングと交換を実現することです。

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)

インターネット交換ポイント（IXPS）での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.

このドキュメントは、インターネット交換ポイント（IXPS）での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.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5963で取得できます。

著作権表示

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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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

1. はじめに

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.

ほとんどのインターネット交換ポイント（IXPS）はレイヤー2レベルで動作し、IPv6の採用が簡単なタスクになります。ただし、IXPは通常、統計、ルートサーバー、見栄えの良いグラス、IPv6の実装によって影響を受ける可能性のあるブロードキャストコントロールなどの追加サービスを実装します。このドキュメントは、新規または既存のIXPに対するIPv6の影響を明確にしています。ドキュメントはイーサネットスイッチファブリックを想定していますが、他のレイヤー2構成を展開できます。

2. Switch Fabric Configuration

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スイッチファブリックは、[RFC2464]で説明されているように、イーサネット上で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. Independent 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参加者は、相互接続全体に1つの追加のVLANタグを渡す必要があります。この場合、IXPが元々VLANタグ付けを使用しなかった場合、VLANタグ付けを確立する必要があり、以前に構成されたLANが「ネイティブVLAN」として攻撃を続けるか、タグ付きVLANに移行します。「独立したVLAN」構成は、IPv4とIPv6トラフィックの論理的な分離を提供し、IPv4およびIPv6トラフィックの個別の統計分析を簡素化します。逆に、「デュアルスタック」構成（IPv4およびIPv6トラフィックの個別の統計分析を実行する場合）では、IPFIX（IPフロー情報エクスポート）[RFC5101]などのフロー技術を使用して、異なる倫理に基づいてトラフィックを分類する必要があります（0x080000に基づいてトラフィックを分類する必要があります。IPv4の場合、ARPの場合は0x0806（アドレス解像度プロトコル）、IPv6の場合は0x86DD）。

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を参照するリンクmtusの唯一の技術的要件は、1280オクテット以上であるか等しくなければならないということです[RFC2460]。IXPのすべてのLANのMTUサイズは、すべての参加者によってよく知られている必要があります。

3. Addressing Plan

3. 対処計画

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.

地域のインターネットレジストリ（RIRS）には、プロバイダーに独立した（PI）IPv6アドレスをIXPに割り当てるための特定のアドレスポリシーがあります。これらの割り当ては通常 /48または短いプレフィックス[rir_ixp_policies]です。国と運用地域に応じて、住所の割り当ては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参加者は、Border Gateway Protocol（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 LANSのアドレス指定が可能です。

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. 一部のIXPSは、各参加者のASN（自律システム番号）の小数点以下のエンコードを、その特派員IPv6アドレス内に含めることを好みます。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.

この例では、112ビットから参加者のASN番号を正しく正当化しています。32ビットASNには最大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の上部としてASNS数の16進エンコードを使用することを好みます。

* 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：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.

この場合、32ビットASNを表すには最大8文字が必要になります。

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番目のスキームは、参加者のIPv6アドレスの一部をIPv4アドレスに関連付けることです。次の例では、IPv4アドレスの最後の4つの小数は、次の例のように、IIDの最後の3文字のBCDエンコードとして10進数を使用して、IPv6アドレスの最後の16進数にコピーされます。

* 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. 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プレフィックスは通常、公的によく知られており、さまざまなRIRによってこの目的のために予約されたIXP割り当ての専用IPv6ブロックから取得されます。これらのブロックは通常、Exchangeファブリックの対処を目的としており、DFZ（デフォルトのフリーゾーン）オペレーターによって除外される場合があります。IXP LANSのルーティングを検討する場合、2つのオプションが特定されています。

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 IXPSは、参加者のAS（自律システム）境界にサービス拒否（DOS）攻撃の可能な起源を制限するために、LANがグローバルにルーティングされるべきではないことを決定する場合があります。この構成では、参加者はこれらの接頭辞をネットワーク内にルーティングすることができます（たとえば、BGP No-Exportコミュニティを使用するか、参加者のIGP内のIXP LANをルーティングして）障害管理を実行できます。この構成を使用して、参加者の外側からの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 LANSは参加者の外部から境界の外部から監視する可能性がありますが、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、Webページ、FTPサーバーなど）をグローバルにルーティングする必要があります。これらは、アップストリームプロバイダーのアドレススペースまたは個別の独立した割り当てから、個別のアドレスブロックからアドレス指定する必要があります。厳密なプレフィックス長さフィルタリングは、RIRから1 /48の割り当てを要求する理由である可能性があります（つまり、世界的にルーティングされない可能性のあるIXPS LANの1 /48割り当てを要求し、IXPの別の非IXP /48割り当てを要求しますグローバルにルーティングされる外部サービス）。

4. Multicast IPv6

4. マルチキャストIPv6

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つの要素があります。近隣発見とマルチキャストピアリングのマルチキャストサポートです。

4.1. Multicast Support and Monitoring for Neighbor Discovery at an IXP

4.1. IXPでの隣人発見のためのマルチキャストサポートと監視

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 Neighbor Discovery [RFC4861]は、IXPスイッチングファブリックで次の必要な機能を実装しています。これらの関数を実行するために、Neighbor SalicitationとNeighbor Advertisementパケットは、Link-Local All-Nodes Multicastアドレス（FF02 :: 1）および/またはSolicited-Nodeマルチキャストアドレス（FF02：0：0：0：0：0：0：0：0：0：0：0：0：0：0：0を使用して交換されます。1：FF00：0000からFF02：0：0：0：0：1：FFFF：FFFF）。[RFC4861]で説明されているように、ルーターは、マルチキャストリスナーディスカバリー（MLD）[RFC2710]またはMLDV2 [RFC3810]のいずれかを使用して、勧誘されたノードマルチキャストアドレスを結合することにより、インターフェイスを初期化します。MLDメッセージは、対応するグループアドレスに送信される場合があります：FF02 :: 2（MLD）またはFF02 :: 16（MLDV2）。IXPによって選択されたアドレス指定計画に応じて、各アドレスの最後の3オクテットがどのように選択されているかによって、参加者のサブセットが条件付けられた各勧誘されたノードマルチキャストグループが共有できます。セクション3の例1では、同じ最後の2桁のASNSを持つ参加者のみが、同じ勧誘されたノードマルチキャストグループを共有します。

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]を使用して、Link-Local RA（Router Advertisement）パケットをブロックする必要があります。これが不可能な場合、IXP演算子は[V6OPS-Rogue-Ra]に記載されているように、Rogueルーター広告パケットの交換を監視する必要があります。

4.2. IPv6 Multicast Traffic Exchange at an IXP

4.2. IXPでのIPv6マルチキャストトラフィック交換

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.

IPv6マルチキャストトラフィック交換の場合、IXPは、ユニキャストIPv6トラフィック交換に使用されている同じLAN、IPv4マルチキャストトラフィック交換に使用されている同じLAN、またはIPv6マルチキャストトラフィック交換に専用のLANを使用することを決定する場合があります。マルチキャスト用の専用LANを持っている理由は、マルチキャストのサポートがない参加者に到達することができない不要なマルチキャストトラフィックを防ぐためです。プロトコル独立したマルチキャスト（PIM）[RFC4601]メッセージは、選択したLANでLink-Local IPv6 'All-PIM-RoutersのマルチキャストグループFF02 :: Dに送信され、許可される必要があります。IPv6 PIMスヌーピングを実装すると、特定のグループに関連付けられた参加者のみがマルチキャストトラフィックを受け取ることができます。IPv6マルチキャストアドレスファミリ（SAFI = 2）のBGPリーチ可能性情報は、通常、MP-BGP（マルチプロトコルBGP）[RFC4760]を使用して交換され、IPv6 PIMが実行するリバースパス転送（RPF）ルックアップに使用されます。マルチキャストIPv6トラフィック交換用に専用のLANが構成されている場合、IPv6マルチキャストアドレスファミリの到達可能性情報は、新しいBGPセッションで運ばれる必要があります。前の段落で説明されているように、ICMPV6ネイバーディスカバリーはマルチキャストIPv6 LANで許可される必要があります。

5. Reverse DNS

5. 逆DNS

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トランスポートを介して到達可能になります。

6. Route-Server

6. ルートサーバー

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アドレスファミリ（[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アクセスに利用できる必要があります。

7. External and Internal Support

7. 外部および内部サポート

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サポートについては、データベースとツールを評価する必要があります。

8. IXP Policies and IPv6

8. IXPポリシーと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トラフィックの監視とフィルタリングのポリシーが整っている場合があります。

9. Security Considerations

9. セキュリティに関する考慮事項

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 LANでの特定のICMPV6トラフィックを監視および/または回避するための手順への参照が含まれています。これらの手順のいずれも、LANのいたずらによって引き起こされるイーサネットループを妨げません。ドキュメントでは、IXP LANSプレフィックスをグローバルに発表しないことにより、IPV6 DOS攻撃をIXPスイッチファブリックに制限する方法についても説明しています。

10. Acknowledgements

10. 謝辞

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からの貢献に感謝したいと思います。

11. Informative References

11. 参考引用

[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。、「イーサネットアドレス解像度プロトコル：または、ネットワークプロトコルアドレスをイーサネットハードウェア上の送信用のビットイーサネットアドレスに変換する」、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、「Internet Protocol、Version 6（IPv6）仕様」、RFC 2460、1998年12月。

[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.

[RFC2464] Crawford、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] Marques、P。and F. Dupont、「IPv6インタードメインルーティングのBGP-4マルチプロトコル拡張の使用」、RFC 2545、1999年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.、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.

[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 4193、2005年10月。

[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.

[RFC4291] Hinden、R。およびS. Deering、「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] Fenner、B.、Handley、M.、Holbrook、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] 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 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比較マトリックスのRIRS割り当てポリシー」、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 Router Advertisement Problem Statement」、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 Switzerland

   EMail: rogaglia@cisco.com