[要約] RFC 4971は、IS-ISプロトコルの拡張であり、ルーター情報の広告に関するものです。その目的は、IS-ISネットワーク内のルーターの特性や機能に関する情報を効果的に伝達することです。
Network Working Group JP. Vasseur, Ed.
Request for Comments: 4971 N. Shen, Ed.
Category: Standards Track Cisco Systems, Inc.
R. Aggarwal, Ed.
Juniper Networks
July 2007
Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information
広告ルーター情報のための中間システム（IS-IS）拡張機能
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 IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain.
このドキュメントでは、複数のサブTLVで形成された、新しいオプションの中間システム（IS-IS）という名前のCapabilityに名前が付けられた新しいオプションの中間システムを定義します。これにより、ルーターはIS-ISレベルまたはルーティングドメイン全体でその機能を発表できます。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. IS-IS Router CAPABILITY TLV .....................................3
3. Elements of Procedure ...........................................4
4. Interoperability with Routers Not Supporting the
Capability TLV ..................................................5
5. Security Considerations .........................................6
6. IANA Considerations .............................................6
7. Acknowledgment ..................................................6
8. References ......................................................6
8.1. Normative References .......................................6
8.2. Informative References .....................................8
There are several situations where it is useful for the IS-IS [IS-IS] [IS-IS-IP] routers to learn the capabilities of the other routers of their IS-IS level, area, or routing domain. For the sake of illustration, three examples related to MPLS Traffic Engineering (TE) are described here:
IS-IS [IS-IS] [IS-IP]ルーターがIS-ISレベル、エリア、またはルーティングドメインの他のルーターの機能を学習することが役立ついくつかの状況があります。図のために、MPLSトラフィックエンジニアリング（TE）に関連する3つの例について説明します。
1. Mesh-group: the setting up of a mesh of TE Label Switched Paths (LSPs) [IS-IS-TE] requires some significant configuration effort. [AUTOMESH] proposes an auto-discovery mechanism whereby every Label Switching Router (LSR) of a mesh advertises its mesh-group membership by means of IS-IS extensions.
1. Mesh-Group：TEラベルスイッチ付きパス（LSP）[IS-IS-TE]のメッシュのセットアップには、いくつかの重要な構成の取り組みが必要です。[Automesh]は、メッシュのすべてのラベルスイッチングルーター（LSR）がIS-IS拡張を使用してメッシュグループのメンバーシップを宣伝する自動ディスコーブリーメカニズムを提案します。
2. Point to Multipoint TE LSP (P2MP LSP). A specific sub-TLV ([TE-NODE-CAP]) allows an LSR to advertise its Point To Multipoint capabilities ([P2MP] and [P2MP-REQS]).
2. マルチポイントTE LSP（P2MP LSP）を指します。特定のSub-TLV（[Te-Node-Cap]）により、LSRはマルチポイント機能（[P2MP]および[P2MP-Reqs]）へのポイントを宣伝できます。
3. Inter-area traffic engineering: Advertisement of the IPv4 and/or the IPv6 Traffic Engineering Router IDs.
3. エリア間交通工学：IPv4および/またはIPv6トラフィックエンジニアリングルーターIDの広告。
The use of IS-IS for Path Computation Element (PCE) discovery may also be considered and will be discussed in the PCE WG.
Path Computation Element（PCE）発見にIS-ISの使用も考慮される場合があり、PCE WGで説明します。
The capabilities mentioned above require the specification of new sub-TLVs carried within the CAPABILITY TLV defined in this document.
上記の機能には、このドキュメントで定義されている機能TLV内で運ばれる新しいサブTLVの仕様が必要です。
Note that the examples above are provided for the sake of illustration. This document proposes a generic capability advertising mechanism that is not limited to MPLS Traffic Engineering.
上記の例は、説明のために提供されていることに注意してください。このドキュメントは、MPLSトラフィックエンジニアリングに限定されない一般的な機能広告メカニズムを提案しています。
This document defines a new optional IS-IS TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. The applications mentioned above require the specification of new sub-TLVs carried within the CAPABILITY TLV defined in this document.
このドキュメントでは、複数のサブTLVで形成された新しいオプションのIS-IS TLVという名前の機能を定義します。これにより、ルーターはIS-I-ISレベルまたはルーティングドメイン全体でその機能を発表できます。上記のアプリケーションでは、このドキュメントで定義されている機能TLV内で運ばれる新しいサブTLVの仕様が必要です。
Definition of these sub-TLVs is outside the scope of this document.
これらのサブTLVの定義は、このドキュメントの範囲外です。
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 [RFC-2119].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、RFC 2119 [RFC-2119]に記載されているように解釈される。
The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 1 octet that specifies the number of bytes in the value field, and a variable length value field that starts with 4 octets of Router ID, indicating the source of the TLV, and followed by 1 octet of flags.
IS-ISルーター機能TLVは、タイプの1オクテット、値フィールドのバイト数を指定する1オクテット、およびルーターIDの4オクテットから始まる可変長さの値フィールドで構成されており、TLVのソースを示しています。、および1オクテットの旗が続きます。
A set of optional sub-TLVs may follow the flag field. Sub-TLVs are formatted as described in RFC 3784 [IS-IS-TE].
オプションのサブTLVのセットは、フラグフィールドに従うことができます。Sub-TLVは、RFC 3784 [IS-IS-TE]で説明されているようにフォーマットされます。
TYPE: 242 LENGTH: from 5 to 255 VALUE: Router ID (4 octets) Flags (1 octet) Set of optional sub-TLVs (0-250 octets)
タイプ：242長さ：5から255値：ルーターID（4オクテット）フラグ（1オクテット）オプションのサブTLV（0-250オクテット）のセット
Flags
フラグ
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |D|S|
+-+-+-+-+-+-+-+-+
Currently two bit flags are defined.
現在、2つのビットフラグが定義されています。
S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV MUST be flooded across the entire routing domain. If the S bit is not set(0), the TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking.
Sビット（0x01）：Sビットが設定されている場合（1）、IS-ISルーター機能TLVは、ルーティングドメイン全体に浸水する必要があります。Sビットが設定されていない場合（0）、TLVをレベル間で漏らしてはなりません。このビットは、TLVの漏れ中に変更してはなりません。
D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from level-2 to level-1, the D bit MUST be set. Otherwise, this bit MUST be clear. IS-IS Router capability TLVs with the D bit set MUST NOT be leaked from level-1 to level-2. This is to prevent TLV looping.
Dビット（0x02）：IS-ISルーター機能TLVがレベル2からレベル1に漏れている場合、Dビットを設定する必要があります。それ以外の場合、このビットは明確でなければなりません。IS-ISルーター機能Dビットセットを使用したTLVは、レベル1からレベル2に漏れてはなりません。これは、TLVループを防ぐためです。
The Router CAPABILITY TLV is OPTIONAL. As specified in Section 3, more than one Router CAPABILITY TLV from the same source MAY be present.
ルーター機能TLVはオプションです。セクション3で指定されているように、同じソースから複数のルーター機能TLVが存在する場合があります。
This document does not specify how an application may use the Router Capability TLV and such specification is outside the scope of this document.
このドキュメントでは、アプリケーションがルーター機能TLVを使用する方法を指定していません。そのような仕様は、このドキュメントの範囲外です。
A router that generates a CAPABILITY TLV MUST have a Router ID that is a 32-bit number. The ID MUST be unique within the IS-IS area. If the router generates any capability TLVs with domain flooding scope, then the ID MUST also be unique within the IS-IS routing domain.
TLVを生成するルーターには、32ビット番号のルーターIDが必要です。IDは、IS-IS領域内で一意でなければなりません。ルーターがドメインフラッディングスコープを備えた機能TLVを生成する場合、IDはIS-ISルーティングドメイン内で一意にする必要があります。
When advertising capabilities with different flooding scopes, a router MUST originate a minimum of two Router CAPABILITY TLVs, each TLV carrying the set of sub-TLVs with the same flooding scope. For instance, if a router advertises two sets of capabilities, C1 and C2, with an area/level scope and routing domain scope respectively, C1 and C2 being specified by their respective sub-TLV(s), the router will originate two Router CAPABILITY TLVs:
さまざまな洪水スコープを備えた広告機能の場合、ルーターは最低2つのルーター機能TLVを発信する必要があり、各TLVは同じ洪水範囲を持つサブTLVのセットを運ぶ必要があります。たとえば、ルーターがそれぞれエリア/レベルの範囲とルーティングドメインスコープを持つ2セットのC1とC2を宣伝する場合、C1とC2はそれぞれのサブTLVによって指定されます。ルーターは2つのルーター機能を発信します。TLVS：
- One Router CAPABILITY TLV with the S flag cleared, carrying the sub-TLV(s) relative to C1. This Router CAPABILITY TLV will not be leaked into another level.
- Sフラグを備えた1つのルーター機能TLVがクリアされ、C1に対するサブTLV（S）を運びます。このルーター機能TLVは、別のレベルに漏れません。
- One Router CAPABILITY TLV with the S flag set, carrying the sub-TLV(s) relative to C2. This Router CAPABILITY TLV will be leaked into other IS-IS levels. When the TLV is leaked from level-2 to level-1, the D bit will be set in the level-1 LSP advertisement.
- Sフラグセットを備えた1つのルーター機能TLV。このルーター機能TLVは、他のIS-ISレベルにリークされます。TLVがレベル2からレベル1に漏れている場合、Dビットはレベル1 LSP広告で設定されます。
In order to prevent the use of stale capabilities, a system MUST NOT use a Capability TLV present in an LSP of a system that is not currently reachable via Level-x paths, where "x" is the level (1 or 2) in which the sending system advertised the TLV. This requirement applies regardless of whether or not the sending system is the originator of the Capabilities TLV. Note that leaking a Capabilities TLV is one of the uses that is prohibited under these conditions.
古い機能の使用を防ぐために、システムは、レベルXパスを介して現在到達できないシステムのLSPに存在する機能TLVを使用してはなりません。「X」はレベル（1または2）です。送信システムはTLVを宣伝しました。この要件は、送信システムが機能TLVの創始者であるかどうかに関係なく適用されます。TLVを漏らすことは、これらの条件下で禁止されている用途の1つであることに注意してください。
Example: If Level-1 router A generates a Capability TLV and floods it to two L1/L2 routers, S and T, they will flood it into the Level-2 domain. Now suppose the Level-1 area partitions, such that A and S are in one partition and T is in another. IP routing will still continue to work, but if A now issues a revised version of the CAP TLV, or decides to stop advertising it, S will follow suit, but T will continue to advertise the old version until the LSP times out.
例：レベル1ルーターAが機能TLVを生成し、2つのL1/L2ルーター、SとTにあふれている場合、レベル2ドメインにあふれます。ここで、AとSが1つのパーティションになり、Tが別のパーティションになるように、レベル1エリアパーティションを仮定します。IPルーティングは引き続き機能しますが、現在、CAP TLVの改訂版を発行するか、広告を停止することを決定した場合、Sはそれに続きますが、TはLSPがタイムするまで古いバージョンを宣伝し続けます。
Routers in other areas have to choose whether to trust T's copy of A's capabilities or S's copy of A's information and, they have no reliable way to choose. By making sure that T stops leaking A's information, this removes the possibility that other routers will use stale information from A.
他の領域のルーターは、Aの機能のTのコピーを信頼するか、Aの情報のSのコピーを信頼するかを選択する必要があり、選択する信頼できる方法がありません。TがAの情報の漏れを止めることを確認することにより、他のルーターがAから古い情報を使用する可能性が削除されます。
In IS-IS, the atomic unit of the update process is a TLV -- or more precisely, in the case of TLVs that allow multiple entries to appear in the value field (e.g., IS-neighbors), the atomic unit is an entry in the value field of a TLV. If an update to an entry in a TLV is advertised in an LSP fragment different from the LSP fragment associated with the old advertisement, the possibility exists that other systems can temporarily have either 0 copies of a particular advertisement or 2 copies of a particular advertisement, depending on the order in which new copies of the LSP fragment that had the old advertisement and the fragment that has the new advertisement arrive at other systems.
IS-ISでは、更新プロセスの原子ユニットはTLVです。より正確には、複数のエントリが値フィールドに表示される可能性があるTLVの場合（例：is-neighbors）、原子ユニットはエントリです。TLVの値フィールド。TLVのエントリの更新が古い広告に関連付けられたLSPフラグメントとは異なるLSPフラグメントで宣伝されている場合、他のシステムが特定の広告の0コピーまたは特定の広告の2コピーのいずれかを一時的に持っている可能性が存在します。古い広告を備えたLSPフラグメントの新しいコピーと、新しい広告が他のシステムに到着するフラグメントの順序に応じて。
Wherever possible, an implementation SHOULD advertise the update to a capabilities TLV in the same LSP fragment as the advertisement that it replaces. Where this is not possible, the two affected LSP fragments should be flooded as an atomic action.
可能な限り、実装は、それが置き換える広告と同じLSPフラグメントの機能TLVのアップデートを宣伝する必要があります。これが不可能な場合、影響を受ける2つのLSPフラグメントは、原子作用として浸水する必要があります。
Systems that receive an update to an existing capability TLV can minimize the potential disruption associated with the update by employing a holddown time prior to processing the update so as to allow for the receipt of multiple LSP fragments associated with the same update prior to beginning processing.
既存の機能TLVの更新を受信するシステムは、処理を開始する前に同じアップデートに関連付けられた複数のLSPフラグメントを受け取ることができるように、更新の処理前にホールドダウン時間を使用することにより、更新に関連する潜在的な混乱を最小限に抑えることができます。
Where a receiving system has two copies of a capabilities TLV from the same system that have different settings for a given attribute, the procedure used to choose which copy shall be used is undefined.
受信システムに、特定の属性に対して異なる設定を持つ同じシステムからの機能TLVの2つのコピーがある場合、使用するコピーを選択するために使用される手順は未定義です。
Routers that do not support the Router CAPABILITY TLV MUST silently ignore the TLV(s) and continue processing other TLVs in the same LSP. Routers that do not support specific sub-TLVs carried within a Router CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs and continue processing those sub-TLVs that are supported in the Router CAPABILITY TLV. How partial support may impact the operation of the capabilities advertised within the Router CAPABILITY TLV is outside the scope of this document.
ルーター機能TLVをサポートしていないルーターは、TLVを静かに無視し、同じLSPで他のTLVの処理を継続する必要があります。ルーター機能TLV内で運ばれる特定のサブTLVをサポートしないルーターは、サポートされていないサブTLVを静かに無視し、ルーター機能TLVでサポートされているサブTLVの処理を継続する必要があります。ルーター機能TLV内で宣伝されている機能の動作に部分的なサポートがどのように影響するかは、このドキュメントの範囲外です。
In order for Router CAPABILITY TLVs with domain-wide scope originated by L1 Routers to be flooded across the entire domain, at least one L1/L2 Router in every area of the domain MUST support the Router CAPABILITY TLV.
ルーター機能のために、ドメイン全体のスコープを備えたTLVがL1ルーター全体に浸水するようになりました。ドメインのすべての領域で少なくとも1つのL1/L2ルーターがルーター機能TLVをサポートする必要があります。
If leaking of the CAPABILITY TLV is required, the entire CAPABILITY TLV MUST be leaked into another level even though it may contain some of the unsupported sub-TLVs.
TLVを漏らす必要がある場合、サポートされていないサブTLVの一部が含まれている場合でも、TLV全体を別のレベルにリークする必要があります。
Any new security issues raised by the procedures in this document depend upon the opportunity for LSPs to be snooped and modified, the ease/difficulty of which has not been altered. As the LSPs may now contain additional information regarding router capabilities, this new information would also become available to an attacker. Specifications based on this mechanism need to describe the security considerations around the disclosure and modification of their information. Note that an integrity mechanism, such as the one defined in [RFC-3567] or [IS-IS-HMAC], should be applied if there is high risk resulting from modification of capability information.
このドキュメントの手順によって提起された新しいセキュリティの問題は、LSPがスヌーピングおよび変更される機会に依存します。その容易さ/難易度は変更されていません。LSPにはルーター機能に関する追加情報が含まれているため、この新しい情報も攻撃者が利用できるようになります。このメカニズムに基づく仕様は、情報の開示と変更に関するセキュリティ上の考慮事項を説明する必要があります。[RFC-3567]または[IS-IS-HMAC]で定義されているものなどの整合性メカニズムは、能力情報の変更に起因する高いリスクがある場合は適用する必要があることに注意してください。
IANA assigned a new IS-IS TLV code-point for the newly defined IS-IS TLV type named the IS-IS Router CAPABILITY TLV and defined in this document. The assigned value is 242.
IANAは、IS-ISルーター機能TLVと呼ばれる新しく定義されたIS-IS TLVタイプに新しいIS-IS TLVコードポイントを割り当て、このドキュメントで定義しました。割り当てられた値は242です。
The authors would like to thank Jean-Louis Le Roux, Paul Mabey, Andrew Partan, and Adrian Farrel for their useful comments.
著者は、Jean-Louis Le Roux、Paul Mabey、Andrew Partan、およびAdrian Farrelの有用なコメントに感謝したいと思います。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[IS-IS] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO 10589.
[IS-IS] "Connectionless-Mode Network Service（ISO 8473）を提供するためのプロトコルと組み合わせて使用するためのドメイン内部システム内領域内領域内のルーティング交換プロトコル」、ISO 10589。
[RFC-3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003.
[RFC-3567] Li、T。およびR. Atkinson、「中間システムから中間システム（IS-IS）暗号認証」、RFC 3567、2003年7月。
[IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[IS-IS-IP] Callon、R。、「TCP/IPおよびデュアル環境でのルーティングのためのOSI IS-I-ISの使用」、RFC 1195、1990年12月。
[IS-IS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[IS-IS-TE] Smit、H。およびT. Li、「交通工学のための中間システム（IS-IS）拡張（TE）」、RFC 3784、2004年6月。
[AUTOMESH] Vasseur, JP., Ed., Le Roux, JL., Ed., Yasukawa, S., Previdi, S., Psenak, P., and P. Mabbey, "Routing extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership", RFC 4972, July 2007.
[Automesh] Vasseur、JP。、ed。、Le Roux、Jl。、ed。、Yasukawa、S.、Previdi、S.、Psenak、P。、およびP. Mabbey、「Multiprotocolの発見のためのルーティング拡張機能（MPLS）ラベルスイッチルーター（LSR）トラフィックエンジニアリング（TE）メッシュメンバーシップ "、RFC 4972、2007年7月。
[TE-NODE-CAP] Vasseur, JP., Ed., and J.L. Le Roux, "Routing Extensions for Discovery of Traffic Engineering Node Capabilities", Work in Progress, April 2007.
[Te-Node-Cap] Vasseur、Jp。、ed。、およびJ.L. Le Roux、「トラフィックエンジニアリングノード機能の発見のためのルーティング拡張機能」、2007年4月、進行中の作業。
[P2MP] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[P2MP-REQS] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[P2MP-Reqs] Yasukawa、S.、ed。、「ポイントツーマルチポイントトラフィックエンジニアリングMPLSラベルスイッチドパス（LSP）のシグナリング要件」、RFC 4461、2006年4月。
[IS-IS-HMAC] Bhatia, M., Ed. and V. Manral, Ed., "IS-IS Generic Cryptographic Authentication", Work in Progress, May 2007.
[IS-IS-HMAC] Bhatia、M.、ed。and V. Manral、ed。、「IS-IS Generic Cryptographic Authentication」、2007年5月、進行中の作業。
Authors' Addresses
著者のアドレス
Jean-Philippe Vasseur CISCO Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA EMail: jpv@cisco.com
Jean-Philippe Vasseur Cisco Systems、Inc。1414 Massachusetts Avenue Boxborough、MA 01719 USAメール：jpv@cisco.com
Stefano Previdi CISCO Systems, Inc. Via Del Serafico 200 00142 - Roma ITALY EMail: sprevidi@cisco.com Mike Shand Cisco Systems 250 Longwater Avenue, Reading, Berkshire, RG2 6GB UK EMail: mshand@cisco.com
Stefano Previdi Cisco Systems、Inc。Del Serafico 200 00142 -Roma Italy Email：sprevidi@cisco.com Mike Shand Cisco Systems 250 Longwater Avenue、Reading、Berkshire、RG2 6GB UKメール：mshand@cisco.com
Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, Ca. 95035 USA EMail: ginsberg@cisco.com
Les Ginsberg Cisco Systems 510 McCarthy Blvd.ミルピタス、カリフォルニア州95035 USAメール：ginsberg@cisco.com
Acee Lindem Redback Networks 102 Carric Bend Court Cary, NC 27519 USA EMail: acee@redback.com
Acee Lindem Redback Networks 102 Carric Bend Court Cary、NC 27519 USAメール：acee@redback.com
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: naiming@cisco.com
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose、CA 95134 USAメール：naiming@cisco.com
Rahul Aggarwal Juniper Networks 1194 N. Mathilda Avenue San Jose, CA 94089 USA EMail: rahul@juniper.net
Rahul Aggarwal Juniper Networks 1194 N. Mathilda Avenue San Jose、CA 94089 USAメール：rahul@juniper.net
Scott Shaffer EMail: sshaffer@bridgeport-networks.com
Scott Shafferメール：sshaffer@bridgeport-networks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
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, THE IETF TRUST 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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
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は、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得しようとする試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
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 currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。