[要約] RFC 2365は、管理上のスコープを持つIPマルチキャストに関する規格であり、インターネット上でのマルチキャスト通信を制御するための手法を提供しています。このRFCの目的は、異なる管理ドメイン間でのマルチキャストトラフィックの制御と管理を可能にすることです。
Network Working Group D. Meyer
Request for Comments: 2365 University of Oregon
BCP: 23 July 1998
Category: Best Current Practice
Administratively Scoped IP Multicast
管理用スコープのIPマルチキャスト
Status of this Memo
本文書の状態
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
このドキュメントでは、インターネットコミュニティのためのインターネットのベストプラクティスを示し、改善のためのディスカッションと提案を要求します。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
This document defines the "administratively scoped IPv4 multicast space" to be the range 239.0.0.0 to 239.255.255.255. In addition, it describes a simple set of semantics for the implementation of Administratively Scoped IP Multicast. Finally, it provides a mapping between the IPv6 multicast address classes [RFC1884] and IPv4 multicast address classes.
このドキュメントでは、「管理スコープのIPv4マルチキャストスペース」を239.0.0.0〜239.255.255.255の範囲と定義しています。さらに、管理用スコープのIPマルチキャストを実装するための簡単なセマンティクスのセットについても説明します。最後に、IPv6マルチキャストアドレスクラス[RFC1884]とIPv4マルチキャストアドレスクラス間のマッピングを提供します。
This memo is a product of the MBONE Deployment Working Group (MBONED) in the Operations and Management Area of the Internet Engineering Task Force. Submit comments to <mboned@ns.uoregon.edu> or the author.
このメモは、インターネット技術特別調査委員会の運用および管理領域にあるMBONE展開作業グループ（MBONED）の製品です。 <mboned@ns.uoregon.edu>または作者にコメントを送信してください。
Much of this memo is taken from "Administratively Scoped IP Multicast", Van Jacobson and Steve Deering, presented at the 30th IETF, Toronto, Canada, 25 July 1994. Steve Casner, Mark Handley and Dave Thaler have also provided insightful comments on earlier versions of this document.
このメモの多くは、1994年7月25日、カナダのトロントで開催された第30回IETFで発表された「管理スコープIPマルチキャスト」のVan JacobsonとSteve Deeringから引用されています。このドキュメントの。
Most current IP multicast implementations achieve some level of scoping by using the TTL field in the IP header. Typical MBONE (Multicast Backbone) usage has been to engineer TTL thresholds that confine traffic to some administratively defined topological region. The basic forwarding rule for interfaces with configured TTL thresholds is that a packet is not forwarded across the interface unless its remaining TTL is greater than the threshold.
現在のほとんどのIPマルチキャスト実装では、IPヘッダーのTTLフィールドを使用して、ある程度のスコープを実現しています。典型的なMBONE（マルチキャストバックボーン）の使用は、管理上定義されたトポロジリージョンにトラフィックを制限するTTLしきい値を設計することでした。 TTLしきい値が設定されているインターフェースの基本的な転送ルールは、残りのTTLがしきい値を超えない限り、パケットはインターフェース全体に転送されないことです。
TTL scoping has been used to control the distribution of multicast traffic with the objective of easing stress on scarce resources (e.g., bandwidth), or to achieve some kind of improved privacy or scaling properties. In addition, the TTL is also used in its traditional role to limit datagram lifetime. Given these often conflicting roles, TTL scoping has proven difficult to implement reliably, and the resulting schemes have often been complex and difficult to understand.
TTLスコーピングは、不足しているリソース（帯域幅など）へのストレスを緩和する目的でマルチキャストトラフィックの配信を制御するため、または何らかの改善されたプライバシーまたはスケーリングプロパティを実現するために使用されています。さらに、TTLは従来の役割でも使用され、データグラムの寿命を制限します。これらのしばしば相反する役割を考えると、TTLスコーピングは確実に実装することが困難であることが証明されており、結果として生じるスキームはしばしば複雑であり、理解することが困難でした。
A more serious architectural problem concerns the interaction of TTL scoping with broadcast and prune protocols (e.g., DVMRP [DVMRP]). The particular problem is that in many common cases, TTL scoping can prevent pruning from being effective. Consider the case in which a packet has either had its TTL expire or failed a TTL threshold. The router which discards the packet will not be capable of pruning any upstream sources, and thus will sink all multicast traffic (whether or not there are downstream receivers). Note that while it might seem possible to send prunes upstream from the point at which a packet is discarded, this strategy can result in legitimate traffic being discarded, since subsequent packets could take a different path and arrive at the same point with a larger TTL.
より深刻なアーキテクチャの問題は、TTLスコーピングとブロードキャストおよびプルーンプロトコル（DVMRP [DVMRP]など）との相互作用に関係しています。特定の問題は、多くの一般的なケースで、TTLスコーピングがプルーニングの効果を妨げる可能性があることです。パケットのTTL期限が切れているか、TTLしきい値に失敗した場合を考えます。パケットを破棄するルーターは、上流のソースをプルーニングできないため、すべてのマルチキャストトラフィックをシンクします（下流のレシーバーがあるかどうかに関係なく）。パケットが破棄されたポイントから上流にプルーンを送信することは可能に思えるかもしれませんが、後続のパケットが異なるパスを通過してより大きなTTLで同じポイントに到達する可能性があるため、この戦略は正当なトラフィックを破棄する可能性があることに注意してください。
On the other hand, administratively scoped IP multicast can provide clear and simple semantics for scoped IP multicast. The key properties of administratively scoped IP multicast are that (i). packets addressed to administratively scoped multicast addresses do not cross configured administrative boundaries, and (ii). administratively scoped multicast addresses are locally assigned, and hence are not required to be unique across administrative boundaries.
一方、管理用スコープのIPマルチキャストは、スコープ付きIPマルチキャストに明確で単純なセマンティクスを提供できます。管理用スコープのIPマルチキャストの主要なプロパティは（i）です。管理用スコープのマルチキャストアドレス宛のパケットは、構成された管理境界を越えません。管理スコープのマルチキャストアドレスはローカルに割り当てられるため、管理境界を越えて一意である必要はありません。
The administratively scoped IPv4 multicast address space is defined to be the range 239.0.0.0 to 239.255.255.255.
管理用スコープのIPv4マルチキャストアドレススペースは、239.0.0.0〜239.255.255.255の範囲に定義されています。
In order to support administratively scoped IP multicast, a router should support the configuration of per-interface scoped IP multicast boundaries. Such a router, called a boundary router, does not forward packets matching an interface's boundary definition in either direction (the bi-directional check prevents problems with multi-access networks). In addition, a boundary router always prunes the boundary for dense-mode groups [PIMDM], and doesn't accept joins for sparse-mode groups [PIMSM] in the administratively scoped range.
管理用スコープのIPマルチキャストをサポートするには、ルーターがインターフェイスごとのスコープのIPマルチキャスト境界の構成をサポートする必要があります。境界ルーターと呼ばれるこのようなルーターは、インターフェイスの境界定義に一致するパケットをどちらの方向にも転送しません（双方向チェックにより、マルチアクセスネットワークの問題が防止されます）。さらに、境界ルーターは常に、稠密モードグループ[PIMDM]の境界をプルーニングし、管理スコープの範囲内の疎モードグループ[PIMSM]の結合を受け入れません。
The structure of the IP version 4 administratively scoped multicast space is loosely based on the IP Version 6 Addressing Architecture described in RFC 1884 [RFC1884]. This document defines two important scopes: the IPv4 Local Scope and IPv4 Organization Local Scope. These scopes are described below.
IPバージョン4の管理スコープマルチキャストスペースの構造は、RFC 1884 [RFC1884]で説明されているIPバージョン6アドレッシングアーキテクチャに大まかに基づいています。このドキュメントでは、IPv4ローカルスコープとIPv4組織ローカルスコープという2つの重要なスコープを定義しています。これらのスコープについて以下で説明します。
239.255.0.0/16 is defined to be the IPv4 Local Scope. The Local Scope is the minimal enclosing scope, and hence is not further divisible. Although the exact extent of a Local Scope is site dependent, locally scoped regions must obey certain topological constraints. In particular, a Local Scope must not span any other scope boundary. Further, a Local Scope must be completely contained within or equal to any larger scope. In the event that scope regions overlap in area, the area of overlap must be in its own local scope. This implies that any scope boundary is also a boundary for the Local Scope. The more general topological requirements for administratively scoped regions are discussed below.
239.255.0.0/16は、IPv4ローカルスコープとして定義されています。ローカルスコープは最小の包含スコープであるため、さらに分割できません。ローカルスコープの正確な範囲はサイトに依存しますが、ローカルスコープのリージョンは特定のトポロジー制約に従う必要があります。特に、ローカルスコープは他のスコープ境界をまたがってはなりません。さらに、ローカルスコープは、より大きなスコープ内に完全に含まれるか、同等である必要があります。スコープリージョンが領域でオーバーラップする場合、オーバーラップの領域は独自のローカルスコープ内にある必要があります。これは、スコープの境界がローカルスコープの境界でもあることを意味します。管理対象範囲のリージョンのより一般的なトポロジ要件については、以下で説明します。
6.1.1. Expansion of the IPv4 Local Scope
6.1.1. IPv4ローカルスコープの拡張
The IPv4 Local Scope space grows "downward". As such, the IPv4 Local Scope may grow downward from 239.255.0.0/16 into the reserved ranges 239.254.0.0/16 and 239.253.0.0/16. However, these ranges should not be utilized until the 239.255.0.0/16 space is no longer sufficient.
IPv4ローカルスコープスペースは「下方」に拡大します。そのため、IPv4ローカルスコープは、239.255.0.0 / 16から予約範囲239.254.0.0/16および239.253.0.0/16に下がる可能性があります。ただし、これらの範囲は、239.255.0.0 / 16のスペースが十分でなくなるまで使用しないでください。
239.192.0.0/14 is defined to be the IPv4 Organization Local Scope, and is the space from which an organization should allocate sub-ranges when defining scopes for private use.
239.192.0.0/14はIPv4組織のローカルスコープとして定義されており、私的使用のスコープを定義するときに組織がサブ範囲を割り当てる必要があるスペースです。
The ranges 239.0.0.0/10, 239.64.0.0/10 and 239.128.0.0/10 are unassigned and available for expansion of this space. These ranges should be left unassigned until the 239.192.0.0/14 space is no longer sufficient. This is to allow for the possibility that future revisions of this document may define additional scopes on a scale larger than organizations.
239.0.0.0/10、239.64.0.0/10、および239.128.0.0/10の範囲は割り当てられておらず、このスペースの拡張に使用できます。これらの範囲は、239.192.0.0 / 14スペースが十分でなくなるまで割り当てられないままにしておく必要があります。これは、このドキュメントの将来の改訂により、組織よりも大規模な追加のスコープが定義される可能性を考慮してです。
The other two scope classes of interest, statically assigned link-local scope and global scope already exist in IPv4 multicast space.
対象となる他の2つのスコープクラス、静的に割り当てられたリンクローカルスコープとグローバルスコープは、IPv4マルチキャストスペースにすでに存在しています。
The statically assigned link-local scope is 224.0.0.0/24. The existing static global scope allocations are somewhat more granular, and include
静的に割り当てられたリンクローカルスコープは224.0.0.0/24です。既存の静的なグローバルスコープの割り当てはやや細かく、以下を含みます
224.1.0.0-224.1.255.255 ST Multicast Groups 224.2.0.0-224.2.127.253 Multimedia Conference Calls 224.2.127.254 SAPv1 Announcements 224.2.127.255 SAPv0 Announcements (deprecated) 224.2.128.0-224.2.255.255 SAP Dynamic Assignments 224.252.0.0-224.255.255.255 DIS transient groups 232.0.0.0-232.255.255.255 VMTP transient groups
224.1.0.0-224.1.255.255 STマルチキャストグループ224.2.0.0-224.2.127.253マルチメディア電話会議224.2.127.254 SAPv1アナウンス224.2.127.255 SAPv0アナウンス（非推奨）224.2.128.0-224.2.255.255 SAP動的割り当て224.252.0.0-224.255.255.255 DIS一時グループ232.0.0.0-232.255.255.255 VMTP一時グループ
See [RFC1700] for current multicast address assignments (this list can also be found, possibly in a more current form, on ftp://ftp.isi.edu/in-notes/iana/assignments/multicast-addresses).
現在のマルチキャストアドレスの割り当てについては、[RFC1700]を参照してください（このリストは、ftp：//ftp.isi.edu/in-notes/iana/assignments/multicast-addressesで、おそらくより最新の形式で見つけることもできます）。
An administratively scoped IP multicast region is defined to be a topological region in which there are one or more boundary routers with common boundary definitions. Such a router is said to be a boundary for scoped addresses in the range defined in its configuration.
管理用スコープのIPマルチキャストリージョンは、共通の境界定義を持つ1つ以上の境界ルーターが存在するトポロジリージョンとして定義されます。このようなルーターは、その構成で定義された範囲のスコープアドレスの境界であると言われています。
Network administrators may configure a scope region whenever constrained multicast scope is required. In addition, an administrator may configure overlapping scope regions (networks can be in multiple scope regions) where convenient, with the only limitations being that a scope region must be connected (there must be a path between any two nodes within a scope region that doesn't leave that region), and convex (i.e., no path between any two points in the region can cross a region boundary). However, it is important to note that if administratively scoped areas intersect topologically, then the outer scope must consist of its address space minus the address spaces of any intersecting scopes. This requirement prevents the problem that would arise when a path between two points in a convex region crosses the boundary of an intersecting region. For this reason, it is recommended that administrative scopes that intersect topologically should not intersect in address range.
ネットワーク管理者は、制約付きマルチキャストスコープが必要な場合はいつでも、スコープ領域を構成できます。さらに、管理者は、重複するスコープ領域を構成することもできます（ネットワークは複数のスコープ領域にある場合があります）。ただし、スコープ領域を接続する必要があるという唯一の制限があります（スコープ領域内の2つのノード間にパスがなければなりません。 'その領域を離れない）、および凸面（つまり、領域内の任意の2点間のパスが領域境界を横切ることができない）。ただし、管理用スコープの領域がトポロジ的に交差する場合、外側のスコープはそのアドレススペースから、交差するスコープのアドレススペースを差し引いたものである必要があることに注意することが重要です。この要件により、凸領域の2点間のパスが交差領域の境界を横切るときに発生する問題が回避されます。このため、トポロジ的に交差する管理スコープは、アドレス範囲内で交差しないようにすることをお勧めします。
Finally, note that any scope boundary is a boundary for the Local Scope. This implies that packets sent to groups covered by 239.255.0.0/16 must not be forwarded across any link for which a scoped boundary is defined.
最後に、スコープの境界はローカルスコープの境界であることに注意してください。これは、239.255.0.0 / 16でカバーされるグループに送信されるパケットは、スコープ境界が定義されているリンクを介して転送されてはならないことを意味します。
The following table outlines the partitioning of the IPv4 multicast space, and gives the mapping from IPv4 multicast prefixes to IPv6 SCOP values:
次の表は、IPv4マルチキャストスペースのパーティション分割の概要を示し、IPv4マルチキャストプレフィックスからIPv6 SCOP値へのマッピングを示しています。
IPv6 SCOP RFC 1884 Description IPv4 Prefix
===============================================================
0 reserved
1 node-local scope
2 link-local scope 224.0.0.0/24
3 (unassigned) 239.255.0.0/16
4 (unassigned)
5 site-local scope
6 (unassigned)
7 (unassigned)
8 organization-local scope 239.192.0.0/14
A (unassigned)
B (unassigned)
C (unassigned)
D (unassigned)
E global scope 224.0.1.0-238.255.255.255
F reserved
(unassigned) 239.0.0.0/10
(unassigned) 239.64.0.0/10
(unassigned) 239.128.0.0/10
The high order /24 in every scoped region is reserved for relative assignments. A relative assignment is an integer offset from highest address in the scope and represents a 32-bit address (for IPv4). For example, in the Local Scope defined above, 239.255.255.0/24 is reserved for relative allocations. The de-facto relative assignment "0", (i.e., 239.255.255.255 in the Local Scope) currently exists for SAP [SAP]. The next relative assignment, "1", corresponds to the address 239.255.255.254 in the Local Scope. The rest of a scoped region below the reserved /24 is available for dynamic assignment (presumably by an address allocation protocol).
すべてのスコープ領域の高位/ 24は、相対的な割り当てのために予約されています。相対割り当ては、スコープの最上位アドレスからの整数オフセットであり、32ビットアドレスを表します（IPv4の場合）。たとえば、上記で定義したローカルスコープでは、239.255.255.0 / 24は相対割り当て用に予約されています。現在、SAP [SAP]には、事実上の相対割り当て「0」（つまり、ローカルスコープの239.255.255.255）が存在します。次の相対的な割り当て「1」は、ローカルスコープのアドレス239.255.255.254に対応します。 reserved / 24の下の残りのスコープ領域は、動的割り当てに使用できます（おそらくアドレス割り当てプロトコルによる）。
In is important to note that a scope discovery protocol [MZAP] will have to be developed to make practical use of scopes other than the Local Scope. In addition, since any use of any administratively scoped region, including the Local Scope, requires dynamically assigned addressing, an Address Allocation Protocol (AAP) will need to be developed to make administrative scoping generally useful.
ローカルスコープ以外のスコープを実際に使用するには、スコープ検出プロトコル[MZAP]を開発する必要があることに注意してください。さらに、ローカルスコープを含む管理用スコープの領域を使用するには、動的に割り当てられるアドレス指定が必要であるため、一般的に管理スコープを有効に活用するために、アドレス割り当てプロトコル（AAP）を開発する必要があります。
Requests for relative assignments should be directed to the IANA. The IANA will be advised by an area expert when making relative address assignments. The area expert will be appointed by the relevant Area Director.
相対的な割り当てのリクエストは、IANAに送信する必要があります。 IANAは、相対的なアドレス割り当てを行うときに、エリアの専門家からアドバイスを受けます。エリアエキスパートは、関連するエリアディレクターによって任命されます。
In general, relative addresses will be used only for bootstrapping to dynamic address assignments from within the scope. As such, relative assignments should only be made to those services that cannot use a dynamic address assignment protocol to find the address used by that service within the desired scope, such as a dynamic address assignment service itself.
一般に、相対アドレスは、スコープ内からの動的アドレス割り当てへのブートストラップにのみ使用されます。そのため、動的アドレス割り当てサービス自体など、目的のスコープ内でそのサービスが使用するアドレスを見つけるために動的アドレス割り当てプロトコルを使用できないサービスに対してのみ、相対的な割り当てを行う必要があります。
10. Security Considerations
10. セキュリティに関する考慮事項
It is recommended that organizations using the administratively scoped IP Multicast addresses not rely on them to prevent sensitive data from being transmitted outside the organization. Should a multicast router on an administrative boundary be mis-configured, have a bug in the administrative scoping code, or have other problems that would cause that router to forward an administratively scoped IP multicast packet outside of the proper scope, the organizations data would leave its intended transmission region.
機密データが組織の外部に送信されるのを防ぐために、管理用スコープのIPマルチキャストアドレスを使用する組織はそれらに依存しないことをお勧めします。管理境界上のマルチキャストルーターが正しく構成されていない、管理スコープコードにバグがある、またはそのルーターが管理スコープのIPマルチキャストパケットを適切なスコープ外に転送する原因となるその他の問題がある場合、組織のデータは残されますその意図された伝送領域。
Organizations using administratively scoped IP Multicasting to transmit sensitive data should use some confidentiality mechanism (e.g. encryption) to protect that data. In the case of many existing video-conferencing applications (e.g. vat), encryption is available as an application feature and merely needs to be enabled (and appropriate cryptographic keys securely distributed). For many other applications, the use of the IP Encapsulating Security Payload (ESP) [RFC-1825, RFC-1827] can provide IP-layer confidentiality though encryption.
管理スコープのIPマルチキャストを使用して機密データを送信する組織は、機密性メカニズム（暗号化など）を使用してそのデータを保護する必要があります。多くの既存のビデオ会議アプリケーション（VATなど）の場合、アプリケーションの機能として暗号化を利用でき、暗号化を有効にするだけで済みます（安全に配布される適切な暗号化キー）。他の多くのアプリケーションでは、IPカプセル化セキュリティペイロード（ESP）[RFC-1825、RFC-1827]を使用すると、暗号化によるIP層の機密性を提供できます。
Within the context of an administratively scoped IP multicast group, the use of manual key distribution might well be feasible. While dynamic key management for IP Security is a research area at the time this note is written, it is expected that the IETF will be extending the ISAKMP key management protocol to support scalable multicast key distribution in the future.
管理用スコープのIPマルチキャストグループのコンテキスト内では、手動でのキー配布の使用が十分に可能です。このセキュリティ情報の執筆時点では、IPセキュリティの動的キー管理は研究分野ですが、IETFはISAKMPキー管理プロトコルを拡張して、将来的にスケーラブルなマルチキャストキー配布をサポートする予定です。
It is important to note that the "boundary router" described in this note is not necessarily providing any kind of firewall capability.
このノートで説明されている「境界ルーター」は、必ずしもあらゆる種類のファイアウォール機能を提供しているわけではないことに注意することが重要です。
[ASMA] V. Jacobson, S. Deering, "Administratively Scoped IP Multicast", presented at the 30th IETF, Toronto, Canada, 25 July 1994.
[ASMA] V. Jacobson、S。Deering、「Administratively Scoped IP Multicast」、1994年7月25日、カナダ、トロントの第30回IETFで発表。
[DVMRP] Pusateri, T., "Distance Vector Multicast Routing Protocol", Work in Progress.
[DVMRP] Pusateri、T。、「Distance Vector Multicast Routing Protocol」、作業中。
[MZAP] Handley, M., "Multicast-Scope Zone Announcement Protocol (MZAP)", Work in Progress.
[MZAP] Handley、M。、「Multicast-Scope Zone Announcement Protocol（MZAP）」、作業中。
[PIMDM] Deering, S, et. al., "Protocol Independent Multicast Version 2, Dense Mode Specification", Work in Progress.
[PIMDM] Deering、S、他その他、「Protocol Independent Multicast Version 2、Dense Mode Specification」、Work in Progress。
[PIMSM] Estrin, D., Farinacci, D., Helmy, A., Thaler, D., Deering, S., Handley, M., Jacobson, V., Liu, C., Sharma, P., and L. Wei, "Protocol Independent Multicast Sparse Mode (PIM-SM): Protocol Specification", RFC 2362, June 1998.
[PIMSM] Estrin、D.、Farinacci、D.、Helmy、A.、Thaler、D.、Deering、S.、Handley、M.、Jacobson、V.、Liu、C.、Sharma、P。、およびL Wei、「Protocol Independent Multicast Sparse Mode（PIM-SM）：Protocol Specification」、RFC 2362、1998年6月。
[RFC1700] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[RFC1700] Reynolds、J。、およびJ. Postel、「Assigned Numbers」、STD 2、RFC 1700、1994年10月。
[RFC1884] Hinden. R., and S. Deering, "IP Version 6 Addressing Architecture", RFC1884, December 1995.
[RFC1884]ヒンデン。 R.、およびS. Deering、「IP Version 6 Addressing Architecture」、RFC1884、1995年12月。
[SAP] Handley, M., "SAP: Session Announcement Protocol", Work in Progress.
[SAP] Handley、M。、「SAP：Session Announcement Protocol」、Work in Progress。
David Meyer Cisco Systems San Jose, CA
David Meyer Cisco Systemsカリフォルニア州サンノゼ
EMail: dmm@cisco.com
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright（C）The Internet Society（1998）。全著作権所有。
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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。