[要約] RFC 4623は、PWE3フラグメンテーションと再結合に関する標準仕様であり、エッジからエッジまでの仮想回線のエミュレーションをサポートします。目的は、大きなパケットを複数の小さなパケットに分割し、再結合することで、ネットワークの効率性と信頼性を向上させることです。
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
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 Internet Society (2006).
Copyright（c）The Internet Society（2006）。
Abstract
概要
This document defines a generalized method of performing fragmentation for use by Pseudowire Emulation Edge-to-Edge (PWE3) protocols and services.
このドキュメントは、Pseudowireエミュレーションエッジツーエッジ（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:
Pseudowireエミュレーションエッジツーエッジアーキテクチャドキュメント[アーキテクチャ]は、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.
擬似具体（PW）ペイロードは通常、単一のIPまたはMPLSパケットスイッチネットワーク（PSN）プロトコルデータユニット（PDU）として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.
断片化および再組み立て手順にはシーケンス番号が必要なため、断片化されたパケットのシーケンス番号フィールドを使用する必要があります（MPLSとL2TP3カプセルのそれぞれのシーケンス番号フィールドの位置については、セクション4.1および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.
使用中の特定の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].
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全体のMTUサイズの適切な構成と管理、および発信元のホストで動作する適応測定（[Pathmtu]とともに適応的な測定値が含まれます（[Pathmtu]、[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パケットをフラグメントして転送できる場合、CEから到着するフラグメントパケットを断片化し、IPv4フラグメントをその付属のフレーミングで転送する可能性があります（AC AC）PWの上。アーキテクチャには、IPv4の断片化はPWに到達する前に発生し、そのPWTypeの通常の方法で転送するために複数のフレームを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-Control]で信号手順を使用する場合、VCラベルを宣伝する際にフラグメンテーションの使用を知らせるために使用される擬似ワイヤーインターフェイスパラメーターサブ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-Control]シグナル伝達が使用されていない場合、Fragmentationを使用するかどうかは送信者で構成する必要があります。
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で（壊れていない）ペイロード全体が運ばれることを示します。最初のフラグメント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.
PATH MTU [PATHMTU] [PATHMTUV6]を使用して、フラグメントの最大サイズを動的に決定できます。PATH MTUのMPLSへの適用については、[LabelStack]で説明します。フラグメントの最大サイズも構成できます。[MPLS-Control]の信号界面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 [L2TPV2]ヘッダーのBおよびEビットの位置と、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パケットに適用される一般的なメカニズムよりも優位性を獲得できます。さらに、特定のノードに到着するすべてのIPトラフィックの再組み立てを可能にするよりも、PWの断片化は、一部またはすべてのPWSに対して選択的な方法でより簡単に有効になる場合があります。
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内でフラグメンテーションが有効になっている場合、そのPWのIPパケット上のすべてのL2TPでDFビットを設定する必要があります。
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の自動調整のためにPATH MTU（[PathMTU]、[PathMTuv6]）に参加する必要があります。ペイロードがIPの場合、PATH MTUもペイロードレベルで使用する必要があります。
The constructs defined in this section for advertising fragmentation support in L2TP are applicable to [L2TPv3] and [L2TPv2].
L2TPでの広告断片化サポートのためにこのセクションで定義されているコンストラクトは、[L2TPV3]および[L2TPV2]に適用されます。
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は、着信コールレクエスト（ICRQ）、着信コールリプス（ICRP）、着信コール接続（ICCN）、発信コールリケスト（OCRQ）、発信-Call-Replyに存在する場合があります（OCRP）、発信コール接続（occn）、またはset-link-info（sli）メッセージ。受信した最新の値は、常に以前の値よりも優先され、SLIメッセージを介して受信した場合、セッションの寿命にわたって動的でなければなりません。2つの新しいAVP（MRRU）の1つは、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.
属性番号94のMRU（最大受信ユニット）は、この値を宣伝するPWの側面で売り上げ可能なL2TPカプセル化を含む、断片化または完全な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に設定する必要があります。長さ（隠す前）は8です。ベンダーIDは0のIETFベンダーIDです。
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に設定する必要があります。長さ（隠す前）は8です。ベンダーIDは0のIETFベンダーIDです。
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固有のサブレイヤーの先行ビットでビット2および3として定義されます（セクション7を参照）。
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
図6：デフォルトのL2固有のサブレーヤーのBおよびEビットの位置
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.
S（シーケンス）ビットは[L2TPV3]で定義されています。バリアント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特異的崇高の存在と形式は、[L2TPV3]のセクション5.4.4で定義されているL2固有のサブレイヤーAVP属性タイプ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ビットは、以下に示すように、L2TPV2ヘッダーの先行ビットでビット8および9として定義されます（セクション7を参照）。
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).
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].
セクション5.3および5.4で2つの追加のAVP属性が指定されています。[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固有のサブレーヤーの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.
著者は、この文書のレビューについて、Cisco SystemsのEric RosenとCarlos 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.
[コントロールワード] Bryant、S.、Swallow、G.、Martini、L。、およびD. McPherson、「Pseudowire Emulation Edge-to-Edge（PWE3）MPLS PSNを使用するための単語」、RFC 4385、2月2006年。
[IANA] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.
[IANA] Martini、L。、「Pseudowire Edge to Edge Emulation（PWE3）のIANAの割り当て」、BCP 116、RFC 4446、2006年4月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Rosen、E.、Tappan、D.、Fedorkow、G.、Rekhter、Y.、Farinacci、D.、Li、T。、およびA. Conta、「Mpls Label Stack Encoding」、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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。、およびB. Palter、「層」トンネリングプロトコル "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] Lau、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.、Lloyd、B.、McGregor、G.、Carr、D。、およびT. Coradetti、「The PPP Multilink Protocol（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.
[MPLS-Control] Martini、L.、Rosen、E.、El-Aawar、N.、Smith、T.、およびG. Heron、「Pseudowire Setup and Maintenance fut Label Distribution Protocol（LDP）」、RFC 4447、2006年4月。
[PATHMTU] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[Pathmtu] Mogul、J。およびS. Deering、「Path MTU Discovery」、RFC 1191、1990年11月。
[PATHMTUv6] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[Pathmtuv6] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のPath MTU Discovery」、RFC 1981、1996年8月。
[Architecture] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.
[アーキテクチャ] Bryant、S。およびP. Pate、「Pseudo Wire Emulation Edge-to-Edge（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）考慮事項更新」、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 Transport（Fast）上のフレームベースのATM」、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.、Reed、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] Postel、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.
[TinyFrag] Miller、I。、「小さなフラグメント攻撃のバリアントに対する保護（RFC 1858）」、RFC 3128、2001年6月。
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.
トランスミッションのために大きなパケットを小さなユニットに断片化することは新しいものではありません。1つの断片化と再組み立て方法は、RFC 1990、マルチリンクPPP [MLPPP]で定義されました。この方法は、フレームリレー[FRF.12]とATM [高速]ネットワークテクノロジーの両方にも採用されました。このドキュメントでは、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を許可することもできます。これにより、再組み立てリソースをより均等に配信できるようになり、PWSの単一または小さなセットがノードのすべての再組み立てリソースを排出する可能性が低くなります。オーダーの断片を落とすのと同様に、これが効果的なサービスの拒否を提供する可能性のある知覚可能なケースがあります。たとえば、各フレームを限定された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シーケンス番号と制御ビットフィールドを利用します。したがって、上記のRFC 1990シーケンス番号形式のいずれも使用しないため、代わりにPWE3ヘッダーに既に存在するシーケンス番号に依存します。
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.
RFC 1990は、2つの1ビットフィールドを定義しています。A（b）フラグメントビットと（e）ndingフラグメントビット。Bビットは、PPPパケットから派生した最初のフラグメントで1に設定され、同じPPPパケットの他のすべてのフラグメントに対して0に設定されています。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フレームから派生した最初のフラグメントで0に設定され、同じフレームから派生した他のすべてのフラグメントに対して1に設定されます。Eビットは最後のフラグメントで0に設定され、他のすべてのフラグメントに対して1に設定されます。完全なフレーミングされていないフレームには、BとEビットの両方が0に設定されています。BおよびEビットのこの値の反転の背後にある動機は、完全なフレーム（特に、完全なフレームのみをサポートする実装）をBとEのままにすることを許可することです。ヘッダーのビットは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.
断片化をサポートするには、すべてのPWE3トンネルプロトコルに対してBおよびEビットを定義または識別する必要があります。セクション4および5は、PWE3 MPLS [コントロールワード]、L2TPV2 [L2TPV2]、およびL2TPV3 [L2TPV3]トンネルプロトコルのこれらの位置を定義しています。
Authors' Addresses
著者のアドレス
Andrew G. Malis Tellabs 1415 West Diehl Road Naperville, IL 60563
Andrew G. Malis Tellabs 1415 West Diehl Road Naperville、IL 60563
EMail: Andy.Malis@tellabs.com
W. Mark Townsley Cisco Systems 7025 Kit Creek Road PO Box 14987 Research Triangle Park, NC 27709
W.マークタウンズリーシスコシステム7025キットクリークロードPOボックス14987リサーチトライアングルパーク、ノースカロライナ州27709
EMail: mark@townsley.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
Copyright（c）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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 provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポートアクティビティ（IASA）によって提供されます。