Network Working Group P. Calhoun
Request for Comments: 3308 Black Storm Networks
Category: Standards Track W. Luo
Cisco Systems, Inc.
D. McPherson
TCB
K. Peirce
Malibu Networks, Inc.
November 2002
Layer Two Tunneling Protocol (L2TP)
Differentiated Services Extension
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document describes mechanisms which enable the Layer Two Tunneling Protocol (L2TP) to negotiate desired Per Hop Behavior (PHB) code for the L2TP control connection, as well as individual sessions within an L2TP tunnel.
この文書では、L2TPトンネル内L2TPコントロール接続のための所望当たりホップの動作（PHB）コード、ならびに個々のセッションをネゴシエートするレイヤ2トンネリングプロトコル（L2TP）を有効に機構が記載されています。
L2TP provides a standard method for tunneling PPP packets. The current specification provides no provisions for supporting Differentiated Services (diffserv) over the L2TP control connection or subsequent data sessions. As a result, no standard mechanism currently exists within L2TP to provide L2TP protocol negotiations for service discrimination.
L2TPは、PPPパケットをトンネリングするための標準的な方法を提供します。現在の仕様では、L2TP制御接続又は後続のデータセッションで差別化サービス（DiffServの）をサポートするための規定を提供しません。その結果、標準的なメカニズムは、現在、サービス識別のためのL2TPプロトコルネゴシエーションを提供するためにL2TP内に存在しません。
Table of Contents
目次
1. Specification of Requirements ............................... 2
2. Introduction ................................................ 2
3. Control Connection Operation ................................ 3
3.1. Control Connection DS AVP (SCCRQ, SCCRP) .................... 4
4. Session Operation ........................................... 4
4.1. Session DS AVP (ICRQ, ICRP, OCRQ, OCRP) ..................... 6
5. DS AVPs Correlation ......................................... 6
6. PHB Encoding ................................................ 6
7. DSCP Selection .............................................. 7
8. Packet Reordering and Sequence Numbers ...................... 7
9. Crossing Differentiated Services Boundaries ................. 7
10. IANA Considerations ......................................... 8
11. Security Considerations ..................................... 8
12. Acknowledgements ............................................ 8
13. References .................................................. 8
14. Authors' Addresses .......................................... 9
15. Full Copyright Statement .................................... 10
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC 2119]に記載されているように解釈されます。
The L2TP specification currently provides no mechanism for supporting diffserv (DS). This document describes mechanisms that enable L2TP to indicate desired PHB code, as defined in [RFC 3140], to be associated with an L2TP control connection, as well as individual sessions within an L2TP tunnel.
L2TP仕様は現在のDiffServ（DS）を支持するためのメカニズムを提供しません。この文書は、[RFC 3140]で定義されたL2TPトンネル内のL2TP制御接続、ならびに個々のセッションに関連することとして、所望のPHBコードを示すためにL2TPをイネーブル機構が記載されています。
The actual bit interpretation of the DS field is beyond the scope of this document, and is purposefully omitted. This document is concerned only with defining a uniform exchange and subsequent mapping mechanism for the DS AVPs.
DSフィールドの実際のビットの解釈は、このドキュメントの範囲を超えて、かつ意図的に省略されています。この文書は、DSのAVPのための均一な交換とその後のマッピングメカニズムを定義することに関する。
As defined in [RFC 2661], a control connection operates in-band over a tunnel to control the establishment, release, and maintenance of sessions and of the tunnel itself. As such, this document provides a mechanism to enable discrimination of L2TP control messages from other packets. For this purpose, we introduce the Control Connection DS (CCDS) AVP.
[RFC 2661]で定義されるように、制御接続は、セッションのトンネル自体の確立、解放、および維持を制御するために、トンネルを介して帯域内で動作します。そのようなものとして、この文書は、他のパケットからL2TP制御メッセージの識別を可能にするための機構を提供します。この目的のために、我々はコントロールコネクションDS（CCDS）AVPをご紹介します。
The presence of the CCDS AVP serves as an indication to the peer (LAC or LNS) that the tunnel initiator wishes both the tunnel initiator and terminator to use the per-hop behavior(s) (PHB(s)) indicated by the AVP's PHB code for all packets within the tunnel's control connection. A PHB is a description of the externally observable forwarding behavior of a DS node applied to a particular DS behavior aggregate, as defined in [RFC 2475]. The most simple example of a PHB is one which guarantees a minimal bandwidth allocation of a link to a behavior aggregate.
CCDS AVPの存在はAVPのPHBによって示されるトンネル・イニシエータは、ホップ単位動作（複数可）（PHB（複数可））を使用するトンネル・イニシエータとターミネーターとの両方を望んでいることをピア（LACまたはLNS）への指示として役立ちますトンネルの制御接続内のすべてのパケットのためのコード。 [RFC 2475]で定義されるようにPHBは、特定のDS行動集合に適用されるDSノードの外部から観察可能な転送動作について説明します。 PHBの最も簡単な例は、行動の集約へのリンクの最小帯域幅割り当てを保証です。
Upon receipt of a Start-Control-Connection-Request (SCCRQ) containing the CCDS AVP, if the tunnel terminator provides no support for the CCDS AVP it MUST ignore the AVP and send an SCCRP to the tunnel initiator without the CCDS AVP. The tunnel initiator interprets the absence of the CCDS AVP in the SCCRP as an indication that the tunnel terminator is incapable of supporting CCDS.
CCDS AVPを含むスタートコントロール接続要求（SCCRQ）を受信すると、トンネル・ターミネータは、CCDS AVPのためのサポートを提供しない場合、それはAVPを無視しCCDS AVPなしトンネルイニシエータにSCCRPを送らなければなりません。トンネル・イニシエータは、トンネル・ターミネータは、CCDを支持することができないという指示としてSCCRPにおけるCCDS AVPの不在を解釈します。
Upon receipt of an SCCRP that contains no CCDS AVP in response to a SCCRQ that contained a CCDS AVP, if the tunnel initiator wants to continue tunnel establishment it sends an SCCCN. Otherwise, it sends a StopCCN to the tunnel terminator to end the connection. The StopCCN control message MUST contain the Result Code 8 that indicates CCDS AVP value (47) as the reason for sending the StopCCN.
トンネル・イニシエータは、それがSCCCNを送信するトンネル確立を続行したい場合、CCDS AVPを含まSCCRQに応答しないCCDS AVPを含まないSCCRPを受信します。それ以外の場合は、接続を終了するためにトンネルターミネータにStopCCNを送ります。 StopCCN制御メッセージはStopCCNを送信する理由としてCCDS AVP値（47）を示す結果コード8を含まなければなりません。
If the tunnel terminator provides support for CCDS, it SHOULD use the Host Name AVP embedded in SCCRQ to consult its local policy, and to determine whether local policy permits the requested PHB code to be used on this control connection. If it is unwilling or unable to support the requested PHB code after consulting the local policy, the tunnel terminator MUST send an SCCRP control message containing a CCDS AVP indicating the value it is willing to use. If the CCDS AVP value is the same as the one in the SCCRQ, it signals the acceptance of the requested PHB code. If the value is different it serves as a counter-offer by the tunnel terminator.
トンネル・ターミネータは、CCDSのためのサポートを提供する場合、それはそのローカルポリシーを参照するSCCRQに埋め込まれたホスト名AVPを使用する必要があり、ローカルポリシーは、この制御接続に使用される要求されたPHBコードを許可するかどうかを決定します。それは不本意またはローカルポリシーに相談した後、要求されたPHBコードをサポートすることができない場合、トンネル・ターミネータは、使用する意思がある値を示すCCDSのAVPを含むSCCRP制御メッセージを送信しなければなりません。 CCDS AVP値がSCCRQにおけるものと同じである場合、それは要求されたPHBコードの受け入れを知らせます。値が異なる場合には、トンネル・ターミネータによってカウンター・オファーとして機能します。
If the tunnel initiator receives an SCCRP that contains a CCDS AVP with a value other than that requested in the SCCRQ, the tunnel initiator SHOULD check the PHB code against its own policy. If it is unwilling to use the value, the tunnel initiator MUST send a StopCCN control message containing the Result Code 8 that indicates CCDS AVP value (47) as the reason for sending the StopCCN.
トンネル・イニシエータはSCCRQに要求された以外の値でCCDS AVPが含まSCCRPを受信した場合、トンネル・イニシエータは、自身のポリシーに対するPHBコードを確認してください。それは値を使用することは不本意である場合、トンネル・イニシエータはStopCCNを送信するための理由としてCCDS AVP値（47）を示す結果コード8を含むStopCCNコントロールメッセージを送らなければなりません。
The CCDS AVP is encoded as Vendor ID 0, and the Attribute Type is 47.
CCDS AVPはベンダーID 0として符号化され、属性タイプは47です。
Each CCDS AVP is encoded as follows:
次のように各CCDS AVPは、符号化されています：
Vendor ID = 0 Attribute = 47
ベンダーID = 0属性= 47
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 47 | PHB Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be present in the following message types: SCCRQ and SCCRP. This AVP MAY be hidden (the H-bit set to 0 or 1) and is optional (M-bit not set). The length (before hiding) of this AVP MUST be 8 octets. The encoding of the PHB code is described in Section 6.
このAVPは、次のメッセージタイプに存在していてもよい：SCCRQとSCCRP。このAVPは、隠された（H-ビットが0または1に設定）及び（M-ビットセットされていない）任意であるかもしれません。このAVPのLength（隠れることの前の）は8つのオクテットでなければなりません。 PHBコードの符号化は、セクション6で説明されています。
As defined in [RFC 2661], an L2TP session is connection-oriented. The LAC and LNS maintain states for each call that is initiated or answered by an LAC. An L2TP session is created between the LAC and LNS when an end-to-end connection is established between a Remote System and the LNS. Datagrams related to the connection are sent over the tunnel between the LAC and LNS. As such, this document provides a mechanism to enable discrimination for packets within a particular session from those in other sessions. For this purpose, we introduce the Session DS (SDS) AVP.
[RFC 2661]で定義されるように、L2TPセッションは接続指向です。 LACとLNSはLACによって開始または応答されるコールごとに状態を維持します。エンドツーエンドの接続がリモートシステムとLNSの間で確立されたときにL2TPセッションはLACとLNSの間で作成されます。接続に関連するデータグラムはLACとLNS間のトンネルを介して送信されます。そのようなものとして、この文書は、他のセッションのものから特定のセッション内のパケットの識別を可能にするための機構を提供します。この目的のために、我々は、セッションDS（SDS）AVPをご紹介します。
The presence of the SDS AVP serves as an indication to the peer (LAC or LNS) that the session initiator wishes both the session initiator and terminator to use the per-hop behavior(s) (PHB(s)) indicated by the AVP's PHB code for all packets within the session.
SDS AVPの存在は、セッション開始剤がホップ単位動作（複数可）（PHB（複数可））を使用するセッション開始及び終端の両方を望んでいることをピア（LACまたはLNS）への指示として役立つAVPのPHBによって示されますセッション内のすべてのパケットのためのコード。
Upon receipt of an Incoming-Call-Request (ICRQ) or Outgoing-Call-Request (OCRQ) containing the SDS AVP if the session terminator provides no support for the requested PHB code, the session terminator MUST ignore the SDS AVP and send an ICRP or OCRP to the session initiator without the SDS AVP. The session initiator interprets the absence of the SDS AVP in the ICRP or OCRP as an indication that the session terminator is incapable of supporting SDS.
着信-要求（ICRQ）またはセッションターミネータが要求されたPHBコードのためのサポートを提供していない場合は、セッションターミネータがSDSのAVPを無視して、ICRPを送らなければなりませんSDS AVPを含む発信・コール要求（OCRQ）を受信するとまたはSDS AVPなしでセッション開始剤OCRP。セッションイニシエータは、セッションターミネータがSDSを支持することができないという指示としてICRP又はOCRPにおけるSDS AVPの不在を解釈します。
Upon receipt of an ICRP or OCRP that contains no SDS AVP in response to an ICRQ or OCRQ that contained an SDS AVP, if the session initiator is willing to omit employing SDS AVP it continues session establishment as defined in [RFC 2661]. Otherwise, it sends a CDN to the session terminator to end the connection. The CDN control message MUST contain the Result Code 12 that indicates SDS AVP value (48) as the reason for sending the CDN.
[RFC 2661]で定義されるように、セッション開始剤がSDS AVPを用い省略する意思がある場合、SDS AVPを含まICRQまたはOCRQに応答しないSDS AVPを含まないICRP又はOCRPを受信すると、セッションの確立を継続します。それ以外の場合は、接続を終了するために、セッションの終端にCDNを送ります。 CDN制御メッセージはCDNを送る理由としてSDS AVP値（48）を示す結果コード12を含まなければなりません。
In order to help the session terminator to distinguish one session from another when consulting the local policy of the PHB code, the session initiator MAY use the identifier or a combination of identifiers embedded in AVPs such as Proxy Authen Name AVP, Calling Number AVP, Called Number AVP, and Sub-Address AVP. When Proxy Authen Name AVP is used as a distinguishor, it SHOULD be present in the ICRQ or OCRQ. The designated DS identifier(s) used for looking up the PHB code SHOULD be configurable.
PHBコードのローカルポリシーを相談するときから別のセッションを区別するために、セッションターミネータを助けるために、セッション開始剤が呼び出され、数AVPを呼び出すと、識別子や、プロキシのAuthen名AVPとしてのAVPに埋め込まれた識別子の組み合わせを使用することができます数AVP、およびサブアドレスAVP。プロキシのAuthen名AVPをdistinguishorとして使用される場合、それはICRQまたはOCRQで存在すべきです。 PHBコードをルックアップするために使用される指定されたDS識別子（S）設定であるべきです。
If the session terminator provides support for SDS, it SHOULD use the the designated DS identification AVP (via out-of-band agreement between the administrators of the LAC and LNS) to consult the local policy and determinate whether the local policy permits the requested PHB code to be used on this session. If it is unwilling or unable to support the requested PHB code the session terminator MUST do one of the following:
セッションターミネータがSDSのためのサポートを提供している場合は、ローカルポリシーが要求されたPHBを許可するかどうか、それはローカルポリシーと確定を相談する（LACとLNSの管理者間の帯域外の合意を経て）指定されたDS識別AVPを使用すべきですこのセッションで使用するコード。それは要求されたPHBコードをサポートしたくないか、できない場合はセッションターミネータは、次のいずれかを行う必要があります
1) Send a CDN message containing the Result Code 12 that indicates SDS AVP value (48) as the reason for sending the CDN.
1）CDNを送る理由としてSDS AVP値（48）を示す結果コード12を含むCDNメッセージを送ります。
2) Send an Incoming-Call-Reply (ICRP) or Outgoing-Call-Reply (OCRP) message containing an SDS AVP indicating the PHB code the terminator is willing to use for the session.
2）着信リプライ（ICRP）またはターミネーターがセッションに使用する意思があるPHBコードを示すSDSのAVPを含む出射コール応答（OCRP）メッセージを送ります。
If the session terminator supports the PHB code in the SDS AVP session establishment MUST continue as defined in [RFC 2661].
セッションターミネータが継続しなければならないSDS AVPのセッション確立におけるPHBコードをサポートしている場合は、[RFC 2661]で定義されています。
If the session initiator receives an ICRP or OCRP that contains an SDS AVP with a value other than that requested in the ICRQ or OCRQ, and the session initiator is unwilling to use the value, the session initiator MUST send a CDN message containing the Result Code 12 that indicates SDS AVP value (48) as the reason for sending the CDN. If the session initiator receives an ICRP or OCRP that contains an SDS AVP with a value other than that requested in the ICRQ or OCRQ, and the session initiator is willing to use the value, the session initiator MUST proceed as indicated in [RFC 2661].
セッションイニシエータがICRQかOCRQに要求されたもの以外の値とSDS AVPが含まれているICRPかOCRPを受け取り、セッション開始者が値を使用したくない場合には、セッション開始剤は、結果コードを含むCDNメッセージを送らなければなりませんCDNを送る理由としてSDS AVP値（48）を示している12。セッション開始剤はICRQまたはOCRQに要求されたもの以外の値を用いてSDS AVPが含まICRP又はOCRPを受信し、セッション開始値を使用する意思がある場合は[RFC 2661]に示されているように、セッション開始が進行しなければなりません。
The SDS AVP is encoded as Vendor ID 0, and the Attribute Value is 48.
SDS AVPはベンダーID 0として符号化され、属性値は48です。
Each SDS AVP is encoded as follows:
次のようにそれぞれのSDS AVPは、符号化されています：
Vendor ID = 0 Attribute = 48
ベンダーID = 0属性= 48
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 48 | PHB Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This AVP MAY be present in the following message types: ICRQ, ICRP, OCRQ and OCRP. This AVP MAY be hidden (the H-bit set to 0 or 1) and is optional (M-bit is not set 0). The length (before hiding) of this AVP MUST be 8 octets. The encoding of the PHB code is described in Section 6.
このAVPは、次のメッセージタイプに存在しているかもしれませ：ICRQ、ICRP、OCRQ、およびOCRP。このAVPは、隠された（H-ビットが0または1に設定）と（Mビットが0に設定されていない）任意であるかもしれません。このAVPのLength（隠れることの前の）は8つのオクテットでなければなりません。 PHBコードの符号化は、セクション6で説明されています。
CCDS AVP and SDS AVP are independent of each other. CCDS AVP is used to signal diffserv for the control connection between two L2TP peers, while SDS AVP is used for data connection. The PHB code signaled in one AVP SHOULD NOT have any implication on the PHB code signaled in the other AVP. Implementations MAY choose to implement either or both DS AVPs, and operations MAY choose to enable diffserv on either or both types of connections.
CCDS AVPとSDS AVPは、互いに独立しています。 CCDS AVPは、SDS AVPは、データ接続のために使用されている間、2つのL2TPピア間の制御接続のためのDiffServを知らせるために使用されます。 PHBコードは、AVPは、他のAVPで合図PHBコード上の任意の意味を持つべきではない1で合図をしました。実装は、いずれかまたは両方のDS AVPを実装することを選択することができ、操作が接続のいずれか、または両方のタイプでのDiffServを有効にするために選ぶかもしれません。
The PHB code is a left-justified 16-bit field using Per Hop Behavior (PHB) encoding defined in [RFC 3140]. Note that [RFC 3140] and its successor are the ultimate authority defining PHB encoding.
PHBコードあたりのホップの動作（PHB）[RFC 3140]で定義されたエンコーディングを使用して左詰め16ビットのフィールドです。 [RFC 3140]とその後継者がPHBエンコーディングを定義究極の権威であることに留意されたいです。
Upon successful establishment of an L2TP tunnel control connection or individual L2TP session employing the appropriate DS AVP defined in this document, both LAC and LNS MUST use their own PHB-to-DSCP mappings of their present DS domains to map the PHB to a DSCP and place it in the DS field of the outer IP header of packets transmitted on the connection.
L2TPトンネル制御接続又は本文書で定義された適切なDS AVPを用いた個々のL2TPセッションの成功確立時に、LACとLNSの両方がDSCPにPHBをマッピングするために彼らの現在のDSドメインの独自のPHB対DSCPマッピングを使用しなければならないと接続上で送信されたパケットの外側IPヘッダのDSフィールドに置き。
The requirements or rules of each service and DSCP mapping are set through administrative policy mechanisms which are outside the scope of this document.
各サービスとDSCPマッピングの要件や規則は、この文書の範囲外で管理ポリシーメカニズムを介して設定されています。
[RFC 2474] RECOMMENDS that PHB implementations not cause reordering of packets within an individual connection. [RFC 3140] requires that a set of PHBs signaled using a single PHB ID MUST NOT cause additional packet reordering within an individual connection vs. using a single PHB. Since the CCDS and SDS AVPs contain one PHB ID, use of diffserv PHBs in accordance with this specification should not cause additional packet reordering within an L2TP control or data connection.
[RFC 2474]はPHBの実装は、個々の接続内のパケットの並び替えを引き起こさないことをお勧めします。 [RFC 3140]はのPHBのセットは、単一のPHBを使用して対個々の接続内で追加のパケットの並べ替えを引き起こしてはならない単一PHBのIDを使用して通知する必要があります。 CCDSとSDSのAVPの一つPHBのIDを含んでいるので、この仕様書に基づいてのDiffServのPHBの使用はL2TPコントロールまたはデータ接続内で並べ替え、追加のパケットが発生することはありません。
Sequence numbers are required to be present in all control messages and are used to provide reliable delivery on the control connection, as defined in [RFC 2661]. While packet reordering is inevitably as much a function of the network as it is local traffic conditioning, the probability of it occurring when employing the CCDS AVP is same as when not employing the AVP. Data messages MAY use sequence numbers to reorder packets and detect lost packets.
シーケンス番号は、すべての制御メッセージ中に存在することが必要であり、[RFC 2661]で定義されるように、制御接続上の信頼できる配信を提供するために使用されます。パケットの並べ替えは、必然的に、ローカル交通調節であるようなネットワークのような多くの機能であるが、CCDS AVPを使用する場合、それが起こる確率はAVPを使用しない場合と同じです。データメッセージは、パケットの順序を変更し、失われたパケットを検出するために、シーケンス番号を使用するかもしれません。
With the potential that an L2TP connection traverses an arbitrary number of DS domains, signaling PHBs via L2TP is more appropriate than signaling DSCPs, because it maintains a consistent end-to-end differentiated service for the L2TP connection. As per [RFC 2983], the negotiated PHBs are mapped to locally defined DSCPs of the current DS domain at the tunnel ingress node. At the DS domain boundary nodes, the DSCPs can be rewritten in the DS field of the outer IP header, so that the DSCPs are always with respect to whatever DS domain the packet happens to be in.
それはL2TP接続用の一貫したエンドツーエンドの差別化サービスを維持するため、L2TP接続はL2TPを介してのPHBシグナリングDSドメインの任意の数は、横断する電位と、のDSCPシグナリングよりも適切です。 [RFC 2983]に従って、ネゴシエートのPHBは、トンネル入口ノードにおける現在のDSドメインの局所的に定義されたのDSCPにマッピングされます。 DSCPパケットがであることを起こるどのDSドメインに対して常にあるようDSドメイン境界ノードでのDSCPを、外部IPヘッダのDSフィールドに書き換えることができます。
As a result, it is perfectly acceptable that the outermost DS field of packets arriving on a given control connection or session are not marked with the same DSCP value that was used by the tunnel ingress node.
その結果、所定の制御接続またはセッションに到着したパケットの最DSフィールドは、トンネル入口ノードによって使用されたのと同じDSCP値でマークされていないことが完全に許容可能です。
This document defines 2 L2TP Differentiated Services Extension AVPs. The IANA has assigned the value of 47 for the "CCDS AVP" defined in section 5.1 and the value of 48 for SDS AVP defined in section 6.1.
このドキュメントでは、2つのL2TP差別化サービス拡張AVPを定義します。 IANAはセクション5.1とセクション6.1で定義されたSDS AVPのための48の値で定義された「CCDS AVP」のための47の値を割り当てています。
IANA has also assigned L2TP Result Code values of 8 for disconnecting control connection due to mismatching CCDS value (StopCCN), and 12 for disconnecting call due to mismatching SDS value (CDN).
IANAはまた、原因SDS値（CDN）を不整合にコールを切断するミスマッチCCDS値（StopCCN）、及び12への制御接続を切断するための8のL2TP結果コード値を割り当てました。
This encoding in itself raises no security issues. However, users of this encoding should consider that modifying a DSCP MAY constitute theft or denial of service, so protocols using this encoding MUST be adequately protected. No new security issues beyond those discussed in [RFC 2474] and [RFC 2475] are introduced here.
これ自体のエンコーディングには、セキュリティ上の問題を提起していません。しかし、この符号化のユーザは、このエンコーディングを使用して、プロトコルが適切に保護されなければならないようにDSCPを変更することは、サービスの窃盗又は拒否を構成してもよいことを考慮すべきです。 [RFC 2474]と[RFC 2475]で説明したものを超えて新たなセキュリティ問題は、ここで紹介されていません。
Many thanks to David Black, W. Mark Townsley, Nishit Vasavada, Andy Koscinski and John Shriver for their review and insightful feedback.
彼らのレビューと洞察に満ちたフィードバックのためのデビッド・ブラック、W.マークTownsley、Nishit Vasavada、アンディKoscinskiとジョン・シュライバーに感謝します。
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC 1661]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC 2474] Nichols, K., Blake, S., Baker, F. and D. Black "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[RFC 2474]ニコルズ、K.、ブレイク、S.、ベイカー、F.とD.黒 "IPv4とIPv6ヘッダーとの差別化されたサービス分野（DS分野）の定義"、RFC 2474、1998年12月。
[RFC 2475] Blake, S., Black, D., Carlson, Z., Davies, E., Wang, Z. and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998.
[RFC 2475]ブレイク、S.、ブラック、D.、カールソン、Z.、デイヴィス、E.、王、Z.とW.ワイス、 "差別化サービスのためのアーキテクチャ"、RFC 2475、1998年12月。
[RFC 2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661, August 1999.
[RFC 2661] Townsley、W.、バレンシア、A.、ルーベンス、A.、ポール、G.、ゾルン、G.およびB. Palter、 "レイヤ2トンネルプロトコル（L2TP）"、RFC 2661、1999年8月。
[RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC 2983]ブラック、D.、 "差別化サービスおよびトンネル"、RFC 2983、2000年10月。
[RFC 3140] Black, D., Brim, S., Carpenter, B. and F. Le Faucheur, "Per Hop Behavior Identification Codes", RFC 3140, June 2001.
[RFC 3140]黒、D.、つば、S.、大工、B.およびF.ルFaucheur、 "当たりホップ行動識別コード"、RFC 3140、2001年6月。
Pat R. Calhoun 110 Nortech Parkway San Jose, CA 95134-2307
パットR.カルフーン110 Nortechパークウェイサンノゼ、CA 95134から2307
Phone: +1 408.941.0500 EMail: pcalhoun@bstormnetworks.com
電話：+1 408.941.0500 Eメール：pcalhoun@bstormnetworks.com
Wei Luo Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
魏羅シスコシステムズ、株式会社170西タスマン・ドライブサンノゼ、CA 95134
Phone: +1 408.525.6906 EMail: luo@cisco.com
電話：+1 408.525.6906 Eメール：luo@cisco.com
Danny McPherson TCB
ダニー・マクファーソンTCB
Phone: +1 303.470.9257 EMail: danny@tcb.net
電話：+1 303.470.9257 Eメール：danny@tcb.net
Ken Peirce Malibu Networks, Inc. 1107 Investment Blvd, Suite 250 El Dorado Hills, CA 95762
ケン・パースマリブネットワークス株式会社1107年投資ブルバード、スイート250エルドラドヒルズ、CA 95762
Phone: +1 916.941.8814 EMail: Ken@malibunetworks.com
電話：+1 916.941.8814 Eメール：Ken@malibunetworks.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。