[要約] RFC 6930は、IPv4インフラストラクチャ上でのIPv6の迅速な展開（6rd）をサポートするためのRADIUS属性についての規格です。このRFCの目的は、6rdを実装するためのRADIUS属性の定義と使用方法を提供することです。
Internet Engineering Task Force (IETF) D. Guo
Request for Comments: 6930 S. Jiang, Ed.
Category: Standards Track Huawei Technologies Co., Ltd
ISSN: 2070-1721 R. Despres
RD-IPtech
R. Maglione
Cisco Systems
April 2013
RADIUS Attribute for IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)
IPv4インフラストラクチャでのIPv6迅速な展開のためのRADIUS属性（6番目）
Abstract
概要
The IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. The Dynamic Host Configuration Protocol (DHCP) 6rd option has been defined to configure the 6rd Customer Edge (CE). However, in many networks, the configuration information may be stored in the Authentication Authorization and Accounting (AAA) servers, while user configuration is mainly acquired from a Broadband Network Gateway (BNG) through the DHCP protocol. This document defines a Remote Authentication Dial-In User Service (RADIUS) attribute that carries 6rd configuration information from the AAA server to BNGs.
IPv4インフラストラクチャでのIPv6迅速な展開（第6）は、IPv4 / IPv6共存期間中にIPv4とIPv6の両方の接続サービスを同時に提供します。動的ホスト構成プロトコル（DHCP）の6番目のオプションは、6番目のカスタマーエッジ（CE）を構成するために定義されています。ただし、多くのネットワークでは、構成情報は認証承認およびアカウンティング（AAA）サーバーに格納される場合がありますが、ユーザー構成は主にDHCPプロトコルを介してブロードバンドネットワークゲートウェイ（BNG）から取得されます。このドキュメントでは、AAAサーバーからBNGに6番目の構成情報を伝達するリモート認証ダイヤルインユーザーサービス（RADIUS）属性を定義します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6930.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6930で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. IPv6 6rd Configuration with RADIUS ..............................4
4. Attributes ......................................................6
4.1. IPv6-6rd-Configuration Attribute ...........................6
4.2. Table of Attributes ........................................9
5. Diameter Considerations .........................................9
6. Security Considerations .........................................9
7. IANA Considerations ............................................10
8. Acknowledgments ................................................10
9. References .....................................................10
9.1. Normative References ......................................10
9.2. Informative References ....................................11
Recently, providers have started to deploy IPv6 and to consider transition to IPv6. The IPv6 Rapid Deployment (6rd) [RFC5969] provides both IPv4 and IPv6 connectivity services simultaneously during the IPv4/IPv6 coexistence period. 6rd is used to provide IPv6 connectivity service through legacy IPv4-only infrastructure. 6rd uses the Dynamic Host Configuration Protocol (DHCP) [RFC2131], and the 6rd Customer Edge (CE) uses the DHCP 6rd option [RFC5969] to discover a 6rd Border Relay and to configure an IPv6 prefix and address.
最近、プロバイダーはIPv6の展開を開始し、IPv6への移行を検討しています。 IPv6 Rapid Deployment（6rd）[RFC5969]は、IPv4 / IPv6共存期間中にIPv4とIPv6の両方の接続サービスを同時に提供します。 6rdは、レガシーIPv4のみのインフラストラクチャを介してIPv6接続サービスを提供するために使用されます。 6rdは動的ホスト構成プロトコル（DHCP）[RFC2131]を使用し、6rd Customer Edge（CE）はDHCP 6rdオプション[RFC5969]を使用して6rdボーダーリレーを検出し、IPv6プレフィックスとアドレスを構成します。
In many networks, user-configuration information is managed by Authentication, Authorization, and Accounting (AAA) servers. The Remote Authentication Dial-In User Service (RADIUS) protocol [RFC2865] is usually used by AAA servers to communicate with network elements. In a fixed-line broadband network, the Broadband Network Gateways (BNGs) act as the access gateway for users. The BNGs are assumed to embed a DHCP server function that allows them to handle locally any DHCP requests issued by hosts.
多くのネットワークでは、ユーザー構成情報は認証、承認、およびアカウンティング（AAA）サーバーによって管理されます。リモート認証ダイヤルインユーザーサービス（RADIUS）プロトコル[RFC2865]は、通常、AAAサーバーがネットワーク要素と通信するために使用されます。固定回線ブロードバンドネットワークでは、ブロードバンドネットワークゲートウェイ（BNG）がユーザーのアクセスゲートウェイとして機能します。 BNGは、ホストが発行したDHCP要求をローカルで処理できるようにするDHCPサーバー機能を組み込んでいると想定されています。
Since the 6rd configuration information is stored in AAA servers, and user configuration is mainly through DHCP between BNGs and hosts/CEs, new RADIUS attributes are needed to propagate the information from AAA servers to BNGs.
6番目の構成情報はAAAサーバーに格納され、ユーザー構成は主にBNGとホスト/ CE間のDHCPを介して行われるため、AAAサーバーからBNGに情報を伝達するには新しいRADIUS属性が必要です。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The terms 6rd Customer Edge (6rd CE) and 6rd Border Relay (BR) are defined in [RFC5969]. "MAC" stands for Media Access Control.
6rd Customer Edge（6rd CE）および6rd Border Relay（BR）という用語は、[RFC5969]で定義されています。 「MAC」はMedia Access Controlの略です。
Figure 1 illustrates how DHCP and the RADIUS protocol cooperate to provide 6rd CE with 6rd configuration information.
図1は、DHCPとRADIUSプロトコルがどのように連携して、6番目のCEに6番目の構成情報を提供するかを示しています。
6rd CE BNG AAA Server
| | |
|-------DHCPDISCOVER------>| |
|(Parameter Request w/ 6rd option) |
| |--Access-Request(6rd Attr)-->|
| | |
| |<--Access-Accept(6rd Attr)---|
|<-------DHCPOFFER---------| |
| (6rd option) | |
| | |
DHCP RADIUS
Figure 1: The Cooperation between DHCP and RADIUS When Combined with RADIUS Authentication
図1：RADIUS認証と組み合わせた場合のDHCPとRADIUSの連携
The BNG acts as a client of RADIUS and as a DHCP server. First, the 6rd CE MAY initiate a DHCPDISCOVER message that includes a Parameter Request option (55) [RFC2132] with the 6rd option [RFC5969]. When the BNG receives the DHCPDISCOVER, it SHOULD initiate a RADIUS Access- Request message to the RADIUS server. In that message,
BNGは、RADIUSのクライアントおよびDHCPサーバーとして機能します。最初に、6番目のCEは、6番目のオプション[RFC5969]を使用して、パラメーター要求オプション（55）[RFC2132]を含むDHCPDISCOVERメッセージを開始してもよい（MAY）。 BNGがDHCPDISCOVERを受信すると、RADIUSサーバーへのRADIUS Access-Requestメッセージを開始する必要があります（SHOULD）。そのメッセージの中で、
- the User-Name attribute (1) SHOULD be filled by the 6rd CE MAC address, and
- ユーザー名属性（1）は、6番目のCE MACアドレスで埋める必要があります。
- the User-Password attribute (2) SHOULD be filled by the shared 6rd password that has been preconfigured on the DHCP server.
- User-Password属性（2）には、DHCPサーバーで事前に構成された共有の6番目のパスワードを入力する必要があります（SHOULD）。
The BNG requests authentication, as defined in [RFC2865], with the IPv6-6rd-Configuration attribute (Section 4.1) in the desired attribute list. If the authentication request is approved by the AAA server, an Access-Accept message MUST be acknowledged with the IPv6-6rd-Configuration attribute. Then, the BNG SHOULD respond to the 6rd CE with a DHCPOFFER message, which contains a DHCP 6rd option. The recommended format of the MAC address is as defined in Calling-Station-Id ([RFC3580], Section 3.20) without the SSID (Service Set Identifier) portion.
BNGは、[RFC2865]で定義されているように、目的の属性リストのIPv6-6rd-Configuration属性（セクション4.1）を使用して認証を要求します。認証要求がAAAサーバーによって承認される場合、Access-AcceptメッセージはIPv6-6rd-Configuration属性で確認されなければなりません（MUST）。次に、BNG SHOULDは、6番目のCEにDHCPOFFERメッセージで応答する必要があります。これには、DHCP 6rdオプションが含まれています。 MACアドレスの推奨フォーマットは、Calling-Station-Id（[RFC3580]、セクション3.20）で定義されているもので、SSID（Service Set Identifier）部分は含まれていません。
Figure 2 describes another scenario -- later re-authorization -- in which the authorization operation is not coupled with authentication. Authorization relevant to 6rd is done independently after the authentication process.
図2は、承認操作が認証と連動していない別のシナリオ（後で再承認）を示しています。 6rdに関連する承認は、認証プロセスの後に独立して行われます。
6rd CE BNG AAA Server
| | |
|--------DHCPREQUEST------>| |
|(Parameter Request w/ 6rd option) |
| |--Access-Request(6rd Attr)-->|
| | |
| |<--Access-Accept(6rd Attr)---|
| | |
|<---------DHCPACK---------| |
| (6rd option) | |
| | |
DHCP RADIUS
Figure 2: The Cooperation between DHCP and RADIUS When Decoupled from RADIUS Authentication
図2：RADIUS認証から切り離された場合のDHCPとRADIUSの連携
In this scenario, the Access-Request packet SHOULD contain a Service-Type attribute (6) with the value Authorize Only (17); thus, according to [RFC5080], the Access-Request packet MUST contain a State attribute that it obtains from the previous authentication process.
このシナリオでは、Access-Requestパケットには、Authorize Only（17）という値のService-Type属性（6）が含まれる必要があります（SHOULD）。したがって、[RFC5080]によると、Access-Requestパケットには、以前の認証プロセスから取得したState属性が含まれている必要があります。
In both above-mentioned scenarios, Message-Authenticator (type 80) [RFC2865] SHOULD be used to protect both Access-Request and Access-Accept messages.
上記の両方のシナリオで、Message-Authenticator（タイプ80）[RFC2865]を使用して、Access-RequestメッセージとAccess-Acceptメッセージの両方を保護する必要があります（SHOULD）。
After receiving the IPv6-6rd-Configuration attribute in the initial Access-Accept, the BNG SHOULD store the received 6rd configuration parameters locally. When the 6rd CE sends a DHCP Request message to request an extension of the lifetime for the assigned address, the BNG does not have to initiate a new Access-Request towards the AAA server to request the 6rd configuration parameters. The BNG could retrieve the previously stored 6rd configuration parameters and use them in its reply.
最初のAccess-AcceptでIPv6-6rd-Configuration属性を受け取った後、BNGは受け取った6番目の構成パラメーターをローカルに保存する必要があります（SHOULD）。 6rd CEがDHCP要求メッセージを送信して、割り当てられたアドレスのライフタイムの延長を要求する場合、BNGは、6番目の構成パラメータを要求するために、AAAサーバーに対して新しいAccess-Requestを開始する必要はありません。 BNGは、以前に保存された6番目の構成パラメータを取得し、その応答で使用できます。
If the BNG does not receive the IPv6-6rd-Configuration attribute in the Access-Accept, it MAY fall back to a preconfigured default 6rd configuration, if any. If the BNG does not have any preconfigured default 6rd configuration or if the BNG receives an Access-Reject, the tunnel cannot be established.
BNGがAccess-AcceptでIPv6-6rd-Configuration属性を受信しない場合、事前に構成されたデフォルトの6rd構成があれば、それにフォールバックできます（MAY）。 BNGに事前構成されたデフォルトの6番目の構成がない場合、またはBNGがAccess-Rejectを受信した場合、トンネルを確立できません。
As specified in [RFC2131], Section 4.4.5 ("Reacquisition and expiration"), if the DHCP server to which the DHCP Request message was sent at time T1 has not responded by time T2 (typically 0.375*duration_of_lease after T1), the 6rd CE (the DHCP client) SHOULD enter the REBINDING state and attempt to contact any server.
[RFC2131]のセクション4.4.5（「再取得と有効期限」）で指定されているように、時刻T1にDHCPリクエストメッセージが送信されたDHCPサーバーが時刻T2（通常はT1後0.375 * duration_of_lease）までに応答しない場合、 6rd CE（DHCPクライアント）はREBINDING状態に入り、任意のサーバーへの接続を試みる必要があります（SHOULD）。
In this situation, the secondary BNG receiving the new DHCP message MUST initiate a new Access-Request towards the AAA server. The secondary BNG MAY include the IPv6-6rd-Configuration attribute in its Access-Request.
この状況では、新しいDHCPメッセージを受信するセカンダリBNGは、AAAサーバーへの新しいアクセス要求を開始する必要があります。セカンダリBNGは、Access-RequestにIPv6-6rd-Configuration属性を含めることができます（MAY）。
This section defines the IPv6-6rd-Configuration attribute that is used in both above-mentioned scenarios. The attribute design follows [RFC6158] and refers to [RFC6929].
このセクションでは、上記の両方のシナリオで使用されるIPv6-6rd-Configuration属性を定義します。属性の設計は[RFC6158]に従い、[RFC6929]を参照します。
The specification requires that multiple IPv4 addresses are associated with one IPv6 prefix. Given that RADIUS currently has no recommended way of grouping multiple attributes, the design below appears to be a reasonable compromise. The IPv6-6rd-Configuration attribute is structured as follows:
この仕様では、複数のIPv4アドレスが1つのIPv6プレフィックスに関連付けられている必要があります。 RADIUSには現在複数の属性をグループ化する推奨方法がないため、以下の設計は妥当な妥協案のようです。 IPv6-6rd-Configuration属性は次のように構成されています。
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 | SubType1 | SubLen1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4MaskLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType2 | SubLen2 | Reserved | 6rdPrefixLen |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ 6rdPrefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SubType3 | SubLen3 | 6rdBRIPv4Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 6rdBRIPv4Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
173
１７３
Length
長さ
28 + n*6 (the length of the entire attribute in octets, where n is the number of BR IPv4 addresses and minimum n is 1)
28 + n * 6（オクテット単位の属性全体の長さ。nはBR IPv4アドレスの数であり、最小のnは1です）
SubType1
サブタイプ1
1 (SubType number, for the IPv4 Mask Length suboption)
1（IPv4マスク長サブオプション用のサブタイプ番号）
SubLen1
SubLen1
6 (the length of the IPv4 Mask Length suboption)
6（IPv4マスク長サブオプションの長さ）
IPv4MaskLen
IPv4MaskLen
The number of high-order bits that are identical across all CE IPv4 addresses within a given 6rd domain. This may be any value between 0 and 32. Any value greater than 32 is invalid. Since [RFC6158], Appendix A.2.1, has forbidden 8-bit fields, a 32-bit field is used here.
特定の6rdドメイン内のすべてのCE IPv4アドレスで同一の高位ビットの数。 0から32までの任意の値を指定できます。32より大きい値は無効です。付録A.2.1の[RFC6158]では8ビットフィールドが禁止されているため、ここでは32ビットフィールドを使用しています。
SubType2
サブタイプ2
2 (SubType number for the 6rd prefix suboption)
2（6番目の接頭部サブオプションのサブタイプ番号）
SubLen2
サブレン2
20 (the length of the 6rd prefix suboption)
20（6番目の接頭部サブオプションの長さ）
Reserved
予約済み
Set to all 0 for now. Reserved for future use. To be compatible with other IPv6 prefix attributes in the RADIUS protocol, the bits MUST be set to zero by the sender and MUST be ignored by the receiver.
ここではすべて0に設定します。将来の使用のために予約されています。 RADIUSプロトコルの他のIPv6プレフィックス属性と互換性を持たせるには、ビットを送信者がゼロに設定する必要があり、受信者が無視する必要があります。
6rdPrefixLen
6rdPrefixLen
The IPv6 Prefix length of the Service Provider's 6rd IPv6 prefix in number of bits. The 6rdPrefixLen MUST be less than or equal to 128.
サービスプロバイダーの6番目のIPv6プレフィックスのIPv6プレフィックス長（ビット数）。 6rdPrefixLenは128以下でなければなりません。
6rdPrefix
6rdPrefix
The Service Provider's 6rd IPv6 prefix represented as a 16-octet IPv6 address. The bits after the 6rdPrefixlen number of bits in the prefix SHOULD be set to zero.
16オクテットのIPv6アドレスとして表されるサービスプロバイダーの6番目のIPv6プレフィックス。プレフィックスの6rdPrefixlenビット数の後のビットはゼロに設定する必要があります（SHOULD）。
SubType3
サブタイプ3
3 (SubType number, for the 6rd Border Relay IPv4 address suboption)
3（サブタイプ番号、6番目のボーダーリレーIPv4アドレスサブオプションの場合）
SubLen3
サブレン3
6 (the length of the 6rd Border Relay IPv4 address suboption)
6（6番目のボーダーリレーIPv4アドレスサブオプションの長さ）
6rdBRIPv4Address
6rdBRIPv4Address
One or more IPv4 addresses of the 6rd Border Relay(s) for a given 6rd domain. The maximum RADIUS attribute length of 255 octets results in a limit of 37 IPv4 addresses.
特定の6rdドメインの6rdボーダーリレーの1つ以上のIPv4アドレス。 RADIUS属性の最大長が255オクテットの場合、IPv4アドレスは37に制限されます。
Since the subtypes have values, they can appear in any order. If multiple 6rdBRIPv4Address (subtype 3) appear, they are RECOMMENDED to be placed together.
サブタイプには値があるため、それらは任意の順序で表示できます。複数の6rdBRIPv4Address（サブタイプ3）が表示される場合、それらを一緒に配置することをお勧めします。
The IPv6-6rd-Configuration attribute is normally used in Access-Accept messages. It MAY be used in Access-Request packets as a hint to the RADIUS server; for example, if the BNG is preconfigured with a default 6rd configuration, these parameters MAY be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the BNG, and it MAY assign different 6rd parameters.
IPv6-6rd-Configuration属性は通常、Access-Acceptメッセージで使用されます。 RADIUSサーバーへのヒントとしてAccess-Requestパケットで使用される場合があります。たとえば、BNGがデフォルトの6番目の構成で事前構成されている場合、これらのパラメーターを属性に挿入できます（MAY）。 RADIUSサーバーは、BNGから送信されたヒントを無視してもよい（MAY）、異なる6番目のパラメーターを割り当ててもよい（MAY）。
If the BNG includes the IPv6-6rd-Configuration attribute, but the AAA server does not recognize it, this attribute MUST be ignored by the AAA server.
BNGにIPv6-6rd-Configuration属性が含まれているが、AAAサーバーがそれを認識しない場合、AAAサーバーはこの属性を無視する必要があります。
If the BNG does not receive the IPv6-6rd-Configuration attribute in the Access-Accept, it MAY fallback to a preconfigured default 6rd configuration, if any. If the BNG does not have any preconfigured default 6rd configuration, the 6rd tunnel cannot be established.
BNGがAccess-AcceptでIPv6-6rd-Configuration属性を受信しない場合、事前に構成されたデフォルトの6rd構成があれば、それにフォールバックできます（MAY）。 BNGに事前構成されたデフォルトの6番目の構成がない場合、6番目のトンネルを確立できません。
If the BNG is pre-provisioned with a default 6rd configuration and the 6rd configuration received in Access-Accept is different from the configured default, then the 6rd configuration received in the Access-Accept message MUST be used for the session.
BNGがデフォルトの6番目の構成で事前プロビジョニングされており、Access-Acceptで受信した6番目の構成が構成済みのデフォルトと異なる場合、セッションではAccess-Acceptメッセージで受信した6番目の構成を使用する必要があります。
If the BNG cannot support the received 6rd configuration for any reason, the tunnel SHOULD NOT be established.
BNGが何らかの理由で受信した6番目の構成をサポートできない場合、トンネルは確立されるべきではありません（SHOULD NOT）。
The following table adds to the one in [RFC2865], Section 5.44, providing a guide to the quantity of IPv6-6rd-Configuration attributes that may be found in each kind of packet.
次の表は、[RFC2865]のセクション5.44の表に追加され、各種類のパケットで検出されるIPv6-6rd-Configuration属性の数についてのガイドを提供します。
Request Accept Reject Challenge Accounting # Attribute Request 0-1 0-1 0 0 0-1 173 IPv6-6rd-Configuration 0-1 0-1 0 0 0-1 1 User-Name 0-1 0 0 0 0-1 2 User-Password 0-1 0-1 0 0 0-1 6 Service-Type 0-1 0-1 0-1 0-1 0-1 80 Message-Authenticator
Request Accept Reject Challenge Accounting＃Attribute Request 0-1 0-1 0 0 0-1 173 IPv6-6rd-Configuration 0-1 0-1 0 0 0-1 1 User-Name 0-1 0 0 0 0-1 2 User-Password 0-1 0-1 0 0 0-1 6 Service-Type 0-1 0-1 0-1 0-1 0-1 80 Message-Authenticator
The following key defines the meanings 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. 1 Exactly one instance of this attribute MUST be present in packet.
0この属性はパケットに存在してはなりません。 0+この属性のゼロ個以上のインスタンスがパケットに存在する場合があります。 0-1この属性のゼロまたは1つのインスタンスがパケットに存在する場合があります。 1この属性の正確に1つのインスタンスがパケットに存在する必要があります。
This attribute is usable within either RADIUS or Diameter [RFC6733]. Since the attribute defined in this document has been allocated from the standard RADIUS type space, no special handling is required by Diameter entities.
この属性は、RADIUSまたはDiameterのいずれかで使用できます[RFC6733]。このドキュメントで定義されている属性は標準のRADIUSタイプスペースから割り当てられているため、Diameterエンティティによる特別な処理は必要ありません。
In 6rd scenarios, both CE and BNG are within a provider network, which can be considered as a closed network and a lower-threat environment. A similar consideration can be applied to the RADIUS message exchange between the BNG and the AAA server.
6番目のシナリオでは、CEとBNGの両方がプロバイダーネットワーク内にあります。これは、クローズドネットワークとより脅威の少ない環境と見なすことができます。同様の考慮事項は、BNGとAAAサーバー間のRADIUSメッセージ交換にも適用できます。
In 6rd scenarios, the RADIUS protocol is run over IPv4. Known security vulnerabilities of the RADIUS protocol are discussed in [RFC2607], [RFC2865], and [RFC2869]. Use of IPsec [RFC4301] for providing security when RADIUS is carried in IPv6 is discussed in [RFC3162].
6番目のシナリオでは、RADIUSプロトコルはIPv4で実行されます。 RADIUSプロトコルの既知のセキュリティ脆弱性は、[RFC2607]、[RFC2865]、および[RFC2869]で説明されています。 RADIUSがIPv6で実行されるときにセキュリティを提供するためのIPsec [RFC4301]の使用については、[RFC3162]で説明されています。
To get unauthorized 6rd configuration information, a malicious user may use MAC address spoofing and/or a dictionary attack on the shared 6rd password that has been preconfigured on the DHCP server. The relevant security issues have been considered in Section 12 of [RFC5969].
不正な6番目の構成情報を取得するために、悪意のあるユーザーは、DHCPサーバーで事前構成されている共有6番目のパスワードに対してMACアドレスのなりすましや辞書攻撃を使用する可能性があります。関連するセキュリティ問題は、[RFC5969]のセクション12で検討されています。
Security issues that may arise specifically between the 6rd CE and BNG are discussed in [RFC5969]. Furthermore, generic DHCP security mechanisms can be applied to DHCP intercommunication between 6rd CE and BNG.
6rd CEとBNGの間で特に発生する可能性があるセキュリティ問題は、[RFC5969]で説明されています。さらに、汎用DHCPセキュリティメカニズムを6rd CEとBNG間のDHCP相互通信に適用できます。
Security considerations for the Diameter protocol are discussed in [RFC6733].
Diameterプロトコルのセキュリティに関する考慮事項は、[RFC6733]で説明されています。
Per this document, IANA has assigned one new RADIUS Attribute Type in the "Radius Types" registry (currently located at http://www.iana.org/assignments/radius-types) for the following attribute:
このドキュメントに従って、IANAは "Radius Types"レジストリ（現在はhttp://www.iana.org/assignments/radius-typesにあります）で次の属性に対して1つの新しいRADIUS属性タイプを割り当てました。
IPv6-6rd-Configuration (173)
IPv6-6rd構成（173）
The authors would like to thank Alan DeKok, Yong Cui, Leaf Yeh, Sean Turner, Joseph Salowey, Glen Zorn, Dave Nelson, Bernard Aboba, Benoit Claise, Barry Lieba, Stephen Farrell, Adrian Farrel, Ralph Droms, and other members of the SOFTWIRE WG, RADEXT WG, AAA Doctors, and Security Directorate for valuable comments.
著者は、アラン・デコック、ヨン・クイ、リーフ・イェ、ショーン・ターナー、ジョセフ・サロウイ、グレン・ゾーン、デイブ・ネルソン、バーナード・アボバ、ブノワ・クレイズ、バリー・リーバ、スティーブン・ファレル、エイドリアン・ファレル、ラルフ・ドロムス、およびその他のメンバーに感謝しますSOFTWIRE WG、RADEXT WG、AAA Doctors、およびSecurity Directorateから貴重なコメントをいただきました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R。、「Dynamic Host Configuration Protocol」、RFC 2131、1997年3月。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、1997年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、2000年6月。
[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、Zorn、G。、およびD. Mitton、「RADIUS and IPv6」、RFC 3162、2001年8月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、2005年12月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080] Nelson、D。およびA. DeKok、「Common Remote Authentication Dial In User Service（RADIUS）Implementation Issues and Suggested Fixes」、RFC 5080、2007年12月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969] Townsley、W.およびO. Troan、「IPv4 Infrastructures on IPv4 Infrastructures（6rd）-Protocol Specification」、RFC 5969、2010年8月。
[RFC6158] DeKok, A., Ed., and G. Weber, "RADIUS Design Guidelines", BCP 158, RFC 6158, March 2011.
[RFC6158] DeKok、A.、Ed。、およびG. Weber、「RADIUS Design Guidelines」、BCP 158、RFC 6158、2011年3月。
[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, October 2012.
[RFC6733] Fajardo、V.、Ed。、Arkko、J.、Loughney、J.、and G. Zorn、Ed。、 "Diameter Base Protocol"、RFC 6733、October 2012。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607] Aboba、B。およびJ. Vollbrecht、「Proxy Chaining and Policy Implementation in Roaming」、RFC 2607、1999年6月。
[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney、C.、Willats、W。、およびP. Calhoun、「RADIUS Extensions」、RFC 2869、2000年6月。
[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[RFC3580] Congdon、P.、Aboba、B.、Smith、A.、Zorn、G。、およびJ. Roese、「IEEE 802.1X Remote Authentication Dial In User Service（RADIUS）Usage Guidelines」、RFC 3580、2003年9月。
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial-In User Service (RADIUS) Protocol Extensions", RFC 6929, April 2013.
[RFC6929] DeKok、A。およびA. Lior、「Remote Authentication Dial-In User Service（RADIUS）Protocol Extensions」、RFC 6929、2013年4月。
Authors' Addresses
著者のアドレス
Dayong Guo Huawei Technologies Co., Ltd Q14 Huawei Campus, 156 BeiQi Road, ZhongGuan Cun, Hai-Dian District, Beijing 100095 P.R. China
DAはテクノロジー株式会社としてGU oh UAを使用しています。Q14hu Aをキャンパスとして、156はIQ i道路、z洪GUケースc UN、h love-Dイアン地区、北京100095
EMail: guoseu@huawei.com
Sheng Jiang (Editor) Huawei Technologies Co., Ltd Q14 Huawei Campus, 156 BeiQi Road, ZhongGuan Cun, Hai-Dian District, Beijing 100095 P.R. China
S横江（編集者）hu Aはテクノロジーズ株式会社Q14 hu Aはキャンパス、156はIQ i道路、z洪GUケースc UN、h爱-Dイアン地区、北京100095 P.R.中国
EMail: jiangsheng@huawei.com
Remi Despres RD-IPtech 3 rue du President Wilson Levallois France
Remi Despres RD-IPtech 3 rue du President Wilson Levallois France
EMail: despres.remi@laposte.net
Roberta Maglione Cisco Systems 181 Bay Street Toronto, ON M5J 2T3 Canada
Roberta Sweater Cisco Systems 181 Bay Street Toronto、ON M5J 2T3 Canada
EMail: robmgl@cisco.com