Network Working Group D. Borman
Request for Comments: 2675 Berkeley Software Design
Obsoletes: 2147 S. Deering
Category: Standards Track Cisco
R. Hinden
Nokia
August 1999
IPv6 Jumbograms
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 Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
A "jumbogram" is an IPv6 packet containing a payload longer than 65,535 octets. This document describes the IPv6 Jumbo Payload option, which provides the means of specifying such large payload lengths. It also describes the changes needed to TCP and UDP to make use of jumbograms.
「ジャンボグラムは」65535オクテットより長いペイロードを含むIPv6パケットです。この文書では、このような大きなペイロードの長さを指定する手段を提供するIPv6のジャンボペイロードオプションを記述する。また、ジャンボグラムを利用するためにTCPおよびUDPに必要な変更について説明します。
Jumbograms are relevant only to IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets, and need not be implemented or understood by IPv6 nodes that do not support attachment to links with such large MTUs.
ジャンボグラムのみ65575オクテットよりも大きいリンクMTUを持つリンクに取り付けることができるIPv6ノードに関連する、そのような大型のMTUとのリンクへの結合をサポートしないIPv6ノードによって実装または理解する必要はありません。
jumbo (jum'bO),
ジャンボ（jum'bO）、
n., pl. -bos, adj.
-n.
1. a person, animal, or thing very large of its kind.
-adj.
2. very large: the jumbo box of cereal.
[1800-10; orig. uncert.; popularized as the name of a large elephant purchased and exhibited by P.T. Barnum in 1882]
[1800から1810。 ORIG。 uncert;購入した大きな象の名前として普及してP.T.で展示1882年バーナム]
-- www.infoplease.com
ーー ｗっｗ。いんふぉｐぇあせ。こｍ
The IPv6 header [IPv6] has a 16-bit Payload Length field and, therefore, supports payloads up to 65,535 octets long. This document specifies an IPv6 hop-by-hop option, called the Jumbo Payload option, that carries a 32-bit length field in order to allow transmission of IPv6 packets with payloads between 65,536 and 4,294,967,295 octets in length. Packets with such long payloads are referred to as "jumbograms".
IPv6ヘッダ[IPv6は】16ビットのペイロード長フィールドを有しており、従って、長い65,535オクテットにペイロードをサポートします。この文書は、IPv6のホップバイホップオプションを指定し、長さが65,536と4,294,967,295オクテットの間のペイロードとIPv6パケットの伝送を可能にするために32ビット長のフィールドを運ぶ巨大ペイロードオプションと呼ばれます。このような長いペイロードを持つパケットは、「ジャンボグラム」と呼ばれています。
The Jumbo Payload option is relevant only for IPv6 nodes that may be attached to links with a link MTU greater than 65,575 octets (that is, 65,535 + 40, where 40 octets is the size of the IPv6 header). The Jumbo Payload option need not be implemented or understood by IPv6 nodes that do not support attachment to links with MTU greater than 65,575.
ジャンボペイロードオプションは、（40オクテットのIPv6ヘッダのサイズであるが、+ 40 65,535である、）65575オクテットよりも大きいリンクMTUを持つリンクに取り付けることができるIPv6ノードに関連します。巨大ペイロードオプションは、65575よりも大きいMTUを持つリンクに添付ファイルをサポートしていないIPv6ノードによって実装または理解する必要はありません。
On links with configurable MTUs, the MTU must not be configured to a value greater than 65,575 octets if there are nodes attached to that link that do not support the Jumbo Payload option and it can not be guaranteed that the Jumbo Payload option will not be sent to those nodes.
巨大ペイロードオプションをサポートしていないと、巨大ペイロードオプションが送信されないことが保証できないリンクに接続されたノードが存在する場合、設定のMTUを持つリンクで、MTUは65575オクテットよりも大きい値に設定しないでくださいこれらのノードに。
The UDP header [UDP] has a 16-bit Length field which prevents it from making use of jumbograms, and though the TCP header [TCP] does not have a Length field, both the TCP MSS option and the TCP Urgent field are constrained to 16 bits. This document specifies some simple enhancements to TCP and UDP to enable them to make use of jumbograms. An implementation of TCP or UDP on an IPv6 node that supports the Jumbo Payload option must include the enhancements specified here.
UDPヘッダーは[UDP]ジャンボグラムを利用することを防止する16ビット長のフィールドを有しており、TCPヘッダ[TCP]はTCP MSSオプションとTCP緊急フィールドの両方がに制約され、長さフィールドを持っていないけれども16ビット。この文書では、ジャンボグラムを利用するためにそれらを可能にするために、TCPとUDPにいくつかの簡単な機能強化を指定します。巨大ペイロードオプションをサポートしているIPv6ノード上のTCPやUDPの実装では、ここで指定した機能強化が含まれている必要があります。
Note: The 16 bit checksum used by UDP and TCP becomes less accurate as the length of the data being checksummed is increased. Application designers may want to take this into consideration.
注：UDPおよびTCPによって使用される16ビットチェックサムはチェックサム中のデータの長さが増加するにつれてより不正確になります。アプリケーション設計者は、これを考慮するすることもできます。
This document merges and updates material that was previously published in two separate documents:
以前に二つの別々の文書に掲載されました。この文書のマージと更新材質：
- The specification of the Jumbo Payload option previously appeared as part of the IPv6 specification in RFC 1883. RFC 1883 has been superseded by RFC 2460, which no longer includes specification of the Jumbo Payload option.
- ジャンボペイロードオプションの仕様は、以前RFC 1883におけるIPv6仕様の一部として登場RFC 1883はもはやジャンボペイロードオプションの仕様を含むRFC 2460、に置き換えられました。
- The specification of TCP and UDP enhancements to support jumbograms previously appeared as RFC 2147. RFC 2147 is obsoleted by this document.
- TCPとUDPの拡張機能の仕様は、以前RFC 2147 RFC 2147は、本文書によって廃止されたとして登場ジャンボグラムをサポートします。
The Jumbo Payload option is carried in an IPv6 Hop-by-Hop Options header, immediately following the IPv6 header. This option has an alignment requirement of 4n + 2. (See [IPv6, Section 4.2] for discussion of option alignment.) The option has the following format:
ジャンボペイロードオプションは直ちにIPv6ヘッダ以下、IPv6のホップバイホップオプションヘッダで運ばれます。このオプションは、（オプションのアラインメントの議論については[IPv6のセクション4.2]参照）4N + 2の整列要求を持つオプションは、次の形式を有します。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jumbo Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type 8-bit value C2 (hexadecimal).
オプションタイプの8ビット値C2（16進数）。
Opt Data Len 8-bit value 4.
OPTデータレン8ビット値4。
Jumbo Payload Length 32-bit unsigned integer. Length of the IPv6 packet in octets, excluding the IPv6 header but including the Hop-by-Hop Options header and any other extension headers present. Must be greater than 65,535.
ジャンボペイロード長32ビットの符号なし整数。オクテットのIPv6パケットの長さ、IPv6ヘッダを除く本ホップバイホップオプションヘッダと他の拡張ヘッダを含みます。 65,535よりも大きくなければなりません。
The Payload Length field in the IPv6 header must be set to zero in every packet that carries the Jumbo Payload option.
IPv6ヘッダ内のペイロード長フィールドはジャンボペイロードオプションを運ぶすべてのパケットにゼロに設定されなければなりません。
If a node that understands the Jumbo Payload option receives a packet whose IPv6 header carries a Payload Length of zero and a Next Header value of zero (meaning that a Hop-by-Hop Options header follows), and whose link-layer framing indicates the presence of octets beyond the IPv6 header, the node must proceed to process the Hop-by-Hop Options header in order to determine the actual length of the payload from the Jumbo Payload option.
ジャンボペイロードオプションを理解するノードは、そのIPv6のヘッダゼロのペイロード長とゼロの次ヘッダ値を運ぶパケットを受信した場合（ホップバイホップオプションヘッダが続くことを意味する）、およびそのリンク層フレーミングを示しIPv6ヘッダを越えオクテットの存在は、ノードがジャンボペイロードオプションからペイロードの実際の長さを決定するために、ホップバイホップオプションヘッダを処理するように進行しなければなりません。
The Jumbo Payload option must not be used in a packet that carries a Fragment header.
ジャンボペイロードオプションは、フラグメントヘッダを運ぶパケットに使用されてはなりません。
Higher-layer protocols that use the IPv6 Payload Length field to compute the value of the Upper-Layer Packet Length field in the checksum pseudo-header described in [IPv6, Section 8.1] must instead use the Jumbo Payload Length field for that computation, for packets that carry the Jumbo Payload option.
[IPv6のセクション8.1]で説明チェックサム疑似ヘッダに上位層パケット長フィールドの値を計算するためのIPv6ペイロード長さフィールドを使用する上位層プロトコルではなくため、その計算のためにジャンボペイロード長さフィールドを使用する必要があります巨大ペイロードオプションを運ぶパケット。
Nodes that understand the Jumbo Payload option are required to detect a number of possible format errors, and if the erroneous packet was not destined to a multicast address, report the error by sending an ICMP Parameter Problem message [ICMPv6] to the packet's source. The following list of errors specifies the values to be used in the Code and Pointer fields of the Parameter Problem message:
巨大ペイロードオプションを理解したノードは、可能なフォーマットエラーの数を検出するために必要な、と誤ったパケットはマルチキャストアドレス宛てていなかった場合、パケットの送信元にICMPパラメータ問題メッセージ[ICMPv6の]を送信することで、エラーを報告しています。エラーの次のリストは、パラメータ問題メッセージのコードとポインタの分野で使用される値を指定します。
error: IPv6 Payload Length = 0 and IPv6 Next Header = Hop-by-Hop Options and Jumbo Payload option not present
エラー：存在しないのIPv6ペイロード長= 0とIPv6次ヘッダ=ホップバイホップオプションと巨大ペイロードオプション
Code: 0
Pointer: high-order octet of the IPv6 Payload Length
error: IPv6 Payload Length != 0 and Jumbo Payload option present
エラー：！のIPv6ペイロード長= 0と巨大ペイロードオプションの存在
Code: 0
Pointer: Option Type field of the Jumbo Payload option
error: Jumbo Payload option present and Jumbo Payload Length < 65,536
エラー：巨大ペイロードオプションの存在とジャンボペイロード長<65,536
Code: 0
Pointer: high-order octet of the Jumbo Payload Length
error: Jumbo Payload option present and Fragment header present
エラー：ジャンボペイロードオプション存在し、フラグメントヘッダの存在
Code: 0
Pointer: high-order octet of the Fragment header.
A node that does not understand the Jumbo Payload option is expected to respond to erroneously-received jumbograms as follows, according to the IPv6 specification:
巨大ペイロードオプションを理解していないノードは、IPv6の仕様に応じて、以下のように誤って受信したジャンボグラムを応答することが期待されています。
error: IPv6 Payload Length = 0 and IPv6 Next Header = Hop-by-Hop Options
エラー：IPv6のペイロード長= 0とIPv6の次ヘッダ=ホップバイホップオプション
Code: 0
Pointer: high-order octet of the IPv6 Payload Length
error: IPv6 Payload Length != 0 and Jumbo Payload option present
エラー：！のIPv6ペイロード長= 0と巨大ペイロードオプションの存在
Code: 2
Pointer: Option Type field of the Jumbo Payload option
The 16-bit Length field of the UDP header limits the total length of a UDP packet (that is, a UDP header plus data) to no greater than 65,535 octets. This document specifies the following modification of UDP to relax that limit: UDP packets longer than 65,535 octets may be sent by setting the UDP Length field to zero, and letting the receiver derive the actual UDP packet length from the IPv6 payload length. (Note that, prior to this modification, zero was not a legal value for the UDP Length field, because the UDP packet length includes the UDP header and therefore has a minimum value of 8.)
UDPヘッダの16ビット長のフィールドが大きくない65,535よりオクテットにUDPパケットの合計長さ（すなわち、UDPヘッダとデータ）を制限します。この文書では、その制限を緩和するためにUDPの以下の変更を指定しています。長い65,535オクテットよりUDPパケットがゼロにUDPの長さフィールドを設定し、受信機は、IPv6ペイロード長から実際のUDPパケット長を導出させることにより、送信されることがあります。 （UDPパケット長がUDPヘッダを含み、従って、8の最小値を有するため、この変更に先立って、ゼロUDP Lengthフィールドの有効な値ではなかったことに注意してください）
The specific requirements for sending a UDP jumbogram are as follows:
次のようにUDPのジャンボグラムを送信するための具体的な要件は次のとおりです。
When sending a UDP packet, if and only if the length of the UDP header plus UDP data is greater than 65,535, set the Length field in the UDP header to zero.
及びUDPヘッダーとUDPデータの長さを超える65,535場合にのみ、ゼロにUDPヘッダの長さフィールドを設定した場合、UDPパケットを送信するとき。
The IPv6 packet carrying such a large UDP packet will necessarily include a Jumbo Payload option in a Hop-by-Hop Options header; set the Jumbo Payload Length field of that option to be the actual length of the UDP header plus data, plus the length of all IPv6 extension headers present between the IPv6 header and the UDP header.
このような大きなUDPパケットを運ぶIPv6パケットは、必ずしもホップバイホップオプションヘッダ内のジャンボペイロードオプションを含むであろう。 UDPヘッダとデータの実際の長さにそのオプションのジャンボペイロード長フィールド、プラスIPv6ヘッダとUDPヘッダとの間に存在する全てのIPv6拡張ヘッダの長さを設定します。
For generating the UDP checksum, use the actual length of the UDP header plus data, NOT zero, in the checksum pseudo-header [IPv6, Section 8.1].
UDPチェックサムを生成するために、チェックサム疑似ヘッダ[IPv6のセクション8.1]で、UDPヘッダとデータ、ゼロでないの実際の長さを使用します。
The specific requirements for receiving a UDP jumbogram are as follows:
次のようにUDPのジャンボグラムを受信するための具体的な要件は次のとおりです。
When receiving a UDP packet, if and only if the Length field in the UDP header is zero, calculate the actual length of the UDP header plus data from the IPv6 Jumbo Payload Length field minus the length of all extension headers present between the IPv6 header and the UDP header.
UDPパケットを受信すると、UDPヘッダの長さフィールドがゼロであれば、場合にのみ、IPv6のジャンボペイロード長フィールドからUDPヘッダとデータの実際の長さを引いIPv6ヘッダとの間に存在する全ての拡張ヘッダの長さを計算しますUDPヘッダ。
In the unexpected case that the UDP Length field is zero but no Jumbo Payload option is present (i.e., the IPv6 packet is not a jumbogram), use the Payload Length field in the IPv6 header, in place of the Jumbo Payload Length field, in the above calculation.
（すなわち、IPv6パケットがジャンボグラムではない）、UDP長フィールドがゼロであるが、何ジャンボペイロードオプションが存在しないことを予期しない場合に、ジャンボペイロード長フィールドの代わりに、IPv6ヘッダ内のペイロード長フィールドを使用上記の計算。
For verifying the received UDP checksum, use the calculated length of the UDP header plus data, NOT zero, in the checksum pseudo-header.
受信されたUDPチェックサムを検証するために、チェックサム疑似ヘッダに、UDPヘッダとデータ、NOTゼロの計算された長さを使用します。
Because there is no length field in the TCP header, there is nothing limiting the length of an individual TCP packet. However, the MSS value that is negotiated at the beginning of the connection limits the largest TCP packet that can be sent, and the Urgent Pointer cannot reference data beyond 65,535 bytes.
TCPヘッダには長さフィールドが存在しないので、個々のTCPパケットの長さを制限するものは何もありません。しかし、接続の開始時に交渉されるMSS値を送信することができる最大のTCPパケットを制限し、緊急ポインタは、65,535バイトを超えるデータを参照することはできません。
When determining what MSS value to send, if the MTU of the directly attached interface minus 60 [IPv6, Section 8.3] is greater than or equal to 65,535, then set the MSS value to 65,535.
MSS値を送信するかを決定する際に直接接続されているインターフェースのMTUマイナス60のIPv6、セクション8.3]以上65,535に等しい場合、次いで65,535にMSS値を設定します。
When an MSS value of 65,535 is received, it is to be treated as infinity. The actual MSS is determined by subtracting 60 from the value learned by performing Path MTU Discovery [MTU-DISC] over the path to the TCP peer.
65,535のMSS値を受信したとき、それは無限大として扱われるべきです。実際のMSSは、TCPピアへのパス上のパスMTU探索[MTU-DISC]を行うことにより、学習値から60を減算することによって決定されます。
The Urgent Pointer problem could be fixed by adding a TCP Urgent Pointer Option. However, since it is unlikely that applications using jumbograms will also use Urgent Pointers, a less intrusive change similar to the MSS change will suffice.
緊急ポインタの問題は、TCP緊急ポインタオプションを追加することによって固定することができます。それはジャンボグラムを使用したアプリケーションも緊急ポインタを使用することはほとんどありませんので、MSSの変更に似控えめ変更は十分です。
When a TCP packet is to be sent with an Urgent Pointer (i.e., the URG bit set), first calculate the offset from the Sequence Number to the Urgent Pointer. If the offset is less than 65,535, fill in the Urgent field and continue with the normal TCP processing. If the offset is greater than 65,535, and the offset is greater than or equal to the length of the TCP data, fill in the Urgent Pointer with 65,535 and continue with the normal TCP processing. Otherwise, the TCP packet must be split into two pieces. The first piece contains data up to, but not including the data pointed to by the Urgent Pointer, and the Urgent field is set to 65,535 to indicate that the Urgent Pointer is beyond the end of this packet. The second piece can then be sent with the Urgent field set normally.
TCPパケットが緊急ポインタ（すなわち、URGビットセット）で送信される場合、最初の緊急ポインタにシーケンス番号からのオフセットを計算します。オフセット65,535未満の場合は、緊急フィールドに入力し、通常のTCP処理を続行します。オフセット65,535より大きく、オフセットよりも大きいかまたはTCPデータの長さに等しい場合、65,535と緊急ポインタを記入し、通常のTCP処理を続行します。それ以外の場合は、TCPパケットを二つに分割する必要があります。最初の作品は、までのデータが含まれていますが、データは含まれません緊急ポインタで指され、緊急フィールドは緊急ポインタがこのパケットの終わりを超えていることを示すために65535に設定されています。第二部分は、その後、正常に設定緊急フィールドで送信することができます。
Note: The first piece does not have to include all of the data up to the Urgent Pointer. It can be shorter, just as long as it ends within 65,534 bytes of the Urgent Pointer, so that the offset to the Urgent Pointer in the second piece will be less than 65,535 bytes.
注意：最初の作品は緊急ポインタまでのデータのすべてを含める必要はありません。二枚で緊急ポインタにオフセット未満65,535バイトになりますようにそれは、ちょうど限り、それは緊急ポインタの65534バイト以内に終了するよう、短くすることができます。
For TCP input processing, when a TCP packet is received with the URG bit set and an Urgent field of 65,535, the Urgent Pointer is calculated using an offset equal to the length of the TCP data, rather than the offset in the Urgent field.
TCP入力処理のためのTCPパケットがURGで受信された場合、ビットセットと65,535の緊急フィールドは、緊急ポインタは、緊急フィールドのオフセットではなく、TCPデータの長さに等しいオフセットを使用して計算されます。
It should also be noted that though the TCP window is only 16-bits, larger windows can be used through use of the TCP Window Scale option [TCP-EXT].
また、TCPウィンドウはわずか16ビットであるが、大きな窓がTCPウィンドウスケールオプション[TCP-EXT]の使用を介して使用することができることに留意すべきです。
The Jumbo Payload option and TCP/UDP jumbograms do not introduce any known new security concerns.
巨大ペイロードオプションおよびTCP / UDPジャンボグラムは、任意の既知の新たなセキュリティ上の懸念を導入していません。
David A. Borman Berkeley Software Design, Inc. 4719 Weston Hills Drive Eagan, MN 55123 USA
デビッド・A・ボーマンバークレーソフトウェアデザイン株式会社4719ウェストンヒルズドライブイーガン、MN 55123 USA
Phone: +1 612 405 8194 EMail: dab@bsdi.com
電話：+1 612 405 8194 Eメール：dab@bsdi.com
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
スティーブンE.デアリングシスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134-1706 USA
Phone: +1 408 527 8213 EMail: deering@cisco.com
電話：+1 408 527 8213 Eメール：deering@cisco.com
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
ロバートM. Hindenとノキア313フェアチャイルドドライブマウンテンビュー、CA 94043 USA
Phone: +1 650 625 2004 EMail: hinden@iprg.nokia.com
電話：+1 650 625 2004 Eメール：hinden@iprg.nokia.com
[ICMPv6] Conta, A. and S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[ICMPv6の]コンタ、A.とS.デアリング、RFC 2463 "インターネットプロトコルバージョン6（IPv6）のためのICMP"、1998年12月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6の]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[MTU-DISC] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery for IP Version 6", RFC 1981, August 1986.
[MTU-DISC]、RFC 1981 "IPバージョン6のためのパスMTUディスカバリ" マッキャン、J.、デアリング、S.とJ.ムガール人、1986年8月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP]ポステル、J.、 "伝送制御プロトコル"、STD 7、RFC 793、1981年9月。
[TCP-EXT] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions for High Performance", RFC 1323, May 1992.
[TCP-EXT]ヤコブソン、V.、ブレーデン、R.とD.ボーマン、 "ハイパフォーマンスのためのTCP拡張"、RFC 1323、1992年5月。
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[UDP]ポステル、J.、 "ユーザ・データグラム・プロトコル"、STD 6、RFC 768、1980年8月。
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。