この文書はRFC2867の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
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-Status-Type
属性[1]の新しい値を定義します。
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].
この文書のキーワード"MAY"と"MUST"と"MUST NOT"と"optional"と"recommended"
と"SHOULD"と"SHOULD NOT"は[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]のようなトンネルプロトコルの多くがアプリケーションが
ダイアルアップネットワークアクセスと関連します。インターネットを経由
して企業のイントラネットに安全にアクセスするようなトンネルは、自発的
トンネルと特徴づけられます：トンネルは特定の目的で、ユーザーのリクエ
ストで作られます。他のアプリケーションが義務的なトンネルをします：ト
ンネルは、インターネット・サービスプロバイダのサービスとして、ユーザー
の行動なしで、ユーザーに選択を許さないで作られます。典型的に、サービ
スを供給しするＩＳＰが請求処理やネットワーク計画などのためにサービス
に関するデータを集めることを望みます。 ダイアルアップネットワークで
利用データを集める一つの方法がラディウス課金[1]によってです。ラディ
ウス課金の使用はダイアルアップ利用データを各ＮＡＳに記憶するのではな
く、中央の場所でコントロールされることを許します。
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-Status-Type属
性の新しい値が提案されます。特定の推薦のため、と例として、Ｌ２ＴＰプ
ロトコルのこの属性のアプリケーションはRFC2809にあります。
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.
強制的なトンネルは他のエンティティーの供給するパッケージサービスの一
部かもしれません。例えば、会社が強制的トンネルでその従業員に遠隔から
イントラネットアクセスを供給するためにＩＳＰと契約するかもしれません。
この場合、ラディウスの集積とトンネルプロトコルは、ＩＳＰと企業の課金
の同期を許し、それぞれの側でユーザーのリソース消費のレコードを受け取
ることを許します。これはＩＳＰ明細を監査する手段を会社に提供します。
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.
会計監査は、通常User-NameとAcct-Tunnel-ConnectionとTunnel-Client-
EndpointとTunnel-Server-Endpoint属性でユニーク呼を識別し、ＮＳＡの課
金要求とトンネルサーバの対応する課金要求を対応させることを可能にしま
す。
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トンネルにラディウス課金を実行する時、Acct-Tunnel-Connection
属性でCall-Serial-Numberが使われるべきです(SHOULD)。L2TPでCall-Serial-
Numberは３２ビットのフィールドで、PPTPでは１６ビットフィールドです。
PPTPでＩＰアドレスとCall-Serial-Numberの組合せユニークであるべきです
(SHOULD)が、必須ではありません。加えて、Call-Serial-Numberを決定する
方法が指定されず、リブート後に再利用される可能性を残します。
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.
１６ビットのCall-Serial-Numberが長期的にある呼を他のすべての呼と区別
するには十分ではないことに注意してください。例えば、もしCall-Serial-
Numberが単純に割り当てられ、問題のＮＡＳが９６ポートを持ち常に使われ、
平均的に２０分つながっているなら、１６ビットのCall-Serial-Numberの値
はが６５５３６÷ （９６×３呼／時間×２４時間／日） ≒９.４８日で元に
戻るでしょう。
3. New Acct-Status-Type Values
3. 新しいAcct-Status-Type値
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:
この値は他のノードでのトンネル設立を印すために使われるかもしれ
ません(MAY)。もしこの値が使われるなら、次の属性が課金要求パケッ
トに含められるべきです(SHOULD)：
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)
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:
この値は他のノードでのトンネル破壊を印すために使われるかもしれ
ません(MAY)。もしこの値が使われるなら、次の属性が課金要求パケッ
トに含められるべきです(SHOULD)：
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)
3.3. Tunnel-Reject
3.3. トンネル拒否
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:
この値は他のノードでのトンネル設立拒否を印すために使われるかも
しれません(MAY)。もしこの値が使われるなら、次の属性が課金要求
パケットに含められるべきです(SHOULD)：
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)
3.4. Tunnel-Link-Start
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.
この値はトンネルリンクの生成を示すために使われるかもしれません
(MAY)。あるトンネルタイプ（例えば、L2TP）だけがトンネル毎に多数
のリンクをサポートします。この属性は多数のリンクを運ぶトンネル
の中でリンクの生成を示すことを意図します。例えば、もし義務的な
トンネルが寿命の間にＭリンクを運ぶなら、２（Ｍ＋１）のラディウ
ス課金メッセージが送られるかもしれません：それぞれは、トンネル
自身の生成と削除と、トンネル中のリンクの生成と削除を示します。
もしただひとつのリンクだけがトンネルで運べるなら（例えば、トン
ネルモードのIPsec）、Tunnel-Start属性の存在が（可能な）リンク
の開始を暗示するため、この属性を課金パケットに含める必要があり
ません。
If this value is used, the following attributes SHOULD also be
included in the Accounting-Request packet:
もしこの値が使われるなら、次の属性が課金要求パケットに含められ
るべきです(SHOULD)：
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)
3.5. Tunnel-Link-Stop
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.
この値はトンネルリンクの削除を示すために使われるかもしれません
(MAY)。あるトンネルタイプ（例えば、L2TP）だけがトンネル毎に多数
のリンクをサポートします。この属性は多数のリンクを運ぶトンネル
の中でリンクの削除を示すことを意図します。例えば、もし義務的な
トンネルが寿命の間にＭリンクを運ぶなら、２（Ｍ＋１）のラディウ
ス課金メッセージが送られるかもしれません：それぞれは、トンネル
自身の生成と削除と、トンネル中のリンクの生成と削除を示します。
もしただひとつのリンクだけがトンネルで運べるなら（例えば、トン
ネルモードのIPsec）、Tunnel-Stop属性の存在が（可能な）リンクの
開始を暗示するため、この属性を課金パケットに含める必要がありま
せん。
If this value is used, the following attributes SHOULD also be
included in the Accounting-Request packet:
もしこの値が使われるなら、次の属性が課金要求パケットに含められ
るべきです(SHOULD)：
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)
3.6. Tunnel-Link-Reject
3.6. トンネルリンク拒否
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）、
この場合Tunnel-Reject属性の存在が同じ事を意味するので、この属性
を課金パケットに含める必要がありません。
If this value is used, the following attributes SHOULD also be
included in the Accounting-Request packet:
もしこの値が使われるなら、次の属性が課金要求パケットに含められ
るべきです(SHOULD)：
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)
4. Attributes
4. 属性
4.1. Acct-Tunnel-Connection
4.1. 課金トンネル接続
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-Status-Type属性を
含む課金要求パケットに含められるべきです(SHOULD)。この属性は、
Tunnel-Client-Endpoint属性Tunnel- Server-Endpoint属性[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 課金トンネル接続
Length
長さ
>= 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 Tunnel ＩＤと電話番号がこのフィールドでコー
ド化されるかもしれません。このフィールドの正確なコーディングは
実装に依存します。
4.2. Acct-Tunnel-Packets-Lost
4.1. 課金トンネルパケット損失
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-Status-Type属性値がTunnel-Link-Stopである課金要求パケッ
トに含められるべきです(SHOULD)。
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 課金トンネルパケット損失
Length
長さ
6
６
Lost
損失
The Lost field is 4 octets in length and represents the number
of packets lost on the link.
損失フィールドは４オクテット長で、リンク上で失われたパケットの
数を表します。
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 この属性はパケットにあってはなりません(MUST NOT)。
0+ Zero or more instances of this attribute MAY be present in
packet.
0+ この属性はパケットに０個以上存在しています(MAY)。
0-1 Zero or one instance of this attribute MAY be present in
packet.
0-1 この属性はパケットに０個か１個存在しています(MAY)。
6. Security Considerations
6. セキュリティの考察
By "sniffing" RADIUS Accounting packets, it might be possible for an
eavesdropper to perform a passive analysis of tunnel connections.
ラディウス課金パケットの「スニファ」によって、盗聴者がトンネル接続の
受動的な分析を行うことは可能であるかもしれません。
7. References
7. 参考文献
[1] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and
I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC
2868, June 2000.
[4] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. and
B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661,
August 1999.
[5] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W. and
G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)", RFC 2637,
July 1999.
8. Acknowledgments
8. 謝辞
Thanks to Aydin Edguer, Ly Loi, Matt Holdrege and Gurdeep Singh Pall
for salient input and review.
重要なインプットとレビューについてAydin EdguerとLy Loiと
Matt Holdregeと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
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
Phone: +1 978 288 4570
Fax: +1 978 288 3030
EMail: dmitton@nortelnetworks.com
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, Washington 98052
Phone: +1 425 936 6605
Fax: +1 425 936 7329
EMail: aboba@internaut.com
10. Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (2000). 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.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。