Network Working Group P. Marques
Request for Comments: 2545 cisco Systems, Inc.
Category: Standards Track F. Dupont
Inria
March 1999
Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing
IPv6のドメイン間ルーティングのためのBGP-4マルチプロトコル拡張機能の使用
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
BGP-4 Multiprotocol Extensions [BGP-MP] defines the format of two BGP attributes (MP_REACH_NLRI and MP_UNREACH_NLRI) that can be used to announce and withdraw the announcement of reachability information. This document defines how compliant systems should make use of those attributes for the purpose of conveying IPv6 routing information.
BGP-4マルチプロトコル拡張[BGP-MPは、2つのBGP到達可能性情報のアナウンスを発表し、引き出すために使用することができる（MP_REACH_NLRIとMP_UNREACH_NLRI）属性のフォーマットを定義します。この文書では、準拠したシステムがIPv6ルーティング情報を伝達する目的のためにそれらの属性を利用する方法を定義します。
The BGP-4 protocol [BGP-4] in particular, and path vector routing protocols in general, are mostly independent of the particular Address Family for which the protocol is being used.
BGP-4プロトコル一般に、特に[BGP-4]、およびパスベクトルルーティングプロトコルは、プロトコルが使用されている特定のアドレスファミリーのほとんど無関係です。
IPv6 falls under the generic category of protocols for which BGP-4 is suitable and, unless stated otherwise in this document, the BGP-4 procedures to apply when using BGP-4 to carry IPv6 reachability information are those defined in [BGP-4] and in subsequent documents that extend or update the BGP-4 specification.
IPv6が本書で特に明記しない限りBGP-4は、適当であり、そのためのプロトコルの一般的なカテゴリに該当する、IPv6の到達可能性情報を運ぶためにBGP-4を使用する際に適用するBGP-4の手順は、[BGP-4]で定義されたものです及びBGP-4仕様を拡張または更新以降の文書です。
In terms of routing information, the most significant difference between IPv6 and IPv4 (for which BGP was originally designed) is the fact that IPv6 introduces scoped unicast addresses and defines particular situations when a particular address scope must be used. This document concerns itself essentially with the necessary rules to accommodate IPv6 address scope requirements.
ルーティング情報の観点から、（BGPが元々設計された）は、IPv6とIPv4の間の最も大きな違いは、IPv6がスコープユニキャストアドレスを紹介し、特定のアドレス範囲が使用されなければならないときに特定の状況を定義することです。 IPv6のアドレススコープの要件に対応するために必要なルールと本質的にこの文書では、懸念そのもの。
IPv6 defines 3 unicast address scopes [ADDR-ARCH]: global, site-local and link-local. Site-local addresses are non-link-local address which are valid within the scope of a "site" and cannot be exported beyond it. As this document makes no assumption on the characteristics of a particular routing realm where BGP-4 is used, it makes no distinction between global and site-local addresses and refers to both as "global" or "non-link-local". Network administrators must however respect address scope restrictions and should be aware that the concepts of a BGP-4 routing domain and "site" are orthogonal notions and that they may or may not coincide in a given situation.
グローバル、サイトローカル及びリンクローカル：IPv6は3つのユニキャストアドレススコープ[ADDR-ARCH]を定義します。サイトローカルアドレスは、「サイト」の範囲内で有効であり、それを超えてエクスポートすることはできません非リンクローカルアドレスです。この文書は、BGP-4が使用される特定のルーティング領域の特性に何の仮定をしないように、グローバルおよびサイトローカルアドレスを区別しないし、「グローバル」または「非リンクローカル」との両方を指します。ネットワーク管理者は、しかし、アドレス範囲の制限を尊重しなければならないし、BGP-4ルーティングドメインと「サイト」のコンセプトは直交概念であることに注意してください、彼らはよく、または与えられた状況に一致しないかもしれない必要があります。
Companion IPv6 specifications further define that only link-local address can be used when generating ICMP Redirect Messages [ND] and as next hop addresses in some routing protocols (eg. RIPng [RIP]).
コンパニオンのIPv6仕様はさらにICMPリダイレクト・メッセージ[ND]といくつかのルーティングプロトコルのようなネクストホップアドレス（例えばRIPngの[RIP]）を生成するときにのみリンクローカルアドレスを使用することができることを規定します。
This restrictions does imply that an IPv6 router must have a link-local next hop address for all directly connected routes (routes for which the given router and the next hop router share a common subnet prefix).
この制限は、IPv6ルータは、直接接続されたすべてのルート（のための特定のルータとネクストホップルータを共有し、共通のサブネットプレフィックスルート）のためのリンクローカルネクストホップアドレスを持っていなければならないことを意味するものではありません。
Link-local addresses are not, however, well suited to be used as next hop attributes in BGP-4 given the rules defined for this attribute in the protocol specification [BGP-4].
リンクローカルアドレスは、しかし、プロトコル仕様[BGP-4〕この属性に定義された規則所定のBGP-4のネクストホップ属性として使用するにはあまり適していません。
For the above reasons, when BGP-4 is used to convey IPv6 reachability information it is sometimes necessary to announce a next hop attribute that consists of a global address and a link-local address. The following section describes the rules that should be followed when constructing the Network Address of Next Hop field of an MP_REACH_NLRI attribute.
BGP-4がIPv6到達可能性情報を伝えるために使用される場合、上記の理由から、グローバルアドレスとリンクローカルアドレスで構成されてネクストホップ属性を発表しなければならない場合があります。次のセクションでは、MP_REACH_NLRI属性のネクストホップフィールドのネットワークアドレスを構築する際に従うべきルールを説明しています。
A BGP speaker shall advertise to its peer in the Network Address of Next Hop field the global IPv6 address of the next hop, potentially followed by the link-local IPv6 address of the next hop.
BGPスピーカは、潜在的に次のホップのリンクローカルIPv6アドレスに続くネクストホップフィールドのネットワークアドレスネクストホップのグローバルIPv6アドレス内のピアに広告するものとします。
The value of the Length of Next Hop Network Address field on a MP_REACH_NLRI attribute shall be set to 16, when only a global address is present, or 32 if a link-local address is also included in the Next Hop field.
リンクローカルアドレスはまた、ネクストホップフィールドに含まれている場合MP_REACH_NLRI属性のネクストホップネットワークアドレスフィールドの長さの値は、唯一のグローバルアドレスが存在している16、または32に設定されなければなりません。
The link-local address shall be included in the Next Hop field if and only if the BGP speaker shares a common subnet with the entity identified by the global IPv6 address carried in the Network Address of Next Hop field and the peer the route is being advertised to.
だけBGPスピーカを共有している場合ネクストホップフィールドとピアのネットワークアドレスで運ばグローバルIPv6アドレスによって識別されるエンティティと共通のサブネットはルートがアドバタイズされている場合、リンクローカルアドレスは、ネクストホップフィールドに含まれなければなりませんに。
In all other cases a BGP speaker shall advertise to its peer in the Network Address field only the global IPv6 address of the next hop (the value of the Length of Network Address of Next Hop field shall be set to 16).
他のすべての場合でBGPスピーカは、ネットワークアドレスフィールドに、そのピアにネクストホップの唯一のグローバルIPv6アドレスを広告するもの（次ホップフィールドのネットワークアドレスの長さの値が16に設定されなければなりません）。
As a consequence, a BGP speaker that advertises a route to an internal peer may modify the Network Address of Next Hop field by removing the link-local IPv6 address of the next hop.
その結果、内部ピアにルートをアドバタイズBGPスピーカは、ネクストホップのリンクローカルIPv6アドレスを除去することにより、ネクストホップフィールドのネットワークアドレスを変更することができます。
TCP connections, on top of which BGP-4 messages are exchanged, can be established either over IPv4 or IPv6. While BGP-4 itself is independent of the particular transport used it derives implicit configuration information from the address used to establish the peering session. This information (the network address of a peer) is taken in account in the route dissemination procedure. Thus, when using TCP over IPv4 as a transport for IPv6 reachability information, additional explicit configuration of the peer's network address is required.
TCP接続は、BGP-4のメッセージが交換されるの上に、IPv4またはIPv6のいずれかを介して確立することができます。 BGP-4自体は、特定のトランスポートとは無関係であるが、それがピアリングセッションを確立するために使用されるアドレスからの暗黙的な設定情報を導出する使用。この情報（ピアのネットワークアドレス）がルート普及手順で口座に取り込まれます。 IPv6の到達可能性情報のためのトランスポートとしてIPv4の上にTCPを使用する場合したがって、ピアのネットワークアドレスの追加の明示的な設定が必要です。
Note that the information referred above is distinct from the BGP Identifier used in the BGP-4 tie breaking procedure. The BGP Identifier is a 32 bit unsigned integer exchanged between two peers at session establishment time, within an OPEN message. This is a system wide value determined at startup which must be unique in the network and should be derived from an IPv4 address regardless of the network protocol(s) a particular BGP-4 instance is configured to convey at a given moment.
上記いう情報はBGP-4タイブレイク手順で使用されるBGP識別子とは異なることに注意してください。 BGP識別子は、32ビットの符号なし整数は、OPENメッセージ内に、セッション確立時に2つのピア間で交換されます。これは、ネットワーク内で一意でなければならないとにかかわらず、特定のBGP-4インスタンスが所与の時点で搬送するように構成されているネットワークプロトコル（単数または複数）のIPv4アドレスから派生しなければならない起動時に決定され、システム全体の値です。
The use of TCP over IPv6 as transport protocol for IPv6 reachability information also has the advantage of providing explicit confirmation of IPv6 network reachability between two peers.
IPv6の到達可能性情報のためのトランスポートプロトコルとしてIPv6を介したTCPの使用はまた、2つのピア間のIPv6ネットワーク到達可能性の明示的な確認を提供するという利点を有します。
The extensions defined in this document allow BGP to propagate reachability information about IPv6 routes. As such, no new security issues are raised beyond those that already exist in BGP-4 and its use with IPv4.
この文書で定義された拡張は、BGPは、IPv6ルートについての到達可能性情報を伝播することができます。そのため、新たなセキュリティ問題は、すでにBGP-4とIPv4での使用には存在しているものを超えて発生しません。
This document derives from the work on BGP-4 Multiprotocol Extensions by Tony Bates, Ravi Chandra, Dave Katz and Yakov Rekhter.
この文書では、トニー・ベイツ、ラヴィチャンドラ、デイブ・カッツとヤコフ・レックターでBGP-4マルチプロトコル拡張機能の作業に由来します。
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[ADDR-ARCH] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[BGP-4] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1771, March 1995.
[BGP-4] Rekhter、Y.、およびT.李、 "ボーダーゲートウェイプロトコル4（BGP-4）"、RFC 1771、1995年3月。
[BGP-MP] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998.
[BGP-MP]ベイツ、T.、チャンドラ、R.、カッツ、D.およびY. Rekhter、 "BGP-4のためのマルチプロトコルの拡張"、RFC 2283、1998年2月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6の]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[ND] Narten氏、T.、Nordmarkと、E.およびW.シンプソン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 2461、1998年12月。
[RIP] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RIP]マルキン、G.およびR. Minnear、 "IPv6のためのRIPng"、RFC 2080、1997年1月。
Pedro R. Marques cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
ペドロ・R.マルケスシスコシステムズ社170 W.タスマン博士はカリフォルニア州サンノゼ95134 USA
Phone: +1 408 527-5202 Fax: +1 408 526-4952 EMail: roque@cisco.com
電話：+1 408 527-5202ファックス：+1 408 526-4952 Eメール：roque@cisco.com
Francis Dupont GIE DYADE INRIA Rocquencourt Domaine de Voluceau BP 105 78153 Le Chesnay CEDEX FRANCE
フランシス・デュポンGIE DYADE INRIA Rocquencourtドメーヌ・デ・Voluceau BP 105 78153シェズネーセデックスFRANCE
Phone: +33 1 39 63 52 13 Fax: +33 1 39 63 58 66 EMail: Francis.Dupont@inria.fr
電話：+33 1 39 63 52 13ファックス：+33 1 39 63 58 66 Eメール：Francis.Dupont@inria.fr
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。