[要約] RFC 2867は、トンネルプロトコルのサポートのためのRADIUSアカウンティングの変更に関するものです。このRFCの目的は、トンネルプロトコルを使用するネットワークデバイスのアカウンティング情報をRADIUSサーバに送信するための仕様を提供することです。

Network Working Group                                            G. Zorn
Request for Comments: 2867                           Cisco Systems, Inc.
Category: Informational                                         B. Aboba
Updates: 2866                                      Microsoft Corporation
                                                               D. Mitton
                                                         Nortel Networks
                                                               June 2000
        

RADIUS Accounting Modifications for Tunnel Protocol Support

トンネルプロトコルサポートのための半径会計変更

Status of this Memo

本文書の位置付け

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。

Copyright Notice

著作権表示

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

Copyright(c)The Internet Society(2000)。無断転載を禁じます。

Abstract

概要

This document defines new RADIUS accounting Attributes and new values for the existing Acct-Status-Type Attribute [1] designed to support the provision of compulsory tunneling in dial-up networks.

このドキュメントでは、ダイヤルアップネットワークでの強制トンネルの提供をサポートするように設計された既存のACCTステータス型属性[1]の新しいRADIUSアカウンティング属性と新しい値を定義します。

Specification of Requirements

要件の仕様

In this document, the key words "MAY", "MUST, "MUST NOT", "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [2].

このドキュメントでは、キーワードは「可能性があります」、「必要はない」、「オプション」、「推奨」、「は」、「必要はありません」、および「必要はありません」は、[2]で説明されているように解釈されるべきではありません。

1. Introduction
1. はじめに

Many applications of tunneling protocols such as PPTP [5] and L2TP [4] involve dial-up network access. Some, such as the provision of secure access to corporate intranets via the Internet, are characterized by voluntary tunneling: the tunnel is created at the request of the user for a specific purpose. Other applications involve compulsory tunneling: the tunnel is created without any action from the user and without allowing the user any choice in the matter, as a service of the Internet service provider (ISP). Typically, ISPs providing a service want to collect data regarding that service for billing, network planning, etc. One way to collect usage data in dial-up networks is by means of RADIUS Accounting [1]. The use of RADIUS Accounting allows dial-up usage data to be collected at a central location, rather than stored on each NAS.

PPTP [5]やL2TP [4]などのトンネルプロトコルの多くのアプリケーションには、ダイヤルアップネットワークアクセスが含まれます。インターネットを介した企業イントラネットへの安全なアクセスの提供などの一部は、自発的なトンネリングによって特徴付けられます。トンネルは、特定の目的のためにユーザーの要求に応じて作成されます。その他のアプリケーションには、強制トンネリングが含まれます。トンネルは、ユーザーからのアクションなしで、およびインターネットサービスプロバイダー(ISP)のサービスとしてユーザーに問題の選択を許可することなく作成されます。通常、サービスを提供するISPは、請求、ネットワーク計画などのサービスに関するデータを収集したいと考えています。ダイヤルアップネットワークで使用データを収集する1つの方法は、RADIUSアカウンティングによるものです[1]。RADIUSアカウンティングを使用すると、各NASに保存されるのではなく、中央の場所でダイヤルアップ使用データを収集できます。

In order to collect usage data regarding tunneling, new RADIUS attributes are needed; this document defines these attributes. In addition, several new values for the Acct-Status-Type attribute are proposed. Specific recommendations for, and examples of, the application of this attribute for the L2TP protocol can be found in RFC 2809.

トンネリングに関する使用データを収集するには、新しい半径属性が必要です。このドキュメントは、これらの属性を定義します。さらに、ACCTステータス型属性のいくつかの新しい値が提案されています。L2TPプロトコルのこの属性の適用に対する特定の推奨事項と例は、RFC 2809に記載されています。

2. Implementation Notes
2. 実装ノート

Compulsory tunneling may be part of a package of services provided by one entity to another. For example, a corporation might contract with an ISP to provide remote intranet access to its employees via compulsory tunneling. In this case, the integration of RADIUS and tunnel protocols allows the ISP and the corporation to synchronize their accounting activities so that each side receives a record of the user's resource consumption. This provides the corporation with the means to audit ISP bills.

強制トンネリングは、あるエンティティが別のエンティティに提供するサービスのパッケージの一部である場合があります。たとえば、企業はISPと契約して、強制トンネリングを介して従業員にリモートイントラネットアクセスを提供する場合があります。この場合、RADIUSとトンネルプロトコルの統合により、ISPと企業は会計活動を同期させ、各側がユーザーのリソース消費の記録を受け取るようにします。これにより、企業はISP請求書を監査する手段を提供します。

In auditing, the User-Name, Acct-Tunnel-Connection, Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes are typically used to uniquely identify the call, allowing the Accounting-Request sent by the NAS to be reconciled with the corresponding Accounting-Request sent by the tunnel server.

監査では、ユーザー名、ACCTトンネル接続、トンネルクライアントエンドポイント、トンネルサーバーエンドポイントの属性を通常、コールを一意に識別するために使用され、NASが送信した会計要件を対応するものと調整できるようにします。トンネルサーバーから送信された会計再クエスト。

When implementing RADIUS accounting for L2TP/PPTP tunneling, the Call-Serial-Number SHOULD be used in the Acct-Tunnel-Connection attribute. In L2TP, the Call-Serial-Number is a 32-bit field and in PPTP it is a 16-bit field. In PPTP the combination of IP Address and Call-Serial-Number SHOULD be unique, but this is not required. In addition, no method for determining the Call-Serial-Number is specified, which leaves open the possibility of wrapping after a reboot.

L2TP/PPTPトンネリングのRADIUSアカウンティングを実装する場合、ACCTトンネル接続属性でコールシリアル番号を使用する必要があります。L2TPでは、コールシリアル番号は32ビットフィールドであり、PPTPでは16ビットフィールドです。PPTPでは、IPアドレスとコールシリアル番号の組み合わせは一意でなければなりませんが、これは必要ありません。さらに、コールシリアル番号を決定する方法は指定されておらず、再起動後にラップの可能性が残ります。

Note that a 16-bit Call-Serial-Number is not sufficient to distinguish a given call from all other calls over an extended time period. For example, if the Call-Serial-Number is assigned monotonically, the NAS in question has 96 ports which are continually busy and the average call is of 20 minutes duration, then a 16-bit Call-Serial-Number will wrap within 65536/(96 * 3 calls/hour * 24 hours/day) = 9.48 days.

16ビットのコールシリアル番号は、長期間にわたって他のすべての呼び出しと特定の呼び出しを区別するのに十分ではないことに注意してください。たとえば、コールシリアル番号が単調に割り当てられている場合、問題のNASには96ポートが継続的にビジーで、平均コールは20分間の期間である場合、16ビットのコールシリアル番号は65536/以内にラップします。(96 * 3コール/時間 * 24時間/日)= 9.48日。

3. New Acct-Status-Type Values
3. 新しいACCT-STATUSタイプの値
3.1. Tunnel-Start
3.1. トンネルスタート

Value

価値

9

9

Description

説明

This value MAY be used to mark the establishment of a tunnel with another node. If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet:

この値は、トンネルの確立を別のノードでマークするために使用できます。この値を使用する場合、次の属性も会計レクエストパケットに含める必要があります。

User-Name (1) NAS-IP-Address (4) Acct-Delay-Time (41) Event-Timestamp (55) Tunnel-Type (64) Tunnel-Medium-Type (65) Tunnel-Client-Endpoint (66) Tunnel-Server-Endpoint (67) Acct-Tunnel-Connection (68)

ユーザー名(1)NAS-IP-Address(4)ACCT-Delay-Time(41)Event-Timestamp(55)Tunnel-Type(64)Tunnel-Med-Type(65)Tunnel-Client-Endpoint(66)トンネルサーバーエンドポイント(67)ACCT-Tunnel-Connection(68)

3.2. Tunnel-Stop
3.2. トンネルストップ

Value

価値

10

10

Description

説明

This value MAY be used to mark the destruction of a tunnel to or from another node. If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet:

この値は、別のノードへのトンネルの破壊をマークするために使用できます。この値を使用する場合、次の属性も会計レクエストパケットに含める必要があります。

User-Name (1) NAS-IP-Address (4) Acct-Delay-Time (41) Acct-Input-Octets (42) Acct-Output-Octets (43) Acct-Session-Id (44) Acct-Session-Time (46) Acct-Input-Packets (47) Acct-Output-Packets (48) Acct-Terminate-Cause (49) Acct-Multi-Session-Id (51) Event-Timestamp (55) Tunnel-Type (64) Tunnel-Medium-Type (65) Tunnel-Client-Endpoint (66) Tunnel-Server-Endpoint (67) Acct-Tunnel-Connection (68) Acct-Tunnel-Packets-Lost (86)

user-name(1)nas-ip-address(4)acct-delay-time(41)acct-input-octets(42)acct-output-octets(43)acct-session-id(44)acct-session-時間(46)ACCT入力パケット(47)ACCT出力パケット(48)ACCTターミネート原因(49)ACCT-MULTI-SESSION-ID(51)イベント - テメスタンプ(55)トンネルタイプ(64)トンネルメディウムタイプ(65)トンネルクライアントエンドポイント(66)トンネルサーバーエンドポイント(67)ACCT-Tunnel-Connection(68)ACCT-Tunnel-Packets-Lost(86)

3.3. Tunnel-Reject
3.3. トンネル - rejtion

Value

価値

11

11

Description

説明

This value MAY be used to mark the rejection of the establishment of a tunnel with another node. If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet:

この値は、別のノードでトンネルの確立の拒絶をマークするために使用できます。この値を使用する場合、次の属性も会計レクエストパケットに含める必要があります。

User-Name (1) NAS-IP-Address (4) Acct-Delay-Time (41) Acct-Terminate-Cause (49) Event-Timestamp (55) Tunnel-Type (64) Tunnel-Medium-Type (65) Tunnel-Client-Endpoint (66) Tunnel-Server-Endpoint (67) Acct-Tunnel-Connection (68)

user-name(1)nas-ip-address(4)acct-delay-time(41)acct-ターミネート原因(49)イベント - ティメスタンプ(55)トンネルタイプ(64)トンネルメディウムタイプ(65)トンネルクライアントエンドポイント(66)トンネルサーバーエンドポイント(67)ACCTトンネル接続(68)

3.4. トンネルリンクスタート

Value

価値

12

12

Description

説明

This value MAY be used to mark the creation of a tunnel link. Only some tunnel types (e.g., L2TP) support multiple links per tunnel. This Attribute is intended to mark the creation of a link within a tunnel that carries multiple links. For example, if a mandatory tunnel were to carry M links over its lifetime, 2(M+1) RADIUS Accounting messages might be sent: one each marking the initiation and destruction of the tunnel itself and one each for the initiation and destruction of each link within the tunnel. If only a single link can be carried in a given tunnel (e.g., IPsec in the tunnel mode), this Attribute need not be included in accounting packets, since the presence of the Tunnel-Start Attribute will imply the initiation of the (only possible) link.

この値は、トンネルリンクの作成をマークするために使用できます。一部のトンネルタイプ(L2TPなど)のみがトンネルごとの複数のリンクをサポートしています。この属性は、複数のリンクを運ぶトンネル内のリンクの作成をマークすることを目的としています。たとえば、必須のトンネルがその寿命にわたってmリンクを運ぶ場合、2(m 1)半径の会計メッセージが送信される場合があります。それぞれがトンネル自体の開始と破壊をマークし、それぞれが各リンクの開始と破壊のために1つをマークしますトンネル内。特定のトンネルに単一のリンクのみを運ぶことができる場合(トンネルモードのIPSECなど)、トンネルスタート属性の存在は(可能なみ)の開始を意味するため、この属性を会計パケットに含める必要はありません。) リンク。

If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet:

この値を使用する場合、次の属性も会計レクエストパケットに含める必要があります。

User-Name (1) NAS-IP-Address (4) NAS-Port (5) Acct-Delay-Time (41) Event-Timestamp (55) Tunnel-Type (64) Tunnel-Medium-Type (65) Tunnel-Client-Endpoint (66) Tunnel-Server-Endpoint (67) Acct-Tunnel-Connection (68)

user-name(1)nas-ip-address(4)nas-port(5)acct-delay-time(41)event-timestamp(55)トンネルタイプ(64)トンネル - メディウムタイプ(65)トンネル - クライアントエンドポイント(66)トンネルサーバーエンドポイント(67)ACCT-Tunnel-Connection(68)

3.5. トンネルリンクストップ

Value

価値

13

13

Description

説明

This value MAY be used to mark the destruction of a tunnel link. Only some tunnel types (e.g., L2TP) support multiple links per tunnel. This Attribute is intended to mark the destruction of a link within a tunnel that carries multiple links. For example, if a mandatory tunnel were to carry M links over its lifetime, 2(M+1) RADIUS Accounting messages might be sent: one each marking the initiation and destruction of the tunnel itself and one each for the initiation and destruction of each link within the tunnel. If only a single link can be carried in a given tunnel (e.g., IPsec in the tunnel mode), this Attribute need not be included in accounting packets, since the presence of the Tunnel-Stop Attribute will imply the termination of the (only possible) link.

この値は、トンネルリンクの破壊をマークするために使用できます。一部のトンネルタイプ(L2TPなど)のみがトンネルごとの複数のリンクをサポートしています。この属性は、複数のリンクを運ぶトンネル内のリンクの破壊をマークすることを目的としています。たとえば、必須のトンネルがその寿命にわたってmリンクを運ぶ場合、2(m 1)半径の会計メッセージが送信される場合があります。それぞれがトンネル自体の開始と破壊をマークし、それぞれが各リンクの開始と破壊のために1つをマークしますトンネル内。特定のトンネルに単一のリンクのみを運ぶことができる場合(トンネルモードのIPSECなど)、トンネルストップ属性の存在は(可能なみ)の終了を意味するため、この属性を会計パケットに含める必要はありません。) リンク。

If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet:

この値を使用する場合、次の属性も会計レクエストパケットに含める必要があります。

User-Name (1) NAS-IP-Address (4) NAS-Port (5) Acct-Delay-Time (41) Acct-Input-Octets (42) Acct-Output-Octets (43) Acct-Session-Id (44) Acct-Session-Time (46) Acct-Input-Packets (47) Acct-Output-Packets (48) Acct-Terminate-Cause (49) Acct-Multi-Session-Id (51) Event-Timestamp (55) NAS-Port-Type (61) Tunnel-Type (64) Tunnel-Medium-Type (65) Tunnel-Client-Endpoint (66) Tunnel-Server-Endpoint (67) Acct-Tunnel-Connection (68) Acct-Tunnel-Packets-Lost (86)

user-name(1)nas-ip-address(4)nas-port(5)acct-delay-time(41)acct-input-ouctets(42)acct-output-ouctets(43)acct-session-id(44)ACCT-SESSION-TIME(46)ACCT-Input-Packets(47)ACCT-OUTPUT-PACKETS(48)ACCTターミネート原因(49)ACCT-Multi-Session-ID(51)イベント - タイミスタンプ(55)NAS-Port-Type(61)トンネルタイプ(64)トンネル - メディウムタイプ(65)トンネルクライアントエンドポイント(66)トンネルサーバーエンドポイント(67)ACCT-Tunnel-Connection- ACCT-Tunnel--パケットロスト(86)

3.6. トンネルリンク - reject

Value

価値

14

14

Description

説明

This value MAY be used to mark the rejection of the establishment of a new link in an existing tunnel. Only some tunnel types (e.g., L2TP) support multiple links per tunnel. If only a single link can be carried in a given tunnel (e.g., IPsec in the tunnel mode), this Attribute need not be included in accounting packets, since in this case the Tunnel-Reject Attribute has the same meaning.

この値は、既存のトンネルに新しいリンクの確立の拒否をマークするために使用できます。一部のトンネルタイプ(L2TPなど)のみがトンネルごとの複数のリンクをサポートしています。特定のトンネルに単一のリンクのみを運ぶことができる場合(トンネルモードのIPSECなど)、この属性は会計パケットに含める必要はありません。

If this value is used, the following attributes SHOULD also be included in the Accounting-Request packet:

この値を使用する場合、次の属性も会計レクエストパケットに含める必要があります。

User-Name (1) NAS-IP-Address (4) Acct-Delay-Time (41) Acct-Terminate-Cause (49) Event-Timestamp (55) Tunnel-Type (64) Tunnel-Medium-Type (65) Tunnel-Client-Endpoint (66) Tunnel-Server-Endpoint (67) Acct-Tunnel-Connection (68)

user-name(1)nas-ip-address(4)acct-delay-time(41)acct-ターミネート原因(49)イベント - ティメスタンプ(55)トンネルタイプ(64)トンネルメディウムタイプ(65)トンネルクライアントエンドポイント(66)トンネルサーバーエンドポイント(67)ACCTトンネル接続(68)

4. Attributes
4. 属性
4.1. Acct-Tunnel-Connection
4.1. ACCTトンネル接続

Description

説明

This Attribute indicates the identifier assigned to the tunnel session. It SHOULD be included in Accounting-Request packets which contain an Acct-Status-Type attribute having the value Start, Stop or any of the values described above. This attribute, along with the Tunnel-Client-Endpoint and Tunnel-Server-Endpoint attributes [3], may be used to provide a means to uniquely identify a tunnel session for auditing purposes.

この属性は、トンネルセッションに割り当てられた識別子を示します。値の開始、停止、または上記の値のいずれかを持つACCTステータス型属性を含む会計レクエストパケットに含める必要があります。この属性は、トンネルクライアントエンドポイントおよびトンネルサーバーエンドポイント属性[3]とともに、監査目的でトンネルセッションを一意に識別する手段を提供するために使用できます。

A summary of the Acct-Tunnel-Connection Attribute format is shown below. The fields are transmitted from left to right.

ACCT-Tunnel-Connection属性形式の概要を以下に示します。フィールドは左から右に送信されます。

       0                   1                   2
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |    Length     |    String ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Type

タイプ

68 for Acct-Tunnel-Connection

68 ACCT-Tunnel接続の場合

Length

長さ

>= 3

> = 3

String

The format of the identifier represented by the String field depends upon the value of the Tunnel-Type attribute [3]. For example, to fully identify an L2TP tunnel connection, the L2TP Tunnel ID and Call ID might be encoded in this field. The exact encoding of this field is implementation dependent.

文字列フィールドで表される識別子の形式は、トンネルタイプの属性の値に依存します[3]。たとえば、L2TPトンネル接続を完全に識別するために、L2TPトンネルIDとコールIDがこのフィールドでエンコードされる場合があります。このフィールドの正確なエンコードは、実装依存です。

4.2. Acct-Tunnel-Packets-Lost
4.2. acct-tunnel-packets-lost

Description

説明

This Attribute indicates the number of packets lost on a given link. It SHOULD be included in Accounting-Request packets which contain an Acct-Status-Type attribute having the value Tunnel-Link-Stop.

この属性は、特定のリンクで失われたパケットの数を示します。値トンネルリンクストップを持つACCTステータスタイプの属性を含む会計レクエストパケットに含める必要があります。

A summary of the Acct-Tunnel-Packets-Lost Attribute format is shown below. The fields are transmitted from left to right.

ACCT-Tunnel-Packets-Lost属性形式の概要を以下に示します。フィールドは左から右に送信されます。

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      Type     |    Length     |               Lost
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 Lost (cont)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        

Type

タイプ

86 for Acct-Tunnel-Packets-Lost

86 ACCT-Tunnel-Packets-Lostの場合

Length

長さ

6

6

Lost

失った

The Lost field is 4 octets in length and represents the number of packets lost on the link.

失われたフィールドの長さは4オクテットで、リンクで失われたパケットの数を表します。

5. Table of Attributes
5. 属性の表

The following table provides a guide to which attributes may be found in Accounting-Request packets. No tunnel attributes should be found in Accounting-Response packets.

次の表には、会計レクエストパケットに属性が見つかるガイドを示します。会計応答パケットには、トンネル属性を見つける必要はありません。

   Request        #       Attribute
     0-1          64      Tunnel-Type
     0-1          65      Tunnel-Medium-Type
     0-1          66      Tunnel-Client-Endpoint
     0-1          67      Tunnel-Server-Endpoint
     0-1          68      Acct-Tunnel-Connection
     0            69      Tunnel-Password
     0-1          81      Tunnel-Private-Group-ID
     0-1          82      Tunnel-Assignment-ID
     0            83      Tunnel-Preference
     0-1          86      Acct-Tunnel-Packets-Lost
        

The following table defines the meaning of the above table entries.

次の表は、上記のテーブルエントリの意味を定義しています。

0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet.

0この属性はパケットに存在してはなりません。この属性の0ゼロ以上のインスタンスがパケットに存在する場合があります。この属性の0-1インスタンスまたは1つのインスタンスがパケットに存在する場合があります。

6. Security Considerations
6. セキュリティに関する考慮事項

By "sniffing" RADIUS Accounting packets, it might be possible for an eavesdropper to perform a passive analysis of tunnel connections.

Radius Accountingパケットを「スニッフィング」することにより、盗聴者がトンネル接続のパッシブ分析を実行することが可能かもしれません。

7. References
7. 参考文献

[1] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[1] Rigney、C。、「Radius Accounting」、RFC 2866、2000年6月。

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

[2] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.

[3] Zorn、G.、Leifer、D.、Rubens、A.、Shriver、J.、Holdrege、M。、およびI. Goyret、「トンネルプロトコルサポートの半径属性」、RFC 2868、2000年6月。

[4] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.

[4] Townsley、W.、Valencia、A.、Rubens、A.、Pall、G.、Zorn、G.およびB. Palter、「レイヤー2トンネルプロトコル "L2TP" "、RFC 2661、1999年8月。

[5] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637, July 1999.

[5] Hamzeh、K.、Pall、G.、Verthein、W.、Taarud、J.、Little、W。and G. Zorn、「ポイントツーポイントトンネルプロトコル(PPTP)」、RFC 2637、1999年7月。

8. Acknowledgments
8. 謝辞

Thanks to Aydin Edguer, Ly Loi, Matt Holdrege and Gurdeep Singh Pall for salient input and review.

Aydin Edguer、Ly Loi、Mattrege、Gurdeep Singh Pallに感謝します。

9. Authors' Addresses
9. 著者のアドレス

Questions about this memo can be directed to:

このメモに関する質問は、次のように向けることができます。

Glen Zorn Cisco Systems, Inc. 500 108th Avenue N.E., Suite 500 Bellevue, Washington 98004 USA

Glen Zorn Cisco Systems、Inc。500 108th Avenue N.E.、Suite 500 Bellevue、Washington 98004 USA

   Phone: +1 425 438 8218
   FAX:   +1 425 438 1848
   EMail: gwz@cisco.com
        

Dave Mitton Nortel Networks 880 Technology Park Drive Billerica, MA 01821

Dave Mitton Nortel Networks 880 Technology Park Drive Billerica、MA 01821

   Phone: +1 978 288 4570
   Fax:   +1 978 288 3030
   EMail: dmitton@nortelnetworks.com
        

Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, Washington 98052

バーナードアボバマイクロソフトコーポレーションワンマイクロソフトウェイレドモンド、ワシントン98052

   Phone: +1 425 936 6605
   Fax:   +1 425 936 7329
   EMail: aboba@internaut.com
        
10. 完全な著作権声明

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

Copyright(c)The Internet Society(2000)。無断転載を禁じます。

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