RFC4580 DHCPv6 Relay Agent Subscriber-IDオプション 翻訳: 日本シー・エー・ディー株式会社 (Shibuya K. - Microbrains Inc.) -------------------------------------------------------------------- Network Working Group B. Volz Request for Comments: 4580 Cisco Systems, Inc. Category: Standards Track June 2006 Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Relay Agent Subscriber-ID Option 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 (2006). Abstract 要約 This memo defines a new Relay Agent Subscriber-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). The option allows a DHCPv6 relay agent to associate a stable "Subscriber-ID" with DHCPv6 client messages in a way that is independent of the client and of the underlying physical network infrastructure. このメモは、DHCPv6で使われる、新しい Relay Agent Subscriber-IDオプションを定義するものである。 このオプションは、安定した「加入者ID」をDHCPv6リレーエージェントがDHCPv6クライアントメッセージに付加するのに使われる。これは、クライアントと物理的なネットワークインフラから独立している。 Table of Contents 1. Introduction ....................................................2 2. The Relay Agent Subscriber-ID Option ............................2 3. DHCPv6 Relay Agent Behavior .....................................3 4. DHCPv6 Server Behavior ..........................................3 5. Security Considerations .........................................4 6. IANA Considerations .............................................4 7. Acknowledgements ................................................4 8. References ......................................................4 8.1. Normative References .......................................4 8.2. Informative References .....................................4 Volz Standards Track [Page 1] RFC 4580 Relay Agent Subscriber-ID June 2006 1. Introduction 1. はじめに DHCPv6 [1] provides IP addresses and configuration information for IPv6 clients. It includes a relay agent capability, in which processes within the network infrastructure receive multicast messages from clients and relay them to DHCPv6 servers. In some network environments, it will be useful for the relay agent to add information to the DHCPv6 message before relaying it. DHCPv6 [1] はIPv6クライアントのIPアドレスと設定情報を提供する仕組みである。 これは、リレーエージェントの仕組みを含んでおり、ネットワーク内でマルチキャストメッセージをクライアントから受信し、DHCPv6サーバに転送する仕組みを持つ。 いくつかのネットワーク環境においては、転送を行なう前にDHCPv6メッセージに情報を追加したほうがリレーエージェントにとって都合が良いことがある。 The information that relay agents supply can also be used in the server's decision-making about the addresses, delegated prefixes [2], and configuration parameters that the client is to receive. リレーエージェントが提供する情報はまた、クライアントに送るアドレスや代理プレフィックス [4]、設定情報をサーバが決める際にも有用である。 In many service-provider environments, it is believed to be desirable to associate some provider-specific information with clients' DHCPv6 messages that is independent of the physical network configuration and that the relay agent has learned through some means that is outside the scope of this memo. 多くのサービスプロバイダの環境においては、クライアントのDHCPv6メッセージに、物理的なネットワーク構成に関係のないプロバイダ固有の情報をつける事が望まれている。この情報は本メモで取り扱う範囲の外側にある何らかの方法で、リレーエージェントが獲得するものである。 2. The Relay Agent Subscriber-ID Option 2. Relay Agent Subscriber-IDオプション In complex service provider environments, there is a need to connect a customer's DHCPv6 configuration with the customer's administrative information. The Relay Agent Subscriber-ID option carries a value that can be independent of the physical network configuration through which the subscriber is connected. This value complements, and might well be used in addition to, the network-based information. The "subscriber-id" assigned by the provider is intended to be stable as customers connect through different paths, and as network changes occur. 複雑なサービスプロバイダ環境においては、顧客のDHCPv6設定と顧客の管理情報を結びつけておかなければいけないことがある。 Relay Agent Subscriber-IDオプションによって、顧客が接続している物理的なネットワーク構成とは直接関係ない値を送信することができる。 この値はネットワーク構成に基づく情報を補完し、合わせて用いられる。 プロバイダによって付けられた「加入者ID」は、顧客の接続経路が変わったり、ネットワーク構成が変化した時でも安定して使えるようになっている。 The subscriber-id information allows the service provider to assign/ activate subscriber-specific actions; e.g., assignment of specific IP addresses, prefixes, DNS configuration, trigger accounting, etc. This option is de-coupled from the access network's physical structure, so a subscriber that moves from one access-point to another, for example, would not require reconfiguration at the service provider's DHCPv6 servers. 加入者ID情報を使って、サービスプロバイダは加入者毎の処理を実施することができる。例えば、固定のIPアドレスやプレフィックス、DNS設定を割り当てたり、課金を開始したり、等である。 このオプションは、ネットワークの物理的な状態とは切り離されているので、例えば加入者がアクセスポイントを渡り歩いたりしても、サービスプロバイダのDHCPv6サーバの設定を変更する必要が無い。 The subscriber-id information is only intended for use within a single administrative domain and is only exchanged between the relay agents and DHCPv6 servers within that domain. Therefore, the format and encoding of the data in the option is not standardized, and this specification does not establish any semantic requirements on the data. This specification only defines the option for conveying this information from relay agents to DHCPv6 servers. 加入者ID情報は、一つの管理ドメイン内だけで取り扱われる事を前提としており、ドメイン内のリレーエージェントとDHCPv6サーバ間でやりとりされることを想定している。 このため、このオプション内のデータのフォーマットとエンコードは標準化されていない。 また、本規定ではデータの意味については何も決めていない。 本規定は、この情報をリレーエージェントからDHCPv6サーバに伝えるオプションを定義しているだけである。 Volz Standards Track [Page 2] RFC 4580 Relay Agent Subscriber-ID June 2006 However, as the DHCPv4 Subscriber-ID suboption [3] specifies Network Virtual Terminal (NVT) American Standard Code for Information Interchange (ASCII) [4] encoded data, in environments where both DHCPv4 [5] and DHCPv6 are being used, it may be beneficial to use that encoding. ただし、DHCPv4 Subscriber-IDサブオプション [3] は、仮想ネットワーク端末 (NVT) ASCII [4] エンコードデータ形式を定めており、これは DHCPv4 [5]でもDHCPv6でも使うとしている。 このエンコーディングを用いるのがよいであろう。 The format of the DHCPv6 Relay Agent Subscriber-ID option is shown below: DHCPv6 Relay Agent Subscriber-IDオプションのフォーマットは以下の通り: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_SUBSCRIBER_ID | option-len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . subscriber-id . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPTION_SUBSCRIBER_ID | オプション長 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . 加入者ID . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ option-code OPTION_SUBSCRIBER_ID (38) option-len length, in octets, of the subscriber-id field. The minimum length is 1 octet. subscriber-id The subscriber's identity. オプションコード OPTION_SUBSCRIBER_ID (38) オプション長 加入者IDフィールドの長さをオクテット単位にしたもの。最小のオプション長は1である。 加入者ID 加入者の識別子 3. DHCPv6 Relay Agent Behavior 3. DHCPv6リレーエージェントの挙動 DHCPv6 relay agents may be configured to include a Subscriber-ID option in relayed (RELAY-FORW) DHCPv6 messages. How the subscriber- id is assigned and the mechanisms used to configure it are outside the scope of this memo. DHCPv6リレーエージェントは、転送する（RELAY-FORW) DHCPv6メッセージにSubscriber-IDオプションを付けるように設定されていてもよい。 加入者IDの割り当て方法や設定の機構は、本メモの取り扱う範疇ではない。 4. DHCPv6 Server Behavior 4. DHCPv6サーバの挙動 This option provides additional information to the DHCPv6 server. The DHCPv6 server may use this information, if available, in addition to other relay agent option data, other options included in the DHCPv6 client messages, and physical network topology information in order to assign IP addresses, delegate prefixes, and/or other configuration parameters to the client. There is no special additional processing for this option. このオプションはDHCPv6サーバに付加情報を提供する。 可能ならば、DHCPv6サーバは、この情報を他のリレーエージェントのオプションデータやクライアントメッセージに含まれる情報、ネットワーク構成情報と合わせて用い、IPアドレスや代理プレフィックス、その他の設定パラメータをクライアントに送る際に利用してもよい。 それ以外にこのオプションに対して行なう事は無い。 There is no requirement that a server return this option and its data in a RELAY-REPLY message. サーバはこのオプションとそのデータをRELAY-REPLYメッセージに付ける必要は無い。 Volz Standards Track [Page 3] RFC 4580 Relay Agent Subscriber-ID June 2006 5. Security Considerations 5. セキュリティの考察 As the subscriber-id option is only exchanged between relay agents and DHCPv6 servers, [1], Section 21.1, provides details on securing DHCPv6 messages sent between servers and relay agents. [1], Section 23, provides general DHCPv6 security considerations. Subscriber-IDオプションはリレーエージェントとDHCPv6サーバ間だけで送受信されるものであるので、このセキュリティに関しては、[1]の21.1章に記述されている、サーバとリレーエージェント間のDHCPv6メッセージのセキュリティ事項に沿う。 [1]の23章では、DHCPv6のセキュリティ全般について考察されている。 6. IANA Considerations 6. IANAの対応 IANA has assigned a DHCPv6 option code (38) for the Relay Agent Subscriber-ID Option. IANAは Relay Agent Subscriber-IDオプションにDHCPv6オプションコード 38 を割り当てた。 7. Acknowledgements Thanks to Richard Johnson, Theyn Palaniappan, and Mark Stapp as this document is essentially an edited version of their memo [3]. 8. References 8.1. Normative References [1] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. 8.2. Informative References [2] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003. [3] Johnson, R., Palaniappan, T., and M. Stapp, "Subscriber-ID Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 3993, March 2005. [4] Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, May 1983. [5] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. Volz Standards Track [Page 4] RFC 4580 Relay Agent Subscriber-ID June 2006 Author's Address Bernard Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA Phone: +1 978 936 0382 EMail: volz@cisco.com Volz Standards Track [Page 5] RFC 4580 Relay Agent Subscriber-ID June 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). 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. 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 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. 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. 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. 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. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Volz Standards Track [Page 6]