RFC3446 日本語訳
3446 Anycast Rendevous Point (RP) mechanism using Protocol IndependentMulticast (PIM) and Multicast Source Discovery Protocol (MSDP). D.Kim, D. Meyer, H. Kilmer, D. Farinacci. January 2003. (Format: TXT=14792 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Kim Request for Comments: 3446 Verio Category: Informational D. Meyer H. Kilmer D. Farinacci Procket Networks January 2003
コメントを求めるワーキンググループD.キムの要求をネットワークでつないでください: 3446年のVerioカテゴリ: 情報のD.のマイヤーH.キルマーD.ファリナッチProcketは2003年1月をネットワークでつなぎます。
Anycast Rendevous Point (RP) mechanism using Protocol Independent Multicast (PIM) and Multicast Source Discovery Protocol (MSDP)
プロトコル無党派Multicast(PIM)とMulticast Sourceディスカバリープロトコルを使用するAnycast Rendevous Point(RP)メカニズム(MSDP)
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
This document describes a mechanism to allow for an arbitrary number of Rendevous Points (RPs) per group in a single shared-tree Protocol Independent Multicast-Sparse Mode (PIM-SM) domain.
このドキュメントは、ただ一つの共有された木のプロトコル無党派のMulticastまばらなMode(PIM-SM)ドメインで1グループあたりのRendevous Points(RPs)の特殊活字の数字を考慮するためにメカニズムについて説明します。
1. Introduction
1. 序論
PIM-SM, as defined in RFC 2362, allows for only a single active RP per group, and as such the decision of optimal RP placement can become problematic for a multi-regional network deploying PIM-SM.
グループ、最適のRPプレースメントのそのような決定がマルチ地域ネットワークに問題が多くなることができるようにRFC2362で定義されるPIM-SMは、PIM-SMを配備しながら、独身のアクティブなRPだけを考慮します。
Anycast RP relaxes an important constraint in PIM-SM, namely, that there can be only one group to RP mapping can be active at any time. The single mapping property has several implications, including traffic concentration, lack of scalable register decapsulation (when using the shared tree), slow convergence when an active RP fails, possible sub-optimal forwarding of multicast packets, and distant RP dependencies. These properties of PIM-SM have been demonstrated in native continental or inter-continental scale multicast deployments. As a result, it is clear that ISP backbones require a mechanism that allows definition of multiple active RPs per group in a single PIM-SM domain. Further, any such mechanism should also address the issues addressed above.
Anycast RPはPIM-SMで重要な規制を弛緩して、そこですなわち、それはそうであることができます。RPマッピングへの1つのグループだけがいつでも、活動的である場合があります。 ただ一つのマッピングの特性に、いくつかの意味があります、交通集中、スケーラブルなレジスタ被膜剥離術(共有された木を使用するとき)の不足、アクティブなRPが失敗するときの遅い集合、マルチキャストパケットの可能なサブ最適の推進、および冷ややかなRPの依存を含んでいて。 PIM-SMのこれらの特性はネイティブの自制的であるか大陸間なスケールマルチキャスト展開でデモをしました。 その結果、ISP背骨がただ一つのPIM-SMドメインで複数の1グループあたりのアクティブなRPsの定義を許すメカニズムを必要とするのは、明確です。 また、さらに、どんなそのようなメカニズムも上に記述された問題を記述するはずです。
Kim, et al. Informational [Page 1] RFC 3446 Anycast RP mechanism using PIM and MSDP January 2003
キム、他 2003年1月にPIMとMSDPを使用する情報[1ページ]のRFC3446Anycast RPメカニズム
The mechanism described here is intended to address the need for better fail-over (convergence time) and sharing of the register decapsulation load (again, when using the shared-tree) among RPs in a domain. It is primarily intended for applications within those networks using MBGP, Multicast Source Discovery Protocol [MSDP] and PIM-SM protocols, for native multicast deployment, although it is not limited to those protocols. In particular, Anycast RP is applicable in any PIM-SM network that also supports MSDP (MSDP is required so that the various RPs in the domain maintain a consistent view of the sources that are active). Note however, a domain deploying Anycast RP is not required to run MBGP. Finally, a general requirement of the Anycast RP scheme is that the anycast address MUST NOT be used as the RP address in the RP's SA messages.
ここで説明されたメカニズムは、ドメインで、より良いフェイルオーバー(集合時間)の必要性を記述することを意図して、RPsの中でレジスタ被膜剥離術負荷(再び共有された木を使用するとき)を共有しています。 それはアプリケーションのためにそれらのネットワークの中でMBGP、Multicast Sourceディスカバリープロトコル[MSDP]、およびPIM-SMプロトコルを使用することで主として意図します、ネイティブのマルチキャスト展開のために、それはそれらのプロトコルに制限されませんが。 Anycast RPはまた、MSDPを支持するどんなPIM-SMネットワークでも特に、適切です(MSDPが必要であるので、そのドメインの様々なRPsは活発なソースの一貫した視点を維持します)。 しかしながら、Anycast RPを配備するドメインはMBGPを走らせるのに必要でないことに注意してください。 最終的に、Anycast RP計画の一般的な要件はRPアドレスとしてRPのSAメッセージでanycastアドレスを使用してはいけないということです。
The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED, SHALL, SHALL NOT, SHOULD, SHOULD NOT are to be interpreted as defined in BCP 14, RFC 2119 [RFC2119].
キーワードが解釈しなければならない、BCP14RFC2119[RFC2119]で定義されるようにNOT、5月、OPTIONAL、REQUIRED、RECOMMENDED、SHALL、SHALL NOT、SHOULD、SHOULD NOTを解釈することになっていなければなりません。
2. Problem Definition
2. 問題定義
The anycast RP solution provides a solution for both fast fail-over and shared-tree load balancing among any number of active RPs in a domain.
anycast RP解決策は速いフェイルオーバーとドメインのいろいろなアクティブなRPsの中の共有された木のロードバランシングの両方の解決法を提供します。
2.1. Traffic Concentration and Distributing Decapsulation Load Among RPs
2.1. 交通集中と被膜剥離術を分配するのはRPsの中でロードされます。
While PIM-SM allows for multiple RPs to be defined for a given group, only one group to RP mapping can be active at a given time. A traditional deployment mechanism for balancing register decapsulation load between multiple RPs covering the multicast group space is to split up the 224.0.0.0/4 space between multiple defined RPs. This is an acceptable solution as long as multicast traffic remains low, but has problems as multicast traffic increases, especially because the network operator defining group space split between RPs does not always have a priori knowledge of traffic distribution between groups. This can be overcome via periodic reconfigurations, but operational considerations cause this type of solution to scale poorly.
PIM-SMが、複数のRPsが与えられたグループのために定義されるのを許容する間、RPマッピングへの1つのグループだけが一時に活動的である場合があります。 マルチキャストグループスペースをカバーするのがある複数のRPsの間のバランスをとることのレジスタ被膜剥離術負荷のための伝統的な展開メカニズムは複数の定義されたRPsの間の.0.0/4スペースを224.0に分けました。 これには、マルチキャスト交通が低いままで残っている限り、許容できる解決策ですが、マルチキャスト交通が増加するのに従って、問題があります、特にRPsの間で分けられたグループスペースを定義するネットワーク・オペレータがグループの間にいつもトラヒック分配に関する先験的な知識を持っているというわけではないので。 周期的な再構成でこれに打ち勝つことができますが、操作上の問題で、このタイプの解決は不十分に比例します。
2.2. Sub-optimal Forwarding of Multicast Packets
2.2. マルチキャストパケットのサブ最適の推進
When a single RP serves a given multicast group, all joins to that group will be sent to that RP regardless of the topological distance between the RP and the sources and receivers. Initial data will be sent towards the RP also until configured the shortest path tree switch threshold is reached, or the data will always be sent towards the RP if the network is configured to always use the RP rooted shared tree. This holds true even if all the sources and the
RPと、ソースと受信機の間の位相的な距離にかかわらずRPが与えられたマルチキャストグループに役立って、すべて接合する分類されるシングルをそのRPに送るとき。 初期のデータをRPに向かって送るでしょう、また、最短パス木のスイッチ敷居は構成されるまで届いています、または、いつもRP根づいている共有された木を使用するためにネットワークを構成するなら、いつもRPに向かってデータを送るでしょう。 そしてこれが有効である、すべてのソース。
Kim, et al. Informational [Page 2] RFC 3446 Anycast RP mechanism using PIM and MSDP January 2003
キム、他 2003年1月にPIMとMSDPを使用する情報[2ページ]のRFC3446Anycast RPメカニズム
receivers are in any given single region, and RP is topologically distant from the sources and the receivers. This is an artifact of the dynamic nature of multicast group members, and of the fact that operators may not always have a priori knowledge of the topological placement of the group members.
ただ一つの領域を考えて、受信機はそうです、そして、どんなもRPは位相的にそうです。ソースと受信機から、遠方です。 これはマルチキャストグループのメンバーのダイナミックな自然、およびオペレータにはグループのメンバーの位相的なプレースメントに関する先験的な知識がいつもあるかもしれないというわけではないという事実の人工物です。
Taken together, these effects can mean that (for example) although all the sources and receivers of a given group are in Europe, they are joining towards the RP in the USA and the data will be traversing a relatively expensive pipe(s) twice, once to get to RP, and back down the RP rooted tree again, creating inefficient use of expensive resources.
一緒に取って、これらの効果は、再びRPの根づいている木にRP、および後部に着くように一度(例えば、)与えられたグループのすべてのソースと受信機がヨーロッパにありますが、米国のRPに向かって接合していて、データが二度比較的高価なパイプを横断することを意味できます、高価なリソースの効率の悪い使用を作成して。
2.3. Distant RP Dependencies
2.3. 冷ややかなRPの依存
As outlined above, a single active RP per group may cause local sources and receivers to become dependent on a topologically distant RP. In addition, when multiple RPs are configured, there can be considerable convergence delay involved in switching to the backup RP. This delay may exist independent of the toplogical location of the primary and backup RPs.
地元筋と受信機が上に概説されているように1グループあたり1独身のアクティブなRPによって依存するようになるかもしれない、位相的である、遠方のRP 複数のRPsが構成されるとき、さらに、バックアップRPに切り替わるのにかかわるかなりの集合遅れがあることができます。 この遅れは予備選挙とバックアップRPsのtoplogical位置の如何にかかわらず存在するかもしれません。
3. Solution
3. ソリューション
Given the problem set outlined above, a good solution would allow an operator to configure multiple RPs per group, and distribute those RPs in a topologically significant manner to the sources and receivers.
複数の1グループあたりのRPsを構成して、それらのRPsを分配するためにセットが上に概説されていて、良い解決策がオペレータを許容するだろうことにおける問題を与える、位相的である、重要な方法、ソースと受信機に。
3.1. Mechanisms
3.1. メカニズム
All the RPs serving a given group or set of groups are configured with an identical anycast address, using a numbered interface on the RPs (frequently a logical interface such as a loopback is used). RPs then advertise group to RP mappings using this interface address. This will cause group members (senders) to join (register) towards the topologically closest RP. RPs MSDP peer with each other using an address unique to each RP. Since the anycast address is not a unique address (by definition), a router MUST NOT choose the anycast unicast address as the router ID, as this can prevent peerings and/or adjacencies from being established.
与えられたグループか1セットのグループに役立つすべてのRPsが同じanycastアドレスによって構成されます、RPsで番号付のインタフェースを使用して(頻繁に、ループバックなどの論理的なインタフェースは使用されています)。 そして、RPsは、このインターフェース・アドレスを使用することでRPマッピングにグループの広告を出します。 これが接合する(登録します)(送付者)をグループのメンバーに引き起こす、位相的である、最も近いRP。 互いが各RPにユニークなアドレスを使用していて、RPs MSDPはじっと見ます。 anycastアドレスがユニークなアドレス(定義上)でないので、ルータはルータIDとしてanycastユニキャストアドレスを選んではいけません、これが、peerings、そして/または、隣接番組が確立されるのを防ぐことができるとき。
In summary then, the following steps are required:
次に、概要では、以下のステップが必要です:
Kim, et al. Informational [Page 3] RFC 3446 Anycast RP mechanism using PIM and MSDP January 2003
キム、他 2003年1月にPIMとMSDPを使用する情報[3ページ]のRFC3446Anycast RPメカニズム
3.1.1. Create the set of group-to-anycast-RP-address mappings
3.1.1. グループからanycast-RPアドレス・マッピングのセットを創設してください。
The first step is to create the set of group-to-anycast-RP-address mappings to be used in the domain. Each RP participating in an anycast RP set must be configured with a consistent set of group to RP address mappings. This mapping will be used by the non-RP routers in the domain.
第一歩はそのドメインで使用されるためにグループからanycast-RPアドレス・マッピングのセットを創設することです。 一貫したセットのグループでanycast RPセットに参加する各RPをRPアドレス・マッピングに構成しなければなりません。 このマッピングはそのドメインの非RPルータによって使用されるでしょう。
3.1.2. Configure each RP for the group range with the anycast RP address
3.1.2. anycast RPアドレスで各RPをグループ範囲に構成してください。
The next step is to configure each RP for the group range with the anycast RP address. If a dynamic mechanism, such as auto-RP or the PIMv2 bootstrap mechanism, is being used to advertise group to RP mappings, the anycast IP address should be used for the RP address.
次のステップはanycast RPアドレスで各RPをグループ範囲に構成することです。 ダイナミックなメカニズム(自動RPかPIMv2がメカニズムを独力で進むようなもの)がRPマッピングにグループの広告を出すのに使用されているなら、anycast IPアドレスはRPアドレスに使用されるべきです。
3.1.3. Configure MSDP peerings between each of the anycast RPs in the set
3.1.3. セットでそれぞれのanycast RPsの間のMSDP peeringsを構成してください。
Unlike the group to RP mapping advertisements, MSDP peerings must use an IP address that is unique to the endpoints; that is, the MSDP peering endpoints MUST use a unicast rather than anycast address. A general guideline is to follow the addressing of the BGP peerings, e.g., loopbacks for iBGP peering, physical interface addresses for eBGP peering. Note that the anycast address MUST NOT be used as the RP address in SA messages (as this would case the peer-RPF check to fail).
広告を写像するRPへのグループと異なって、MSDP peeringsは終点にユニークなIPアドレスを使用しなければなりません。 すなわち、MSDPじっと見る終点はanycastアドレスよりむしろユニキャストを使用しなければなりません。 一般的ガイドラインはBGP peeringsのアドレシング、iBGPのじっと見る(eBGPのじっと見る物理インターフェースアドレス)例えばループバックに続くことです。 RPがSAにメッセージを記述するとき(これが失敗するように同輩-RPFチェックをケースに入れるだろうというとき)、anycastアドレスを使用してはいけないことに注意してください。
3.1.4. Configure the non-RP's with the group-to-anycast-RP-address mappings
3.1.4. グループからanycast-RPアドレス・マッピングによる非RPのものを構成してください。
Finally, each non-RP router must learn the set of group to RP mappings. This could be done via static configuration, auto-RP, or by PIMv2 bootstrap mechanism.
最終的に、それぞれの非RPルータはグループのセットをRPマッピングに学ばなければなりません。 これは、静的な構成、自動RPを通してするか、またはPIMv2でメカニズムを独力で進むかもしれません。
3.1.5. Ensure that the anycast IP address is reachable by all routers in the domain
3.1.5. anycast IPアドレスがそのドメインのすべてのルータで届いているのを確実にしてください。
This is typically accomplished by causing each RP to inject the /32 into the domain's IGP.
各RPがドメインのIGPに/32を注ぐことを引き起こすことによって、これは通常達成されます。
3.2. Interaction with MSDP Peer-RPF check
3.2. MSDP Peer-RPFチェックとの相互作用
Each MSDP peer receives and forwards the message away from the RP address in a "peer-RPF flooding" fashion. The notion of peer-RPF flooding is with respect to forwarding SA messages [MSDP]. The BGP routing tables are examined to determine which peer is the next hop towards the originating RP of the SA message. Such a peer is called an "RPF peer". See [MSDP] for details of the Peer-RPF check.
それぞれのMSDP同輩は、「同輩-RPF氾濫」ファッションでRPアドレスから遠くにメッセージを受け取って、転送します。 推進SAメッセージ[MSDP]に関して同輩-RPF氾濫の概念があります。 BGP経路指定テーブルは、どの同輩がSAメッセージの由来しているRPに向かった次のホップであるかを決定するために調べられます。 そのような同輩は「RPF同輩」と呼ばれます。 Peer-RPFの細部のための[MSDP]がチェックするのを見てください。
Kim, et al. Informational [Page 4] RFC 3446 Anycast RP mechanism using PIM and MSDP January 2003
キム、他 2003年1月にPIMとMSDPを使用する情報[4ページ]のRFC3446Anycast RPメカニズム
3.3. State Implications
3.3. 州の含意
It should be noted that using MSDP in this way forces the creation of (S,G) state along the path from the receiver to the source. This state may not be present if a single RP was used and receivers were forced to stay on the shared tree.
このようにMSDPを使用すると(S、G)状態の創設が経路に沿って受信機からソースまで強制されることに注意されるべきです。 独身のRPが使用されて、受信機が共有された木の上にやむを得ず滞在したなら、この状態は存在していないかもしれません。
4. Security considerations
4. セキュリティ問題
Since the solution described here makes heavy use of anycast addressing, care must be taken to avoid spoofing. In particular unicast routing and PIM RPs must be protected.
ここで説明された解決策がanycastアドレシングの重い使用をするので、だますのを避けるために注意しなければなりません。 特に、ユニキャストルーティングとPIM RPsを保護しなければなりません。
4.1. Unicast Routing
4.1. ユニキャストルート設定
Both internal and external unicast routing can be weakly protected with keyed MD5 [RFC1828], as implemented in an internal protocol such as OSPF [RFC2328] or in BGP [RFC2385]. More generally, IPSEC [RFC2401] could be used to provide protocol integrity for the unicast routing system.
合わせられたMD5[RFC1828]と共に内部の、そして、外部の両方のユニキャストルーティングを弱々しく保護できます、OSPFなどの内部のプロトコル[RFC2328]かBGP[RFC2385]で実行されるように。 より一般に、ユニキャストルーティングシステムにプロトコル保全を供給するのに、IPSEC[RFC2401]を使用できました。
4.1.1. Effects of Unicast Routing Instability
4.1.1. ユニキャストルート設定の不安定性の効果
While not a security issue, it is worth noting that if unicast routing is unstable, then the actual RP that source or receiver is using will be subject to the same instability.
安全保障問題でない間、ユニキャストルーティングが不安定であるならソースか受信機が使用している実際のRPは同じ不安定性を受けることがあることに注意する価値があります。
4.2. Multicast Protocol Integrity
4.2. マルチキャストプロトコル保全
The mechanisms described in [RFC2362] should be used to provide protocol message integrity protection and group-wise message origin authentication.
[RFC2362]で説明されたメカニズムは、プロトコルメッセージの保全保護とグループ的なメッセージ起源認証を提供するのに使用されるべきです。
4.3. MSDP Peer Integrity
4.3. MSDP同輩保全
As is the the case for BGP, MSDP peers can be protected using keyed MD5 [RFC1828].
BGPのためのケースのように、合わせられたMD5[RFC1828]を使用することでMSDP同輩を保護できます。
5. Acknowledgments
5. 承認
John Meylor, Bill Fenner, Dave Thaler and Tom Pusateri provided insightful comments on earlier versions for this idea.
ジョンMeylor、ビル・フェナー、デーヴThaler、およびトムPusateriはこの考えのための以前のバージョンの洞察に満ちたコメントを提供しました。
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 authors.
このメモはインターネット・エンジニアリング・タスク・フォースのOperationsとManagement AreaのMBONE Deployment作業部会(MBONED)の製品です。 コメント to <mboned@ns.uoregon.edu を提出してください、gt;、または、作者。
Kim, et al. Informational [Page 5] RFC 3446 Anycast RP mechanism using PIM and MSDP January 2003
キム、他 2003年1月にPIMとMSDPを使用する情報[5ページ]のRFC3446Anycast RPメカニズム
6. References
6. 参照
[MSDP] D. Meyer and B. Fenner, Editors, "Multicast Source Discovery Protocol (MSDP)", Work in Progress.
[MSDP] エディターズ、「マルチキャストソース発見プロトコル(MSDP)」というD.マイヤーとB.フェナーは進行中で働いています。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, August 1995.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1995年8月。
[RFC1828] Metzger, P. and W. Simpson, "IP Authentication using Keyed MD5", RFC 1828, August 1995.
[RFC1828] メッツガー、P.、およびW.シンプソン、「IP認証使用は1995年8月にMD5"、RFC1828を合わせました」。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2362] 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.
[RFC2362] Estrin、D.、ファリナッチ、D.、Helmy、A.、ターレル、D.、デアリング、S.、ハンドレー、M.、ジェーコブソン、V.、リュウ、C.、シャルマ、P.、およびL.ウェイ、「独立しているマルチキャストまばらなモード(PIM-Sm)を議定書の中で述べてください」 「プロトコル仕様」、RFC2362、1998年6月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy、J.、「OSPF、バージョン2インチ、STD54、RFC2328、1998インチ年4月。
[RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998.
[RFC2385] ヘファーナン、A.、「TCP MD5 Signature Optionを通したBGPセッションズの保護」、RFC2385、1998年8月。
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within ESP and AH", RFC 2403, November 1998.
そして、[RFC2403] マドソン、C.、およびR.グレン、「超能力の中のHMAC-MD5-96の使用、ああ、」、RFC2403、11月1998日
7. Author's Address
7. 作者のアドレス
Dorian Kim Verio, Inc. EMail: dorian@blackrose.org
ドリアンキムVerio Inc.EMail: dorian@blackrose.org
Hank Kilmer EMail: hank@rem.com
ハンクキルマーEMail: hank@rem.com
Dino Farinacci Procket Networks EMail: dino@procket.com
恐竜ファリナッチProcketネットワークはメールされます: dino@procket.com
David Meyer EMail: dmm@maoz.com
デヴィッドマイヤーEMail: dmm@maoz.com
Kim, et al. Informational [Page 6] RFC 3446 Anycast RP mechanism using PIM and MSDP January 2003
キム、他 2003年1月にPIMとMSDPを使用する情報[6ページ]のRFC3446Anycast RPメカニズム
8. Full Copyright Statement
8. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Kim, et al. Informational [Page 7]
キム、他 情報[7ページ]
一覧
スポンサーリンク