この文書はRFC3162の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group B. Aboba
Request for Comments: 3162 Microsoft
Category: Standards Track G. Zorn
Cisco Systems
D. Mitton
Circular Logic UnLtd.
August 2001
RADIUS and IPv6
ＲＡＤＩＵＳとＩＰｖ６
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
概要
This document specifies the operation of RADIUS (Remote
Authentication Dial In User Service) when run over IPv6 as well as
the RADIUS attributes used to support IPv6 network access.
この文書は、ラディウス（遠隔認証ダイヤルインユーザサービス）をＩＰｖ
６上で動かす際や、ＩＰｖ６ネットワークアクセスをサポートするためラ
ディウス属性を使う際の、ラディウスの操作を指定します。
1. Introduction
1. はじめに
This document specifies the operation of RADIUS [4]-[8] over IPv6
[13] as well as the RADIUS attributes used to support IPv6 network
access.
この文書は、ＩＰｖ６[13]上でのＲＡＤＩＵＳ[4]-[8]操作や、ＩＰｖ６ネッ
トワークアクセスをサポートするＲＡＤＩＵＳ属性を指定します
Note that a NAS sending a RADIUS Access-Request may not know a-priori
whether the host will be using IPv4, IPv6, or both. For example,
within PPP, IPv6CP [11] occurs after LCP, so that address assignment
will not occur until after RADIUS authentication and authorization
has completed.
ラディウスアクセス要請を送っているＮＡＳは、ホストがＩＰｖ４かＩＰｖ
６かあるいは両方のともを使っているかどうか知らないことに注意してくだ
さい。例えば、ＰＰＰ内で、 IPv6CP[11]がＬＣＰの後に起こり、アドレス割
当てがラディウス認証と認可が完了した後まで、起こらないでしょう。
Therefore it is presumed that the IPv6 attributes described in this
document MAY be sent along with IPv4-related attributes within the
same RADIUS message and that the NAS will decide which attributes to
use. The NAS SHOULD only allocate addresses and prefixes that the
client can actually use, however. For example, there is no need for
the NAS to reserve use of an IPv4 address for a host that only
supports IPv6; similarly, a host only using IPv4 or 6to4 [12] does
not require allocation of an IPv6 prefix.
それ故にこの文書で記述されたＩＰｖ６属性が同じラディウスメッセージ内
でＩＰｖ４関連の属性とともに送られるかもしれなく(MAY)、ＮＡＳがいずれ
の属性を使うべきか決めるであろうと推測されます。しかしながら、ＮＡＳ
はただクライアントが実際に使うことができるアドレスとプレフィックスを
割り当てるだけであるべきです(SHOULD)。例えば、ＮＡＳがただＩＰｖ６を
サポートするだけのホストのためにＩＰｖ４アドレスの使用を確保する必要
がありません；同様に、ただＩＰｖ４あるいは６to４[12]を使うだけである
ホストがＩＰｖ６プレフィックスの割り当てを必要としません。
The NAS can provide IPv6 access natively, or alternatively, via other
methods such as IPv6 within IPv4 tunnels [15] or 6over4 [14]. The
choice of method for providing IPv6 access has no effect on RADIUS
usage per se, although if it is desired that an IPv6 within IPv4
tunnel be opened to a particular location, then tunnel attributes
should be utilized, as described in [6], [7].
ＮＡＳはネイティブのＩＰｖ６アクセスや、代わりに、ＩＰｖ４トンネル内
のＩＰｖ６[15]や６over４[14]のような他の方法でＩＰｖ６アクセスを供給
することができます。もしＩＰｖ４トンネル中のＩＰｖ６が特定の場所に作
られることが望まれるなら[6][7]で記述されるようにトンネル属性が利用さ
れるべきだが、ＩＰｖ６アクセスを供給する方法の選択はラディウスの使用
に対する効果を持っていません。
1.1. Requirements language
1.1. 条件用語
In this document, the key words "MAY", "MUST, "MUST NOT", "optional",
"recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as
described in [1].
この文書で、キーワード"MAY"と"MUST"と"MUST NOT"と"optional"と
"recommended"と"SHOULD"と"SHOULD NOT"は[1]で記述されるように解釈され
るはずです。
2. Attributes
2. 属性
2.1. NAS-IPv6-Address
2.1. ＮＡＳ−ＩＰｖ６アドレス
Description
詳細
This Attribute indicates the identifying IPv6 Address of the NAS
which is requesting authentication of the user, and SHOULD be
unique to the NAS within the scope of the RADIUS server. NAS-
IPv6-Address is only used in Access-Request packets. NAS-IPv6-
Address and/or NAS-IP-Address MAY be present in an Access-Request
packet; however, if neither attribute is present then NAS-
Identifier MUST be present.
この属性はユーザーの認証を求めているＮＡＳを識別するＩＰｖ６アドレ
スを示し、アドレスはラディウスサーバーの範囲でＮＡＳに特有であるべ
きです(SHOULD)。ＮＡＳ-ＩＰｖ６アドレスはアクセス要求パケットでだ
け使います。ＮＡＳ-ＩＰｖ６アドレスやＮＡＳ-ＩＰアドレスがアクセス
要求パケットで存在しているかもしれません(MAY)；しかし、いずれの属
性もなければＮＡＳ識別子が存在しているに違いありません(MUST)。
A summary of the NAS-IPv6-Address Attribute format is shown below.
The fields are transmitted from left to right.
ＮＡＳ-ＩＰｖ６アドレス属性フォーマットの要約を以下に記します。フィー
ルドは左から右に送信されます。
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 | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
95 for NAS-IPv6-Address
95 ＮＡＳ−ＩＰｖ６アドレス
Length
長さ
18
18
Address
アドレス
The Address field is 16 octets.
アドレレスフィールドは１６オクテット
3.2. Framed-Interface-Id
3.2. フレームインタフェース識別子
Description
詳細
This Attribute indicates the IPv6 interface identifier to be
configured for the user. It MAY be used in Access-Accept packets.
If the Interface-Identifier IPv6CP option [11] has been
successfully negotiated, this Attribute MUST be included in an
Access-Request packet as a hint by the NAS to the server that it
would prefer that value. It is recommended, but not required,
that the server honor the hint.
この属性はユーザーのＩＰｖ６インタフェース識別子を示します。これは
アクセス許可パケットで使われるかもしれません(MAY)。もしインターフェー
ス識別子IPv6CPオプション[11]の交渉が成功したら、ＮＡＳはこの属性を
好ましい値のヒントとしてアクセス要求に含められなくてはなりません
(MUST)。サーバがヒントを重んじることが勧められますが、必須ではあり
ません(recommended)。
A summary of the Framed-Interface-Id Attribute format is shown below.
The fields are transmitted from left to right.
フレームインタフェース識別子属性フォーマットの概要を以下に示します。
フィールドは左から右に送られます。
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 | Interface-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Id
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Interface-Id |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
96 for Framed-Interface-Id
95 フレームインタフェース識別子
Length
長さ
10
Interface-Id
インタフェース識別子
The Interface-Id field is 8 octets.
インタフェース識別子フィールドは８オクテットです。
2.3. Framed-IPv6-Prefix
2.3. フレームＩＰｖ６プレフィックス
Description
詳細
This Attribute indicates an IPv6 prefix (and corresponding route)
to be configured for the user. It MAY be used in Access-Accept
packets, and can appear multiple times. It MAY be used in an
Access-Request packet as a hint by the NAS to the server that it
would prefer these prefix(es), but the server is not required to
honor the hint. Since it is assumed that the NAS will plumb a
route corresponding to the prefix, it is not necessary for the
server to also send a Framed-IPv6-Route attribute for the same
prefix.
この属性はユーザーのＩＰｖ６プレフィックス（と対応する経路）を示し
ます。これはアクセス許可パケットで使われるかもしれなくて(MAY)、何
度も現れることが出来ます。ＮＡＳはサーバへの好ましいプレフィックス
のヒントとしてアクセス要求に設定するかもしれませんが(MAY)、サーバ
はヒントを重視することが要求されません。ＮＡＳがプレフィックスに対
応している経路として働くと想定されるので、サーバーが同じプレフィッ
クスのフレームＩＰｖ６経路属性を送ることは必要ではありません。
A summary of the Framed-IPv6-Prefix Attribute format is shown below.
The fields are transmitted from left to right.
フレームＩＰｖ６プレフィックス属性フォーマットの要約を下に記述します。
フィールドは左から右に送られます。
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 | Reserved | Prefix-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
97 for Framed-IPv6-Prefix
97 フレームＩＰｖ６プレフィックス
Length
長さ
At least 4 and no larger than 20.
最小４、最大２０
Reserved
予約
This field, which is reserved and MUST be present, is always set
to zero.
このフィールドは予約で、存在しなければならず(MUST)、常にゼロを設定
します。
Prefix-Length
プレフィックス長
The length of the prefix, in bits. At least 0 and no larger than
128.
ビット単位のプレフィックス長。最小０で、最大１２８
Prefix
プレフィックス
The Prefix field is up to 16 octets in length. Bits outside of
the Prefix-Length, if included, must be zero.
プレフィックスフィールドは１６オクテット以下です。プレフィックス長
を超えるビットは、もしあれば、ゼロであるに違いありません。
2.4. Login-IPv6-Host
2.4. ログインＩＰｖ６ホスト
Description
詳細
This Attribute indicates the system with which to connect the
user, when the Login-Service Attribute is included. It MAY be
used in Access-Accept packets. It MAY be used in an Access-
Request packet as a hint to the server that the NAS would prefer
to use that host, but the server is not required to honor the
hint.
この属性は、ログインサービス属性が含まれる時に、ユーザーの接続する
システムを示します。これはアクセス許可パケットで使われるかもしれま
せん(MAY)。これはアクセス要求でＮＡＳがサーバに好ましいホストのヒ
ントを与えるために使われるかもしれませんが(MAY)、サーバはヒントを
重視することを要求されません。
A summary of the Login-IPv6-Host Attribute format is shown below.
The fields are transmitted from left to right.
ログインＩＰｖ６ホスト属性のフォーマットの概要を以下に示します。フィー
ルドは左から右に送られます。
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 | Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
98 for Login-IPv6-Host
98 ログインＩＰｖ６ホスト
Length
長さ
18
18
Address
アドレス
The Address field is 16 octets in length. The value
0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF indicates that the NAS SHOULD
allow the user to select an address or name to be connected to.
The value 0 indicates that the NAS SHOULD select a host to connect
the user to. Other values indicate the address the NAS SHOULD
connect the user to.
アドレスフィールドは長さは１６オクテットです。
0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFの値はＮＡＳがユーザーに接続すべ
きアドレスや名前の選択を許すべき(SHOULD)であることを示します。０の
値はＮＡＳがユーザーを接続するホストを選択するべき(SHOULD)であるこ
とを示します。他の値はＮＡＳがユーザーを接続すべき(SHOULD)アドレス
を示します。
2.5. Framed-IPv6-Route
2.5. フレームＩＰｖ６経路
Description
詳細
This Attribute provides routing information to be configured for
the user on the NAS. It is used in the Access-Accept packet and
can appear multiple times.
この属性はＮＡＳ上のユーザーに設定する経路情報を提供します。これは
アクセス許可パケットで使われて、何度も現れる事ができます。
A summary of the Framed-IPv6-Route Attribute format is shown below.
The fields are transmitted from left to right.
フレームＩＰｖ６経路属性フォーマットの概要を以下に示します。フィール
ドは左から右に送られます。
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 | Text ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
99 for Framed-IPv6-Route
99 フレームＩＰｖ６経路
Length
長さ
>=3
３以上
Text
テキスト
The Text field is one or more octets, and its contents are
implementation dependent. The field is not NUL (hex 00)
terminated. It is intended to be human readable and MUST NOT
affect operation of the protocol.
テキストフィールドは１オクテット以上で、中身は実装に依存します。
フィールドはヌル（１６進数の００）で終わりません。これは人間が読む
ことができるように意図されていて、プロトコル操作に影響を与えてはな
りません(MUST NOT)。
For IPv6 routes, it SHOULD contain a destination prefix optionally
followed by a slash and a decimal length specifier stating how
many high order bits of the prefix to use. That is followed by a
space, a gateway address, a space, and one or more metrics
(encoded in decimal) separated by spaces. Prefixes and addresses
are formatted as described in [16]. For example,
"2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1".
ＩＰｖ６経路で、これは宛先プレフィックスを含むべきで(SHOULD)、オプ
ションでスラッシュと１０進数のプレフィックスの何ビットを使うかを示
す長さ表示を含みます。これにスペースとゲートウェイアドレスとスペー
スとスペースで区切った１つ以上のメトリックが続きます。プレフィック
スとアドレスのフォーマットは[16]で記述され形式です。例えば
"2000:0:0:106::/64 2000::106:a00:20ff:fe99:a998 1"です。
Whenever the gateway address is the IPv6 unspecified address the
IP address of the user SHOULD be used as the gateway address. The
unspecified address can be expressed in any of the acceptable
formats described in [16]. For example, "2000:0:0:106::/64 :: 1".
ゲートウェイアドレスがＩＰｖ６の特定されていないアドレスである時は、
ユーザーのＩＰアドレスはゲートウェイアドレスとして用いられるべきで
す(SHOULD)。特定されていないアドレスは[16]で記述されたフォーマット
のどれ表現してもかまいません。例えば"2000:0:0:106::/64 :: 1"です。
2.6. Framed-IPv6-Pool
2.6. フレームＩＰｖ６プール
Description
詳細
This Attribute contains the name of an assigned pool that SHOULD
be used to assign an IPv6 prefix for the user. If a NAS does not
support multiple prefix pools, the NAS MUST ignore this Attribute.
この属性はユーザーのＩＰｖ６プレフィックスを割り当てるために使われ
るべき(SHOULD)プールの名前を含んでいます。もしＮＡＳが多数のプレ
フィックスプールをサポートしないなら、ＮＡＳはこの属性を無視しなく
てはなりません(MUST)。
A summary of the Framed-IPv6-Pool Attribute format is shown below.
The fields are transmitted from left to right.
フレームＩＰｖ６プール属性フォーマットの概要を以下に示します。フィー
ルドは左から右に送られます。
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
タイプ
100 for Framed-IPv6-Pool
100 フレームＩＰｖ６プール
Length
長さ
>= 3
３以上
String
文字列
The string field contains the name of an assigned IPv6 prefix pool
configured on the NAS. The field is not NUL (hex 00) terminated.
文字列フィールドはＮＡＳ上の割り当てＩＰｖ６プレフィックスプールの
名前を含んでいます。フィールドはヌル（１６進数の００）で終了しませ
ん。
3. Table of Attributes
3. 属性表
The following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity.
次の表は属性がどの種類パケットで、どれだけあるかを示します。
Request Accept Reject Challenge Accounting # Attribute
Request
要求 許可 拒否 チャレン 課金 # 属性
ジ 要求
0-1 0 0 0 0-1 95 NAS-IPv6-Address
0-1 0-1 0 0 0-1 96 Framed-Interface-Id
0+ 0+ 0 0 0+ 97 Framed-IPv6-Prefix
0+ 0+ 0 0 0+ 98 Login-IPv6-Host
0 0+ 0 0 0+ 99 Framed-IPv6-Route
0 0-1 0 0 0-1 100 Framed-IPv6-Pool
4. References
4. 参考文献
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March, 1997.
[2] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO
10646", RFC 2044, October 1996.
[3] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy
Implementation in Roaming", RFC 2607, June 1999.
[4] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[6] Zorn, G., Mitton, D. and B. Aboba, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867, June
2000.
[7] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M.
and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support",
RFC 2868, June 2000.
[8] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions",
RFC 2869, June 2000.
[9] Kent S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[11] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472,
December 1998.
[12] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via
IPv4 Clouds", RFC 3056, February 2001.
[13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 2460, December 1998.
[14] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4
Domains without Explicit Tunnels", RFC 2529, March 1999.
[15] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6
Hosts and Routers", RFC 2893, August 2000.
[16] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 2373, July 1998.
5. Security Considerations
5. セキュリティの考察
This document describes the use of RADIUS for the purposes of
authentication, authorization and accounting in IPv6-enabled
networks. In such networks, the RADIUS protocol may run either over
IPv4 or over IPv6. Known security vulnerabilities of the RADIUS
protocol are described in [3], [4] and [8].
この文書はＩＰｖ６を使用可能なネットワークで認証と認可と課金の目的の
ラディウスの用途を記述します。このようなネットワークで、ラディウスプ
ロトコルはＩＰｖ４上やＩＰｖ６上で動作するかもしれません。ラディウス
プロトコルの既知のセキュリティ周知の弱点が[3][4][8]で記述されます。
Since IPSEC [9] is mandatory to implement for IPv6, it is expected
that running RADIUS implementations supporting IPv6 will typically
run over IPSEC. Where RADIUS is run over IPSEC and where
certificates are used for authentication, it may be desirable to
avoid management of RADIUS shared secrets, so as to leverage the
improved scalability of public key infrastructure.
IPSEC[9]がＩＰｖ６の必須の機能なので、ＩＰｖ６をサポートしているラディ
ウスの実行は典型的にIPSEC上で走ると思われます。ラディウスがIPSEC上で
動作し、証明書が認証で使われる場合、公開鍵インフラの改善されたスケー
ラビリティの影響から、ラディウス共有秘密鍵の管理を避けることは望まし
いかもしれません。
Within RADIUS, a shared secret is used for hiding of attributes such
as User-Password [4] and Tunnel-Password [7]. In addition, the
shared secret is used in computation of the Response Authenticator
[4], as well as the Message-Authenticator attribute [8]. Therefore,
in RADIUS a shared secret is used to provide confidentiality as well
as integrity protection and authentication. As a result, only use of
IPSEC ESP with a non-null transform can provide security services
sufficient to substitute for RADIUS application-layer security.
Therefore, where IPSEC AH or ESP null is used, it will typically
still be necessary to configure a RADIUS shared secret.
ラディウスの中で、共有秘密鍵がユーザーパスワード[4]とトンネルパスワー
ド[7]のような属性の暗号化のために使われます。加えて、共有秘密鍵は、回
答認証[4]とメッセージ認証属性[8]の計算で使われます。それ故に、ラディ
ウスの共有秘密鍵が、完全性保護と認証と機密性を供給するために使われま
す。結果として、ヌル変換でないIPSECのＥＳＰだけでラディウスアプリケー
ション層セキュリティの代わりに用いるに十分なセキュリティサービスを供
給することができます。しかしIPSECのＡＨかヌルＥＳＰを使った場合、ラ
ディウス共有秘密鍵を設定することは典型的にまだ必要でしょう。
However, where RADIUS is run over IPSEC ESP with a non-null
transform, the secret shared between the NAS and the RADIUS server
MAY NOT be configured. In this case, a shared secret of zero length
MUST be assumed.
しかしながら、IPSECのヌル変換でないＥＳＰによって、ＮＡＳとラディウス
サーバー間の共有秘密鍵が設定されないかもしれません(MAY NOT)。この場合、
ゼロ長の共有秘密鍵が仮定されなくてはなりません(MUST)。
6. IANA Considerations
6. ＩＡＮＡの考慮
This document requires the assignment of six new RADIUS attribute
numbers for the following attributes:
この文書は次の属性のために６つの新しいラディウス属性番号の割当てを必
要とします：
NAS-IPv6-Address
Framed-Interface-Id
Framed-IPv6-Prefix
Login-IPv6-Host
Framed-IPv6-Route
Framed-IPv6-Pool
See section 3 for the registered list of numbers.
登録された番号のリストは３章を見てください。
7. Acknowledgments
7. 謝辞
The authors would like to acknowledge Jun-ichiro itojun Hagino of IIJ
Research Laboratory, Darran Potter of Cisco and Carl Rigney of Lucent
for contributions to this document.
著者はこの文書への貢献のためにIIJ研究所のJun-ichiro itojun Haginoと
CiscoのDarran PotterとLucentのCarl Rigneyに感謝したいです。
8. Authors' Addresses
8. 著者のアドレス
Bernard Aboba
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052
Phone: +1 425 936 6605
Fax: +1 425 936 7329
EMail: bernarda@microsoft.com
Glen Zorn
Cisco Systems, Inc.
500 108th Avenue N.E., Suite 500
Bellevue, WA 98004
Phone: +1 425 471 4861
EMail: gwz@cisco.com
Dave Mitton
Circular Logic UnLtd.
733 Turnpike Street #154
North Andover, MA 01845
Phone: 978 683-1814
Email: david@mitton.com
Full Copyright Statement
著作権表示全文
Copyright (C) The Internet Society (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.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。