[要約] RFC 3308は、L2TPに差別化サービス拡張を提供するためのプロトコルです。その目的は、L2TPトンネル上でのトラフィックの優先順位付けと品質の制御を可能にすることです。
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
レイヤー2つのトンネルプロトコル（L2TP）差別化されたサービス拡張
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.
Copyright（c）The Internet Society（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.
このドキュメントでは、レイヤー2トンネリングプロトコル（L2TP）がL2TP制御接続の希望するホップごとの動作（PHB）コードと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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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）をサポートするメカニズムを提供していません。このドキュメントでは、L2TPが[RFC 3140]で定義されているように、L2TP制御接続とL2TPトンネル内の個々のセッションに関連付けられているように、L2TPが望ましいPHBコードを示すことができるメカニズムについて説明しています。
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）（PHB）を使用するようにトンネルイニシエーターの両方が望んでいることを示すものとして機能します。トンネルの制御接続内のすべてのパケットのコード。PHBは、[RFC 2475]で定義されているように、特定の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を含むStart-Control-Connection-Request（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.
トンネルイニシエーターがトンネルの確立を継続したい場合、CCDS AVPを含むSCCRQに応答してCCDS AVPを含むSCCRPを受け取ったとき、SCCCNを送信します。それ以外の場合は、接続を終了するためにトンネルターミネーターに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.
トンネルターミネーターがCCDのサポートを提供する場合、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に設定されています）、オプション（MBITは設定されていません）です。このAVPの長さ（隠す前）は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の間にエンドツーエンド接続が確立されると、LACとLNSの間にL2TPセッションが作成されます。接続に関連するデータグラムは、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の存在は、セッションイニシエーターがセッションイニシエーターとターミネーターの両方に、AVPのPHBで示された（PHB）（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.
セッションターミネーターが要求されたPHBコードをサポートしていない場合、SDS AVPを含む、受信コールリケスト（ICRQ）または発信コールリケスト（OCRQ）を受領すると、セッションターミネーターはSDS AVPを無視し、ICRPを送信する必要がありますまたは、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.
SDS AVPを含むICRQまたはOCRQに応答してSDS AVPを含むICRPまたはOCRPを受け取ると、セッションイニシエーターがSDS AVPの採用を省略したい場合、[RFC 2661]で定義されているようにセッション確立を継続します。それ以外の場合、接続を終了するためにセッションターミネーターに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コードのローカルポリシーに相談するときに1つのセッションを別のセッションと区別するのを支援するために、セッションイニシエーターは識別子または識別子を使用して、Proxy Authen名AVPなどのAVPに埋め込まれた識別子の組み合わせを使用します。番号AVP、およびサブアドレスAVP。プロキシ認証名AVPが識別器として使用される場合、ICRQまたはOCRQに存在する必要があります。PHBコードの検索に使用される指定されたDS識別子は、構成可能である必要があります。
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のサポートを提供する場合、指定されたDS識別AVP（LACとLNSの管理者間の帯域外契約を介して）を使用して、ローカルポリシーに相談し、ローカルポリシーが要求されたPHBを許可するかどうかを決定する必要がありますこのセッションで使用するコード。要求された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) ターミネーターがセッションに使用する意思があるPHBコードを示すSDS AVPを含む、着信コールリピュライ（ICRP）または発信-Call-Reply（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].
セッションイニシエーターがICRPまたはOCRQで要求された値以外の値を持つSDS AVPを含むICRPまたはOCRPを受信し、セッションイニシエーターが値を使用したくない場合、セッションイニシエーターは結果コードを含むCDNメッセージを送信する必要があります12 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ビットは設定されていません）。このAVPの長さ（隠す前）は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は、2つのL2TPピア間の制御接続のDiffServを信号にするために使用され、SDS AVPはデータ接続に使用されます。1つのAVPで合図されたPHBコードは、他のAVPでシグナルが表示されるPHBコードに意味がないはずです。実装では、いずれかまたは両方の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コードは、[RFC 3140]で定義されているPERホップ動作（PHB）エンコードを使用して、左正当化された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.
このドキュメントで定義されている適切なDS AVPを採用しているL2TPトンネル制御接続または個々のL2TPセッションの確立を成功させると、LACとLNSの両方が現在のDSドメインの独自のPHB-DSCPマッピングを使用して、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 IDを使用して信号を送信したPHBのセットが、単一のPHBを使用して個々の接続内で追加のパケットを並べ替えてはならないことを要求しています。CCDSおよびSDS AVPには1つの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接続が任意の数のDSドメインを横断する可能性があるため、L2TPを介したシグナルPHBSがDSCPをシグナルよりも適切であり、L2TP接続の一貫したエンドツーエンドの差別化サービスを維持するためです。[RFC 2983]に従って、交渉されたPHBは、トンネルイングレスノードの現在のDSドメインのローカルで定義されたDSCPにマッピングされます。DSドメイン境界ノードでは、DSCPSを外側IPヘッダーのDSフィールドに書き換えることができるため、DSCPSは常にパケットが入っている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で定義されている「CCDS AVP」に47の値を割り当て、セクション6.1で定義されているSDS AVPの値48を割り当てました。
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はまた、CCDS値の不一致による制御接続を切断するために8のL2TP結果コード値（STOPCCN）、およびSDS値の不一致によるコールを切断するために12を割り当てました（CDN）。
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.
David Black、W。MarkTownsley、Nishit Vasavada、Andy Koscinski、John Shriverのレビューと洞察に満ちたフィードバックに感謝します。
[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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.
[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] Blake、S.、Black、D.、Carlson、Z.、Davies、E.、Wang、Z。、およびW. Weiss、「差別化されたサービスの建築」、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.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G。およびB. Palter、「レイヤー2トンネルプロトコル（L2TP）」、RFC 2661、1999年8月。
[RFC 2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC 2983] Black、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] Black、D.、Brim、S.、Carpenter、B。and F. Le Faucheur、「ホップの動作識別コード」、RFC 3140、2001年6月。
Pat R. Calhoun 110 Nortech Parkway San Jose, CA 95134-2307
パットR.カルホーン110ノルテックパークウェイサンノゼ、カリフォルニア95134-2307
Phone: +1 408.941.0500
EMail: pcalhoun@bstormnetworks.com
Wei Luo Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134
Wei Luo Cisco Systems、Inc。170 West Tasman Drive San Jose、CA 95134
Phone: +1 408.525.6906
EMail: luo@cisco.com
Danny McPherson TCB
ダニー・マクファーソンTCB
Phone: +1 303.470.9257
EMail: danny@tcb.net
Ken Peirce Malibu Networks, Inc. 1107 Investment Blvd, Suite 250 El Dorado Hills, CA 95762
Ken Peirce Malibu Networks、Inc。1107 Investment Blvd、Suite 250 El Dorado Hills、CA 95762
Phone: +1 916.941.8814
EMail: Ken@malibunetworks.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。