Network Working Group                                         J. Salowey
Request for Comments: 4818                                      R. Droms
Category: Standards Track                            Cisco Systems, Inc.
                                                              April 2007
        
                 RADIUS Delegated-IPv6-Prefix Attribute
        

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.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。

Copyright Notice

著作権表示

Copyright (C) The IETF Trust (2007).

著作権(C)IETFトラスト(2007)。

Abstract

抽象

This document defines a RADIUS (Remote Authentication Dial In User Service) attribute that carries an IPv6 prefix that is to be delegated to the user. This attribute is usable within either RADIUS or Diameter.

このドキュメントでは、RADIUS(ユーザサービスにおけるリモート認証ダイヤル)ユーザーに委任されるIPv6プレフィックスを運ぶ属性を定義します。この属性は、RADIUSまたは直径のどちらか内で使用可能です。

1. Introduction
1. はじめに

This document defines the Delegated-IPv6-Prefix attribute as a RADIUS [1] attribute that carries an IPv6 prefix to be delegated to the user, for use in the user's network. For example, the prefix in a Delegated-IPv6-Prefix attribute can be delegated to another node through DHCP Prefix Delegation [2].

この文書は、ユーザーのネットワークで使用するために、ユーザに委任するIPv6プレフィックスを運ぶRADIUS [1]属性として委任-のIPv6プレフィックスの属性を定義します。たとえば、委任-のIPv6プレフィックスの属性にプレフィックスはDHCPプレフィックス委譲を介して他のノードに委任することができる[2]。

The Delegated-IPv6-Prefix attribute can be used in DHCP Prefix Delegation between the delegating router and a RADIUS server, as illustrated in the following message sequence.

次のメッセージ・シーケンスに示すように、委任-のIPv6-prefix属性は、委任ルータとRADIUSサーバ間でDHCPプレフィックス委任に使用す​​ることができます。

   Requesting Router   Delegating Router                   RADIUS Server
         |                     |                                 |
         |-Solicit------------>|                                 |
         |                     |-Request------------------------>|
         |                     |<--Accept(Delegated-IPv6-Prefix)-|
         |<--Advertise(Prefix)-|                                 |
         |-Request(Prefix)---->|                                 |
         |<--Reply(Prefix)-----|                                 |
         |                     |                                 |
                DHCP PD                      RADIUS
        

The Framed-IPv6-Prefix attribute [4] is not designed to support delegation of IPv6 prefixes to be used in the user's network, and therefore Framed-IPv6-Prefix and Delegated-IPv6-Prefix attributes may be included in the same RADIUS packet.

Framed-IPv6-Prefixアトリビュート[4]ユーザのネットワークで使用されるIPv6プレフィックスの委任をサポートするように設計され、したがって入れる-のIPv6プレフィックスと委任-のIPv6プレフィックスの属性されていない同一のRADIUSパケットに含まれてもよいです。

2. Terminology
2.用語

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 RFC 2119 [3].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[3]。

3. Attribute Format
3.属性のフォーマット

The format of the Delegated-IPv6-Prefix is:

委任-のIPv6プレフィックスの形式は次のとおりです。

       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

タイプ

123 for Delegated-IPv6-Prefix

委任-のIPv6プレフィックスのための123

Length

長さ

           The length of the entire attribute, in bytes.  At least 4 (to
           hold Type/Length/Reserved/Prefix-Length for a 0-bit prefix),
           and no larger than 20 (to hold Type/Length/ Reserved/Prefix-
           Length for a 128-bit prefix)
        

Reserved

予約済み

Always set to zero by sender; ignored by receiver

常に送信者によってゼロに設定します。受信機で無視

Prefix-Length

プレフィックス長

           The length of the prefix being delegated, in bits.  At least
           0 and no larger than 128 bits (identifying a single IPv6
           address)
        

Note that the prefix field is only required to be long enough to hold the prefix bits and can be shorter than 16 bytes. Any bits in the prefix field that are not part of the prefix MUST be zero.

プレフィックスフィールドのみプレフィックスビットを保持するのに十分な長であることが要求されると、16のバイトよりも短くすることができることに注意してください。接頭辞の一部ではないプレフィックスフィールド内の任意のビットはゼロでなければなりません。

The Delegated-IPv6-Prefix MAY appear in an Access-Accept packet, and can appear multiple times. It MAY appear 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.

委任-のIPv6プレフィックスは、アクセス受け入れパケットに現れるかもしれ、および複数回表示されることができます。それはこれらの接頭語(es)を好むだろうサーバへのNASによってヒントとしてのAccess-Requestパケットに現れるかもしれが、サーバーはヒントを尊重する必要はありません。

The Delegated-IPv6-Prefix attribute MAY appear in an Accounting-Request packet.

委任-のIPv6-prefix属性は、アカウンティング要求パケットに表示されることがあります。

The Delegated-IPv6-Prefix MUST NOT appear in any other RADIUS packets.

委任-のIPv6プレフィックスは、他のRADIUSパケットに現れてはいけません。

4. Table of Attributes
属性の4表

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+      0+     0      0         0+          123 Delegated-IPv6-   |
   |                                                 Prefix            |
   +-------------------------------------------------------------------+
        

The meaning of the above table entries is as follows: 0 This attribute MUST NOT be present. 0+ Zero or more instances of this attribute MAY be present. 0-1 Zero or one instance of this attribute MAY be present. 1 Exactly one instance of this attribute MUST be present. 1+ One or more of these attributes MUST be present.

次のように上記テーブルエントリの意味は次のとおりです。0この属性が存在しているはずがありません。 0+この属性のゼロ以上のインスタンスが存在してもよいです。この属性の0-1ゼロまたは1つのインスタンスが存在してもよいです。この属性の1つのちょうど1つのインスタンスが存在しなければなりません。 1+これらの属性の1つ以上が存在しなければなりません。

5. Diameter Considerations
5.直径の考慮事項

When used in Diameter, the attribute defined in this specification can be used as a Diameter AVP from the Code space 1-255, i.e., RADIUS attribute compatibility space. No additional Diameter Code values are therefore allocated. The data types of the attributes are as follows:

直径が使用される場合、本明細書で定義された属性は、コード空間1-255からのDiameter AVPとして使用することができ、即ち、RADIUSは、互換性空間属性。追加直径コード値は、したがって、割り当てられていません。次のような属性のデータ型は、次のとおりです。

Delegated-IPv6-Prefix OctetString

委任-のIPv6プレフィックスのOctetString

The attribute in this specification has no special translation requirements for Diameter to RADIUS or RADIUS to Diameter gateways, i.e., the attribute is copied as is, except for changes relating to headers, alignment, and padding. See also RFC 3588 [5], Section 4.1, and RFC 4005 [6], Section 9.

本明細書内の属性、すなわち、属性はヘッダ、位置合わせ、及びパディングに関連する変更点を除いて、そのままコピーされ、直径ゲートウェイにRADIUSまたはRADIUSの直径のための特別な翻訳要件を有していません。 RFC 3588 [5]、セクション4.1、及びRFC 4005 [6]、9章も参照。

The text in this specification describing the applicability of the Delegated-IPv6-Prefix attribute for RADIUS Access-Request applies in Diameter to AA-Request [6] or Diameter-EAP-Request [7].

RADIUSアクセス要求がAAリクエストに直径が適用されるための委任-のIPv6プレフィックスの属性の適用を説明する本明細書ではテキスト[6]又は直径-EAP-リクエスト[7]。

The text in this specification describing the applicability of the Delegated-IPv6-Prefix attribute for RADIUS Access-Accept applies in Diameter to AA-Answer or Diameter-EAP-Answer that indicates success.

RADIUSアクセス - 受け入れのための委任-のIPv6プレフィックスの属性の適用可能性を説明し、この仕様のテキストは成功を示しAA-回答または直径-EAP-回答に直径が適用されます。

The text in this specification describing the applicability of the Delegated-IPv6-Prefix attribute for RADIUS Accounting-Request applies to Diameter Accounting-Request [6] as well.

RADIUSアカウンティング - 要求に対する委任-のIPv6プレフィックスの属性の適用を説明する本明細書のテキストは、[6]同様に直径アカウンティング要求に適用されます。

The AVP flag rules [5] for the Delegated-IPv6-Prefix attribute are:

AVPフラグルール[5]委任-のIPv6プレフィックスの属性のためのものです。

                                      +---------------------+
                                      |    AVP Flag rules   |
                                      |----+-----+----+-----|----+
                     AVP              |    |     |SHLD| MUST|    |
     Attribute Name  Code  Value Type |MUST| MAY | NOT|  NOT|Encr|
     ---------------------------------|----+-----+----+-----|----|
     Delegated-IPv6- 123   OctetString| M  |  P  |    |  V  | Y  |
       Prefix                         |    |     |    |     |    |
     ---------------------------------|----+-----+----+-----|----|
        
6. IANA Considerations
6. IANAの考慮事項

IANA assigned a Type value, 123, for this attribute from the RADIUS Attribute Types registry.

IANAは、RADIUS属性タイプのレジストリからこの属性のため、Type値、123を割り当てました。

7. Security Considerations
7.セキュリティの考慮事項

Known security vulnerabilities of the RADIUS protocol are discussed in RFC 2607 [8], RFC 2865 [1], and RFC 2869 [9]. Use of IPsec [10] for providing security when RADIUS is carried in IPv6 is discussed in RFC 3162.

RADIUSプロトコルの既知のセキュリティの脆弱性は、RFC 2607に記載されている[8]、RFC 2865 [1]、及びRFC 2869 [9]。 RADIUSがIPv6で実行されるときにセキュリティを提供するためにIPsec [10]の使用は、RFC 3162に記載されています。

Security considerations for the Diameter protocol are discussed in RFC 3588 [5].

Diameterプロトコルのためのセキュリティ問題は、RFC 3588に記載されている[5]。

8. References
8.参照文献
8.1. Normative References
8.1. 引用規格

[1] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.

[1] Rigney、C.、ウィレンス、S.、ルーベン、A.、およびW.シンプソンを、 "リモート認証ダイヤルインユーザーサービス(RADIUS)で"、RFC 2865、2000年6月。

[2] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.

[2] Troan、O.とR. Droms、RFC 3633 "動的ホスト構成プロトコル(DHCP)バージョン6のIPv6プレフィックスオプション"、2003年12月。

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

[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

9.2. Informative References
9.2. 参考文献

[4] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.

[4] Aboba、B.、ゾルン、G.、およびD.ミットン、 "RADIUSとIPv6"、RFC 3162、2001年8月。

[5] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

[5]カルフーン、P.、Loughney、J.、ガットマン、E.、ゾルン、G.、およびJ. Arkko、 "直径ベースプロトコル"、RFC 3588、2003年9月。

[6] Calhoun, P., Zorn, G., Spence, D., and D. Mitton, "Diameter Network Access Server Application", RFC 4005, August 2005.

[6]カルフーン、P.、ツォルン、G.、スペンス、D.、およびD.ミトン、 "直径ネットワークアクセスサーバーアプリケーション"、RFC 4005、2005年8月。

[7] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, August 2005.

[7] Eronen、P.、ヒラー、T.、およびG.ゾルン、 "直径拡張認証プロトコル(EAP)アプリケーション"、RFC 4072、2005年8月。

[8] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.

[8] Aboba、B.、およびJ. Vollbrecht、 "ローミング中のプロキシ連鎖とポリシー実装"、RFC 2607、1999年6月。

[9] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.

[9] Rigney、C.、Willats、W.、およびP.カルフーン、 "RADIUS拡張機能"、RFC 2869、2000年6月。

[10] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.

[10]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。

Authors' Addresses

著者のアドレス

Joe Salowey Cisco Systems, Inc. 2901 Third Avenue Seattle, WA 98121 USA

ジョーSaloweyシスコシステムズ株式会社2901 Third Avenueのシアトル、WA 98121 USA

Phone: +1 206.310.0596 EMail: jsalowey@cisco.com

電話:+1 206.310.0596 Eメール:jsalowey@cisco.com

Ralph Droms Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA

ラルフDromsシスコシステムズ株式会社1414年マサチューセッツアベニューボックスボロー、MA 01719 USA

Phone: +1 978.936.1674 EMail: rdroms@cisco.com

電話:+1 978.936.1674 Eメール:rdroms@cisco.com

Full Copyright Statement

完全な著作権声明

Copyright (C) The IETF Trust (2007).

著作権(C)IETFトラスト(2007)。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、(もしあれば)を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。