[要約] RFC 4813は、OSPFリンクローカルシグナリングの仕様を定義しており、リンク上のOSPFルータ間での情報交換を改善することを目的としています。リンクローカルシグナリングは、OSPFプロトコルの拡張機能であり、リンク上の隣接ルータ間でのネットワーク状態の変更を効率的に通知するために使用されます。
Network Working Group B. Friedman
Request for Comments: 4813 L. Nguyen
Category: Experimental A. Roy
D. Yeung
Cisco Systems
A. Zinin
Alcatel
February 2007
OSPF Link-Local Signaling
OSPFリンクローカルシグナル伝達
Status of This Memo
本文書の位置付け
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティの実験プロトコルを定義します。いかなる種類のインターネット標準を指定しません。改善のための議論と提案が要求されます。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
OSPF is a link-state intra-domain routing protocol used in IP networks. OSPF routers exchange information on a link using packets that follow a well-defined format. The format of OSPF packets is not flexible enough to enable applications to exchange arbitrary data, which may be necessary in certain situations. This memo describes a vendor-specific, backward-compatible technique to perform link-local signaling, i.e., exchange arbitrary data on a link.
OSPFは、IPネットワークで使用されるリンク状態内領域内ルーティングプロトコルです。OSPFルーターは、明確に定義された形式に従うパケットを使用して、リンクで情報を交換します。OSPFパケットの形式は、特定の状況で必要な任意のデータを交換するアプリケーションを有効にするほど柔軟ではありません。このメモは、リンクローカルシグナル伝達を実行するためのベンダー固有の後方互換性のある手法、つまりリンク上の任意のデータを交換することについて説明しています。
Table of Contents
目次
1. Introduction ....................................................2
2. Proposed Solution ...............................................2
2.1. Options Field ..............................................3
2.2. LLS Data Block .............................................4
2.3. LLS TLVs ...................................................5
2.4. Predefined TLV .............................................5
2.4.1. Extended Options TLV ................................5
2.4.2. Cryptographic Authentication TLV ....................6
3. Backward Compatibility ..........................................7
4. Security Considerations .........................................7
5. IANA Considerations .............................................7
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
Appendix A. Acknowledgements ......................................9
Formats of OSPF [RFC2328] packets are not very flexible to provide an acceptable mechanism for opaque data transfer. However, this appears to be very useful to allow OSPF routers to do so. An example where such a technique could be used is exchanging some capabilities on a link (standard OSPF utilizes the Options field in Hello and Exchange packets, but there are not so many bits left in it).
OSPF [RFC2328]パケットの形式は、不透明なデータ転送の許容可能なメカニズムを提供するためにあまり柔軟ではありません。ただし、これはOSPFルーターがそうすることができるように非常に便利であるように見えます。このような手法を使用できる例は、リンク上のいくつかの機能を交換することです（標準のOSPFは、HelloとExchangeパケットのオプションフィールドを使用しますが、それほど多くのビットは残っていません）。
One potential way of solving this task could be introducing a new packet type. However, that would mean introducing extra packets on the network, which may not be desirable, so this document describes how to exchange data using existing, standard OSPF packet types.
このタスクを解決する潜在的な方法の1つは、新しいパケットタイプを導入することです。ただし、それはネットワークに追加のパケットを導入することを意味しますが、これは望ましくない可能性があります。そのため、このドキュメントでは、既存の標準OSPFパケットタイプを使用してデータを交換する方法について説明します。
To perform link-local signaling (LLS), OSPF routers add a special data block at the end of OSPF packets or right after the authentication data block when cryptographic authentication is used. Like with OSPF cryptographic authentication, the length of the LLS-block is not included into the length of OSPF packet, but is included in the IP packet length. Figure 1 illustrates how the LLS data block is attached.
Link-Local Signaling（LLS）を実行するために、OSPFルーターは、OSPFパケットの最後に、または暗号化認証が使用されるときに認証データブロックの直後に特別なデータブロックを追加します。OSPF暗号化認証と同様に、LLSブロックの長さはOSPFパケットの長さに含まれていませんが、IPパケットの長さに含まれています。図1は、LLSデータブロックの添付方法を示しています。
+---------------------+ --
| IP Header | ^
| Length = HL+X+Y+Z | | Header Length
| | v
+---------------------+ --
| OSPF Header | ^
| Length = X | |
|.....................| | X
| | |
| OSPF Data | |
| | v
+---------------------+ --
| | ^
| Authentication Data | | Y
| | v
+---------------------+ --
| | ^
| LLS Data | | Z
| | v
+---------------------+ --
Figure 1: Attaching LLS Data Block
図1：LLSデータブロックの添付
The LLS data block may be attached to OSPF packets of two types -- type 1 (OSPF Hello), and type 2 (OSPF DBD). The data included in the LLS block attached to a Hello packet may be used for dynamic signaling, since Hello packets may be sent at any moment in time. However, delivery of LLS data in Hello packets is not guaranteed. The data sent with Database Description (DBD) packets is guaranteed to be delivered as part of the adjacency forming process.
LLSデータブロックは、タイプ1（OSPF Hello）とタイプ2（OSPF DBD）の2つのタイプのOSPFパケットに添付される場合があります。ハローパケットに添付されたLLSブロックに含まれるデータは、ハローパケットがいつでも送信される可能性があるため、動的シグナル伝達に使用できます。ただし、ハローパケットでのLLSデータの配信は保証されていません。データベース説明（DBD）パケットで送信されたデータは、隣接する形成プロセスの一部として配信されることが保証されています。
This memo does not specify how the data transmitted by the LLS mechanism should be interpreted by OSPF routers. The interface between the OSPF LLS component and its clients is implementation-specific.
このメモは、LLSメカニズムによって送信されるデータをOSPFルーターによって解釈する方法を指定していません。OSPF LLSコンポーネントとそのクライアントの間のインターフェイスは、実装固有です。
A new bit, called L (L stands for LLS), is introduced to the OSPF Options field (see Figure 2). The value of the bit is 0x10. Routers set the L-bit in Hello and DBD packets to indicate that the packet contains the LLS data block.
L（LのLLSの略）と呼ばれる新しいビットがOSPFオプションフィールドに導入されます（図2を参照）。ビットの値は0x10です。ルーターは、LIBITをHelloとDBDパケットに設定して、パケットにLLSデータブロックが含まれていることを示します。
+---+---+---+---+---+---+---+---+
| * | O | DC| L |N/P| MC| E | * |
+---+---+---+---+---+---+---+-+-+
Figure 2: The Options Field
図2：オプションフィールド
L-bit
l-bit
This bit is set only in Hello and DBD packets. It is not set in OSPF Link State Advertisements (LSAs) and may be used in them for different purposes.
このビットは、HelloおよびDBDパケットでのみ設定されています。OSPF Link State Advertisements（LSA）には設定されておらず、さまざまな目的で使用できます。
The data block used for link-local signaling is formatted as described below (see Figure 3 for illustration).
Link-Localシグナル伝達に使用されるデータブロックは、以下に説明するようにフォーマットされています（図については図3を参照）。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | LLS Data Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| LLS TLVs |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Format of the LLS Data Block
図3：LLSデータブロックの形式
Checksum
チェックサム
The Checksum field contains the standard IP checksum of the entire contents of the LLS block.
チェックサムフィールドには、LLSブロックの内容全体の標準的なIPチェックサムが含まれています。
LLS Length
LLS長
The 16-bit LLS Data Length field contains the length (in 32-bit words) of the LLS block including the header and payload. Implementations should not use the Length field in the IP packet header to determine the length of the LLS data block.
16ビットLLSデータ長さフィールドには、ヘッダーとペイロードを含むLLSブロックの長さ（32ビット語）が含まれています。実装は、IPパケットヘッダーの長さフィールドを使用して、LLSデータブロックの長さを決定しないでください。
Note that if the OSPF packet is cryptographically authenticated, the LLS data block must also be cryptographically authenticated. In this case, the regular LLS checksum is not calculated and the LLS block will contain a cryptographic authentication TLV (see Section 2.4.2).
OSPFパケットが暗号化された認証されている場合、LLSデータブロックも暗号化された認証されている必要があることに注意してください。この場合、通常のLLSチェックサムは計算されず、LLSブロックには暗号化認証TLVが含まれます（セクション2.4.2を参照）。
The rest of the block contains a set of Type/Length/Value (TLV) triplets as described in Section 2.3. All TLVs must be 32-bit aligned (with padding if necessary).
ブロックの残りの部分には、セクション2.3で説明されているように、タイプ/長さ/値（TLV）トリプレットのセットが含まれています。すべてのTLVは、32ビットアラインドしている必要があります（必要に応じてパディングを使用）。
The contents of the LLS data block is constructed using TLVs. See Figure 4 for the TLV format.
LLSデータブロックの内容は、TLVを使用して構築されます。TLV形式については、図4を参照してください。
The Type field contains the TLV ID that is unique for each type of TLVs. The Length field contains the length of the Value field (in bytes) that is variable and contains arbitrary data.
タイプフィールドには、各タイプのTLVに一意のTLV IDが含まれています。長さフィールドには、変数で任意のデータが含まれる値フィールド（バイト単位）の長さが含まれます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Value .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Format of LLS TLVs
図4：LLS TLVの形式
Note that TLVs are always padded to 32-bit boundary, but padding bytes are not included in the TLV Length field (though it is included in the LLS Data Length field of the LLS block header).
TLVは常に32ビット境界にパッドで埋められていますが、パディングバイトはTLV長いフィールドに含まれていません（ただし、LLSブロックヘッダーのLLSデータ長フィールドに含まれています）。
This subsection describes a TLV called Extended Options (EO) TLV. The format of EO-TLV is shown in Figure 5.
このサブセクションでは、拡張オプション（EO）TLVと呼ばれるTLVについて説明しています。EO-TLVの形式を図5に示します。
Bits in the Value field do not have any semantics from the point of view of the LLS mechanism. This field may be used to announce some OSPF capabilities that are link-specific. Also, other OSPF extensions may allocate bits in the bit vector to perform boolean link-local signaling.
値フィールドのビットには、LLSメカニズムの観点からセマンティクスがありません。このフィールドは、リンク固有のOSPF機能を発表するために使用できます。また、他のOSPF拡張機能は、ビットベクトルのビットを割り当てて、ブールリンクローカルシグナル伝達を実行する場合があります。
The length of the Value field in EO-TLV is 4 bytes.
EO-TLVの値フィールドの長さは4バイトです。
The value of the Type field in EO-TLV is 1.
EO-TLVのタイプフィールドの値は1です。
EO-TLV should only appear once in the LLS data block.
EO-TLVは、LLSデータブロックに1回しか表示されません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of EO-TLV
図5：EO-TLVの形式
Currently, [RFC4811] and [RFC4812] use bits in the Extended Options field of the EO-TLV. The Extended Options bits are also defined in Section 5.
現在、[RFC4811]および[RFC4812]は、EO-TLVの拡張オプションフィールドにビットを使用しています。拡張オプションビットは、セクション5でも定義されています。
This document defines a special TLV that is used for cryptographic authentication (CA-TLV) of the LLS data block. This TLV should be included in the LLS block when the cryptographic (MD5) authentication is enabled on the corresponding interface. The message digest of the LLS block should be calculated using the same key as that used for the main OSPF packet. The cryptographic sequence number is included in the TLV and must be the same as the one in the main OSPF packet for the LLS block to be considered authentic.
このドキュメントでは、LLSデータブロックの暗号化認証（CA-TLV）に使用される特別なTLVを定義します。このTLVは、対応するインターフェイスで暗号化（MD5）認証が有効になっている場合、LLSブロックに含める必要があります。LLSブロックのメッセージダイジェストは、メインのOSPFパケットに使用されているキーと同じキーを使用して計算する必要があります。暗号化シーケンス番号はTLVに含まれており、LLSブロックが本物と見なされるためのメインOSPFパケットのパケットと同じでなければなりません。
The TLV is constructed as shown Figure 6.
TLVは、図6に示すように構築されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 2 | AuthLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. AuthData .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Format of Cryptographic Authentication TLV
図6：暗号化認証TLVの形式
The value of the Type field for CA-TLV is 2.
CA-TLVのタイプフィールドの値は2です。
The Length field in the header contains the length of the data portion of the TLV that includes 4 bytes for the sequence number and the length of the message digest (MD5) block for the whole LLS block in bytes (this will always be 16 bytes for MD5). So the AuthLen field will have value of 20.
ヘッダーの長さフィールドには、TLVのデータ部分の長さが含まれます。これには、シーケンス番号の4バイトとメッセージダイジェストの長さ（MD5）ブロックの長さが含まれています。MD5）。したがって、Authlenフィールドの値は20です。
The Sequence Number field contains the cryptographic sequence number that is used to prevent simple replay attacks. For the LLS block to be considered authentic, the sequence number in the CA-TLV must match the sequence number in the OSPF packet.
シーケンス番号フィールドには、単純なリプレイ攻撃を防ぐために使用される暗号化シーケンス番号が含まれています。LLSブロックを本物と見なすには、CA-TLVのシーケンス番号はOSPFパケットのシーケンス番号と一致する必要があります。
The AuthData field contains the message digest calculated for the LLS data block.
AuthDataフィールドには、LLSデータブロックに対して計算されたメッセージダイジェストが含まれています。
The CA-TLV may appear in the LLS block only once. Also, when present, this TLV should be the last in the LLS block.
CA-TLVは、LLSブロックに1回だけ表示される場合があります。また、存在する場合、このTLVはLLSブロックの最後になるはずです。
The modifications to OSPF packet formats are compatible with standard OSPF because LLS-incapable routers will not consider the extra data after the packet; i.e., the LLS data block will be ignored by routers that do not support the LLS extension.
LLSに入れられないルーターがパケット後の追加データを考慮しないため、OSPFパケット形式の変更は標準のOSPFと互換性があります。つまり、LLSデータブロックは、LLS拡張機能をサポートしていないルーターによって無視されます。
The function described in this document does not create any new security issues for the OSPF protocol. The described technique provides the same level of security as the OSPF protocol by allowing LLS data to be authenticated (see Section 2.4.2 for more details).
このドキュメントで説明されている機能は、OSPFプロトコルの新しいセキュリティ問題を作成しません。記載されている手法は、LLSデータを認証できるようにすることにより、OSPFプロトコルと同じレベルのセキュリティを提供します（詳細については、セクション2.4.2を参照）。
LLS TLV types are maintained by the IANA. Extensions to OSPF that require a new LLS TLV type must be reviewed by a designated expert from the routing area.
LLS TLVタイプはIANAによって維持されます。新しいLLS TLVタイプを必要とするOSPFへの拡張は、ルーティングエリアの指定された専門家によってレビューする必要があります。
Following the policies outlined in [RFC2434], LLS type values in the range of 0-32767 are allocated through an IETF consensus action, and LLS type values in the range of 32768-65536 are reserved for private and experimental use.
[RFC2434]で概説されているポリシーに続いて、0-32767の範囲のLLSタイプの値はIETFコンセンサスアクションによって割り当てられ、32768-65536の範囲のLLSタイプ値は私的および実験的使用のために予約されています。
This document assigns LLS types 1 and 2, as follows:
このドキュメントは、次のようにLLSタイプ1と2を割り当てます。
LLS Type Name Reference 0 Reserved 1 Extended Options [RFC4813] 2 Cryptographic Authentication [RFC4813] 3-32767 Reserved for assignment by the IANA 32768-65535 Private Use
LLSタイプ名リファレンス0予約済み1拡張オプション[RFC4813] 2暗号化認証[RFC4813] 3-32767 IANA 32768-655535プライベート使用
This document also assigns the following bits for the Extended Options bits field in the EO-TLV outlined in Section 2.4.1:
このドキュメントは、セクション2.4.1で概説されているEO-TLVの拡張オプションビットフィールドに次のビットを割り当てます。
Extended Options Bit Name Reference
0x00000001 LSDB Resynchronization (LR) [RFC4811]
0x00000002 Restart Signal (RS-bit) [RFC4812]
Other Extended Options bits will be allocated through an IETF consensus action.
その他の拡張オプションビットは、IETFコンセンサスアクションを通じて割り当てられます。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328] Moy、J。、「OSPFバージョン2」、STD 54、RFC 2328、1998年4月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC4811] Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band Link State Database (LSDB) Resynchronization", RFC 4811, February 2007.
[RFC4811] Nguyen、L.、Roy、A。、およびA. Zinin、「OSPF Out-Band Link State Database（LSDB）再同期」、RFC 4811、2007年2月。
[RFC4812] Nguyen, L., Roy, A., and A. Zinin, "OSPF Restart Signaling", RFC 4812, February 2007.
[RFC4812] Nguyen、L.、Roy、A。、およびA. Zinin、「OSPF Restart Signaling」、RFC 4812、2007年2月。
The authors would like to acknowledge Russ White for his review of this document.
著者は、この文書のレビューについてRuss Whiteを認めたいと考えています。
Authors' Addresses
著者のアドレス
Barry Friedman Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: friedman@cisco.com
バリーフリードマンシスコシステム225ウェストタスマンドライブサンノゼ、カリフォルニア95134 USAメール：friedman@cisco.com
Liem Nguyen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: lhnguyen@cisco.com
Liem Nguyen Cisco Systems 225 West Tasman Drive San Jose、CA 95134 USAメール：lhnguyen@cisco.com
Abhay Roy Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: akr@cisco.com
Abhay Roy Cisco Systems 225 West Tasman Drive San Jose、CA 95134 USAメール：akr@cisco.com
Derek Yeung Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: myeung@cisco.com
Derek Yeung Cisco Systems 225 West Tasman Drive San Jose、CA 95134 USAメール：myeung@cisco.com
Alex Zinin Alcatel Sunnyvale, CA USA EMail: zinin@psg.com
Alex Zinin Alcatel Sunnyvale、CA米国メールメール：zinin@psg.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
この文書は、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への情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。