[要約] 要約： RFC 3146は、IPv6パケットをIEEE 1394ネットワーク上で転送するための仕様を提供しています。目的： このRFCの目的は、IPv6をサポートするためにIEEE 1394ネットワークを使用する際のプロトコルの要件と手順を定義することです。
Network Working Group K. Fujisawa
Request for Comments: 3146 A. Onoe
Category: Standards Track Sony Corporation
October 2001
Transmission of IPv6 Packets over IEEE 1394 Networks
IEEE 1394ネットワークを介した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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
Abstract
概要
This document describes the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks.
このドキュメントでは、IPv6パケットの送信のためのフレーム形式と、IEEE1394ネットワークでIPv6リンクローカルアドレスを形成する方法と、ステートレレスに自動確認されたアドレスを説明します。
IEEE Std 1394-1995 (and its amendment) is a standard for a High Performance Serial Bus. IETF IP1394 Working Group has standardized the method to carry IPv4 datagrams and ARP packets over IEEE1394 subnetwork [IP1394].
IEEE STD 1394-1995（およびその修正）は、高性能の連続バスの基準です。IETF IP1394ワーキンググループは、IEEE1394サブネットワーク[IP1394]を介してIPv4データグラムとARPパケットを運ぶ方法を標準化しました。
This document describes the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on IEEE1394 networks. It also describes the content of the Source/Target Link-layer Address option used in Neighbor Discovery [DISC] when the messages are transmitted on an IEEE1394 network.
このドキュメントでは、IPv6 [IPv6]パケットを送信するためのフレーム形式と、IEEE1394ネットワークでIPv6リンクローカルアドレスを形成する方法と、ステートレレスに自動構成されたアドレスを形成する方法について説明します。また、メッセージがIEEE1394ネットワークで送信されたときに、Neighbor Discovery [disc]で使用されるソース/ターゲットリンクレイヤーアドレスオプションの内容についても説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119に記載されているとおりに解釈されます。
An IPv6-capable node MUST fulfill the following minimum requirements:
IPv6対応ノードは、次の最小要件を満たす必要があります。
- it MUST implement configuration ROM in the general format specified by ISO/IEC 13213:1994 and MUST implement the bus information block specified by IEEE Std 1394a-2000 [1394a] and a unit directory specified by this document;
- ISO/IEC 13213：1994で指定された一般的な形式で構成ROMを実装する必要があり、IEEE STD 1394A-2000 [1394a]で指定されたバス情報ブロックと、このドキュメントで指定されたユニットディレクトリを実装する必要があります。
- the max_rec field in its bus information block MUST be at least 8; this indicates an ability to accept block write requests and asynchronous stream packets with data payload of 512 octets. The same ability MUST also apply to read requests; that is, the node MUST be able to transmit a block response packet with a data payload of 512 octets;
- バス情報ブロックのMAX_RECフィールドは、少なくとも8でなければなりません。これは、512オクテットのデータペイロードを使用して、ブロック書き込み要求と非同期ストリームパケットを受け入れる機能を示しています。また、読み取りリクエストにも同じ能力を適用する必要があります。つまり、ノードは512オクテットのデータペイロードでブロック応答パケットを送信できる必要があります。
- it MUST be isochronous resource manager capable, as specified by IEEE Std 1394a-2000;
- IEEE STD 1394A-2000で指定されているように、それは有能なリソースマネージャーでなければなりません。
- it MUST support both reception and transmission of asynchronous streams as specified by IEEE Std 1394a-2000.
- IEEE STD 1394A-2000で指定されているように、非同期ストリームの受信と送信の両方をサポートする必要があります。
The encapsulation and fragmentation mechanism MUST be the same as "4. LINK ENCAPSULATION AND FRAGMENTATION" of [IP1394].
カプセル化および断片化メカニズムは、[IP1394]の「リンクカプセル化と断片化」と同じでなければなりません。
Note: Since there is an ether_type field to discriminate protocols and MCAP (multicast channel allocation protocol) is used for both IPv4 and IPv6, the version field in GASP (global asynchronous stream packet) header of IPv6 datagrams is the same value (one) as [IP1394].
注：プロトコルを識別するETHER_TYPEフィールドがあるため、MCAP（マルチキャストチャネル割り当てプロトコル）がIPv4とIPv6の両方に使用されているため、IPv6データグラムのGasp（グローバル非同期ストリームパケット）のバージョンフィールドは同じ値（1）と同じ値（1）です。[IP1394]。
The ether_type value for IPv6 is 0x86dd.
IPv6のETHER_TYPE値は0x86DDです。
The default MTU size for IPv6 packets on an IEEE1394 network is 1500 octets. This size may be reduced by a Router Advertisement [DISC] containing an MTU option which specifies a smaller MTU, or by manual configuration of each node. If a Router Advertisement received on an IEEE1394 interface has an MTU option specifying an MTU larger than 1500, or larger than a manually configured value, that MTU option may be logged to system management but MUST be otherwise ignored. The mechanism to extend MTU size between particular two nodes is for further study.
IEEE1394ネットワーク上のIPv6パケットのデフォルトのMTUサイズは1500オクテットです。このサイズは、小さいMTUを指定するMTUオプションを含むルーター広告[disc]、または各ノードの手動構成によって削減される場合があります。IEEE1394インターフェイスで受信したルーター広告には、1500を超えるMTUを指定するMTUオプションがある場合、または手動で構成された値よりも大きいMTUオプションがある場合、そのMTUオプションはシステム管理にログに記録される可能性がありますが、それ以外の場合は無視する必要があります。特定の2つのノード間でMTUサイズを拡張するメカニズムは、さらなる研究のためです。
Configuration ROM for IPv6-capable nodes MUST contain a unit directory in the format specified by [IP1394] except following rules.
IPv6対応ノードの構成ROMには、次のルールを除き、[IP1394]で指定された形式のユニットディレクトリを含める必要があります。
- The value for Unit_SW_Version is 0x000002.
- Unit_sw_versionの値は0x000002です。
- The textual descriptor for the Unit_SW_Version MUST be "IPv6".
- Unit_sw_versionのテキスト記述子は「IPv6」でなければなりません。
Note: A dual-stack (IPv4 and IPv6) node will have two unit directories for IPv4 and IPv6 respectively.
注：デュアルスタック（IPv4およびIPv6）ノードには、それぞれIPv4とIPv6の2つのユニットディレクトリがあります。
The Interface Identifier [AARCH] for an IEEE1394 interface is formed from the interface's built-in EUI-64 identifier by complementing the "Universal/Local" (U/L) bit, which is the next-to-lowest order bit of the first octet of the EUI-64 identifier. Complementing this bit will generally change a 0 value to a 1, since an interface's built-in EUI-64 identifier is expected to be from a universally administered address space and hence have a globally unique value. A universally administered EUI-64 identifier is signified by a 0 in the U/L bit position, while a globally unique IPv6 Interface Identifier is signified by a 1 in the corresponding position. For further discussion on this point, see [AARCH].
IEEE1394インターフェイスのインターフェイス識別子[AARCH]は、「ユニバーサル/ローカル」（U/L）ビットを補完することにより、インターフェイスの組み込みのEUI-64識別子から形成されます。EUI-64識別子のオクテット。インターフェイスの組み込みのEUI-64識別子は、普遍的に管理されたアドレス空間からのものであり、したがってグローバルに一意の値があるため、このビットを補完することは一般に0値を1に変更します。普遍的に管理されたEUI-64識別子は、U/Lビット位置の0で象徴され、グローバルに一意のIPv6インターフェイス識別子は、対応する位置の1で象徴されます。この点に関する詳細については、[AARCH]を参照してください。
An IPv6 address prefix used for stateless autoconfiguration [ACONF] of an IEEE1394 interface MUST have a length of 64 bits.
IEEE1394インターフェイスのStateless Autoconfiguration [ACONF]に使用されるIPv6アドレスプレフィックスは、64ビットの長さを持つ必要があります。
The IPv6 link-local address [AARCH] for an IEEE1394 interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64.
IEEE1394インターフェイスのIPv6 Link-Localアドレス[AARCH]は、上記のようにインターフェイス識別子をプレフィックスFE80 ::/64に追加することにより形成されます。
10 bits 54 bits 64 bits
+----------+-----------------------+----------------------------+
|1111111010| (zeros) | Interface Identifier |
+----------+-----------------------+----------------------------+
The procedure for mapping IPv6 unicast addresses into IEEE1394 link-layer addresses uses the Neighbor Discovery [DISC]. Since 1394 link address (node_ID) will not be constant across a 1394 bridge, we have chosen not to put it in the Link-layer Address option. The recipient of the Neighbor Discovery SHOULD use the source_ID (obtained from either the asynchronous packet header or the GASP header) in conjunction with the content of the Source link-layer address. An implementation MAY use some other methods to obtain a node_ID of the sender utilizing a mapping table between node_unique_ID (EUI-64 identifier) and node_ID. The mechanism to make such mapping table is out of scope of this document.
IPv6ユニキャストアドレスをIEEE1394リンクレイヤーアドレスにマッピングする手順では、Neighbor Discovery [disc]が使用されます。1394年のリンクアドレス（node_id）は1394ブリッジ全体で一定ではないため、リンク層アドレスオプションに入れないことを選択しました。Neighbor Discoveryの受信者は、Source Link-Layerアドレスのコンテンツと組み合わせて、Source_ID（非同期パケットヘッダーまたはGaspヘッダーのいずれかから取得）を使用する必要があります。実装は、他のいくつかの方法を使用して、node_unique_id（eui-64識別子）とnode_idの間のマッピングテーブルを使用して送信者のnode_idを取得する場合があります。このようなマッピングテーブルを作成するメカニズムは、このドキュメントの範囲外です。
The recipient of an Neighbor Discovery packet MUST ignore it unless the most significant ten bits of the source_ID are equal to either 0x3FF or the most significant ten bits of the recipient's NODE_IDS register.
Neighbor Discoveryパケットの受信者は、Source_IDの最も重要な10ビットが0x3ffまたは受信者のnode_idsレジスタの最も重要な10ビットに等しい場合を除き、それを無視する必要があります。
The Source/Target Link-layer Address option has the following form when the link layer is IEEE1394.
リンクレイヤーがIEEE1394の場合、ソース/ターゲットリンクレイヤーアドレスオプションには、次のフォームがあります。
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 = 3 | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+
| node_unique_ID (EUI-64 identifier) |
+--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | max_rec | spd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unicast_FIFO |
+--- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type 1 for Source Link-layer address.
2 for Target Link-layer address.
Length 3 (in units of 8 octets).
node_unique_ID This field contains the node unique ID of the node and MUST be equal to that specified in the node's configuration ROM.
node_unique_idこのフィールドには、ノードのノード一意のIDが含まれており、ノードの構成ROMで指定されているものと等しくなければなりません。
max_rec This field MUST be equal to the value of max_rec in the node's configuration ROM.
MAX_RECこのフィールドは、ノードの構成ROMのMAX_RECの値に等しくなければなりません。
spd This field MUST be set to the lesser of the node's link speed and PHY speed. The link speed is the maximum speed at which the link may send or receive packets; the PHY speed is the maximum speed at which the PHY may send, receive or repeat packets. The encoding used for spd is specified in the Table 2 of [IP1394].
SPDこのフィールドは、ノードのリンク速度とPHY速度の低い方に設定する必要があります。リンク速度は、リンクがパケットを送信または受信できる最大速度です。Phy速度は、Phyがパケットを送信、受信、または繰り返す可能性のある最大速度です。SPDに使用されるエンコーディングは、[IP1394]の表2に指定されています。
unicast_FIFO This field MUST specify the 48-bit offset of the node's FIFO available for the receipt of IPv6 datagrams. The offset of a node's unicast FIFO MUST NOT change, except as the result of a power reset.
Unicast_fifoこのフィールドは、IPv6データグラムの受領に使用できるノードのFIFOの48ビットオフセットを指定する必要があります。ノードのユニキャストFIFOのオフセットは、電源リセットの結果を除いて変更してはなりません。
reserved This field MUST be set to all zeros by the sender and ignored by the receiver.
予約されたこのフィールドは、送信者によってすべてのゼロに設定され、受信機によって無視されなければなりません。
Note that node_ID may change when 1394 bus-reset occurs. The mapping cache held in the node SHOULD be cleared on 1394 bus-reset.
Node_IDは、1394バスレスが発生すると変更される可能性があることに注意してください。ノードに保持されているマッピングキャッシュは、1394バスレスでクリアする必要があります。
According to [1394], the maximum data payload and the transmission speed SHOULD be determined based on the sender's capability, the recipient's capability, and the PHYs of all intervening nodes.
[1394]によれば、最大データペイロードと送信速度は、送信者の能力、受信者の能力、およびすべての介在ノードの物理に基づいて決定する必要があります。
By default, all best-effort IPv6 multicast MUST use asynchronous stream packets whose channel number is equal to the channel field from the BROADCAST_CHANNEL register. In particular, datagrams addressed to all-nodes multicast addresses, all-routers multicast addresses, and solicited-node multicast addresses [AARCH] MUST use the default channel specified by the BROADCAST_CHANNEL register.
デフォルトでは、すべてのBest-Effort IPv6マルチキャストは、チャネル番号がbroadcast_channelレジスタのチャネルフィールドに等しい非同期ストリームパケットを使用する必要があります。特に、All-Nodesマルチキャストアドレス、All-Routersマルチキャストアドレス、および勧誘されたマルチキャストアドレス[AARCH]にアドレス指定されたデータグラム[AARCH]は、broadcast_channelレジスタで指定されたデフォルトチャネルを使用する必要があります。
Best-effort IPv6 multicast for other multicast group addresses may utilize a different channel number if such a channel number is allocated and advertised prior to use, by the multicast channel allocation protocol (MCAP), as described in [IP1394].
他のマルチキャストグループアドレス用のベストエフォルトIPv6マルチキャストは、[IP1394]に記載されているように、マルチキャストチャネル割り当てプロトコル（MCAP）によって、そのようなチャネル番号が使用前に割り当てられ、宣伝されている場合、異なるチャネル番号を利用できます。
When a node wishes to receive multicast data addressed to other than all-nodes multicast addresses, all-routers multicast addresses, and solicited-node multicast addresses, it MUST confirm if the channel mapping between a multicast group address and a channel number exists using MCAP, as described in "9.3 Multicast Receive" in [IP1394].
ノードが、すべてノードのマルチキャストアドレス、オールルーターのマルチキャストアドレス、および勧誘されたマルチキャストアドレス以外にアドレス指定されたマルチキャストデータを受信したい場合、MCAPを使用してマルチキャストグループアドレスとチャネル番号の間のチャネルマッピングが存在するかどうかを確認する必要があります。、[IP1394]の「9.3マルチキャスト受信」で説明されているように。
The implementation of MCAP is optional for send-only nodes. A node MAY transmit multicast data addressed to any multicast addresses into the default broadcast channel regardless of the existing allocation of the channel. If a node wishes to transmit multicast data on other than the default channel, it MUST first confirm by MCAP whether or not a channel number for the group address has been already allocated. The implementors are encouraged to use this protocol when transmitting high-rate multicast streams.
MCAPの実装は、送信専用ノードのオプションです。ノードは、チャネルの既存の割り当てに関係なく、マルチキャストアドレスにアドレス指定されたマルチキャストデータをデフォルトのブロードキャストチャネルに送信する場合があります。ノードがデフォルトチャネル以外にマルチキャストデータを送信したい場合、最初にグループアドレスのチャネル番号がすでに割り当てられているかどうかをMCAPで確認する必要があります。実装者は、高レートのマルチキャストストリームを送信するときにこのプロトコルを使用することをお勧めします。
The MCAP 'type' value for IPv6 group address descriptor is 2.
IPv6グループアドレス記述子のMCAP「タイプ」値は2です。
IANA has assigned a value of 0x000002 for "Unit_SW_Version for IPv6 over IEEE1394" out of the "CSR Protocol Identifiers" name space, as described in section 5. The details of the "CSR Protocol Identifiers" namespace is described in "10. IANA CONSIDERATIONS" of [IP1394].
IANAは、セクション5で説明されているように、「CSRプロトコル識別子」という名前の「CSRプロトコル識別子」という名前の「CSRプロトコル識別子」という名前のIEEE1394を超えるIPv6の「Unit_sw_version」に0x000002の値を割り当てました。「[IP1394]。
Section 9.1 of [IP1394] defines MCAP group address descriptors, which include an 8-bit type name space. This document requests that IANA maintain a name space to manage MCAP group address descriptors. The initial assignments for that table are:
[IP1394]のセクション9.1は、8ビットタイプ名のスペースを含むMCAPグループアドレス記述子を定義しています。このドキュメントは、IANAがMCAPグループアドレス記述子を管理するための名前スペースを維持することを要求します。そのテーブルの最初の割り当ては次のとおりです。
Value Usage
0 reserved
1 IPv4 Multicast Address
2 IPv6 Multicast Address
255 reserved
Additional values from the range 3-254 can be assigned through Standards Action [RFC 2434].
範囲3-254の追加値は、標準アクション[RFC 2434]を通じて割り当てることができます。
IPv6 over IEEE1394 does not introduce any additional security considerations over [IP1394]. The security concerns described in "11. SECURITY CONSIDERATIONS" in [IP1394] apply here as well.
IEEE1394を超えるIPv6は、[IP1394]をめぐる追加のセキュリティ上の考慮事項を導入しません。[IP1394]の「セキュリティ上の考慮事項」に記載されているセキュリティの懸念もここにも適用されます。
The authors would like to acknowledge the authors of [IP1394] and [ETHER] since some part of this document has been derived from them.
著者は、この文書の一部がそれらから派生しているため、[IP1394]および[エーテル]の著者に謝意を付けたいと考えています。
[1394] IEEE Std 1394-1995, Standard for a High Performance Serial Bus
[1394] IEEE STD 1394-1995、高性能シリアルバスの標準
[1394a] IEEE Std 1394a-2000, Standard for a High Performance Serial Bus - Amendment 1
[1394a] IEEE STD 1394A -2000、高性能シリアルバスの標準 - 修正1
[IP1394] Johansson, P., "IPv4 over IEEE 1394", RFC 2734, December 1999.
[IP1394] Johansson、P。、「IPv4 Over IEEE 1394」、RFC 2734、1999年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月。
[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373 December 1998.
[Aarch] Hinden、R。and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373 1998年12月。
[ACONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[ACONF] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[DISC] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[disc] Narten、T.、Nordmark、E。、およびW. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.
[Ether] Crawford、M。、「イーサネットネットワーク上のIPv6パケットの送信」、RFC 2464、1998年12月。
Kenji Fujisawa Network & Software Technology Center, Sony Corporation 6-7-35 Kitashinagawa, Shinagawa-ku, Tokyo 141-0001, JAPAN
藤沢ネットワーク＆ソフトウェアテクノロジーセンター、ソニーコーポレーション6-7-35キタシナガワ、シナガワクー、東京141-0001、日本
Phone: +81-3-5795-8507
Fax: +81-3-5795-8977
EMail: fujisawa@sm.sony.co.jp
Atsushi Onoe Internet Systems Laboratory, Internet Laboratories, Sony Corporation 6-7-35 Kitashinagawa, Shinagawa-ku, Tokyo 141-0001, JAPAN
Atsushi Onoe Internet Systems Laboratory、Internet Laboratories、Sony Corporation 6-7-35 Kitashinagawa、Shinagawa-Ku、Tokyo 141-0001、日本
Phone: +81-3-5448-4620
Fax: +81-3-5448-4622
EMail: onoe@sm.sony.co.jp
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（2001）。無断転載を禁じます。
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エディター機能の資金は現在、インターネット協会によって提供されています。