[要約] RFC 3307は、IPv6マルチキャストアドレスの割り当てガイドラインを提供するものであり、IPv6ネットワークにおけるマルチキャストアドレスの使用方法と割り当て方法を定義しています。このRFCの目的は、IPv6ネットワークにおけるマルチキャスト通信の効率的な実装を支援することです。

Network Working Group                                        B. Haberman
Request for Comments: 3307                                    Consultant
Category: Standards Track                                    August 2002
        

Allocation Guidelines for IPv6 Multicast Addresses

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 (2002). All Rights Reserved.

Copyright(c)The Internet Society(2002)。無断転載を禁じます。

Abstract

概要

This document specifies guidelines that must be implemented by any entity responsible for allocating IPv6 multicast addresses. This includes, but is not limited to, any documents or entities wishing to assign permanent IPv6 multicast addresses, allocate dynamic IPv6 multicast addresses, and define permanent IPv6 multicast group identifiers. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into the MAC layer address.

このドキュメントは、IPv6マルチキャストアドレスの割り当てを担当するエンティティが実装する必要があるガイドラインを指定します。これには、永続的なIPv6マルチキャストアドレスを割り当て、動的IPv6マルチキャストアドレスを割り当て、永続的なIPv6マルチキャストグループ識別子を定義するドキュメントまたはエンティティが含まれますが、これらに限定されません。これらのガイドラインの目的は、IPv6レイヤーだけでなく、IPレイヤーアドレスの部分をMACレイヤーアドレスにエンコードするメディアのリンク層でも、IPv6マルチキャストアドレス衝突の確率を低下させることです。

Table of Contents

目次

   1. Terminology.....................................................2
   2. Introduction....................................................2
   3. Applicability...................................................3
   4. Group ID Selection Guidelines...................................3
   4.1  Permanent IPv6 Multicast Addresses............................4
   4.2  Permanent IPv6 Multicast Group Identifiers....................4
   4.3  Dynamic IPv6 Multicast Addresses..............................4
   4.3.1 Server Allocation............................................5
   4.3.2 Host Allocation..............................................5
   5. IANA Considerations.............................................5
   6. Security Considerations.........................................6
   7. Acknowledgements................................................6
   8. References......................................................6
   Author's Address...................................................7
   Full Copyright Statement...........................................8
        
1. Terminology
1. 用語

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]で説明されているように解釈される。

The term "group ID", throughout this document, conforms to the definition contained in [UNIMCAST], that is, the low-order 32 bits of the IPv6 multicast address.

「グループID」という用語は、このドキュメント全体で、[Unimcast]に含まれる定義、つまりIPv6マルチキャストアドレスの低次の32ビットに準拠しています。

2. Introduction
2. はじめに

This document specifies guidelines that MUST be implemented by any entity responsible for allocating IPv6 multicast addresses. This includes, but is not limited to, any documents or entities wishing to assign permanent IPv6 multicast addresses, allocate dynamic IPv6 multicast addresses, and define permanent IPv6 multicast group identifiers. The purpose of these guidelines is to reduce the probability of IPv6 multicast address collision, not only at the IPv6 layer, but also at the link-layer of media that encode portions of the IP layer address into the link-layer address.

このドキュメントは、IPv6マルチキャストアドレスの割り当てを担当するエンティティが実装する必要があるガイドラインを指定します。これには、永続的なIPv6マルチキャストアドレスを割り当て、動的IPv6マルチキャストアドレスを割り当て、永続的なIPv6マルチキャストグループ識別子を定義するドキュメントまたはエンティティが含まれますが、これらに限定されません。これらのガイドラインの目的は、IPv6レイヤーだけでなく、IPレイヤーアドレスの一部をリンク層アドレスにエンコードするメディアのリンク層でも、IPv6マルチキャストアドレスの衝突の確率を減らすことです。

With the current IPv6 address architecture [ADDRARCH] and the extension to the multicast address architecture specified in [UNIMCAST], a set of guidelines is needed for entities assigning any flavor of IPv6 multicast addresses.

現在のIPv6アドレスアーキテクチャ[AddRarch]および[UNIMCAST]で指定されたマルチキャストアドレスアーキテクチャの拡張機能により、IPv6マルチキャストアドレスのフレーバーを割り当てるエンティティには、一連のガイドラインが必要です。

The current approach of several physical media [RFC 2464][RFC 2467] is to map a portion of the IPv6 multicast address into a link-layer destination address. This is accomplished by taking the low order 32 bits (henceforth called the group ID) of the IPv6 multicast address and including them in the link-layer destination address. Group IDs, less than or equal to, 32 bits long will generate unique link-layer addresses within a given multicast scope.

いくつかの物理メディア[RFC 2464] [RFC 2467]の現在のアプローチは、IPv6マルチキャストアドレスの一部をリンク層宛先アドレスにマッピングすることです。これは、IPv6マルチキャストアドレスの32ビット(以降、グループIDと呼ばれる)を使用し、リンク層の宛先アドレスにそれらを含めることによって達成されます。32ビット以下のグループIDは、特定のマルチキャスト範囲内で一意のリンク層アドレスを生成します。

These guidelines specify how the group ID of the IPv6 multicast address are chosen and assigned. The guidelines specify several mechanisms that can be used to determine the group ID of the multicast address, based on the type of allocation being done.

これらのガイドラインは、IPv6マルチキャストアドレスのグループIDが選択され、割り当てられる方法を指定します。ガイドラインでは、行われている割り当ての種類に基づいて、マルチキャストアドレスのグループIDを決定するために使用できるいくつかのメカニズムを指定します。

3. Applicability
3. 適用可能性

These guidelines are designed to be used in any environment in which IPv6 multicast addresses are delegated, assigned, or selected. These guidelines are not limited to use by MADCAP [RFC 2730] servers. The following is a non-exhaustive list of applications of these guidelines:

これらのガイドラインは、IPv6マルチキャストアドレスが委任、割り当て、または選択されている任意の環境で使用されるように設計されています。これらのガイドラインは、MADCAP [RFC 2730]サーバーによる使用に限定されません。以下は、これらのガイドラインのアプリケーションの網羅的ではないリストです。

- Source-specific multicast application servers can generate an SSM group address by generating a 96-bit multicast prefix, as defined in [UNIMCAST] (i.e. FF3x::/96) and concatenating that with a group ID, as defined in this document.

- ソース固有のマルチキャストアプリケーションサーバーは、[Unimcast](つまり、FF3x ::/96)で定義されているように、96ビットマルチキャストプレフィックスを生成し、このドキュメントで定義されているグループIDと同時にそれを連結することにより、SSMグループアドレスを生成できます。

- A MADCAP server allocates IPv6 multicast addresses conforming to section 2.7 of [ADDRARCH], creating the group ID using the rules defined in this document.

- MADCAPサーバーは、[AddRarch]のセクション2.7に準拠したIPv6マルチキャストアドレスを割り当て、このドキュメントで定義されているルールを使用してグループIDを作成します。

- Nodes supplying multicast services in a zeroconf environment generate multicast addresses without the need of centralized control.

- Zeroconf環境でマルチキャストサービスを提供するノードは、集中制御を必要とせずにマルチキャストアドレスを生成します。

- IANA can assign permanent multicast addresses to fulfill requests via the protocol standardization process.

- IANAは、プロトコル標準化プロセスを介して要求を満たすために、永続的なマルチキャストアドレスを割り当てることができます。

4. Group ID Selection Guidelines
4. グループID選択ガイドライン

The Group ID selection process allows for three types of multicast address assignments. These are permanent IPv6 multicast addresses, dynamic IPv6 multicast addresses, and permanent IPv6 multicast group IDs. The following guidelines assume that the prefix of the multicast address has been initialized according to [ADDRARCH] or [UNIMCAST].

グループID選択プロセスでは、3種類のマルチキャストアドレスの割り当てが可能になります。これらは、永続的なIPv6マルチキャストアドレス、動的IPv6マルチキャストアドレス、および永続的なIPv6マルチキャストグループIDです。次のガイドラインでは、マルチキャストアドレスの接頭辞が[Addrarch]または[Unimcast]に従って初期化されていると想定しています。

4.1 Permanent IPv6 Multicast Addresses
4.1 永続的なIPv6マルチキャストアドレス

Permanent multicast addresses, like those defined in [RFC 2375], are allocated by IANA. These addresses will be assigned with group ID's, in the range of 0x00000001 to 0x3FFFFFFF, on an Expert Review basis.

[RFC 2375]で定義されているものと同様に、恒久的なマルチキャストアドレスはIANAによって割り当てられます。これらのアドレスは、エキスパートレビューベースで、0x00000001〜0x3ffffffffの範囲のグループIDで割り当てられます。

Multicast addresses assigned by IANA MUST have the T bit set to 0 and the P bit set to 0.

IANAによって割り当てられたマルチキャストアドレスは、tビットを0に設定し、pビットを0に設定する必要があります。

4.2 Permanent IPv6 Multicast Group Identifiers
4.2 永続的なIPv6マルチキャストグループ識別子

Permanent group IDs allow for a global identifier of a particular service (e.g. Network Time Protocol (NTP) being assigned the group ID 0x40404040). The use of permanent group IDs differs from permanent multicast addresses in that a permanent group ID offers a global identifier for a service being offered by numerous servers.

永続的なグループIDにより、特定のサービスのグローバル識別子(例:ネットワークタイムプロトコル(NTP)がグループID 0x40404040を割り当てられています)を可能にします。永続的なグループIDの使用は、永続的なグループIDが多数のサーバーが提供するサービスのグローバル識別子を提供するという点で、永続的なマルチキャストアドレスとは異なります。

As an example, consider the NTP example group ID of 0x40404040. An NTP client would be able to access multiple servers and multiple scopes. That is, the NTP client will know that the group ID 0x40404040 identifies an NTP multicast stream regardless of the upper 96 bits of the multicast address.

例として、0x40404040のNTP例グループIDを考えてください。NTPクライアントは、複数のサーバーと複数のスコープにアクセスできます。つまり、NTPクライアントは、グループID 0x40404040が、マルチキャストアドレスの上部96ビットに関係なく、NTPマルチキャストストリームを識別することを知っています。

Permanent group IDs are allocated on an Expert Review basis, in the range 0x40000000 to 0x7FFFFFFF. These permanent group IDs are meant to be used in IPv6 multicast addresses, defined in [UNIMCAST].

永続的なグループIDは、0x40000000〜0x7fffffffの範囲で、専門家のレビューベースで割り当てられます。これらの永続的なグループIDは、[unimcast]で定義されているIPv6マルチキャストアドレスで使用することを目的としています。

4.3 Dynamic IPv6 Multicast Addresses
4.3 動的IPv6マルチキャストアドレス

Dynamic IPv6 multicast addresses can be allocated by an allocation server or by an end-host. Regardless of the allocation mechanism, all dynamically allocated IPv6 multicast addresses MUST have the T bit set to 1. This will distinguish the dynamically allocated addresses from the permanently assigned multicast addresses, defined in [RFC 2375], at the link-layer on any media that maps the lower portion of the IPv6 multicast address into a link-layer address. It should be noted that the high-order bit of the Group ID will be the same value as the T flag.

動的IPv6マルチキャストアドレスは、割り当てサーバーまたはエンドホストによって割り当てることができます。割り当てメカニズムに関係なく、すべての動的に割り当てられたIPv6マルチキャストアドレスは、tビットを1に設定する必要があります。これにより、[RFC 2375]で定義されている恒久的に割り当てられたマルチキャストアドレスと、任意のメディアのリンク層で、恒久的に割り当てられたマルチキャストアドレスが区別されます。IPv6マルチキャストアドレスの下部をリンク層アドレスにマッピングします。グループIDの高次ビットは、Tフラグと同じ値になることに注意する必要があります。

As an example, the permanent IPv6 multicast address FF02::9 maps to an Ethernet group address of 33-33-00-00-00-09. A dynamically allocated IPv6 multicast address of FF32::8000:9 would map to the Ethernet group address 33-33-80-00-00-09.

例として、永続的なIPv6マルチキャストアドレスFF02 :: 9は、33-33-00-00-00-09のイーサネットグループアドレスにマップします。FF32 :: 8000:9の動的に割り当てられたIPv6マルチキャストアドレスは、イーサネットグループアドレス33-33-80-00-00-09にマッピングされます。

4.3.1 Server Allocation
4.3.1 サーバー割り当て

The allocation of IPv6 multicast addresses, by a server, is defined in [RFC 2730]. Address management is the responsibility of the allocation protocol and outside the scope of this document. Allocation servers MUST use the group ID range 0x80000000 to 0xFFFFFFFF.

サーバーによるIPv6マルチキャストアドレスの割り当ては、[RFC 2730]で定義されています。アドレス管理は、割り当てプロトコルの責任であり、このドキュメントの範囲外です。割り当てサーバーは、グループID範囲0x80000000〜0xffffffffを使用する必要があります。

4.3.2 Host Allocation
4.3.2 ホスト割り当て

Host-based allocation allows hosts to self-select IPv6 multicast addresses. One example of host-based allocation is the Zeroconf Multicast Address Allocation Protocol [ZMAAPDOC]. Issues with collision detection, claim notification, etc. are outside the scope of this document and the responsibility of the protocol being used, such as [ZMAAPDOC].

ホストベースの割り当てにより、ホストはIPv6マルチキャストアドレスを自己選択できます。ホストベースの割り当ての1つの例は、Zeroconfマルチキャストアドレス割り当てプロトコル[zmaapdoc]です。衝突検出、クレーム通知などの問題は、このドキュメントの範囲と[Zmaapdoc]などのプロトコルの責任の範囲外です。

The group ID portion of the address is created using either a pseudo-random 32-bit number or a 32-bit number created using the guidelines in [RFC 1750]. The generated group ID MUST fall in the range 0x80000000 to 0xFFFFFFFF. This can be accomplished by setting the high-order bit of the generated number to 1.

アドレスのグループID部分は、[RFC 1750]のガイドラインを使用して作成された擬似ランダム32ビット番号または32ビット番号のいずれかを使用して作成されます。生成されたグループIDは、0x80000000から0xffffffffの範囲に分類する必要があります。これは、生成された数の高次ビットを1に設定することで実現できます。

5. IANA Considerations
5. IANAの考慮事項

This document requests the creation of a new registry maintained by IANA. This new registry will maintain permanent group ID values. The premise of this new registry is to allow for permanent group IDs to be used across multiple domains utilizing the multicast address architecture defined in [UNIMCAST]. The permanent group IDs will fall in the range 0x40000000 to 0x7FFFFFFF.

このドキュメントでは、IANAが管理する新しいレジストリの作成をリクエストします。この新しいレジストリは、永久的なグループID値を維持します。この新しいレジストリの前提は、[Unimcast]で定義されているマルチキャストアドレスアーキテクチャを使用して、複数のドメインで永続的なグループIDを使用できるようにすることです。永続的なグループIDは、0x40000000から0x7ffffffffの範囲に分類されます。

In addition, this document also defines rules for the allocation of permanent IPv6 multicast addresses by IANA. These rules specify different ranges for multicast addresses that are IPv6-only and for IPv6 multicast addresses that have corresponding IPv4 multicast addresses.

さらに、このドキュメントでは、IANAによる永続的なIPv6マルチキャストアドレスの割り当てに関するルールも定義しています。これらのルールは、IPv6のみのマルチキャストアドレスと、対応するIPv4マルチキャストアドレスを持つIPv6マルチキャストアドレスのさまざまな範囲を指定します。

Following the policies outlined in [RFC 2434]:

[RFC 2434]で概説されているポリシーに従ってください。

- Permanent IPv6 multicast addresses with corresponding IPv4 multicast addresses, like those defined in [RFC 2375], are allocated with group ID's in the range of 1 to 0x3FFFFFFF on an Expert Review basis, see Section 4.1.

- [RFC 2375]で定義されているものと同様に、対応するIPv4マルチキャストアドレスを持つ永続的なIPv6マルチキャストアドレスは、専門家のレビューベースで1〜0x3FFFFFFFの範囲のグループIDに割り当てられます。セクション4.1を参照してください。

- Permanent IPv6-only multicast addresses are allocated with group ID's in the range 0x100 to 0x3FFFFFFF on an Expert Review basis. - Permanent group ID's are allocated on an Expert Review basis in the range 0x40000000 to 0x7FFFFFFF, see Section 4.2. - The range 0x80000000 to 0xFFFFFFFF is reserved for use by dynamic multicast address allocation mechanisms, see Section 4.3.

- 永続的なIPv6のみのマルチキャストアドレスは、エキスパートレビューベースで0x100〜0x3ffffffffの範囲のグループIDで割り当てられます。 - 永続的なグループIDは、0x40000000から0x7ffffffffの範囲の専門家レビューベースで割り当てられます。セクション4.2を参照してください。-0x80000000〜0xffffffffの範囲は、動的なマルチキャストアドレス割り当てメカニズムによって使用されるために予約されています。セクション4.3を参照してください。

All approved requests for a permanent IPv6 multicast address will result in the assignment of a unique group ID which shall be reserved in all valid IPv6 multicast scopes.

永続的なIPv6マルチキャストアドレスに対する承認されたすべての要求により、すべての有効なIPv6マルチキャストスコープで予約される一意のグループIDが割り当てられます。

6. Security Considerations
6. セキュリティに関する考慮事項

The allocation mechanisms described in this document do not alter the security properties of either the Any Source or Source Specific multicast service models of IPv4 and IPv6.

このドキュメントで説明されている割り当てメカニズムは、IPv4およびIPv6のソースまたはソース固有のマルチキャストサービスモデルのいずれのセキュリティプロパティを変更しません。

The potential to allocate large blocks of addresses can lead to Denial-of-Service attacks. A more in-depth discussion of the security issues surrounding dynamic allocation of multicast addresses can be found in [RFC 2908].

住所の大きなブロックを割り当てる可能性は、サービス拒否攻撃につながる可能性があります。マルチキャストアドレスの動的割り当てを取り巻くセキュリティの問題についてのより詳細な議論は、[RFC 2908]に記載されています。

7. Acknowledgements
7. 謝辞

The author would like to thank Dave Thaler, Steve Deering, Allison Mankin, Thomas Narten, and Erik Nordmark for their thorough review of this document.

著者は、この文書を徹底的にレビューしてくれたDave Thaler、Steve Deering、Allison Mankin、Thomas Narten、Erik Nordmarkに感謝したいと思います。

8. References
8. 参考文献

[RFC 2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.

[RFC 2026] Bradner、S。、「インターネット標準プロセス - 改訂3」、BCP 9、RFC 2026、1996年10月。

[UNIMCAST] Haberman, B. and D. Thaler, "Unicast Prefix-based IPv6 Multicast Addresses", RFC 3306, June 2002.

[Unimcast] Haberman、B。and D. Thaler、「UnicastプレフィックスベースのIPv6マルチキャストアドレス」、RFC 3306、2002年6月。

[ADDRARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.

[Addrarch] Hinden、R。and S. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年7月。

[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1999.

[RFC 2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1999年3月。

[RFC 2730] Hanna, S., Patel, B. and M. Shah, "Multicast Address Dynamic Client Allocation Protocol (MADCAP)", RFC 2730, December 1999.

[RFC 2730] Hanna、S.、Patel、B。、およびM. Shah、「マルチキャストアドレス動的クライアント割り当てプロトコル(MADCAP)」、RFC 2730、1999年12月。

[RFC 2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, December 1998.

[RFC 2464] Crawford、M。、「イーサネットネットワーク上のIPv6パケットの送信」、RFC 2464、1998年12月。

[RFC 2467] Crawford, M., "Transmission of IPv6 over FDDI Networks", RFC 2467, December 1998.

[RFC 2467] Crawford、M。、「FDDIネットワーク上のIPv6の送信」、RFC 2467、1998年12月。

[RFC 1750] Eastlake, D., Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.

[RFC 1750] Eastlake、D.、Crocker、S。and J. Schiller、「セキュリティのためのランダム性推奨」、RFC 1750、1994年12月。

[RFC 2375] Hinden, R. and S. Deering, "IPv6 Multicast Address Assignments", RFC 2375, July 1998.

[RFC 2375] Hinden、R。およびS. Deering、「IPv6マルチキャストアドレスの割り当て」、RFC 2375、1998年7月。

[RFC 2908] Thaler, D., Handley, M. and D. Estrin, "The Internet Multicast Address Allocation Architecture", RFC 2908, September 2000.

[RFC 2908] Thaler、D.、Handley、M。and D. Estrin、「The Internet Multicast Address Arlocation Architecture」、RFC 2908、2000年9月。

[ZMAAPDOC] Catrina, et al, "Zeroconf Multicast Address Allocation Protocol (ZMAAP)", Work In Progress.

[Zmaapdoc] Catrina、et al、「Zeroconfマルチキャストアドレス割り当てプロトコル(ZMAAP)」、作業進行中。

Author's Address

著者の連絡先

Brian Haberman Consultant Phone: 1-919-949-4828 EMail: bkhabs@nc.rr.com

ブライアンハーバーマンコンサルタント電話:1-919-949-4828メール:bkhabs@nc.rr.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The Internet Society (2002). All Rights Reserved.

Copyright(c)The Internet Society(2002)。無断転載を禁じます。

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エディター機能の資金は現在、インターネット協会によって提供されています。