Network Working Group T. Chown
Request for Comments: 4076 University of Southampton
Category: Informational S. Venaas
UNINETT
A. Vijayabhaskar
Cisco Systems (India) Private Limited
May 2005
Renumbering Requirements for Stateless
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
Abstract
抽象
IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document.
ステートレスアドレス自動設定を使用してIPv6ホストは、自動的にIPv6アドレスとデフォルトルータの設定を構成することができます。しかし、更なる設定は使用できません。これらのホストは、自動的にDNS、NTP、または他の特定の設定を構成したい場合は、IPv6の動的ホスト構成プロトコル（DHCPv6）のステートレスバリアントを使用することができます。ステートレスアドレス自動設定とステートレスのDHCPv6のこの組み合わせは、IPv6ネットワークでは非常に一般的に使用することができます。しかし、この組み合わせを使用しているホストは、現在、ステートレスDHCPv6のオプション設定の変更の通知をすべきで手段がありません。例えば、新しいNTPサーバアドレス、DNS検索パスの変更、またはフルサイトリナンバリングの追加。この文書は、溶液は、その後の文書で提案されるべきで、そこから問題文として提示されます。
Table of Contents
目次
1. Introduction ...................................................2
2. Problem Statement ..............................................3
3. Renumbering Scenarios ..........................................3
3.1. Site Renumbering .........................................4
3.2. Changes to a DHCPv6-assigned Setting .....................4
4. Renumbering Requirements .......................................4
5. Considerations in Choosing a Solution ..........................4
6. Solution Space .................................................5
7. Summary ........................................................5
8. Security Considerations ........................................6
9. Acknowledgements ...............................................6
10. References .....................................................6
10.1. Normative References .....................................6
10.2. Informative References ...................................6
IPv6 hosts using Stateless Address Autoconfiguration [2] are able to configure their IPv6 address and default router settings automatically. Although Stateless Address Autoconfiguration for IPv6 allows automatic configuration of these settings, it does not provide a mechanism for additional non IP-address settings to be configured automatically.
IPv6のステートレスアドレス自動設定を使用してホストする[2]自動的にIPv6アドレスとデフォルトルータの設定を構成することができます。 IPv6のステートレスアドレス自動設定は、これらの設定を自動的に設定できますが、それが自動的に設定される追加の非IPアドレスの設定のためのメカニズムを提供していません。
The full version of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [3] is designed to provide both stateful address assignment to IPv6 hosts, as well as additional (non IP-address) configuration including DNS, NTP, and other specific settings. A full stateful DHCPv6 server allocates the addresses and maintains the clients' bindings to keep track of client leases.
IPv6用動的ホスト構成プロトコル（DHCPv6）のフルバージョンは、[3]は、IPv6ホストにステートフルアドレス割り当て、ならびにDNS、NTP、および他の特定の設定を含む追加の（非IPアドレス）構成の両方を提供するように設計されています。フルステートフルDHCPv6サーバはアドレスを割り当て、クライアントのリースを追跡するために、クライアントのバインディングを維持します。
If hosts using Stateless Address Autoconfiguration for IPv6 wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant [4] of DHCPv6 could be used. This variant is more lightweight. It does not do address assignment; instead, it only provides additional configuration parameters, such as DNS resolver addresses. It does not maintain dynamic state about the information assigned to clients, and therefore there is no need to maintain dynamic per-client state on the server.
IPv6のステートレスアドレス自動設定を使用しているホストが自動的にDNS、NTP、または他の特定の設定を構成したい場合は、[4]のDHCPv6のステートレスバリアントを使用することができます。この変形は、より軽量です。これは、アドレスの割り当てを行いません。代わりに、それだけで、このようなDNSリゾルバアドレスなどの追加設定パラメータを提供します。これは、クライアントに割り当てられた情報についての動的な状態を維持しないので、サーバ上で動的なクライアントごとの状態を維持する必要はありません。
This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks.
ステートレスアドレス自動設定とステートレスのDHCPv6のこの組み合わせは、IPv6ネットワークでは非常に一般的に使用することができます。
A problem, however, lies in the ability, or lack of ability, of clients using this combination to be informed of (or to deduce) changes in DHCPv6-assigned settings.
問題は、しかし、DHCPv6の割り当ての設定の変更が通知される（または推測する）この組み合わせを使用しているクライアントの、能力、または能力の欠如にあります。
While a DHCPv6 server unicasts Reconfigure messages to individual clients to trigger them to initiate Information-request/reply configuration exchanges to update their configuration settings, the stateless variant of DHCPv6 cannot use the Reconfigure mechanism because it does not maintain a list of IP addresses (leases) to send the unicast messages to. Note that in DHCPv6, Reconfigure messages must be unicast; multicast is not allowed.
DHCPv6サーバのユニキャストは、情報要求/その構成設定を更新するために、コンフィギュレーション交換を返信開始するためにそれらを起動するために、個々のクライアントにメッセージを再設定している間、それはIPアドレス（リースのリストを保持していないために、DHCPv6ののステートレスバリアントは、再設定メカニズムを使用することはできません）にユニキャストメッセージを送信します。 DHCPv6の中で、再設定メッセージは、ユニキャストでなければならないことに注意してください。マルチキャストが許可されていません。
Thus, events including the following cannot be handled:
したがって、次のようなイベントを処理することができません。
o Full site renumbering
Oのフルサイトリナンバリング
o DNS server change of address
アドレスのO DNSサーバの変更
o NTP server change of address
アドレスのO NTPサーバの変更
o A change in DNS search paths
DNS検索パスの変更O
It would be highly desirable that a host using the combination of Stateless Address Autoconfiguration and stateless DHCPv6 could handle a renumbering or reconfiguration event, whether planned or unplanned by the network administrator.
ステートレスアドレス自動設定とステートレスDHCPv6の組み合わせを使用して、ホストが計画またはネットワーク管理者によって計画されていないかどうか、リナンバリングまたは再構成イベントを処理できることが非常に望ましいです。
Note that the scope of the problem could extend beyond Stateless DHCPv6, since only IP address options have a lifetime; i.e., there is no mechanism even in the full DHCPv6 that "expires" old information or otherwise forces a client to recheck that new/updated information is available. However, with full DHCPv6, a node may learn of updates to non-address options when renewing its address lease.
IPアドレスのみのオプションが寿命を持っているので、問題の範囲は、ステートレスDHCPv6のを超えて拡張できることに注意してください。つまり、古い情報を「期限が切れる」あるいは新しい/更新された情報が利用可能であることを再確認するために、クライアントを強制していることも、完全なDHCPv6の内メカニズムはありません。そのアドレスのリースを更新するときしかし、フルのDHCPv6で、ノードは非アドレスオプションの最新情報を知ることができます。
There are two main scenarios for changes to DHCPv6-assigned settings that would require the client to initiate an Information-request/ reply exchange to update the configuration.
設定を更新するための情報要求/応答交換を開始するためにクライアントが必要となるのDHCPv6-割り当てた設定に変更するための2つの主要なシナリオがあります。
One of the fundamental principles of IPv6 is that sites receive their IPv6 address allocations from an ISP using provider-assigned (PA) address space. There is currently no provider-independent (PI) address space in IPv6. Therefore, a site changing its ISP must renumber its network. Any such site renumbering will require hosts to reconfigure both their own address and default router settings and their stateless DHCPv6-assigned settings.
IPv6のの基本原則の1つは、サイトは、プロバイダに割り当てられた（PA）のアドレス空間を使用してISPから自分のIPv6アドレスの割り当てを受けるということです。 IPv6のにはプロバイダに依存しない（PI）のアドレス空間は現在ありません。したがって、そのISPを変更するサイトでは、そのネットワーク番号を付け直す必要があります。そのような任意のサイトのリナンバリングは、ホストが自分のアドレスとデフォルトルータ設定とそのステートレスDHCPv6の割り当ての設定の両方を再設定する必要があります。
An administrator may need to change one or more stateless DHCPv6-assigned settings; e.g., an NTP server, DNS server, or the DNS search path. This may be required if a new, additional DNS server is brought online and is moved to a new network (prefix), or if an existing server is decommissioned or known to be unavailable.
管理者は、一つ以上のステートレスDHCPv6の割り当ての設定を変更する必要があります。例えば、NTPサーバ、DNSサーバ、またはDNS検索パス。既存のサーバーを撤去または使用不能であることが知られている場合は、新しい、追加のDNSサーバーがオンラインになると、新たなネットワーク（プレフィックス）に移動した場合、またはこれが必要になることがあります。
Ideally, any of the above scenarios should be handled automatically by the hosts on the network. For this to be realised, a method is required whereby the hosts are informed that they should request new stateless DHCPv6-assigned setting information.
理想的には、上記のシナリオのいずれかがネットワーク上のホストによって自動的に処理されなければなりません。これを実現するためには、この方法は、ホストは、彼らが新しいステートレスDHCPv6の割り当ての設定情報を要求すべきであることが通知されていることにより、必要とされます。
The solution to the problem may depend on whether the renumbering or configuration change is planned or unplanned, from the perspective of the network administrator. There is already work underway toward understanding the planned renumbering [5] scenario for IPv6 networks. However, there is currently no mechanism in stateless DHCPv6 for handling planned renumbering events.
問題を解決するには、ネットワーク管理者の観点から、リナンバリングまたは構成の変更が計画または計画外されているかどうかに依存してもよいです。 IPv6ネットワークの計画リナンバリング[5]シナリオを理解することに向かって進んで働くすでにあります。しかし、計画されたリナンバリングイベントを処理するためのステートレスのDHCPv6でのメカニズムは現在ありません。
A number of considerations could be listed for a desirable solution:
検討事項の数は、望ましい解決のために記載されていることができます：
o The solution should support planned renumbering; it is desirable that it also supports unplanned renumbering.
Oソリューションは、計画されたリナンバリングをサポートする必要があります。また、予定外の再番号付けをサポートしていることが望ましいです。
o Security is important. No new security concerns should be introduced to Stateless DHCPv6 by the solution.
Oセキュリティが重要です。新たな安全保障上の懸念は、ソリューションによってステートレスDHCPv6のに導入すべきではありません。
o It must be possible to update options, even if the network is not renumbered.
Oネットワークを再番号付けされていない場合でも、オプションを更新することが可能でなければなりません。
o It is desirable to maintain the "stateless" property; i.e., no per-client state should need to be kept in the server.
O「ステートレス」性質を維持することが望ましいです。つまり、何もクライアントごとの状態は、サーバーに保管する必要はないはずです。
Solutions should be designed and presented in a separate document. An initial brief set of candidate solutions might include the following:
ソリューションを設計し、別の文書で提示されなければなりません。解候補の初期の簡単なセットは、次のようなものがあります
o Add a Reconfigure message mechanism that would work in the stateless DHCPv6 environment. This could enable planned or unplanned events, but may require a multicast mechanism in order to be realised.
OステートレスDHCPv6の環境で動作します再設定メッセージのメカニズムを追加します。これは、計画的または計画外のイベントを有効にすることができますが、実現するために、マルチキャストメカニズムが必要な場合があります。
o Convey a valid lifetime timer to clients for stateless DHCPv6- assigned settings. This could primarily enable planned events, but with a small time-out it could handle unplanned events to some extent at the expense of the additional request traffic. The selection of recommended lifetime values/ranges would be the subject of future work.
OステートレスDHCPv6-割り当てられた設定のために、クライアントに有効な存続期間タイマを伝えます。これは主に、計画的なイベントを可能にすることができるが、小さなタイムアウトでは、追加の要求トラフィックを犠牲にしてある程度の計画外のイベントを処理することができます。推奨ライフタイム値/範囲の選択は、今後の作業の対象となります。
o Use some form of Router Advertisement (RA) [1] as a hint to request new stateless DHCPv6-assigned settings. Using only an observed new RA prefix as a hint to re-request settings would not handle changes that are purely to NTP, DNS, or other options. Other possible means of detection of network (re)attachment could also be used as cues (e.g., see Goals of Detecting Network Attachment (DNA) in IPv6 [6]).
Oルータ広告（RA）のいくつかのフォームを使用し、[1]新しいステートレスDHCPv6の割り当てられた設定を要求するためのヒントとして。ヒントとしてのみ認められ、新たなRAのプレフィックスを使用するために再要求の設定は、NTP、DNS、または他のオプションに純粋にされている変更を処理しません。ネットワークの他の検出可能な手段（再）アタッチメントも手がかりとして使用することができる（例えば、IPv6における検出ネットワークアタッチメント（DNA）の目標[6]を参照）。
o Change the semantics of the 'O' flag in RAs [2] so that toggling its value may trigger an Information-request message.
O [2]の値をトグルする情報要求メッセージをトリガすることができるようにのRAの「O」フラグの意味を変更します。
There will also be conditions under which a client should send an Information-request, such as reconnection to a link. Recommendations for these cases are outside the scope of this document, but we expect ongoing work in the DNA WG (as scoped in Goals of Detecting Network Attachment (DNA) in IPv6 [6]) to yield recommendations.
また、クライアントがそのようなリンクへの再接続として、情報要求を送信する条件があります。これらのケースのための推奨事項は、この文書の範囲外であるが、（IPv6における検出ネットワークアタッチメント（DNA）のゴールにスコープとして[6]）我々が推奨を生成するDNA WGにおける進行中の作業を期待します。
This document presents a problem statement for how IPv6 hosts that use the combination of Stateless Address Autoconfiguration and stateless DHCPv6 may be informed of renumbering events or other changes to the settings that they originally learned through stateless DHCPv6. A short list of candidate solutions is presented, which the authors hope will be expanded upon in subsequent documents.
この文書では、彼らはもともとステートレスDHCPv6のを介して学習設定にイベントや他の変更をリナンバリングの通知をすることができるステートレスアドレス自動設定とステートレスDHCPv6の組み合わせを使用する方法のIPv6ホストのための問題文を提示します。解候補の短いリストは、著者が、後続の文書に上に展開されることを願っている、提示されています。
There are no security considerations in this problem statement per se. However, whatever mechanism is designed or chosen to address this problem should avoid introducing new security concerns for (stateless) DHCPv6.
この問題声明自体にはセキュリティ上の考慮事項はありません。しかし、どのようなメカニズムこの問題に対処するために設計または選択されている（ステートレス）DHCPv6のための新たな安全保障上の懸念を導入することは避けてください。
The issues of maintaining appropriate security through a renumbering event are outside the scope of this document (if specific servers within the network are being added or removed, firewall configurations and ACLs, for example, will need to reflect this). However, this is an important area for further work.
リナンバリングイベントを介して適切なセキュリティを維持することの問題は、（ネットワーク内の特定のサーバが追加または削除される場合、ファイアウォール設定およびACLは、例えば、これを反映する必要があります）、この文書の範囲外です。しかし、これはさらなる作業のための重要な領域です。
The authors would like to thank Ralph Droms, Bernie Volz, and other individuals on the DHC mail list for their comments on this document, as well as colleagues on the 6NET project. We also thank the review comments, particularly those from Thomas Narten.
著者は6NETプロジェクトに関する彼らのこのドキュメントに関するコメントだけでなく、同僚のためのDHCメールリストにラルフDroms、バーニーフォルツ、および他の個人に感謝したいと思います。我々はまた、特にトーマスNarten氏から、レビューコメントに感謝します。
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[1] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 2461、1998年12月。
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[2]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[3] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニーを、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[4] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[4] Droms、R.、 "IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス"、RFC 3736、2004年4月。
[5] Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", Work in Progress, July 2004.
[5]ベイカー、F.、リア、E.およびR. Droms、「国旗の日なしでIPv6ネットワークを再番号付けのための手順」、進歩、2004年7月の作業。
[6] Choi, J., "Goals of Detecting Network Attachment (DNA) in IPv6", Work in Progress, October 2004.
進歩、2004年10月[6]チェ、J.、 "IPv6における検出ネットワークアタッチメント（DNA）の目標"、ワーク。
Authors' Addresses
著者のアドレス
Tim Chown University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom
電子のサウサンプトン学校とコンピュータサイエンスサウサンプトン、ハンプシャーSO17 1BJイギリスのティムのchown大学
EMail: tjc@ecs.soton.ac.uk
メールアドレス：tjc@ecs.soton.ac.uk
Stig Venaas UNINETT Trondheim NO 7465 Norway
NO 7465ノルウェースティグVenaas UNINETTハイム
EMail: venaas@uninett.no
メールアドレス：venaas@uninett.no
Vijayabhaskar A Kalusivalingam Cisco Systems (India) Private Limited 9, Brunton Road Bangalore 560025 India
シスコシステムズヴィジャヤBhaskaraのkalusivalingam（インド）プライベートリミテッド9、brntomロード、バンガロール560025、インド
EMail: vibhaska@cisco.com
メールアドレス：vibhaska@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（C）インターネット協会（2005）。
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 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が表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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機能のための基金は現在、インターネット協会によって提供されます。