RFC4576 日本語訳
4576 Using a Link State Advertisement (LSA) Options Bit to PreventLooping in BGP/MPLS IP Virtual Private Networks (VPNs). E. Rosen, P.Psenak, P. Pillay-Esnault. June 2006. (Format: TXT=15149 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Rosen Request for Comments: 4576 P. Psenak Category: Standards Track P. Pillay-Esnault Cisco Systems, Inc. June 2006
コメントを求めるワーキンググループE.ローゼン要求をネットワークでつないでください: 4576年のP.Psenakカテゴリ: 標準化過程P.Pillay-EsnaultシスコシステムズInc.2006年6月
Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)
BGP/MPLS IP仮想私設網で輪にするのを防ぐのにリンク州の広告(LSA)オプションビットを使用します。(VPNs)
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
This document specifies a procedure that deals with a particular issue that may arise when a Service Provider (SP) provides "BGP/MPLS IP VPN" service to a customer and the customer uses OSPFv2 to advertise its routes to the SP. In this situation, a Customer Edge (CE) Router and a Provider Edge (PE) Router are OSPF peers, and customer routes are sent via OSPFv2 from the CE to the PE. The customer routes are converted into BGP routes, and BGP carries them across the backbone to other PE routers. The routes are then converted back to OSPF routes sent via OSPF to other CE routers. As a result of this conversion, some of the information needed to prevent loops may be lost. A procedure is needed to ensure that once a route is sent from a PE to a CE, the route will be ignored by any PE that receives it back from a CE. This document specifies the necessary procedure, using one of the options bits in the LSA (Link State Advertisements) to indicate that an LSA has already been forwarded by a PE and should be ignored by any other PEs that see it.
このドキュメントはService Provider(SP)が顧客に対する「BGP/MPLS IP VPN」サービスを提供して、顧客がsp.にルートの広告を出すのにOSPFv2を使用すると起こるかもしれない特定の問題に対処する手順を指定します。 この状況で、Customer Edge(CE)ルータとProvider Edge(PE)ルータはOSPF同輩です、そして、CEからPEまでのOSPFv2を通して顧客ルートを送ります。 顧客ルートはBGPルートに変換されます、そして、BGPは背骨の向こう側に他のPEルータまでそれらを運びます。 そして、ルートは他のCEルータへのOSPFを通して送られたOSPFルートに変換して戻されます。 この変換の結果、輪を防ぐのに必要である何らかの情報が失われるかもしれません。 手順が、いったんPEからCEにルートを送ると、CEからそれを受けるどんなPEもルートを無視するのを保証するのに必要です。 このドキュメントは必要な手順を指定します、LSAがPEによって既に進められて、それを見るいかなる他のPEsによっても無視されるはずであるのを示すのにLSA(リンク州Advertisements)でオプションビットの1つを使用して。
Rosen, et al. Standards Track [Page 1] RFC 4576 Prevent Looping in BGP/MPLS IP VPNs June 2006
ローゼン、他 標準化過程[1ページ]RFC4576は、IP VPNs2006年6月にBGP/MPLSで輪にするのを防ぎます。
Table of Contents
目次
1. Introduction ....................................................2 2. Specification of Requirements ...................................3 3. Information Loss and Loops ......................................3 4. Using the LSA Options to Prevent Loops ..........................4 5. Security Considerations .........................................5 6. Acknowledgements ................................................5 7. Normative References ............................................6
1. 序論…2 2. 要件の仕様…3 3. 情報の損失と輪…3 4. 防ぐLSAオプションを使用するのは輪にされます…4 5. セキュリティ問題…5 6. 承認…5 7. 標準の参照…6
1. Introduction
1. 序論
[VPN] describes a method by which a Service Provider (SP) can use its IP backbone to provide an "IP VPN" service to customers. In that sort of service, a customer's edge devices (CE devices) are connected to the provider's edge routers (PE routers). Each CE device is in a single Virtual Private Network (VPN). Each PE device may attach to multiple CEs of the same or of different VPNs. A VPN thus consists of a set of "network segments" connected by the SP's backbone.
[VPN]はService Provider(SP)が顧客に対する「IP VPN」サービスを提供するのにIP背骨を使用できる方法を説明します。 その種類のサービスでは、顧客のエッジデバイス(CE装置)はプロバイダーの縁のルータ(PEルータ)に接続されます。 それぞれのCE装置がただ一つのVirtual兵士のNetwork(VPN)にあります。 それぞれのPE装置は同じくらいか異なったVPNsの複数のCEsに付くかもしれません。 その結果、VPNはSPの背骨によって接続された1セットの「ネットワークセグメント」から成ります。
A CE exchanges routes with a PE, using a routing protocol to which the customer and the SP jointly agree. The PE runs that routing protocol's decision process (i.e., it performs the routing computation) to determine the set of IP address prefixes for which the following two conditions hold:
顧客とSPが共同で同意するルーティング・プロトコルを使用して、CEはPEとルートを交換します。 プロトコルの決定を発送して、IPのセットを決定するために処理される(すなわち、それはルーティング計算を実行します)PE下痢は以下の2つの条件が当てはまる接頭語を記述します:
- Each address prefix in the set can be reached via that CE.
- セットにおけるそれぞれのアドレス接頭語にそのCEを通して達することができます。
- The path from that CE to each such address prefix does NOT include the SP backbone (i.e., it does not include any PE routers).
- そのCEからそのようなそれぞれのアドレス接頭語までの経路はSP背骨を含んでいません(すなわち、それはどんなPEルータも含んでいません)。
The PE routers that attach to a particular VPN redistribute routes to these address prefixes into BGP, so that they can use BGP to distribute the VPN's routes to each other. BGP carries these routes in the "VPN-IPv4 address family", so that they are distinct from ordinary Internet routes. The VPN-IPv4 address family also extends the IP addresses on the left so that address prefixes from two different VPNs are always distinct to BGP, even if both VPNs use the same piece of the private RFC 1918 address space. Thus, routes from different VPNs can be carried by a single BGP instance and can be stored in a common BGP table without fear of conflict.
特定のVPNに付くPEルータはBGPへのこれらのアドレス接頭語にルートを再配付します、VPNのルートを互いに分配するのにBGPを使用できるように。 BGPが「VPN-IPv4アドレス家」でこれらのルートを運ぶので、それらは普通のインターネットルートと異なっています。 また、VPN-IPv4アドレス家が左に関するIPアドレスを広げるので、2異なったVPNsからのアドレス接頭語はいつもBGPに異なります、両方のVPNsが1918年の個人的なRFCアドレス空間の同じ断片を使用しても。 したがって、異なったVPNsからのルートをただ一つのBGP例で運ぶことができて、一般的なBGPテーブルに闘争への恐怖なしで格納できます。
If a PE router receives a particular VPN-IPv4 route via BGP, and if that PE is attached to a CE in the VPN to which the route belongs, then BGP's decision process may install that route in the BGP route table. If so, the PE translates the route back into an IP route and
PEルータがBGPを通して特定のVPN-IPv4ルートを受けて、そのPEがルートが属するVPNにCEに取り付けられるなら、BGPの決定の過程はBGPルートテーブルにそのルートをインストールするかもしれません。 そしてそうだとすれば、PEがIPルートにルートを翻訳して戻す。
Rosen, et al. Standards Track [Page 2] RFC 4576 Prevent Looping in BGP/MPLS IP VPNs June 2006
ローゼン、他 標準化過程[2ページ]RFC4576は、IP VPNs2006年6月にBGP/MPLSで輪にするのを防ぎます。
redistributes it to the routing protocol that is running on the link to that CE.
そのCEへのリンクで走っているルーティング・プロトコルにそれを再配付します。
This methodology provides a "peer model". CE routers peer with PE routers, but CE routers at different sites do not peer with each other.
この方法論は「同輩モデル」を提供します。 CEルータはPEルータでじっと見ますが、異なったサイトのCEルータは互いと共にじっと見ません。
If a VPN uses OSPFv2 as its internal routing protocol, it is not necessarily the case that the CE routers of that VPN use OSPFv2 to peer with the PE routers. Each site in a VPN can use OSPFv2 as its intra-site routing protocol while using BGP or RIP (for example) to distribute routes to a PE router. However, it is certainly convenient when OSPFv2 is being used intra-site to use it on the PE- CE link as well, and [VPN] explicitly allows this. In this case, a PE will run a separate instance of OSPFv2 for each VPN that is attached to the PE; the PE will in general have multiple VPN-specific OSPFv2 routing tables.
VPNが内部のルーティング・プロトコルとしてOSPFv2を使用するなら、そのVPNのCEルータがPEルータでじっと見るのにOSPFv2を使用するのは、必ず事実であるというわけではありません。 VPNの各サイトは(例えば)PEルータにルートを分配するのにBGPかRIPを使用している間、イントラサイトルーティング・プロトコルとしてOSPFv2を使用できます。 しかしながら、OSPFv2がまた、PE- CEリンクの上にそれを使用する中古のイントラサイトであるときに、確かに、それは便利です、そして、[VPN]は明らかにこれを許容します。 この場合、PEはPEに取り付けられる各VPNのためにOSPFv2の別々の例を走らせるでしょう。 一般に、PEには、複数のVPN特有のOSPFv2経路指定テーブルがあるでしょう。
When OSPFv2 is used on a PE-CE link that belongs to a particular VPN, the PE router must redistribute to that VPN's OSPFv2 instance certain routes that have been installed in the BGP routing table. Similarly, a PE router must redistribute to BGP routes that have been installed in the VPN-specific OSPF routing tables. Procedures for this are specified in [VPN-OSPF].
OSPFv2が特定のVPNに属すPE-CEリンクの上に使用されるとき、PEルータはBGP経路指定テーブルにインストールされた例のある一定のルートをそのVPNのOSPFv2に再配付しなければなりません。 同様に、PEルータはVPN特有のOSPF経路指定テーブルにインストールされたルートをBGPに再配付しなければなりません。 これのための手順は[VPN-OSPF]で指定されます。
The routes that are redistributed from BGP to OSPFv2 are advertised in LSAs that are originated by the PE. The PE acts as an OSPF border router, advertising some of these routes in AS-external LSAs, and some in summary LSAs, as specified in [VPN-OSPF].
PEによって溯源されるLSAsにBGPからOSPFv2まで再配付されるルートの広告を出します。 PEはOSPF境界ルータとして機能します、[VPN-OSPF]の指定されるとしてのAS外部のLSAsのこれらのいくつかのルート、および概要LSAsのいくつかの広告を出して。
Similarly, when a PE router receives an LSA from a CE router, it runs the OSPF routing computation. Any route that gets installed in the OSPF routing table must be translated into a VPN-IPv4 route and then redistributed into BGP. BGP will then distribute these routes to the other PE routers.
PEルータがCEルータからLSAを受けるとき、同様に、それはOSPFルーティング計算を走らせます。 OSPF経路指定テーブルにインストールされるどんなルートも、VPN-IPv4ルートに翻訳して、次に、BGPに再配付しなければなりません。 そして、BGPは他のPEルータにこれらのルートを分配するでしょう。
2. Specification of Requirements
2. 要件の仕様
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.
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119で説明されるように本書では解釈されることであるべきです。
3. Information Loss and Loops
3. 情報の損失と輪
A PE, say PE1, may learn a route to a particular VPN-IPv4 address prefix via BGP. This may cause it to generate a summary LSA or an AS-external LSA in which it reports that address prefix. This LSA may then be distributed to a particular CE, say CE1. The LSA may
PE1は、PEがBGPを通して特定のVPN-IPv4アドレス接頭語にルートを学ぶかもしれないと言います。 これで、それは概要LSAかそのアドレス接頭語を報告するAS外部のLSAを発生させるかもしれません。 CE1は、次に、このLSAが特定のCEに分配されるかもしれないと言います。 LSAはそうするかもしれません。
Rosen, et al. Standards Track [Page 3] RFC 4576 Prevent Looping in BGP/MPLS IP VPNs June 2006
ローゼン、他 標準化過程[3ページ]RFC4576は、IP VPNs2006年6月にBGP/MPLSで輪にするのを防ぎます。
then be distributed throughout a particular OSPF area, reaching another CE, say CE2. CE2 may then distribute the LSA to another PE, say PE2.
次に、別のCEに達して、特定のOSPF領域中で分配されてください、そして、CE2を言ってください。 PE2は、次に、CE2が別のPEにLSAを分配するかもしれないと言います。
As stated in the previous section, PE2 must run the OSPF routing computation to determine whether a particular address prefix, reported in an LSA from CE2, is reachable from CE2 via a path that does not include any PE router. Unfortunately, there is no standard way to do this. The OSPFv2 LSAs do not necessarily carry the information needed to enable PE2 to determine that the path to address prefix X in a particular LSA from CE2 is actually a path that includes, say PE1. If PE2 then leaks X into BGP as a VPN-IPv4 route, then PE2 is violating one of the constraints for loop-freedom in BGP; viz., that routes learned from a particular BGP domain are not redistributed back into that BGP domain. This could cause a routing loop to be created.
前項で述べられているように、PE2はLSAでCE2から報告された特定のアドレス接頭語が何かPEルータを含んでいない経路を通してCE2から届いているかどうか決定するためにOSPFルーティング計算を走らせなければなりません。 残念ながら、これをするどんな標準の方法もありません。 OSPFv2 LSAsは必ずPE2が、CE2から特定のLSAの接頭語Xを記述する経路が実際にそれが含む経路であることを決定するのを可能にするのに必要である情報を運ぶというわけではありません、とPE1は言います。 VPN-IPv4ルートとしてのBGPへの漏出X、次に、PE2であるなら、PE2はBGPの輪自由の規制の1つに違反しています。 つまり、特定のBGPドメインから学習されたそのルートはそのBGPドメインに再配付して戻されません。 これで、ルーティング輪を作成できました。
It is therefore necessary to have a means by which an LSA may carry the information that a particular address prefix has been learned from a PE router. Any PE router that receives an LSA with this information would omit the information in this LSA from its OSPF routing computation, and thus it would not leak the information back into BGP.
したがって、LSAが特定のアドレス接頭語がPEルータから学習されたという情報を運ぶかもしれない手段を持つのが必要です。 この情報でLSAを受けるどんなPEルータもOSPFルーティング計算からこのLSAの情報を省略するでしょう、そして、その結果、それは情報をBGPに漏らして戻さないでしょう。
When a PE generates an AS-external LSA, it could use a distinct tag value to indicate that the LSA is carrying information about an address prefix for whom the path includes a PE router. However, this method is not available in the case where the PE generates a Summary LSA. Per [VPN-OSPF], each PE router must function as an OSPF area 0 router. If the PE-CE link is an area 0 link, then it is possible for the PE to receive, over that link, a summary LSA that originated at another PE router. Thus, we need some way of marking a summary LSA to indicate that it is carrying information about a path via a PE router.
PEがAS外部のLSAを発生させると、それは、LSAが経路がPEルータを含んでいるアドレス接頭語の情報を運ぶのを示すのに異なったタグ値を使用するかもしれません。 しかしながら、この方法はPEがSummary LSAを発生させる場合で利用可能ではありません。 [VPN-OSPF]に従って、それぞれのPEルータはOSPF領域0ルータとして機能しなければなりません。 PEがそのリンクの上に受信するのが、PE-CEリンクが領域0のリンクであるなら可能であり、概要は別のPEルータで由来したLSAです。 したがって、私たちはPEルータで経路の情報を運ぶのを示す概要がLSAであるとマークする何らかの方法を必要とします。
4. Using the LSA Options to Prevent Loops
4. 輪を防ぐのにLSAオプションを使用します。
The high-order bit of the LSA Options field (a previously unused bit) is used to solve the problem described in the previous section. We refer to this bit as the DN bit. When a type 3, 5, or 7 LSA is sent from a PE to a CE, the DN bit MUST be set. The DN bit MUST be clear in all other LSA types.
LSA Options分野(以前に未使用のビット)の高位のビットは、前項で説明された問題を解決するのに使用されます。 DNが噛み付いたので、私たちはこのビットを参照します。 タイプ3、5、または7LSAをPEからCEに送るとき、DNビットを設定しなければなりません。 DNビットは他のLSAがタイプするのが全部で明確でなければなりません。
Rosen, et al. Standards Track [Page 4] RFC 4576 Prevent Looping in BGP/MPLS IP VPNs June 2006
ローゼン、他 標準化過程[4ページ]RFC4576は、IP VPNs2006年6月にBGP/MPLSで輪にするのを防ぎます。
+-------------------------------------+ | DN | * | DC | EA | N/P | MC | E | * | +-------------------------------------+
+-------------------------------------+ | DN| * | DC| EA| N/P| M.C.| E| * | +-------------------------------------+
Options Field with DN Bit (RFC 2328, Section A.2)
DNビットがあるオプション分野(RFC2328、セクションA.2)
When the PE receives, from a CE router, a type 3, 5, or 7 LSA with the DN bit set, the information from that LSA MUST NOT be used during the OSPF route calculation. As a result, the LSA is not translated into a BGP route. The DN bit MUST be ignored in all other LSA types.
PEが受信するときには、CEルータ、タイプ3、5、またはそのLSA MUST NOTからのDNビットがあるLSAが設定する7、情報から、OSPFルート計算の間、使用されてください。 その結果、LSAはBGPルートに翻訳されません。 他のすべてのLSAタイプでDNビットを無視しなければなりません。
This prevents routes learned via BGP from being redistributed to BGP. (This restriction is analogous to the usual OSPF restriction that inter-area routes that are learned from area 0 are not passed back to area 0.)
これは、BGPを通して学習されたルートがBGPに再配付されるのを防ぎます。 (領域0から学習される相互領域ルートが領域0に戻されないというこの制限は普通のOSPF制限に類似しています。)
Note that the DN bit has no other effect on LSA handling. In particular, an LSA with the DN bit set will be put in the topological database, aged, flooded, etc., just as if DN were not set.
DNビットが他の影響を全くLSA取り扱いに与えないことに注意してください。 特に、DNビットがセットしたことでのLSAは老いていて、水につかっている位相的なデータベースなどに入れられるでしょう、まるでDNが用意ができているだけではないかのように。
5. Security Considerations
5. セキュリティ問題
An attacker may cause the DN bit to be set, in an LSA traveling from CE to PE, when the DN bit should really be clear. This may cause the address prefixes mentioned in that LSA to be unreachable from other sites of the VPN. Similarly, an attacker may cause the DN bit to be clear, in an LSA traveling in either direction, when the DN bit should really be set. This may cause routing loops for traffic that is destined to the address prefixes mentioned in that LSA.
攻撃者はDNビットを設定させるかもしれません、CEからPEまで旅行するLSAで、DNビットが本当に明確であるはずであるときに。 これは、そのLSAで言及されたアドレス接頭語がVPNの他のサイトから手が届かないことを引き起こすかもしれません。 同様に、攻撃者は、DNビットが明確であることを引き起こすかもしれません、どちらの方向にも旅行するLSAで、DNビットが本当に設定されるべきであるとき。 これはそのLSAで言及されたアドレス接頭語に運命づけられている交通のためのルーティング輪を引き起こすかもしれません。
These possibilities may be eliminated by using cryptographic authentication as specified in Section D of [OSPFv2].
これらの可能性は、[OSPFv2]のセクションDにおける指定されるとしての暗号の認証を使用することによって、排除されるかもしれません。
6. Acknowledgements
6. 承認
The idea of using the high-order options bit for this purpose is due to Derek Yeung. Thanks to Yakov Rekhter for his contribution to this work. We also wish to thank Acee Lindem for his helpful comments.
高位オプションビットを使用するという考えはデリックYeungのこのためにためです。 おかげに、これへの彼の貢献のためのヤコフRekhterは働いています。 また、彼の役に立つコメントについてAcee Lindemに感謝申し上げます。
Rosen, et al. Standards Track [Page 5] RFC 4576 Prevent Looping in BGP/MPLS IP VPNs June 2006
ローゼン、他 標準化過程[5ページ]RFC4576は、IP VPNs2006年6月にBGP/MPLSで輪にするのを防ぎます。
7. Normative References
7. 引用規格
[OSPFv2] Postel, J., "Suggested Telnet Protocol Changes", RFC 328, April 1972.
[OSPFv2] ポステル、J.、「提案されたテルネット・プロトコル変化」、RFC328、1972年4月。
[VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, February 2006.
[VPN]ローゼンとE.とY.Rekhter、「BGP/MPLS IP仮想私設網(VPNs)」、RFC4364 2006年2月。
[VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault, "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4577, June 2006.
[VPN-OSPF] ローゼン、E.、Psenak、P.、およびP.Pillay-Esnault、「プロバイダー/顧客縁としてのOSPFはBGP/MPLS IP仮想私設網(VPNs)のために議定書を作ります」、RFC4577、2006年6月。
Authors' Addresses
作者のアドレス
Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719
マサチューセッツ通りBoxborough、エリックC.ローゼンシスコシステムズInc.1414MA 01719
EMail: erosen@cisco.com
メール: erosen@cisco.com
Peter Psenak Cisco Systems BA Business Center, 9th Floor Plynarenska 1 Bratislava 82109 Slovakia
ピーターPsenakシスコシステムズBaビジネスセンター、9階のPlynarenska1ブラティスラバ82109スロバキア
EMail: ppsenak@cisco.com
メール: ppsenak@cisco.com
Padma Pillay-Esnault Cisco Systems 3750 Cisco Way San Jose, CA 95134
Padma Pillay-Esnaultシスコシステムズ3750コクチマス道サンノゼ(カリフォルニア)95134
EMail: ppe@cisco.com
メール: ppe@cisco.com
Rosen, et al. Standards Track [Page 6] RFC 4576 Prevent Looping in BGP/MPLS IP VPNs June 2006
ローゼン、他 標準化過程[6ページ]RFC4576は、IP VPNs2006年6月にBGP/MPLSで輪にするのを防ぎます。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Rosen, et al. Standards Track [Page 7]
ローゼン、他 標準化過程[7ページ]
一覧
スポンサーリンク