RFC3145 日本語訳

Network Working Group                                           R. Verma
Request for Comments: 3145                           Deloitte Consulting
Category: Standards Track                                       M. Verma
                                                        3Com Corporation
                                                              J. Carlson
                                                        Sun Microsystems
                                                               July 2001

Vermaがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3145年のDeloitteコンサルティングカテゴリ: 標準化過程M.Verma 3Com社のJ.カールソンサン・マイクロシステムズ2001年7月

                   L2TP Disconnect Cause Information

L2TPは、原因が情報であると切断します。

Status of this Memo

この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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

Abstract

要約

   This document provides an extension to the Layer 2 Tunneling Protocol
   ("L2TP"), a mechanism for tunneling Point-to-Point Protocol (PPP)
   sessions.  L2TP lacks a mechanism for a host to provide PPP-related
   disconnect cause information to another host.  This information,
   provided by the extension described in this document, can be useful
   for accounting and debugging purposes.

このドキュメントはLayer2Tunnelingプロトコル("L2TP")、トンネリング二地点間プロトコル(ppp)セッションのためのメカニズムに拡大を供給します。 L2TPはホストがPPP関連の分離原因情報を別のホストに提供するメカニズムを欠いています。 本書では説明された拡大で提供されたこの情報は会計と目的をデバッグすることの役に立つ場合があります。

1.  Introduction

1. 序論

   L2TP [1] defines a general-purpose mechanism for tunneling PPP over
   various media.  By design, it insulates L2TP operation from the
   details of the PPP session that is being encapsulated by L2TP.  There
   are, however, cases where it may be desirable for PPP-specific
   disconnect information to be provided to an L2TP host (L2TP Access
   Concentrator [LAC] or L2TP Network Server [LNS]) in a descriptive
   format.  The lack of this information is especially a problem when
   the LAC and LNS are not owned or managed by the same entities.

L2TP[1]はトンネリングPPPのために様々なメディアの上で汎用メカニズムを定義します。 故意に、それはL2TPによってカプセル化されているPPPセッションの詳細からL2TP操作を隔離します。 しかしながら、ケースが描写的である形式でL2TPホスト(L2TP Access Concentrator[LAC]かL2TP Network Server[LNS])にPPP特有の分離情報を提供するのが望ましいかもしれないところにあります。 LACとLNSが同じ実体によって所有されてもいませんし、管理もされないとき、この情報の不足は特に問題です。

   The Result and Error Codes defined for L2TP specify only L2TP-
   specific disconnect information.  This document provides an
   additional Attribute Value Pair (AVP), called PPP Disconnect Cause
   Code, that MAY be used by an L2TP host to provide PPP-specific

L2TPのために定義されたResultとError CodesはL2TPの特定の分離情報だけを指定します。 このドキュメントはPPP特有の状態で提供するのにL2TPホストによって使用されるかもしれないPPP Disconnect Cause Codeと呼ばれる追加Attribute Value Pair(AVP)を提供します。

Verma, et al.               Standards Track                     [Page 1]

RFC 3145           L2TP Disconnect Cause Information           July 2001

Verma、他 標準化過程[1ページ]RFC3145L2TPは、2001年7月に原因が情報であると切断します。

   disconnect information to its peer.  This AVP should be used in
   conjunction with, and not as a replacement for, the L2TP Result and
   Error Code AVPs.

同輩に情報から切断してください。 交換とどんな交換としてこのAVPを使用するべきでない、L2TP ResultとError Code AVPs。

   The PPP Disconnect Cause Code AVP can also be used to provide a
   human-readable disconnect reason to the user.  This AVP should not
   have any effect on either the functioning of the tunnel or the
   functioning of the PPP session; it is for informational and logging
   purposes only.

また、人間読み込み可能な分離理由をユーザに提供するのにPPP Disconnect Cause Code AVPを使用できます。 このAVPはトンネルの機能かPPPセッションの機能のどちらかにどんな影響も与えるはずがありません。 それは情報と伐採目的だけのためのものです。

   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 BCP 14 [2].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14[2]で説明されるように本書では解釈されることであるべきですか?

2.  PPP Disconnect Cause Code AVP

2. pppは原因コードAVPから切断します。

   The AVP is valid in the L2TP Call-Disconnect-Notify (CDN) message
   only, and it MUST NOT be marked Mandatory.

AVPはL2TP Call分離に通知している(CDN)メッセージだけで有効です、そして、それはMandatoryであるとマークされてはいけません。

   The PPP Disconnect Cause Code AVP is encoded with Vendor ID 0 and an
   Attribute Type of PPP Disconnect Cause Code (46).  The length of the
   Value field MUST be at least 11 octets.  If the length is more than
   11 octets, the additional octets MUST contain a descriptive text in
   UTF-8 [3] format that can be displayed to the user or in a log file.
   The format of the AVP is shown below.

PPP Disconnect Cause Code AVPはVendor ID0とPPP Disconnect Cause Code(46)のAttribute Typeと共にコード化されます。 Value分野の長さは少なくとも11の八重奏であるに違いありません。 長さが11以上の八重奏であるなら、追加八重奏はユーザに表示できるUTF-8[3]書式かログファイルの説明文を含まなければなりません。 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| rsvd  |      Length       |          Vendor ID          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |         Attribute Type        |       Disconnect Code       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Control Protocol Number    |   Direction   | Message...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

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| rsvd| 長さ| ベンダーID| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 属性タイプ| コードから切断してください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 制御プロトコル番号| 方向| メッセージ… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

                  Figure 1: PPP Disconnect Cause Code AVP

図1: pppは原因コードAVPから切断します。

   Mandatory (M) bit: MUST be 0.

義務的な(M)ビット: 0はそうであるに違いありませんか?

   Hidden (H) bit: MAY be 1 if the attribute is hidden.

隠された(H)ビット: 属性が隠されるなら、1であるかもしれません。

   Length: The length of the entire attribute in octets, expressed as a
   single octet.  The length MUST be at least 11.

長さ: ただ一つの八重奏として言い表された八重奏における、全体の属性の長さ。 長さは少なくとも11であるに違いありません。

   Vendor ID: A two octet value in network byte order; set to 0 to
   indicate that this is an IETF-assigned attribute.

ベンダーID: ネットワークバイトオーダーにおける2八重奏価値。 0にセットして、これがIETFによって割り当てられた属性であることを示してください。

Verma, et al.               Standards Track                     [Page 2]

RFC 3145           L2TP Disconnect Cause Information           July 2001

Verma、他 標準化過程[2ページ]RFC3145L2TPは、2001年7月に原因が情報であると切断します。

   Attribute Type: A two octet value in network byte order; set to 46
   (PPP Disconnect Cause Code).

タイプを結果と考えてください: ネットワークバイトオーダーにおける2八重奏価値。 46(PPP Disconnect Cause Code)にセットしてください。

   Disconnect Code: A two octet value in network byte order.  (Described
   in section 3 of this document.)

コードから切断してください: ネットワークバイトオーダーにおける2八重奏価値。 (このドキュメントのセクション3で、説明されます。)

   Control Protocol Number: The PPP Control Protocol number of the
   primary protocol known to have caused the error, if any.  This field
   may be 0 unless mentioned otherwise in the description of the
   Disconnect Codes in section 3.

プロトコル番号を制御してください: もしあれば誤りを引き起こしたのが知られているプライマリプロトコルのPPP Controlプロトコル番号 別の方法でDisconnect Codesの記述でセクション3で言及されない場合、この分野は0であるかもしれません。

   Direction: A single octet value; specifies the direction in which the
   Disconnect Code applies.

方向: ただ一つの八重奏値。 Disconnect Codeが適用する方向を指定します。

            The valid values of this field are:

この分野の有効値は以下の通りです。

                    0: global error
                    1: at peer
                    2: at local
                    3-255: Reserved

0: グローバルな誤り1: 同輩2で: 地方の3-255で: 予約されます。

   This field SHOULD be 0 unless documented otherwise in the description
   of the specific Disconnect Code.

これはSHOULDをさばきます。別の方法で特定Disconnect Codeの記述に記録されない場合、0になってください。

3.  Disconnect Codes

3. コードから切断してください。

   This section contains the list of well-known values of the Disconnect
   Code field in the PPP Disconnect Cause Code AVP.  The IANA will
   maintain a registry of the up-to-date values (see section 5 of this
   document).  These values should be used in conjunction with the
   Direction value and the Control Protocol Number field to interpret
   the specific error condition.

このセクションはPPP Disconnect Cause Code AVPのDisconnect Code分野のよく知られる値のリストを含みます。 IANAは最新の値の登録を維持するでしょう(このドキュメントのセクション5を見てください)。 これらの値は、特定のエラー条件を解釈するのにDirection値とControlプロトコルNumber分野に関連して使用されるべきです。

   Unless documented otherwise for a specific Disconnect Code, the
   Direction value SHOULD be 0.

特定のDisconnect Code、Direction値のSHOULDにそうでない状態で記録されない場合、0になってください。

3.1.  Global Errors

3.1. グローバルな誤り

   The global error codes, given in the list below, are Disconnect Codes
   that do not relate to one particular PPP Control Protocol.  The
   Control Protocol Number for these errors thus MUST be set to 0.

リストで以下に与えられたグローバルなエラーコードは1つの特定のPPP Controlプロトコルに関連しないDisconnect Codesです。 その結果、これらの誤りのためのControlプロトコルNumberは0に用意ができなければなりません。

   0    No information available.

0 利用可能な情報がありません。

   1    Administrative disconnect.

1 管理分離。

   2    Link Control Protocol (LCP) renegotiation at LNS disabled; LNS
        expects proxy LCP information, LAC did not send it.

2 LNSでの再交渉が無効にしたControlプロトコル(LCP)をリンクしてください。 LNSは、プロキシLCP情報、LACがそれを送らなかったと予想します。

Verma, et al.               Standards Track                     [Page 3]

RFC 3145           L2TP Disconnect Cause Information           July 2001

Verma、他 標準化過程[3ページ]RFC3145L2TPは、2001年7月に原因が情報であると切断します。

   3    Normal Disconnection, LCP Terminate-Request sent.

3 正常なDisconnection、LCP Terminate-要求は発信しました。

        Valid Direction values are:

有効なDirection値は以下の通りです。

           1: LCP Terminate-Request sent by peer
           2: LCP Terminate-Request sent by local

1: 同輩2によって送られたLCP Terminate-要求: 地方によって送られたLCP Terminate-要求

   4    Compulsory encryption required by a PPP peer was refused by the
        other.

PPP同輩によって必要とされた4の強制的な暗号化はもう片方によって拒否されました。

        Valid Direction values are:

有効なDirection値は以下の通りです。

           1: Required by local; refused by peer
           2: Required by peer; refused by local

1: 地方が必要です。 同輩2によって拒否されます: 同輩が必要です。 地方によって拒否されます。

3.2.  LCP Errors

3.2. LCP誤り

   The LCP error codes, listed below, are disconnect reasons that are
   directly related to the failure of PPP peers to negotiate mutually
   agreeable link parameters.  The Control Protocol Number for these
   errors MUST be set to C021 hexadecimal (LCP).

以下に記載されたLCPエラーコードは直接PPP同輩が互いに快いリンクパラメータを交渉しないことに関連する分離理由です。 これらの誤りのためのControlプロトコルNumberは16進(LCP)をC021に設定することであるに違いありません。

   5    FSM (Finite State Machine) Timeout error.  (PPP event "TO-".)

5 FSM(有限州Machine)タイムアウト誤り。 (PPPイベント、「-、」、)。

   6    No recognizable LCP packets were received.

6 どんな認識可能なLCPパケットも受け取りませんでした。

   7    LCP failure: Magic Number error; link possibly looped back.

7 LCPの故障: 魔法Number誤り。 ことによると輪にされた後部をリンクしてください。

   8    LCP link failure: Echo Request timeout.

8 LCPは失敗をリンクします: Requestタイムアウトを反響してください。

   9    Peer has unexpected Endpoint-Discriminator for existing
        Multilink PPP (MP) bundle.

9同輩は既存のMultilink PPP(MP)に、予期していなかったEndpoint-弁別器を荷物をまとめさせます。

   10   Peer has unexpected MRRU for existing MP bundle.

10同輩は既存のMPのための予期していなかったMRRUを荷物をまとめさせます。

   11   Peer has unexpected Short-Sequence-Number option for existing
        MP bundle.

11同輩は既存のMPにとって、予期していなかったShort系列番号オプションを荷物をまとめさせます。

   12   Compulsory call-back required by a PPP peer was refused by the
        other.

12 PPP同輩によって必要とされた強制的な呼び戻しはもう片方によって拒否されました。

        Valid Direction values are:

有効なDirection値は以下の通りです。

           1: Required by local; refused by peer
           2: Required by peer; refused by local

1: 地方が必要です。 同輩2によって拒否されます: 同輩が必要です。 地方によって拒否されます。

Verma, et al.               Standards Track                     [Page 4]

RFC 3145           L2TP Disconnect Cause Information           July 2001

Verma、他 標準化過程[4ページ]RFC3145L2TPは、2001年7月に原因が情報であると切断します。

3.3.  Authentication Errors

3.3. 認証誤り

   The authentication error codes, listed below, are disconnect reasons
   that are directly related to authentication failures between the PPP
   peers.  The Control Protocol Number for such errors MUST correspond
   to the PPP Control Protocol number for the authentication protocol in
   use.

以下に記載された認証エラーコードは直接PPP同輩の間の認証失敗に関連する分離理由です。 そのような誤りのためのControlプロトコルNumberは使用中の認証プロトコルのPPP Controlプロトコル番号に対応しなければなりません。

   13   FSM Timeout error.

13 FSM Timeout誤り。

   14   Peer has unexpected authenticated name for existing MP bundle.

14同輩は既存のMPにとって、予期していなかった認証された名前を荷物をまとめさせます。

   15   PPP authentication failure: Authentication protocol
        unacceptable.

15 PPP認証の故障: 容認できない認証プロトコル。

        Valid Direction values are:

有効なDirection値は以下の通りです。

           1: All local authentication protocols were rejected by the
              peer.

1: すべてのローカルの認証プロトコルが同輩によって拒絶されました。

           2: All authentication protocols requested by peer were
              unacceptable or unimplemented locally.

2: 同輩によって要求されたすべての認証プロトコルが、容認できなかったか、または局所的に非実装しました。

   16   PPP authentication failure: Authentication failed (bad name,
        password, or secret).

16 PPP認証の故障: 認証は(悪名、パスワード、または秘密)に失敗しました。

        Valid Direction values are:

有効なDirection値は以下の通りです。

           1: Authentication of peer identity by local system.
           2: Authentication of local identity by peer system.

1: ローカルシステムによる同輩のアイデンティティの認証。 2: 同輩システムによる地方のアイデンティティの認証。

3.4.  Network Control Protocol (NCP) Errors

3.4. ネットワーク制御プロトコル(NCP)誤り

   NCP Errors are disconnect reasons that are directly related to the
   failure of PPP peers to negotiate a mutually agreeable set of
   parameters for the network protocols.  The Control Protocol Number
   for such errors SHOULD correspond to the PPP Network Control Protocol
   number in use.  Where multiple network protocols are in use, multiple
   copies of this AVP MAY be given to indicate failure reasons for each
   NCP.  Otherwise, if only one copy of the AVP is given, the Control
   Protocol Number SHOULD correspond to the last (most recent) failing
   NCP.

NCP Errorsは直接PPP同輩がネットワーク・プロトコルのための互いに快いセットのパラメタを交渉しないことに関連する分離理由です。 そのような誤りSHOULDのためのControlプロトコルNumberは使用中のPPP Network Controlプロトコル番号に対応しています。 使用、複本のこのAVP MAYでは、複数のネットワーク・プロトコルがそうで与えて、それぞれのNCPの失敗理由を示してください。 さもなければ、AVPのコピー1部だけを与えるなら、ControlプロトコルNumber SHOULDは最後の(最新)の失敗NCPに対応しています。

   17   FSM Timeout error.

17 FSM Timeout誤り。

   18   No NCPs available (all disabled or rejected); no NCPs went to
        Opened state.  (Control Protocol Number may be zero only if
        neither peer has enabled NCPs.)

18 利用可能な(すべて無効にしているか、または拒絶された)NCPがありません。 NCPは全くOpened状態に続きませんでした。 (どちらの同輩もNCPを可能にしていない場合にだけ、コントロールプロトコルNumberはゼロであるかもしれません。)

Verma, et al.               Standards Track                     [Page 5]

RFC 3145           L2TP Disconnect Cause Information           July 2001

Verma、他 標準化過程[5ページ]RFC3145L2TPは、2001年7月に原因が情報であると切断します。

   19   NCP failure: failed to converge on acceptable addresses.

19 NCP失敗: 許容できるアドレスに集まりませんでした。

        Valid Direction values are:

有効なDirection値は以下の通りです。

           1: Too many Configure-Naks received from peer.
           2: Too many Configure-Naks sent to peer.

1: あまりに多くのConfigure-Naksが同輩から受信しました。 2: あまりに多くのConfigure-Naksが、じっと見るために発信しました。

   20   NCP failure: user not permitted to use any addresses.

20 NCP失敗: ユーザは、どんなアドレスも使用するのを可能にしませんでした。

        Valid Direction values are:

有効なDirection値は以下の通りです。

           1: Local link address not acceptable to peer.
           2: Remote link address not acceptable to local system.

1: じっと見るのにおいて許容できないローカルのリンクアドレス。 2: ローカルシステムに許容できないリモートリンクアドレス。

4.  Notes

4. 注意

   This AVP MAY may be sent by either the LNS or LAC.  It is generally
   expected that this AVP will be most useful in sending notification
   from the LNS to LAC in the compulsory tunneling case, although it is
   not precluded from use in any other case.

このAVP MAYはLNSかLACのどちらかによって送られるかもしれません。 一般に、強制的なトンネリング場合でLNSからLACまで通告を送る際にこのAVPが最も役に立つと予想されます、それは使用からいかなる他の場合でも排除されませんが。

   A draft form of this AVP used Vendor ID 43 (3Com Corporation) and
   vendor-specific Attribute Type 46.  Implementations MAY accept AVPs
   with these values as equivalent to the message described in this
   document, but SHOULD NOT transmit an AVP using these values.

このAVPの手形様式はVendor ID43(3Com社)とベンダー特有のAttribute Type46を使用しました。 実装は、これらの値があるAVPsが本書では説明されたメッセージに同等であると受け入れるかもしれませんが、SHOULD NOTは、これらの値を使用することでAVPを伝えます。

5.  Security Considerations

5. セキュリティ問題

   The integrity and confidentiality of this AVP relies on the
   underlying L2TP security mechanisms.  It is intended for logging and
   diagnostic purposes in the event of PPP link failure and should not
   pose a threat to system security, but the AVP MAY be hidden as
   described in section 4.3 of RFC 2661.

このAVPの保全と秘密性は基本的なL2TPセキュリティー対策を当てにします。PPPリンクの故障の場合、伐採と診断目的のために意図します、そして、システムセキュリティへの姿勢aの脅威ではなく、AVP MAYがRFC2661のセクション4.3で説明されるように隠されるべきですか?

   The defined extension does not provide information that would be
   useful to an attacker.  Future extensions should not be defined to
   lessen security.  For instance, it is inappropriate to provide
   distinguishing information that would inform the peer that a given
   authentication name is correct, but the password/secret is incorrect.

定義された拡大は攻撃者の役に立つ情報を提供しません。 セキュリティを少なくするために今後の拡大を定義するべきではありません。 例えば、提供するために、与えられた認証名が正しいのですが、パスワード/秘密が不正確であることは、同輩に知らせる情報を区別するのにおいて不適当です。

Verma, et al.               Standards Track                     [Page 6]

RFC 3145           L2TP Disconnect Cause Information           July 2001

Verma、他 標準化過程[6ページ]RFC3145L2TPは、2001年7月に原因が情報であると切断します。

6.  IANA Considerations

6. IANA問題

   IANA has assigned an L2TP Attribute Type value of 46 for the PPP
   Disconnect Cause Code defined in Section 2.

IANAはセクション2で定義されたPPP Disconnect Cause Codeのために46のL2TP Attribute Type値を割り当てました。

   This AVP includes an enumerated cause code value, called the
   "Disconnect Code."  Values 0 through 20 are described in this
   document.  Values 21 through 32767 (inclusive) are assigned by the
   IANA subject to IESG Approval.  Values 32768 through 65279
   (inclusive) are assigned by the IANA on a First Come First Served
   basis, and are intended for vendor-specific features.  Values 65280
   through 65535 (inclusive) are allocated for Private or Experimental
   Use, and no assignment through the IANA is expected.

このAVPは「分離コード」と呼ばれる列挙された原因コード値を含んでいます。 値0〜20は本書では説明されます。 値21〜32767(包括的な)はIESG Approvalを条件としてIANAによって割り当てられます。 値32768〜65279(包括的な)は、First Come First ServedベースでIANAによって割り当てられて、ベンダー特有の特徴のために意図します。 兵士かExperimental Useのために、値65280〜65535(包括的な)を割り当てます、そして、IANAを通した課題を全く予想しません。

7.  References

7. 参照

   [1] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B.
       Palter, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661, August 1999.

Townsley、W.、バレンシア、A.、ルーベン、A.、祭服、G.、ゾルン、G.、およびB.があしらう[1]、「層2はプロトコル(L2TP)にトンネルを堀ります」、RFC2661、1999年8月。

   [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
       2279, January 1998.

[3]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。

8.  Acknowledgments

8. 承認

   The authors thank W. Mark Townsley and Thomas Narten for their
   comments and help.

彼らのコメントについてW.マークTownsleyとトーマスNartenに感謝します、そして、作者は助けます。

Verma, et al.               Standards Track                     [Page 7]

RFC 3145           L2TP Disconnect Cause Information           July 2001

Verma、他 標準化過程[7ページ]RFC3145L2TPは、2001年7月に原因が情報であると切断します。

9.  Contacts

9. 接触

9.1.  L2TP Working Group Chair

9.1. L2TPワーキンググループ議長

   W. Mark Townsley
   Cisco Systems
   7025 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC 27709

7025年のW.マークTownsleyシスコシステムズキットクリーク道路私書箱14987リサーチトライアングル公園、NC 27709

   EMail:  townsley@cisco.com

メール: townsley@cisco.com

9.2.  Authors' Addresses

9.2. 作者のアドレス

   Rohit Verma
   180 N. Stetson Avenue
   Chicago IL 60601

Rohit Verma180N.ステットソン帽アベニューシカゴイリノイ 60601

   Phone:  +1 312 374 2475
   Fax:    +1 312 870 2475
   EMail:  rverma@dc.com

以下に電話をしてください。 +1 312 374、2475Fax: +1 2475年の312 870メール: rverma@dc.com

   Madhvi Verma
   3800 Golf Road
   Rolling Meadows IL 60008

Meadowsイリノイ 60008を回転させるMadhvi Verma3800ゴルフ道路

   Phone:  +1 847 262 2987
   Fax:    +1 847 262 2255
   EMail:  Madhvi_Verma@3com.com

以下に電話をしてください。 +1 847 262、2987Fax: +1 2255年の847 262メール: Madhvi_Verma@3com.com

   James Carlson
   Sun Microsystems
   1 Network Drive MS UBUR02-212
   Burlington MA  01803-2757

ジェームスカールソンサン・マイクロシステムズ1ネットワークDriveさんのUBUR02-212Burlington MA01803-2757

   Phone:  +1 781 442 2084
   Fax:    +1 781 442 1677
   EMail:  james.d.carlson@sun.com

以下に電話をしてください。 +1 781 442、2084Fax: +1 1677年の781 442メール: james.d.carlson@sun.com

Verma, et al.               Standards Track                     [Page 8]

RFC 3145           L2TP Disconnect Cause Information           July 2001

Verma、他 標準化過程[8ページ]RFC3145L2TPは、2001年7月に原因が情報であると切断します。

10.  Standard Notices

10. 標準の通知

10.1.  IETF Intellectual Property Statement

10.1. IETF知的所有権声明

   The IETF takes no position regarding the validity or scope of any
   intellectual property 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; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP 11.  Copies of
   claims of rights made available for publication 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 Secretariat.

IETFはどんな知的所有権の正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可がimplementersによるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights, which may cover technology that, may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

IETFは、どんな利害関係者も技術をカバーするかもしれないどんな著作権、特許、特許出願、または他の所有権もその注目していただくよう誘います。それが、この規格を練習するのに必要であるかもしれません。 IETF専務に情報を扱ってください。

Verma, et al.               Standards Track                     [Page 9]

RFC 3145           L2TP Disconnect Cause Information           July 2001

Verma、他 標準化過程[9ページ]RFC3145L2TPは、2001年7月に原因が情報であると切断します。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

   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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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機能のための基金は現在、インターネット協会によって提供されます。

Verma, et al.               Standards Track                    [Page 10]

Verma、他 標準化過程[10ページ]