RFC2545 日本語訳

2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-DomainRouting. P. Marques, F. Dupont. March 1999. (Format: TXT=10209 bytes) (Status: PROPOSED STANDARD)

RFC一覧
英語原文

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 Inter-Domain Routing のための 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.

   この文書は、the Internet community のための Internet standards track
   protocol を明細に記述し、改良のための討議と提案を要求する。このプロ
   トコルの標準化状態とステータスについては、"Internet Official
   Protocol Standards" (STD 1) の最新版を参照してもらいたい。このメモの
   配布は、無制限である。

-----------------------------------------------------------------------

Copyright Notice

著作権表示

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

-----------------------------------------------------------------------

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 Multiprotocol Extensions [BGP-MP] は、到達可能情報広告のアナウ
   ンスと取り消しに使用可能な 2 つの BGP 属性形式 (MP_REACH_NLRI と
   MP_UNREACH_NLRI) を定義する。この文書は、IPv6 ルーティング情報転送目
   的のため、準拠するシステムがこれら属性をどのように使用すべきかを定義
   する。

-----------------------------------------------------------------------

1. Introduction

1. 序論

   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] と、一般にパスベクトルルーティングプロ
   トコルは、プロトコルが使用されている特定の Address Family に、ほとん
   ど依存しない。

   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.

   ルーティング情報の点から、IPv6 と (もともと BGP が設計された) IPv4
   間の最も重要な違いは、IPv6 が scoped unicast address(s) を導入したこ
   とと、特定のアドレススコープが使用されなければならない時に特定の状況
   を定義したという事実である。この文書は、IPv6 アドレススコープ要求に
   適合するための必要なルールとともに、本質的にそれ自身に関係している。
   
-----------------------------------------------------------------------

2. IPv6 Address Scopes

2. 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]:
   グローバル、サイトローカルとリンクローカルアドレスである。サイトロー
   カルアドレスは、"site" のスコープ内で有効なリンクローカルでないアド
   レスであり、そのスコープを越えて外へ出すことができない。この文書は
   BGP-4 が使用される特定のルーティング領域の特性に想定を置かないので、
   グローバルとサイトローカルアドレス間の区別をおこなわなく、"global"
   もしくは "non-link-local" として両方とも参照される。しかしながら、
   ネットワーク管理者は、アドレススコープ制限を考慮しなければならなく
   BGP-4 ルーティングドメインと "site" の概念が直行概念であることに気
   づくべきであり、それらは与えられた状況で一致するかもしれないし、一
   致しないかもしれない。

   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 仕様書(s) の一方は、ICMP Redirect Messages [ND] を生成する時と
   いくつかのルーティングプロトコル (たとえば RIPng [RIP]) で next hop
   アドレスとして使用されることができるリンクローカルアドレスのみをさら
   に進んで定義する。

   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 ルータがすべての直接接続された経路 (与えられたルー
   タと next hop ルータは、共通サブネットプレフィックスを共有するという
   経路) に関し、リンクローカル next hop アドレスを持たなければならない
   ことを暗に意味する。

   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] 内の next hop 属性のために定
   義されるルールを与えた BGP-4 の next hop 属性として使用されるように
   リンクローカルアドレスは、よく適されていない。

   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 到達可能情報を運ぶために使用される時
   には、グローバルアドレスとリンクローカルアドレスからなる next hop 属
   性を広告することが、時には必要である。次の section は、MP_REACH_NLRI
   属性の Network Address of Next Hop フィールドを構成する時に従われる
   べきルールを記述する。

-----------------------------------------------------------------------

3. Constructing the Next Hop field

3. ネクストホップフィールドの構成

   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 スピーカは、Network Address of Next Hop フィールド内のそのピアに
   next hop であるグローバル IPv6 アドレスを広告すべきである。もしかす
   ると next hop であるリンクローカル 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 属性上の Length of
   Next Hop Network Address フィールド値は、16 に設定されるべきである。
   または、リンクローカルアドレスが Next Hop フィールドにも含まれる場合
   には、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.

   リンクローカルアドレスは、Next Hop フィールドに含まれるべきである。
   これは、もし BGP スピーカが共通サブネットとグローバル IPv6 アドレス
   により識別されるエンティティとピアとで共有されるか、もしくは共有され
   る場合にである。ここで、グローバル IPv6 アドレスとは Network Address
   of Next Hop フィールドで運ばれたものであり、ピアとはその経路がそのピ
   アへと広告されているものである。

   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 スピーカは、Network Address フィールドの
   そのピアに、next hop であるグローバル IPv6 アドレスのみを広告すべき
   である (Length of Network Address of Next Hop フィールド値は、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 スピーカは、next hop であるリ
   ンクローカル IPv6 アドレスを削除することにより、Network Address of
   Next Hop フィールドを変更するかもしれない。

-----------------------------------------------------------------------

4. Transport

4. トランスポート

   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 メッセージが交換される TCP コネクションは、IPv4 か IPv6 上のどち
   らかで確立されることができる。BGP-4 それ自身は使用される特定のトラン
   スポートに依存しないけれども、これは、ピアリングセッションを確立する
   ために使用されるアドレスからの暗黙の設定情報を引き出す。この情報 (ピ
   アのネットワークアドレス) は、経路普及手続きに考慮される。したがって
   IPv6 到達可能情報のトランスポートとして TCP over IPv4 を使用する時、
   ピアのネットワークアドレスに関する追加の明示的な設定が必要とされる。

   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 Identifier 決定手続きと
   異なることに注意しなさい。BGP Identifier は、OPEN メッセージ内のセッ
   ション確立の時点で 2 つのピア間で交換される 32 bit 符号なし整数であ
   る。これは、ネットワーク内で一意でなければならなく、特定の 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 到達可能情報のためのトランスポートプロトコルとして TCP over
   IPv6 の使用は、2 つのピア間の IPv6 ネットワーク到達の明示的な確認を
   提供するという強みも持つ。

-----------------------------------------------------------------------

5. Security Considerations

5. セキュリティに関する考察

   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 でのその使用を越え
   て、新しいセキュリティ問題は増やされない。

-----------------------------------------------------------------------

6. Acknowledgments

6. 謝辞

   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 Multiprotocol Extensions の成果から得られた。

-----------------------------------------------------------------------

7. References

7. 参考文献

   [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
               Architecture", RFC 2373, July 1998.

   [BGP-4]     Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
               (BGP-4)", RFC 1771, March 1995.

   [BGP-MP]    Bates, T., Chandra, R., Katz, D. and Y. Rekhter,
               "Multiprotocol Extensions for BGP-4", RFC 2283, February
               1998.

   [IPv6]      Deering, S. and R. Hinden, "Internet Protocol, Version 6
               (IPv6) Specification", RFC 2460, December 1998.

   [ND]        Narten, T., Nordmark, E. and W. Simpson, "Neighbor
               Discovery for IP Version 6 (IPv6)", RFC 2461, December
               1998.

   [RIP]       Malkin, G. and R. Minnear, "RIPng for IPv6",
               RFC 2080, January 1997.

-----------------------------------------------------------------------

8. Author Information

8. 著者の情報

   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

   Phone: +33 1 39 63 52 13
   Fax:   +33 1 39 63 58 66
   EMail: Francis.Dupont@inria.fr

-----------------------------------------------------------------------

9.  Full Copyright Statement

9.  著作権表示全文

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

   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.

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

DOMによる要素生成後にクラッシュすることがある

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る