RFC5065 日本語訳

Network Working Group                                          P. Traina
Request for Comments: 5065                            Blissfully Retired
Obsoletes: 3065                                             D. McPherson
Category: Standards Track                                 Arbor Networks
                                                              J. Scudder
                                                        Juniper Networks
                                                             August 2007

Trainaがコメントのために要求するワーキンググループP.をネットワークでつないでください: 5065が幸せに退職した、時代遅れにします: 3065年のD.マクファーソンカテゴリ: 標準化過程あずまやは2007年8月にJ.Scudder杜松ネットワークをネットワークでつなぎます。

                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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

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 that 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への単一の自律システムが同盟者にとって外部であることの形でじっと見るとき代理をされる自律システムの同盟者を創造するのに使用されるかもしれないBGPに拡大について説明します、その結果、「完全なメッシュ」要件を取り除きます。 この拡大の意志は、方針管理で支援して、大きい自律システムを維持する管理の複雑さを減少させることです。

   This document obsoletes RFC 3065.

このドキュメントはRFC3065を時代遅れにします。

Traina, et al.              Standards Track                     [Page 1]

RFC 5065                                                     August 2007

Traina、他 規格は2007年8月にRFC5065を追跡します[1ページ]。

Table of Contents

目次

   1. Introduction ....................................................3
      1.1. Specification of Requirements ..............................3
      1.2. Terminology ................................................3
   2. Discussion ......................................................4
   3. AS_CONFED Segment Type Extension ................................5
   4. Operation .......................................................5
      4.1. AS_PATH Modification Rules .................................6
   5. Error Handling ..................................................8
      5.1. Error Handling .............................................8
      5.2. MED and LOCAL_PREF Handling ................................8
      5.3. AS_PATH and Path Selection .................................9
   6. Compatibility Considerations ...................................10
   7. Deployment Considerations ......................................10
   8. Security Considerations ........................................10
   9. Acknowledgments ................................................11
   10. References ....................................................11
      10.1. Normative References .....................................11
      10.2. Informative References ...................................11
   Appendix A. Aggregate Routing Information .........................13
   Appendix B. Changes from RFC 3065 .................................13

1. 序論…3 1.1. 要件の仕様…3 1.2. 用語…3 2. 議論…4 3. _CONFEDセグメントタイプ拡張子として…5 4. 操作…5 4.1. _として、経路変更は統治されます…6 5. エラー処理…8 5.1. エラー処理…8 5.2. 医学の、そして、地方の_PREF取り扱い…8 5.3. _経路と経路選択として…9 6. 互換性問題…10 7. 展開問題…10 8. セキュリティ問題…10 9. 承認…11 10. 参照…11 10.1. 標準の参照…11 10.2. 有益な参照…11付録A.は経路情報に集められます…13 付録B.はRFC3065から変化します…13

Traina, et al.              Standards Track                     [Page 2]

RFC 5065                                                     August 2007

Traina、他 規格は2007年8月にRFC5065を追跡します[2ページ]。

1.  Introduction

1. 序論

   As originally 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 Internal BGP (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のユニークなInternal BGP(IBGP)セッションが必要であるということです。 今日、多くの多くのネットワークで一般的なIBGPスピーカーがそのままな自律システムの中にいるとき、この「完全なメッシュ」要件は明確に比例しません。

   This scaling problem has been well documented and a number of
   proposals have been made to alleviate this, such as [RFC2796] and
   [RFC1863] (made historic by [RFC4223]).  This document presents
   another alternative alleviating the need for a "full mesh" and is
   known as "Autonomous System Confederations for BGP", or simply, "BGP
   confederations".  It has also been observed that BGP confederations
   may provide improvements in routing policy control.

このスケーリング問題をよく記録しました、そして、これを軽減するのを多くの提案をしました、[RFC2796]や[RFC1863]([RFC4223]によって歴史的に作られている)のように。 このドキュメントは、「完全なメッシュ」の必要性を軽減する別の代替手段を提示して、「BGPのための自律システム同盟者」、または単に「BGP同盟者」として知られています。 また、BGP同盟者がルーティング方針コントロールにおける改良を提供するかもしれないのが観測されました。

   This document is a revision of, and obsoletes, [RFC3065], which is
   itself a revision of [RFC1965].  It includes editorial changes,
   terminology clarifications, and more explicit protocol specifications
   based on extensive implementation and deployment experience with BGP
   Confederations.

このドキュメントが改正である、時代遅れに、[RFC3065。](その]はそれ自体で[RFC1965]の改正です)。 それはBGP Confederationsと共に大規模な実現と展開経験に基づく編集の変化、用語明確化、および、より明白なプロトコル仕様を含んでいます。

1.1.  Specification of Requirements

1.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 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?

1.2.  Terminology

1.2. 用語

   AS Confederation

同盟者として

      A collection of autonomous systems represented and advertised as a
      single AS number to BGP speakers that are not members of the local
      BGP confederation.

自律システムの収集は、ただ一つのAS番号として地元のBGP同盟者のメンバーでないBGPスピーカーに、表して、広告を出しました。

   AS Confederation Identifier

同盟者識別子として

      An externally visible autonomous system number that identifies a
      BGP confederation as a whole.

全体でBGP同盟者を特定する外部的に目に見える自律システム番号。

   Member Autonomous System (Member-AS)

メンバー自律システム(メンバー、-、)

      An autonomous system that is contained in a given AS
      confederation.  Note that "Member Autonomous System" and "Member-
      AS" are used entirely interchangeably throughout this document.

与えられたAS同盟者で含まれている自律システム。 そして、その「メンバー自律システム」に注意してください、「メンバー、」 このドキュメント中で完全に互換性を持って使用されます。

Traina, et al.              Standards Track                     [Page 3]

RFC 5065                                                     August 2007

Traina、他 規格は2007年8月にRFC5065を追跡します[3ページ]。

   Member-AS Number

メンバー、-、数

      An autonomous system number identifier visible only within a BGP
      confederation, and used to represent a Member-AS within that
      confederation.

その同盟者の中にメンバー-ASを表すのにおいてBGP同盟者だけの中で目に見えて、中古の自律システム数の識別子。

2.  Discussion

2. 議論

   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.

情報でルーティング方針を制御する目的のための、より小さいドメインへの非常に多くのBGPスピーカーがBGP AS_PATH属性に含まれている状態で自律システムを細分するのは役に立つかもしれません。 例えば、地理的な領域のすべてのBGPスピーカーを単一体と考えるのを選ぶかもしれません。

   In addition to potential improvements in routing policy control, if
   techniques such as those presented here or in [RFC4456] are not
   employed, [BGP-4] 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.

ルーティング方針コントロールにおける潜在的改良に加えて、ここか[RFC4456]に提示されたものなどのテクニックが採用していないなら、[BGP-4]は、同じ自律システムのBGPスピーカーが外のルーティング情報を交換する目的のためにすべてのスピーカーの中にTCP接続の完全なメッシュを設立するのを必要とします。 自律システムでは、各境界ルータによって維持される必要があるイントラドメイン接続の数は重要になることができます。

   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_PATH情報に基づくルーティング方針の複雑さはインターネットのすべてのメンバーのために増加するかもしれません。 さらに、この分割は自律システムのこの収集の内部のトポロジーが変更されているとき、じっと見ながら外部であることの形で調整する維持オーバーヘッドを上げます。

   Therefore, division of an autonomous system into separate systems may
   adversely affect optimal routing of packets through the Internet.

したがって、別々のシステムへの自律システムの分割はインターネットを通してパケットの最適ルーティングに悪影響を与えるかもしれません。

   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.

しかしながら、通常必要であるのは一般的な管理の下で自律システムの収集を単一体か自律システムと見なすのが可能であることを意味するこの分割された自律システムの内部のトポロジーを露出するために全くありません、自律システムの同盟者自身の境界の外から見られると。

Traina, et al.              Standards Track                     [Page 4]

RFC 5065                                                     August 2007

Traina、他 規格は2007年8月にRFC5065を追跡します[4ページ]。

3.  AS_CONFED Segment Type Extension

3. _CONFEDセグメントタイプ拡張子として

   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_PATH属性がAS経路セグメントの系列で構成される周知の義務的な属性であると指定します。 それぞれのAS経路セグメントは三重の<経路セグメントタイプ、経路セグメントの長さ、経路セグメント価値の>によって表されます。

   In [BGP-4], the path segment type is a 1-octet field with the two
   following values defined:

[BGP-4]では、経路セグメントタイプは2つの次の値が定義されている1八重奏の分野です:

   Value     Segment Type

値のセグメントタイプ

     1       AS_SET: unordered set of autonomous systems that a route in
             the UPDATE message has traversed

_としての1はセットしました: UPDATEメッセージのルートが横断した順不同のセットの自律システム

     2       AS_SEQUENCE: ordered set of autonomous systems that a route
             in the UPDATE message has traversed

2 _系列として: UPDATEメッセージのルートが横断した順序集合の自律システム

   This document specifies two additional segment types:

このドキュメントは2つの追加セグメントタイプを指定します:

     3       AS_CONFED_SEQUENCE: ordered set of Member Autonomous
             Systems in the local confederation that the UPDATE message
             has traversed

3 _CONFED_系列として: UPDATEメッセージが横断した地元の同盟者におけるメンバーAutonomous Systemsの順序集合

     4       AS_CONFED_SET: unordered set of Member Autonomous Systems
             in the local confederation that the UPDATE message has
             traversed

4 _CONFEDとして、_はセットしました: UPDATEメッセージが横断した地元の同盟者におけるメンバーAutonomous Systemsの順不同のセット

4.  Operation

4. 操作

   A member of a BGP confederation MUST use its AS Confederation
   Identifier in all transactions with peers that are not members of its
   confederation.  This AS Confederation Identifier is the "externally
   visible" AS number, and this number is used in OPEN messages and
   advertised in the AS_PATH attribute.

BGP同盟者のメンバーは同盟者のメンバーでない同輩と共にすべての取引にAS Confederation Identifierを使用しなければなりません。 このAS Confederation Identifierが「外部的に目に見える」AS番号であり、この数をオープンメッセージで使用して、AS_PATH属性で広告を出します。

   A member of a BGP confederation MUST use its Member-AS Number in all
   transactions with peers that are members of the same confederation as
   the local BGP speaker.

BGP同盟者のメンバーは地元のBGPスピーカーと同じ同盟者のメンバーである同輩と共にすべての取引にメンバー-AS Numberを使用しなければなりません。

   A BGP speaker receiving an AS_PATH attribute containing an autonomous
   system matching its own AS Confederation Identifier SHALL treat the
   path in the same fashion as if it had received a path containing its
   own AS number.

まるでそれ自身のAS番号を含む経路を受けたかのようにそれ自身のAS Confederation Identifier SHALLに合っている自律システムを含むAS_PATH属性を受けるBGPスピーカーは同じファッションで経路を扱います。

Traina, et al.              Standards Track                     [Page 5]

RFC 5065                                                     August 2007

Traina、他 規格は2007年8月にRFC5065を追跡します[5ページ]。

   A BGP speaker receiving an AS_PATH attribute containing an
   AS_CONFED_SEQUENCE or AS_CONFED_SET that 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 Number SHALLを含むAS_CONFED_SEQUENCEかAS_CONFED_SETを含むAS_PATH属性を受けるBGPスピーカーは同じファッションで経路を扱います。

4.1.  AS_PATH Modification Rules

4.1. _経路変更規則として

   When implementing BGP confederations, Section 5.1.2 of [BGP-4] is
   replaced with the following text:

BGP同盟者を実行するとき、.2セクション5.1[BGP-4]を以下のテキストに取り替えます:

   AS_PATH is a well-known mandatory attribute.  This attribute
   identifies the autonomous systems through which routing information
   carried in this UPDATE message has passed.  The components of this
   list can be AS_SETs, AS_SEQUENCEs, AS_CONFED_SETs or
   AS_CONFED_SEQUENCES.

AS_PATHは周知の義務的な属性です。 この属性はこのUPDATEメッセージで運ばれたルーティング情報が終わった自律システムを特定します。 このリストの成分は、AS_SETs、AS_SEQUENCEs、AS_CONFED_SETsまたはAS_CONFED_SEQUENCESであるかもしれません。

   When a BGP speaker propagates a route it learned from another BGP
   speaker's UPDATE message, it modifies the route's AS_PATH attribute
   based on the location of the BGP speaker to which the route will be
   sent:

BGPスピーカーがそれが別のBGPスピーカーのUPDATEメッセージから学んだルートを伝播するとき、ルートが送られるBGPスピーカーの位置に基づくルートのAS_PATH属性を変更します:

   a) When a given BGP speaker advertises the route to another BGP
      speaker located in its own Member-AS, the advertising speaker
      SHALL NOT modify the AS_PATH attribute associated with the route.

a) 与えられたBGPスピーカーがそれ自身のメンバー-ASに位置する別のBGPスピーカーにルートの広告を出すとき、広告スピーカーSHALL NOTはルートに関連しているAS_PATH属性を変更します。

   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 confederation, the advertising speaker updates the AS_PATH
      attribute as follows:

b) 与えられたBGPスピーカーが地元の同盟者のメンバーである隣接している自律システムに位置するBGPスピーカーにルートの広告を出すとき、広告スピーカーは以下のAS_PATH属性をアップデートします:

      1) if the first path segment of the AS_PATH is of type
         AS_CONFED_SEQUENCE, the local system prepends its own Member-AS
         number as the last element of the sequence (put it in the
         leftmost position with respect to the position of octets in the
         protocol message).  If the act of prepending will cause an
         overflow in the AS_PATH segment (i.e., more than 255 ASs), it
         SHOULD prepend a new segment of type AS_CONFED_SEQUENCE and
         prepend its own AS number to this new segment.

_1) ASの最初の経路セグメントであるなら、タイプAS_CONFED_SEQUENCE(系列(プロトコルメッセージにおける八重奏の位置に関して一番左位置にそれを入れる)の最後の原理としてのローカルシステムのprependsのそれ自身のメンバー-AS番号)にはPATHがあります。 prependingする行為がAS_PATHセグメント(すなわち、255ASs)でオーバーフローを引き起こして、それがタイプAS_CONFED_SEQUENCEのSHOULD prependのa新しいセグメントであり、prependがそれ自身のASであるなら、これほど新しくセグメントに付番してください。

      2) if the first path segment of the AS_PATH is not of type
         AS_CONFED_SEQUENCE, the local system prepends a new path
         segment of type AS_CONFED_SEQUENCE to the AS_PATH, including
         its own Member-AS Number in that segment.

2) タイプAS_CONFED_SEQUENCEにはPATHがAS_の最初の経路セグメントであるならなくて、ローカルシステムprependsはAS_PATHへのタイプAS_CONFED_SEQUENCEの新しい経路セグメントです、そのセグメントでそれ自身のメンバー-AS Numberを含んでいて。

      3) if the AS_PATH is empty, the local system creates a path
         segment of type AS_CONFED_SEQUENCE, places its own Member-AS
         Number into that segment, and places that segment into the
         AS_PATH.

3) AS_PATHが空であるなら、ローカルシステムは、タイプAS_CONFED_SEQUENCEの経路セグメントを作成して、それ自身のメンバー-AS Numberをそのセグメントに置いて、AS_PATHにそのセグメントを置きます。

Traina, et al.              Standards Track                     [Page 6]

RFC 5065                                                     August 2007

Traina、他 規格は2007年8月にRFC5065を追跡します[6ページ]。

   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 local confederation, the advertising speaker SHALL update the
      AS_PATH attribute as follows:

c) 与えられたBGPスピーカーが地元の同盟者のメンバーでない隣接している自律システムに位置するBGPスピーカーにルートの広告を出すとき、広告スピーカーSHALLは以下のAS_PATH属性をアップデートします:

      1) if any path segments of the AS_PATH are of the type
         AS_CONFED_SEQUENCE or AS_CONFED_SET, those segments MUST be
         removed from the AS_PATH attribute, leaving the sanitized
         AS_PATH attribute to be operated on by steps 2, 3 or 4.

1) AS_PATHの何か経路セグメントがタイプAS_CONFED_SEQUENCEかAS_CONFED_SETのものであるなら、AS_PATH属性からそれらのセグメントを取り除かなければなりません、ステップ2、3または4で操作されるべき殺菌されたAS_PATH属性をオンなままにして。

      2) if the first path segment of the remaining AS_PATH is of type
         AS_SEQUENCE, the local system prepends its own AS Confederation
         Identifier as the last element of the sequence (put it in the
         leftmost position with respect to the position of octets in the
         protocol message).  If the act of prepending will cause an
         overflow in the AS_PATH segment (i.e., more than 255 ASs), it
         SHOULD prepend a new segment of type AS_SEQUENCE and prepend
         its own AS number to this new segment.

_2) 残っているASの最初の経路セグメントであるなら、タイプAS_SEQUENCE(系列(プロトコルメッセージにおける八重奏の位置に関して一番左位置にそれを入れる)の最後の原理としてのローカルシステムのprependsのそれ自身のAS Confederation Identifier)にはPATHがあります。 prependingする行為がAS_PATHセグメント(すなわち、255ASs)でオーバーフローを引き起こして、それがタイプAS_SEQUENCEのSHOULD prependのa新しいセグメントであり、prependがそれ自身のものであるなら、ASはこれほど新しくセグメントに付番します。

      3) if the first path segment of the remaining AS_PATH is of type
         AS_SET, the local system prepends a new path segment of type
         AS_SEQUENCE to the AS_PATH, including its own AS Confederation
         Identifier in that segment.

3) 残っているAS_の最初の経路セグメントであるなら、タイプAS_SETにはPATHがあって、ローカルシステムprependsはそのセグメントでそれ自身のAS Confederation Identifierを含むAS_PATHへのタイプAS_SEQUENCEの新しい経路セグメントです。

      4) if the remaining AS_PATH is empty, the local system creates a
         path segment of type AS_SEQUENCE, places its own AS
         Confederation Identifier into that segment, and places that
         segment into the AS_PATH.

4) 残っているAS_PATHが空であるなら、ローカルシステムは、タイプAS_SEQUENCEの経路セグメントを作成して、それ自身のAS Confederation Identifierをそのセグメントに置いて、AS_PATHにそのセグメントを置きます。

   When a BGP speaker originates a route then:

BGPスピーカーがその時ルートを溯源するとき:

   a) the originating speaker includes its own AS Confederation
      Identifier in a path segment, of type AS_SEQUENCE, in 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 AS Confederation Identifier of
      the originating speaker's autonomous system will be the only entry
      the path segment, and this path segment will be the only segment
      in the AS_PATH attribute.

a) 由来しているスピーカーはタイプAS_SEQUENCEの経路セグメントでそれ自身のAS Confederation Identifierを入れます、地元の同盟者のメンバーでない隣接している自律システムに位置するBGPスピーカーに送られたすべてのUPDATEメッセージのAS_PATH属性で。 この場合、由来しているスピーカーの自律システムのAS Confederation Identifierは唯一のエントリーが経路セグメントであったならそうするでしょう、そして、この経路セグメントはAS_PATH属性で唯一のセグメントになるでしょう。

   b) the originating speaker includes its own Member-AS Number in a
      path segment, of type AS_CONFED_SEQUENCE, in the AS_PATH attribute
      of all UPDATE messages sent to BGP speakers located in neighboring
      Member Autonomous Systems that are members of the local
      confederation.  In this case, the Member-AS Number of the
      originating speaker's autonomous system will be the only entry the
      path segment, and this path segment will be the only segment in
      the AS_PATH attribute.

b) 由来しているスピーカーはタイプAS_CONFED_SEQUENCEの経路セグメントでそれ自身のメンバー-AS Numberを入れます、地元の同盟者のメンバーであるメンバーAutonomous Systemsを近所付き合いさせる際に位置するBGPスピーカーに送られたすべてのUPDATEメッセージのAS_PATH属性で。 この場合、由来しているスピーカーの自律システムのメンバー-AS Numberは唯一のエントリーが経路セグメントであったならそうするでしょう、そして、この経路セグメントはAS_PATH属性で唯一のセグメントになるでしょう。

Traina, et al.              Standards Track                     [Page 7]

RFC 5065                                                     August 2007

Traina、他 規格は2007年8月にRFC5065を追跡します[7ページ]。

   c) the originating speaker includes an empty AS_PATH attribute in all
      UPDATE messages sent to BGP speakers residing within the same
      Member-AS.  (An empty AS_PATH attribute is one whose length field
      contains the value zero).

c) 由来しているスピーカーは同じメンバー-ASの中に住んでいるBGPスピーカーに送られたすべてのUPDATEメッセージで空のAS_PATH属性を入れます。 (空のAS_PATH属性は長さの分野が値ゼロを含むものです。)

   Whenever the modification of the AS_PATH attribute calls for
   including or prepending the AS Confederation Identifier or Member-AS
   Number of the local system, the local system MAY include/prepend more
   than one instance of that value in the AS_PATH attribute.  This is
   controlled via local configuration.

AS_PATH属性の変更が、ローカルシステムのAS Confederation Identifierかメンバー-AS Numberを含んでいるか、またはprependingするように求めるときはいつも、ローカルシステムはAS_PATH属性におけるその価値の1つの例より/prependを含むかもしれません。 これは地方の構成で制御されます。

5.  Error Handling

5. エラー処理

   A BGP speaker MUST NOT transmit updates containing AS_CONFED_SET or
   AS_CONFED_SEQUENCE attributes to peers that are not members of the
   local confederation.

BGPスピーカーはAS_CONFED_SETを含むアップデートかAS_CONFED_SEQUENCE属性を地元の同盟者のメンバーでない同輩に伝えてはいけません。

   It is an error for a BGP speaker to receive an UPDATE message with an
   AS_PATH attribute that contains AS_CONFED_SEQUENCE or AS_CONFED_SET
   segments from a neighbor that is not located in the same
   confederation.  If a BGP speaker receives such an UPDATE message, it
   SHALL treat the message as having a malformed AS_PATH according to
   the procedures of [BGP-4], Section 6.3 ("UPDATE Message Error
   Handling").

同じ同盟者で位置していないのは、BGPスピーカーがAS_CONFED_SEQUENCEを含むAS_PATH属性かAS_CONFED_SETセグメントで隣人からUPDATEメッセージを受け取る誤りです。 BGPスピーカーがそのようなものを受けるなら、UPDATEは通信します、それ。SHALLは[BGP-4]の手順によると、奇形のAS_PATHを持っているとしてメッセージを扱います、セクション6.3(「アップデートメッセージエラー処理」)。

   It is a error for a BGP speaker to receive an update message from a
   confederation peer that is not in the same Member-AS that does not
   have AS_CONFED_SEQUENCE as the first segment.  If a BGP speaker
   receives such an UPDATE message, it SHALL treat the message as having
   a malformed AS_PATH according to the procedures of [BGP-4], Section
   6.3 ("UPDATE Message Error Handling").

最初のセグメントとしてAS_CONFED_SEQUENCEを持っていないのと同じメンバー-ASにないのは、BGPスピーカーが同盟者同輩からアップデートメッセージを受け取る誤りです。 BGPスピーカーがそのようなものを受けるなら、UPDATEは通信します、それ。SHALLは[BGP-4]の手順によると、奇形のAS_PATHを持っているとしてメッセージを扱います、セクション6.3(「アップデートメッセージエラー処理」)。

5.1.  Common Administrative Issues

5.1. 一般的な管理問題

   It is reasonable for Member Autonomous Systems of a confederation to
   share a common administration and Interior Gateway Protocol (IGP)
   information for the entire confederation.  It is also reasonable for
   each Member-AS to run an independent IGP.  In the latter case, the
   NEXT_HOP may need to be set using policy (i.e., by default it is
   unchanged).

同盟者のメンバーAutonomous Systemsが全体の同盟者のために一般的な管理とInteriorゲートウェイプロトコル(IGP)情報を共有するのは、妥当です。 また、各メンバー-ASが独立しているIGPを走らせるのも、妥当です。 後者の場合では、ネクスト_HOPは、方針を使用するように設定される必要があるかもしれません(デフォルトで、すなわち、それは変わりがありません)。

5.2.  MED and LOCAL_PREF Handling

5.2. 医学の、そして、地方の_PREF取り扱い

   It SHALL be legal for a BGP speaker to advertise an unchanged
   NEXT_HOP and MULTI_EXIT_DISC (MED) attribute to peers in a
   neighboring Member-AS of the local confederation.

それ、SHALL、BGPスピーカーが変わりのないネクスト_HOPとMULTI_EXIT_DISC(MED)属性の地元の同盟者の隣接しているメンバー-ASの同輩に広告を出すには、法的であってください。

Traina, et al.              Standards Track                     [Page 8]

RFC 5065                                                     August 2007

Traina、他 規格は2007年8月にRFC5065を追跡します[8ページ]。

   MEDs of two routes SHOULD only be compared if the first autonomous
   systems in the first AS_SEQUENCE in both routes are the same -- i.e.,
   skip all the autonomous systems in the AS_CONFED_SET and
   AS_CONFED_SEQUENCE.  An implementation MAY provide the ability to
   configure path selection such that MEDs of two routes are comparable
   if the first autonomous systems in the AS_PATHs are the same,
   regardless of AS_SEQUENCE or AS_CONFED_SEQUENCE in the AS_PATH.

両方のルートにおける最初のAS_SEQUENCEにおける最初の自律システムが同じである場合にだけ比べて、2のMEDsはSHOULDを発送します--すなわち、AS_CONFED_SETとAS_CONFED_SEQUENCEですべての自律システムをスキップしてください。 実現が経路選択を構成する能力を提供するかもしれないので、AS_PATHsにおける最初の自律システムがAS_SEQUENCEかAS_CONFED_SEQUENCEにかかわらずAS_PATHで同じであるなら、2つのルートのMEDsは匹敵しています。

   An implementation MAY compare MEDs received from a Member-AS via
   multiple paths.  An implementation MAY compare MEDs from different
   Member Autonomous Systems of the same confederation.

実現は複数の経路を通してメンバー-ASから受け取られたMEDsを比較するかもしれません。 実現は同じ同盟者の異なったメンバーAutonomous SystemsからMEDsを比較するかもしれません。

   In addition, the restriction against sending the LOCAL_PREF attribute
   to peers in a neighboring autonomous system within the same
   confederation is removed.

さらに、同じ同盟者の中でLOCAL_PREF属性を隣接している自律システムの同輩に送ることに対する制限を取り除きます。

5.3.  AS_PATH and Path Selection

5.3. _経路と経路選択として

   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 [BGP-4].

同盟者の中にメンバーから受け取られた情報の経路選択評価基準は同じ自律システムの中のメンバーから受け取られた情報に使用される同じ規則に従わなければなりません、[BGP-4]で指定されるように。

   In addition, the following rules SHALL be applied:

さらに、適用されていて、以下はSHALLを統治します:

   1) If the AS_PATH is internal to the local confederation (i.e., there
      are only AS_CONFED_* segments), consider the neighbor AS to be the
      local AS.

1) 地元の同盟者にとって、AS_PATHが内部であるなら(すなわち、AS_CONFED_*セグメントしかありません)、隣人ASが地方のASであると考えてください。

   2) Otherwise, if the first segment in the path that is not an
      AS_CONFED_SEQUENCE or AS_CONFED_SET is an AS_SEQUENCE, consider
      the neighbor AS to be the leftmost AS_SEQUENCE AS.

2) さもなければ、AS_CONFED_SEQUENCEでなくて、またまたはAS_CONFED_SETでもない経路における最初のセグメントがAS_SEQUENCEであるなら隣人ASが一番左AS_SEQUENCE ASであると考えてください。

   3) When comparing routes using AS_PATH length, CONFED_SEQUENCE and
      CONFED_SETs SHOULD NOT be counted.

3) AS_PATHの長さ、CONFED_SEQUENCE、およびCONFED_SETs SHOULDを使用することでルートを比較するときには、数えられないでください。

   4) When comparing routes using the internal (IBGP learned) versus
      external (EBGP learned) rules, treat a route that is learned from
      a peer that is in the same confederation (not necessarily the same
      Member-AS) as "internal".

4) (EBGPは学びました)外部の規則に対して内部を使用することで(IBGPは学びました)ルートを比較するときには、「内部」として同じ同盟者中であることの同輩(必ず同じメンバー-ASでない)から学習されるルートを扱ってください。

Traina, et al.              Standards Track                     [Page 9]

RFC 5065                                                     August 2007

Traina、他 規格は2007年8月にRFC5065を追跡します[9ページ]。

6.  Compatibility Considerations

6. 互換性問題

   All BGP speakers participating as members of a confederation MUST
   recognize the AS_CONFED_SET and AS_CONFED_SEQUENCE segment type
   extensions to the AS_PATH attribute.

同盟者のメンバーが、_CONFED_SETとAS_CONFEDが_SEQUENCEセグメントであると認めなければならないので参加するすべてのBGPスピーカーがAS_PATH属性に拡大をタイプします。

   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スピーカーも「アップデートメッセージ誤り」と「_経路としての奇形」のサブコードを指定するNOTIFICATIONメッセージを発生させるでしょう。

   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同盟者を支持しなければならないのを含意します。 しかしながら、同盟者の外のBGPスピーカーはこれらの拡大を支持する必要はありません。

7.  Deployment Considerations

7. 展開問題

   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.

手動で同盟者のトポロジーと冗長要件に基づく複数のメンバーAutonomous Systemsを通してリレーされる可到達性情報によって引き起こされた写し広告をフィルターにかけるために注意するべきです。

   Additionally, confederations (as well as route reflectors), by
   excluding different reachability information from consideration at
   different locations in a confederation, have been shown [RFC3345] to
   cause permanent oscillation between candidate routes when using the
   tie-breaking rules required by BGP [BGP-4].  Care must be taken when
   selecting MED values and tie-breaking policy to avoid these
   situations.

さらに、別の場所で同盟者で異なった可到達性情報を考慮に入れないようにすることによって、同盟者(ルート反射鏡と同様に)は繋がりを壊す規則を使用するときの候補ルートの間の永久的な振動がBGP[BGP-4]が必要であることが原因に示されました[RFC3345]。 これらの状況を避けるために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測定基準、そして/または、BGPを避けるのに他の繋がりを壊す方針を使用すると比較にならないほどMEDsに基づく選択が発送されるより高く構成することです。

8.  Security Considerations

8. セキュリティ問題

   This extension to BGP does not change the underlying security issues
   inherent in the existing BGP protocol, such as those described in
   [RFC2385] and [BGP-VULN].

BGPへのこの拡大は既存のBGPプロトコルの固有である[RFC2385]と[BGP-VULN]で説明されたものなどの基本的な安全保障問題を変えません。

Traina, et al.              Standards Track                    [Page 10]

RFC 5065                                                     August 2007

Traina、他 規格は2007年8月にRFC5065を追跡します[10ページ]。

9.  Acknowledgments

9. 承認

   The general concept of BGP confederations was taken from IDRP's
   Routing Domain Confederations [ISO10747].  Some of the introductory
   text in this document was taken from [RFC2796].

IDRPのルート設定Domain Confederations[ISO10747]からBGP同盟者の一般概念を取りました。 [RFC2796]から紹介しているテキストのいくつかを本書では取りました。

   The authors would like to acknowledge Jeffrey Haas for his extensive
   feedback on this document.  We'd also like to thank Bruce Cole,
   Srihari Ramachandra, Alex Zinin, Naresh Kumar Paliwal, Jeffrey Haas,
   Cengiz Alaettinoglu, Mike Hollyman, and Bruno Rijsman for their
   feedback and suggestions.

作者はこのドキュメントの彼の大規模なフィードバックのためにジェフリー・ハースを承認したがっています。 また、彼らのフィードバックと提案についてブルース・コール、Srihari Ramachandra、アレックス・ジニン、NareshクマーPaliwal、ジェフリー・ハース、Cengiz Alaettinoglu、マイクHollyman、およびブルーノRijsmanに感謝申し上げます。

   Finally, we'd like to acknowledge Ravi Chandra and Yakov Rekhter for
   providing constructive and valuable feedback on earlier versions of
   this specification.

最終的に、この仕様の以前のバージョンの建設的で有益なフィードバックを提供するためにラービーチャンドラとヤコフRekhterを承認したいと思います。

10.  References

10. 参照

10.1.  Normative References

10.1. 引用規格

   [BGP-4]    Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271, January
              2006.

[BGP-4]Rekhter、Y.(エド)、李、T.(エド)、およびS.野兎(エド)、「境界ゲートウェイは4(BGP-4)について議定書の中で述べます」、RFC4271、2006年1月。

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

[RFC1965] Traina、P.、「BGPのための自律システム同盟者」、RFC1965、1996年6月。

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [RFC3065]  Traina, P., McPherson, D., and J. Scudder, "Autonomous
              System Confederations for BGP", RFC 3065, February 2001.

2001年2月の[RFC3065]TrainaとP.とマクファーソン、D.とJ.Scudder、「BGPのための自律システム同盟者」RFC3065。

10.2.  Informative References

10.2. 有益な参照

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

[ISO10747] Kunzinger、C.、エディタ、「相互ドメインルーティング・プロトコル」、ISO/IEC10747、1993年10月。

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

[RFC1863]ハスキン、1995年10月のD.、「完全なメッシュルーティングへのBGP/IDRP Route Server代替手段」RFC1863。

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

[RFC2385] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。

   [RFC3345]  McPherson, D., Gill, V., Walton, D., and A. Retana,
              "Border Gateway Protocol (BGP) Persistent Route
              Oscillation Condition", RFC 3345, August 2002.

[RFC3345] マクファーソン、D.、エラ、V.、ウォルトン、D.、およびA.レタナは「ゲートウェイのプロトコルの(BGP)しつこいルート振動状態に接しています」、RFC3345、2002年8月。

Traina, et al.              Standards Track                    [Page 11]

RFC 5065                                                     August 2007

Traina、他 規格は2007年8月にRFC5065を追跡します[11ページ]。

   [RFC4223]  Savola, P., "Reclassification of RFC 1863 to Historic",
              RFC 4223, October 2005.

[RFC4223]Savola、P.、「Reclassification、歴史的へのRFC1863、」、RFC4223、10月2005日

   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis", RFC
              4272, January 2006.

[RFC4272] マーフィー、S.、「BGPセキュリティの脆弱性分析」、RFC4272、2006年1月。

   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
              Reflection: An Alternative to Full Mesh Internal BGP
              (IBGP)", RFC 4456, April 2006.

[RFC4456] ベイツ、T.、チェン、E.、およびR.チャンドラ、「BGPは反射を発送します」。 「完全なメッシュ内部のBGP(IBGP)への代替手段」、RFC4456、2006年4月。

Traina, et al.              Standards Track                    [Page 12]

RFC 5065                                                     August 2007

Traina、他 規格は2007年8月にRFC5065を追跡します[12ページ]。

Appendix A.  Aggregate Routing Information

付録のA.の集合経路情報

   As a practical matter, aggregation as discussed in [BGP-4], Section
   9.2.2.2, is not generally employed within confederations.  However,
   in the event that such aggregation is performed within a
   confederation, the rules of [BGP-4] should be followed, making the
   necessary substitutions between AS_SET and AS_CONFED_SET and
   similarly, AS_SEQUENCE and AS_CONFED_SEQUENCE.  Confederation-type
   segments (AS_CONFED_SET and AS_CONFED_SEQUENCE) MUST be kept separate
   from non-confederation segments (AS_SET and AS_SEQUENCE).  An
   implementation could also choose to provide a form of aggregation
   wherein non-confederation segments are aggregated as discussed in
   [BGP-4], Section 9.2.2.2, and confederation-type segments are not
   aggregated.

一般に、実用的な件、[BGP-4]、セクション9.2.2で議論する集合として、.2は同盟者の中で採用していません。 しかしながら、そのような集合が同盟者の中で実行される場合、[BGP-4]の規則は従われるべきです、AS_SEQUENCEとAS_CONFED_SEQUENCE、AS_SETとAS_CONFED_SETの間、そして、同様に必要な代替をして。 同盟者タイプセグメント(AS_CONFED_SETとAS_CONFED_SEQUENCE)を非同盟者セグメント(AS_SETとAS_SEQUENCE)から別々に保たなければなりません。 また、実現は、議論して、セグメントがセクション9.2.2の[BGP-4]、.2、および同盟者タイプで集められないとき非同盟者セグメントが集められる集合のフォームを提供するのを選ぶかもしれません。

   Support for aggregation of confederation-type segments is not
   mandatory.

同盟者タイプセグメントの集合のサポートは義務的ではありません。

Appendix B.  Changes from RFC 3065

RFC3065からの付録B.変化

   The primary trigger for an update to RFC 3065 was regarding issues
   associated with AS path segment handling, in particular what to do
   when interacting with BGP peers external to a confederation and to
   ensure AS_CONFED_[SET|SEQUENCE] segment types are not propagated to
   peers outside of a confederation.

_AS経路セグメント取り扱いに関連している問題に関してRFC3065へのアップデートのための第一の引き金がありました、そして、BGPと対話するとき、特にするべきことは同盟者にとって外部であることの形でじっと見ます、そして、ASを確実にするために、CONFED_[SET| SEQUENCE]セグメントタイプは同盟者の外で同輩に伝播されません。

   As such, the "Error Handling" section above was added and applies not
   only to BGP confederation speakers, but to all BGP speakers.

そういうものとして、上の「エラー処理」セクションは、すべてのBGPスピーカーにも加えられて、BGP同盟者スピーカーに適用するだけではなく、適用されます。

   Other changes are mostly trivial and surrounding some clarification
   and consistency in terminology and denoting that
   AS_CONFED_[SET|SEQUENCE] Segment Type handling should be just as it
   is in the base BGP specification [BGP-4].

他の変化はほとんど些細です、そして、用語の何らかの明確化と一貫性を囲んでいて、ちょうどそれとしてAS_CONFED_[SET| SEQUENCE]セグメントType取り扱いがそうあるべきであるのを指示するのがベースBGP仕様[BGP-4]にあります。

Authors' Addresses

作者のアドレス

   Paul Traina
   Blissfully Retired
   Email: bgp-confederations@st04.pst.org

ポールTrainaは幸せにメールを回収しました: bgp-confederations@st04.pst.org

   Danny McPherson
   Arbor Networks
   EMail: danny@arbor.net

ダニーマクファーソンあずまやネットワークはメールされます: danny@arbor.net

   John G. Scudder
   Juniper Networks
   EMail: jgs@juniper.net

ジョンG.Scudder杜松ネットワークはメールされます: jgs@juniper.net

Traina, et al.              Standards Track                    [Page 13]

RFC 5065                                                     August 2007

Traina、他 規格は2007年8月にRFC5065を追跡します[13ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Traina, et al.              Standards Track                    [Page 14]

Traina、他 標準化過程[14ページ]