RFC4580 日本語訳

Network Working Group                                            B. Volz
Request for Comments: 4580                           Cisco Systems, Inc.
Category: Standards Track                                      June 2006

コメントを求めるワーキンググループB.フォルツ要求をネットワークでつないでください: 4580年のシスコシステムズInc.カテゴリ: 標準化過程2006年6月

         Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
                    Relay Agent Subscriber-ID Option

IPv6(DHCPv6)中継エージェント加入者IDオプションのためのダイナミックなホスト構成プロトコル

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(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.

このメモはIPv6(DHCPv6)のためにDynamic Host Configuration Protocolのための新しいRelayエージェントSubscriber-IDオプションを定義します。 オプションで、DHCPv6中継エージェントはクライアントと基本的な物理ネットワークインフラストラクチャから独立している方法で安定した「加入者ID」を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

1. 序論…2 2. 中継エージェント加入者IDオプション…2 3. DHCPv6はエージェントの振舞いをリレーします…3 4. DHCPv6サーバの振舞い…3 5. セキュリティ問題…4 6. IANA問題…4 7. 承認…4 8. 参照…4 8.1. 標準の参照…4 8.2. 有益な参照…4

Volz                        Standards Track                     [Page 1]

RFC 4580               Relay Agent Subscriber-ID               June 2006

フォルツ標準化過程[1ページ]RFC4580は2006年6月にエージェント加入者IDをリレーします。

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]はIPアドレスと設定情報をIPv6クライアントに提供します。 それは中継エージェント能力を含んでいます。(ネットワークインフラの中のプロセスは、それでクライアントからマルチキャストメッセージを受け取って、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.

また、クライアントが受け取ることになっているアドレス、代表として派遣された接頭語[2]、および設定パラメータに関してサーバの意志決定に中継エージェントが提供する情報を使用できます。

   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. 中継エージェント加入者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エージェントSubscriber-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.

加入者イド情報で、サービスプロバイダーは、加入者特有の動作を割り当てるか、または起動します。 例えば、特定のIPアドレス、接頭語、DNS構成、引き金の会計などの課題 このオプションがアクセスネットワークの物理構造から衝撃を吸収されるので、例えば1つのアクセスポイントから別のアクセスポイントまで移行する加入者はサービスプロバイダーの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.

加入者イド情報をただ一つの管理ドメインの中の使用のために意図するだけであり、そのドメインの中の中継エージェントとDHCPv6サーバの間で交換するだけです。 したがって、オプションにおける、データの形式とコード化は標準化されません、そして、この仕様はデータに関するどんな意味要件も確立しません。 この仕様は中継エージェントからDHCPv6サーバまでこの情報を伝えるためのオプションを定義するだけです。

Volz                        Standards Track                     [Page 2]

RFC 4580               Relay Agent Subscriber-ID               June 2006

フォルツ標準化過程[2ページ]RFC4580は2006年6月にエージェント加入者IDをリレーします。

   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]がNetwork Virtual Terminal(NVT)情報交換用米国標準コード(ASCII)の[4]のコード化されたデータを指定するDHCPv4[5]とDHCPv6の両方が使用されている環境で、そのコード化を使用するのは有益であるかもしれません。

   The format of the DHCPv6 Relay Agent Subscriber-ID option is shown
   below:

DHCPv6 Relayエージェント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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | オプション_加入者_ID| オプション-len| 加入者..イド

      option-code      OPTION_SUBSCRIBER_ID (38)

オプションコードOPTION_SUBSCRIBER_ID(38)

      option-len       length, in octets, of the subscriber-id field.
                       The minimum length is 1 octet.

加入者イド分野の八重奏におけるオプション-lenの長さ。 最小の長さは1つの八重奏です。

      subscriber-id    The subscriber's identity.

加入者イド、加入者のアイデンティティ。

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オプションを含むように構成されるかもしれません。 加入者イドは割り当てられます、そして、このメモの範囲の外にそれを構成するのに使用されるメカニズムがどうあるか。

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クライアントメッセージに含まれていた他のオプション、および物理ネットワークトポロジー情報に加えて利用可能であるなら、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

フォルツ標準化過程[3ページ]RFC4580は2006年6月にエージェント加入者IDをリレーします。

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.

中継エージェントと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エージェントSubscriber-ID OptionのためにDHCPv6オプションコード(38)を割り当てました。

7.  Acknowledgements

7. 承認

   Thanks to Richard Johnson, Theyn Palaniappan, and Mark Stapp as this
   document is essentially an edited version of their memo [3].

このドキュメントが本質的にはそれらのメモ[3]の編集されたバージョンであるので、リチャード・ジョンソン、Theyn Palaniappan、およびマークStappをありがとうございます。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [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.

[1] Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。

8.2.  Informative References

8.2. 有益な参照

   [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、「Dynamic Host Configuration Protocol(DHCP)バージョン6インチIPv6 Prefix Options、RFC3633、2003年12月。」

   [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.

[3] ジョンソン、R.、Palaniappan、T.、およびM.スタップ、「Dynamic Host Configuration Protocol(DHCP)中継エージェントオプションのための加入者ID Suboption」、RFC3993(2005年3月)。

   [4]  Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD
        8, RFC 854, May 1983.

[4] ポステルとJ.とJ.レイノルズ、「telnetプロトコル仕様」、STD8、RFC854、1983年5月。

   [5]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
        March 1997.

[5]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。

Volz                        Standards Track                     [Page 4]

RFC 4580               Relay Agent Subscriber-ID               June 2006

フォルツ標準化過程[4ページ]RFC4580は2006年6月にエージェント加入者IDをリレーします。

Author's Address

作者のアドレス

   Bernard Volz
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA  01719
   USA

バーナードフォルツシスコシステムズInc.1414マサチューセッツAve。 Boxborough、MA01719米国

   Phone: +1 978 936 0382
   EMail: volz@cisco.com

以下に電話をしてください。 +1 0382年の978 936メール: volz@cisco.com

Volz                        Standards Track                     [Page 5]

RFC 4580               Relay Agent Subscriber-ID               June 2006

フォルツ標準化過程[5ページ]RFC4580は2006年6月にエージェント加入者IDをリレーします。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(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.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   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 provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Volz                        Standards Track                     [Page 6]

フォルツ標準化過程[6ページ]