[要約] RFC 2337は、ATM上のルータ間でのSparse Mode PIMを使用したIntra-LIS IPマルチキャストに関する規格です。このRFCの目的は、ATMネットワーク内でのIPマルチキャストの効率的な配信を実現するための手法を提案することです。
Network Working Group D. Farinacci
Request for Comments: 2337 Cisco Systems
Category: Experimental D. Meyer
Cisco Systems
Y. Rekhter
Cisco Systems
April 1998
Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM
スパースモードPIMを使用した、ATM上のルーター間のLIS内IPマルチキャスト
Status of this Memo
本文書の状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. 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 describes how intra-LIS IP multicast can be efficiently supported among routers over ATM without using the Multicast Address Resolution Server (MARS). The method described here is specific to Sparse Mode PIM [PIM-SM], and relies on the explicit join mechanism inherent in PIM-SM to notify routers when they should create group specific point-to-multipoint VCs.
このドキュメントでは、マルチキャストアドレス解決サーバー（MARS）を使用せずに、LIS内IPマルチキャストをATM上のルーター間で効率的にサポートする方法について説明します。ここで説明する方法は、スパースモードPIM [PIM-SM]に固有のものであり、PIM-SMに固有の明示的な参加メカニズムに依存して、グループ固有のポイントツーマルチポイントVCを作成する必要があるときにルーターに通知します。
This document focuses on forwarding of multicast traffic among PIM-SM routers connected to an ATM network. Routers on an ATM network are partitioned into Logical IP Subnets, or LISs. This document deals with handling multicast within a single LIS. Handling inter-LIS multicast traffic, including handling shortcuts, is outside the scope of this document. In addition, this document does not address forwarding of multicast traffic to or from hosts connected to an ATM network.
このドキュメントでは、ATMネットワークに接続されたPIM-SMルータ間でのマルチキャストトラフィックの転送に焦点を当てています。 ATMネットワーク上のルーターは、論理IPサブネット（LIS）に分割されます。このドキュメントでは、単一のLIS内でマルチキャストを処理する方法について説明します。ショートカットの処理を含むLIS間マルチキャストトラフィックの処理は、このドキュメントの範囲外です。さらに、このドキュメントでは、ATMネットワークに接続されたホストとの間のマルチキャストトラフィックの転送については扱いません。
This document requires that each router within a LIS knows IP and ATM addresses of all other routers within the LIS. The mapping between IP and ATM addresses may be provided by an ARP server [RFC2225], or by any other means (e.g., static configuration).
このドキュメントでは、LIS内の各ルーターがLIS内の他のすべてのルーターのIPアドレスとATMアドレスを認識している必要があります。 IPアドレスとATMアドレス間のマッピングは、ARPサーバー[RFC2225]によって、またはその他の手段（静的構成など）によって提供されます。
Each PIM router within a LIS is required to maintain a single (shared) point-to-multipoint distribution VC rooted at the router with all other PIM routers in the LIS as the leaf nodes. The VC is expected to be used for forwarding of multicast traffic (both data and control) among routers within the LIS. For example, this VC would be used for distributing PIM [PIM-SM] control messages (Join/Prune messages).
LIS内の各PIMルーターは、LIS内の他のすべてのPIMルーターをリーフノードとして、ルーターをルートとする単一（共有）ポイントツーマルチポイント分散VCを維持する必要があります。 VCは、LIS内のルーター間のマルチキャストトラフィック（データと制御の両方）の転送に使用されることが期待されています。たとえば、このVCは、PIM [PIM-SM]制御メッセージ（Join / Pruneメッセージ）の配信に使用されます。
In addition, if a PIM router receives a IGMP report from an non-PIM neighbor, then the router may add the reporter to the existing shared distribution VC or to the group specific distribution VC (if it exists). The PIM router may also create a specific VC for this IGMP proxy.
さらに、PIMルーターが非PIMネイバーからIGMPレポートを受信した場合、ルーターは既存の共有配布VCまたはグループ固有の配布VC（存在する場合）にレポーターを追加できます。 PIMルーターは、このIGMPプロキシに対して特定のVCを作成することもあります。
Routers may also maintain group specific, dedicated point-to-multipoint VCs. In particular, an upstream router for a group may choose to become the root of a group specific point-to-multipoint VC whose leaves are the downstream routers that have directly connected or downstream receivers for the group. While the criteria for establishing a group specific point-to-multipoint VC are local to a router, issues such as the volume of traffic associated with the group and the fanout factor within the LIS should be considered. Finally, note that a router must minimally support a single shared point-to-multipoint VC for distribution of control messages and data (to all group addresses).
ルーターは、グループ固有の専用ポイントツーマルチポイントVCも維持できます。特に、グループのアップストリームルータは、グループに直接接続されたダウンストリームルータまたはグループのダウンストリームレシーバーをリーフとするグループ固有のポイントツーマルチポイントVCのルートになることを選択できます。グループ固有のポイントツーマルチポイントVCを確立するための基準はルーターに対してローカルですが、グループに関連付けられたトラフィックの量やLIS内のファンアウト係数などの問題を考慮する必要があります。最後に、制御メッセージとデータを（すべてのグループアドレスに）配信するために、ルーターは単一の共有ポイントツーマルチポイントVCを最低限サポートする必要があることに注意してください。
A router can choose to establish a dedicated point-to-multipoint VC (or add another leaf to an already established dedicated point-to-multipoint VC) when it receives a PIM Join or IGMP report messages from another device in the same LIS. When a router that is the root of a point-to-multipoint VC receives PIM Prune message or IGMP leave, it removes the originator of the message from its dedicated point-to-multipoint VC.
ルータは、同じLIS内の別のデバイスからPIM加入またはIGMPレポートメッセージを受信したときに、専用のポイントツーマルチポイントVCを確立する（またはすでに確立されている専用のポイントツーマルチポイントVCに別のリーフを追加する）ことを選択できます。ポイントツーマルチポイントVCのルートであるルーターがPIM PruneメッセージまたはIGMP脱退を受信すると、専用のポイントツーマルチポイントVCからメッセージの発信者を削除します。
If at least one of the routers within a LIS decides to switch to a source-rooted tree (by sending (S,G) PIM Joins), then all other routers within the LIS that have downstream members for G should switch to that source-rooted tree as well. Since a router that switches to a source-rooted tree sends PIM Join messages for (S,G) over its shared point-to-multipoint VC, the other routers within the LIS are able to detect this. Once a router that has downstream members for G detects this, the router should send (S,G) PIM Join message as well (otherwise the router may receive duplicate traffic from S).
LIS内の少なくとも1つのルーターが（S、G）PIM結合を送信することによってソースルートツリーに切り替えることを決定した場合、Gのダウンストリームメンバーを持つLIS内の他のすべてのルーターは、そのソースに切り替える必要があります。同様に根ざした木。ソースルートツリーに切り替わるルーターは、共有ポイントツーマルチポイントVCを介して（S、G）のPIM加入メッセージを送信するため、LIS内の他のルーターはこれを検出できます。 Gのダウンストリームメンバーを持つルーターがこれを検出すると、ルーターは（S、G）PIM加入メッセージも送信する必要があります（そうでない場合、ルーターはSから重複したトラフィックを受信する可能性があります）。
Note that it is possible for a non-PIM router in the LIS to fail to receive data if the injection point moves to router to which there is not an existing VC.
インジェクションポイントが既存のVCがないルーターに移動した場合、LISの非PIMルーターがデータを受信できない可能性があることに注意してください。
As mentioned above, this document requires that once one router in a LIS decides to switch to the source tree for some (S,G), all routers in the LIS that have downstream members must also switch to the (S,G) source tree. Now, when a new router wants to receive traffic from G, it starts sending (*,G)-Joins on it's shared point-to-multipoint VC toward the RP for G. The root of the (S,G)-source-rooted tree will know to add the new router to the point-to-multipoint VC servicing the (S,G)-source-rooted tree by observing the (*,G)-joins on it's shared point-to-multipoint VC. However, the new router must also switch to the (S,G)-source-rooted tree. In order to accomplish this, the newly added router must:
上記のように、このドキュメントでは、LISの1つのルーターが（S、G）のソースツリーに切り替えることを決定すると、ダウンストリームメンバーを持つLISのすべてのルーターも（S、G）ソースツリーに切り替える必要があります。これで、新しいルーターがGからトラフィックを受信する場合、（*、G）-Joinの共有ポイントツーマルチポイントVCへの参加をGのRPに向けて送信し始めます。（S、G）-source-のルートルートツリーは、共有ルーターの（*、G）-joinを監視することで、（S、G）-source-rootedツリーにサービスを提供するポイントツーマルチポイントVCに新しいルーターを追加することを認識します。ただし、新しいルーターも（S、G）ソースルートツリーに切り替える必要があります。これを実現するために、新しく追加されたルーターは次の条件を満たす必要があります。
(i). Notice that it has been added to a new point-to-multipoint VC
（私）。新しいポイントツーマルチポイントVCに追加されていることに注意してください。
(ii). Notice (S,G) traffic coming down this new point-to-multipoint VC
（ii）。この新しいポイントツーマルチポイントVCに到達する（S、G）トラフィックに注意してください
(iii). Send (S,G) joins toward S, causing it to switch to the source-rooted tree. The router learns that the VC is used to distribute (S,G) traffic in the previous steps.
（iii）。送信（S、G）はSに参加し、ソースルートツリーに切り替えます。ルータは、前のステップで（S、G）トラフィックを分散するためにVCが使用されていることを学習します。
When a router receives a multicast packet from another router in its own LIS, the router should not send the packet on any of the routers distribution point-to-multipoint VCs associate with the LIS. This eliminates the problem of "packet reflection". Sending the packet on the routers' distribution VCs associated with other LISs is controlled by the multicast routing procedures.
ルーターが自身のLIS内の別のルーターからマルチキャストパケットを受信する場合、ルーターは、LISに関連付けられているルーター配布ポイントツーマルチポイントVCでパケットを送信しないでください。これにより、「パケット反射」の問題が解消されます。他のLISに関連付けられたルーターの配布VCでのパケットの送信は、マルチキャストルーティング手順によって制御されます。
The intra-LIS multicast scheme described in this document is intended to be a less complex solution to an important subset of the functionality provided by the Multicast Address Resolution Server, or MARS [MARS]. In particular, it is designed to provide intra-LIS multicast between routers using PIM-SM, and does not consider the case of host-rooted point-to-multicast multicast distribution VCs.
このドキュメントで説明されているLIS内マルチキャストスキームは、マルチキャストアドレス解決サーバー（MARS [MARS]）によって提供される機能の重要なサブセットに対するそれほど複雑ではないソリューションになることを目的としています。特に、PIM-SMを使用してルーター間にLIS内マルチキャストを提供するように設計されており、ホストをルートとするポイントツーマルチキャストマルチキャスト配布VCの場合は考慮されていません。
Although MARS supports both of the current schemes for mapping the IP multicast service model to ATM (multicast server and meshes of point-to-multipoint VCs), it does so at at cost and complexity higher than of the scheme described in this document. In addition, MARS requires new encapsulations, whereas this proposal works with either LLC/SNAP or with NLPID encapsulation. Another important difference is that MARS allows point-to-multipoint VCs rooted either at a source or at a multicast server (MCS). The approach taken here is to constrain complexity by focusing on PIM-SM (taking advantage of information available in explicit joins), and by allowing point-to-multipoint VCs to be rooted only at the routers (which is roughly analogous to the complexity and functionality of rooting point-to-multipoint VCs at the sources).
MARSは、IPマルチキャストサービスモデルをATMにマッピングするための現在のスキーム（マルチキャストサーバーとポイントツーマルチポイントVCのメッシュ）の両方をサポートしますが、このドキュメントで説明されているスキームよりもコストと複雑さが高くなります。さらに、MARSには新しいカプセル化が必要ですが、この提案はLLC / SNAPまたはNLPIDカプセル化のいずれかで機能します。もう1つの重要な違いは、MARSでは、ソースまたはマルチキャストサーバー（MCS）をルートとするポイントツーマルチポイントVCが許可されることです。ここで採用されているアプローチは、PIM-SMに焦点を合わせ（明示的な結合で利用可能な情報を利用する）、ポイントツーマルチポイントVCをルーターでのみルートできるようにすることで複雑さを制限することです（これは、複雑さとほぼ同じです）。ソースでポイントツーマルチポイントVCをルート化する機能）。
In summary, the method described in this document is designed for the router-to-router case, and takes advantage of the explicit-join mechanism inherent in PIM-SM to provide a simple mechanism for intra-LIS multicast between routers. MARS, on the other hand, accepts different tradeoffs in complexity-functionality design space. In particular, while the MARS paradigm provides a general neighbor discovery mechanism, allows host to participate, and is protocol independent, it does so at considerable cost.
要約すると、このドキュメントで説明する方法は、ルーター間での使用を想定して設計されており、PIM-SMに固有の明示的結合メカニズムを利用して、ルーター間のLISマルチキャスト用のシンプルなメカニズムを提供します。一方、MARSは、複雑さ-機能性の設計空間におけるさまざまなトレードオフを受け入れます。特に、MARSパラダイムは一般的なネイバー探索メカニズムを提供し、ホストの参加を可能にし、プロトコルに依存しませんが、かなりのコストがかかります。
In general, the security issues relevant to the proposal outlined in the memo are subsumed by those faced by PIM-SM. While work in proceeding on security for PIM-SM, it is worthwhile noting that several issues have been raised in conjunction with multicast routing and with PIM-SM in particular. These issues include but are not limited to:
一般に、メモで概説されている提案に関連するセキュリティ問題は、PIM-SMが直面する問題に含まれます。 PIM-SMのセキュリティに関する作業を進めていますが、マルチキャストルーティング、特にPIM-SMに関連していくつかの問題が発生していることに注意してください。これらの問題には以下が含まれますが、これらに限定されません。
(i). Unauthorized Senders
（私）。無許可の送信者
(ii). Unauthorized Receivers
（ii）。無許可の受信者
(iii). Unauthorized use of the RP
（iii）。 RPの不正使用
(iv). Unauthorized "last hop" switching to shortest path tree.
（iv）。不正な「ラストホップ」が最短パスツリーに切り替わります。
Historically, routing protocols used within the Internet have lacked strong authentication mechanisms [RFC1704]. In the late 1980s, analysis revealed that there were a number of security problems in Internet routing protocols then in use [BELLOVIN89]. During the early 1990s it became clear that adversaries were selectively attacking various intra-domain and inter-domain routing protocols (e.g. via TCP session stealing of BGP sessions) [CERTCA9501, RFC1636]. More recently, cryptographic authentication mechanisms have been developed for RIPv2, OSPF, and the proprietary EIGRP routing protocols. BGP protection, in the form of a Keyed MD5 option for TCP, has also become widely deployed.
従来、インターネット内で使用されるルーティングプロトコルには、強力な認証メカニズムがありませんでした[RFC1704]。 1980年代後半の分析により、当時使用されていたインターネットルーティングプロトコルに多数のセキュリティ問題があることが明らかになりました[BELLOVIN89]。 1990年代の初めに、敵がさまざまなドメイン内およびドメイン間ルーティングプロトコルを選択的に攻撃していることが明らかになりました（たとえば、BGPセッションのTCPセッション盗用を介して）[CERTCA9501、RFC1636]。最近では、RIPv2、OSPF、および独自のEIGRPルーティングプロトコル用の暗号化認証メカニズムが開発されました。 TCP用のキー付きMD5オプションの形式のBGP保護も、広く導入されています。
At present, most multicast routing protocols lack strong cryptographic protection. One possible approach to this is to incorporate a strong cryptographic protection mechanism (e.g. Keyed HMAC MD5 [RFC2104]) within the routing protocol itself. Alternately, the routing protocol could be designed and specified to use the IP Authentication Header (AH) [RFC1825, RFC1826, RFC2085] to provide cryptographic authentication.
現在、ほとんどのマルチキャストルーティングプロトコルには強力な暗号化保護機能がありません。これに対する1つの可能なアプローチは、ルーティングプロトコル自体に強力な暗号化保護メカニズム（Keyed HMAC MD5 [RFC2104]など）を組み込むことです。あるいは、ルーティングプロトコルは、IP認証ヘッダー（AH）[RFC1825、RFC1826、RFC2085]を使用して暗号化認証を提供するように設計および指定できます。
Because the intent of any routing protocol is to propagate routing information to other parties, confidentiality is not generally required in routing protocols. In those few cases where local security policy might require confidentiality, the use of the IP Encapsulating Security Payload (ESP) [RFC1825, RFC1827] is recommended.
ルーティングプロトコルの目的はルーティング情報を他の関係者に伝達することであるため、ルーティングプロトコルでは通常、機密性は必要ありません。ローカルセキュリティポリシーで機密性が要求される可能性があるいくつかのケースでは、IPカプセル化セキュリティペイロード（ESP）[RFC1825、RFC1827]の使用をお勧めします。
Scalable dynamic multicast key management is an active research area at this time. Candidate technologies for scalable dynamic multicast key management include CBT-based key management [RFC1949] and the Group Key Management Protocol (GKMP) [RFC2093,RFC2094]. The IETF IP Security Working Group is actively working on GKMP extensions to the standards-track ISAKMP key management protocol being developed in the same working group.
スケーラブルな動的マルチキャストキー管理は、現時点で活発な研究分野です。スケーラブルな動的マルチキャストキー管理の候補となるテクノロジーには、CBTベースのキー管理[RFC1949]とグループキー管理プロトコル（GKMP）[RFC2093、RFC2094]があります。 IETF IPセキュリティワーキンググループは、同じワーキンググループで開発されている標準化過程のISAKMPキー管理プロトコルのGKMP拡張に積極的に取り組んでいます。
[BELLOVIN89] S. Bellovin, "Security Problems in the TCP/IP Protocol Suite", ACM Computer Communications Review, Volume 19, Number 2, pp. 32-48, April 1989.
[BELLOVIN89] S. Bellovin、「TCP / IPプロトコルスイートのセキュリティ問題」、ACM Computer Communications Review、Volume 19、Number 2、32-48ページ、1989年4月。
[CERTCA9501] CERT, "IP Spoofing Attacks and Hijacked Terminal Connections", ftp://ftp.cert.org/cert_advisories/, January 1995.
[CERTCA9501] CERT、「IPスプーフィング攻撃とハイジャックされた端末接続」、ftp：//ftp.cert.org/cert_advisories/、1995年1月。
[MARS] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM Networks.", RFC 2022, November 1996.
[MARS]アーミテージ、G。、「UNI 3.0 / 3.1ベースのATMネットワーク上のマルチキャストのサポート。」、RFC 2022、1996年11月。
[PIM-SM] Estrin, D, et. al., "Protocol Independent Multicast Sparse Mode (PIM-SM): Protocol Specification", Work in Progress.
[PIM-SM]エストリン、D、他al。、「Protocol Independent Multicast Sparse Mode（PIM-SM）：Protocol Specification」、作業中。
[RFC1636] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report of IAB Workshop on Security in the Internet Architecture February 8-10, 1994", RFC 1636, June 1994.
[RFC1636]ブレーデン、R。、クラーク、D。、クロッカー、S。、およびC.ウイテマ、「インターネットアーキテクチャにおけるセキュリティに関するIABワークショップのレポート、1994年2月8〜10日」、RFC 1636、1994年6月。
[RFC1704] Haller, N., and R. Atkinson, "On Internet Authentication", RFC 1704, October 1994.
[RFC1704] Haller、N。、およびR. Atkinson、「On Internet Authentication」、RFC 1704、1994年10月。
[RFC1825] Atkinson, R., "IP Security Architecture", RFC 1825, August 1995.
[RFC1825] Atkinson、R。、「IP Security Architecture」、RFC 1825、1995年8月。
[RFC1826] Atkinson, R., "IP Authentication Header", RFC 1826, August 1995.
[RFC1826] Atkinson、R。、「IP Authentication Header」、RFC 1826、1995年8月。
[RFC1827] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827, August 1995.
[RFC1827] Atkinson、R。、「IP Encapsulating Security Payload」、RFC 1827、1995年8月。
[RFC1949] Ballardie, A., "Scalable Multicast Key Distribution", RFC1949, June 1996.
[RFC1949] Ballardie、A。、「Scalable Multicast Key Distribution」、RFC1949、1996年6月。
[RFC2085] Oehler, M., and R. Glenn, "HMAC-MD5 IP Authentication with Replay Prevention", RFC 2085, February 1997.
[RFC2085] Oehler、M。、およびR. Glenn、「HMAC-MD5 IP Authentication with Replay Prevention」、RFC 2085、1997年2月。
[RFC2093] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Specification", RFC 2093, July 1997.
[RFC2093] Harney、H。、およびC. Muckenhirn、「Group Key Management Protocol（GKMP）Specification」、RFC 2093、1997年7月。
[RFC2094] Harney, H., and C. Muckenhirn, "Group Key Management Protocol (GKMP) Architecture", RFC 2094, July 1997.
[RFC2094] Harney、H。、およびC. Muckenhirn、「Group Key Management Protocol（GKMP）Architecture」、RFC 2094、1997年7月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. Canetti、「HMAC：Keyed Hashing for Message Authentication」、RFC 2104、1997年2月。
[RFC2225] Laubach, M., and J. Halpern, "Classical IP and ARP over ATM", RFC 2225, April 1998.
[RFC2225] Laubach、M。、およびJ. Halpern、「Classical IP and ARP over ATM」、RFC 2225、1998年4月。
Petri Helenius provided several insightful comments on earlier versions of this document.
Petri Heleniusは、このドキュメントの以前のバージョンについていくつかの洞察に満ちたコメントを提供しました。
Dino Farinacci Cisco Systems 170 Tasman Dr. San Jose, CA 95134
Dino Farinacci Cisco Systems 170 Tasman Dr. San Jose、CA 95134
Phone: (408) 526-4696 EMail: dino@cisco.com
電話：（408）526-4696メール：dino@cisco.com
David Meyer Cisco Systems 170 Tasman Dr. San Jose, CA 95134
David Meyer Cisco Systems 170 Tasman Dr. San Jose、CA 95134
Phone: (541) 687-2581 EMail: dmm@cisco.com
電話：（541）687-2581メール：dmm@cisco.com
Yakov Rekhter cisco Systems, Inc. 170 Tasman Dr. San Jose, CA 95134
Yakov Rekhter cisco Systems、Inc. 170 Tasman Dr. San Jose、CA 95134
Phone: (914) 528-0090 EMail: yakov@cisco.com
電話：（914）528-0090メール：yakov@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.
このドキュメントとここに含まれる情報は「現状有姿」で提供され、インターネット社会およびインターネット技術タスクフォースは、明示または黙示を問わず、ここに記載されている情報の使用が保証するものに限定されないいかなる保証も含め、一切の保証を否認します。商品性または特定の目的への適合性に関する権利または黙示の保証を侵害すること。