[要約] RFC 2675はIPv6 Jumbogramsの仕様を定めたものであり、大容量のデータ転送を可能にするためのプロトコルです。目的は、IPv6ネットワークでの効率的な大容量データ転送を実現することです。
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.
Copyright（c）The Internet Society（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.
「ジャンボグラム」は、65,535オクテットより長いペイロードを含む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.
ジャンボグラムは、65,575を超えるリンクMTUのリンクに接続される可能性のあるIPv6ノードにのみ関連し、そのような大きなMTUとのリンクへのアタッチメントをサポートしないIPv6ノードによって実装または理解する必要はありません。
jumbo (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.
n。、pl。-bos、adj。-n。1.その種の人、動物、または非常に大きなもの。-ADJ。2.非常に大きい：シリアルのジャンボボックス。
[1800-10; orig. uncert.; popularized as the name of a large elephant purchased and exhibited by P.T. Barnum in 1882]
[1800-10;起源。不安。P.T.によって購入され展示された大きな象の名前として普及しています。1882年のバーナム]
-- www.infoplease.com
-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オクテットまでのペイロードをサポートしています。このドキュメントは、65,536〜4,294,967,295オクテットのペイロードを持つIPv6パケットの送信を許可するために、32ビットの長さフィールドを持つジャンボペイロードオプションと呼ばれるIPv6ホップバイホップオプションを指定します。このような長いペイロードを持つパケットは、「ジャンボグラム」と呼ばれます。
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.
ジャンボペイロードオプションは、65,575を超えるオクテット（つまり、65,535 40、40オクテットがIPv6ヘッダーのサイズ）を超えるリンクMTUのリンクに接続できるIPv6ノードにのみ関連します。ジャンボペイロードオプションは、65,575を超える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を65,575オクテットを超える値に構成する必要はありません。それらのノードに。
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:
このドキュメントは、以前に2つの別々のドキュメントで公開されていた素材をマージおよび更新します。
- 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仕様の一部として登場しました。RFC1883は、ジャンボペイロードオプションの仕様が含まれなくなった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として登場しました。RFC2147はこのドキュメントによって廃止されています。
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ホップバイホップオプションヘッダーで運ばれます。このオプションには、4n 2のアラインメント要件があります。（オプションアライメントの説明については、[IPv6、セクション4.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ビット符号なし整数。Octetsの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
コード：0ポインター：IPv6ペイロード長の高次オクテット
error: IPv6 Payload Length != 0 and Jumbo Payload option present
エラー：IPv6ペイロード長さ！= 0およびジャンボペイロードオプションの表示
Code: 0 Pointer: Option Type field of the Jumbo Payload option
コード：0ポインター：ジャンボペイロードオプションのオプションタイプフィールド
error: Jumbo Payload option present and Jumbo Payload Length < 65,536
エラー：ジャンボペイロードオプションプレゼントとジャンボペイロード長<65,536
Code: 0 Pointer: high-order octet of the Jumbo Payload Length
コード：0ポインター：ジャンボペイロード長の高次オクテット
error: Jumbo Payload option present and Fragment header present
エラー：ジャンボペイロードオプションプレゼントとフラグメントヘッダープレゼント
Code: 0 Pointer: high-order octet of the Fragment header.
コード：0ポインター：フラグメントヘッダーの高次オクテット。
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:
Jumboペイロードオプションを理解していないノードは、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
コード：0ポインター：IPv6ペイロード長の高次オクテット
error: IPv6 Payload Length != 0 and Jumbo Payload option present
エラー：IPv6ペイロード長さ！= 0およびジャンボペイロードオプションの表示
Code: 2 Pointer: Option Type field of the Jumbo Payload option
コード：2ポインター：ジャンボペイロードオプションのオプションタイプフィールド
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ビットの長さフィールドは、UDPパケットの全長（つまり、UDPヘッダーとデータ）を65,535オクテット以下に制限します。このドキュメントは、その制限を緩和するためにUDPの次の変更を指定します。UDP長さフィールドをゼロに設定し、IPv6ペイロード長から実際のUDPパケット長をレシーバーに導き出すことにより、65,535を超えるUDPパケットを送信できます。（この変更の前に、UDPパケットの長さにUDPヘッダーが含まれているため、最小値は8のため、ゼロはUDP長さフィールドの法的価値ではなかったことに注意してください。）
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チェックサムを生成するには、Checksum pseudo-header [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パケットを受信する場合、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.
UDPの長さフィールドがゼロであるが、ジャンボペイロードオプションが存在しないという予期しない場合（つまり、IPv6パケットはジャンボグラムではありません）、ジャンボペイロード長の代わりに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ヘッダーの計算された長さとデータを使用します。
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値を決定するとき、直接接続されたインターフェイスをマイナス60 [IPv6、セクション8.3]を差し引いた場合、65,535以上の場合、MSS値を65,535に設定します。
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ピアへのパス上でPATH MTU Discovery [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パケットは2つのピースに分割する必要があります。最初のピースにはデータが含まれていますが、緊急ポインターによって指摘されたデータを含めません。緊急フィールドは65,535に設定されており、緊急ポインターがこのパケットの終わりを超えていることを示します。2番目のピースは、正常に緊急のフィールドセットで送信できます。
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,534バイト以内で終了する限り、短くなる可能性があります。そのため、2番目のピースの緊急ポインターへのオフセットは65,535バイト未満になります。
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
David A. Borman Berkeley Software Design、Inc。4719 Weston Hills Drive Eagan、Mn 55123 USA
Phone: +1 612 405 8194
EMail: dab@bsdi.com
Stephen E. Deering Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134-1706 USA
Stephen E. Deering Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134-1706 USA
Phone: +1 408 527 8213
EMail: deering@cisco.com
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
ロバートM.ヒンデンノキア313フェアチャイルドドライブマウンテンビュー、カリフォルニア94043 USA
Phone: +1 650 625 2004
EMail: hinden@iprg.nokia.com
[ICMPv6] Conta, A. and S. Deering, "ICMP for the Internet Protocol Version 6 (IPv6)", RFC 2463, December 1998.
[ICMPv6] Conta、A。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）のICMP」、RFC 2463、1998年12月。
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and 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] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1986年8月。
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.
[TCP] Postel、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] Jacobson、V.、Braden、R。およびD. Borman、「TCP拡張機能のためのTCP拡張」、RFC 1323、1992年5月。
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[UDP] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。