[要約] RFC 2545は、IPv6のインタードメインルーティングにおけるBGP-4マルチプロトコル拡張の使用に関するものです。このRFCの目的は、IPv6ネットワーク間のルーティングを効果的に行うために、BGP-4プロトコルを拡張する方法を提案することです。
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.
Copyright（c）The Internet Society（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が適切であるプロトコルの一般的なカテゴリに分類され、このドキュメントに別段の記載されていない限り、BGP-4を使用してIPv6の到達可能性情報を運ぶときに適用する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.
ルーティング情報の観点から、IPv6とIPv4（BGPが元々設計されていた）の最も重要な違いは、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属性の次のホップネットワークアドレスフィールドの長さの値は、グローバルアドレスのみが存在する場合、または次のホップフィールドにリンクローカルアドレスも含まれている場合は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スピーカーは、次のホップのLink-Local 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.
BGP-4メッセージが交換されるTCP接続は、IPv4またはIPv6を介して確立できます。BGP-4自体は使用される特定の輸送とは独立していますが、ピアリングセッションの確立に使用されるアドレスから暗黙の構成情報を導き出します。この情報（ピアのネットワークアドレス）は、ルート普及手順で考慮されます。したがって、IPv4の到達可能性情報のトランスポートとして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識別子は、開いたメッセージ内で、セッションの確立時間に2人のピア間で交換される32ビットの署名されていない整数です。これは、ネットワークで一意でなければならないスタートアップで決定されるシステム幅の広い値であり、ネットワークプロトコルに関係なくIPv4アドレスから派生する必要があります。特定のBGP-4インスタンスは、特定の瞬間に伝達するように構成されています。
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.
このドキュメントは、Tony Bates、Ravi Chandra、Dave Katz、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. Deering、「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. Li、「Border Gateway Protocol 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] Bates、T.、Chandra、R.、Katz、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] Deering、S。and 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。and W. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RIP] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RIP] Malkin、G。およびR. Minnear、「IPv6のRIPNG」、RFC 2080、1997年1月。
Pedro R. Marques cisco Systems, Inc. 170 W. Tasman Dr. San Jose, CA 95134 USA
Pedro R. Marques Cisco Systems、Inc。170 W. Tasman Dr. San Jose、CA 95134 USA
Phone: +1 408 527-5202
Fax: +1 408 526-4952
EMail: roque@cisco.com
Francis Dupont GIE DYADE INRIA Rocquencourt Domaine de Voluceau BP 105 78153 Le Chesnay CEDEX FRANCE
フランシス・デュポン・ジー・ダイアデ・インリア・ロックエンクール・ドメーヌ・デ・ヴォルコーBP 105 78153 Le Chesnay Cedex France
Phone: +33 1 39 63 52 13
Fax: +33 1 39 63 58 66
EMail: Francis.Dupont@inria.fr
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。