[要約] RFC 5185は、OSPFのマルチエリア隣接性に関する仕様であり、異なるエリア間での隣接関係を確立するための手法を提供しています。このRFCの目的は、OSPFネットワークのスケーラビリティとパフォーマンスを向上させることです。
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
OSPFマルチエリア隣接
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.
このドキュメントでは、Open Shortest Path First（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にトラフィックをルーティングします。R1は、R3を使用してエリア内エリア1パスを使用して、R2に接続されたエリア1ネットワークに到達します。OSPF仮想リンクを使用して、R1とR2の間のリンクをエリア1に移動せずにこの問題を解決することはできません。これは、実際にネットワークのバックボーントポロジの一部である場合、これは望ましくありません。
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.
本明細書に記載されているプロトコル拡張は、R1とR2のリンクをバックボーンエリアとエリア1の両方の一部にすることにより、この問題を修正します。
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.
もう1つのアプローチは、複数の領域で1つの数のリンクを構成できるようにすることです。セクション8.2。OSPF仕様[OSPF]は、OSPFエリアIDを使用して、受信したOSPFパケットを脱マルグに使用する必要があることを既に指定しています。このアプローチの1つの制限は、マルチアクセスネットワークがサポートされていないことです。この制限は、「リンク状態ルーティングプロトコルでのLAN上のポイントツーポイント操作」[P2Plan]をサポートする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].
ABRSは、単に異なるエリアに属する複数の隣接を確立します。各マルチエリアの隣接は、構成された領域のポイントツーポイントリンクとして発表されます。ただし、番号付きのポイントツーポイントリンクとは異なり、マルチエリアの隣接にはタイプ3のリンクは宣伝されていません。このポイントツーポイントリンクは、その領域のトポロジカルパスを提供します。リンクを使用した最初または一次隣接は、RFC 2328 [OSPF]と一致する方法でリンクを操作し、宣伝します。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
マルチエリアの隣接は、共通のインターフェイスを持つ2つのルーター間で構成されています。ポイントツーポイントインターフェイスでは、隣人が1人しか存在しないため、隣人のアドレスを構成する必要はありません。他のすべてのネットワークタイプについては、各マルチエリア隣接の隣接アドレスを構成するか、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制御パケットがAllSPFRouterのアドレスに送信されます。他のすべてのネットワークタイプについては、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で説明されています。2番目の段落から始まり、その段落の下の3番目の弾丸を通して続くテキストは、次のように変更されます。
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を一致させます。この場合、パケットは1回のホップで送信されました。したがって、パケットの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.
o マルチエリアの隣接の場合、エリアIDがマルチエリア隣接の構成エリアと一致する場合、パケットは受け入れられ、これからそのエリアのマルチエリア隣接に関連付けられています。
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]).
o IP宛先がAlldRoutersであるパケットは、受信インターフェイスの状態がDRまたはバックアップである場合にのみ受け入れる必要があります（[OSPF]のセクション9.1を参照）。
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]のセクション9で指定されているように、OSPFインターフェイスデータ構造は、構成されたマルチアレア隣接性ごとに構築されています。インターフェイスタイプは常にポイントツーポイントになります。
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:
Link ID = Remote's Router ID
リンクID = remoteのルーターID
Link Data = Neighbor's IP Address or IfIndex (if the underlying interface is unnumbered).
link data = neighborの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の近隣を明確に識別しているため（[OSPFV3]のセクション3.4.3.1を参照）、セクション2.7で説明されているルーター-LSAリンクへの変更はOSPFV3に適用されます。さらに、マルチエリア隣接に対応する接頭辞は、ルーターのエリア内 - エリア-PREFIX-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]).
Link-LSAは、マルチエリアの隣接するために宣伝されるべきではありません。NeighborのIPv6リンクローカルアドレスは、他の方法で学習できます。たとえば、マルチエリアの隣接を介して受信したハローパケットのIPv6ヘッダーから抽出できます。近隣のIPv6リンクローカルアドレスは、Multi-Accessネットワークの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] Moy、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.、Ferguson、D。、およびJ. Moy、「OSPF for IPv6」、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-Keywords] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Shen、N。およびA. Zinin、「リンク状態のルーティングプロトコルのLAN上のポイントツーポイント操作」、進行中の作業。
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.
彼の最後のコールレビューとコメントをしてくれたMitchell Erblich'sに感謝します。
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.
彼女の最後のコールレビューとコメントをしてくれたPadma Pillay-Esnaultに感謝します。また、最後に別々に呼ばれたOSPFV3アプリケーションセクションに関するコメントについては、Padmaに感謝します。
Thanks to Nischal Seth for pointing out that the document inadvertently precluded point-to-point over LAN interfaces.
Nischal Sethに、文書がLANインターフェイス上でポイントツーポイントを誤って排除したことを指摘してくれたことに感謝します。
Thanks to Ben Campbell for performing the General Area review.
一般的なエリアのレビューを行ってくれたBen Campbellに感謝します。
Thanks to Jari Arkko for comments during the IESG review.
IESGレビュー中のコメントについてJari Arkkoに感謝します。
The RFC text was produced using Marshall Rose's xml2rfc tool.
RFCテキストは、Marshall RoseのXML2RFCツールを使用して作成されました。
Authors' Addresses
著者のアドレス
Sina Mirtorabi Nuova Systems 3 West Plumeria Drive San Jose, CA 95134 USA
Sina Mirtorabi Nuova Systems 3 West Plumeria Drive San Jose、CA 95134 USA
EMail: sina@nuovasystems.com
Peter Psenak Cisco Systems Apollo Business Center Mlynske nivy 43 821 09 Bratislava Slovakia
Peter Psenak Cisco Systems Apollo Business Center Mlynske Nivy 43 821 09 Bratislava Slovakia
EMail: ppsenak@cisco.com
Acee Lindem (editor) Redback Networks 102 Carric Bend Court Cary, NC 27519 USA
Acee Lindem（編集者）Redback Networks 102 Carric Bend Court Cary、NC 27519 USA
EMail: acee@redback.com
Anand Oswal Redback Networks 300 Holger Way San Jose, CA 95134 USA
Anand Oswal Redback Networks 300 Holger Way San Jose、CA 95134 USA
EMail: aoswal@redback.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。