[要約] RFC 4720は、PWE3フレームチェックシーケンスの保持に関する規格であり、Pseudowire Emulation Edge-to-Edge（PWE3）ネットワークでのフレームの整合性を確保するために使用されます。目的は、PWE3ネットワークでのデータの信頼性を向上させることです。
Network Working Group A. Malis
Request for Comments: 4720 Tellabs
Category: Standards Track D. Allan
Nortel Networks
N. Del Regno
MCI
November 2006
Pseudowire Emulation Edge-to-Edge (PWE3) Frame Check Sequence Retention
PSEUDOWIREエミュレーションエッジとエッジ（PWE3）フレームチェックシーケンス保持
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 (2006).
Copyright（c）The IETF Trust（2006）。
Abstract
概要
This document defines a mechanism for preserving Frame Check Sequence (FCS) through Ethernet, Frame Relay, High-Level Data Link Control (HDLC), and PPP pseudowires.
このドキュメントは、イーサネット、フレームリレー、高レベルのデータリンクコントロール（HDLC）、およびPPP擬似ワイヤを介してフレームチェックシーケンス（FCS）を保存するメカニズムを定義します。
Table of Contents
目次
1. Overview ........................................................1
2. Specification of Requirements ...................................3
3. Signaling FCS Retention with MPLS-Based Pseudowires .............3
4. Signaling FCS Retention with L2TPv3-Based Pseudowires ...........4
5. Security Considerations .........................................5
6. Applicability Statement .........................................5
7. IANA Considerations .............................................6
8. Acknowledgement .................................................6
9. Normative References ............................................6
The specifications for Ethernet, Frame Relay, HDLC, and PPP pseudowire encapsulation [1] [2] [3] [9] [10] [11] include a mode of use whereby frames are transparently delivered across the pseudowire without any header or other alterations by the pseudowire ingress or egress Provider Edge (PE). (Note that this mode is inherent for HDLC and PPP Pseudowires.)
イーサネット、フレームリレー、HDLC、およびPPP擬似ワイヤーのカプセル化の仕様[1] [2] [3] [9] [10] [11]には、ヘッダーやその他のヘッダーなしでフレームが擬似ワイヤ全体に透過的に配信される使用方法が含まれています。Pseudowireの侵入または出力プロバイダーエッジ（PE）による変更。（このモードはHDLCおよびPPP Pseudowiresに固有のものであることに注意してください。）
However, these specifications all specify that the original Frame Check Sequence (FCS) be removed at ingress and regenerated at egress, which means that the frames may be subject to unintentional alteration during their traversal of the pseudowire from the ingress to the egress PE. Thus, the pseudowire cannot absolutely be guaranteed to be "transparent" in nature.
ただし、これらの仕様はすべて、元のフレームチェックシーケンス（FCS）がイングレス時に削除され、出口で再生されることを指定しています。つまり、フレームは、侵入から出口PEへの擬似動物の移動中に意図しない変化の影響を受ける可能性があります。したがって、擬似ワイヤーは、本質的に「透明」であることを絶対に保証することはできません。
To be more precise, pseudowires, as currently defined, leave the payload vulnerable to unintended modification occurring while transiting the encapsulating network. Not only can a PW-aware device internally corrupt an encapsulated payload, but ANY LSR or router in the path can corrupt the encapsulated payload. In the event of such corruption, there is no way to detect the corruption through the path of the pseudowire. Further, because the FCS is calculated upon network egress, any corruption will pass transparently through ALL Layer 2 switches (Ethernet and Frame Relay) through which the packets travel. Only at the endpoint, assuming that the corrupted packet even reaches the correct endpoint, can the packet be discarded, and depending on the contents of the packet, the corruption may not ever be detected.
より正確には、現在定義されているように、擬似ワイヤは、カプセル化ネットワークを通過する際に発生する意図しない変更に対して脆弱なペイロードのままにします。PWに付随するデバイスは、カプセル化されたペイロードを内部的に破損できるだけでなく、パス内のLSRまたはルーターはカプセル化されたペイロードを破損する可能性があります。そのような腐敗が発生した場合、擬似ワイヤの道を通して腐敗を検出する方法はありません。さらに、FCSはネットワーク出力時に計算されるため、パケットが移動するすべてのレイヤー2スイッチ（イーサネットとフレームリレー）を介して腐敗は透過的に通過します。エンドポイントでのみ、破損したパケットが正しいエンドポイントに到達することさえ、パケットを破棄でき、パケットの内容に応じて、腐敗は検出されない場合があります。
Not only does the encapsulation technique leave the payload unprotected, it also subverts the error checking mechanisms already in place in SP and customer networks by calculating FCS on questionable data.
カプセル化技術はペイロードを保護されていないだけでなく、疑わしいデータでFCを計算することにより、SPおよび顧客ネットワークで既に実施されているエラーチェックメカニズムを覆します。
In a perfect network comprising perfect equipment, this is not an issue. However, as there is no such thing, it is an issue. SPs should have the option of saving overhead by yielding the ability to detect faults. Equally, SPs should have the option to sacrifice the overhead of carrying the original FCS end-to-end to ensure the ability to detect faults in the encapsulating network.
完璧な機器で構成される完全なネットワークでは、これは問題ではありません。ただし、そのようなことはないので、それは問題です。SPSには、障害を検出する能力を生成することにより、頭上を保存するオプションが必要です。同様に、SPSには、元のFCSエンドツーエンドを運ぶオーバーヘッドを犠牲にして、カプセル化ネットワークの障害を検出する能力を確保するオプションが必要です。
This document defines such a mechanism to allow the ingress PE to retain the original frame FCS on ingress to the network, and it relieves the egress PE of the task of regenerating the FCS.
このドキュメントは、イングレスPEがネットワークへのイングレス時に元のフレームFCを保持できるようにするこのようなメカニズムを定義し、FCSを再生するタスクの出口PEを軽減します。
This is an OPTIONAL mechanism for pseudowire implementations. For interoperability with systems that do not implement this document, the default behavior is that the FCS is removed at the ingress PE and regenerated at the egress PE, as specified in [1], [2], and [3].
これは、擬似化された実装のためのオプションのメカニズムです。このドキュメントを実装していないシステムとの相互運用性のために、デフォルトの動作は、[1]、[2]、および[3]で指定されているように、侵入PEでFCSが削除され、出口PEで再生されることです。
This capability may be used only with Ethernet pseudowires that use "raw mode" [1], Frame Relay pseudowires that use "port mode" [2] [3], and HDLC and PPP pseudowires [3].
この機能は、「RAWモード」[1]、「ポートモード」[2] [3]、およびHDLCおよびPPP PSEUDOWIRES [3]を使用するフレームリレープソイドワイヤを使用するイーサネットの擬似動物でのみ使用できます。
Note that this mechanism is not intended to carry errored frames through the pseudowire; as usual, the FCS MUST be examined at the ingress PE, and errored frames MUST be discarded. The FCS MAY also be examined by the egress PE; if this is done, errored frames MUST be discarded. The egress PE MAY also wish to generate an alarm or count the number of errored frames.
このメカニズムは、擬似ワイヤーを通じてエラーフレームを運ぶことを意図していないことに注意してください。いつものように、FCSは侵入PEで検査する必要があり、エラーフレームを破棄する必要があります。FCSは、出口PEによっても検査される場合があります。これが行われた場合、エラーフレームを破棄する必要があります。出力PEは、アラームを生成したり、エラーフレームの数をカウントしたりすることもあります。
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 [6].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、RFC 2119 [6]に記載されているように解釈される。
When using the signaling procedures in [4], there is a Pseudowire Interface Parameter Sub-TLV type used to signal the desire to retain the FCS when advertising a VC label [5]:
[4]で信号手順を使用する場合、VCラベルを宣伝する際にFCSを保持したいという欲求を信号するために使用される擬似ワイヤーインターフェイスパラメーターSub-TLVタイプがあります[5]：
Parameter Length Description 0x0A 4 FCS Retention Indicator
パラメーターの長さの説明0x0a 4 FCS保持指標
The presence of this parameter indicates that the egress PE requests that the ingress PE retain the FCS for the VC label being advertised. It does not obligate the ingress PE to retain the FCS; it is simply an indication that the ingress PE MAY retain the FCS. The sender MUST NOT retain the FCS if this parameter is not present in the VC FEC element.
このパラメーターの存在は、出力PEが宣伝されているVCラベルのFCSを保持することをEgress PEが要求することを示しています。侵入PEにFCSを保持する義務はありません。これは、侵入PEがFCSを保持する可能性があることを単に示しています。このパラメーターがVC FEC要素に存在しない場合、送信者はFCSを保持してはなりません。
The parameter includes a 16-bit FCS length field, which indicates the length of the original FCS being retained. For Ethernet pseudowires, this length will always be set to 4. For HDLC, PPP, and Frame Relay pseudowires, this length will be set to either 2 or 4. Since the FCS length on these interfaces is a local setting, retaining the FCS only makes sense if the FCS length is identical on both ends of the pseudowire. Including the FCS length in this parameter allows the PEs to ensure that the FCS is only retained when it makes sense.
パラメーターには、16ビットのFCS長さフィールドが含まれており、これは元のFCSの長さを保持していることを示します。イーサネットの擬似ワイヤの場合、この長さは常に4に設定されます。HDLC、PPP、およびフレームリレープソイドワイヤの場合、この長さは2または4のいずれかに設定されます。FCSの長さが擬似ワイヤの両端で同一である場合、理にかなっています。このパラメーターにFCSの長さを含めることで、PESは、理にかなっているときにFCSが保持されることを保証できます。
Since unknown parameters are silently ignored [4], backward compatibility with systems that do not implement this document is provided by requiring that the FCS be retained ONLY if the FCS Retention Indicator with an identical setting for the FCS length has been included in the advertisements for both directions on a pseudowire.
未知のパラメーターは静かに無視されるため[4]、このドキュメントを実装しないシステムとの後方互換性は、FCS長さの同一の設定を持つFCS保持インジケーターが広告に含まれている場合にのみ、FCSを保持することによって提供されます。擬似ワイヤの両方の方向。
If the ingress PE recognizes the FCS Retention Indicator parameter but does not wish to retain the FCS with the indicated length, it need only issue its own label mapping message for the opposite direction without including the FCS Retention Indicator. This will prevent FCS retention in either direction.
Ingress PEがFCS保持インジケータパラメーターを認識しているが、指定された長さでFCSを保持することを望まない場合、FCS保持インジケーターを含めることなく、反対方向の独自のラベルマッピングメッセージを発行する必要があります。これにより、どちらの方向でもFCS保持が妨げられます。
If PWE3 signaling [4] is not in use for a pseudowire, then whether the FCS is to be retained MUST be identically provisioned in both PEs at the pseudowire endpoints. If there is no provisioning support for this option, the default behavior is to remove the FCS.
PWE3シグナル伝達[4]が擬似ワイヤに使用されていない場合、FCSを保持するかどうかは、擬似ワイヤのエンドポイントで両方のPEで同じようにプロビジョニングする必要があります。このオプションのプロビジョニングサポートがない場合、デフォルトの動作はFCSを削除することです。
This section uses the following terms as defined in [7]:
このセクションでは、[7]で定義されている次の用語を使用します。
Incoming-Call-Request (ICRQ) Incoming-Call-Reply (ICRP) Incoming-Call-Connected (ICCN) Attribute Value Pair (AVP) L2TP Control Connection Endpoint (LCCE)
受信 - コールリケスト（ICRQ）受信 - コール - 繰り返し（ICRP）受信コール接続（ICCN）属性値ペア（AVP）L2TP制御接続エンドポイント（LCCE）
When using the signaling procedures in [7], the FCS Retention AVP, Attribute Type 92, is used.
[7]で信号手順を使用する場合、FCS保持AVP属性タイプ92が使用されます。
The Attribute Value field for this AVP has the following format:
このAVPの属性値フィールドには、次の形式があります。
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FCS Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The FCS Length is a 2-octet unsigned integer.
FCSの長さは、2オクテットの署名整数です。
The presence of this AVP in an ICRQ or ICRP message indicates that an LCCE (PE) requests that its peer retain FCS for the L2TP session being established. If the receiving LCCE recognizes the AVP and complies with the FCS retention request, it MUST include an FCS Retention AVP as an acknowledgement in a corresponding ICRP or ICCN message. FCS Retention is always bidirectional; thus, FCS is only retained if both LCCEs send an FCS Retention AVP during session establishment.
ICRQまたはICRPメッセージにこのAVPが存在することは、LCCE（PE）がPEERがL2TPセッションのFCを確立するFCを保持することを要求することを示しています。受信LCCEがAVPを認識し、FCS保持リクエストに準拠している場合、対応するICRPまたはICCNメッセージの確認としてFCS保持AVPを含める必要があります。FCS保持は常に双方向です。したがって、FCSは、両方のLCCEがセッションの確立中にFCS保持AVPを送信する場合にのみ保持されます。
The Attribute Value is a 16-bit FCS length field, which indicates the length of the original FCS being retained. For Ethernet pseudowires, this length will always be set to 4. For HDLC, PPP, and Frame Relay pseudowires, this length will be set to either 2 or 4. Since the FCS length on these interfaces is a local setting, retaining the FCS only makes sense if the FCS length is identical on both ends of the pseudowire. Including the FCS length in this AVP allows the PEs to ensure that the FCS is only retained when doing so makes sense.
属性値は16ビットのFCS長さフィールドで、これは元のFCSの長さを保持していることを示します。イーサネットの擬似ワイヤの場合、この長さは常に4に設定されます。HDLC、PPP、およびフレームリレープソイドワイヤの場合、この長さは2または4のいずれかに設定されます。FCSの長さが擬似ワイヤの両端で同一である場合、理にかなっています。このAVPにFCSの長さを含めることで、PESは、そうすることが理にかなっているときにFCSが保持されることを保証できます。
The Length of this AVP is 8. The M bit for this AVP MUST be set to 0 (zero). This AVP MAY be hidden (the H bit MAY be 1 or 0).
このAVPの長さは8です。このAVPのMビットは、0（ゼロ）に設定する必要があります。このAVPは隠されている可能性があります（Hビットは1または0です）。
This mechanism enhances the data integrity of transparent Ethernet, Frame Relay, and HDLC pseudowires, because the original FCS, as generated by the Customer Edge (CE), is included in the encapsulation. When the encapsulated payload passes FCS checking at the destination CE, it is clear that the payload was not altered during its transmission through the network (or at least to the accuracy of the original FCS; but that is demonstrably better than no FCS at all).
このメカニズムは、顧客エッジ（CE）によって生成された元のFCSがカプセル化に含まれているため、透明イーサネット、フレームリレー、およびHDLC擬似ワイヤのデータ整合性を高めます。カプセル化されたペイロードが宛先CEでFCSをチェックする場合、ネットワークを介した送信中にペイロードが変更されなかったことは明らかです（または少なくとも元のFCSの精度まで。。
Of course, nothing comes for free; this requires the additional overhead of carrying the original FCS (in general, either two or four octets per payload packet).
もちろん、無料で何もありません。これには、元のFCを運ぶための追加のオーバーヘッドが必要です（一般に、ペイロードパケットごとに2オクターまたは4オクテット）。
This signaling is backward compatible and interoperable with systems that do not implement this document.
このシグナリングは、このドキュメントを実装していないシステムとの後方互換性があり、相互運用可能です。
In general, this document is intended to further extend the applicability of the services defined by [1], [2], and [3] to make them more suitable for use in deployments where data integrity is an issue (or at least is as much of an issue as in the original services that defined the FCS usage in the first place). There are some situations where this extension is not necessary, such as where the inner payloads have their own error-checking capabilities (such as TCP). But for inner payloads that do rely on the error-detecting capabilities of the link layer (such as SNA), this additional protection can be invaluable.
一般に、このドキュメントは、[1]、[2]、および[3]によって定義されたサービスの適用性をさらに拡張して、データの整合性が問題である展開での使用に適していることを目的としています（または少なくともそのようですそもそもFCS使用量を定義した元のサービスのような問題の多く。内側のペイロードに独自のエラーチェック機能（TCPなど）がある場合など、この拡張機能が必要ない状況がいくつかあります。ただし、リンクレイヤー（SNAなど）のエラー検出機能に依存する内部ペイロードの場合、この追加の保護は非常に貴重です。
When pseudowires are being used to connect 802.1 bridges, this document allows pseudowires to comply with the requirement that all media interconnecting 802.1 bridges have (at least) 32-bit FCS protection.
802.1ブリッジを接続するために擬似動物が使用されている場合、このドキュメントにより、擬似ワイヤは802.1ブリッジを相互接続するすべてのメディアが（少なくとも）32ビットFCS保護を持つという要件に準拠することができます。
Note that this document is one possible alternative for a service provider to enhance the end-to-end data integrity of pseudowires. Other mechanisms may include the use of end-to-end IPsec between the PEs, or internal mechanisms in the P routers to ensure the integrity of packets as they are switched between ingress and egress interfaces. Service providers may wish to compare the relative strengths of each approach when planning their pseudowire deployments; however, an argument can be made that it may be wasteful for an SP to use an end-to-end integrity mechanism that is STRONGER than the FCS generated by the source CE and checked by the destination CE.
このドキュメントは、サービスプロバイダーが擬似動物のエンドツーエンドのデータの整合性を強化するための1つの可能な代替手段であることに注意してください。その他のメカニズムには、PES間のエンドツーエンドのIPSECの使用、またはPルーターの内部メカニズムが含まれる場合があり、インクレス界面と出口界面の間に切り替えられたパケットの整合性を確保することができます。サービスプロバイダーは、擬似展開を計画する際に、各アプローチの相対的な強さを比較したい場合があります。ただし、SPがソースCEによって生成され、宛先CEによってチェックされたFCよりも強いエンドツーエンドの完全性メカニズムを使用することは無駄である可能性があるという議論ができます。
This document does not specify any new registries for IANA to maintain.
このドキュメントでは、IANAが維持する新しいレジストリを指定していません。
Note that [5] allocates the FCS Retention Indicator interface parameter; therefore, no further IANA action is required.
[5]はFCS保持インジケータインターフェイスパラメーターを割り当てることに注意してください。したがって、それ以上のIANAアクションは必要ありません。
IANA assigned one value within the L2TP "Control Message Attribute Value Pairs" section as per [8]. The new AVP is 92 and is referred to in the IANA L2TP parameters registry as "FCS Retention".
IANAは、[8]に従って、L2TP「制御メッセージ属性値ペア」セクション内に1つの値を割り当てました。新しいAVPは92で、IANA L2TPパラメーターレジストリで「FCS保持」と呼ばれています。
The authors would like to thank Mark Townsley for the text in Section 4.
著者は、セクション4のテキストについてマークタウンズリーに感謝したいと思います。
[1] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006.
[1] Martini、L.、Rosen、E.、El-Aawar、N。、およびG. Heron、「MPLSネットワーク上のイーサネットの輸送のためのカプセル化方法」、RFC 4448、2006年4月。
[2] Martini, L., Ed., Kawa, C., Ed., and A. Malis, Ed., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, September 2006.
[2] Martini、L.、ed。、Kawa、C.、ed。、およびA. Malis、ed。、「マルチプロトコルラベルスイッチング（MPLS）ネットワークを介したフレームリレーの輸送のためのカプセル化方法」、RFC 4619、2006年9月。
[3] Martini, L., Rosen, E., Heron, G., and A. Malis, "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006.
[3] Martini、L.、Rosen、E.、Heron、G。、およびA. Malis、「MPLSネットワーク上のPPP/高レベルデータリンクコントロール（HDLC）の輸送のためのカプセル化方法」、RFC 4618、2006年9月。
[4] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.
[4] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T。、およびG. Heron、「ラベル分布プロトコル（LDP）を使用した擬似ワイヤーのセットアップとメンテナンス」、2006年4月、RFC 4447。
[5] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[5] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）のIANAの割り当て」、BCP 116、RFC 4446、2006年4月。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[7] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[7] Lau、J.、Townsley、M。、およびI. Goyret、「レイヤー2トンネルプロトコル - バージョン3（L2TPV3）」、RFC 3931、2005年3月。
[8] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
[8] Townsley、W。、「レイヤー2つのトンネルプロトコル（L2TP）インターネット割り当てされた数字の権限（IANA）の考慮事項更新」、BCP 68、RFC 3438、2002年12月。
[9] Aggarwal, R., Townsley, M., and M. Dos Santos, "Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4719, November 2006.
[9] Aggarwal、R.、Townsley、M。、およびM. Dos Santos、「レイヤー2トンネルプロトコルバージョン3（L2TPV3）上のイーサネットフレームの輸送」、RFC 4719、2006年11月。
[10] Townsley, M., Wilkie, G., Booth, S., Bryant, S., and J. Lau, "Frame Relay over Layer 2 Tunneling Protocol Version 3 (L2TPv3)", RFC 4591, August 2006.
[10] Townsley、M.、Wilkie、G.、Booth、S.、Bryant、S。、およびJ. Lau、「レイヤー2トンネリングプロトコルバージョン3（L2TPV3）」、RFC 4591、2006年8月。
[11] Pignataro, C. and M. Townsley, "High-Level Data Link Control (HDLC) Frames over Layer 2 Tunneling Protocol, Version 3 (L2TPv3)", RFC 4349, February 2006.
[11] Pignataro、C。and M. Townsley、「高レベルのデータリンク制御（HDLC）フレーム上のレイヤー2トンネリングプロトコル、バージョン3（L2TPV3）」、RFC 4349、2006年2月。
Authors' Addresses
著者のアドレス
Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134
Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose、CA 95134
EMail: Andy.Malis@tellabs.com
David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA
David Allan Nortel Networks 3500 Carling Ave. Ottawa、オンタリオ州カナダ
EMail: dallan@nortel.com
Nick Del Regno MCI 400 International Parkway Richardson, TX 75081
ニックデルレグノMCI 400インターナショナルパークウェイリチャードソン、テキサス75081
EMail: nick.delregno@mci.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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.
この文書は、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エディター機能の資金は現在、インターネット協会によって提供されています。