Internet Engineering Task Force (IETF) R. Maglione
Request for Comments: 6519 Telecom Italia
Category: Standards Track A. Durand
ISSN: 2070-1721 Juniper Networks
February 2012
RADIUS Extensions for Dual-Stack Lite
Abstract
抽象
Dual-Stack Lite is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix. Dual-Stack Lite requires pre-configuration of the Dual-Stack Lite Address Family Transition Router (AFTR) tunnel information on the Basic Bridging BroadBand (B4) element. In many networks, the customer profile information may be stored in Authentication, Authorization, and Accounting (AAA) servers, while client configurations are mainly provided through the Dynamic Host Configuration Protocol (DHCP). This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attribute to carry the Dual-Stack Lite AFTR tunnel name; the RADIUS attribute is defined based on the equivalent DHCPv6 OPTION_AFTR_NAME option. This RADIUS attribute is meant to be used between the RADIUS server and the Network Access Server (NAS); it is not intended to be used directly between the B4 element and the RADIUS server.
デュアルスタックLiteは唯一のIPv6プレフィックスでアドレス指定されているお客様に、IPv4とIPv6接続の両方を提供するソリューションです。デュアルスタックLiteは、基本的なブリッジングブロードバンド（B4）要素のデュアルスタックライトのファミリーの遷移ルータアドレス（AFTR）トンネル情報の事前設定が必要です。クライアントの構成は、主に動的ホスト構成プロトコル（DHCP）を介して提供されている間、多くのネットワークでは、顧客プロファイル情報は、認証、認可、アカウンティング（AAA）サーバに格納することができます。この文書は、新しいリモート認証ダイヤルインユーザーサービス（RADIUS）はトンネル名AFTRデュアルスタックライトを運ぶために属性を指定します。 RADIUS属性は、同等のDHCPv6 OPTION_AFTR_NAMEオプションに基づいて定義されます。このRADIUS属性は、RADIUSサーバとネットワーク・アクセス・サーバ（NAS）の間で使用されることを意味しています。 B4要素とRADIUSサーバ間で直接使用するためのものではありません。
Status of This Memo
このメモのステータス
This is an Internet Standards Track document.
これは、インターネット標準化過程文書です。
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）の製品です。これは、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/rfc6519.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6519で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2012 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. DS-Lite Configuration with RADIUS and DHCPv6 ....................4
4. RADIUS Attribute ................................................7
4.1. DS-Lite-Tunnel-Name ........................................7
5. Table of Attributes .............................................9
6. Security Considerations .........................................9
7. IANA Considerations .............................................9
8. References .....................................................10
8.1. Normative References ......................................10
8.2. Informative References ....................................10
Dual-Stack Lite [RFC6333] is a solution to offer both IPv4 and IPv6 connectivity to customers that are addressed only with an IPv6 prefix (no IPv4 address is assigned to the attachment device). One of its key components is an IPv4-over-IPv6 tunnel, but a Dual-Stack-Lite Basic Bridging BroadBand (B4) element will not know if the network to which it is attached offers Dual-Stack Lite support. Even if the B4 did know, it would not know the remote end of the tunnel to which it could establish a connection.
デュアルスタックライト[RFC6333]は唯一のIPv6プレフィックス（無IPv4アドレスが取り付け装置に割り当てられていない）を用いてアドレス指定される顧客にIPv4とIPv6接続の両方を提供するソリューションです。その重要な要素の1つは、IPv4のオーバーのIPv6トンネルですが、それが接続されているネットワークがデュアルスタックLiteのサポートを提供しています場合はデュアルスタック-Liteの基本的なブリッジングブロードバンド（B4）の要素が知ることができません。 B4は知っていたとしても、それは接続を確立することができたにトンネルのリモートエンドを知ることはできません。
To inform the B4 element of the location of the Address Family Transition Router (AFTR), a Fully Qualified Domain Name (FQDN) may be used. Once this information is conveyed, the presence of the configuration indicating the AFTR's location also informs a host to initiate Dual-Stack Lite (DS-Lite) service and become a Softwire Initiator.
アドレスファミリ移行ルータ（AFTR）の位置のB4要素を通知するために、完全修飾ドメイン名（FQDN）を使用することができます。この情報が搬送されると、AFTRの位置を示す構成の存在はまた、デュアルスタックライト（DS-Liteの）サービスを開始し、Softwireイニシエータになるためにホストに通知します。
[RFC6334] specifies a DHCPv6 option that is meant to be used by a DS-Lite client (B4 element) to discover its AFTR name. In order to be able to populate such an option, the DHCPv6 server must be pre-provisioned with the AFTR name.
[RFC6334]はそのAFTR名前を発見するためにDS-Liteクライアント（B4要素）によって使用されることを意味しているのDHCPv6オプションを指定します。そのようなオプションを移入することができるようにするために、DHCPv6サーバはAFTR名で事前にプロビジョニングする必要があります。
In broadband environments, a customer profile may be managed by Authentication, Authorization, and Accounting (AAA) servers, together with AAA for users. The Remote Authentication Dial-In User Service (RADIUS) protocol [RFC2865] is usually used by AAA servers to communicate with network elements. [RADIUS-IPv6] describes a typical broadband network scenario in which the Network Access Server (NAS) acts as the access gateway for the users (hosts or Customer Premises Equipment (CPE) devices) and also embeds a DHCPv6 server function that allows it to locally handle any DHCPv6 requests issued by the clients.
ブロードバンド環境では、顧客プロファイルは一緒にユーザーのためのAAAで、認証、許可、およびアカウンティング（AAA）サーバによって管理することができます。リモート認証ダイヤルインユーザーサービス（RADIUS）プロトコル[RFC2865]は通常のネットワーク要素と通信するためにAAAサーバによって使用されます。 [RADIUS-IPv6は】ネットワーク・アクセス・サーバ（NAS）は、ユーザ（ホストまたは顧客宅内機器（CPE）デバイス）のためのアクセスゲートウェイとして機能し、また、それがすることを可能にするDHCPv6サーバ機能が組み込まれた典型的なブロードバンドネットワークシナリオについて説明しますローカルクライアントによって発行されたすべてのDHCPv6の要求を処理します。
Since the DS-Lite AFTR information can be stored in AAA servers and the client configuration is mainly provided through DHCP running between the NAS and the requesting clients, a new RADIUS attribute is needed to send AFTR information from the AAA server to the NAS.
DS-LiteののでAFTR情報は、AAAサーバに保存することができ、クライアントの設定は主にDHCPがNASと要求するクライアントの間で実行を介して提供され、新しいRADIUS属性がNASにAAAサーバからの情報AFTR送信するために必要とされています。
This document defines a new RADIUS attribute to be used for carrying the DS-Lite Tunnel Name, based on the equivalent DHCPv6 option already specified in [RFC6334].
この文書では、すでに[RFC6334]で指定された同等のDHCPv6オプションに基づいて、DS-Liteのトンネル名を運ぶために使用される新しい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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The terms DS-Lite Basic Bridging BroadBand element (B4) and the DS-Lite Address Family Transition Router element (AFTR) are defined in [RFC6333].
用語のDS-Liteの基本的なブリッジングブロードバンド要素（B4）とDS-Liteは（AFTR）[RFC6333]で定義されている家族の遷移ルータエレメントアドレス。
Figure 1 illustrates how the RADIUS protocol and DHCPv6 work together to accomplish DS-Lite configuration on the B4 element when a PPP session is used to provide connectivity to the user.
図1は、RADIUSプロトコルとDHCPv6は、PPPセッションがユーザへの接続を提供するために使用される場合B4要素上にDS-Liteの構成を達成するために一緒に動作する方法を示す図です。
The NAS operates as a client of RADIUS and as a DHCP Server. The NAS initially sends a RADIUS Access-Request message to the RADIUS server, requesting authentication. Once the RADIUS server receives the request, it validates the sending client, and if the request is approved, the AAA server replies with an Access-Accept message including a list of attribute-value pairs that describe the parameters to be used for this session. This list MAY also contain the AFTR tunnel name. When the NAS receives a DHCPv6 client request containing the DS-Lite tunnel option, the NAS SHALL use the name returned in the RADIUS DS-Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME option in the DHCPv6 reply message.
NASは、RADIUSのクライアントとして、およびDHCPサーバとして動作します。 NASは、最初に認証を要求し、RADIUSサーバーにRADIUS Access-Requestメッセージを送信します。 RADIUSサーバが要求を受信すると、送信側クライアントを検証し、要求が承認された場合、AAAサーバは、パラメータがこのセッションのために使用されることを説明した属性と値のペアのリストを含むAccess-Acceptメッセージで応答します。このリストには、AFTRトンネル名を含むかもしれません。 NASは、DS-Liteのトンネルオプションを含むDHCPv6クライアント要求を受信すると、NASは、名前を使用しなければならないRADIUS DS-Liteは、トンネル名で返されたDHCPv6応答メッセージ内のDHCPv6 OPTION_AFTR_NAMEオプションを移入する属性。
B4 NAS AAA
| | Server
| | |
|----PPP LCP Config-Request------> | |
| | |
| |----Access-Request ---->|
| | |
| |<---- Access-Accept-----|
| | (DS-Lite-Tunnel-Name) |
|<-----PPP LCP Config-ACK ------- | |
| | |
| | |
|--- PPP IPv6CP Config-Request --->| |
| | |
|<----- PPP IPv6CP Config-ACK -----| |
| | |
|------- DHCPv6 Solicit -------->| |
| | |
|<-------DHCPv6 Advertisement -----| |
| (DHCPv6 OPTION_AFTR_NAME) | |
| | |
|------- DHCPv6 Request -------->| |
| | |
|<-------- DHCPv6 Reply ---------- | |
| (DHCPv6 OPTION_AFTR_NAME) | |
DHCPv6 RADIUS
DHCPv6のRADIUS
Figure 1: RADIUS and DHCPv6 Message Flow for a PPP Session
図1：PPPセッションのためのRADIUSとDHCPv6メッセージフロー
Figure 2 illustrates how the RADIUS protocol and DHCPv6 work together to accomplish DS-Lite configuration on the B4 element when an IP session is used to provide connectivity to the user.
図2は、RADIUSプロトコルとDHCPv6は、IPセッションがユーザへの接続を提供するために使用される場合B4要素上にDS-Liteの構成を達成するために一緒に動作する方法を示す図です。
The only difference between this message flow and the previous one is that in this scenario, the interaction between the NAS and the AAA/ RADIUS server is triggered by the DHCPv6 Solicit message received by the NAS from the B4 acting as a DHCPv6 client, while in the case of a PPP session, the trigger is the PPP Link Control Protocol (LCP) Config-Request message received by the NAS.
このメッセージ・フローと以前のものとの間の唯一の違いは、内ながら、このシナリオでは、NASおよびAAA / RADIUSサーバとの間の相互作用は、DHCPv6クライアントとして動作B4からNASによって受信されたDHCPv6要請メッセージによってトリガされることですPPPセッションの場合は、トリガは、NASによって受信されたPPPリンク制御プロトコル（LCP）CONFIG-Requestメッセージです。
B4 NAS AAA
| | Server
|------ DHCPv6 Solicit ---------> | |
| | |
| |----Access-Request ---->|
| | |
| |<---Access-Accept-------|
| | (DS-Lite-Tunnel-Name) |
| | |
|<-------DHCPv6 Advertisement------| |
| (DHCPv6 OPTION_AFTR_NAME) | |
| | |
|------- DHCPv6 Request -------->| |
| | |
| | |
|<----- DHCPv6 Reply ------------- | |
| (DHCPv6 OPTION_AFTR_NAME) | |
DHCPv6 RADIUS
DHCPv6のRADIUS
Figure 2: RADIUS and DHCPv6 Message Flow for an IP Session
図2：IPセッションのためのRADIUSとDHCPv6メッセージフロー
In the scenario depicted in Figure 2, the Access-Request packet contains a Service-Type attribute with the value Authorize Only (17); thus, according to [RFC5080], the Access-Request packet MUST contain a State attribute.
図2に示すシナリオでは、アクセス要求パケットは、値を有するサービスタイプ属性は、承認のみを含む（17）。したがって、[RFC5080]によると、アクセス要求パケットは州属性を含まなければなりません。
After receiving the DS-Lite-Tunnel-Name attribute in the initial Access-Accept packet, the NAS MUST store the received AFTR tunnel name locally. When the B4 sends a DHCPv6 Renew message to request an extension of the lifetimes for the assigned address or prefix, the NAS does not have to initiate a new Access-Request packet towards the AAA server to request the AFTR tunnel name. The NAS retrieves the previously stored AFTR tunnel name and uses it in its reply.
初期のAccess-受け入れパケット内のDS-LITE-トンネル-Name属性を受け取った後、NASは、ローカルに受信AFTRトンネル名を保存しなければなりません。 B4は、DHCPv6のは、割り当てられたアドレスやプレフィックスの寿命の延長を要求するメッセージを送信すると更新、NASはAFTRトンネル名を要求するために、AAAサーバに向けて、新たなアクセス要求パケットを開始する必要はありません。 NASは、予め記憶されAFTRトンネル名を取得し、その応答でそれを使用します。
According to [RFC3315], if the DHCPv6 server to which the DHCPv6 Renew message was sent at time T1 has not responded, the DHCPv6 client initiates a Rebind/Reply message exchange with any available server. In this scenario, the NAS receiving the DHCPv6 Rebind message MUST initiate a new Access-Request message towards the AAA server. The NAS MAY include the DS-Lite-Tunnel-Name attribute in its Access-Request message.
DHCPv6のメッセージを更新するために、DHCPv6サーバはT1が応答していない時に送信された場合による[RFC3315]は、DHCPv6クライアントは、任意の利用可能なサーバとの再結合/応答メッセージの交換を開始します。このシナリオでは、DHCPv6の再バインドメッセージを受信したNASは、AAAサーバに向けて新たなAccess-Requestメッセージを開始しなければなりません。 NASは、Access-RequestメッセージでDS-LITE-トンネル-Name属性を含むかもしれません。
If the NAS does not receive the DS-Lite-Tunnel-Name attribute in the Access-Accept message, it MAY fall back to a pre-configured default tunnel name, if any. If the NAS does not have any pre-configured default tunnel name or if the NAS receives an Access-Reject message, the IPv4-over-IPv6 tunnel cannot be established; thus, the B4 element has only IPv6 connectivity.
NASは、Access-AcceptメッセージでDS-LITE-トンネル-Name属性を受信しない場合があれば、それは、事前に構成されたデフォルトのトンネル名にフォールバックするかもしれません。 NASは、任意の事前設定されたデフォルトのトンネルの名前を持っていない場合、またはNASがAccess-Rejectメッセージを受信した場合、IPv4のオーバーIPv6トンネルを確立することができません。このように、B4要素は、IPv6のみの接続性を持っています。
This section specifies the format of the new RADIUS attribute.
このセクションでは、新しいRADIUS属性の形式を指定します。
The DS-Lite-Tunnel-Name RADIUS attribute contains an FQDN that refers to the AFTR to which the client is requested to establish a connection. The NAS SHALL use the name returned in the RADIUS DS-Lite-Tunnel-Name attribute to populate the DHCPv6 OPTION_AFTR_NAME option [RFC6334].
DS-Liteの-トンネル名RADIUS属性は、クライアントが接続を確立するように要求されているAFTRを参照するFQDNが含まれています。 NASは、DHCPv6のOPTION_AFTR_NAMEオプション[RFC6334]を移入するRADIUS DS-Liteは、トンネル名で返される属性名を使用しなければなりません。
This attribute MAY be used in Access-Request packets as a hint to the RADIUS server; for example, if the NAS is pre-configured with a default tunnel name, this name MAY be inserted in the attribute. The RADIUS server MAY ignore the hint sent by the NAS, and it MAY assign a different AFTR tunnel name.
この属性は、RADIUSサーバへのヒントとしてのAccess-Requestパケットで使用されるかもしれません。 NASデフォルトトンネル名で事前に構成されている場合、例えば、この名前は、属性に挿入することができます。 RADIUSサーバがNASによって送信されたヒントを無視してもよく、それは異なるAFTRトンネル名を割り当てることができます。
If the NAS includes the DS-Lite-Tunnel-Name attribute, but the AAA server does not recognize it, this attribute MUST be ignored by the AAA server.
NASは、DS-Liteの-トンネル-Name属性が含まれていますが、AAAサーバがそれを認識しない場合、この属性は、AAAサーバによって無視されなければなりません。
If the NAS does not receive the DS-Lite-Tunnel-Name attribute in the Access-Accept message, it MAY fall back to a pre-configured default tunnel name, if any. If the NAS does not have any pre-configured default tunnel name, the tunnel cannot be established.
NASは、Access-AcceptメッセージでDS-LITE-トンネル-Name属性を受信しない場合があれば、それは、事前に構成されたデフォルトのトンネル名にフォールバックするかもしれません。 NASは、任意の事前設定されたデフォルトのトンネル名を持っていない場合は、トンネルを確立することはできません。
If the NAS is pre-provisioned with a default AFTR tunnel name and the AFTR tunnel name received in the Access-Accept message is different from the configured default, then the AFTR tunnel name received in the Access-Accept message MUST be used for the session.
NASは、トンネル名とAFTRトンネル名AFTRデフォルトで事前にプロビジョニングされている場合Access-Acceptメッセージが設定されたデフォルトとは異なるで受信し、次いでAFTRトンネル名は、Access-Acceptメッセージがセッションのために使用しなければならないで受信。
If the NAS cannot support the received AFTR tunnel name for any reason, the tunnel SHOULD NOT be established.
NASは、何らかの理由で受信AFTRトンネル名をサポートできない場合は、トンネルが確立されるべきではありません。
When the Access-Request message is triggered by a DHCPv6 Rebind message, if the AFTR tunnel name received in the Access-Accept message is different from the currently used one for that session, the NAS MUST force the B4 to re-establish the tunnel using the new AFTR name received in the Access-Accept message.
AFTRトンネル名がAccess-Acceptメッセージがそのセッションのために現在使用されるものとは異なるでは、NASは再確立トンネル使用にB4を強制する必要があり受信したAccess-Requestメッセージは、DHCPv6の再バインドメッセージによってトリガーされたとき新しいAFTR名前は、Access-Acceptメッセージで受け取りました。
If an implementation includes Change-of-Authorization (CoA) messages [RFC5176], they could be used to modify the current established DS-Lite tunnel. When the NAS receives a CoA Request message containing the DS-Lite-Tunnel-Name attribute, the NAS MUST send a Reconfigure message to a B4 to inform the B4 that the NAS has new or updated configuration parameters and that the B4 is to initiate a Renew/Reply or Information-Request/Reply transaction with the NAS in order to receive the updated information.
実装が変更-の承認（COA）メッセージ[RFC5176]を含んでいる場合、彼らは現在の確立DS-Liteのトンネルを変更するために使用することができます。 NASは、DS-Liteの-トンネル-Name属性を含むアシルCoA要求メッセージを受信した場合、NASはNASが新規または更新された設定パラメータを持つB4を知らせるためにB4に再設定メッセージを送らなければなりませんし、B4が開始することであること更新された情報を受信するために、NASとの取引を返信/返信または情報要求/更新。
Upon receiving an AFTR tunnel name different from the currently used one, the B4 MUST terminate the current DS-Lite tunnel, and the B4 MUST establish a new DS-Lite tunnel with the specified AFTR.
現在1用いる異なるAFTRトンネル名を受信すると、B4は、現在のDS-Liteのトンネルを終端しなければならない、およびB4はAFTR指定して新しいDS-Liteのトンネルを確立しなければなりません。
The DS-Lite-Tunnel-Name RADIUS attribute MAY be present in Accounting-Request records where the Acct-Status-Type is set to Start, Stop, or Interim-Update. The DS-Lite-Tunnel-Name RADIUS attribute MUST NOT appear more than once in a message.
DS-Liteの-トンネル名RADIUS属性は、アカウンティング・ステータス・タイプは、停止、または暫定-Updateを起動するように設定されているアカウンティング要求レコードの中に存在してもよいです。 DS-Liteの-トンネル名RADIUS属性は、メッセージ内に複数回現れてはなりません。
A summary of the DS-Lite-Tunnel-Name RADIUS attribute format is shown below. The fields are transmitted from left to right.
DS-Liteの-トンネル名RADIUS属性のフォーマットの概要は以下の通りです。フィールドは左から右に送信されます。
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 | DS-Lite-Tunnel-Name (FQDN)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
タイプ：
144 for DS-Lite-Tunnel-Name.
DS-Liteの-トンネルの名前のための144。
Length:
長さ：
This field indicates the total length in octets of this
attribute including the Type and Length fields, and the length
in octets of the DS-Lite-Tunnel-Name field.
DS-Lite-Tunnel-Name:
DS-Liteの-トンネル名：
This field contains a single FQDN of the remote tunnel endpoint,
located at the DS-Lite AFTR.
As the DS-Lite-Tunnel-Name attribute is used to populate the DHCPv6 OPTION_AFTR_NAME option, the DS-Lite-Tunnel-Name field is formatted as required in DHCPv6 (Section 8 of [RFC3315] -- "Representation and Use of Domain Names"). Briefly, the format described is using a single octet noting the length of one DNS label (limited to at most 63 octets), followed by the label contents. This repeats until all labels in the FQDN are exhausted, including a terminating zero-length label. Any updates to Section 8 of [RFC3315] also apply to the encoding of this field.
ドメイン名の「表現と利用 - DS-Liteの-トンネル-Name属性は、DHCPv6のOPTION_AFTR_NAMEオプションを設定するために使用されている通りのDHCPv6（[RFC3315]のセクション8で必要に応じて、DS-Liteの-トンネル-Nameフィールドがフォーマットされ「）。簡潔には、1つのDNSラベルの長さを指摘単一のオクテットを使用して説明した形式は、ラベルの内容、続いて、（最大で63個のオクテットに限定されるもの）。 FQDNですべてのラベルが終了する長さゼロのラベルを含め、排出されるまで、これが繰り返されます。 [RFC3315]のセクション8への更新も、このフィールドの符号化に適用されます。
The data type of the DS-Lite-Tunnel-Name RADIUS attribute is a string with opaque encapsulation, according to Section 5 of [RFC2865].
DS-Liteの-トンネル名RADIUSアトリビュートのデータ型は、[RFC2865]のセクション5によると、不透明なカプセル化された文字列です。
The following tables provide a guide to which attributes may be found in which kinds of packets, and in what quantity.
以下の表は、属性パケットの種類のもので、どのような量で見出されてもよいためのガイドを提供します。
Access- Access- Access- Challenge Accounting # Attribute Request Accept Reject Request 0-1 0-1 0 0 0-1 144 DS-Lite-Tunnel-Name
Access- Access- Access-チャレンジ会計＃の属性要求は、要求を拒否し0-1 0-1 0 0 0-1 144 DS-Liteは、トンネルの名前を受け入れます
CoA-Request CoA-ACK CoA-NACK # Attribute 0-1 0 0 144 DS-Lite-Tunnel-Name
CoAのリクエストのCoA-ACKのCoA-NACKの＃属性0-1 0 0 144 DS-Liteは、トンネルの名前
The following table defines the meaning of the above table entries.
次の表は、上記テーブルエントリの意味を定義します。
0 This attribute MUST NOT be present in the packet. 0+ Zero or more instances of this attribute MAY be present in the packet. 0-1 Zero or one instance of this attribute MAY be present in the packet.
0この属性は、パケット内に存在してはなりません。 0+この属性のゼロ以上のインスタンスがパケットに存在してもよいです。この属性の0-1ゼロまたは1つのインスタンスがパケットに存在してもよいです。
This document has no additional security considerations beyond those already identified in [RFC2865] for the RADIUS protocol and in [RFC5176] for CoA messages.
この文書では、すでにRADIUSプロトコル用とCoAメッセージの[RFC5176]の[RFC2865]で同定されたものを超えて追加のセキュリティ上の考慮事項を持っていません。
[RFC6333] discusses security issues related to Dual-Stack Lite.
[RFC6333]はデュアルスタックライトに関連するセキュリティの問題について説明します。
Per this document, IANA has allocated a new RADIUS attribute type from the IANA registry "Radius Attribute Types" located at http://www.iana.org/assignments/radius-types.
このドキュメントごとに、IANAはIANAレジストリから新しいRADIUS属性タイプhttp://www.iana.org/assignments/radius-typesにある「半径は、属性の型」に割り当てられています。
DS-Lite-Tunnel-Name - 144
DS-Liteの-トンネル名 - 144
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080]ネルソン、D.とA. DeKok、RFC 5080、2007年12月 "ユーザーサービス（RADIUS）の実装の問題と推奨修正に共通のリモート認証ダイヤル"。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.
[RFC6333]デュラン、A.、Droms、R.、Woodyatt、J.、およびY.リー、 "IPv4の枯渇後デュアルスタックLiteのブロードバンドの展開"、RFC 6333、2011年8月。
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, August 2011.
[RFC6334]ハンキンズ、D.とT. Mrugalski、 "IPv6の動的ホスト構成プロトコル（DHCPv6）デュアルスタックLiteのオプション"、RFC 6334、2011年8月。
[RADIUS-IPv6] Lourdelet, B., Dec, W., Ed., Sarikaya, B., Zorn, G., and D. Miles, "RADIUS attributes for IPv6 Access Networks", Work in Progress, November 2011.
[RADIUS-のIPv6] Lourdelet、B.、12月、W.、エド。、Sarikaya、B.、ツォルン、G.、およびD.マイル、進歩、2011年11月の作業 "RADIUSは、IPv6アクセスネットワークのための属性"。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, January 2008.
、RFC 5176、2008年1月[RFC5176]千葉、M.、Dommety、G.、エクランド、M.、ミトン、D.、およびB. Aboba、 "ユーザーサービス（RADIUS）でリモート認証ダイヤルへのダイナミックな承認拡張機能"。
Authors' Addresses
著者のアドレス
Roberta Maglione Telecom Italia Via Reiss Romoli 274 Torino 10148 Italy
ロベルタセーターテレコムイタリアViaライスRomoli 274トリノ10148イタリア
EMail: roberta.maglione@telecomitalia.it
メールアドレス：roberta.maglione@telecomitalia.it
Alain Durand Juniper Networks 1194 North Mathilda Avenue Sunnyvale, CA 94089-1206 USA
アラン・デュランジュニパーネットワークスの1194北マチルダアベニューサニーベール、CA 94089から1206 USA
EMail: adurand@juniper.net
メールアドレス：adurand@juniper.net