RFC2675 日本語訳
2675 IPv6 Jumbograms. D. Borman, S. Deering, R. Hinden. August 1999. (Format: TXT=17320 bytes) (Obsoletes RFC2147) (Status: PROPOSED STANDARD)
RFC一覧
英語原文
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
IPv6 ジャンボ (データ) グラム
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.
この文書は、Internet community のための Internet standards track
protocol を明細に記述し、改良のための討議と提案を要求する。このプロ
トコルの標準化状態とステータスについては、"Internet Official
Protocol Standards" (STD 1) の最新版を参照してもらいたい。このメモの
配布は、無制限である。
-----------------------------------------------------------------------
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
-----------------------------------------------------------------------
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.
"jumbogram" は、65,535 octets よりも大きいペイロードを含んだ IPv6 パ
ケットである。この文書は、IPv6 Jumbo Payload オプションを記述する。
このオプションは、非常に大きなペイロードの指定手段を提供する。これは
jumbograms 利用のため、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.
jumbograms は、65,575 octets より大きな link MTU を持つ link に取り
付けられるだろう IPv6 nodes のみに関連がある。そしてこれは、非常に大
きな MTUs を持つ link への取り付けをサポートしない IPv6 には実装も理
解される必要もない。
-----------------------------------------------------------------------
1. Introduction
1. 序論
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.
大変大きな: 穀物の大変大きな箱。
[1800-10; orig. uncert.; popularized as the name of a large
elephant purchased and exhibited by P.T. Barnum in 1882]
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-bit Payload Length フィールドを持つ。それ
ゆえ 65,535 octets 長までペイロードをサポートする。この文書は、Jumbo
Payload オプションと呼ばれる、IPv6 hop-by-hop オプションを明細に述べ
る。このオプションは、長さ 65,536 から 4,294,967,295 octets 間のペイ
ロードを持つ IPv6 パケットの転送を許すための 32-bit 長フィールドを運
ぶ。非常に大きなペイロードを持つパケットは、"jumbograms" として参照
される。
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.
Jumbo Payload オプションは、65,575 octets より大きな link MTU を持
つ link に取り付けられるだろう IP nodes についてのみ関連する (65,575
は 65,535 + 40 であり、40 octets は IPv6 ヘッダサイズである)。Jumbo
Payload オプションは、65,575 より大きな MTU を持つ link への取り付け
をサポートしない IPv6 nodes に実装や理解される必要がない。
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 を持つ link 上で、Jumbo Payload オプションをサポート
しない link に取り付けられた nodes がもしあるなら、MTU は、65,575
octets より大きな値に設定してはならない。これは、Jumbo Payload オプ
ションがそれら nodes へと送信されないということを保証できない (から
である)。
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-bit Length フィールドを持つ。このフィールド
は、UDP の jumbogram 利用を妨げる。そして TCP ヘッダ [TCP] は Length
フィールドを持たないけれども、TCP MSS オプションと TCP Urgent フィー
ルド両方は、16 bits に抑制される。この文書は、TCP と UDP が
jumbogram を利用できるようにするため、それらへのいくつかのシンプルな
エンハンスメントを明細に述べる。Jumbo Payload オプションをサポートす
る IPv6 node 上での 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 bit チェックサムは、チェックサ
ム計算が増加されることになるデータ長として、むしろ正確でなくなる。ア
プリケーション設計者は、このことを考慮に入れたいだろう。
1.1 Document History
1.1 文書履歴
This document merges and updates material that was previously
published in two separate documents:
この文書は、2 つの別々の文書で前に公開された資料を merge し、そして
更新した。
- 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.
Jumbo Payload オプションの仕様は、RFC 1883 の IPv6 仕様書の一部分
として前に現れた。RFC 1883 は、RFC 2460 により取って代わられ、
Jumbo Payload オプションの仕様をもはや含まない。
- The specification of TCP and UDP enhancements to support
jumbograms previously appeared as RFC 2147. RFC 2147 is obsoleted
by this document.
jumbograms をサポートするため TCP と UDP エンハンスメントの仕様は
RFC 2147 として前に現れた。RFC 2147 は、この文書により obsolete
された (すたれた)。
-----------------------------------------------------------------------
2. Format of the Jumbo Payload Option
2. 巨大ペイロードオプションの形式
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:
Jumbo Payload オプションは、IPv6 ヘッダに直ちに続くものである IPv6
Hop-by-Hop Options ヘッダで運ばれる。このオプションは、配置要求
4n + 2 を持つ。(オプション配置の審議について、[IPv6, Section 4.2] を
参照しなさい。) オプションは、次に述べる形式を持つ:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Jumbo Payload Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type 8-bit value C2 (hexadecimal).
8-bit 値 C2 (16 進)。
Opt Data Len 8-bit value 4.
8-bit 値 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-bit 符号なし整数。IPv6 ヘッダを除くが Hop-
by-Hop Options ヘッダと他の存在するどんな拡張
ヘッダも含んだ、octets での IPv6 パケット長。
65,535 より大きくなければならない。
-----------------------------------------------------------------------
3. Usage of the Jumbo Payload Option
3. 巨大ペイロードオプションの使用法
The Payload Length field in the IPv6 header must be set to zero in
every packet that carries the Jumbo Payload option.
IPv6 ヘッダ中の Payload Length フィールドは、Jumbo Payload オプショ
ンを運ぶすべてのパケットで、zero に設定しなければならない。
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.
Jumbo Payload オプションを理解する node が zero の Payload Length と
(Hop-by-Hop Options ヘッダが続くことを意味する) zero の Next Header
値を運ぶ IPv6 ヘッダであるパケットと、link 層フレーム化したものが
IPv6 ヘッダ以上であることを指し示すパケットを受信するなら、その node
は、Jumbo Payload オプションから実際のペイロード長を決定するために、
Hop-by-Hop Options を処理し始めなければならない。
The Jumbo Payload option must not be used in a packet that carries a
Fragment header.
Jumbo Payload オプションは、Fragment ヘッダを運ぶパケットに決して使
用されてはならない。
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, Section 8.1] で記述されたチェックサム疑似ヘッダ内の Upper-
Layer Packet Length フィールド値を計算するため、IPv6 Payload Length
フィールドを使用する Higher-layer (より高い上位層) プロトコルは、
Jumbo Payload オプションを運ぶパケットについて、その計算のために
Jumbo Payload Length フィールドを代わりに使用しなければならない。
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:
Jumbo Payload オプションを理解する nodes は、多数の起こりうる形式エ
ラーを発見することが必要とされる。そして、もし誤ったパケットがマルチ
キャストアドレス行きでなかったなら、パケットの始点へと ICMP
Parameter Problem メッセージ [ICMPv6] を送信することにより、エラーを
報告する。次に述べるエラーリストは、Parameter Problem メッセージの
Code と Pointer フィールドで使用される値を明細に述べる:
error: IPv6 Payload Length = 0 and
IPv6 Next Header = Hop-by-Hop Options and
Jumbo Payload option not present
IPv6 Payload Length = 0 で、かつ
IPv6 Next Header = Hop-by-Hop Options と Jumbo Payload オ
プションが存在しない場合
Code: 0
Pointer: high-order octet of the IPv6 Payload Length
IPv6 Payload Length の最上位 octet
error: IPv6 Payload Length != 0 and
Jumbo Payload option present
IPv6 Payload Length != 0 で、かつ
Jumbo Payload オプションが存在する場合
Code: 0
Pointer: Option Type field of the Jumbo Payload option
Jumbo Payload オプションの Option Type
error: Jumbo Payload option present and
Jumbo Payload Length < 65,536
Jumbo Payload オプションが存在し、かつ
Jumbo Payload Length < 65,536 の場合
Code: 0
Pointer: high-order octet of the Jumbo Payload Length
Jumbo Payload Length の最上位 octet
error: Jumbo Payload option present and
Fragment header present
Jumbo Payload オプションが存在し、かつ
Fragment ヘッダが存在する場合
Code: 0
Pointer: high-order octet of the Fragment header.
Fragment ヘッダの最上位 octet
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 Payload オプションを理解しない node は、IPv6 仕様書にしたがっ
て、次のように誤って受信された jumbograms へと応答することが期待され
る:
error: IPv6 Payload Length = 0 and
IPv6 Next Header = Hop-by-Hop Options
IPv6 Payload Length = 0 で、かつ
IPv6 Next Header = Hop-by-Hop Options の場合
Code: 0
Pointer: high-order octet of the IPv6 Payload Length
IPv6 Payload Length の最上位 octet
error: IPv6 Payload Length != 0 and
Jumbo Payload option present
IPv6 Payload Length != 0 で、かつ
Jumbo Payload オプションが存在する場合
Code: 2
Pointer: Option Type field of the Jumbo Payload option
Jumbo Payload オプションの Option Type フィールド
-----------------------------------------------------------------------
4. UDP Jumbograms
4. UDP 巨大 (ペイロード) グラム
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-bit Length フィールドは、UDP パケット (すなわち UDP
ヘッダとデータを足したもの) の全長を、65,535 octets より大きくできな
いように制限する。この文書は、その制限をゆるめるために次に述べる変更
を明細に述べる: 65,535 octets より大きな UDP パケットは、UDP Length
フィールドを zero に設定して送信される。そして受信側に IPv6 ペイロー
ドから実際の UDP パケット長を引き出させる。(この変更より前に、zero
は、UDP Length フィールド値に対して許される値でないことに注意しなさ
い。なぜなら、UDP パケット長は UDP ヘッダを含むので、8 の最小値を持
つからである。)
The specific requirements for sending a UDP jumbogram are as follows:
UDP jumbogram 送信に関する明確な要求は、次の通りである:
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 ヘッダと UDP データを足した長さが
65,535 より大きいなら、UDP ヘッダ中の Length フィールドを zero に
設定しなさい。
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 パケットは、Hop-by-Hop
Options ヘッダ中に Jumbo Payload オプションを必ず含む; IPv6 ヘッ
ダと UDP ヘッダ間にあるすべての拡張ヘッダ長を加えて、UDP ヘッダと
データを足した実際の長さで、そのオプションの Jumbo Payload Length
フィールドを設定しなさい。
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 チェックサム生成に関し、UDP ヘッダとデータを足した実際の長さ
を使用しなさい。チェックサム疑似ヘッダ [IPv6, Section 8.1] で、
zero にならない (NOT)。
The specific requirements for receiving a UDP jumbogram are as
follows:
UDP jumbogram 受信に関する明確な要求は、次の通りである:
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 ヘッダの Length フィールドが zero で
あるなら、IPv6 ヘッダと UDP ヘッダ間にあったすべての拡張ヘッダの
長さを引いた IPv6 Jumbo Payload Length フィールドから、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 Length フィールドが zero であるが Jumbo Payload オプションが
ない (すなわち、IPv6 パケットが jumbogram でない) という予期され
ないケースでは、上の計算で、Jumbo Payload Length フィールドの代わ
りに、IPv6 ヘッダの Payload Length フィールドを使用しなさい。
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 ヘッダとデータを足し
たその計算された長さを使用しなさい。チェックサム疑似ヘッダで、
zero にならない (NOT)。
-----------------------------------------------------------------------
5. TCP Jumbograms
5. TCP 巨大 (データ) グラム
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 パケット値を制限する。そし
て Urgent Pointer は、65,535 bytes を越えたデータを参照できない。
5.1 TCP MSS
5.1 TCP MSS 値
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, Section 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 peer への path 上の Path MTU Discovery [MTU-
DISC] をおこなうことにより学習した値から 60 を引くことにより決定され
る。
5.2 TCP Urgent Pointer
5.2 TCP 緊急ポインタ
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.
Urgent Pointer 問題は、TCP Urgent Pointer Option を追加することによ
り直すことができる。しかしながら jumbogram を使用するアプリケーショ
ンが Urgent Pointers も使用することはありそうにないので、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 パケットが Urgent Pointer と送信される (すなわち、URG bit が設定
される) 時、最初に Sequence Number から Urgent Pointer への offset
を計算しなさい。もし offset が 65,535 より小さいなら、Urgent フィー
ルドを埋め、通常の TCP 処理を続けなさい。もし offset が 65,535 より
大きいなら、offset は TCP データの長さより大きいか等しく、65,535 で
Urgent Pointer を埋め、通常の TCP 処理を続けなさい。そうでなければ
TCP パケットは、2 つに分割されなければならない。最初の部分は、Urgent
Pointer によりポインタされるデータを含まないデータまでを含む。そして
Urgent Pointer がこのパケットの終わりを越えていることを指し示すため
Urgent フィールドは、65,535 に設定される。2 つめの部分は、その後、通
常に設定される Urgent フィールドで送信されることができる。
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.
注意: 最初の部分は、Urgent Pointer までのすべてのデータを含まなけれ
ばならないということは、ない。これは、Urgent Pointer の 65,534 bytes
内で終わる限り、短くできる。それで 2 つめの部分で Urgent Pointer へ
の offset は、65,535 bytes より小さいだろう。
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 bit に設定され、かつ 65,535
の Urgent フィールドで受信された時、Urgent Pointer は、Urgent フィー
ルド内の offset よりむしろ、TCP データの長さに等しい offset を使用し
て計算される。
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 window が 16-bits のみであるけれども、より大きな window は、TCP
Window Scale オプション [TCP-EXT] の使用を通して使用されることができ
ることにも注意されるべきである。
-----------------------------------------------------------------------
6. Security Considerations
6. セキュリティに関する考察
The Jumbo Payload option and TCP/UDP jumbograms do not introduce any
known new security concerns.
Jumbo Payload オプションと TCP/UDP jumbograms は、知られているどんな
新しいセキュリティ懸念も生み出さない。
-----------------------------------------------------------------------
7. Authors' Addresses
7. 著者のアドレス
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
Phone: +1 408 527 8213
EMail: deering@cisco.com
Robert M. Hinden
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA
Phone: +1 650 625 2004
EMail: hinden@iprg.nokia.com
-----------------------------------------------------------------------
8. References
8. 参考文献
[ICMPv6] Conta, A. and S. Deering, "ICMP for the Internet Protocol
Version 6 (IPv6)", RFC 2463, December 1998.
[IPv6] Deering, S. and R. Hinden, "Internet Protocol Version 6
(IPv6) Specification", RFC 2460, December 1998.
[MTU-DISC] McCann, J., Deering, S. and J. Mogul, "Path MTU Discovery
for IP Version 6", RFC 1981, August 1986.
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981.
[TCP-EXT] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
for High Performance", RFC 1323, May 1992.
[UDP] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
-----------------------------------------------------------------------
9. Full Copyright Statement
9. 著作権表示全文
Copyright (C) The Internet Society (1999). All Rights Reserved.
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 の働きに対する資金援助は、Internet Society により現在提供
される。
