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
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).
著作権（C）IETFトラスト（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]フレームが透過任意のヘッダなしで疑似回線を横切って送達される使用のモードまたは他方を含みます疑似回線の入力または出力プロバイダーエッジ（PE）によって変化。 （このモードでは、HDLCおよびPPPスードワイヤための固有であることに注意してください。）
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.
だけでなく、それはまた、疑わしいデータにFCSを計算することによって、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.
完璧な設備を備えた完璧なネットワークでは、これは問題ではありません。そのような事がないようしかし、それは問題です。 SPは障害を検出する能力を与えることにより、オーバーヘッドを保存するオプションを持っている必要があります。同様に、SPは封止ネットワークの障害を検出する能力を確保するために、元の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がネットワークへの入口上の元のフレームFCSを保持することを可能にするような機構を定義し、それが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].
これは、疑似回線の実装のためのオプションのメカニズムです。この文書を実装していないシステムとの相互運用性のために、デフォルトの動作は、で指定されFCSは、入口PEで除去し、出口PEで再生されることである[1]、[2]、[3]。
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疑似回線[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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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を保持する欲求を知らせるために使用される疑似回線インタフェースパラメータサブ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を保持出口PE要求が広告されていることを示しています。これは、FCSを保持するために入口PEを義務付けません。単に入口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.
パラメータが保持され、元のFCSの長さを示す16ビットのFCS長さフィールドを含みます。イーサネット疑似回線の場合、この長さは常にHDLC、PPPのために4に設定され、リレー疑似回線フレームであろうこれらのインタフェース上のFCS長はローカル設定であるので、この長さは、FCSを保持する、2または4のいずれかに設定されますFCSの長さは、疑似回線の両端で同一であれば意味があります。このパラメータでFCSの長さを含めると、それは理にかなっているとき、PEは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.
未知のパラメータは、サイレントFCS長に対して同一設定でFCS保持インジケータはの広告に含まれている場合にのみFCSを保持することを要求することによって提供されるこのドキュメントを実装していないシステムで[4]、下位互換性を無視しているのでスードワイヤ上の両方向。
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.
イングレス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.
タイプ92 [7]、FCS保持AVPは、属性でシグナリング手順を使用する場合、使用されています。
The Attribute Value field for this AVP has the following format:
このAVPのためのAttribute Value分野には、以下の形式になっています。
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）は、そのピアが確立されたL2TPセッションのためのFCSを保持することを要求することを示しています。受信LCCEがAVPを認識し、FCS保持要求に準拠している場合、それは対応するICRP又はICCNメッセージで確認応答としてFCS保持AVPを含まなければなりません。 FCS保持は常に双方向です。両方のLCCEsは、セッション確立中にFCS保持AVPを送信する場合ので、FCSのみが保持されます。
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.
属性値が保持され、元のFCSの長さを示す16ビットのFCS長フィールドです。イーサネット疑似回線の場合、この長さは常にHDLC、PPPのために4に設定され、リレー疑似回線フレームであろうこれらのインタフェース上のFCS長はローカル設定であるので、この長さは、FCSを保持する、2または4のいずれかに設定されますFCSの長さは、疑似回線の両端で同一であれば意味があります。このAVPでFCSの長さを含めると、そうすることが理にかなっているとき、PEは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の長さは、このAVPのためのMビットが0（ゼロ）に設定しなければならない8です。この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の疑似回線のデータの整合性を高めます。カプセル化されたペイロードは、FCSが宛先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).
もちろん、何も自由のために来ることはありません。これは、元の（一般的には、いずれかのペイロード・パケットごとに2つのまたは4つのオクテット）FCSを運ぶ追加のオーバーヘッドが必要となります。
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つの可能な選択肢であることに注意してください。他の機構は、彼らが入力および出力インターフェースとの間で切り替えされるパケットの完全性を保証するために、PルータでのPE、または内部機構との間のエンドツーエンドのIPsecの使用を含むことができます。サービスプロバイダは、彼らの疑似回線の導入を計画する際に、各アプローチの相対的な強さを比較することを望むかもしれません。しかし、引数はSPがFCSソースCEによって生成され、宛先のCEによって確認されたよりも強力であるエンドツーエンドの完全性機構を使用することは無駄であり得ることを作ることができます。
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は、L2TP内の一つの値を割り当て、[8]の通りの「制御メッセージは、値のペアを属性」。新しいAVPは92であり、「FCS保持」としてIANA L2TPパラメータレジストリで参照されます。
The authors would like to thank Mark Townsley for the text in Section 4.
著者は、第4節でのテキストのマークTownsleyに感謝したいと思います。
[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]マティーニ、L.、ローゼン、E.、エル・Aawar、N.、およびG.サギ、 "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]マティーニ、L.、エド。、カワ、C.、エド。、およびA. Malis、エド。、 "フレームリレーの輸送のためのカプセル化方法マルチプロトコルラベルの上に（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]マティーニ、L.、ローゼン、E.、ヘロン、G.、およびA. Malis、RFC 4618、2006年9月 "MPLSネットワーク上のPPP /ハイレベルデータリンク制御（HDLC）の輸送のためのカプセル化方法" 。
[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]マティーニ、L.、ローゼン、E.、エル・Aawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して擬似回線の設定とメンテナンス"、RFC 4447、2006年4月。
[5] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[5]マティーニ、L.、BCP 116、RFC 4446、2006年4月 "エッジエミュレーションに擬似回線縁（PWE3）のためのIANAの割り当て"。
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[6]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[7] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
[7]ラウ、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（Internet Assigned Numbers Authority）の考慮事項更新"、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]アガルワル、R.、Townsley、M.、およびM.ドス・サントス、 "レイヤ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.、ウィルキー、G.、ブース、S.、ブライアント、S.、およびJ.ラウ、 "レイヤ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.とM. Townsley、RFC 4349、2006年2月 "ハイレベルデータリンク制御（HDLC）は、レイヤ2トンネリングプロトコル、バージョン3（L2TPv3の）の上にフレーム"。
Authors' Addresses
著者のアドレス
Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134
アンドリューG. Malisテラブス90リオロブレス博士はカリフォルニア州サンノゼ95134
EMail: Andy.Malis@tellabs.com
メールアドレス：Andy.Malis@tellabs.com
David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA
デビッド・アランノーテルネットワークス3500カーリングアベニュー。オタワ、オンタリオ、カナダ
EMail: dallan@nortel.com
メールアドレス：dallan@nortel.com
Nick Del Regno MCI 400 International Parkway Richardson, TX 75081
ニック・デル・レグノMCI 400国際パークウェイ・リチャードソン、TX 75081
EMail: nick.delregno@mci.com
メールアドレス：nick.delregno@mci.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（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.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。