Network Working Group S. Mirtorabi
Request for Comments: 5185 Nuova Systems
Category: Standards Track P. Psenak
Cisco Systems
A. Lindem, Ed.
A. Oswal
Redback Networks
May 2008
OSPF Multi-Area Adjacency
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）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
This document describes an extension to the Open Shortest Path First (OSPF) protocol to allow a single physical link to be shared by multiple areas. This is necessary to allow the link to be considered an intra-area link in multiple areas. This would create an intra-area path in each of the corresponding areas sharing the same link.
この文書では、単一の物理リンクが複数の領域で共有することを可能にするオープンショーテストパスファースト（OSPF）プロトコルの拡張を記述しています。これは、リンクが複数のエリアでエリア内のリンクと考えることができるようにする必要があります。これは、同一のリンクを共有し、対応する領域毎にエリア内のパスを作成します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Possible Solutions . . . . . . . . . . . . . . . . . . . . 3
1.3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . 4
1.4. Requirements Notation . . . . . . . . . . . . . . . . . . . 4
2. Functional Specifications . . . . . . . . . . . . . . . . . . . 4
2.1. Multi-Area Adjacency Configuration and Neighbor
Discovery . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Multi-Area Adjacency Packet Transmission . . . . . . . . . 5
2.3. Multi-Area Adjacency Control Packet Reception Changes . . . 5
2.4. Interface Data Structure . . . . . . . . . . . . . . . . . 6
2.5. Interface FSM . . . . . . . . . . . . . . . . . . . . . . . 6
2.6. Neighbor Data Structure and Neighbor FSM . . . . . . . . . 6
2.7. Advertising Multi-Area Adjacencies . . . . . . . . . . . . 6
3. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Adjacency Endpoint Compatibility . . . . . . . . . . . . . 7
4. OSPFv3 Applicability . . . . . . . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Normative References . . . . . . . . . . . . . . . . . . . 8
6.2. Informative References . . . . . . . . . . . . . . . . . . 8
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 9
It is often a requirement to have an Open Shortest Path First (OSPF) [OSPF] link in multiple areas. This will allow the link to be considered as an intra-area path in each area and be preferred over higher cost links. A simple example of this requirement is to use a high-speed link between two Area Border Routers (ABRs)in multiple areas.
複数のエリアにオープン最短パスファースト（OSPF）[OSPF]リンクを有することがしばしば必要条件です。これは、リンクは、各エリアのエリア内パスとして考慮されるように、より高いコストリンクよりも好ましいことができます。この要件の簡単な例では、複数の領域に2つの分割境界ルータ（のABR）との間の高速リンクを使用することです。
Consider the following topology:
次のトポロジを考えてみます。
R1-------Backbone------R2
| |
Area 1 Area 1
| |
R3--------Area 1--------R4
Multi-Link Topology
マルチリンクトポロジ
The backbone area link between R1 and R2 is a high-speed link, and it is desirable to forward Area 1's traffic between R1 and R2 over that link. In the current OSPF specification [OSPF], intra-area paths are preferred over inter-area paths. As a result, R1 will always route traffic to R4 through Area 1 over the lower speed links. R1 will even use the intra-area Area 1 path though R3 to get to Area 1 networks connected to R2. An OSPF virtual link cannot be used to solve this problem without moving the link between R1 and R2 to Area 1. This is not desirable if the physical link is, in fact, part of the network's backbone topology.
R1とR2の間バックボーンエリアリンクは高速リンクであり、そのリンク上でR1とR2との間の領域1のトラフィックを転送することが望ましいです。現在のOSPF仕様[OSPF]において、エリア内経路は、エリア間の経路よりも好ましいです。その結果、R1は、低速リンク上でエリア1からR4まで常にトラフィックをルーティングなります。 R3は、エリアにR2に接続されたネットワーク1を取得するのにR1でもエリア内エリア1パスを使用します。 OSPF仮想リンクは、物理リンクが、実際には、ネットワークのバックボーン・トポロジの一部である場合はエリア1にR1とR2の間のリンクを移動することなく、これは望ましいことではない。この問題を解決するために使用することはできません。
The protocol extension described herein will rectify this problem by allowing the link between R1 and R2 to be part of both the backbone area and Area 1.
本明細書に記載のプロトコル拡張は、バックボーンエリアとエリア1の両方の一部であるとR1とR2との間のリンクを可能にすることによって、この問題を修正します。
For numbered interfaces, the OSPF (Open Shortest Path First) specification [OSPF] allows a separate OSPF interface to be configured in each area using a secondary address. The disadvantages of this approach are that it requires additional IP address configuration, it doesn't apply to unnumbered interfaces, and advertising secondary addresses will result in a larger overall routing table.
番号のインターフェイスのために、OSPF（オープンショーテストパスファースト）仕様[OSPF]は別個OSPFインターフェイスがセカンダリアドレスを使用して、各領域で構成されることを可能にします。このアプローチの欠点は、それがアンナンバードインターフェイスには適用されません、およびセカンダリアドレスを広告することは、より大きな全体のルーティングテーブルになり、それは追加のIPアドレスの設定が必要であることです。
Allowing a link with a single address to simply be configured in multiple areas would also solve the problem. However, this would result in the subnet corresponding to the interface residing in multiple areas that is contrary to the definition of an OSPF area as a collection of subnets.
単に複数のエリアで構成するための単一のアドレスとのリンクを可能にすることも、問題は解決するだろう。しかしながら、これは、サブネットの集合としてOSPFエリアの定義に反して複数の領域に存在する界面に対応するサブネットをもたらすであろう。
Another approach is to simply allow unnumbered links to be configured in multiple areas. Section 8.2. of the OSPF specification [OSPF] already specifies that the OSPF area ID should be used to de-multiplex received OSPF packets. One limitation of this approach is that multi-access networks are not supported. Although this limitation may be overcome for LAN media with support of "Point-to-Point operation over LAN in link-state routing protocols" [P2PLAN], it may not be acceptable to configure the link as unnumbered due to network management policies. Many popular network management applications individually test the path to each interface by pinging its IP address.
別のアプローチは、単に番号のないリンクが複数のエリアで構成することができるようにすることです。セクション8.2。 OSPF仕様の[OSPF]既にOSPFエリアIDが多重を解除するために使用されるOSPFパケットを受信するように指定。このアプローチの1つの制限は、マルチアクセスネットワークがサポートされていないことです。この制限は、[P2PLAN「リンクステートルーティングプロトコルでLAN上にポイントツーポイント操作」の支援を受けてLAN媒体に克服することができるが、ネットワーク管理ポリシーに無数のようなリンクを設定するために許容されないかもしれません。多くの一般的なネットワーク管理アプリケーションは、個別にそのIPアドレスをpingすることで、各インタフェースへのパスをテストします。
ABRs will simply establish multiple adjacencies belonging to different areas. Each multi-area adjacency is announced as a point-to-point link in the configured area. However, unlike numbered point-to-point links, no type 3 link is advertised for multi-area adjacencies. This point-to-point link will provide a topological path for that area. The first or primary adjacency using the link will operate and advertise the link in a manner consistent with RFC 2328 [OSPF].
ABRは、単に異なる領域に属する複数の隣接関係を確立します。各マルチエリア隣接関係が設定領域内のポイントツーポイントリンクとして発表されています。ただし、番号のポイントツーポイントリンクとは異なり、タイプ3リンクはマルチエリア隣接関係のために宣伝されていません。このポイントツーポイントリンクは、そのエリアのトポロジパスを提供します。動作及びRFC 2328 [OSPF]と一致する形でリンクをアドバタイズしますリンクを使用して第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 [RFC-KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [RFC-KEYWORDS]に記載されているように解釈されます。
Multi-area adjacencies are configured between two routers having a common interface. On point-to-point interfaces, there is no need to configure the neighbor's address since there can be only one neighbor. For all other network types, the neighbor address of each multi-area adjacency must be configured or automatically discovered via a mechanism external to OSPF.
マルチエリアの隣接関係は、共通のインタフェースを有する二つのルータの間に構成されています。ポイントツーポイントインターフェイスでは、唯一の隣人が存在することができるので、隣人のアドレスを設定する必要はありません。他のすべてのネットワークタイプのために、各マルチエリア隣接の隣接アドレスを設定する必要があり、または、自動的にOSPFの外部機構を介して発見しました。
On point-to-point interfaces, OSPF control packets are sent to the AllSPFRouters address. For all other network types, OSPF control packets are unicast to the remote neighbor's IP address.
ポイントツーポイントインターフェイス上で、OSPF制御パケットがAllSPFRoutersアドレスに送信されます。他のすべてのネットワーク・タイプの場合、OSPF制御パケットは、リモートネイバーのIPアドレスへのユニキャストです。
Receiving protocol packets is described in Section 8.2 of [OSPF]. The text starting with the second paragraph and continuing through the third bullet beneath that paragraph is changed as follows:
プロトコルパケットを受信する[OSPF]のセクション8.2に記載されています。次のように第二段落で開始し、その段落の下に第三弾を介して継続テキストが変更されます。
Next, the OSPF packet header is verified. The fields specified in the header must match those configured for the receiving interface. If they do not, the packet should be discarded:
次に、OSPFパケットヘッダが検証されます。ヘッダで指定されたフィールドは、受信インタフェース用に設定されるものと一致する必要があります。そうでない場合は、パケットが破棄されるべきです。
o The version number field must specify protocol version 2.
Oバージョン番号フィールドには、プロトコルバージョン2を指定する必要があります。
o The Area ID found in the OSPF header must be verified. If all of the following cases fail, the packet should be discarded. The Area ID specified in the header must either:
O OSPFヘッダに見出されるエリアIDが検証されなければなりません。以下の例すべてが失敗した場合、パケットは破棄されなければなりません。ヘッダのいずれかにする必要があり、指定エリアID：
1. Match the Area ID of the receiving interface. In this case, the packet has been sent over a single hop. Therefore, the packet's IP source address is required to be on the same network as the receiving interface. This can be verified by comparing the packet's IP source address to the interface's IP address, after masking both addresses with the interface mask. This comparison should not be performed on point-to-point networks. On point-to-point networks, the interface addresses of each end of the link are assigned independently, if they are assigned at all.
1.受信インタフェースのエリアIDと一致します。この場合、パケットは、単一のホップを介して送信されてきました。したがって、パケットのIPソースアドレスは、受信インタフェースと同じネットワーク上にあることが必要です。これは、インタフェースマスクで両方のアドレスをマスクした後、インターフェイスのIPアドレスへのパケットの送信元IPアドレスを比較することによって確認することができます。この比較は、ポイントツーポイントネットワーク上で実行するべきではありません。彼らが全く割り当てられている場合は、ポイントツーポイントネットワークでは、リンクの両端のインターフェイスアドレスは、独立して割り当てられます。
2. Indicate a non-backbone area. In this case, the packet has been sent over a multi-area adjacency. If the area-id matches the configured area for a multi-area adjacency, the packet is accepted and is from now on associated with the multi-area adjacency for that area.
2.非バックボーンエリアを示します。この場合、パケットは、マルチエリア隣接介して送信されてきました。エリアIDがマルチエリア隣接に対して設定領域と一致する場合、パケットは受け入れられ、今からその領域のマルチエリア隣接関係に関連した上です。
3. Indicate the backbone. In this case, the packet has been sent over a virtual link or a multi-area adjacency.
3.バックボーンを示します。この場合、パケットは、仮想リンクまたはマルチエリア隣接関係を介して送信されてきました。
o For virtual links, the receiving router must be an ABR, and the Router ID specified in the packet (the source router) must be the other end of a configured virtual link. The receiving interface must also attach to the virtual link's configured transit area. If all of these checks succeed, the packet is accepted and is from now on associated with the virtual link.
O仮想リンクについて、受信ルータは、ABRでなければならず、パケット（ソースルータ）に指定されたルータIDが設定された仮想リンクのもう一方の端でなければなりません。受信インタフェースは、仮想リンクの構成されたトランジットエリアにアタッチする必要があります。これらのチェックのすべてが成功した場合、パケットは受け入れられ、今で仮想リンクに関連付けられている上からです。
o For multi-area adjacencies, if the area-id matches the configured area for the multi-area adjacency, the packet is accepted and is from now on associated with the multi-area adjacency for that area.
エリアIDがマルチエリア隣接に対して設定領域と一致する場合、マルチエリア隣接関係のため、O、パケットは受け入れられ、今からその領域のマルチエリア隣接関係に関連した上にあります。
o Note that if there is a match for both a virtual link and a multi-area adjacency then this is a configuration error that should be handled at the configuration level.
O仮想リンク及びマルチエリア隣接両方に一致がある場合、これはコンフィギュレーションレベルで処理されるべき構成エラーであることに留意されたいです。
o Packets whose IP destination is AllDRouters should only be accepted if the state of the receiving interface is DR or Backup (see Section 9.1 of [OSPF]).
そのIP宛先（[OSPF]のセクション9.1を参照）受信インタフェースの状態は、DRまたはバックアップである場合AllDRoutersのみ受け入れられるべきであるOパケット。
o [...] The remainder of Section 8.2 of [OSPF] is unchanged.
O [...] [OSPF]の8.2節の残りの部分は変更されません。
An OSPF interface data structure is built for each configured multi-area adjacency as specified in Section 9 of [OSPF]. The interface type will always be point-to-point.
OSPFインターフェイス[OSPF]のセクション9で指定されたデータ構造は、各構成されたマルチエリア隣接関係のために構築されています。インターフェイスタイプは常にポイント・ツー・ポイントになります。
The interface Finite State Machine (FSM) will be the same as a point-to-point link irrespective of the underlying physical link.
インタフェース有限状態機械（FSM）は、基礎となる物理リンクのかかわらず、ポイントツーポイントリンクと同じになります。
Both the neighbor data structure and neighbor FSM are the same as for standard OSPF, specified in Section 10 of [OSPF].
両方の隣接データ構造と隣接FSMは、[OSPF]のセクション10で指定された、標準的なOSPFの場合と同じです。
Multi-area adjacencies are announced as point-to-point links. Once the router's multi-area adjacency reaches the FULL state, it will be added as a link type 1 to the Router Link State Advertisement (LSA) with:
マルチエリア隣接関係は、ポイントツーポイントリンクとして発表されています。ルータのマルチエリア隣接関係がFULL状態に達すると、それはで、ルータのリンクステートアドバタイズメント（LSA）へのリンクタイプ1として追加されます。
Link ID = Remote's Router ID
リンクID =リモートのルータID
Link Data = Neighbor's IP Address or IfIndex (if the underlying interface is unnumbered).
リンクデータ=ネイバーのIPアドレスまたはifIndexの（根本的なインターフェースに番号が付いていない場合）。
Unlike numbered point-to-point links, no type 3 link is advertised for multi-area adjacencies.
番号のポイントツーポイントリンクとは異なり、タイプ3リンクは、マルチエリアの隣接関係のためにアドバタイズされません。
All mechanisms described in this document are backward compatible with standard OSPF implementations [OSPF].
この文書に記載されているすべての機構は、標準的なOSPFの実装[OSPF]との下位互換性があります。
Since multi-area adjacencies are modeled as point-to-point links, it is only necessary for the router at the other end of the adjacency to model the adjacency as a point-to-point link. However, the network topology will be easier to represent and troubleshoot if both neighbors are symmetrically configured as multi-area adjacencies.
マルチエリアの隣接関係がポイントツーポイントリンクとしてモデル化されているので、ポイントツーポイントリンクとして隣接関係をモデル化するために隣接の他端にルータのためにのみ必要です。両方の隣人が対称マルチエリアの隣接関係として構成されている場合は、ネットワークトポロジが表現とトラブルシューティングが容易になります。
The mechanisms defined in this document also apply to OSPFv3 [OSPFV3]. As in OSPF, a multi-area adjacency is advertised as a point-to-point link in the advertising router's router-LSA. Since OSPFv3 router-LSA links are independent of addressing semantics and unambiguously identify OSPFv3 neighbors (refer to Section 3.4.3.1 of [OSPFV3]), the change to router-LSA links described in Section 2.7 is not applicable to OSPFv3. Furthermore, no prefixes corresponding to the multi-area adjacency are advertised in the router's intra-area-prefix-LSA.
この文書で定義されたメカニズムはまた、OSPFv3の【のOSPFv3]に適用されます。 OSPFのように、マルチエリア隣接関係は、広告ルータのルータLSAでのポイントツーポイントリンクとしてアドバタイズされます。 OSPFv3のルータLSAリンクアドレッシングセマンティクスとは無関係であると明確のOSPFv3ネイバーを識別するため（セクション3.4.3.1を参照[OSPFv3は】）、2.7節に記載ルータLSAリンクへの変更は、OSPFv3のに適用されません。さらに、マルチエリア隣接関係に対応するプレフィックスは、ルータのエリア内プレフィックス-LSAでアドバタイズされません。
A link-LSA SHOULD NOT be advertised for a multi-area adjacency. The neighbor's IPv6 link local address can be learned in other ways, e.g., it can be extracted from the IPv6 header of Hello packets received over the multi-area adjacency. The neighbor IPv6 link local address is required for the OSPFv3 route next-hop calculation on multi-access networks (refer to Section 3.8.1.1 of [OSPFV3]).
リンクLSAは、マルチエリア隣接関係のために広告されるべきではありません。隣人のIPv6リンクローカルアドレスは、他の方法で学習することができ、例えば、それはHelloパケットのIPv6ヘッダから抽出することができるマルチエリア隣接介して受信。ネイバーのIPv6リンクローカルアドレスは、マルチアクセスネットワーク上のOSPFv3ルートのネクストホップ計算（[OSPFv3の]のセクション3.8.1.1を参照）に必要とされます。
This document does not raise any security issues that are not already covered in [OSPF] or [OSPFV3].
この文書では、すでに[OSPF]または[OSPFv3の]でカバーされていない任意のセキュリティ上の問題を提起しません。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF]モイ、J.、 "OSPFバージョン2"、STD 54、RFC 2328、1998年4月。
[OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
【のOSPFv3] Coltun、R.、ファーガソン、D.、およびJ.モイ、 "IPv6のためのOSPF"、RFC 2740、1999年12月。
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[P2PLAN] Shen, N. and A. Zinin, "Point-to-point operation over LAN in link-state routing protocols", Work in Progress.
【P2PLAN]シェン、N.とA.ジニン、「リンクステートルーティングプロトコルにおけるLAN経由ポイントツーポイント操作」、ProgressのWork。
Appendix A. Acknowledgments
付録A.謝辞
The authors wish to acknowledge Pat Murphy for convincing the OSPF WG to address the requirement.
著者は、要件に対処するためにOSPF WGを納得させるためにパット・マーフィーを確認したいです。
Thanks to Mitchell Erblich's for his last call review and comments.
彼の最後の呼び出しレビューとコメントのためのミッチェルErblichのおかげ。
Thanks to Padma Pillay-Esnault for her last call review and comments. Also, thanks to Padma for comments on the OSPFv3 applicability section that was last called separately.
彼女の最後の呼び出しレビューとコメントのパドマPillay-Esnaultに感謝します。また、最後に個別に呼ばれたのOSPFv3の適用セクションのコメントのためのパドマに感謝。
Thanks to Nischal Seth for pointing out that the document inadvertently precluded point-to-point over LAN interfaces.
文書が誤ってLANインターフェイス上のポイントツーポイントを排除することを指摘するためNischalセスのおかげ。
Thanks to Ben Campbell for performing the General Area review.
- エリアの見直しを実施するためのベン・キャンベルに感謝します。
Thanks to Jari Arkko for comments during the IESG review.
IESGレビュー中のコメントのためのヤリArkkoに感謝します。
The RFC text was produced using Marshall Rose's xml2rfc tool.
RFCテキストは、マーシャルローズのxml2rfcツールを使用して製造しました。
Authors' Addresses
著者のアドレス
Sina Mirtorabi Nuova Systems 3 West Plumeria Drive San Jose, CA 95134 USA
シーナMirtorabi新しいシステム3西プルメリアドライブサンノゼ、CA 95134 USA
EMail: sina@nuovasystems.com
メールアドレス：sina@nuovasystems.com
Peter Psenak Cisco Systems Apollo Business Center Mlynske nivy 43 821 09 Bratislava Slovakia
ピーターPsenakシスコシステムズアポロビジネスセンターMlynskéニヴィ43 821 09ブラチスラバスロバキア
EMail: ppsenak@cisco.com
メールアドレス：ppsenak@cisco.com
Acee Lindem (editor) Redback Networks 102 Carric Bend Court Cary, NC 27519 USA
ACEE Lindem（編集者）レッドバック・ネットワーク102 Carricベンド裁判所カリー、NC 27519 USA
EMail: acee@redback.com
メールアドレス：acee@redback.com
Anand Oswal Redback Networks 300 Holger Way San Jose, CA 95134 USA
アナンドOswalレッドバック・ネットワーク300ホルガー・ウェイサンノゼ、CA 95134 USA
EMail: aoswal@redback.com
メールアドレス：aoswal@redback.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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に情報を記述してください。