この文書はRFC3065の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


Network Working Group                                          P. Traina
Request for Comments: 3065                        Juniper Networks, Inc.
Obsoletes: 1965                                             D. McPherson
Category: Standards Track                           Amber Networks, Inc.
                                                              J. Scudder
                                                     Cisco Systems, Inc.
                                                           February 2001


                Autonomous System Confederations for BGP
                        BGPの自律システム同盟

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 (2001).  All Rights Reserved.

Abstract
概要

   The Border Gateway Protocol (BGP) is an inter-autonomous system
   routing protocol designed for Transmission Control Protocol/Internet
   Protocol (TCP/IP) networks.  BGP requires that all BGP speakers
   within a single autonomous system (AS) must be fully meshed.  This
   represents a serious scaling problem that has been well documented in
   a number of proposals.
   ボーダーゲートウェイプロトコル(BGP)は伝送制御プロトコル/インター
   ネット・プロトコル(TCP/IP)ネットワークのために設計された自律
   システム間のルーティングプロトコルです。BGPはひとつの自律システム
   (AS)内のすべてのBGPスピーカが完全メッシュであることを要求しま
   す。これは多くの提案で明文化されている重大なスケール問題を起こします。

   This document describes an extension to BGP which may be used to
   create a confederation of autonomous systems that is represented as a
   single autonomous system to BGP peers external to the confederation,
   thereby removing the "full mesh" requirement.  The intention of this
   extension is to aid in policy administration and reduce the
   management complexity of maintaining a large autonomous system.
   この文章は、外部BGPピアに1つの自律システムに見えるような、自律シ
   ステム間の同盟に使用する、BGP拡張を記述します。この拡張の意図は、
   大きな自律システムの運用で、ポリシ管理の手助けと、複雑な管理を軽減す
   ることです。

1. Specification of Requirements
1. 必要条件の仕様
 
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC 2119].
   この文書のキーワード"MUST"と、"MUST NOT"と、"REQUIRED"と、"SHALL"と、
   "SHALL NOT"と、"SHOULD"と、"SHOULD NOT"と、"RECOMMENDED"と、"MAY"と、
   "OPTIONAL"は[RFC2119]で記述されるように解釈します。

2. Introduction
2. はじめに

   As currently defined, BGP requires that all BGP speakers within a
   single AS must be fully meshed.  The result is that for n BGP
   speakers within an AS n*(n-1)/2 unique IBGP sessions are required.
   This "full mesh" requirement clearly does not scale when there are a
   large number of IBGP speakers within the autonomous system, as is
   common in many networks today.
   現在定義されるように、BGPはAS内のすべてのBGPスピーカが完全メッ
   シュであることを要求します。この結果、AS内のn個のBGPスピーカに、
   n*(n-1)/2本のIBGPセッションが必要です。この「完全メッシュ」条件は
   明らかに、今日多くのネットワークで一般的なように、自律システム内に多
   数のIBGPスピーカがいる時にスケールしません。

   This scaling problem has been well documented and a number of
   proposals have been made to alleviate this [3,5].  This document
   represents another alternative in alleviating the need for a "full
   mesh" and is known as "Autonomous System Confederations for BGP", or
   simply, "BGP Confederations".  It can also be said the BGP
   Confederations MAY provide improvements in routing policy control.
   このスケール問題は文書化されており、多くの提案がこれを軽減するために
   作られました[3,5]。この文書は「完全メッシュ」の必要を軽減するもう1つ
   の選択肢を示し、そして「BGPのための自律システム同盟」、あるいは単
   に、「BGP同盟」として知られています。BGP同盟がポリシー制御の経
   路を決める際の改良を供給するかもしれない(MAY)と同じく言われます。

   This document is a revision of RFC 1965 [4] and it includes editorial
   changes, clarifications and corrections based on the deployment
   experience with BGP Confederations.  These revisions are summarized
   in Appendix A.
   この文書はRFC1965[4]の修正で、そしてBGP同盟の運用経験に基づ
   く編集上の変更と明確化と訂正を含みます。これらの修正は付録Aに要約さ
   れています。

3. Terms and Definitions
3. 用語と定義

   AS Confederation
   AS同盟

      A collection of autonomous systems advertised as a single AS
      number to BGP speakers that are not members of the confederation.
      同盟のメンバーでないBGPスピーカに同じAS番号を広告する自律シス
      テムの集合
 
   AS Confederation Identifier
   AS同盟識別子

      An externally visible autonomous system number that identifies the
      confederation as a whole.
      同盟全体を識別する、外部に見えてる自律システム番号。
 
   Member-AS
   メンバAS
 
      An autonomous system that is contained in a given AS
      confederation.
      与えられたAS同盟に含まれるAS
 
   Member-AS Number
   メンバAS番号
 
      An autonomous system number visible only internal to a BGP
      confederation.
      BGP同盟の内部からのみ見える自律システム番号

4. Discussion
4. 議論

   It may be useful to subdivide autonomous systems with a very large
   number of BGP speakers into smaller domains for purposes of
   controlling routing policy via information contained in the BGP
   AS_PATH attribute.  For example, one may choose to consider all BGP
   speakers in a geographic region as a single entity.  In addition to
   potential improvements in routing policy control, if techniques such
   as those presented here or in [5] are not employed, [1] requires BGP
   speakers in the same autonomous system to establish a full mesh of
   TCP connections among all speakers for the purpose of exchanging
   exterior routing information.  In autonomous systems the number of
   intra-domain connections that need to be maintained by each border
   router can become significant.
   BGPのASパス属性に含まれる情報によってルーティングポリシーを制御
   する目的で、非常に多数のBGPスピーカを持つ自律システムをより小さい
   ドメインに小分割することは有用であるかもしれません。例えば、地理的な
   地域のすべてのBGPスピーカをひとつの要素と考えるかもしれません。ルー
   ティングポリシ制御の改良の可能性に加えて、もしここや[5]で公開されたテ
   クニックが使用されないなら、[1]が外面ルーティング情報交換の目的でBG
   Pスピーカに同じ自律システム内のすべてのスピーカ間に完全メッシュTC
   P接続を作ることを要求します。自律システムでそれぞれの境界ルータで維
   持する必要があるドメイン内の接続の数は重大になりえます。

   Subdividing a large autonomous system allows a significant reduction
   in the total number of intra-domain BGP connections, as the
   connectivity requirements simplify to the model used for inter-domain
   connections.
   大きな自律システムを分割することは、接続性条件がドメイン間接続に使わ
   れたモデルを単純化するように、ドメイン内BGP接続の合計数のかなりの
   縮小を許します。
 
   Unfortunately subdividing an autonomous system may increase the
   complexity of routing policy based on AS_PATH information for all
   members of the Internet.  Additionally, this division increases the
   maintenance overhead of coordinating external peering when the
   internal topology of this collection of autonomous systems is
   modified.
   不幸にも自律システムを分割することはすべてのインターネットのメンバの
   ASパス情報に基づくルーティングポリシの複雑さを増すかもしれません。
   さらに、この分割は、この自律システムの集合の内部トポロジーが修正され
   る時に、外部ピアリングを調整する維持費を増やします。
 
   Finally, dividing a large AS may unnecessarily increase the length of
   the sequence portions of the AS_PATH attribute.  Several common BGP
   implementations can use the number of "AS hops" required to reach a
   given destination as part of the path selection criteria.  While this
   is not an optimal method of determining route preference, given the
   lack of other in-band information, it provides a reasonable default
   behavior which is widely used across the Internet.  Therefore,
   division of an autonomous system into separate systems may adversely
   affect optimal routing of packets through the Internet.
   最後に、大きなASを分割することは、ASパス属性の長さを不必要に増加
   させるでしょう。いくつかのBGP実装は共通して経路選択基準の1つとし
   て、「ASホップ」の数を目的地までの距離として要求します。これが、経
   路選択の優先順位決定の最適な手段ではないけれども、他の情報がないので、
   これは広くインターネットで広く使われる妥当なデフォルトの振舞いです。
   それゆえ、自律システムを複数に分割することは、インターネットのパケッ
   トの最適なルーティングによくない影響を与えます。
 
   However, there is usually no need to expose the internal topology of
   this divided autonomous system, which means it is possible to regard
   a collection of autonomous systems under a common administration as a
   single entity or autonomous system when viewed from outside the
   confines of the confederation of autonomous systems itself.
   しかしながら、通常この分かれた自律システムの内部トポロジーを露出する
   必要がなく、共通の管理下の自律システムの集合を、同盟の境界の外部から
   見たときに、1つの要素あるいは自律システムとみなす事は可能です。

5. AS_CONFED Segment Type Extension
5. AS同盟セグメント種別の拡張

   Currently, BGP specifies that the AS_PATH attribute is a well-known
   mandatory attribute that is composed of a sequence of AS path
   segments.  Each AS path segment is represented by a triple <path
   segment type, path segment length, path segment value>.
   現在BGPはASパス属性が既知必須属性で、ASパスセグメントからなる
   事を指定します。それぞれのASパスセグメントは<パスセグメント種別、
   パスセグメント長、パスセグメント値>の3項組みで表現されています。

   In [1], the path segment type is a 1-octet long field with the two
   following values defined:
   [1]で、パスセグメント種別は1オクテット長フィールドで、下記に定義され
   る2つの値です。

   Value     Segment Type
   値        セグメント種別
 
      1       AS_SET: unordered set of ASs a route in the
              UPDATE message has traversed
      1       AS集合:更新メッセージで経路のASの順序なし集合。

      2       AS_SEQUENCE: ordered set of ASs a route in
              the UPDATE message has traversed
      2       AS列:更新メッセージで経路のASの順序付き集合。

   This document reserves two additional segment types:
   この書類は2つの追加のセグメント種別を予約します:
 
      3       AS_CONFED_SEQUENCE: ordered set of Member AS Numbers
              in the local confederation that the UPDATE message has
              traversed
      3       AS同盟列:更新メッセージで経路のローカルな同盟のメンバ
              AS番号の順序付き集合。
 
      4       AS_CONFED_SET: unordered set of Member AS Numbers in
              the local confederation that the UPDATE message has
              traversed
      4       AS同盟集合:更新メッセージで経路のローカルな同盟のメン
              バAS番号の順序なし集合。
 
6. Operation
6. オペレーション

   A member of a BGP confederation will use its AS Confederation ID in
   all transactions with peers that are not members of its
   confederation.  This confederation identifier is considered to be the
   "externally visible" AS number and this number is used in OPEN
   messages and advertised in the AS_PATH attribute.
   BGP同盟のメンバは、同盟のメンバでないピアとのすべての処理で同盟識
   別子を使用するでしょう。この同盟識別子は「外に見える」AS番号とみな
   され、この番号はオープンメッセージで利用され、ASパス属性で広告され
   ます。

   A member of a BGP confederation will use its Member AS Number in all
   transactions with peers that are members of the same confederation as
   the given router.
   BGP同盟のメンバは、自分の同盟のメンバーであるピアに対してメンバの
   ピアとのすべての処理でメンバAS番号を使用するしょう。

   A BGP speaker receiving an AS_PATH attribute containing an autonomous
   system matching its own confederation shall treat the path in the
   same fashion as if it had received a path containing its own AS
   number.
   自同盟に一致する自律システムを含むASパス属性を受信したBGPスピー
   カは、自AS番号を含むパスを受信したようにパスを扱うべきです。

   A BGP speaker receiving an AS_PATH attribute containing an
   AS_CONFED_SEQUENCE or AS_CONFED_SET which contains its own Member AS
   Number shall treat the path in the same fashion as if it had received
   a path containing its own AS number.
   自メンバAS番号を含むAS同盟列あるいはAS同盟集合を含むASパス属
   性を受信したBGPスピーカは、自AS番号を含むパスを受信したかのよう
   にパスを扱うべきです。

6.1. AS_PATH Modification Rules
6.1. ASパス変更規則

   Section 5.1.2 of [1] is replaced with the following text:
   [1]の5.1.2章は、次の文章で置き換えられます。

   When a BGP speaker propagates a route which it has learned from
   another BGP speaker's UPDATE message, it shall modify the route's
   AS_PATH attribute based on the location of the BGP speaker to which
   the route will be sent:
   BGPスピーカが他のBGPスピーカの更新メッセージから学んだ経路を伝
   える時、経路が送られるであろうBGPスピーカの場所に基づいて経路のA
   Sパス属性を修正するべきです:

   a) When a given BGP speaker advertises the route to another BGP
      speaker located in its own autonomous system, the advertising
      speaker shall not modify the AS_PATH attribute associated with the
      route.
   a) 自己の自律システムにいるBGPルータに経路を広告する時、広告するス
      ピーカは経路のASパス属性を変更しないでしょう。

   b) When a given BGP speaker advertises the route to a BGP speaker
      located in a neighboring autonomous system that is a member of the
      local autonomous system confederation, then the advertising
      speaker shall update the AS_PATH attribute as follows:
   b) 自己の自律システム同盟に含まれる隣接自律システムにいるBGPルータ
      に経路を広告する時、広告するスピーカは以下の様にASパス属性を更新
      するでしょう。

      1) if the first path segment of the AS_PATH is of type
         AS_CONFED_SEQUENCE, the local system shall prepend its own AS
         number as the last element of the sequence (put it in the
         leftmost position).
      1) もし、ASパスの最初のパスセグメントがAS同盟列であれば、ロー
         カルシステムは、自分自身のAS番号を処理の最後の要素に設定する
         でしょう(最左位置)。

      2) if the first path segment of the AS_PATH is not of type
         AS_CONFED_SEQUENCE the local system shall prepend a new path
         segment of type AS_CONFED_SEQUENCE to the AS_PATH, including
         its own confederation identifier in that segment.
      2) もし、ASパスの最初のパスセグメントがAS同盟列でないなら、ロー
         カルシステムはASパスへ、自己の同盟識別子を含む、新しいAS同
         盟列を追加します。

   c) When a given BGP speaker advertises the route to a BGP speaker
      located in a neighboring autonomous system that is not a member of
      the current autonomous system confederation, the advertising
      speaker shall update the AS_PATH attribute as follows:
   c) 自己の自律システム同盟に含まれない隣接自律システムにいるBGPルー
      タに経路を広告する時、広告するスピーカは以下の様にASパス属性を更
      新するでしょう。

      1) if the first path segment of the AS_PATH is of type
         AS_CONFED_SEQUENCE, that segment and any immediately following
         segments of the type AS_CONFED_SET or AS_CONFED_SEQUENCE are
         removed from the AS_PATH attribute, leaving the sanitized
         AS_PATH attribute to be operated on by steps 2, or 3.
      1) もしASパスの最初のパスセグメントがAS同盟列の時、そのセグメ
         ントと直後のAS同盟集合かAS同盟列のセグメントはASパス属性
         から削除され、きれいにされたASパス属性は2ステップや3ステッ
         プの操作をされます。

      2) if the first path segment of the remaining AS_PATH is of type
         AS_SEQUENCE, the local system shall prepend its own
         confederation ID as the last element of the sequence (put it in
         the leftmost position).
      2) もし、残りのASパスの最初のパスセグメントがAS列なら、ローカ
         ルなシステムは列の最後の要素に自己の同盟識別子を追加します(一
         番左の位置に置く)。

      3) if there are no path segments following the removal of the
         first AS_CONFED_SET/AS_CONFED_SEQUENCE segments, or if the
         first path segment of the remaining AS_PATH is of type AS_SET
         the local system shall prepend a new path segment of type
         AS_SEQUENCE to the AS_PATH, including its own confederation ID
         in that segment.
      3) もし、削除した最初のAS同盟集合/AS同盟列セグメントの後にセ
         グメントがないか、残りのパスの最初のセグメントがAS集合なら、
         ローカルシステムはAS列に、自己の同盟識別子を含む新しいセグメ
         ントを、ASパスに追加します。

   When a BGP speaker originates a route:
   BGPスピーカが経路を生成する時:

   a) the originating speaker shall include an empty AS_PATH attribute
      in all UPDATE messages sent to BGP speakers located in its own
      Member AS Number.  (An empty AS_PATH attribute is one whose length
      field contains the value zero).
   a) 経路の生成元のスピーカは、自己のメンバAS番号のBGPスピーカに送
      信する全ての更新メッセージに空のASパス属性を含めるべきです。(空
      のASパス属性は長さフィールドがゼロの値であるものです)。

   b) the originating speaker shall include its own Member AS Number in
      an AS_CONFED_SEQUENCE segment of the AS_PATH attribute of all
      UPDATE messages sent to BGP speakers located in neighboring
      Member-AS that are members of the local confederation (i.e., the
      originating speaker's Member AS Number will be the only entry in
      the AS_PATH attribute).
   b) 経路の生成元のスピーカは、自己の同盟のメンバの近隣メンバAS番号の
      BGPスピーカに送信する全ての更新メッセージで、ASパス属性のAS
      同盟列セグメントに自己のメンバAS番号を含めるべきです(すなわち、
      経路の生成元のスピーカのメンバAS番号がASパス属性の唯一の項目で
      す)。

   c) the originating speaker shall include its own autonomous system in
      an AS_SEQUENCE segment of the AS_PATH attribute of all UPDATE
      messages sent to BGP speakers located in neighboring autonomous
      systems that are not members of the local confederation.  (In this
      case, the autonomous system number of the originating speaker's
      member confederation will be the only entry in the AS_PATH
      attribute).
   c) 経路の生成元のスピーカは、自己の同盟のメンバでないの近隣メンバAS
      番号のBGPスピーカに送信する全ての更新メッセージで、ASパス属性
      のAS列セグメントに自己のAS番号を含めるべきです。(この場合、経
      路の生成元のスピーカがメンバである自律システムの番号がASパス属性
      の唯一の項目であるでしょう)。

7. Common Administration Issues
7. 共通管理問題

   It is reasonable for member ASs of a confederation to share a common
   administration and IGP information for the entire confederation.
   同盟のメンバASは共通の管理と同盟全体のIGP情報を共有することが合
   理的です。

   It shall be legal for a BGP speaker to advertise an unchanged
   NEXT_HOP and MULTI_EXIT_DISCRIMINATOR (MED) attribute to peers in a
   neighboring AS within the same confederation.  In addition, the
   restriction against sending the LOCAL_PREFERENCE attribute to peers
   in a neighboring AS within the same confederation is removed.  Path
   selection criteria for information received from members inside a
   confederation MUST follow the same rules used for information
   received from members inside the same autonomous system, as specified
   in [1].
   同一の同盟の隣接ASのピアに、修正しない次ホップ属性と多数出口識別属
   性(MED)を広告するのが適正です。さらに、同じ同盟内の隣接ASのピ
   アへはローカル優先属性の再送信の制限が削除されます。[1]で指定されるよ
   うに、同盟内部のメンバから受信した情報に対するパス決定基準は、同じ自
   律システム内のメンバから受信した情報に対する同じ規則を適用しなければ
   なりません(MUST)。

8. Compatability Considerations
8. 互換性の考察

   All BGP speakers participating in a confederation must recognize the
   AS_CONFED_SET and AS_CONFED_SEQUENCE segment type extensions to the
   AS_PATH attribute.
   同盟内に加わるすべてのBGPスピーカは、パス属性のAS同盟集合とAS
   同盟列セグメントの拡張を認識しなければなりません。

   Any BGP speaker not supporting these extensions will generate a
   notification message specifying an "UPDATE Message Error" and a sub-
   code of "Malformed AS_PATH".
   これらに対応しないBGPスピーカは「更新メッセージエラー」と「ASパ
   ス障害」の副コードを指定する通知メッセージを生成するでしょう。

   This compatibility issue implies that all BGP speakers participating
   in a confederation MUST support BGP confederations.  However, BGP
   speakers outside the confederation need not support these extensions.
   この互換性問題は、同盟に参加しているBGPスピーカがBGP同盟に対応
   していなければならない(MUST)事を意味します。しかし、同盟外のBGPス
   ピーカはこれらの拡張をサポートする必要はありません。

9. Deployment Considerations
9. 展開の考察

   BGP confederations have been widely deployed throughout the Internet
   for a number of years and are supported by multiple vendors.
   BGP同盟が何年もの間にインターネットを通じて広く配置され、そして多
   数のベンダによってサポートされます。

   Improper configuration of BGP confederations can cause routing
   information within an AS to be duplicated unnecessarily.  This
   duplication of information will waste system resources, cause
   unnecessary route flaps, and delay convergence.
   BGP同盟の適正でない設定はAS内の経路情報を不必要に複写することが
   あります。この情報の複製はシステム資源を浪費して、不必要な経路バタつ
   きを起こし、収束を遅らせるでしょう。

   Care should be taken to manually filter duplicate advertisements
   caused by reachability information being relayed through multiple
   member autonomous systems based upon the topology and redundancy
   requirements of the confederation.
   同盟のトポロジーと冗長性条件により多数のメンバ自律システムを通しての
   到達性情報による重複広告の手作業によるフィルターが注意深く行われるべ
   きです。

   Additionally, confederations (as well as route reflectors), by
   excluding different reachability information from consideration at
   different locations in a confederation, have been shown to cause
   permanent oscillation between candidate routes when using the tie
   breaking rules required by BGP [1].  Care must be taken when
   selecting MED values and tie breaking policy to avoid these
   situations.
   さらに、(経路反射と同様に)同盟が、同盟内での異なる場所の考慮から異
   なる到達性情報を除外することによって、BGP[1]で必要とされるネクタイ
   締め規則を使う時、経路間の永久振動を起こすことが示されました。これら
   の状態を避けるため、MED値とネクタイ締めポリシを使う際に、注意が必
   要です。

   One potential way to avoid this is by configuring inter-Member-AS IGP
   metrics higher than intra-Member-AS IGP metrics and/or using other
   tie breaking policies to avoid BGP route selection based on
   incomparable MEDs.
   これを避ける可能性がある方法の1つは、メンバAS内IGPの距離をメン
   バAS間IGPの距離より大きくすることと、比較できないMED基づくB
   GP経路選択を避けるネクタイ締めポリシーを使うことです。

10. Security Considerations
10. セキュリティの考察

   This extension to BGP does not change the underlying security issues
   inherent in the existing BGP, such as those defined in [6].
   このBGPへの拡張は、[6]で定義したBGPに存在する固有のセキュリティ
   問題を変えません。

11. Acknowledgments
11. 謝辞

   The general concept of BGP confederations was taken from IDRP's
   Routing Domain Confederations [2].  Some of the introductory text in
   this document was taken from [5].
   BGP同盟の一般的な概念はIDRPの経路ドメイン同盟[2]からえられまし
   た。この文書の導入のテキストのいくつかは[5]からえられました。

   The authors would like to acknowledge Bruce Cole of Juniper Networks
   for his implementation feedback and extensive analysis of the
   limitations of the protocol extensions described in this document and
   [5].  We would also like to acknowledge Srihari Ramachandra of Cisco
   Systems, Inc., for his feedback.
   著者はジュニパーネットワークのBruce Coleに対して、彼の実装フィードバッ
   クとこの文書と[5]で記述されたプロトコル拡張の限界の大規模な分析へ感謝
   をします。我々はフィードバックに対し、シスコシステム社のSrihari
   Ramachandraに感謝します。

   Finally, we'd like to acknowledge Ravi Chandra and Yakov Rekhter for
   providing constructive and valuable feedback on earlier versions of
   this document.
   最終的に、我々はRavi ChandraとYakov Rekhterにこの文書の前のバージョン
   に建設的で貴重なフィードバックを供給したことに感謝します。

12. References
12. 参考文献

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

   [2] Kunzinger, C., Editor, "Inter-Domain Routing Protocol", ISO/IEC
       10747, October 1993.

   [3] Haskin, D., "A BGP/IDRP Route Server alternative to a full mesh
       routing", RFC 1863, October 1995.

   [4] Traina, P. "Autonomous System Confederations for BGP", RFC 1965,
       June 1996.

   [5] Bates, T., Chandra, R. and E. Chen, "BGP Route Reflection An
       Alternative to Full Mesh IBGP", RFC 2796, April 2000.

   [6] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
       Signature Option", RFC 2385, August 1998.

13. Authors' Addresses
13. 著者のアドレス

   Paul Traina
   Juniper Networks, Inc.
   1194 N. Mathilda Ave.
   Sunnyvale, CA 94089 USA

   Phone: +1 408 745-2000
   EMail: pst+confed@juniper.net


   Danny McPherson
   Amber Networks, Inc.
   48664 Milmont Drive
   Fremont, CA 94538

   Phone: +1 510.687.5226
   EMail:  danny@ambernetworks.com


   John G. Scudder
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA 95134

   Phone: +1 734.669.8800
   EMail: jgs@cisco.com


Appendix A: Comparison with RFC 1965
付録A:RFC1965との比較

   The most notable change from [1] is that of reversing the values
   AS_CONFED_SEQUENCE(4) and AS_CONFED_SET(3) to those defined in
   section "AS_CONFED Segment Type Extension".  The reasoning for this
   is that in the initial implementation, which was already widely
   deployed, they were implemented backwards from [4], and as such,
   subsequent implementations implemented them backwards as well.  In
   order to foster interoperability and compliance with deployed
   implementations, they've therefore been changed here as well.
   [1]からの最も顕著な変更は、「AS同盟セグメント種別拡張」章で定義した、
   AS同盟列(4)とAS同盟集合(3)の値を逆にした事です。この理由は、既に
   広く使われていた初期の実装で、[4]より後退した実装が行われ、続く実装が
   同様にしたためです。配置された実装との互換性と追従を促進するために、
   従ってここで変えられました。

   The "Compatibility Discussion" was removed and incorporated into
   other discussions in the document.  Also, the mention of hierarchical
   confederations is removed.  The use of the term "Routing Domain
   Identifier" was replaced with Member AS Number.
   「互換性論議」は除去され、そして他の論議が文書に取り入れられました。
   同じく、階層的な同盟の参照は除去されます。用語「ルーティングドメイン
   識別子」はメンバAS番号で置き換えられました。

   Finally, the "Deployment Considerations" section was expanded a few
   subtle grammar changes were made and a bit more introductory text was
   added.
   最終的に「展開の考察」章で少数の微妙な文法的変更とちょっとした文書の
   追加がされました。

Full Copyright Statement
著作権表示全文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.
   著作権(C)インターネット学会(2003)。すべての権利は保留される。

   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.
   この文書とここに含む情報は無保証で供給され、そしてインターネット学会
   とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
   報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、すべての保証を拒否します。

Acknowledgement
謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So