[要約] RFC 4727は、IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験的な値に関する情報を提供しています。このRFCの目的は、これらのヘッダーの実験的な値の使用方法と意味を明確にすることです。
Network Working Group B. Fenner
Request for Comments: 4727 AT&T Labs - Research
Category: Standards Track November 2006
Experimental Values in IPv4, IPv6, ICMPv4, ICMPv6, UDP, and TCP Headers
IPv4、IPv6、ICMPv4、ICMPv6、UDP、およびTCPヘッダーの実験値
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
Abstract
概要
When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified, and it describes the numbers that have already been reserved by other documents.
プロトコルを実験または拡張する場合、閉じた環境でテストする場合でも、新しい機能を実際にテストまたは実験するために、何らかのプロトコル数または定数を使用する必要があることがよくあります。このドキュメントは、実験をサポートする必要性が特定されている特定のプロトコルの実験目的で、いくつかの範囲の数値を留保し、他のドキュメントによってすでに予約されている数字を説明します。
[RFC3692] recommends assigning option numbers for experiments and testing. This document documents several such assignments for the number spaces whose IANA considerations are documented in [RFC2780]. This document generally follows the form of [RFC2780].
When using these values, carefully consider the advice in Sections 1 and 1.1 of [RFC3692]. It is not appropriate to simply select one of these values and hard code it into a system.
これらの値を使用する場合は、[RFC3692]のセクション1および1.1でアドバイスを慎重に検討します。これらの値のいずれかを単に選択し、それをシステムにハードコードするだけでは適切ではありません。
Note: while [RFC3692] says that it may not be necessary to allocate values for UDP and TCP ports, Sections 6 and 7.1 explicitly reserve ports for this purpose to avoid any possible conflict.
注：[RFC3692]は、UDPおよびTCPポートの値を割り当てる必要はないかもしれないと述べていますが、セクション6および7.1は、この目的のためにポートを明示的に予約して、競合を回避することを回避します。
The IPv4 header [RFC0791] contains the following fields that carry values assigned by the IANA: Version, Type of Service, Protocol, Source Address, Destination Address, and Option Type.
IPv4ヘッダー[RFC0791]には、IANAによって割り当てられた値を伝える次のフィールドが含まれています：バージョン、サービスの種類、プロトコル、ソースアドレス、宛先アドレス、およびオプションタイプが含まれます。
The Version field in IPv4 packets is always 4.
[RFC2474] defines Pool 2 (all code points xxxx11, where 'x' refers to either '0' or '1') as Experimental/Local Use, so no additional code points should be needed. The Explicit Congestion Notification (ECN) field [RFC3168] has no free code points to assign.
[RFC3692] allocates two experimental code points (253 and 254) for the IPv4 Protocol field.
[RFC3692]は、IPv4プロトコルフィールドに2つの実験コードポイント（253および254）を割り当てます。
No experimental IPv4 addresses are defined. For certain experiments, the address ranges set aside for Private Internets in [RFC1918] may be useful. It is not appropriate to use other special-purpose IPv4 addresses [RFC3330] for experimentation.
At the time of this writing, some Internet Registries have policies allowing experimental assignments from number spaces that they control. Depending on the experiment, the registry, and their policy, this may be an appropriate path to pursue.
この執筆時点では、一部のインターネットレジストリには、制御する数字スペースからの実験的割り当てを許可するポリシーがあります。実験、レジストリ、およびそれらのポリシーに応じて、これは追求する適切な道である可能性があります。
The globally routable group 224.0.1.20 is set aside for experimentation. For certain experiments, the administratively scoped multicast groups defined in [RFC2365] may be useful. This document assigns a single link-local scoped group, 224.0.0.254, and a single scope-relative group, 254.
グローバルにルーティング可能なグループ224.0.1.20は、実験のために確保されています。特定の実験では、[RFC2365]で定義されている管理上スコープマルチキャストグループが役立つ場合があります。このドキュメントには、単一のリンクローカルスコープグループ、224.0.0.254、および単一のスコープ関連グループ254を割り当てます。
This document assigns a single option number, with all defined values of the "copy" and "class" fields, resulting in four distinct option type codes. See Section 8 for the assigned values.
このドキュメントには、「コピー」および「クラス」フィールドのすべての定義値がある単一のオプション番号が割り当てられ、4つの異なるオプションタイプコードが表示されます。割り当てられた値については、セクション8を参照してください。
The IPv6 header [RFC2460] contains the following fields that carry values assigned from IANA-managed name spaces: Version, Traffic Class, Next Header, Source and Destination Address. In addition, the IPv6 Hop-by-Hop Options and Destination Options extension headers include an Option Type field with values assigned from an IANA-managed name space. The IPv6 Routing Header contains a Type field for which there is not currently an explicit IANA assignment policy.
IPv6ヘッダー[RFC2460]には、IANAが管理した名前スペース（バージョン、トラフィッククラス、次のヘッダー、ソース、および宛先アドレス）から割り当てられた値を運ぶ以下のフィールドが含まれています。さらに、IPv6ホップバイホップオプションと宛先オプションエクステンションヘッダーには、IANAが管理した名前スペースから割り当てられた値を持つオプションタイプフィールドが含まれています。IPv6ルーティングヘッダーには、現在明示的なIANA割り当てポリシーがないタイプフィールドが含まれています。
The Version field in IPv6 packets is always 6.
IPv6パケットのバージョンフィールドは常に6です。
[RFC2474] defines Pool 2 (all code points xxxx11, where 'x' refers to either '0' or '1') as Experimental/Local Use, so no additional code points should be needed. The ECN field [RFC3168] has no free code points to assign.
[RFC2474]は、プール2（すべてのコードポイントxxxx11を定義します。ここで、「x」は実験的/ローカル使用として使用されるため、追加のコードポイントは必要ありません。ECNフィールド[RFC3168]には、割り当てる無料のコードポイントはありません。
[RFC3692] allocates two experimental code points (253 and 254) for the IPv6 Next Header field.
[RFC3692]は、IPv6次のヘッダーフィールドに2つの実験コードポイント（253および254）を割り当てます。
[RFC2928] defines a set of IPv6 addresses for testing and experimental usage:
[RFC2928]は、テストと実験的使用に関するIPv6アドレスのセットを定義します。
The block of Sub-TLA IDs assigned to the IANA (i.e., 2001:0000::/29 - 2001:01F8::/29) is for assignment for testing and experimental usage to support activities such as the 6bone, and for new approaches like exchanges.
IANAに割り当てられたサブTLA IDのブロック（つまり、2001：0000 ::/29-2001：01F8 ::/29）は、6BONEなどのアクティビティをサポートするためのテストと実験的使用の割り当ておよび新しいアプローチのためのものです。交換のように。
However, at this writing, there are no RFC3692-style experimental IPv6 addresses assigned. [HUSTON05] creates an IANA registry that may in the future contain such assignments. For certain experiments, Unique Local Addresses [RFC4193] may be useful. It is not appropriate to use addresses in the documentation prefix [RFC3849] for experimentation.
ただし、この執筆では、RFC3692スタイルの実験的IPv6アドレスが割り当てられていません。[Huston05]は、将来そのような割り当てが含まれる可能性があるIANAレジストリを作成します。特定の実験では、ユニークなローカルアドレス[RFC4193]が役立つ場合があります。実験には、ドキュメントプレフィックス[RFC3849]のアドレスを使用することは適切ではありません。
At the time of this writing, some Internet Registries have policies allowing experimental assignments from number spaces that they control. Depending on the experiment, the registry, and their policy, this may be an appropriate path to pursue.
The group FF0X::114 is set aside for experimentation at all scope levels. Smaller scopes may be particularly useful for experimentation, since they are defined not to leak out of a given defined boundary, which can be set to be the boundary of the experiment. For certain experiments, other multicast addresses with the T (non-permanently-assigned or "transient" address) bit [RFC4291] set may be useful.
This document assigns a single option type, with all possible values of the "act" and "chg" fields, resulting in eight distinct option type codes. See Section 8 for the assigned values.
このドキュメントには、「ACT」および「CHG」フィールドのすべての可能な値がある単一のオプションタイプを割り当て、8つの異なるオプションタイプコードが得られます。割り当てられた値については、セクション8を参照してください。
This document assigns two values for the Routing Type field in the IPv6 Routing Header, 253 and 254.
このドキュメントは、IPv6ルーティングヘッダー253および254のルーティングタイプフィールドに2つの値を割り当てます。
This document assigns two ICMPv4 type numbers, 253 and 254. ICMPv4 code values are allocated per type, so it's not feasible to assign experimental values in this document.
[RFC4443] includes experimental ICMPv6 type values for Informational (200, 201) and Error (100, 101) message types. ICMPv6 code values are allocated per type, so it's not feasible to assign experimental values in this document.
[RFC4443]は、情報（200、201）およびエラー（100、101）メッセージタイプの実験的ICMPV6タイプの値を含みます。ICMPV6コード値はタイプごとに割り当てられているため、このドキュメントに実験値を割り当てることは不可能です。
The IPv6 Neighbor Discovery header [RFC2461] contains the following fields that carry values assigned from IANA-managed name spaces: Type, Code, and Option Type.
IPv6 Neighbor Discoveryヘッダー[RFC2461]には、IANAが管理した名前スペース（タイプ、コード、およびオプションタイプ）から割り当てられた値を運ぶ以下のフィールドが含まれています。
The Neighbor Discovery Type field is the same as the ICMPv6 Type field. See Section 5 for those code points.
Neighbor Discovery Typeフィールドは、ICMPV6型フィールドと同じです。これらのコードポイントについては、セクション5を参照してください。
The ICMPv6 Code field is not used in IPv6 Neighbor Discovery, so no experimental code points are necessary.
ICMPV6コードフィールドはIPv6 Neighbor Discoveryでは使用されていないため、実験的なコードポイントは必要ありません。
This document assigns two IPv6 Neighbor Discovery Option Types, 253 and 254.
このドキュメントには、2つのIPv6隣接ディスカバリーオプションタイプ、253および254を割り当てます。
Two system ports, 1021 and 1022, have been reserved for experimentation for UDP and TCP.
1021と1022の2つのシステムポートは、UDPとTCPの実験のために予約されています。
Two system ports, 1021 and 1022, have been reserved for experimentation for UDP and TCP.
1021と1022の2つのシステムポートは、UDPとTCPの実験のために予約されています。
There are not enough reserved bits to allocate any for experimentation.
実験に割り当てるのに十分な予約済みビットはありません。
Two TCP options, 253 and 254, have been reserved for experimentation with TCP Options.
253と254の2つのTCPオプションは、TCPオプションの実験のために予約されています。
The new assignments are summarized below.
新しい課題を以下に要約します。
IPv4 Multicast Addresses (multicast-addresses (224.0.0/24) Local Network Control Block section) (Section 2.4.2)
IPv4マルチキャストアドレス（マルチキャストアドレス（224.0.0/24）ローカルネットワーク制御ブロックセクション）（セクション2.4.2）
Group Address Name
------------- ----------------------------
224.0.0.254 RFC3692-style Experiment (*)
IPv4 Multicast Addresses (multicast-addresses relative addresses section) (Section 2.4.2)
IPv4マルチキャストアドレス（マルチキャストアドレス相対アドレスセクション）（セクション2.4.2）
Relative Description
-------- ----------------------------
254 RFC3692-style Experiment (*)
IPv4 Option Numbers (ip-parameters initial section) (Section 2.5)
IPv4オプション番号（IPパラメーター初期セクション）（セクション2.5）
Copy Class Number Value
---- ----- ------ -----
0 0 30 30
0 2 30 94
1 0 30 158
1 2 30 222
IPv6 Option Types (ipv6-parameters Section 5.b.) (Section 3.5)
IPv6オプションタイプ（IPv6-パラメーターセクション5.B.）（セクション3.5）
HEX act chg rest
---- --- --- -----
0x1e 00 0 11110
0x3e 00 1 11110
0x5e 01 0 11110
0x7e 01 1 11110
0x9e 10 0 11110
0xbe 10 1 11110
0xde 11 0 11110
0xfe 11 1 11110
IPv6 Neighbor Discovery Option Formats (icmpv6-parameters) (Section 5.1.3)
IPv6ネイバーディスカバリーオプションフォーマット（ICMPV6-パラメーター）（セクション5.1.3）
Type Description
---- ------------------------------
253 RFC3692-style Experiment 1 (*)
254 RFC3692-style Experiment 2 (*)
IPv6 Routing Header Routing Types (ipv6-parameters Section 5.c.) (Section 3.6)
IPv6ルーティングヘッダールーティングタイプ（IPv6-パラメーターセクション5.C.）（セクション3.6）
Type Description
---- ------------------------------
253 RFC3692-style Experiment 1 (*)
254 RFC3692-style Experiment 2 (*)
ICMPv4 Type Numbers (icmp-parameters) (Section 4)
ICMPV4タイプ番号（ICMP-Parameters）（セクション4）
Type Name
---- ------------------------------
253 RFC3692-style Experiment 1 (*)
254 RFC3692-style Experiment 2 (*)
System Port Numbers (port-numbers) (Sections 6 and 7.1)
システムポート番号（ポート番号）（セクション6および7.1）
Keyword Decimal Description
------- -------- ------------------------------
exp1 1021/udp RFC3692-style Experiment 1 (*)
exp1 1021/tcp RFC3692-style Experiment 1 (*)
exp2 1022/udp RFC3692-style Experiment 2 (*)
exp2 1022/tcp RFC3692-style Experiment 2 (*)
TCP Option Numbers (tcp-parameters) (Section 7.3)
Kind Length Meaning
---- ------ ------------------------------
253 N RFC3692-style Experiment 1 (*)
254 N RFC3692-style Experiment 2 (*)
Each of these registrations is accompanied by the following footnote:
これらの各登録には、次の脚注が伴います。
(*) It is only appropriate to use these values in explicitly-configured experiments; they MUST NOT be shipped as defaults in implementations. See RFC 3692 for details.
（*）これらの値を明示的に構成した実験で使用することのみが適切です。実装のデフォルトとして出荷されてはなりません。詳細については、RFC 3692を参照してください。
Production networks do not necessarily support the use of experimental code points in IP headers. The network scope of support for experimental values should carefully be evaluated before deploying any experiment across extended network domains, such as the public Internet. The potential to disrupt the stable operation of the network hosting the experiment through the use of unsupported experimental code points is a serious consideration when planning an experiment using such code points.
生産ネットワークは、IPヘッダーでの実験コードポイントの使用を必ずしもサポートするわけではありません。実験値のサポートのネットワーク範囲は、パブリックインターネットなどの拡張ネットワークドメイン全体で実験を展開する前に慎重に評価する必要があります。サポートされていない実験コードポイントを使用して、実験をホストするネットワークの安定した操作を破壊する可能性は、そのようなコードポイントを使用して実験を計画する際に深刻な考慮事項です。
Security analyzers such as firewalls and network intrusion detection monitors often rely on unambiguous interpretations of the fields described in this memo. As new values for the fields are assigned, existing security analyzers that do not understand the new values may fail, resulting in either loss of connectivity, if the analyzer declines to forward the unrecognized traffic, or in loss of security if it does forward the traffic and the new values are used as part of an attack. Assigning known values for experiments can allow such analyzers to take a known action for explicitly experimental traffic.
ファイアウォールやネットワーク侵入検出モニターなどのセキュリティアナライザーは、このメモに記載されているフィールドの明確な解釈に依存していることがよくあります。フィールドの新しい値が割り当てられると、新しい値が失敗する可能性がある既存のセキュリティアナライザーが失敗する可能性があり、アナライザーが認識されていないトラフィックを転送することを拒否した場合、またはトラフィックを転送する場合、セキュリティの損失のいずれかの接続の損失をもたらします。また、新しい値は攻撃の一部として使用されます。実験に既知の値を割り当てることで、そのようなアナライザーが明示的に実験的なトラフィックのために既知のアクションをとることができます。
Because the experimental IPv4 options defined in Section 2.5 are not included in the IPsec AH [RFC4302] calculations, it is not possible for one to authenticate their use. Experimenters ought to keep this in mind when designing their experiments. Users of the experimental IPv6 options defined in Section 3.5 can choose whether or not the option is included in the AH calculations by choosing the value of the "chg" field.
セクション2.5で定義された実験的なIPv4オプションは、IPSEC AH [RFC4302]計算に含まれていないため、使用を認証することはできません。実験者は、実験を設計する際にこれを念頭に置いておく必要があります。セクション3.5で定義されている実験的IPv6オプションのユーザーは、「CHG」フィールドの値を選択することにより、AH計算にオプションが含まれているかどうかを選択できます。
When experimental code points are deployed within an administratively self-contained network domain, the network administrators should ensure that each code point is used consistently to avoid interference between experiments. When experimental code points are used in traffic that crosses multiple administrative domains, the experimenters should assume that there is a risk that the same code points will be used simultaneously by other experiments and thus that there is a possibility that the experiments will interfere. Particular attention should be given to security threats that such interference might create.
実験コードポイントが管理上自己完結型ネットワークドメイン内に展開される場合、ネットワーク管理者は、実験間の干渉を避けるために、各コードポイントが一貫して使用されることを確認する必要があります。複数の管理ドメインを通過するトラフィックで実験コードポイントが使用される場合、実験者は、同じコードポイントが他の実験によって同時に使用されるリスクがあると仮定する必要があり、したがって、実験が干渉する可能性があります。そのような干渉が生じるかもしれないセキュリティの脅威に特に注意を払うべきです。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2365] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[RFC2365] Meyer、D。、「管理上スコープIPマルチキャスト」、BCP 23、RFC 2365、1998年7月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーの差別化されたサービスフィールド（DSフィールド）の定義」、RFC 2474、1998年12月。
[RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For Values In the Internet Protocol and Related Headers", BCP 37, RFC 2780, March 2000.
[RFC2780] Bradner、S。およびV. Paxson、「インターネットプロトコルおよび関連するヘッダーの価値に関するIANA割り当てガイドライン」、BCP 37、RFC 2780、2000年3月。
[RFC2928] Hinden, R., Deering, S., Fink, R., and T. Hain, "Initial IPv6 Sub-TLA ID Assignments", RFC 2928, September 2000.
[RFC2928] Hinden、R.、Deering、S.、Fink、R。、およびT. Hain、「初期IPv6サブTLA ID割り当て」、RFC 2928、2000年9月。
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001.
[RFC3168] Ramakrishnan、K.、Floyd、S。、およびD. Black、「IPへの明示的な混雑通知（ECN）の追加」、RFC 3168、2001年9月。
[RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3330] IANA、「特別使用IPv4アドレス」、RFC 3330、2002年9月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692] Narten、T。、「有用と見なされる実験数とテスト数の割り当て」、BCP 82、RFC 3692、2004年1月。
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, July 2004.
[RFC3849] Huston、G.、Lord、A。、およびP. Smith、「IPv6アドレスはドキュメント用に予約されている」、RFC 3849、2004年7月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 4291、2006年2月。
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[RFC4302] Kent、S。、「IP認証ヘッダー」、RFC 4302、2005年12月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）、RFC 4443、2006年3月。
[HUSTON05] Huston, G., "Administration of the IANA Special Purpose Address Block", Work in Progress, December 2005.
[Huston05] Huston、G。、「IANA特別目的アドレスブロックの管理」、2005年12月、進行中の作業。
Author's Address
著者の連絡先
Bill Fenner AT&T Labs - Research 75 Willow Rd Menlo Park, CA 94025 USA
ビル・フェナーAT＆Tラボ - 研究75 Willow Rd Menlo Park、CA 94025 USA
Phone: +1 650 330-7893
EMail: fenner@research.att.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（2006）。
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.
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エディター機能の資金は現在、インターネット協会によって提供されています。