Network Working Group A. Malis
Request for Comments: 4623 Tellabs
Category: Standards Track M. Townsley
Cisco Systems
August 2006
Pseudowire Emulation Edge-to-Edge (PWE3)
Fragmentation and Reassembly
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 Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services.
この文書では、擬似回線エミュレーションエッジ・ツー・エッジ（PWE3）プロトコルおよびサービスが使用するフラグメンテーションを実行する一般的な方法を定義します。
Table of Contents
目次
1. Introduction ....................................................3
2. Conventions Used in This Document ...............................4
3. Alternatives to PWE3 Fragmentation/Reassembly ...................5
4. PWE3 Fragmentation with MPLS ....................................5
4.1. Fragment Bit Locations for MPLS ............................6
4.2. Other Considerations .......................................6
5. PWE3 Fragmentation with L2TP ....................................6
5.1. PW-Specific Fragmentation vs. IP fragmentation .............7
5.2. Advertising Reassembly Support in L2TP .....................7
5.3. L2TP Maximum Receive Unit (MRU) AVP ........................8
5.4. L2TP Maximum Reassembled Receive Unit (MRRU) AVP ...........8
5.5. Fragment Bit Locations for L2TPv3 Encapsulation ............9
5.6. Fragment Bit Locations for L2TPv2 Encapsulation ............9
6. Security Considerations ........................................10
7. IANA Considerations ............................................10
7.1. Control Message Attribute Value Pairs (AVPs) ..............11
7.2. Default L2-Specific Sublayer Bits .........................11
7.3. Leading Bits of the L2TPv2 Message Header .................11
8. Acknowledgements ...............................................11
9. Normative References ...........................................12
10. Informative References ........................................12
Appendix A. Relationship Between This Document and RFC 1990 .......14
The Pseudowire Emulation Edge-to-Edge Architecture Document [Architecture] defines a network reference model for PWE3:
擬似ワイヤエミュレーションエッジツーエッジアーキテクチャ文献[アーキテクチャ] PWE3のネットワーク参照モデルを定義します。
|<-------------- Emulated Service ---------------->|
| |
| |<------- Pseudowire ------->| |
| | | |
| | |<-- PSN Tunnel -->| | |
| PW End V V V V PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
native service native service
Figure 1: PWE3 Network Reference Model
図1：PWE3ネットワークリファレンスモデル
A Pseudowire (PW) payload is normally relayed across the PW as a single IP or MPLS Packet Switched Network (PSN) Protocol Data Unit (PDU). However, there are cases where the combined size of the payload and its associated PWE3 and PSN headers may exceed the PSN path Maximum Transmission Unit (MTU). When a packet exceeds the MTU of a given network, fragmentation and reassembly will allow the packet to traverse the network and reach its intended destination.
単一のIPまたはMPLSパケットがネットワーク（PSN）プロトコルデータユニット（PDU）をスイッチとして疑似回線（PW）ペイロードは、通常、PWを横切って中継されます。しかしながら、ペイロードの合計サイズとそれに関連するPWE3とPSNヘッダーはPSNパス最大伝送単位（MTU）を超えることができる場合があります。パケットは、所与のネットワークのMTUを超えた場合に、断片化と再アセンブリは、パケットがネットワークを通過し、その意図された宛先に到達することを可能にします。
The purpose of this document is to define a generalized method of performing fragmentation for use with all PWE3 protocols and services. This method should be utilized only in cases where MTU-management methods fail. Due to the increased processing overhead, fragmentation and reassembly in core network devices should always be considered something to avoid whenever possible.
このドキュメントの目的は、すべてのPWE3のプロトコルとサービスで使用するための断片化を実行する一般的な方法を定義することです。このメソッドは、MTU-管理方法が失敗の場合に利用すべきです。増大による処理オーバーヘッドに、コアネットワーク装置で断片化と再組み立ては、常に可能な限り回避するために何かを考えるべきです。
The PWE3 fragmentation and reassembly domain is shown in Figure 2:
PWE3断片化と再アセンブリドメインは図2に示されています。
|<-------------- Emulated Service ---------------->|
| |<---Fragmentation Domain--->| |
| ||<------- Pseudowire ----->|| |
| || || |
| || |<-- PSN Tunnel -->| || |
| PW End VV V V VV PW End |
V Service +----+ +----+ Service V
+-----+ | | PE1|==================| PE2| | +-----+
| |----------|............PW1.............|----------| |
| CE1 | | | | | | | | CE2 |
| |----------|............PW2.............|----------| |
+-----+ ^ | | |==================| | | ^ +-----+
^ | +----+ +----+ | | ^
| | Provider Edge 1 Provider Edge 2 | |
| | | |
Customer | | Customer
Edge 1 | | Edge 2
| |
| |
native service native service
Figure 2: PWE3 Fragmentation/Reassembly Domain
図2：PWE3断片化/再アセンブリドメイン
Fragmentation takes place in the transmitting PE immediately prior to PW encapsulation, and reassembly takes place in the receiving PE immediately after PW decapsulation.
フラグメンテーションは、PWカプセル化の直前に送信PEで行われ、そして再組立は直ちにPWデカプセル化後の受信PEで行われます。
Since a sequence number is necessary for the fragmentation and reassembly procedures, using the Sequence Number field on fragmented packets is REQUIRED (see Sections 4.1 and 5.5 for the location of the Sequence Number fields for MPLS and L2TPv3 encapsulations, respectively). The order of operation is that first fragmentation is performed, and then the resulting fragments are assigned sequential sequence numbers.
シーケンス番号が必要とされるフラグメントパケットにシーケンス番号フィールドを使用して、断片化と再アセンブリの手順のために必要であるので（それぞれセクション4.1およびMPLSとL2TPv3のカプセル化のためのシーケンス番号フィールドの場所のために5.5を参照されたいです）。操作の順序は、最初の断片化が行われ、次いで得られたフラグメントはシーケンシャルシーケンス番号が割り当てられていることです。
Depending on the specific PWE3 encapsulation in use, the value 0 may not be a part of the sequence number space, in which case its use for fragmentation must follow this same rule: as the sequence number is incremented, it skips zero and wraps from 65535 to 1. Conversely, if the value 0 is part of the sequence space, then the same sequence space is also used for fragmentation and reassembly.
シーケンス番号がインクリメントされるように、それがゼロをスキップしてラップ65535から：使用中の特定のPWE3カプセル化に応じて、値0は、断片化のためにその使用がこの同じ規則に従う必要があり、その場合、シーケンス番号空間の一部ではないかもしれません1とは逆に、値0は、配列空間の一部である場合、同じ配列空間も断片化と再アセンブリのために使用されます。
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 [KEYWORDS].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [KEYWORDS]で説明されるように解釈されます。
Fragmentation and reassembly in network equipment generally requires significantly greater resources than sending a packet as a single unit. As such, fragmentation and reassembly should be avoided whenever possible. Ideal solutions for avoiding fragmentation include proper configuration and management of MTU sizes between the Customer Edge (CE) router and Provider Edge (PE) router and across the PSN, as well as adaptive measures that operate with the originating host (e.g., [PATHMTU], [PATHMTUv6]) to reduce the packet sizes at the source.
ネットワーク機器におけるフラグメンテーション及び再組み立ては、一般的に単一のユニットとしてパケットを送信するよりも著しく大きいリソースを必要とします。そのため、断片化と再構築は可能な限り避けるべきです。断片化を回避するための理想的なソリューションは、カスタマーエッジ（CE）ルータとプロバイダーエッジ（PE）ルータとPSN間だけでなく、元のホスト（たとえば、[PATHMTU]で動作適応策とのMTUサイズの適切な構成と管理、 [PATHMTUv6]）ソースでパケットサイズを減少させます。
In some cases, a PE may be able to fragment an IP version 4 (IPv4) [RFC791] packet before it enters a PW. For example, if the PE can fragment and forward IPv4 packets with the DF bit clear in a manner that is identical to an IPv4 router, it may fragment packets arriving from a CE, forwarding the IPv4 fragments with associated framing for that attachment circuit (AC) over the PW. Architecturally, the IPv4 fragmentation happens before reaching the PW, presenting multiple frames to the PW to forward in the normal manner for that PWType. Thus, this method is entirely transparent to the PW encapsulation and to the remote end of the PW itself. Packet fragments are ultimately reassembled on the destination IPv4 host in the normal way. IPv6 packets are not to be fragmented in this manner.
いくつかのケースでは、PEは、PWに入る前に、IPバージョン4（IPv4）の[RFC791]パケットを断片化することができるかもしれません。 PEは、IPv4ルータと同一である方法でクリアDFビットにIPv4パケットを断片化し、転送することができる場合、例えば、その接続回線（ACに関連付けられたフレーミングとIPv4のフラグメントを転送する、CEから到着するパケットを断片化することができます）PWを超えます。アーキテクチャは、IPv4の断片化は、そのPWTypeために通常の方法で転送するようにPWに複数のフレームを提示する、PWに到達する前に起こります。したがって、この方法は、PWカプセル化およびPW自体のリモートエンドに完全に透明です。パケットのフラグメントは、最終的には通常の方法で、宛先IPv4ホスト上で再構築されます。 IPv6パケットは、このように断片化されてはなりません。
When using the signaling procedures in [MPLS-Control], there is a Pseudowire Interface Parameter Sub-TLV type used to signal the use of fragmentation when advertising a VC label [IANA]:
[MPLS-制御]でシグナリング手順を使用する場合、VCラベル[IANA]を広告するとき断片の使用を通知するために使用される疑似回線インタフェースパラメータサブTLVのタイプがあります。
Parameter Length Description 0x09 4 Fragmentation indicator
パラメータ長説明0x09の4フラグメンテーションインジケータ
The presence of this parameter in the VC FEC element indicates that the receiver is able to reassemble fragments when the control word is in use for the VC label being advertised. It does not obligate the sender to use fragmentation; it is simply an indication that the sender MAY use fragmentation. The sender MUST NOT use fragmentation if this parameter is not present in the VC FEC element.
VC FEC要素におけるこのパラメータの存在は、受信機は、制御ワードが公示されているVCラベルの使用時にフラグメントを再構築することが可能であることを示しています。これは、断片化を使用するように送信者に義務付けていません。それは単に送信者が断片化を使用するかもしれ徴候です。このパラメータはVC FEC要素に存在しない場合、送信者は、断片化を使用してはなりません。
If [MPLS-Control] signaling is not in use, then whether or not to use fragmentation MUST be configured in the sender.
[MPLS-制御]シグナリングが使用されていない場合は、断片化を使用するかどうかを送信側で設定する必要があります。
MPLS-based PWE3 uses the following control word format [Control-Word], with the B and E fragmentation bits identified in position 8 and 9:
MPLSベースのPWE3は、位置8と9で同定さB及びE断片化ビットで、次の制御ワード形式[コントロール・ワード]を使用しています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0| Flags |B|E| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Preferred PW MPLS Control Word
図3：優先PW MPLS制御ワード
The B and E bits are defined as follows:
次のようにBとEビットが定義されています。
BE -- 00 indicates that the entire (un-fragmented) payload is carried in a single packet 01 indicates the packet carrying the first fragment 10 indicates the packet carrying the last fragment 11 indicates a packet carrying an intermediate fragment
BE - 00（非断片化）ペイロード全体が単一のパケット01で搬送されていることを示す第1の断片10を運ぶパケットが最後のフラグメント11を搬送するパケットは中間フラグメントを運ぶパケットを示して示し示し
See Appendix A for a discussion of the derivation of these values for the B and E bits.
B及びEビットに対するこれらの値の導出についての議論は、付録Aを参照してください。
See Section 1 for the description of the use of the Sequence Number field.
シーケンス番号フィールドの使用の詳細については、セクション1を参照してください。
Path MTU [PATHMTU] [PATHMTUv6] may be used to dynamically determine the maximum size for fragments. The application of path MTU to MPLS is discussed in [LABELSTACK]. The maximum size of the fragments may also be configured. The signaled Interface MTU parameter in [MPLS-Control] SHOULD be used to set the maximum size of the reassembly buffer for received packets to make optimal use of reassembly buffer resources.
パスMTUは[PATHMTU] [PATHMTUv6]動的フラグメントの最大サイズを決定するために使用することができます。 MPLSへのパスMTUの適用は、[LABELSTACK]で議論されています。フラグメントの最大サイズも設定することができます。 [MPLS-制御]でシグナリングインタフェースMTUパラメータは、再構成バッファ資源の最適利用するために、受信したパケットのための再構成バッファの最大サイズを設定するために使用されるべきです。
This section defines the location of the B and E bits for L2TPv3 [L2TPv3] and L2TPv2 [L2TPv2] headers, as well as the signaling mechanism for advertising MRU (Maximum Receive Unit) values and support for fragmentation on a given PW. As IP is the most common PSN used with L2TP, IP PSN fragmentation and reassembly is discussed as well.
このセクションでは、L2TPv3の【のL2TPv3]とL2TPv2のためのBおよびEビット[L2TPv2]ヘッダー、ならびに広告MRU（最大受信ユニット）の値と所定のPWに断片化のサポートのためのシグナリング機構の位置を定義します。 IPは、L2TPで使用される最も一般的なPSNのように、IP PSN断片化と再アセンブリは同様に議論されています。
When proper MTU management across a network fails, IP PSN fragmentation and reassembly may be used to accommodate MTU mismatches between tunnel endpoints. If the overall traffic requiring fragmentation and reassembly is very light, or there are sufficient optimized mechanisms for IP PSN fragmentation and reassembly available, IP PSN fragmentation and reassembly may be sufficient.
ネットワークを介して適切なMTUの管理が失敗した場合、IP PSN断片化と再アセンブリは、トンネルエンドポイントとの間のMTUのミスマッチを収容するために使用されてもよいです。フラグメンテーションと再組立を必要とする全体的なトラフィックが非常に少ない、またはIP PSN断片化し、利用可能な再組み立てのために十分に最適化メカニズムがある場合、IP PSN断片化と再アセンブリが十分であってもよいです。
When facing a large number of PW packets requiring fragmentation and reassembly, a PW-specific method has properties that potentially allow for more resource-friendly implementations. Specifically, the ability to assign buffer usage on a per-PW basis and PW sequencing may be utilized to gain advantage over a general mechanism applying to all IP packets across all PWs. Further, PW fragmentation may be more easily enabled in a selective manner for some or all PWs, rather than enabling reassembly for all IP traffic arriving at a given node.
フラグメンテーションと再組立を必要PWパケットを大量に面する場合、PW-具体的な方法は、潜在的に複数のリソース・フレンドリーな実装を可能にする特性を有します。具体的には、毎PWに基づいて、バッファ使用及びPW配列を割り当てる機能は、すべてのPW全体のすべてのIPパケットに適用する一般的な機構上の利点を得るために利用することができます。さらに、PW断片化をより容易にいくつかまたは全てのPWのために選択的に有効ではなく、所与のノードに到着するすべてのIPトラフィックの再組み立てを可能にすることができます。
Deployments SHOULD avoid a situation that uses a combination of IP PSN and PW fragmentation and reassembly on the same node. Such operation clearly defeats the purpose behind the mechanism defined in this document. This is especially important for L2TPv3 pseudowires, since potentially fragmentation can take place in three different places (the IP PSN, the PW, and the encapsulated payload). Care must be taken to ensure that the MTU/MRU values are set and advertised properly at each tunnel endpoint to avoid this. When fragmentation is enabled within a given PW, the DF bit MUST be set on all L2TP over IP packets for that PW.
展開は、同じノード上のIP PSNとPWの断片化と再構築の組み合わせを使用する事態を避ける必要があります。このような操作は明らかに、この文書で定義されたメカニズムの背後にある目的に反し。潜在的に断片化は、3つの異なる場所（IP PSN、PW、およびカプセル化されたペイロード）で行うことができるので、これは、のL2TPv3疑似回線のために特に重要です。注意がMTU / MRU値が設定され、これを回避するために、各トンネルエンドポイントで適切にアドバタイズされることを保証するために注意しなければなりません。断片化は、与えられたPW内有効にすると、DFビットがそのPWのためにIPパケットを超えるすべてのL2TPに設定しなければなりません。
L2TPv3 nodes SHOULD participate in Path MTU ([PATHMTU], [PATHMTUv6]) for automatic adjustment of the PSN MTU. When the payload is IP, Path MTU should be used at they payload level as well.
L2TPv3のノードは、PSN MTUの自動調整のためのパスMTU（[PATHMTU]、[PATHMTUv6]）に参加すべきです。ペイロードがIPであるとき、彼らは同様のレベルをペイロードで、パスMTUを使用する必要があります。
The constructs defined in this section for advertising fragmentation support in L2TP are applicable to [L2TPv3] and [L2TPv2].
L2TPでの広告の断片化をサポートするために、このセクションで定義された構築物は[L2TPv2]と[L2TPv3の]に適用されます。
This document defines two new AVPs to advertise maximum receive unit values and reassembly support. These AVPs MAY be present in the Incoming-Call-Request (ICRQ), Incoming-Call-Reply (ICRP), Incoming-Call-Connected (ICCN), Outgoing-Call-Request (OCRQ), Outgoing-Call-Reply (OCRP), Outgoing-Call-Connected (OCCN), or Set-Link-Info (SLI) messages. The most recent value received always takes precedence over a previous value and MUST be dynamic over the life of the session if received via the SLI message. One of the two new AVPs (MRRU) is used to advertise that PWE3 reassembly is supported by the sender of the AVP. Reassembly support MAY be unidirectional.
この文書では、最大の単位値と再構築のサポートを受ける宣伝するために、2つの新しいAVPを定義します。これらのAVPはOCRP（発信・コール返信、着信-要求（ICRQ）、着信-返信（ICRP）、着信接続（ICCN）、発信・コール要求（OCRQ）中に存在することができます）、（OCCN）接続の発信コール-、またはSet-リンク情報（SLI）メッセージ。受信した最新の値が常に前の値に優先し、SLIメッセージを介して受信した場合にはセッションの間にダイナミックでなければなりません。二つの新しいのAVP（MRRU）の一つは、PWE3の再構築は、AVPの送信者によってサポートされていることを宣伝するために使用されます。再アセンブリのサポートは、一方向のかもしれ。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: L2TP Maximum Receive Unit (MRU) AVP
図4：L2TP最大受信ユニット（MRU）AVP
MRU (Maximum Receive Unit), attribute number 94, is the maximum size, in octets, of a fragmented or complete PW frame, including L2TP encapsulation, receivable by the side of the PW advertising this value. The advertised MRU does NOT include the PSN header (i.e., the IP and/or UDP header). This AVP does not imply that PWE3 fragmentation or reassembly is supported. If reassembly is not enabled or unavailable, this AVP may be used alone to advertise the MRU for a complete frame.
MRU（最大受信単位）、属性番号94は、L2TPカプセル化、PW広告の側で受信この値を含む断片化または完全なPWフレームの、オクテットで、最大サイズです。アドバタイズされたMRUは、PSNヘッダ（すなわち、IP及び/又はUDPヘッダ）を含みません。このAVPは、PWE3の断片化や再構築がサポートされていることを意味するものではありません。再構築が有効か利用できなくされていない場合は、このAVPは、完全なフレームのためのMRUを宣伝するために単独で使用することができます。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M) bit for this AVP SHOULD be set to 0. The Length (before hiding) is 8. The Vendor ID is the IETF Vendor ID of 0.
このAVPは、（Hビットが0または1でもよい）隠すことができます。このAVPのために必須（M）ビットは（隠れ前）0長さに設定すべきは、ベンダーIDが0のIETFベンダーIDである8です。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MRRU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: L2TP Maximum Reassembled Receive Unit (MRRU) AVP
図5：L2TP最大再構成されたが、受信ユニット（MRRU）AVP
MRRU (Maximum Reassembled Receive Unit AVP), attribute number 95, is the maximum size, in octets, of a reassembled frame, including any PW framing, but not including the L2TP encapsulation or L2-specific sublayer. Presence of this AVP signifies the ability to receive PW fragments and reassemble them. Packet fragments MUST NOT be sent by a peer that has not received this AVP in a control message. If the MRRU is present in a message, the MRU AVP MUST be present as well.
MRRU（最大再構成されたが、ユニットAVPを受信する）、属性番号95は、任意のPWフレーミングなど再組み立てフレームの、オクテットで、最大サイズが、L2TPカプセル化又はL2特異的副層を含みません。このAVPの存在はPWフラグメントを受信し、それらを再構築する能力を意味します。パケット断片は制御メッセージにこのAVPを受信していないピアによって送信されてはいけません。 MRRUがメッセージ内に存在する場合、MRU AVPも存在しなければなりません。
The MRRU SHOULD be used to set the maximum size of the reassembly buffer for received packets to make optimal use of reassembly buffer resources.
MRRUは、再構成バッファ資源の最適利用するために、受信したパケットのための再構成バッファの最大サイズを設定するために使用されるべきです。
This AVP MAY be hidden (the H bit MAY be 0 or 1). The mandatory (M) bit for this AVP SHOULD be set to 0. The Length (before hiding) is 8. The Vendor ID is the IETF Vendor ID of 0.
このAVPは、（Hビットが0または1でもよい）隠すことができます。このAVPのために必須（M）ビットは（隠れ前）0長さに設定すべきは、ベンダーIDが0のIETFベンダーIDである8です。
The usage of the B and E bits is described in Section 4.1. For L2TPv3 encapsulation, the B and E bits are defined as bits 2 and 3 in the leading bits of the Default L2-Specific Sublayer (see Section 7).
BとEビットの使用は、セクション4.1に記載されています。 L2TPv3のカプセル化のために、BとEビットをビットデフォルトL2特有のSublayer（セクション7参照）の先頭ビット2及び3のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|x|S|B|E|x|x|x|x| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: B and E Bits Location in the Default L2-Specific Sublayer
デフォルトL2特有サブレイヤにおいてBとEビット位置：図6
The S (Sequence) bit is as defined in [L2TPv3]. Location of the B and E bits for PW-Types that use a variant L2 specific sublayer are outside the scope of this document.
【のL2TPv3]で定義されるようにS（シーケンス）ビットです。変異体L2特定サブレイヤを使用PW-タイプのBとEビットの位置は、この文書の範囲外です。
When fragmentation is used, an L2-Specific Sublayer with B and E bits defined MUST be present in all data packets for a given session. The presence and format of the L2-Specific Sublayer is advertised via the L2-Specific Sublayer AVP, Attribute Type 69, defined in Section 5.4.4 of [L2TPv3].
断片化が使用される場合、定義されたBとEビットのL2特有サブレイヤは、特定のセッションのすべてのデータ・パケット内に存在していなければなりません。プレゼンスおよびL2特有のフォーマット副層は、L2特有のSublayer AVP、[L2TPv3の]のセクション5.4.4で定義された属性タイプ69を介してアドバタイズされます。
See Section 1 for the description of the use of the Sequence Number field.
シーケンス番号フィールドの使用の詳細については、セクション1を参照してください。
The usage of the B and E bits is described in Section 4.1. For L2TPv2 encapsulation, the B and E bits are defined as bits 8 and 9 in the leading bits of the L2TPv2 header as depicted below (see Section 7).
BとEビットの使用は、セクション4.1に記載されています。以下に示すようにL2TPv2カプセル化のために、BとEビットは（セクション7参照）L2TPv2ヘッダの先頭ビットのビット8および9のように定義されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H|0|0|0|0| Length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|x|x|S|x|O|P|B|E|x|x| Ver | Length (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: B and E bits location in the L2TPv2 Message Header
図7：L2TPv2メッセージヘッダ内のBとEビット位置
As with any additional protocol construct, each level of complexity adds the potential to exploit protocol and implementation errors. Implementers should be especially careful of not tying up an abundance of resources, even for the most pathological combination of packet fragments that could be received. Beyond these issues of general implementation quality, there are no known notable security issues with using the mechanism defined in this document. It should be pointed out that RFC 1990, on which this document is based, and its derivatives have been widely implemented and extensively used in the Internet and elsewhere.
追加のプロトコル構築物と同様に、複雑さの各レベルは、プロトコルや実装誤差を利用する可能性を追加します。実装者はいなくても受信できたパケットフラグメントのほとんどの病理学的組み合わせのために、資源の豊富を拘束特に注意する必要があります。一般的な実装品質のこれらの問題を超えて、この文書で定義されたメカニズムを使用して既知の顕著なセキュリティ上の問題はありません。これは、このドキュメントの基になっていることRFC 1990を、指摘されるべきである、とその誘導体は、広く実施されていると広くインターネットで他の場所で使用します。
[IPFRAG-SEC] and [TINYFRAG] describe potential network attacks associated with IP fragmentation and reassembly. The issues described in these documents attempt to bypass IP access controls by sending various carefully formed "tiny fragments", or by exploiting the IP offset field to cause fragments to overlap and rewrite interesting portions of an IP packet after access checks have been performed. The latter is not an issue with the PW-specific fragmentation method described in this document, as there is no offset field. However, implementations MUST be sure not to allow more than one whole fragment to overwrite another in a reconstructed frame. The former may be a concern if packet filtering and access controls are being placed on tunneled frames within the PW encapsulation. To circumvent any possible attacks in either case, all filtering and access controls should be applied to the resulting reconstructed frame rather than any PW fragments.
[IPFRAG-SEC]および[TINYFRAG] IPフラグメンテーション及び再組み立てに関連する潜在的なネットワーク攻撃を記述する。これらの文書に記載されている問題は、断片が重なるとアクセスチェックが実行された後、IPパケットの面白い部分を書き換えさせるためのフィールドをオフセット、またはIPを活用することによって、様々な慎重に形成された「小さな断片」を送信することにより、IPアクセス制御をバイパスすることを試みます。いかなるオフセットフィールドが存在しないように、後者は、本文書に記載のPW特有の断片化法の問題ではありません。しかし、実装は、複数の全フラグメントが再構成されたフレーム内の別の上書きを許可しないように確認する必要があります。パケットフィルタリングとアクセス制御がPWカプセル化内トンネリングフレーム上に配置されている場合、前者が問題であってもよいです。いずれの場合も、任意の可能な攻撃を回避するために、すべてのフィルタリングとアクセス制御は、結果として得られる再構成されたフレームではなく、任意のPW断片に適用されるべきです。
This document does not define any new registries for IANA to maintain.
IANAが維持するためにこのドキュメントは、新しいレジストリを定義していません。
Note that [IANA] has already allocated the Fragmentation Indicator interface parameter, so no further IANA action is required.
[IANA]既に断片化インジケータインタフェースパラメータを割り当てたので、さらなるIANA動作が必要とされないことに留意されたいです。
This document requires IANA to assign new values for registries already managed by IANA (see Sections 7.1 and 7.2) and two reserved bits in an existing header (see Section 7.3).
この文書は、すでにIANAによって管理されるレジストリの新しい値（セクション7.1および7.2を参照）、既存のヘッダに2つの予約ビットを割り当てるIANAを必要とする（セクション7.3を参照）。
Two additional AVP Attributes are specified in Sections 5.3 and 5.4. They are required to be defined by IANA as described in Section 2.2 of [BCP0068].
二つの追加AVP属性は、セクション5.3および5.4に指定されています。彼らは[BCP0068]のセクション2.2に記載されるようにIANAによって定義される必要があります。
Control Message Attribute Value Pairs
-------------------------------------
94 - Maximum Receive Unit (MRU) AVP 95 - Maximum Reassembled Receive Unit (MRRU) AVP
94 - 最大受信単位（MRU）AVP 95 - 最大再構成されたが、受信ユニット（MRRU）AVP
This registry was created as part of the publication of [L2TPv3]. This document defines two reserved bits in the Default L2-Specific Sublayer in Section 5.5, which may be assigned by IETF Consensus [RFC2434]. They are required to be assigned by IANA.
このレジストリは[L2TPv3の]の出版物の一部として作成されました。このドキュメントはIETFコンセンサス[RFC2434]によって割り当てられてもよいセクション5.5におけるデフォルトL2特有のSublayer、中の2つの予約ビットを定義します。これらはIANAによって割り当てられることが必要です。
Default L2-Specific Sublayer bits - per [L2TPv3]
---------------------------------
Bit 2 - B (Fragmentation) bit Bit 3 - E (Fragmentation) bit
ビット2 - B（断片化）ビットのビット3 - E（断片化）ビット
This document requires definition of two reserved bits in the L2TPv2 [L2TPv2] header. Locations are noted by the "B" and "E" bits in Section 5.6.
この文書では、L2TPv2 [L2TPv2]ヘッダ内の2つの予約ビットの定義を必要とします。位置は、セクション5.6で「B」と「E」ビットで指摘されています。
Leading Bits of the L2TPv2 Message Header - per [L2TPv2, L2TPv3]
-----------------------------------------
Bit 8 - B (Fragmentation) bit Bit 9 - E (Fragmentation) bit
ビット8 - B（断片化）ビットのビット9 - E（断片化）ビット
The authors wish to thank Eric Rosen and Carlos Pignataro, both of Cisco Systems, for their review of this document.
作者はこのドキュメントの彼らのレビューのために、エリック・ローゼンとカルロスPignataro、シスコシステムズの両方に感謝したいです。
[Control-Word] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.
[コントロール・ワード]ブライアント、S.、ツバメ、G.、マルティーニ、L.、及びD.マクファーソン、「MPLS PSNの上の使用のための擬似回線エミュレーションエッジ・ツー・エッジ（PWE3）コントロールワード」、RFC 4385年2月2006。
[IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[IANA]マティーニ、L.、BCP 116、RFC 4446、2006年4月 "エッジエミュレーション（PWE3）への擬似回線EdgeのIANAの割り当て"。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[LABELSTACK] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
【LABELSTACK]ローゼン、E.、タッパン、D.、Fedorkow、G.、Rekhter、Y.、ファリナッチ、D.、李、T.、およびA.コンタ、 "MPLSラベルスタックエンコーディング"、RFC 3032、2001年1月。
[L2TPv2] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
[L2TPv2] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ツォルン、G.、およびB. Palter、 "レイヤ2トンネリングプロトコル "L2TP""、RFC 2661、1999年8月。
[L2TPv3] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
【のL2TPv3]ラウ、J.、Townsley、M.、およびI. Goyret、 "レイヤ2トンネリングプロトコル - バージョン3（L2TPv3の）"、RFC 3931、2005年3月。
[MLPPP] Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[MLPPP] Sklower、K.、ロイド、B.、マクレガー、G.、カー、D.、およびT. Coradetti、 "PPPマルチリンクプロトコル（MP）"、RFC 1990、1996年8月。
[MPLS-Control] 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.
、RFC 4447 [MPLS-制御]マルティーニ、L.、ローゼン、E.、エルAawar、N.、スミス、T.、およびG.サギ、 "ラベル配布プロトコル（LDP）を使用して疑似回線の設定とメンテナンス"、 2006年4月。
[PATHMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[PATHMTU]ムガール人、J.とS.デアリング、 "パスMTUディスカバリ"、RFC 1191、1990年11月。
[PATHMTUv6] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[PATHMTUv6]マッキャン、J.、デアリング、S.、およびJ.ムガール人、RFC 1981 "IPバージョン6のパスMTUディスカバリー"、1996年8月。
[Architecture] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[アーキテクチャ]ブライアント、S.とP.パテ、 "疑似ワイヤーエミュレーション端から端まで（PWE3）アーキテクチャ"、RFC 3985、2005年3月。
[BCP0068] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
[BCP0068] Townsley、W.、 "レイヤ2トンネリングプロトコル（L2TP）IANA（Internet Assigned Numbers Authority）の考慮事項更新"、BCP 68、RFC 3438、2002年12月。
[FAST] ATM Forum, "Frame Based ATM over SONET/SDH Transport (FAST)", af-fbatm-0151.000, July 2000.
[FAST] ATMフォーラム、 "SONET / SDHトランスポート上でフレーム・ベースATM（FAST）"、AF-fbatm-0151.000、2000年7月。
[FRF.12] Frame Relay Forum, "Frame Relay Fragmentation Implementation Agreement", FRF.12, December 1997.
[FRF.12]リレーフォーラム、「フレームリレーフラグメンテーションの実装合意書」、FRF.12、1997年12月フレーム。
[IPFRAG-SEC] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[IPFRAG-SEC] Ziemba、G.、リード、D.、およびP. Trainaの、 "IPフラグメントフィルタリングのためのセキュリティの考慮事項"、RFC 1858、1995年10月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[TINYFRAG] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001.
、RFC 3128、2001年6月[TINYFRAG]ミラー、I.、 "タイニーフラグメント攻撃（RFC 1858）のバリアントに対する保護"。
Appendix A. Relationship between This Document and
このドキュメントとの間付録A.関係
The fragmentation of large packets into smaller units for transmission is not new. One fragmentation and reassembly method was defined in RFC 1990, Multi-Link PPP [MLPPP]. This method was also adopted for both Frame Relay [FRF.12] and ATM [FAST] network technology. This document adopts the RFC 1990 fragmentation and reassembly procedures as well, with some distinct modifications described in this appendix. Familiarity with RFC 1990 is assumed.
送信のためのより小さな単位に大きいパケットの断片化は新しいものではありません。一つの断片化と再アセンブリ方法は、RFC 1990で定義された、マルチリンクPPP [MLPPP]。この方法は、両方のフレームリレー[FRF.12]とATM [FAST]ネットワーク技術を採用しました。この文書では、この付録で説明するいくつかの明確な変更を加えて、同様にRFC 1990フラグメンテーション及び再組み立て手順を採用しています。 RFC 1990に精通が想定されます。
RFC 1990 was designed for use in environments where packet fragments may arrive out of order due to their transmission on multiple parallel links, specifying that buffering be used to place the fragments in correct order. For PWE3, the ability to reorder fragments prior to reassembly is OPTIONAL; receivers MAY choose to drop frames when a lost fragment is detected. Thus, when the sequence number on received fragments shows that a fragment has been skipped, the partially reassembled packet MAY be dropped, or the receiver MAY wish to wait for the fragment to arrive out of order. In the latter case, a reassembly timer MUST be used to avoid locking up buffer resources for too long a period.
RFC 1990バッファリングが正しい順序で断片を配置するために使用されることを指定して、パケットのフラグメントが原因複数の平行リンク上での送信に順不同で到着することができる環境で使用するために設計しました。 PWE3のために、前再構築へのフラグメントの順序を変更する機能はオプションです。受信機は、失われたフラグメントが検出されたときに、フレームをドロップすることを選択するかもしれません。受信されたフラグメント上の配列番号は断片がスキップされたことを示した場合にこのように、部分的に再構成されたパケットは廃棄されてもよく、または受信機は、断片が順不同で到着するのを待機することを望むかもしれません。後者の場合には、再構成タイマーが長すぎる期間ためのバッファリソースをロック回避するために使用されなければなりません。
Dropping out-of-order fragments on a given PW can provide a considerable scalability advantage for network equipment performing reassembly. If out-of-order fragments are a relatively rare event on a given PW, throughput should not be adversely affected by this. Note, however, if there are cases where fragments of a given frame are received out-or-order in a consistent manner (e.g., a short fragment is always switched ahead of a larger fragment), then dropping out-of-order fragments will cause the fragmented frame never to be received. This condition may result in an effective denial of service to a higher-lever application. As such, implementations fragmenting a PW frame MUST at the very least ensure that all fragments are sent in order from their own egress point.
与えられたPWのドロップアウト・オブ・オーダーフラグメントは、ネットワーク機器を行う再構築のために、かなりのスケーラビリティの利点を提供することができます。アウトオブオーダーフラグメントが与えられたPWで比較的稀な事象であれば、スループットに悪影響をこれによって影響されるべきではありません。ただし、与えられたフレームのフラグメントが一致するようにして、または順序受信される場合がある場合（例えば、短い断片は常に前方大きい断片の切り替えられ）、次いで、アウトオブオーダ断片であろうドロップ決して受け取らないことにする断片化されたフレームを引き起こします。この条件は、より高いレバーアプリケーションにサービスの有効な拒否をもたらし得ます。このように、PWフレームを断片化の実装は非常に少なくともすべての断片がそれら自身の出口点から順に送信されることを保証しなければなりません。
An implementation may also choose to allow reassembly of a limited number of fragmented frames on a given PW, or across a set of PWs with reassembly enabled. This allows for a more even distribution of reassembly resources, reducing the chance that a single or small set of PWs will exhaust all reassembly resources for a node. As with dropping out-of-order fragments, there are perceivable cases where this may also provide an effective denial of service. For example, if fragments of multiple frames are consistently received before each frame can be reconstructed in a set of limited PW reassembly buffers, then a set of these fragmented frames will never be delivered.
実装はまた、所与のPWに断片化されたフレームの限られた数の再組み立てを可能にするように選択するか、または再組み立てとのPWのセットにわたって有効にしてもよいです。これは、のPW単一または小さなセットは、ノードのすべての再構築リソースを使い果たしする機会を減らし、再構築リソースのより均一に分布させることができます。アウト・オブ・オーダーの断片を落とすと同じように、これはまた、サービスの効果的な拒否を提供することができる知覚場合があります。複数のフレームのフラグメントは、一貫して各フレームの前に受信された場合、例えば、限定されたPW再組み立てバッファのセットに再構成することができ、これらの断片化されたフレームのセットが配信されることはありません。
RFC 1990 headers use two bits that indicate the first and last fragments in a frame, and a sequence number. The sequence number may be either 12 or 24 bits in length (from [MLPPP]):
RFC 1990のヘッダは、フレーム内の最初と最後のフラグメント、およびシーケンス番号を示す2ビットを使用します。シーケンス番号は、長さが12または24ビットであってもよい（[MLPPP]から）。
0 7 8 15
+-+-+-+-+-------+---------------+
|B|E|0|0| sequence number |
+-+-+-+-+-------+---------------+
+-+-+-+-+-+-+-+-+---------------+
|B|E|0|0|0|0|0|0|sequence number|
+-+-+-+-+-+-+-+-+---------------+
| sequence number (L) |
+---------------+---------------+
Figure 6: RFC 1990 Header Formats
図6：RFC 1990ヘッダーフォーマット
PWE3 fragmentation takes advantage of existing PW sequence numbers and control bit fields wherever possible, rather than defining a separate header exclusively for the use of fragmentation. Thus, it uses neither of the RFC 1990 sequence number formats described above, relying instead on the sequence number that already exists in the PWE3 header.
PWE3断片化は、可能な限り、むしろ断片化の使用のために排他的に別のヘッダーを定義するよりも、既存のPWシーケンス番号及び制御ビットフィールドを利用します。これにより、既にPWE3ヘッダーに存在するシーケンス番号に代えて頼る、上述したRFC 1990のシーケンス番号の形式のどちらを使用します。
RFC 1990 defines two one-bit fields: a (B)eginning fragment bit and an (E)nding fragment bit. The B bit is set to 1 on the first fragment derived from a PPP packet and set to 0 for all other fragments from the same PPP packet. The E bit is set to 1 on the last fragment and set to 0 for all other fragments. A complete unfragmented frame has both the B and E bits set to 1.
（B）eginning断片ビットと（E）nding断片ビット：RFC 1990年2つの1ビットフィールドを定義します。 BビットはPPPパケットから導出され、同じPPPパケットから他のすべてのフラグメントに対して0に設定された第1の断片上に1に設定されています。 Eビットが最後のフラグメントで1に設定され、他のすべてのフラグメントに対して0に設定されています。完全な断片化されていないフレームは、BとEビットの両方が1に設定されています。
PWE3 fragmentation inverts the value of the B and E bits, while retaining the operational concept of marking the beginning and ending of a fragmented frame. Thus, for PW the B bit is set to 0 on the first fragment derived from a PW frame and set to 1 for all other fragments derived from the same frame. The E bit is set to 0 on the last fragment and set to 1 for all other fragments. A complete unfragmented frame has both the B and E bits set to 0. The motivation behind this value inversion for the B and E bits is to allow complete frames (and particularly, implementations that only support complete frames) simply to leave the B and E bits in the header set to 0.
断片化されたフレームの開始と終了をマーキングの動作概念を保持しつつ、PWE3の断片化は、BとEビットの値を反転します。したがって、PWのためのBビットはPWフレームに由来し、同じフレームに由来する他のすべてのフラグメントに対して1に設定された第1の断片に0に設定されています。 Eビットが最後のフラグメントで0に設定され、他のすべてのフラグメントに対して1に設定されています。完全な断片化されていないフレームは、BとEビットはBとEビットは、この値反転の背後にある動機は、完全なフレーム（そして唯一の完全なフレームをサポートし、特に、インプリメンテーション）は、単にBとEを残すことを可能にすることである0に設定されている両方0に設定するヘッダのビット。
In order to support fragmentation, the B and E bits MUST be defined or identified for all PWE3 tunneling protocols. Sections 4 and 5 define these locations for PWE3 MPLS [Control-Word], L2TPv2 [L2TPv2], and L2TPv3 [L2TPv3] tunneling protocols.
断片化をサポートするために、BとEビットを定義する必要があり、またはすべてのPWE3トンネリングプロトコルの同定します。セクション4及び5は、PWE3 MPLS [コントロール・ワード]、L2TPv2 [L2TPv2]、およびL2TPv3の【のL2TPv3]トンネリングプロトコルに対するこれらの位置を定義します。
Authors' Addresses
著者のアドレス
Andrew G. Malis Tellabs 1415 West Diehl Road Naperville, IL 60563
アンドリューG. Malisテラブス1415西ディール道路ネーパーヴィル、IL 60563
EMail: Andy.Malis@tellabs.com
メールアドレス：Andy.Malis@tellabs.com
W. Mark Townsley Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
W.マークTownsleyシスコシステムズ7025キットクリーク道路私書箱14987リサーチトライアングルパーク、NC 27709
EMail: mark@townsley.net
メールアドレス：mark@townsley.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（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.
この文書では、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 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 HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。