Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 5887 Univ. of Auckland
Category: Informational R. Atkinson
ISSN: 2070-1721 Extreme Networks
H. Flinck
Nokia Siemens Networks
May 2010
Renumbering Still Needs Work
Abstract
抽象
This document reviews the existing mechanisms for site renumbering for both IPv4 and IPv6, and it identifies operational issues with those mechanisms. It also summarises current technical proposals for additional mechanisms. Finally, there is a gap analysis identifying possible areas for future work.
この文書では、IPv4とIPv6の両方のためのリナンバリングサイトの既存のメカニズムを検討し、それはそれらのメカニズムと運用上の問題を識別します。また、追加のメカニズムのための現在の技術提案をまとめました。最後に、将来の作業のための可能な領域を特定するギャップ分析があります。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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/rfc5887.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5887で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 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ライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
2. Existing Host-Related Mechanisms ................................5
2.1. DHCP .......................................................5
2.2. IPv6 Stateless Address Autoconfiguration ...................6
2.3. IPv6 ND Router/Prefix Advertisements .......................7
2.4. PPP ........................................................7
2.5. DNS Configuration ..........................................8
2.6. Dynamic Service Discovery ..................................9
3. Existing Router-Related Mechanisms ..............................9
3.1. Router Renumbering .........................................9
4. Existing Multi-Addressing Mechanism for IPv6 ...................10
5. Operational Issues with Renumbering Today ......................11
5.1. Host-Related Issues .......................................11
5.1.1. Network-Layer Issues ...............................11
5.1.2. Transport-Layer Issues .............................13
5.1.3. DNS Issues .........................................14
5.1.4. Application-Layer Issues ...........................14
5.2. Router-Related Issues .....................................16
5.3. Other Issues ..............................................17
5.3.1. NAT State Issues ...................................17
5.3.2. Mobility Issues ....................................18
5.3.3. Multicast Issues ...................................18
5.3.4. Management Issues ..................................19
5.3.5. Security Issues ....................................21
6. Proposed Mechanisms ............................................22
6.1. SHIM6 .....................................................22
6.2. MANET Proposals ...........................................22
6.3. Other IETF Work ...........................................23
6.4. Other Proposals ...........................................23
7. Gaps ...........................................................24
7.1. Host-Related Gaps .........................................24
7.2. Router-Related Gaps .......................................25
7.3. Operational Gaps ..........................................25
7.4. Other Gaps ................................................26
8. Security Considerations ........................................26
9. Acknowledgements ...............................................27
10. Informative References ........................................27
Appendix A. Embedded IP Addresses ................................34
In early 1996, the IAB published a short RFC entitled "Renumbering Needs Work" [RFC1900], which the reader is urged to review before continuing. Almost ten years later, the IETF published "Procedures for Renumbering an IPv6 Network without a Flag Day" [RFC4192]. A few other RFCs have touched on router or host renumbering: [RFC1916], [RFC2071], [RFC2072], [RFC2874], [RFC2894], and [RFC4076].
初期の1996年に、IABは、読者が続行する前に確認するように付勢されている[RFC1900]、「リナンバリングは作業が必要」と題した短いRFCを発表しました。ほぼ10年後、IETFは、[RFC4192]「国旗の日なしでIPv6ネットワークを再番号付けのための手順」を発表しました。 [RFC1916]、[RFC2071]、[RFC2072]、[RFC2874]、[RFC2894]、および[RFC4076]：他のいくつかのRFCは、ルータやホストの再番号付けに触れてきました。
In fact, since 1996, a number of individual mechanisms have become available to simplify some aspects of renumbering. The Dynamic Host Configuration Protocol (DHCP) is available for IPv4 [RFC2131] and IPv6 [RFC3315]. IPv6 includes Stateless Address Autoconfiguration (SLAAC) [RFC4862], and this includes Router Advertisements (RAs) that include options listing the set of active prefixes on a link. The Point-to-Point Protocol (PPP) [RFC1661] also allows for automated address assignment for both versions of IP.
実際には、1996年以来、個々のメカニズムの数は、リナンバリングのいくつかの側面を簡素化するために利用できるようになってきました。 DHCP（Dynamic Host Configuration Protocol）はIPv4の[RFC2131]とIPv6 [RFC3315]のために利用可能です。 IPv6はステートレスアドレス自動設定（SLAAC）[RFC4862]を含み、これは、リンク上のアクティブプレフィックスの集合をリストのオプションを含むルータ広告（RAS）を含みます。ポイントツーポイントプロトコル（PPP）[RFC1661]もIPの両方のバージョンの自動アドレス割り当てを可能にします。
Despite these efforts, renumbering, especially for medium to large sites and networks, is widely viewed as an expensive, painful, and error-prone process, and is therefore avoided by network managers as much as possible. Some would argue that the very design of IP addressing and routing makes automatic renumbering intrinsically impossible. In fact, managers have an economic incentive to avoid having to renumber, and many have resorted to private addressing and Network Address Translation (NAT) as a result. This has the highly unfortunate consequence that any mechanisms for managing the scaling problems of wide-area (BGP4) routing that require occasional or frequent site renumbering have been consistently dismissed as unacceptable. But none of this means that we can duck the problem, because as explained below, renumbering is sometimes unavoidable. This document aims to explore the issues behind this problem statement, especially with a view to identifying the gaps and known operational issues.
これらの努力にもかかわらず、リナンバリング、特に大規模なサイトやネットワークへのメディアのために、広く、高価な痛みを伴う、とエラーが発生しやすいプロセスと見なされるので、できるだけ多くのネットワーク管理者によって回避されます。いくつかは非常にIPの設計アドレッシングとルーティングは、自動リナンバリングが本質的に不可能と主張します。実際には、管理者は再番号付けすることを避けるために経済的インセンティブを持っている、と多くは、結果として取り組む民間とネットワークアドレス変換（NAT）に頼ってきました。これは、広域（BGP4）時々または頻繁サイトのリナンバリングが必要なルーティングのスケーリングの問題を管理するための任意のメカニズムが一貫容認できないとして却下されている非常に不幸な結果を有します。しかし、これのどれも、以下のように説明したので、我々は問題鴨、、リナンバリングは時々避けられないことを意味しません。この文書では、特にギャップと知られている運用上の問題を特定する目的で、この問題文の後ろに問題を探求することを目指しています。
It is worth noting that for a very large class of users, renumbering is not in fact a problem of any significance. A domestic or small office user whose device operates purely as a client or peer-to-peer node is in practice renumbered at every restart (even if the address assigned is often the same). A user who roams widely with a laptop or pocket device is also renumbered frequently. Such users are not concerned with the survival of very long-term application sessions and are in practice indifferent to renumbering. Thus, this document is mainly concerned with issues affecting medium to large sites.
これにより、ユーザーの非常に大きなクラスのために、リナンバリングは実際にはどんな意義の問題ではないことは注目に値します。そのデバイスクライアントまたはピア・ツー・ピア・ノードは実際には再起動のたびに番号が付け直されて（割り当てられたアドレスは、多くの場合、同じであっても）純粋に動作し、国内や小規模オフィスのユーザー。ノートパソコンやポケットデバイスで広くローミングするユーザーも頻繁に番号が付け直されています。このようなユーザーは非常に長期的なアプリケーションセッションの生存に関係しておらず、実際にはリナンバリングに無関心です。したがって、この文書は、大規模なサイトへのメディアに影響を与える問題で主に懸念しています。
There are numerous reasons why such sites might need to renumber in a planned fashion, including:
このようなサイトは、計画された形で含むの番号を変更する必要があるかもしれませんなぜ、多くの理由があります。
o Change of service provider, or addition of a new service provider, when provider-independent addressing is not an option.
サービスプロバイダ、または新しいサービスプロバイダの追加のO変更、プロバイダに依存しないアドレス指定のオプションではありません。
o A service provider itself has to renumber.
Oサービスプロバイダ自体は、番号を付け直す必要があります。
o Change of site topology (i.e., subnet reorganisation).
サイトトポロジの変更O（すなわち、サブネット再編）。
o Merger of two site networks into one, or split of one network into two or more parts.
2つ以上の部分にO 1に2つのサイトネットワークの合併、または1つのネットワークの分割。
o During IPv6 deployment, change of IPv6 access method (e.g., from tunneled to native).
O IPv6展開、（天然にトンネルから例えば、）IPv6アクセス方法の変更中。
The most demanding case would be unplanned automatic renumbering, presumably initiated by a site border router, for reasons connected with wide-area routing. There is already a degree of automatic renumbering for some hosts, e.g., IPv6 "privacy" addresses [RFC4941].
最も要求の厳しい場合には、広域ルーティングと接続の理由から、おそらくサイトの境界ルータによって開始予定外の自動リナンバリング、だろう。いくつかのホスト、例えば、IPv6の「プライバシー」のアドレス[RFC4941]のための自動リナンバリングの程度がすでにあります。
It is certainly to be expected that as the pressure on IPv4 address space intensifies in the next few years, there will be many attempts to consolidate usage of addresses so as to avoid wastage, as part of the "end game" for IPv4, which necessarily requires renumbering of the sites involved. However, strategically, it is more important to implement and deploy techniques for IPv6 renumbering, so that as IPv6 becomes universally deployed, renumbering becomes viewed as a relatively routine event. In particular, some mechanisms being considered to allow indefinite scaling of the wide-area routing system might assume site renumbering to be a straightforward matter.
確かにIPv4アドレス空間の圧力が今後数年間で激化として浪費を避けるために、必然的にIPv4の「エンドゲーム」の一環として、アドレスの使用を統合する多くの試みがあるだろうことが予想されます関連するサイトのリナンバリングが必要です。しかし、戦略的に、実現すると、IPv6が普遍的に展開につれて、リナンバリングは比較的日常的出来事として見てしまうように、IPv6のリナンバリングのための技術を展開することがより重要です。特に、広域ルーティングシステムの不定スケーリングを可能にするために検討されているいくつかのメカニズムが簡単な問題であるために、サイトのリナンバリングを想定することがあります。
There is work in progress that, if successful, would eliminate some of the motivations for renumbering. In particular, some types of solutions to the problem of scalable routing for multihomed sites would likely eliminate both multihoming and switching to another ISP as reasons for site renumbering.
成功した場合、リナンバリングのための動機の一部を排除する、進行中の作業があります。具体的には、マルチホームのサイトのためのスケーラブルなルーティングの問題に対する解決策のいくつかの種類がありそうマルチホーミングとサイトリナンバリングの理由として、別のISPへの切り替えの両方を排除するであろう。
Several proposed identifier/locator split schemes provide good examples, including at least Identifier Locator Network Protocol [ILNP], Locator/ID Separation Protocol [LISP], and Six/One [SIX-ONE] (in alphabetical order). The recent discussion about IPv6 Network Address Translation (IPv6 NAT) provides a separate example [NAT66]. While remaining highly contentious, this approach, coupled with unique local addresses or a provider-independent address prefix, would appear to eliminate some reasons for renumbering in IPv6. However, even if successful, such solutions will not eliminate all of the reasons for renumbering. This document does not take any position about development or deployment of protocols or technologies that would make long-term renumbering unnecessary, but rather deals with practical cases where partial or complete renumbering is necessary in today's Internet.
いくつか提案されている識別子/ロケータ分割スキームは、少なくとも識別子ロケータネットワークプロトコル[ILNP]、ロケータ/ ID分離プロトコル[LISP]を含む、良い例を提供し、シックス/ワン[SIX-ONE（アルファベット順）。 IPv6ネットワークアドレス変換（IPv6のNAT）に関する最近の議論は別の例[NAT66]を提供します。非常に論争残りますが、このアプローチは、ユニークローカルアドレスまたはプロバイダに依存しないアドレスプレフィックスと相まって、IPv6ではリナンバリングのためのいくつかの理由を排除するように思われます。でも、成功した場合は、そのような解決策は、リナンバリングの理由のすべてを排除しません。この文書では、長期的なリナンバリング不要になるだろうプロトコルや技術の開発や展開についての任意の位置を取るのではなく、部分的または完全な再番号付けは、今日のインターネットに必要な実践的な例を扱っていません。
IP addresses do not have a built-in lifetime. Even when an address is leased for a finite time by DHCP or SLAAC, or when it is derived from a DNS record with a finite time to live (TTL) value, this information is unavailable to applications once the address has been passed to an upper layer by the socket interface. Thus, a renumbering event is almost certain to be an unpredictable surprise from the point of view of any application software using the address. Many of the issues listed below derive from this fact.
IPアドレスは、内蔵の寿命を持っていません。アドレスはDHCPまたはSLAACによる有限時間のためにリース、または（TTL）値を生きるために有限時間でDNSレコードから導出されたときにアドレスが上位に渡された後、この情報は、アプリケーションに利用できないときでもソケットインタフェースにより、層。したがって、リナンバリングイベントは、アドレスを使用して、任意のアプリケーションソフトウェアの観点から予測できない驚きであることがほぼ確実です。下記に記載されている問題の多くは、この事実から派生します。
At a high level, DHCP [RFC2131] [RFC3315] offers similar support for renumbering for both versions of IP. A host requests an address when it starts up, the request might be delivered to a local DHCP server or via a relay to a central server, and if all local policy requirements are met, the server will provide an address with an associated lifetime, and various other network-layer parameters (in particular, the subnet mask and the default router address).
ハイレベルでは、DHCP [RFC2131] [RFC3315]はIPの両方のバージョンのリナンバリングのために同様のサポートを提供しています。ホストは起動時に、要求がローカルDHCPサーバまたは中央サーバにリレーを介して配信されるかもしれない、とすべてのローカルポリシーの要件が満たされている場合、サーバは関連付けられた寿命とアドレスを提供しますアドレスを要求し、他の様々なネットワーク層パラメータ（特に、サブネットマスク、デフォルトルータのアドレス）。
From an operational viewpoint, the interesting aspect is the local policy. Some sites require pre-registration of MAC (Media Access Control) addresses as a security measure, while other sites permit any MAC address to obtain an IP address. Similarly, some sites use DHCP to provide the same IP address to a given MAC address each time (this is sometimes called "Static DHCP"), while other sites do not (this is sometimes called "Dynamic DHCP"), and yet other sites use a combination of these two modes where some devices (e.g., servers, Voice over IP (VoIP) handsets) have a relatively static IP address that is provisioned via DHCP while other devices (e.g., portable computers) have a different IP address each time they connect to the network. As an example, many universities in the United States and United Kingdom require MAC address registration of faculty, staff, and student devices (including handheld computers with wireless connections).
運用の観点から、興味深い点は、ローカルポリシーです。他のサイトは、IPアドレスを取得するために、任意のMACアドレスを許可しながら、一部のサイトでは、セキュリティ対策としてMAC（Media Access Control）アドレスの事前登録が必要です。同様に、いくつかのサイトはまだ他のサイトを他のサイトにはないながら（これは時々「ダイナミックDHCP」と呼ばれている）、与えられたMACアドレスに（これは時々「静的DHCP」と呼ばれる）たびに同じIPアドレスを提供するために、DHCPを使用して、いくつかのデバイス（例えば、サーバ、ボイスオーバーIP（VoIP）の携帯電話）は、他のデバイス（例えば、ポータブルコンピュータ）は、異なるIPアドレスを毎回持っていながら、DHCP経由でプロビジョニングされ、比較的静的IPアドレスを持っているこの2つのモードを組み合わせて使用します彼らは、ネットワークに接続します。例として、米国と英国の多くの大学は、（ワイヤレス接続でのハンドヘルドコンピュータを含む）教員、職員、学生機器のMACアドレスの登録が必要です。
These policy choices interact strongly with whether the site has what might be called "strong" or "weak" asset management. At the strong extreme, a site has a complete database of all equipment allowed to be connected, certainly containing the MAC address(es) for each host, as well as other administrative information of various kinds. Such a database can be used to generate configuration files for DHCP, DNS, and any access control mechanisms that might be in use. For example, only certain MAC addresses might be allowed to get an IP address on certain subnets. At the weak extreme, a site has no asset management, any MAC address may get a first-come first-served IP address on any subnet, and there is no network-layer access control.
これらの政策の選択肢は、サイトが「強い」または「弱い」アセット・マネジメントと呼ばれるかもしれないものを持っているかどうかと強く相互作用します。強い極端では、サイトは確かに各ホストのMACアドレスを含む、接続することが許可されているすべての機器の完全なデータベースだけでなく、様々な種類のその他の管理情報を有しています。このようなデータベースは、DHCP、DNSの設定ファイルを生成するために使用することができ、かつ任意のアクセス制御メカニズムが使用されている可能かもしれません。例えば、唯一の特定のMACアドレスは、特定のサブネット上のIPアドレスを取得させて頂く場合がございます。弱い極端で、サイトが資産管理を持っていない、任意のMACアドレスは任意のサブネット上の先着最初のサーブIPアドレスを取得することができ、何のネットワーク層のアクセス制御はありません。
The IEEE 802.1X standard [IEEE.802-1X] [IEEE.802-1X-REV] specifies a connection mechanism for wired/wireless Ethernet that is often combined with DHCP and other mechanisms to form, in effect, a network login. Using such a network login, the user of a device newly connecting to the network must provide both identity and authentication before being granted access to the network. As part of this process, the network control point will often configure the point of network connection for that specific user with a range of parameters -- such as Virtual LAN (VLAN), Access Control Lists (ACLs), and Quality-of-Service (QoS) profiles. Other forms of network login also exist, often using an initial web page for user identification and authentication. The latter approach is commonly used in hotels or cafes.
IEEE 802.1X標準[IEEE.802-1X] [IEEE.802-1X-REV]は、多くの場合、実際には、ネットワークへのログインを形成するために、DHCPおよび他の機構と組み合わされて、有線/無線イーサネット接続機構を指定します。そのようなネットワークへのログインを使用して、新たにネットワークに接続しているデバイスのユーザは、ネットワークへのアクセスが許可される前に、IDと認証の両方を提供する必要があります。このプロセスの一部として、ネットワーク制御点は、多くの場合、パラメータの範囲は、その特定のユーザのネットワーク接続の点を設定します - 、仮想LAN（VLAN）、アクセス制御リスト（ACL）など、およびサービス品質（QoS）のプロファイル。ネットワークログインの他の形態もまた、多くの場合、ユーザーの識別と認証のための最初のWebページを使用して、存在します。後者のアプローチは、一般的にホテルやカフェなどで使用されています。
In principle, a site that uses DHCP can renumber its hosts by reconfiguring DHCP for the new address range. The issues with this are discussed below.
原則的には、DHCPを使用するサイトは、新しいアドレス範囲のためのDHCPを再構成することによって、そのホストの番号を変更することができます。これの問題は、以下に説明されています。
SLAAC, although updated recently [RFC4862], was designed prior to DHCPv6 and was intended for networks where unattended automatic configuration was preferred. Ignoring the case of an isolated network with no router, which will use link-local addresses indefinitely, SLAAC follows a bootstrap process. Each host first gives itself a link-local address, and then needs to receive a link-local multicast Router Advertisement (RA) [RFC4861] that tells it the routeable subnet prefix and the address(es) of the default router(s). A node may either wait for the next regular RA or solicit one by sending a link-local multicast Router Solicitation. Knowing the link prefix from the RA, the node may now configure its own address. There are various methods for this, of which the basic one is to construct a unique 64-bit identifier from the interface's MAC address.
最近更新がSLAAC、[RFC4862]、DHCPv6の前に設計された無人自動構成が好まれたネットワークのために意図されていました。無限にリンクローカルアドレスが使用されないルータと分離されたネットワークの場合を無視し、SLAACは、ブートストラッププロセスに従います。各ホストは、最初に自分自身にリンクローカルアドレスを与え、その後、それをルーティング可能なサブネットプレフィックスとデフォルトルータ（複数可）のアドレスを伝え、リンクローカルマルチキャストルータアドバタイズメント（RA）[RFC4861]を受信する必要があります。ノードは、いずれかの次の定期的なRAを待つか、リンクローカルマルチキャストルーター要請を送信することによって、1を求めることがあります。 RAからのリンクの接頭辞を知って、ノードは現在、自身のアドレスを設定することができます。基本的なものは、インタフェースのMACアドレスからのユニークな64ビットの識別子を構築することとなっている。このための様々な方法があります。
We will not describe here the IPv6 processes for Duplicate Address Detection (DAD), Neighbour Discovery (ND), and Neighbour Unreachability Discovery (NUD). Suffice it to say that they work, once the initial address assignment based on the RA has taken place.
ここでは、重複アドレス検出（DAD）、近隣探索（ND）、および近隣到達不能検出（NUD）のIPv6プロセスを記述しません。 RAに基づいて初期アドレスの割り当てが行われた後、彼らは仕事と言えば十分です。
The contents of the RA message are clearly critical to this process and its use during renumbering. An RA can indicate more than one prefix, and more than one router can send RAs on the same link. For each prefix, the RA indicates two lifetimes: "preferred" and "valid". Addresses derived from this prefix must inherit its lifetimes. When the valid lifetime expires, the prefix is dead and the derived address must not be used any more. When the preferred lifetime is expired (or set to zero) the prefix is deprecated, and must not be used for any new sessions. Thus, setting a preferred lifetime that is zero or finite is SLAAC's warning that renumbering will occur. SLAAC assumes that the new prefix will be advertised in parallel with the deprecated one, so that new sessions will use addresses configured under the new prefix.
RAメッセージの内容は、このプロセスとリナンバリング時に、その使用に明らかに重要です。 RAは、複数のプレフィックスを示すことができ、かつ複数のルータは、同じリンク上のRAを送信することができます。各プレフィックスについて、RAは、二つの寿命を示しています。「優先」と「有効」。このプレフィックスから派生したアドレスは、その寿命を継承しなければなりません。有効期間が満了した場合、プレフィックスは死んでいると派生アドレスはもはや使用することはできません。好適寿命の期限が切れて（またはゼロに設定）されている場合、プレフィックスは廃止され、新たなセッションのために使用することはできません。このように、ゼロまたは有限である優先寿命を設定すると、リナンバリングが発生するSLAACの警告です。 SLAACは、新しいセッションが新しい接頭辞の下に構成されたアドレスを使用するように、新しい接頭辞は、廃止予定の1と並行して宣伝されることを前提としています。
With IPv6, a Router Advertisement not only advertises the availability of an upstream router, but also advertises routing prefix(es) valid on that link (subnetwork). Also, the IPv6 RA message contains a flag indicating whether or not the host should use DHCPv6 to configure. If that flag indicates that the host should use DHCPv6, then the host is not supposed to autoconfigure itself as outlined in Section 2.2. However, there are some issues in this area, described in Section 5.1.1.
IPv6では、ルータアドバタイズメントは、上流のルータのアベイラビリティをアドバタイズするだけでなく、そのリンク（サブネットワーク）上のルーティング接頭語（es）有効をアドバタイズします。また、IPv6のRAメッセージは、ホストが設定するためのDHCPv6を使用すべきか否かを示すフラグを含んでいます。そのフラグは、ホストがDHCPv6のを使うべきであることを示す場合、ホストはセクション2.2に概説されるようにそれ自体を自動設定するように想定されていません。しかし、セクション5.1.1で説明し、この分野におけるいくつかの問題が、あります。
In an environment where a site has more than one upstream link to the outside world, the site might have more than one valid routing prefix. In such cases, typically all valid routing prefixes within a site will have the same prefix length. Also, in such cases, it might be desirable for hosts that obtain their addresses using DHCPv6 to learn about the availability of upstream links dynamically, by deducing from periodic IPv6 RA messages which routing prefixes are currently valid. This application seems possible within the IPv6 Neighbour Discovery architecture, but does not appear to be clearly specified anywhere. So, at present, this approach for hosts to learn about availability of new upstream links or loss of prior upstream links is unlikely to work with currently shipping hosts or routers.
サイトには、外の世界に複数の上流のリンクを持っている環境では、サイトには、複数の有効なルーティングプレフィックスを持っているかもしれません。このような場合には、通常、サイト内のすべての有効なルーティングプレフィックスは、同じプレフィックス長を持つことになります。また、このような場合には、それは、ルーティングプレフィックスは、現在有効な定期的なIPv6のRAメッセージから推定することで、動的に上流のリンクの可用性について学ぶためのDHCPv6を使用して、そのアドレスを取得するホストのために望ましいかもしれません。このアプリケーションは、IPv6近隣探索アーキテクチャ内で可能なようだが、明確にどこにでも指定されていないよう。だから、現在では、新しい上流のリンクの可用性または前の上流のリンクの損失について学ぶためにホストのため、このアプローチは、現在、ホストまたはルータを出荷して作業することはほとんどありません。
"The Point-to-Point Protocol (PPP)" [RFC1661] includes support for a Network Control Protocol (NCP) for both IPv4 and IPv6.
「ポイントツーポイントプロトコル（PPP）」[RFC1661]は、IPv4とIPv6の両方のためのネットワーク制御プロトコル（NCP）のサポートを含みます。
For IPv4, the NCP is known as IPCP [RFC1332] and allows explicit negotiation of an IP address for each end. PPP endpoints acquire (during IPCP negotiation) both their own address and the address of their peer, which may be assumed to be the default router if no routing protocol is operating. Renumbering events arise when IPCP negotiation is restarted on an existing link, when the PPP connection is terminated and restarted, or when the point-to-point medium is reconnected. Peers may propose either the local or remote address or require the other peer to do so. Negotiation is complete when both peers are in agreement. In practice, if no routing protocol is used, as in a subscriber/provider environment, then the provider proposes both addresses and requires the subscriber either to accept the connection or to abort. Effectively, the subscriber device is renumbered each time it connects for a new session.
IPv4の場合、NCPは、IPCP [RFC1332]として知られており、各端部のためのIPアドレスの明示的なネゴシエーションを可能にします。 PPPエンドポイントは、（IPCPネゴシエーション中に）自分のアドレスと全くルーティングプロトコルが動作していない場合、デフォルトルータであると仮定することができるそれらのピアのアドレスの両方を取得します。 IPCPネゴシエーションがPPP接続が終了して再起動、またはポイントツーポイントメディアが再接続されたときにされている既存のリンク上で再起動したときに番号変更のイベントが発生します。ピアは、ローカルまたはリモートアドレスを提案しているか、そうするように、他のピアが必要な場合があります。両方のピアが一致しているとき、交渉は完了です。何のルーティングプロトコルが使用されていない場合実際には、加入者/プロバイダ環境のように、プロバイダは、両方のアドレスを提案し、接続を受け入れるか、中止するか加入者を必要とします。実際には、加入者デバイスは、それが新しいセッションのために接続するたびに番号が付け直されています。
For IPv6, the NCP is IP6CP [RFC5072] and is used to configure an interface identifier for each end, after which link-local addresses may be created in the normal way. In practice, each side can propose its own identifier and renegotiation is only necessary when there is a collision, or when a provider wishes to force a subscriber to use a specific interface identifier. Once link-local addresses are assigned and IP6CP is complete, automatic assignment of global scope addresses is performed by the same methods as with multipoint links, i.e., either SLAAC or DHCPv6. Again, in a subscriber/provider environment, this allows renumbering per PPP session.
IPv6の場合、NCPはIP6CP [RFC5072]は、リンクローカルアドレスは、通常の方法で作成することができる後の各端部のインタフェース識別子を設定するために使用されます。実際には、それぞれの側は、独自の識別子を提案することができ、衝突がある場合に再ネゴシエーションが必要なだけである、またはプロバイダは、特定のインタフェース識別子を使用する加入者を強制することを望む場合。リンクローカルアドレスが割り当てられ、IP6CPが完了されると、グローバルスコープのアドレスの自動割り当ては、マルチリンク、即ち、SLAACまたはDHCPv6のいずれかと同様の方法で行われます。ここでも、加入者/プロバイダー環境で、これは、PPPセッションごとにリナンバリングすることができます。
A site must provide DNS records for some or all of its hosts, and of course these DNS records must be updated when hosts are renumbered. Most sites will achieve this by maintaining a DNS zone file (or a database from which it can be generated) and loading this file into the site's DNS server(s) whenever it is updated. As a renumbering tool, this is clumsy but effective. Clearly perfect synchronisation between the renumbering of the host and the updating of its A or AAAA record is impossible. An alternative is to use Secure Dynamic DNS Update [RFC3007], in which a host informs its own DNS server when it receives a new address.
サイトでは、そのホストの一部またはすべてのDNSレコードを提供しなければならない、そしてホストが再番号付けされている場合、もちろんこれらのDNSレコードを更新する必要があります。ほとんどのサイトは、DNSゾーンファイル（またはそれを発生させることができるデータベース）を維持し、それが更新されるたびに、サイトのDNSサーバー（複数可）には、このファイルをロードすることでこれを実現します。リナンバリングツールとして、これは不器用だが効果的です。ホストの再番号付けおよびそのAまたはAAAAレコードの更新の間に明らかに完全に同期することは不可能です。代替は、それが新しいアドレスを受信したときに、ホストが独自のDNSサーバに通知するセキュリティで保護された動的DNS更新[RFC3007]を使用することです。
There are widespread reports that the freely available BIND DNS software (which is what most UNIX hosts use), Microsoft Windows (XP and later), and Mac OS X all include support for Secure Dynamic DNS Update. So do many home gateways. Further, there are credible reports that these implementations are interoperable when configured properly ([DNSBOOK] p. 228 and p. 506).
自由に利用できるBIND DNSソフトウェア（ほとんどのUNIXホストが使用するものである）、マイクロソフトのWindows（後でXPおよび）、およびMac OS Xのすべてのセキュリティで保護された動的DNSの更新のためのサポートが含まれている広範な報告があります。だから、多くのホームゲートウェイを行います。さらに、（[DNSBOOK]のp。228およびp。506）が適切に構成されている場合、これらの実装が相互運用可能であることを確かな報告があります。
Commonly used commercial DNS and DHCP servers (e.g., Windows Server) often are deployed with Secure Dynamic DNS Update also enabled. In some cases, merely enabling both the DNS server and the DHCP server might enable Secure Dynamic DNS Update as an automatic side effect ([DNSBOOK] p. 506). So in some cases, sites might have deployed
一般的に使用される商業用DNSおよびDHCPサーバ（例えば、Windows Serverの）は、多くの場合にも有効なセキュリティで保護された動的DNSの更新で展開されています。いくつかのケースでは、単にDNSサーバとDHCPサーバの両方を有効にすると、自動副作用などの安全な動的DNS更新を有効にするかもしれない（[DNSBOOK]のp。506）。だから、いくつかのケースでは、サイトが展開されている場合があります
Secure Dynamic DNS Update already, without realising it. An additional enhancement would be for DHCP clients to implement support for the "Client FQDN" option (Option 81).
それを実現することなく、すでにダイナミックDNSアップデートを固定します。 DHCPクライアントは、「クライアントのFQDN」オプション（オプション81）のためのサポートを実装するための追加機能拡張は次のようになります。
Since address changes are usually communicated to other sites via the DNS, the latter's security is essential for secure renumbering. The Internet security community believes that the current DNS Security (DNSsec) and Secure Dynamic DNS Update specifications are sufficiently secure and has been encouraging DNSsec deployment ([RFC3007] [RFC4033] [RFC4034] [RFC4035]).
アドレスの変更は通常、DNSを介して他のサイトに伝達されているので、後者のセキュリティは安全なリナンバリングのために不可欠です。インターネットセキュリティコミュニティは、ダイナミックDNSアップデートの仕様は十分に安全であり、DNSSECの導入（[RFC3007] [RFC4033] [RFC4034] [RFC4035]）を奨励してきたセキュア現在のDNSセキュリティ（DNSSEC）ことと考えています。
As of this writing, there appears to be significantly more momentum towards rapid deployment of DNS Security standards in the global public Internet than previously. Several country-code Top-Level Domains (ccTLDs) have already deployed signed TLD root zones (e.g., Sweden's .SE). Several other TLDs are working to deploy signed TLD root zones by published near-term deadlines (e.g., .GOV, .MIL). In fact, it is reported that .GOV has been signed operationally since early February 2009. It appears likely that the DNS-wide root zone will be signed in the very near future. See, for example, <http://www.dnssec-deployment.org/> and <http://www.ntia.doc.gov/DNS/DNSSEC.html>.
この記事の執筆時点では、以前よりグローバルな公共のインターネットにおけるDNSのセキュリティ規格の急速な展開に向けてかなり多くの勢いがあるように見えます。いくつかの国コードトップレベルドメイン（ccTLD）は、すでに署名したTLDのルートゾーン（例えば、スウェーデンの.SE）を展開しています。いくつかの他のTLDは、公開された短期期限（例えば、.GOV、.MIL）によって署名されたTLDのルートゾーンを展開するために取り組んでいます。実際には、.GOV DNS全体のルートゾーンは非常に近い将来に署名される可能性が表示されます初頭2009年2月以来、運用署名されていることが報告されています。参照、例えば、<http://www.dnssec-deployment.org/>と<http://www.ntia.doc.gov/DNS/DNSSEC.html>。
The need for hosts to contain pre-configured addresses for servers can be reduced by deploying the Service Location Protocol (SLP). For some common services, such as network printing, SLP can therefore be an important tool for facilitating site renumbering. See [RFC2608], [RFC2610], [RFC3059], [RFC3224], [RFC3421], and [RFC3832].
サーバー用の事前設定されたアドレスを格納するためのホストの必要性は、サービスロケーションプロトコル（SLP）を展開することによって減少させることができます。そのようなネットワーク印刷などのいくつかの一般的なサービスについては、SLPは、そのため、サイトのリナンバリングを容易にするための重要なツールとなります。 [RFC2608]、[RFC2610]、[RFC3059]、[RFC3224]、[RFC3421]、および[RFC3832]を参照してください。
Multicast DNS (mDNS) and DNS Service Discovery are already widely deployed in BSD, Linux, Mac OS X, UNIX, and Windows systems, and are also widely used for both link-local name resolution and for DNS-based dynamic service discovery [MDNS] [DNSSD]. In many environments, the combination of mDNS and DNS Service Discovery (e.g., using SRV records [RFC3958]) can be important tools for reducing dependency on configured addresses.
マルチキャストDNS（mDNSの）およびDNSサービス探索は、既に広くBSD、Linuxでは、マックOS X、UNIX、およびWindowsシステムに配備されている、とも広くMDNS [両方のリンクローカルの名前解決のためにとDNSベースの動的なサービスの発見のために使用されています] [DNSSD]。多くの環境では、のmDNSとDNSサービスディスカバリー（例えば、SRVレコード[RFC3958]を使用）の組み合わせは、設定されたアドレスへの依存を低減するための重要なツールであることができます。
Although DHCP was originally conceived for host configuration, it can also be used for some aspects of router configuration. The DHCPv6 Prefix Delegation options [RFC3633] are intended for this. For
DHCPは、もともとホスト構成のために考案されましたが、それはまた、ルータの設定のいくつかの側面のために使用することができます。 DHCPv6のプレフィックス委任オプション[RFC3633]はこのために意図されています。ために
example, DHCPv6 can be used by an ISP to delegate or withdraw a prefix for a customer's router, and this can be cascaded throughout a site to achieve router renumbering.
たとえば、DHCPv6のは、顧客のルータのプレフィックスを委任または撤回するISPで使用することができ、これは、ルータのリナンバリングを達成するために、サイト全体でカスケード接続することができます。
An ICMPv6 extension to allow router renumbering for IPv6 is specified in [RFC2894], but there appears to be little experience with it. It is not mentioned as a useful mechanism by [RFC4192].
IPv6のルータリナンバリングを許可するICMPv6の拡張は、[RFC2894]で指定されたが、それとはほとんど経験があるように思われます。これは[RFC4192]で有用な機構として言及されていません。
[RFC4191] extends IPv6 router advertisements to convey default router preferences and more-specific routes from routers to hosts. This could be used as an additional tool to convey information during renumbering, but does not appear to be used in practice.
[RFC4191]はホストにルータからデフォルトルータ好みと、より特異的なルートを伝えるためのIPv6ルータ広告を拡張します。これは、リナンバリングの際に情報を伝えるために、追加のツールとして使用することができ、実際に使用されていないよう。
[CPE] requires that a customer premises router use DHCPv6 to obtain an address prefix from its upstream ISP and use IPv6 RA messages to establish a default IPv6 route (when IPv6 is in use).
（IPv6が使用されているとき）[CPE]は、顧客宅内ルータ使用のDHCPv6はその上流ISPからアドレスプレフィックスを取得し、デフォルトのIPv6ルートを確立するためのIPv6 RAメッセージを使用することが必要です。
IPv6 was designed to support multiple addresses per interface and multiple prefixes per subnet. As described in [RFC4192], this allows for a phased approach to renumbering (adding the new prefix and addresses before removing the old ones).
IPv6がインターフェイスごとに複数のアドレスとサブネットごとに複数のプレフィックスをサポートするように設計されました。 [RFC4192]で説明したように、これは（古いものを削除する前に、新しいプレフィックスとアドレスを追加）リナンバリングへの段階的なアプローチが可能になります。
As an additional result of the multi-addressing mechanism, a site might choose to use Unique Local Addressing (ULA) [RFC4193] for all on-site communication, or at least for all communication with on-site servers, while using globally routeable IPv6 addresses for all off-site communications. It would also be possible to use ULAs for all on-site network management purposes, by assigning ULAs to all devices. This would make these on-site activities immune to renumbering of the prefix(es) used for off-site communication. Finally, ULAs can be safely shared with peer sites with which there is a VPN connection, which cannot be done with ambiguous IPv4 addresses [RFC1918]; such VPNs would not be affected by renumbering.
グローバルルーティング可能なIPv6を使用しながら、マルチアドレス指定メカニズムの追加の結果として、このサイトは、オンサイトのサーバーとのすべての通信のために、少なくともすべてのオンサイトの通信のために取り組むユニークローカル（ULA）[RFC4193]を使用することを選択、またはかもしれませんすべてのオフサイト通信用のアドレス。また、すべてのデバイスにULAsを割り当てることにより、すべてのオンサイトのネットワーク管理目的でULAsを使用することも可能です。これは、オフサイトの通信に使用される接頭語（ES）のリナンバリングに対する免疫これらのオンサイトの活動になるだろう。最後に、ULAs安全曖昧IPv4アドレス[RFC1918]を用いて行うことができないVPN接続が存在しているピアサイトと共有することができます。そのようなVPNは、リナンバリングの影響を受けることはないだろう。
The IPv6 model also includes "privacy" addresses that are constructed with pseudo-random interface identifiers to conceal actual MAC addresses [RFC4941]. This means that IPv6 stacks and client applications already need to be agile enough to handle frequent IP address changes (e.g., in the privacy address), since in a privacy-sensitive environment the address lifetime likely will be rather short.
IPv6のモデルは、実際のMACアドレス[RFC4941]を隠すために、擬似ランダムインタフェース識別子で構成されている「プライバシー」アドレスを含みます。これは、プライバシーに敏感な環境で、アドレスの有効期間は、おそらくかなり短くなりますので、IPv6のスタックとクライアント・アプリケーションはすでに、（プライバシーのアドレスで、例えば、）頻繁にIPアドレスの変更を処理するのに十分なアジャイルである必要があることを意味します。
For IPv6, a useful description of practical aspects was drafted in [THINK], as a complement to [RFC4192]. As indicated there, a primary requirement is to minimise the disruption caused by renumbering. This applies at two levels: disruption to site operations in general and disruption to individual application sessions in progress at the moment of renumbering. In the IPv6 case, the intrinsic ability to overlap use of the old and new prefixes greatly mitigates disruption to ongoing sessions, as explained in [RFC4192]. This approach is in practice excluded for IPv4, largely because IPv4 lacks a Stateless Address Autoconfiguration (SLAAC) mechanism.
IPv6の場合、実用的な態様の有用な説明は[RFC4192]を補完するものとして、[THINK]で作成されました。そこに示されているように、主要な要件は、リナンバリングによって引き起こされる混乱を最小にすることです。リナンバリングの現時点で進行中の個々のアプリケーションセッションへの一般的なサイトの運営を中断し、中断：この2つのレベルで適用されます。 [RFC4192]で説明したようにIPv6のケースでは、古いものと新しいプレフィックスの使用と重複する固有の能力を大幅に、進行中のセッションの中断を軽減します。このアプローチは、IPv4がステートレスアドレス自動設定（SLAAC）メカニズムが欠如している主な理由、IPv4のために除外実際にあります。
For IPv4, the vast majority of client systems (PCs, workstations, and handheld computers) today use DHCP to obtain their addresses and other network-layer parameters. DHCP provides for lifetimes after which the address lease expires. So it should be possible to devise an operational procedure in which lease expiry coincides with the moment of renumbering (within some margin of error). In the simplest case, the network administrator just lowers all DHCP address lease lifetimes to a very short value (e.g., a few minutes). It does this long enough before a site-wide change that each node will automatically pick up its new IP address within a few minutes of the renumbering event. In this case, it would be the DHCP server itself that automatically accomplishes client renumbering, although this would cause a peak of DHCP traffic and therefore would not be instantaneous. DHCPv6 could accomplish a similar result.
IPv4の場合、クライアント・システムの大半（PC、ワークステーション、およびハンドヘルドコンピュータ）は本日、それらのアドレスおよびその他のネットワーク層パラメータを取得するためにDHCPを使用しています。 DHCPは、アドレスのリースの期限が切れるまでの寿命のために用意されています。だから、有効期限が（エラーのいくつかのマージン内）リナンバリングの瞬間と一致リースする操作手順を考案することが可能なはずです。最も単純なケースでは、ネットワーク管理者は、単に非常に短い値（例えば、数分）に、すべてのDHCPアドレスのリース寿命を低下させます。これは、各ノードが自動的にリナンバリングイベントの数分以内にその新しいIPアドレスをピックアップするサイト全体の変更の前に十分な長さにこれを行います。これは、DHCPトラフィックのピークを引き起こすので、瞬間的ではないでしょうが、この場合、それは、自動的にクライアントのリナンバリングを達成DHCPサーバー自体になります。 DHCPv6が同様の結果を達成することができます。
The FORCERENEW extension is defined for DHCP for IPv4 [RFC3203]. This is specifically unicast-only; a DHCP client must discard a multicast FORCERENEW. This could nevertheless be used to trigger the renumbering process, with the DHCP server cycling through all its clients issuing a FORCERENEW to each one. DHCPv6 has a similar feature, i.e., a unicast RECONFIGURE message, that can be sent to each host to inform it to check its DHCPv6 server for an update. These two features do not appear to be widely used for bulk renumbering purposes.
FORCERENEW拡張はIPv4のDHCP [RFC3203]のために定義されています。これは、具体的には、ユニキャストのみです。 DHCPクライアントは、マルチキャストFORCERENEWを破棄しなければなりません。これは、それにもかかわらず、DHCPサーバがそれぞれにFORCERENEWを発行し、そのすべてのクライアントを巡回して、リナンバリングプロセスをトリガするために使用することができます。 DHCPv6のは、同様の機能、更新のためにそのDHCPv6サーバを確認するためにそれを通知するために、各ホストに送信することができる、すなわち、ユニキャストRECONFIGUREメッセージを、有しています。これらの2つの機能は、広くバルクリナンバリングの目的のために使用されるように表示されません。
Procedures for using a DHCP approach to site renumbering will be very different depending on whether the site uses strong or weak asset management. With strong asset management, and careful operational planning, the subnet addresses and masks will be updated in the database, and a script will be run to regenerate the DHCP MAC-to-IP address tables and the DNS zone file. DHCP and DNS timers will be set temporarily to small values. The DHCP and DNS servers will be fed the new files, and as soon as the previous DHCP leases and DNS TTLs expire, everything will follow automatically, as far as the host IP layer is concerned. In contrast, with weak asset management, and a casual operational approach, the DHCP table will be reconfigured by hand, the DNS zone file will be edited by hand, and when these configurations are installed, there will be a period of confusion until the old leases and TTLs expire. The DHCP FORCERENEW or RECONFIGURE messages could shorten this confusion to some extent.
サイトのリナンバリングへのDHCPのアプローチを使用するための手順は、サイトが強いか、弱い資産管理を使用するかどうかに応じて非常に異なるものになります。強力な資産管理では、と慎重な運用計画、サブネットアドレスとマスクがデータベースに更新され、スクリプトがDHCP MACとIPアドレスのテーブルとDNSゾーンファイルを再生成するために実行されます。 DHCPとDNSのタイマーが小さな値に一時的に設定されます。 DHCPとDNSサーバーは、新しいファイルを供給することになる、とすぐ前のDHCPリースとDNSのTTLの有効期限が切れるよう、すべては限りホストIP層に関しては、自動的に従います。弱い資産管理、そしてカジュアルな運用アプローチとは対照的に、DHCPテーブルを手で再構成され、DNSゾーンファイルを手動で編集され、これらの構成がインストールされている場合、古いまで混乱の期間があるでしょうリースとのTTLが期限切れになります。 DHCP FORCERENEWまたはRECONFIGUREメッセージは、ある程度、この混乱を短縮することができます。
DHCP, particularly for IPv4, has acquired a very large number of additional capabilities, with approximately 170 options defined at the time of this writing. Although most of these do not carry IP address information, some do (for example, options 68 through 76 all carry various IP addresses). Thus, renumbering mechanisms involving DHCP have to take into account more than the basic DHCP job of leasing an address to each host.
DHCPは、特にIPv4のために、この記事の執筆時点で定義された約170のオプションで、追加機能の非常に大きな数を取得しています。これらのほとんどは、IPアドレス情報、いくつかのDOを運ぶことはありませんが（例えば、68〜76のオプションはすべて、さまざまなIPアドレスを運びます）。したがって、DHCPを伴うリナンバリングメカニズムは、各ホストにアドレスをリースの基本的なDHCPジョブよりも考慮に入れる必要があります。
SLAAC is much less overloaded with options than DHCP; in fact, its only extraneous capability is the ability to convey a DNS server address. Using SLAAC to force all hosts on a site to renumber is therefore less complex than DHCP, and the difference between strong and weak asset management is less marked. The principle of synchronising the SLAAC and DNS updates, and of reducing the SLAAC lease time and DNS TTL, does not change.
SLAACははるかに少ないDHCPよりもオプションで過負荷になっています。実際には、その唯一の余分な機能は、DNSサーバーのアドレスを伝える能力です。番号を付け直すために、サイト上のすべてのホストを強制的にSLAACを使用すると、DHCPよりゆえ、あまり複雑であり、強弱資産管理との差が少ないマークされています。 SLAACとDNSの更新を同期化する、とSLAACリース時間とDNS TTLを減少させる原理は、変更されません。
We should note a currently unresolved ambiguity in the interaction between DHCPv6 and SLAAC from the host's point of view. RA messages include a 'Managed Configuration' flag known as the M bit, which is supposed to indicate that DHCPv6 is in use. However, it is unspecified whether hosts must interpret this flag rigidly (i.e., may or must only start DHCPv6 if it is set, or if no RAs are received) or whether hosts are allowed or are recommended to start DHCPv6 by default. An added complexity is that DHCPv6 has a 'stateless' mode [RFC3736] in which SLAAC is used to obtain an address, but DHCPv6 is used to obtain other parameters. Another flag in RA messages, the 'Other configuration' or O bit, indicates this.
私たちは、ビューのホストの視点からのDHCPv6とSLAACの間の相互作用で現在未解決のあいまいさに注意してください。 RAメッセージは、DHCPv6のが使用中であることを示すことになっているMビット、として知られている「管理設定」フラグが含まれます。しかし、ホストが堅固このフラグを解釈しなければならないかどうかを指定されていない（すなわち、よいか、設定されている場合、またはRASが受信されない場合のみのDHCPv6を開始しなければならない）、またはホストが許可されるかどうか、またはデフォルトのDHCPv6を起動することをお勧めします。追加複雑さは、DHCPv6のはSLAACアドレスを取得するために使用される「ステートレス」モード[RFC3736]を有するが、DHCPv6の他のパラメータを取得するために使用されることです。 RAメッセージ内の別のフラグが、「その他の構成」またはOのビットは、このことを示しています。
Until this ambiguous behaviour is clearly resolved by the IETF, operational problems are to be expected, since different host operating systems have taken different approaches. This makes it difficult for a site network manager to configure systems in such a way that all hosts boot in a consistent way. Hosts will start SLAAC, if so directed by appropriately configured RA messages. However, if one operating system also starts a DHCPv6 client by default, and another one starts it only when it receives the M bit, systematic address management is impeded.
このあいまいな行動が明確にIETFによって解決されるまで、異なるホスト・オペレーティング・システムは、異なるアプローチを取っているため、操作上の問題が予想されます。サイトのネットワーク管理者は、すべてのホストが一貫した方法でブートするようにシステムを設定するためにこのことを困難にしています。そう適切に構成されたRAメッセージで指示されている場合ホストは、SLAACを開始します。 1つのオペレーティング・システムは、デフォルトでDHCPv6クライアントを起動し、それがMビットを受信する場合にのみ、別の1がそれを起動する場合は、体系的なアドレス管理が妨げられます。
Also, it should be noted that on an isolated LAN, neither RA nor DHCPv6 responses will be received, and the host will remain with only its self-assigned link-local address. One could also have a situation where a multihomed network uses SLAAC for one address prefix and DHCPv6 for another, which would clearly create a risk of inconsistent host behaviour and operational confusion.
また、分離されたLAN上で、RAやDHCPv6のどちらも応答が受信されることに留意すべきである、とホストはその自己割り当てられたリンクローカルアドレスに残ります。一つは、また明確に矛盾したホストの行動や運用の混乱の危険を作成することになる、マルチホームネットワークが別のために一つのアドレスプレフィックスとDHCPv6のためSLAACを使用して、状況を持つことができます。
Neither the SLAAC approach nor DHCP without pre-registered MAC addresses will work reliably in all cases of systems that are assigned fixed IP addresses for practical reasons. Of course, even systems with static addressing can be configured to use DHCP to obtain their IP address(es). Such use of "Static DHCP" usually will ease site renumbering when it does become necessary. However, in other cases, manual or script-driven procedures, likely to be site-specific and definitely prone to human error, are needed. If a site has even one host with a fixed, manually configured address, completely automatic host renumbering is very likely to be impossible.
あらかじめ登録されたMACアドレスのないSLAACのアプローチもDHCPはいずれも、実際的な理由のために固定IPアドレスが割り当てられているシステムのすべてのケースで確実に動作します。もちろん、静的アドレスでも、システムは、そのIPアドレスを取得するためにDHCPを使用するように設定することができます。それが必要になったときにない「静的DHCP」のような使用は、通常、サイトのリナンバリングを容易にします。しかし、サイト固有である可能性が高いとヒューマンエラーに間違いを起こしやすい他の例、手動またはスクリプト駆動方法で、必要とされています。サイトには、固定された、手動で設定したアドレスを持つにも一つのホストを持っている場合は、完全に自動ホスト再番号付けは不可能である可能性が非常に高いです。
The above assumes the use of typical off-the-shelf hardware and software. There are other environments, often referred to as embedded systems, where DHCP or SLAAC might not be used and even configuration scripts might not be an option; for example, fixed IP addresses might be stored in read-only memory, or even set up using Dual In-Line Package (DIP) switches. Such systems create special problems that no general-purpose solution is likely to address.
上記の典型的な既製のハードウェアおよびソフトウェアの使用を想定しています。多くの場合、DHCPまたはSLAACが使用できない場合がありますでも設定スクリプトはオプションではないかもしれません組み込みシステム、と呼ばれる他の環境では、あります。例えば、固定されたIPアドレスは、読み出し専用メモリに記憶され、あるいはデュアル・インライン・パッケージ（DIP）スイッチを使用して設定されるかもしれません。このようなシステムには、汎用のソリューションが解決する可能性がない特別な問題を作成します。
TCP connections and UDP flows are rigidly bound to a given pair of IP addresses. These are included in the checksum calculation, and there is no provision at present for the endpoint IP addresses to change. It is therefore fundamentally impossible for the flows to survive a renumbering event at either end. From an operational viewpoint, this means that a site that plans to renumber itself is obliged either to follow the overlapped procedure described in [RFC4192] or to announce a site-wide outage for the renumbering process, during which all user sessions will fail. In the case of IPv4, overlapping of the old and new addresses is unlikely to be an option, and in any case is not commonly supported by software. Therefore, absent enhancements to TCP and UDP to enable dynamic endpoint address changes (for example, [HANDLEY]), interruptions to TCP and UDP sessions seem inevitable if renumbering occurs at either session endpoint. The same appears to be true of Datagram Congestion Control Protocol (DCCP) [RFC4340].
TCP接続とUDPフローが厳格にIPアドレスの特定のペアにバインドされています。これらは、チェックサムの計算に含まれ、IPが変更にアドレスエンドポイントの現在の規定はないされています。フローが両端にリナンバリングイベントを存続することはしたがって、基本的には不可能です。運用の観点から、これは自分自身の番号を変更することを計画し、サイトが[RFC4192]で説明重複の手順に従うことや、すべてのユーザーセッションが失敗した時に、リナンバリング処理のためのサイト全体の停止を発表するいずれかの義務があることを意味しています。 IPv4の場合には、古いものと新しいアドレスの重複はオプションになることはほとんどありませんし、どのような場合には、一般的にソフトウェアでサポートされていません。リナンバリングは、セッション・エンドポイントのいずれかで発生した場合、したがって、（例えば、[HANDLEY]）動的エンドポイントアドレスの変更を可能にするためのTCPおよびUDPに存在しない拡張機能、TCPおよびUDPセッションの中断が避けられないように見えます。同じことは、データグラム輻輳制御プロトコル（DCCP）[RFC4340]の真であることが表示されます。
In contrast, Stream Control Transmission Protocol (SCTP) already supports dynamic multihoming of session endpoints, so SCTP sessions ought not be adversely impacted by renumbering the SCTP session endpoints [RFC4960] [RFC5061].
対照的に、ストリーム制御伝送プロトコル（SCTP）が既にセッション・エンドポイントの動的マルチホーミングをサポートするので、SCTPセッションが悪影響SCTPセッション・エンドポイント[RFC4960]、[RFC5061]をリナンバリングによって影響されないはずです。
The main issue is whether the site in question has a systematic procedure for updating its DNS configuration. If it does, updating the DNS for a renumbering event is essentially a clerical issue that must be coordinated as part of a complete plan, including both forward and reverse mapping. As mentioned in [RFC4192], the DNS TTL will be manipulated to ensure that stale addresses are not cached. However, if the site uses a weak asset management model in which DNS updates are made manually on demand, there will be a substantial period of confusion and errors will be made.
主な問題は、問題のサイトはそのDNS構成を更新するための系統的な手順を持っているかどうかです。それがない場合は、リナンバリングイベントのためにDNSを更新すると、両方の前方を含むとマッピングを逆に、完全な計画の一部として調整されなければならない事務の問題は本質的です。 [RFC4192]で述べたように、DNS TTLが古いアドレスがキャッシュされていないことを確実にするために操作されます。サイトが使用している場合しかし、DNSの更新が必要に応じて手動で行われ、混乱やエラーのかなりの期間があるだろうした弱い資産管理モデルが作られます。
There are anecdotal reports that many small user sites do not even maintain their own DNS configuration, despite running their own web and email servers. They point to their ISP's resolver, request the ISP to install DNS entries for their servers, but operate internally mainly by IP address. Thus, renumbering for such sites will require administrative coordination between the site and its ISP(s), unless the DNS servers in use have Secure Dynamic DNS Update enabled. Some commercial DNS service firms include Secure Dynamic DNS Update as part of their DNS service offering.
多くの小規模ユーザサイトでも自分のWebと電子メールサーバを実行しているにもかかわらず、自分自身のDNS設定を維持していないという事例の報告があります。彼らは、サーバー用のDNSエントリをインストールしますが、主にIPアドレスが内部で動作するISPを依頼、そのISPのリゾルバを指します。使用されているDNSサーバーは、セキュリティで保護された動的DNSの更新が有効になっていない限り、このように、このようなサイトのためのリナンバリングは、サイトとそのISPとの間の行政の連携が必要になります。いくつかの商用DNSサービス企業はDNSのサービス提供の一環として、セキュリティで保護された動的DNSの更新が含まれます。
It should be noted that DNS entries commonly have matching Reverse DNS entries. When a site renumbers, these reverse entries will also need to be updated. Depending on a site's operational arrangements for DNS support, it might or might not be possible to combine forward and reverse DNS updates in a single procedure.
DNSエントリは、一般的にリバースDNSエントリが一致していることに留意すべきです。場合は、サイトの再番号付けは、これらの逆のエントリも更新する必要があります。 DNSのサポートのためのサイトの運用取り決めによっては、または前方組み合わせ、単一の手順でDNSの更新を逆転することはできない場合があります。
Ideally, we would carry out a renumbering analysis for each application protocol. To some extent, this has been done, in [RFC3795]. This found that 34 out of 257 Standards-Track or Experimental application-layer RFCs had explicit address dependencies. Although this study was made in the context of IPv4 to IPv6 transition, it is clear that all these protocols might be sensitive to renumbering. However, the situation is worse, in that there is no way to discover by analyzing specifications whether an actual implementation is sensitive to renumbering. Indeed, such analysis might be quite impossible in the case of proprietary applications.
理想的には、私たちは、それぞれのアプリケーションプロトコルのためのリナンバリング分析を行うだろう。ある程度、これは[RFC3795]で、行われています。これは、34 257のうち標準化過程や実験アプリケーション層のRFCは、明示的なアドレスの依存関係を持っていたことが分かりました。この研究は、IPv6への移行へのIPv4の文脈で説明したが、すべてのこれらのプロトコルは、リナンバリングに敏感であるかもしれないことは明らかです。実際の実装は、リナンバリングに敏感であるかどうかを分析することにより、仕様を発見する方法がないという点で、しかし、状況は、悪化しています。実際、このような分析は、プロプライエタリなアプリケーションの場合には、非常に不可能かもしれません。
The sensitivity depends on whether the implementation stores IP addresses in such a way that it might refer back to them later, without allowing for the fact that they might no longer be valid. In general, we can assert that any implementation is at risk from renumbering if it does not check that an address is valid each time it opens a new communications session. This could be done, for example, by knowing and respecting the relevant DNS TTL, or by resolving relevant Fully-Qualified Domain Names (FQDNs) again. A common experience is that even when FQDNs are stored in configuration files, they are resolved only once, when the application starts, and they are cached indefinitely thereafter. This is insufficient. Of course, this does not apply to all application software; for example, several well-known web browsers have short default cache lifetimes.
感度は、実施店舗は、彼らはもはや有効ではないかもしれないという事実を考慮しなくて、それが戻って後でそれらを参照するかもしれないような方法でIPアドレスかどうかに依存します。一般的に、我々はすべての実装は、それはアドレスが新しい通信セッションを開くたびに有効であることを確認していない場合はリナンバリングから危険であることを主張することができます。これは、例えば、関連するDNSのTTLを知り、尊重することによって、又は再度関連する完全修飾ドメイン名（FQDN）を解決することによって、行うことができます。一般的な経験は、FQDNでは、コンフィギュレーションファイルに保存されている場合でも、アプリケーションの起動時に、彼らは、一度だけ解決される、と彼らは無期限以降にキャッシュされていることです。これが不十分です。もちろん、これはすべてのアプリケーションソフトウェアには適用されません。例えば、いくつかのよく知られているウェブブラウザは、短いデフォルトのキャッシュ寿命を有します。
There are even more egregious breaches of this principle, for example, software license systems that depend on the licensed host computer having a particular IP address. Other examples are the use of literal IP addresses in URLs, HTTP cookies, or application proxy configurations. (Also see Appendix A.)
特定のIPアドレスを持つライセンスをホストコンピュータに依存し、さらに悪質例えば、この原則の違反、ソフトウェアライセンスシステムがあります。他の例としては、URLでのリテラルIPアドレスの使用、HTTPクッキー、またはアプリケーションプロキシの設定です。 （また、付録Aを参照してください）
In contrast, there are also many application suites that actively deal with connectivity failures by retrying with alternative addresses or by repeating DNS lookups. This places a considerable burden of complexity on application developers.
これとは対照的に、積極的に代替アドレスで再試行するか、DNSルックアップを繰り返すことによって、接続障害を扱う多くのアプリケーションスイートもあります。これは、アプリケーション開発者の複雑さのかなりの負担がかかります。
It should be noted that applications are in effect encouraged to be aware of and to store IP addresses by the very nature of the socket API calls gethostbyname() and getaddrinfo(). It is highly unfortunate that many applications use APIs that require the application to see and use lower-layer objects, such as network-layer addresses. However, the BSD Sockets API was designed and deployed before the Domain Name System (DNS) was created, so there were few good options at the time. This issue is made worse by the fact that these functions do not return an address lifetime, so that applications have no way to know when an address is no longer valid. The extension of the same model to cover IPv6 has complicated this problem somewhat. An application using the socket API is obliged to contain explicit logic if it wishes to benefit from the availability of multiple addresses for a given remote host. If a programming model were adopted in which only FQDNs were exposed to applications, and addresses were cached with appropriate lifetimes within the API, most of these problems would disappear. It should be noted that at least the first part of this is already available for some programming environments. A common example is Java, where only FQDNs need to be handled by application code in normal circumstances, and no additional application logic is needed to deal with multiple addresses, which are handled by the run-time system. This is highly beneficial for programmers who are not networking experts, and insulates applications software from many aspects of renumbering. It would be helpful to have similarly abstract, DNS-oriented, Networking APIs openly specified and widely available for C and C++.
これは、アプリケーションが有効なのを認識すると、ソケットAPIの性質上、IPアドレスを格納することが奨励されていることに留意すべきであるのgethostbyname（）とはgetaddrinfo（）を呼び出します。多くのアプリケーションは、ネットワーク層アドレスとして下層のオブジェクトを参照し、使用するアプリケーションを必要とするAPIを使用することが非常に残念です。しかし、BSDソケットAPIを設計し、ドメインネームシステム（DNS）が作成される前に展開され、その時点でいくつかの良いオプションがありましたました。この問題は、アプリケーションがアドレスが有効でなくなったときに知らない方法がないように、これらの機能は、アドレスの有効期間を返さないという事実によって悪化しています。 IPv6をカバーするために同じモデルの拡張は多少この問題を複雑にしています。ソケットAPIを使用するアプリケーションは、それが特定のリモートホストのための複数のアドレスの可用性の恩恵を受けるしたい場合は、明示的なロジックを含むように義務付けられています。プログラミングモデルのみのFQDNがアプリケーションに公開された採択された、およびアドレスはAPI内の適切な寿命でキャッシュされた場合は、これらの問題のほとんどは消えてしまいます。これの少なくとも最初の部分は、すでにいくつかのプログラミング環境のために利用可能であることに留意すべきです。一般的な例は、唯一のFQDNは、通常の状況でアプリケーションコードによって処理される必要があるJava（登録商標）、であり、そして追加のアプリケーションロジックは、ランタイムシステムによって処理される複数のアドレスに対処するために必要とされません。これは専門家のネットワークされていないプログラマのための非常に有益である、とリナンバリングの多くの側面からのアプリケーションソフトウェアを絶縁します。同様に、抽象、DNS指向、ネットワークAPI公然と指定し、CおよびC ++のために広く利用可能なを持っていると便利だろう。
Some web browsers intentionally violate the DNS TTL with a technique called "DNS Pinning." DNS Pinning limits acceptance of server IP address changes, due to a JavaScript issue where repeated address changes can be used to induce a browser to scan the inside of a firewalled network and report the results to an outside attacker. Pinning can persist as long as the browser is running, in extreme cases perhaps months at a time. Thus, we can see that security considerations may directly damage the ability of applications to deal with renumbering.
一部のWebブラウザは、意図的と呼ばれる手法でDNSのTTLに違反する「DNSピンニング。」 DNS繰り返さアドレスの変更は、ファイアウォール、ネットワークの内部をスキャンし、外部の攻撃者に結果を報告するようにブラウザを誘導するために使用することができますJavaScriptの問題のためにサーバーのIPアドレス変更の制限の受け入れをピン留め。ピニングは、一度、おそらく数ヶ月極端な場合には、限り、ブラウザが実行されているとして存続することができます。したがって、我々は、セキュリティ上の考慮事項が直接リナンバリングに対処するためのアプリケーションの能力に損傷を与える可能性があることがわかります。
Server applications might need to be restarted when the host they contain is renumbered, to ensure that they are listening on a port and socket bound to the new address. In an IPv6 multi-addressed host, server applications need to be able to listen on more than one address simultaneously, in order to cover an overlap during renumbering. Not all server applications are written to do this, and a name-based API as just mentioned would have to provide for this case invisibly to the server code.
それらに含まれるホストが再番号付けされたときにサーバーアプリケーションは、新しいアドレスにバインドされたポートとソケット上で待機していることを確実にするために、再起動が必要になる場合があります。 IPv6のマルチ対処ホストでは、サーバ・アプリケーションは、リナンバリングの際にオーバーラップをカバーするために、同時に複数のアドレスをリッスンできるようにする必要があります。いないすべてのサーバーアプリケーションは、これを実行するために書かれている、と同じくらい言及した名前ベースのAPIは、サーバーのコードに目に見えないこの場合のために提供しなければなりません。
As noted in Section 2.6, the Service Location Protocol (SLP), and multicast DNS with SRV records for service discovery, have been available for some years. For example, many printers deployed in recent years automatically advertise themselves to potential clients via SLP. Many modern client operating systems automatically participate in SLP without requiring users to enable it. These tools appear not to be widely known, although they can be used to reduce the number of places that IP addresses need to be configured.
2.6節で述べたように、サービスロケーションプロトコル（SLP）、およびサービスの発見のためのSRVレコードを持つマルチキャストDNSは、いくつかの年のために利用されてきました。例えば、近年で展開多くのプリンタは自動的にSLP経由で潜在的な顧客に自分自身をアドバタイズします。現代の多くのクライアントオペレーティングシステムが自動的にそれを有効にするために、ユーザーを必要とせずにSLPに参加しています。彼らはIPアドレスを設定する必要がある場所の数を減らすために使用することができますが、これらのツールは、広く知られていない表示されます。
[RFC2072] gives a detailed review of the operational realities in 1997. A number of the issues discussed in that document were the result of the relatively recent adoption of classless addressing; those issues can be assumed to have vanished by now. Also, DHCP was a relative newcomer at that time, and can now be assumed to be generally available. Above all, the document underlines that systematic planning and administrative preparation are needed, and that all forms of configuration file and script must be reviewed and updated. Clearly this includes filtering and routing rules (e.g., when peering with BGP, but also with intradomain routing as well). Two particular issues mentioned in [RFC2072] are:
[RFC2072]はその文書で議論された問題の数は、クラスレスアドレッシングの比較的最近の採択の結果であった1997年に運用実態の詳細なレビューを提供します。これらの問題は、今では消滅したと想定することができます。また、DHCPはその時点で相対的な新人だった、と今で一般的に利用可能であると想定することができます。なかでも、文書には、体系的な計画と管理の準備が必要であることを強調し、設定ファイルやスクリプトのすべての形態を見直し、更新されなければならないということ。明らかに、これは、（例えば、BGPピアリングとするときだけでなく、ドメイン内ルーティングと同様に）フィルタリングおよびルーティング規則を含みます。 [RFC2072]で述べた2つの特定の問題は、次のとおりです。
o Some routers cache IP addresses in some situations. So routers might need to be restarted as a result of site renumbering.
いくつかの状況では一部のルータキャッシュIPアドレス、O。だから、ルータは、サイトリナンバリングの結果として再起動が必要になることがあります。
o Addresses might be used by configured tunnels, including VPN tunnels, although at least the Internet Key Exchange (IKE) supports the use of Fully-Qualified Domain Names instead.
少なくともインターネット鍵交換（IKE）が代わりに完全修飾ドメイン名の使用をサポートしていますが、Oアドレスは、VPNトンネルを含む構成されたトンネルで使用される可能性があります。
On the latter point, the capability to use FQDNs as endpoint names in IPsec VPNs is not new and is standard (see [RFC2407], Section 4.6.2.3 and [RFC4306], Section 3.5). This capability is present in most IPsec VPN implementations. There does seem to be an "educational" or "awareness" issue that many system/network administrators do not realise that it is there and works well as a way to avoid manual modification during renumbering. (Of course, even in this case, a VPN may need to be reconnected after a renumbering event, but most products appear to handle this automatically.)
IPsec VPNのエンドポイント名は新しいものではなく、標準的であるように、後者の点については、機能はのFQDNを使用する（参照[RFC2407]、セクション4.6.2.3および[RFC4306]、セクション3.5）。この機能は、ほとんどのIPsec VPNの実装に存在しています。多くのシステム/ネットワーク管理者は、それがあるとリナンバリング時に手動で変更を回避する方法としてうまく機能していることに気付いていないことを「教育」や「意識」の問題があるように思えるん。 （もちろん、この場合でも、VPNはリナンバリングイベント後に再接続する必要があるかもしれないが、ほとんどの製品は、これを自動的に処理するために表示されます。）
In IPv6, if a site wanted to be multihomed using multiple provider-aggregated (PA) routing prefixes with one prefix per upstream provider, then the interior routers would need a mechanism to learn which upstream providers and prefixes were currently reachable (and valid). In this case, their Router Advertisement messages could be updated dynamically to only advertise currently valid routing prefixes to hosts. This would be significantly more complicated if the various provider prefixes were of different lengths or if the site had non-uniform subnet prefix lengths.
サイトには、上流プロバイダごとに1つのプレフィックスで複数のプロバイダ凝集（PA）のルーティングプレフィックスを使用してマルチホームになりたい場合はIPv6では、その後、内部ルータは、上流プロバイダとプレフィックスが現在到達可能（かつ有効）したかを学習するためのメカニズムが必要になります。この場合、そのルータ通知メッセージは、ホストだけに、現在有効なルーティングプレフィックスを広告に動的に更新することができます。さまざまなプロバイダプレフィックスが異なる長さであったかのサイトには、不均一なサブネットプレフィックスの長さを持っていた場合なら、これははるかに複雑になります。
When a renumbering event takes place, entries in the state table of any Network Address Translator that happen to contain the affected addresses will become invalid and will eventually time out. Since TCP and UDP sessions are unlikely to survive renumbering anyway, the hosts involved will not be additionally affected. The situation is more complex for multihomed SCTP [SCTPNAT], depending on whether a single or multiple NATs are involved.
リナンバリングイベントが発生すると、影響を受けたアドレスを含むように起こる任意のネットワークアドレス変換の状態テーブルのエントリは無効になり、最終的にタイムアウトします。 TCPおよびUDPセッションがとにかくリナンバリング生き残る可能性は低いので、関係するホストがさらに影響を受けません。状況は、単一または複数のNATが関与しているかどうかに応じて、[SCTPNAT]マルチホームSCTPのために、より複雑です。
A NAT itself might be renumbered and might need a configuration change during a renumbering event. One of the authors has a NAT-enabled home gateway that obtains its exterior address from the residential Internet service provider by acting as a DHCP client. That deployment has not suffered operational problems when the ISP uses DHCP to renumber the gateway's exterior IP address. A critical part of that success has been configuring IKE on the home gateway to use a "mailbox name" for the user's identity type (rather than using the exterior IP address of the home gateway) when creating or managing the IP Security Associations.
NAT自体の番号が変更される可能性がありますし、リナンバリングイベント中に設定変更が必要になることがあります。著者の一人は、DHCPクライアントとして作用することにより、住宅のインターネットサービスプロバイダーからその外側のアドレスを取得し、NAT対応ホームゲートウェイを持っています。 ISPは、ゲートウェイの外部IPアドレスの番号を変更するためにDHCPを使用する場合、その展開は、操作上の問題に見舞われていません。その成功の重要な部分は、IPセキュリティアソシエーションを作成または管理する場合、ユーザーの身元タイプの「メールボックス名」（というよりも、ホームゲートウェイの外部IPアドレスを使用して）を使用するホームゲートウェイ上でIKEを設定されています。
A mobile node using Mobile IP that is not currently in its home network will be adversely affected if either its current care-of address or its home address is renumbered. For IPv6, if the care-of address changes, this will be exactly like moving from one foreign network to another, and Mobile IP will re-bind with its home agent in the normal way. If its home address changes unexpectedly, it can be informed of the new global routing prefix used at the home site through the Mobile Prefix Solicitation and Mobile Prefix Advertisement ICMPv6 messages [RFC3775]. The situation is more tricky if the mobile node is detached at the time of the renumbering event, since it will no longer know a valid subnet anycast address for its home agent, leaving it to deduce a valid address on the basis of DNS information.
その現在の気付アドレスのいずれかまたはそのホームアドレスは番号が付け直されている場合、そのホームネットワーク内に現在いないモバイルIPを使用して、モバイルノードが悪影響を受けることになります。 IPv6の場合、気付アドレスが変更された場合、これは正確に別の外部ネットワークから移動するようになり、モバイルIPは、通常の方法でそのホームエージェントとのバインドを再します。そのホームアドレスが予期せず変更された場合、それはモバイルプレフィックス要請およびモバイルプレフィックス広告ICMPv6メッセージ[RFC3775]を通じて自宅のサイトで使用される新しいグローバルルーティングプレフィックスを知ることができます。それはもはやDNS情報に基づいて有効なアドレスを推測するためにそれを残して、そのホームエージェントのための有効なサブネットエニーキャストアドレスを知っているので、モバイルノードは、リナンバリングイベントの時に切り離されていない場合、状況はより複雑です。
In contrast to Mobile IPv6, Mobile IPv4 does not support prefix solicitation and prefix advertisement messages, limiting its renumbering capability to well-scheduled renumbering events when the mobile node is connected to its home agent and managed by the home network administration. Unexpected home network renumbering events when the mobile node is away from its home network and not connected to the home agent are supported only if a relevant Authentication, Authorisation, and Accounting (AAA) system is able to allocate dynamically a home address and home agent for the mobile node.
モバイルIPv6とは対照的に、モバイルIPv4は、モバイルノードがそのホームエージェントに接続し、ホームネットワーク管理によって管理されている場合だけでなく、スケジュールされたリナンバリングイベントへのリナンバリング機能を制限し、接頭辞の勧誘とプレフィックス広告メッセージをサポートしていません。予期しないホームネットワークモバイルノードがそのホームネットワークから離れているときにイベントをリナンバリングとホームエージェントに接続されていないが、関連する認証、許可、アカウンティング（AAA）システムが動的ホームアドレスおよびホームエージェントを割り当てることができる場合にのみサポートされていますモバイルノード。
As discussed in [THINK], IPv6 multicast can be used to help rather than hinder renumbering, for example, by using multicast as a discovery protocol (as in IPv6 Neighbour Discovery). On the other hand, the embedding of IPv6 unicast addresses into multicast addresses specified in [RFC3306] and the embedded-RP (Rendezvous Point) in [RFC3956] will cause issues when renumbering.
【THINK]で説明したように、IPv6マルチキャストは、例えば、（IPv6の近隣探索の場合のように）発見プロトコルとしてマルチキャストを使用して、リナンバリングを助けるよりもむしろ妨げるために使用することができます。一方、[RFC3306]で指定されたマルチキャストアドレスおよび埋め込み-RP [RFC3956]に（ランデブーポイント）にIPv6ユニキャストアドレスの埋め込みはリナンバリングの問題を引き起こすであろう。
For both IPv4 and IPv6, changing the unicast source address of a multicast sender might also be an issue for receivers, especially for Source-Specific Multicast (SSM). Applications need to learn the new source addresses and new multicast trees need to be built
IPv4とIPv6の両方のために、マルチキャスト送信側のユニキャスト送信元アドレスを変更することは、特にソース固有マルチキャスト（SSM）のために、受信機のための問題であるかもしれません。アプリケーションは、新しい送信元アドレスを学習する必要があり、新たなマルチキャストツリーを構築する必要があります
For IPv4 or IPv6 with Any-Source Multicast (ASM), renumbering can be easy. If sources are renumbered, from the routing perspective, things behave just as if there are new sources within the same multicast group. There may be application issues though. Changing the RP address is easy when using Bootstrap Router (BSR) [RFC5059] for dynamic RP discovery. BSR is widely used, but it is also common to use static config of RP addresses on routers. In that case, router configurations must be updated too.
どれ-ソースマルチキャスト（ASM）とのIPv4またはIPv6の場合は、リナンバリングを簡単にすることができます。ソースは、ルーティングの観点から、付け直されている場合、物事は同じマルチキャストグループ内の新しいソースがあるかのように振る舞います。しかしアプリケーションの問題があるかもしれません。ダイナミックRPの発見のためのブートストラップルータ（BSR）[RFC5059]を使用するときにRPアドレスを変更するのは簡単です。 BSRは、広く使用されているが、また、ルータ上でRPアドレスの静的な設定を使用するのが一般的です。その場合には、ルータの設定も更新する必要があります。
If any multicast ACLs are configured, they raise the same issue as unicast ACLs mentioned elsewhere.
任意のマルチキャストACLが設定されている場合、彼らは他の場所で言及したユニキャストのACLと同じ問題を提起します。
Today, static IP addresses are routinely embedded in numerous configuration files and network management databases, including MIB modules. Ideally, all of these would be generated from a single central asset management database for a given site, but this is far from being universal practice. It should be noted that for IPv6, where multiple routing prefixes per interface and multiple addresses per interface are standard practice, the database and the configuration files will need to allow for this (rather than for a single address per host, as is normal practice for IPv4).
今日では、静的IPアドレスが日常MIBモジュールを含む多数の設定ファイルやネットワーク管理データベース、中に埋め込まれています。理想的には、これらの全ては、特定のサイトのための単一の中央資産管理データベースから生成されるであろうが、これは普遍的な練習には程遠いです。のために、通常の慣行であるとして、インターフェイスごとに複数のルーティングプレフィックスとインターフェイスごとに複数のアドレスが標準的ですIPv6のために、データベースおよび設定ファイルは、このために（というよりもホストごとに単一のアドレスを許可する必要がありますことに留意すべきですIPv4の）。
Furthermore, because of routing policies and VPNs, a site or network might well embed addresses from other sites or networks in its own configuration data. (It is preferable to embed FQDNs instead, of course, whenever possible.) Thus, renumbering will cause a ripple effect of updates for a site and for its neighbours. To the extent that these updates are manual, they will be costly and prone to error. Synchronising updates between independent sites can cause unpredictable delays. Note that Section 4 suggests that IPv6 ULAs can mitigate this problem, but of course only for VPNs and routes that are suitable for ULAs rather than globally routeable addresses. The majority of external addresses to be configured will not be ULAs.
さらに、ため、ルーティングポリシーおよびVPNの、サイトまたはネットワークが十分に独自の構成データの他のサイトやネットワークからのアドレスを埋め込むことがあります。 （それはもちろん、可能な限り、代わりのFQDNを埋め込むことが望ましい。）このように、リナンバリングは、サイトとその隣人のための更新プログラムの波及効果が発生します。これらのアップデートは手動であることを限り、彼らはコストがかかり、エラーを起こしやすいだろう。独立したサイト間の更新を同期すると、予測不可能な遅延を引き起こす可能性があります。その第4節では、IPv6 ULAsはもちろんの唯一のVPNとルートULAsに適しているのではなく、グローバルにルーティング可能なアドレスのため、この問題を軽減できることを示唆している注意してください。設定するための外部アドレスの大半はULAsではありません。
See Appendix A for an extended list of possible static or embedded addresses.
可能な静的または埋め込まれたアドレスの拡張リストについては、付録Aを参照してください。
Some address configuration data are relatively easy to find (for example, site firewall rules, ACLs in site border routers, and DNS). Others might be widely dispersed and much harder to find (for example, configurations for building routers, printer addresses configured by individual users, and personal firewall configurations). Some of these will inevitably be found only after the renumbering event, when the users concerned encounter a problem.
いくつかのアドレス構成データを見つけるのは比較的容易である（例えば、サイトのファイアウォールルール、サイトの境界ルータ、およびDNSでのACL）。その他、広く分散して見つけるのが非常に難しいかもしれません（例えば、建物のルータの設定は、プリンタのアドレスは、個々のユーザー、およびパーソナルファイアウォールの設定によって構成されました）。該当するユーザーは、問題が発生したときに、これらのいくつかは、必然的に、唯一のリナンバリングイベント後に発見されます。
The overlapped model for IPv6 renumbering, with old and new addresses valid simultaneously, means that planned database and configuration file updates will proceed in two stages -- add the new information some time before the renumbering event, and remove the old information some time after. All policy rules must be configured to behave correctly during this process (e.g., preferring the new address as soon as possible). Similarly, monitoring tools must be set up to monitor both old and new during the overlap.
リナンバリングイベントの前に、新たな情報にいくつかの時間を追加し、いくつかの時間後に古い情報を削除 - IPv6のリナンバリングのための重複モデルは、同時に有効な古いものと新しいアドレスで、計画データベースと設定ファイルの更新は2つの段階で進行することを意味します。すべてのポリシールールは、（例えば、できるだけ早く新しいアドレスを好む）このプロセスの中に正しく動作するように設定する必要があります。同様に、監視ツールは、オーバーラップの間に古いものと新しいものの両方を監視するように設定する必要があります。
However, it should be noted that the notion of simultaneously operating multiple prefixes for the same network, although natural for IPv6, is generally not supported by operational tools such as address management software. It also increases the size of IGP routing tables in proportion to the number of prefixes in use. For these reasons, and due to its unfamiliarity to operational staff, the use of multiple prefixes remains rare. Accordingly, the use of ULAs to provide stable on-site addresses even if the off-site prefix changes is also rare.
しかし、それは注意すべきことは、同じネットワークに同時に動作する複数のプレフィックスの概念、IPv6のための自然なものの、一般的にこのようなアドレス管理ソフトウェアなどの運用ツールでサポートされていません。それはまた、使用中のプレフィクスの数に比例してIGPルーティングテーブルのサイズを増大させます。これらの理由から、とによる運用スタッフへの不慣れに、複数のプレフィックスを使用することは珍しいのまま。したがって、オンサイトでの安定提供するために、ULAsの使用は、オフサイトのプレフィックスの変更も稀であったとしても対処しています。
If both IPv4 and IPv6 are renumbered simultaneously in a dual-stack network, additional complications could result, especially with configured IP-in-IP tunnels. This scenario should probably be avoided.
IPv4とIPv6の両方がデュアルスタックネットワークに同時に再番号付けされている場合は、追加の合併症は特に設定されたIP-で-IPトンネルで、可能性があります。このシナリオでは、おそらく避けるべきです。
Use of FQDNs rather than raw IP addresses wherever possible in configuration files and databases will reduce/mitigate the potential issues arising from such configuration files or management databases when renumbering is required or otherwise occurs. This is advocated in [RFC1958] (point 4.1). Just as we noted in Section 5.1.4 for applications, this is insufficient in itself; some devices such as routers are known to only resolve FQDNs once, at start-up, and to continue using the resulting addresses indefinitely. This may require routers to be rebooted, when they should instead be resolving the FQDN again after a given timeout.
FQDNではなく、生のIPアドレス可能な限り、構成ファイルとデータベース内の使用が低減/リナンバリングが必要な場合に、このようなコンフィギュレーションファイルまたは管理データベースから生じる潜在的な問題を軽減するか、そうでない場合に発生します。これは[RFC1958]（点4.1）で提唱されています。我々はアプリケーションのためのセクション5.1.4で述べたのと同じように、これは、それ自体では不十分です。ルータなど一部のデバイスでのみ起動時に、一回のFQDNを解決するために、無期限たアドレスを引き続き使用することが知られています。これは、彼らが代わりに与えられたタイムアウト後、再びFQDNを解決しなければならないとき、ルータは、再起動が必要な場合があります。
By definition, there is at least one place (i.e., the DNS zone file or the database from which it is derived) where address information is nevertheless inevitable.
定義により、少なくとも一箇所がある（すなわち、DNSゾーンファイル、またはそれが由来するデータベース）アドレス情報がそれにもかかわらず、不可避です。
It is also possible that some operators may choose to configure addresses rather than names, precisely to avoid a possible circular dependency and the resulting failure modes. This is arguably even advocated in [RFC1958] (point 3.11).
いくつかの事業者が可能循環依存関係と結果の故障モードを避けるために、正確に、アドレスではなく名前を設定することを選択することも可能です。これは間違いなくても、[RFC1958]（点3.11）で提唱されています。
It should be noted that the management and administration issues (i.e., tracking down, recording, and updating all instances where addresses are stored rather than looked up dynamically) form the dominant concern of managers considering the renumbering problem. This has led many sites to continue the pre-CIDR (Classless Inter-Domain Routing) approach of using a provider-independent (PI) prefix. Some sites, including very large corporate networks, combine PI addressing with NAT. Others have adopted private addressing and NAT as a matter of choice rather than obligation. This range of techniques allows for addressing plans that are independent of the ISP(s) in use, and allows a straightforward approach to multihoming. The direct cost of renumbering is perceived to exceed the indirect costs of these alternatives. Additionally, there is a risk element stemming from the complex dependencies of renumbering: it is hard to be fully certain that the renumbering will not cause unforeseen service disruptions, leading to unknown additional costs.
経営管理上の問題（すなわち、追跡記録、及びアドレスが格納されているのではなく、動的に検索され、すべてのインスタンスを更新する）はリナンバリングの問題を考慮して管理者の支配的な懸念を形成することに留意すべきです。これは、事前にCIDR（クラスレスドメイン間ルーティング）プロバイダに依存しない（PI）の接頭辞を使用してのアプローチを継続するために多くのサイトをリードしてきました。非常に大規模な企業ネットワークを含むいくつかのサイトでは、NATでアドレス指定のPIを兼ね備えています。その他は選択ではなく義務の問題として取り組む民間とNAT採用しています。技術のこの範囲は、使用中のISP（S）から独立している計画に対処することができますし、マルチホーミングへの直接的なアプローチを可能にします。リナンバリングの直接費用は、これらの選択肢の間接的なコストを超えて知覚されます。また、リナンバリングの複雑な依存関係から生じるリスクの要素があります：リナンバリングが不明な追加コストにつながる、不測のサービス中断が発生しないことを完全に特定することは困難です。
A relevant example in a corporate context is VPN configuration data held in every employee laptop, for use while on travel and connecting securely from remote locations. Typically, such VPNs are statically configured using numeric IP addresses for endpoints and even with prefix lists for host routing tables. Use of VPN configurations with FQDNs to name fixed endpoints, such as corporate VPN gateways, and with non-address identity types would enable existing IP Security with IKE to avoid address renumbering issues and work well for highly mobile users. This is all possible today with standard IPsec and standard IKE. It just requires VPN software to be configured with names instead of addresses, and thoughtful network administration.
企業コンテキスト内の関連する例は、VPN構成データが旅行にしながら使用するために、すべての従業員のラップトップに保持され、遠隔地から確実に接続しています。典型的に、このようなVPNは、静的エンドポイントのために、さらにはホストルーティングテーブルのためのプレフィクスリストと数値のIPアドレスを使用して構成されています。このような企業のVPNゲートウェイなどの固定のエンドポイントに名前を付けるのFQDNと、非アドレスアイデンティティタイプのVPN設定を使用すると、アドレスのリナンバリングの問題を回避し、非常にモバイルユーザーのためにうまく動作するようにIKEを持つ既存のIPセキュリティを可能にします。これは、標準IPsecとIKE標準で今日のすべての可能性です。それはちょうど名前の代わりに、アドレス、思いやりのネットワーク管理を設定するVPNソフトウェアが必要です。
It should be noted that site and network operations managers are often very conservative, and reluctant to change operational procedures that are working reasonably well and are perceived as reasonably secure. They quite logically argue that any change brings with it an intrinsic risk of perturbation and insecurity. Thus, even if procedural changes are recommended that will ultimately reduce the risks and difficulties of renumbering (such as using FQDNs protected by DNSsec where addresses are used today), these changes might be resisted.
サイトとネットワークの運用管理者は、多くの場合、非常に保守的、かつ合理的にうまく機能していると合理的に安全なとして認識されている操作手順を変更するには消極的であることに留意すべきです。彼らは非常に論理的にどんな変化がそれを摂動と不安の本質的なリスクをもたらすと主張しています。このように、手順の変更が最終的に（そのようなアドレスは、今日使用されているDNSSECで保護さのFQDNを使用するなど）、リナンバリングのリスクや困難を軽減することが推奨されている場合でも、これらの変更は抵抗している可能性があります。
For IPv6, addresses are intended to be protected against forgery during neighbour discovery by SEcure Neighbour Discovery (SEND) [RFC3971]. This appears to be a very useful precaution during dynamic renumbering, to prevent hijacking of the process by an attacker. Any automatic renumbering scheme has a potential exposure to such hijacking at the moment that a new address is announced. However, at present it is unclear whether or when SEND might be widely implemented or widely deployed.
IPv6の場合、アドレスは、セキュア近隣探索（SEND）[RFC3971]で近隣探索中に偽造から保護することを意図しています。これは、攻撃者によって、プロセスのハイジャックを防ぐために、ダイナミックリナンバリングの際に非常に便利な予防策であるように思われます。任意の自動リナンバリングスキームは、新しいアドレスが発表された瞬間に、このようなハイジャックへの潜在的なエクスポージャーを持っています。しかし、現状では、SENDが広く実装または広く展開されることがありますかどうかは不明であるとき。
Firewall rules will certainly need to be updated, and any other cases where addresses or address prefixes are embedded in security components (access control lists, AAA systems, intrusion detection systems, etc.). If this is not done in advance, legitimate access to resources might be blocked after the renumbering event. If the old rules are not removed promptly, illegitimate access might be possible after the renumbering event. Thus, the security updates will need to be made in two stages (immediately before and immediately after the event).
ファイアウォールのルールは確かに更新する必要があり、アドレスまたはアドレスプレフィックスは、セキュリティコンポーネント（アクセス制御リスト、AAAシステム、侵入検知システムなど）に埋め込まれている他の例でしょう。これは、事前に行われていない場合は、リソースへの正当なアクセスがリナンバリングイベントの後にブロックされる可能性があります。古いルールは速やかに削除されていない場合は、違法なアクセスがリナンバリングイベントの後に可能かもしれません。このように、セキュリティ更新プログラムは、（イベントの直前と直後）二段階で行われる必要があります。
There will be operational and security issues if an X.509v3 Public Key Infrastructure (PKI) Certificate includes a subjectAltName extension that contains an iPAddress [RFC5280], and if the corresponding node then undergoes an IP address change without a concurrent update to the node's PKI Certificate. For these reasons, use of the dNSName rather than the iPAddress is recommended for the subjectAltName extension. Any other use of IP addresses in cryptographic material is likely to be similarly troublesome.
X.509v3公開鍵インフラストラクチャ（PKI）証明書がIPアドレス[RFC5280]を含んでいるsubjectAltName拡張が含まれている場合、対応するノードは、そのノードのPKIへの同時更新せずにIPアドレスの変更を受ける場合運用とセキュリティの問題があるでしょう証明書。これらの理由から、むしろIPアドレス以外のdNSNameの使用はsubjectAltName拡張のために推奨されます。暗号材料におけるIPアドレスのいずれかの他の使用は、同様に面倒である可能性が高いです。
If a site is, for some reason, listed by IP address in a white list (such as a spam white list), this will need to be updated. Conversely, a site that is listed in a black list can escape that list by renumbering itself.
サイトは、何らかの理由で、（そのようなスパムホワイトリストなど）ホワイトリストにあるIPアドレスで表示されている場合、これを更新する必要があります。逆に、ブラックリストに記載されているサイトには、自分自身をリナンバリングすることによって、そのリストを逃れることができます。
The use of IP addresses instead of FQDNs in configurations is sometimes driven by a perceived security need. Since the name resolution process has historically lacked authentication, administrators prefer to use raw IP addresses when the application is security sensitive (firewalls and VPN are two typical examples). It might be possible to solve this issue in the next few years with DNSsec (see Section 2.5), now that there is strong DNS Security deployment momentum.
IPを使用すると、アドレスの代わりの構成でのFQDNは時々、知覚セキュリティの必要性によって駆動されます。名前解決処理は、歴史的に認証を欠いているので、管理者は、アプリケーションがセキュリティ（ファイアウォール及びVPNは、2つの典型的な例である）に敏感である場合、生のIPアドレスを使用することを好みます。強力なDNS Security展開の勢いがあることを、今、DNSSEC（2.5節を参照）で、今後数年でこの問題を解決することができるかもしれません。
SHIM6, proposed as a host-based multihoming mechanism for IPv6, has the property of dynamically switching the addresses used for forwarding the actual packet stream while presenting a constant address as the upper-layer identifier for the transport layer [RFC5533]. At least in principle, this property could be used during renumbering to alleviate the problem described in Section 5.1.2.
IPv6のホストベースのマルチホーミングメカニズムとして提案SHIM6は、動的輸送層[RFC5533]のための上位層識別子として一定のアドレスを提示しながら、実際のパケットストリームを転送するために使用されるアドレスをスイッチング特性を有します。少なくとも原理的には、このプロパティは、セクション5.1.2で説明した問題を軽減するためにリナンバリングの際に使用することができます。
SHIM6 is an example of a class of solutions with this or a similar property; others are Host Identity Protocol (HIP), IKEv2 Mobility and Multihoming (MOBIKE), Mobile IPv6, SCTP, and proposals for multi-path TCP.
SHIM6この又は類似の性質を有する溶液のクラスの例です。他の人がホスト識別プロトコル（HIP）、IKEv2のモビリティとマルチホーミング（MOBIKE）、モバイルIPv6、SCTP、およびマルチパスTCPの提案です。
The IETF working groups dealing with mobile ad hoc networks have been working on a number of mechanisms for mobile routers to discover available border routers dynamically, and for those mobile routers to be able to communicate that information to hosts connected to those mobile routers.
モバイルアドホックネットワークを扱うIETFワーキンググループは、動的に利用可能な境界ルータを発見するために、モバイルルータのための機構の数に取り組んできており、それらのモバイルルータのためのものモバイルルータに接続されたホストにその情報を伝達できるようにします。
Recently, some MANET work has appeared on a "Border Router Discovery Protocol (BRDP)" that might be useful work towards a more dynamic mechanism for site interior router renumbering [BRDP].
最近、いくつかのMANET作業は[BRDP]リナンバリングサイト内部ルータのための、よりダイナミックなメカニズムに向けて有用な作業かもしれません「境界ルータ検出プロトコル（BRDP）」に出演しています。
At present, the IETF AUTOCONF WG (http://www.ietf.org/html.charters/autoconf-charter.html) is working on address autoconfiguration mechanisms for MANET networks that also seem useful for ordinary non-mobile non-MANET networks [AUTOC]. This work is extensively surveyed in [AUTOC2] and [AUTOC3]. Other work in the same area, e.g., [RFC5558], might also be relevant.
現時点では、IETF AUTOCONF WG（http://www.ietf.org/html.charters/autoconf-charter.html）は、通常の非モバイル非MANETネットワークのための便利なように見えるMANETネットワークのためのアドレス自動設定メカニズムに取り組んでいます【AUTOC]。この作品は広範囲に[AUTOC3] [AUTOC2]に調査しています。同じ領域内の他の作業、例えば、[RFC5558]は、また、関連するかもしれません。
MANETs are, of course, unusual in that they must be able to reconfigure themselves at all times and without notice. Hence, the type of hidden static configurations discussed above in Section 5.3.4 are simply intolerable in MANETs. Thus, it is possible that when a consensus is reached on autoconfiguration for MANETs, the selected solution(s) might not be suitable for the more general renumbering problem. However, it is certainly worthwhile to explore applying techniques that work for MANETs to conventional networks also.
アドホックネットワークにおけるはもちろん、珍しいことに、彼らはすべての回で、予告なしに自分自身を再構成することができなければならない、です。したがって、セクション5.3.4で上述の隠された静的構成のタイプは、アドホックネットワークにおける内単に耐え難いあります。したがって、コンセンサスは、アドホックネットワークにおけるための自動設定に達したとき、選択された溶液（s）が、より一般的なリナンバリング問題に適していない可能性があることが可能です。しかし、また、従来のネットワークへのアドホックネットワークにおける適用のために働く技術を探求するために、確かに価値があります。
A DHCPv6 extension has been proposed that could convey alternative routes, in addition to the default router address, to IPv6 hosts [DHRTOPT]. Other DHCP options are also on the table that may offer information about address prefixes and routing to DHCP or DHCPv6 clients, such as [DHSUBNET] and [DHMIFRT]. It is conceivable that these might be extended as a way of informing hosts dynamically of prefix changes.
DHCPv6の拡張は、IPv6に[DHRTOPT】ホスト、デフォルトルータのアドレスに加えて、代替ルートを伝えることができることが提案されています。他のDHCPオプションは、[DHSUBNET]として、DHCPまたはDHCPv6のクライアントにアドレスプレフィックスとルーティングに関する情報を提供することができるテーブルの上にもあり、[DHMIFRT]。これらはプレフィックス変更の動的ホストに通知する方法として拡張されるかもしれないと考えられます。
In the area of management tools, Network Configuration (NETCONF) Protocol [RFC4741] is suitable for the configuration of any network element or server, so could in principle be used to support secure remote address renumbering.
管理ツールの分野では、ネットワーク設定（NETCONF）プロトコル[RFC4741]は、任意のネットワーク要素やサーバの設定に適していますので、原則的に安全なリモートアドレスリナンバリングをサポートするために使用することができます。
The DNSOP WG has considered a Name Server Control Protocol (NSCP) based on NETCONF that provides means for consistent DNS management including potential host renumbering events [DNSCONT].
DNSOP WGは、潜在的なホストリナンバリングイベント[DNSCONT]を含む一貫性のあるDNS管理のための手段を提供NETCONFに基づいてネームサーバー制御プロトコル（NSCP）と考えられています。
A proposal has been made to include an address lifetime as an embedded field in IPv6 addresses, with the idea that all prefixes would automatically expire after a certain period and become unrouteable [CROCKER]. While this might be viewed as provocative, it would force the issue by making renumbering compulsory.
提案はすべてのプレフィックスが自動的に一定期間後に期限切れとなるルーティングできないという考え[CROCKER]で、IPv6アドレスに埋め込まれたフィールドとしてアドレス寿命が含まれるようになされています。これは挑発的と見れるかもしれないが、それは義務をリナンバリングすることによって、問題を強制します。
This section seeks to identify technology gaps between what is available from existing open specifications and what appears to be needed for site renumbering to be tolerable.
このセクションでは、既存のオープンな仕様と何許容するリナンバリングサイトのために必要とされるように見えるから利用可能なものとの技術格差を特定しようとしています。
It would be beneficial to expose address lifetimes in the socket API, or any low-level networking API. This would allow applications to avoid using stale addresses.
ソケットAPIのアドレスの寿命、または任意の低レベルのネットワークAPIを公開することは有益であろう。これにより、アプリケーションは古いアドレスを使用しないようにできるようになります。
The various current discussions of a name-based transport layer or a name-based network API also have potential to alleviate the application-layer issues noted in this document. Application development would be enhanced by the addition of a more abstract network API that supports the C and C++ programming languages. For example, it could use FQDNs and Service Names, rather than SockAddr, IP Address, protocol, and port number. This would be equivalent to similar interfaces already extant for Java programmers.
名前ベースのトランスポート層または名前ベースのネットワークAPIの様々な現在の議論も、この文書で述べたアプリケーション層の問題を緩和する可能性を秘めています。アプリケーション開発は、CやC ++プログラミング言語をサポートし、より抽象的なネットワークAPIの添加によって強化されるだろう。例えば、それはのFQDN名とサービス名ではなく、SOCKADDR、IPアドレス、プロトコル、およびポート番号を使用することができます。これは、Javaプログラマのためのすでに現存同様のインターフェースに相当します。
Moving to a FQDN-based transport layer might enhance the ability to migrate the IP addresses of endpoints for TCP/UDP without having to interrupt a session, or at least in a way that allows a session to restart gracefully.
FQDNベースのトランスポート層に移動すると、セッションを中断することなく、あるいは少なくともセッションが正常に再起動することを可能にする方法で、TCP / UDPのためのエンドポイントのIPアドレスを移行する能力を高める可能性があります。
Having a single registry per host for all address-based configuration (/etc/hosts, anyone?), with secure access for site network management, might be helpful. Ideally, this would be remotely configurable, for example, leveraging the IETF's current work on networked-device configuration protocols (NetConf). While there are proprietary versions of this approach, sometimes based on Lightweight Directory Access Protocol (LDAP), a fully standardised approach seems desirable.
すべてのアドレスベースの設定のためにホストごとに単一のレジストリを持つ（/ etc / hostsには、誰が？）、サイトのネットワーク管理のための安全なアクセスと、役に立つかもしれません。理想的には、これは、ネットワーク・デバイス・コンフィギュレーションプロトコル（NETCONF）にIETFの現在の仕事を活用する、例えば、遠隔で構成可能であろう。時々のLDAP（Lightweight Directory Access Protocol）に基づいて、このアプローチの独自のバージョンが、ありますが、完全に標準化されたアプローチが望ましいと思われます。
Do we really need more than DHCP or SLAAC for regular hosts? Do we need an IPv4 equivalent of SLAAC? How can the use of DHCP FORCERENEW and DHCPv6 RECONFIGURE for bulk renumbering be deployed? FORCERENEW in particular requires DHCP authentication [RFC3118] to be deployed.
私たちは本当に正規のホスト用のDHCPまたはSLAAC以上が必要ですか？我々はSLAACのIPv4の同等物を必要ですか？ DHCP FORCERENEWとバルクリナンバリングのためのDHCPv6 RECONFIGUREの使用がどのように展開することができますか？特にFORCERENEWは、DHCP認証[RFC3118]を展開することが必要です。
The IETF should resolve the 'IPv6 ND M/O flag debate' once and for all, with default, mandatory and optional behaviours of hosts being fully specified.
IETFは、デフォルトでは、完全に指定されたホストの必須およびオプションの振る舞いと「IPv6のND M / Oフラグ論争」一度、すべてのために、解決する必要があります。
The host behaviour for upstream link learning suggested in Section 2.3 should be documented.
上流のリンク学習のためのホストの動作は2.3節で提案文書化する必要があります。
It would be helpful to have multi-path, survivable, extensions for both UDP and TCP (or institutionalise some aspects of SHIM6).
UDPとTCPの両方のためのマルチパス、存続、拡張子を持つことが役に立つこと（またはSHIM6のいくつかの側面を制度）です。
A non-proprietary secure mechanism to allow all address-based configuration to be driven by a central repository for site configuration data. NETCONF might be a good starting point.
サイト構成データの中央リポジトリによって駆動されるように、すべてのアドレスベースの設定を可能にする非独占セキュアなメカニズム。 NETCONFは良い出発点かもしれません。
A MANET solution that's solid enough to apply to fully operational small to medium fixed sites for voluntary or involuntary renumbering.
自発的または非自発的なリナンバリングのための媒体固定サイトに完全に動作小型に適用するのに十分な固体だMANETソリューション。
A MANET-style solution that can be applied convincingly to large or very large sites for voluntary renumbering.
自主的なリナンバリングのための大規模または非常に大規模なサイトに説得力を適用することができMANETスタイルのソリューション。
A useful short-term measure would be to ensure that [RFC2894] and [RFC3633] can be used in practice.
有用な短期の測定値は[RFC2894]及び[RFC3633]は、実際に使用することができることを保証することであろう。
Since address changes are usually communicated via the DNS, the latter's security is essential for secure renumbering. Thus, we should continue existing efforts to deploy DNSsec globally, including not only signing the DNS root, DNS TLDs, and subsidiary DNS zones, but also widely deploying the already available DNSsec-capable DNS resolvers.
アドレスの変更は通常、DNSを介して伝達されているので、後者のセキュリティは安全なリナンバリングのために不可欠です。したがって、我々は唯一のDNSルート、DNSのTLD、および子会社のDNSゾーンに署名するだけでなく、広く既に利用可能なDNSSEC対応のDNSリゾルバを展開していないなど、世界的にDNSSECを導入するための努力を、既存の継続すべきです。
Similarly, we should document and encourage widespread deployment of Secure Dynamic DNS Update both in DNS servers and also in both client and server operating systems. This capability is already widely implemented and widely available, but it is not widely deployed at present.
同様に、我々は文書化し、DNSサーバでもクライアントとサーバの両方のオペレーティングシステムの両方のセキュリティで保護された動的DNS更新の広範な展開を奨励すべきです。この機能は、すでに広く実装され、広く利用可能であるが、それは、現在広く展開されていません。
Deploy multi-prefix usage of IPv6, including Unique Local Addresses (ULAs) to provide stable internal addresses. In particular, address management tools need to support the multi-prefix model and ULAs.
安定した内部アドレスを提供するために、ユニークローカルアドレス（ULAs）を含めたIPv6のマルチプレフィックスの使用量を、展開します。具体的には、アドレス管理ツールは、マルチプレフィックスモデルとULAsをサポートする必要があります。
Ensure that network monitoring systems will function during renumbering, in particular to confirm that renumbering has completed successfully or that some traffic is still using the old prefixes.
特にそのリナンバリングが正常に完了したか、一部のトラフィックはまだ古い接頭辞を使用していることを確認するために、そのネットワーク監視システムがリナンバリング時に機能します確認してください。
Document and encourage systematic site databases and secure configuration protocols for network elements and servers (e.g., NETCONF). The database should store all the information about the network; scripts and tools should derive all configurations from the database. An example of this approach to simplify renumbering is given at [LEROY].
ドキュメントと体系的なサイトのデータベースとネットワーク要素とサーバ（例えば、NETCONF）のための安全なコンフィギュレーションプロトコルを奨励します。データベースには、ネットワークに関するすべての情報を保存する必要があります。スクリプトとツールは、データベースからすべての構成を導き出す必要があります。リナンバリングを簡素化するために、このアプローチの例は、[LEROY]で与えられます。
Document functional requirements for site renumbering tools or toolkits.
サイトリナンバリングツールまたはツールキットのための機能要件を文書化します。
Document operational procedures useful for site renumbering.
サイトのリナンバリングのための便利な操作手順を文書化します。
In general, document renumbering instructions as part of every product manual.
一般的には、各製品の取扱説明書の一部として再番号付けの指示を文書化します。
Recommend strongly that all IPv6 deployment plans, for all sizes of site or network, should include provision for future renumbering. Renumbering should be planned from day one when the first lines of the configuration of a network or network service are written. Every IPv6 operator should expect to have to renumber the network one day and should plan for this event.
すべてのIPv6の展開計画は、サイトまたはネットワークのすべてのサイズのため、将来のリナンバリングのための規定を含むべきであることを強くお勧めします。リナンバリングは、ネットワークやネットワークサービスの構成の第1のラインが書かれている初日から計画する必要があります。すべてのIPv6オペレータは、1日のネットワークを再番号付けし、このイベントのために計画する必要があります持っていることを期待すべきです。
Define a secure mechanism for announcing changes of site prefix to other sites (for example, those that configure routers or VPNs to point to the site in question).
（例えば、ルータやVPNを設定するものが問題のサイトを指すように）他のサイトへのサイトプレフィックスの変更を発表するための安全なメカニズムを定義します。
For Mobile IP, define a better mechanism to handle change of home agent address while mobile is disconnected.
モバイルIPの場合は、モバイルが切断されている間、ホームエージェントアドレスの変更を処理するためのより良いメカニズムを定義します。
Known current issues are discussed in Section 5.3.5. Security issues related to SLAAC are discussed in [RFC3756]. DHCP authentication is defined in [RFC3118].
既知の現在の問題は、セクション5.3.5で説明されています。 SLAACに関連するセキュリティ問題は[RFC3756]で議論されています。 DHCP認証は[RFC3118]で定義されています。
For future mechanisms to assist and simplify renumbering, care must be taken to ensure that prefix or address changes (especially changes coming from another site or via public sources such as the DNS) are adequately authenticated at all points. Otherwise, misuse of renumbering mechanisms would become an attractive target for those wishing to divert traffic or to cause major disruption. As noted in Section 5.1.4, this may result in defensive techniques such as "DNS pinning", which create difficulty when renumbering.
リナンバリングを支援し、簡素化するため、将来のメカニズムについては、ケアはそのプレフィックスまたはアドレスの変更（別のサイトから、またはDNSなどの公共の情報源を経由して来て、特に変更は）適切にすべてのポイントで認証されるように注意しなければなりません。それ以外の場合は、リナンバリングメカニズムの誤用は、トラフィックを迂回させるか、大きな混乱を引き起こすしたい方のための魅力的な標的になります。セクション5.1.4で述べたように、これはリナンバリング時に難易度を作成し、このような「DNSピニング」などの防御技術、になることがあります。
Whatever authentication method(s) are adopted, key distribution will be an important aspect. Most likely, public key cryptography will be needed to authenticate renumbering announcements passing from one site to another, since one cannot assume a preexisting trust relationship between such sites.
どのような認証方式（複数可）を採用している、キー分布が重要な側面であろう。 1は、このようなサイト間の既存の信頼関係を負いかねますので、ほとんどの場合、公開鍵暗号は、あるサイトから別のサイトに渡すリナンバリングアナウンスを認証するために必要とされるであろう。
Significant amounts of text have been adapted from [THINK], which reflects work carried out during the 6NET project funded by the Information Society Technologies Programme of the European Commission. The authors of that document have agreed to their text being submitted under the IETF's current copyright provisions. Helpful material about work following on from 6NET was also provided by Olivier Festor of INRIA.
テキストのかなりの量は、欧州委員会の情報社会技術プログラムによって資金を供給6NETプロジェクトの間に行わ仕事を反映して、[THINK]から適応されています。その文書の著者は、そのテキストがIETFの現在の著作権規定に基づいて提出されることに合意しました。 6NETからの次の仕事に関する有用な材料は、INRIAのオリヴィエFestorによって提供されました。
Useful comments and contributions were made (in alphabetical order) by Jari Arkko, Fred Baker, Olivier Bonaventure, Teco Boot, Stephane Bortzmeyer, Dale Carder, Gert Doering, Ralph Droms, Pasi Eronen, Vijay Gurbani, William Herrin, Cullen Jennings, Eliot Lear, Darrel Lewis, Masataka Ohta, Dan Romascanu, Dave Thaler, Iljitsch van Beijnum, Stig Venaas, Nathan Ward, James Woodyatt, and others.
有益なコメントと貢献はヤリArkko、フレッド・ベイカー、オリヴィエ・ボナベンチャー、テコブーツ、ステファンBortzmeyer、デイル・カーダー、ゲルトDoering、ラルフDroms、パシEronen、ビジェイGurbani、ウィリアムHerrinの、カレン・ジェニングス、エリオット・リアで（アルファベット順に）行われました、ダレル・ルイス、正隆太田、ダンRomascanu、デーブターラー、IljitschバンBeijnum、スティグVenaas、ネイサンウォード、ジェームズWoodyattなど。
[AUTOC] Chakeres, I., Macker, J., and T. Clausen, "Mobile Ad hoc Network Architecture", Work in Progress, November 2007.
[AUTOC] Chakeres、I.、Macker、J.、およびT.クラウゼン、 "モバイルアドホックネットワークアーキテクチャ"、進歩、2007年11月に作業。
[AUTOC2] Bernardos, C., Calderon, M., and H. Moustafa, "Survey of IP address autoconfiguration mechanisms for MANETs", Work in Progress, November 2008.
【AUTOC2] Bernardos、C.、カルデロン、M.、およびH. Moustafa、 "アドホックネットワークにおけるためのIPアドレス自動設定機構の調査"、進歩、2008年11月ワーク。
[AUTOC3] Bernardos, C., Calderon, M., and H. Moustafa, "Ad-Hoc IP Autoconfiguration Solution Space Analysis", Work in Progress, November 2008.
[AUTOC3] Bernardos、C.、カルデロン、M.、およびH. Moustafa、 "アドホックIP自動解空間分析"、進歩、2008年11月の作業。
[BRDP] Boot, T. and A. Holtzer, "Border Router Discovery Protocol (BRDP) based Address Autoconfiguration", Work in Progress, July 2009.
[BRDP]ブート、T.とA. Holtzer、 "境界ルータ検出プロトコル（BRDP）ベースアドレスの自動構成"、進歩、2009年7月での作業。
[CPE] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, Ed., "Basic Requirements for IPv6 Customer Edge Routers", Work in Progress, May 2010.
[CPE]シン、H.、Beebee、W.、Donley、C.、スターク、B.、およびO. Troan、エド。、 "IPv6のカスタマーエッジルータのための基本要件"、進歩、2010年5月での作業。
[CROCKER] Crocker, S., "Renumbering Considered Normal", 2006, <http://www.arin.net/meetings/minutes/ARIN_XVIII/PDF /wednesday/Renumbering_Crocker.pdf>.
[CROCKER]クロッカー、S.は、2006年、<http://www.arin.net/meetings/minutes/ARIN_XVIII/PDF /wednesday/Renumbering_Crocker.pdf> "正常と考えリナンバリング"。
[DHMIFRT] Sun, T. and H. Deng, "Route Configuration by DHCPv6 Option for Hosts with Multiple Interfaces", Work in Progress, March 2009.
[DHMIFRT]日、T.とH.鄧小、「複数のインタフェースを持つホスト用のDHCPv6オプションでルート設定」、進歩、2009年3月での作業。
[DHRTOPT] Dec, W. and R. Johnson, "DHCPv6 Route Option", Work in Progress, March 2010.
[DHRTOPT] 12月、W.とR.ジョンソンは、 "DHCPv6のルートオプション"、進歩、2010年3月に作業します。
[DHSUBNET] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, "Subnet Allocation Option", Work in Progress, May 2010.
【DHSUBNET]ジョンソン、R.、Kumarasamy、J.、キニア、K.、およびM.スタップ、 "サブネット割当てオプション"、進歩、2010年5月ワーク。
[DNSBOOK] Albitz, P. and C. Liu, "DNS and BIND", 5th Edition, O'Reilly, 2006.
[DNSBOOK] Albitz、P.とC.劉、 "DNSおよびBIND"、第5版、オライリー、2006。
[DNSCONT] Dickinson, J., Morris, S., and R. Arends, "Design for a Nameserver Control Protocol", Work in Protocol, October 2008.
[DNSCONT]ディキンソン、J.、モリス、S.、およびR.アレンズ、 "ネームサーバー制御プロトコルのためのデザイン"、議定書、2008年10月の作業。
[DNSSD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, March 2010.
[DNSSD]チェシャー、S.とM. Krochmal、 "DNSベースのサービス発見"、進歩、2010年3月での作業。
[HANDLEY] Handley, M., Wischik, D., and M. Bagnulo, "Multipath Transport, Resource Pooling, and implications for Routing", 2008, <http://www.ietf.org/proceedings/08jul/ slides/RRG-2.pdf>.
【HANDLEY]ハンドレー、M.、Wischik、D.、およびM. Bagnulo、 "マルチパストランスポート、リソースプール、およびルーティングのための含意" 2008年、<http://www.ietf.org/proceedings/08jul/スライド/ RRG-2.pdf>。
[IEEE.802-1X] Institute of Electrical and Electronics Engineers, "Port-Based Network Access Control: IEEE Standard for Local and Metropolitan Area Networks 802.1X-2004", December 2009.
電気電子技術者の[IEEE.802-1X]研究所、「ポートベースのネットワークアクセス制御：ローカルおよびメトロポリタンエリアネットワーク802.1X-2004のためのIEEE規格」、2009年12月。
[IEEE.802-1X-REV] Institute of Electrical and Electronics Engineers, "802.1X-REV - Revision of 802.1X-2004 - Port Based Network Access Control: IEEE Standard for Local and Metropolitan Area Networks", 2009.
[IEEE.802-1X-REV]電気電子技術者協会、「802.1X-REV - 802.1X-2004の改訂 - ポートベースのネットワークアクセスコントロール：ローカルおよびメトロポリタンエリアネットワークのIEEE規格」、2009年。
[ILNP] Atkinson, R., "ILNP Concept of Operations", Work in Progress, February 2010.
[ILNP]アトキンソン、R.、 "オペレーションのILNPコンセプト"、進歩、2010年2月での作業。
[LEROY] Leroy, D. and O. Bonaventure, "Preparing network configurations for IPv6 renumbering", International Journal of Network Management, 2009, <http:// inl.info.ucl.ac.be/system/files/dleroy-nem-2009.pdf>.
[LEROY]リロイ、D.およびO.ボナベンチャー、 "IPv6のリナンバリングのためのネットワーク構成の準備"、ネットワーク管理、2009年の国際ジャーナル、<のhttp：// inl.info.ucl.ac.be/system/files/dleroy- NEM-2009.pdf>。
[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", Work in Progress, April 2010.
[LISP]ファリナッチ、D.、フラー、V.、マイヤー、D.、およびD.ルイス、 "ロケータ/ ID分離プロトコル（LISP）"、進歩、2010年4月作業。
[MDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, March 2010.
[MDNS]チェシャー、S.とM. Krochmal、 "マルチキャストDNS"、進歩、2010年3月での作業。
[NAT66] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address Translation (NAT66)", Work in Progress, March 2009.
[NAT66]ワッサーマン、M.とF.ベイカー、 "IPv6のツーのIPv6ネットワークアドレス変換（NAT66）"、進歩、2009年3月での作業。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332]マクレガー、G.、 "PPPインターネットプロトコル制御プロトコル（IPCP）"、RFC 1332、1992年5月。
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994.
[RFC1661]シンプソン、W.、 "ポイントツーポイントプロトコル（PPP）"、STD 51、RFC 1661、1994年7月。
[RFC1900] Carpenter, B. and Y. Rekhter, "Renumbering Needs Work", RFC 1900, February 1996.
[RFC1900]大工、B.およびY. Rekhter、 "リナンバリングは作業が必要"、RFC 1900、1996年2月。
[RFC1916] Berkowitz, H., Ferguson, P., Leland, W., and P. Nesser, "Enterprise Renumbering: Experience and Information Solicitation", RFC 1916, February 1996.
[RFC1916]バーコウィッツ、H.、ファーガソン、P.、リーランド、W.、およびP. Nesser、 "エンタープライズリナンバリング：経験と情報要請"、RFC 1916、1996年2月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC1958] Carpenter, B., "Architectural Principles of the Internet", RFC 1958, June 1996.
[RFC1958]大工、B.、 "インターネットの建築原則"、RFC 1958、1996年6月。
[RFC2071] Ferguson, P. and H. Berkowitz, "Network Renumbering Overview: Why would I want it and what is it anyway?", RFC 2071, January 1997.
[RFC2071]ファーガソン、P.とH.バーコウィッツ、「ネットワークのリナンバリングの概要：なぜ私はそれをしたいだろうし、それはとにかく何ですか？」、RFC 2071、1997年1月。
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[RFC2072]バーコウィッツ、H.、 "ルータリナンバリングガイド"、RFC 2072、1997年1月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998.
"ISAKMPのための解釈のインターネットIPセキュリティー領域" [RFC2407]パイパー、D.、RFC 2407、1998年11月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608]ガットマン、E.、パーキンス、C.、Veizades、J.、およびM.日、 "サービスロケーションプロトコル、バージョン2"、RFC 2608、1999年6月。
[RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, June 1999.
[RFC2610]パーキンス、C.およびE.グットマン、 "サービスロケーションプロトコルのためのDHCPオプション"、RFC 2610、1999年6月。
[RFC2874] Crawford, M. and C. Huitema, "DNS Extensions to Support IPv6 Address Aggregation and Renumbering", RFC 2874, July 2000.
[RFC2874]クロフォード、M.とC.のHuitemaは、RFC 2874、2000年7月 "DNSの拡張機能は、IPv6アドレスの集約とリナンバリングを支援します"。
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[RFC2894]クロフォード、M.、 "IPv6のルータリナンバリング"、RFC 2894、2000年8月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B.、RFC 3007、2000年11月 "ドメインネームシステム（DNS）動的更新をセキュア"。
[RFC3059] Guttman, E., "Attribute List Extension for the Service Location Protocol", RFC 3059, February 2001.
[RFC3059]グットマン、E.は、RFC 3059、2001年2月、 "サービスロケーションプロトコルのためのリスト拡張属性"。
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R.とW. Arbaugh、 "DHCPメッセージの認証"、RFC 3118、2001年6月。
[RFC3203] T'Joens, Y., Hublet, C., and P. De Schrijver, "DHCP reconfigure extension", RFC 3203, December 2001.
[RFC3203] T'Joens、Y.、Hublet、C.、およびP.デ・Schrijver、 "DHCPの再構成の拡張機能"、RFC 3203、2001年12月。
[RFC3224] Guttman, E., "Vendor Extensions for Service Location Protocol, Version 2", RFC 3224, January 2002.
[RFC3224]グットマン、E.、RFC 3224、2002年1月 "サービスロケーションプロトコル、バージョン2のためのベンダ拡張機能"。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306]ハーバーマン、B.とD.ターラー、 "ユニキャストプレフィックスベースのIPv6マルチキャストアドレス"、RFC 3306、2002年8月。
[RFC3315] Droms, R., 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月。
[RFC3421] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and W. Jerome, "Select and Sort Extensions for the Service Location Protocol (SLP)", RFC 3421, November 2002.
[RFC3421]趙、W.、Schulzrinneと、H.、ガットマン、E.、Bisdikian、C.、およびW.ジェローム、 "サービスロケーションプロトコル（SLP）のための拡張機能を選択し、並べ替え"、RFC 3421、2002年11月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O.とR. Droms、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC3736] Droms、R.、 "IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス"、RFC 3736、2004年4月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.
[RFC3756] Nikander、P.、ケンプ、J.、およびE. Nordmarkと、 "IPv6近隣探索（ND）信頼モデルと脅威"、RFC 3756、2004年5月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[RFC3795] Sofia, R. and P. Nesser, "Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents", RFC 3795, June 2004.
[RFC3795]ソフィア、R.とP. Nesser、RFC 3795、2004年6月「のIPv4の調査は、現在展開IETFアプリケーション領域標準化過程と実験ドキュメント内のアドレス」。
[RFC3832] Zhao, W., Schulzrinne, H., Guttman, E., Bisdikian, C., and W. Jerome, "Remote Service Discovery in the Service Location Protocol (SLP) via DNS SRV", RFC 3832, July 2004.
[RFC3832]趙、W.、Schulzrinneと、H.、ガットマン、E.、Bisdikian、C.、およびW.ジェローム、 "DNSのSRVを経由してサービスロケーションプロトコル（SLP）のリモートサービス発見"、RFC 3832、2004年7月。
[RFC3956] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[RFC3956] Savola、P.とB.ハーバーマン、 "IPv6マルチキャストアドレスでのランデブーポイント（RP）アドレスを埋め込み"、RFC 3956、2004年11月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958] Daigle氏、L.とA.ニュートン、RFC 3958、2005年1月 "SRVのRRを使用したアプリケーションサービスの場所とダイナミックな委譲発見サービス（DDDS）をドメインベース"。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005.
[RFC4034]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張機能のためのリソースレコード"、RFC 4034、2005年3月。
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[RFC4035]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ拡張のためのプロトコル変更"、RFC 4035、2005年3月。
[RFC4076] Chown, T., Venaas, S., and A. Vijayabhaskar, "Renumbering Requirements for Stateless Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4076, May 2005.
[RFC4076]のchown、T.、Venaas、S.、およびA. Vijayabhaskar、 "IPv6のステートレス動的ホスト構成プロトコル（DHCPv6の）のためのリナンバリング要件"、RFC 4076、2005年5月。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, November 2005.
[RFC4191] Draves、R.とD.ターラー、 "デフォルトルータの設定と、より詳細なルート"、RFC 4191、2005年11月。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]ベイカー、F.、リア、E.、およびR. Droms、 "国旗の日なしでIPv6ネットワークを再番号付けのための手順"、RFC 4192、2005年9月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306]カウフマン、C.、 "インターネットキーエクスチェンジ（IKEv2の）プロトコル"、RFC 4306、2005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340]コーラー、E.、ハンドリー、M.、およびS.フロイド、 "データグラム輻輳制御プロトコル（DCCP）"、RFC 4340、2006年3月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741]エンス、R.、 "NETCONF構成プロトコル"、RFC 4741、2006年12月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten氏、T.、Nordmarkと、E.、シンプソン、W.、およびH.ソリマン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。
[RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007.
[RFC4941] Narten氏、T.、Draves、R.、およびS.クリシュナン、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 4941、2007年9月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960]スチュワート、R.、 "ストリーム制御伝送プロトコル"、RFC 4960、2007年9月。
[RFC5059] Bhaskar, N., Gall, A., Lingard, J., and S. Venaas, "Bootstrap Router (BSR) Mechanism for Protocol Independent Multicast (PIM)", RFC 5059, January 2008.
[RFC5059] Bhaskar、N.、ガル、A.、リンガード、J.、およびS. Venaas、 "プロトコル独立マルチキャスト（PIM）のためのブートストラップルータ（BSR）メカニズム"、RFC 5059、2008年1月。
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. Kozuka, "Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration", RFC 5061, September 2007.
[RFC5061]スチュワート、R.、謝、Q.、Tuexen、M.、丸山、S.、およびM.小塚、 "ストリーム制御伝送プロトコル（SCTP）動的アドレス再構成"、RFC 5061、2007年9月。
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over PPP", RFC 5072, September 2007.
[RFC5072] S.Varada、ハスキンズ、D.、およびE.アレン、 "PPPオーバーIPバージョン6"、RFC 5072、2007年9月。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008.
[RFC5280]クーパー、D.、Santesson、S.、ファレル、S.、Boeyen、S.、Housley氏、R.、およびW.ポーク、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト（CRL）のプロフィール」、RFC 5280、2008年5月。
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5533] Nordmarkと、E.およびM. Bagnulo、 "SHIM6：IPv6のレベル3マルチホーミングシム・プロトコル"、RFC 5533、2009年6月。
[RFC5558] Templin, F., "Virtual Enterprise Traversal (VET)", RFC 5558, February 2010.
[RFC5558]テンプリン、F.、 "仮想エンタープライズトラバーサル（VET）"、RFC 5558、2010年2月。
[SCTPNAT] Xie, Q., Stewart, R., Holdrege, M., and M. Tuexen, "SCTP NAT Traversal Considerations", Work in Progress, November 2007.
[SCTPNAT]謝、Q.、スチュワート、R.、ホールドレッジ、M.、およびM. Tuexen、 "SCTP NATトラバーサルの考慮事項"、進歩、2007年11月に作業。
[SIX-ONE] Vogt, C., "Six/One: A Solution for Routing and Addressing in IPv6", Work in Progress, October 2009.
[SIX-ONE]フォークト、C.、 "/ワン6：IPv6におけるルーティングと対処するためのソリューション"、進歩、2009年10月に作業。
[THINK] Chown, T., "Things to think about when Renumbering an IPv6 network", Work in Progress, September 2006.
[THINK] chownコマンドは、T.は、進歩、2006年9月、作品 "物事はIPv6ネットワークのリナンバリング時に考えるように"。
Appendix A. Embedded IP Addresses
付録A.埋め込まれたIPアドレス
This Appendix lists common places where IP addresses might be embedded. The list was adapted from [THINK].
この付録では、IPアドレスが埋め込まれるかもしれない一般的な場所を示しています。リストは[THINK]から適応されました。
Provider based prefix(es)
プロバイダベースの接頭語（ES）
Names resolved to IP addresses in firewall at startup time
起動時にファイアウォールでIPアドレスに解決された名前
IP addresses in remote firewalls allowing access to remote services
リモートサービスへのアクセスを許可するリモートファイアウォール内のIPアドレス
IP-based authentication in remote systems allowing access to online bibliographic resources
オンライン書誌リソースへのアクセスを許可するリモートシステムにおけるIPベースの認証
IP address of both tunnel end points for IPv6 in IPv4 tunnel
IPv4トンネルにIPv6の両方のトンネルエンドポイントのIPアドレス
Hard-coded IP subnet configuration information
ハードコードされたIPサブネットの構成情報
IP addresses for static route targets
スタティックルートターゲットのIPアドレス
Blocked SMTP server IP list (spam sources)
ブロックされたSMTPサーバーIPリスト（スパムソース）
Web .htaccess and remote access controls
ウェブ.htaccessファイルとリモートアクセスコントロール
Apache .Listen. directive on given IP address
Apacheの.Listen。与えられたIPアドレスに関する指令
Configured multicast rendezvous point
設定されたマルチキャストランデブーポイント
TCP wrapper files
TCPラッパーファイル
Samba configuration files
Sambaの設定ファイル
DNS resolv.conf on Unix
Unix上のDNSはresolv.conf
Any network traffic monitoring tool
すべてのネットワークトラフィック監視ツール
NIS/ypbind via the hosts file
hostsファイル経由でNIS / ypbindを
Some interface configurations
いくつかのインターフェイスの設定
Unix portmap security masks
Unixのは、セキュリティマスクのportmap
NIS security masks
NISのセキュリティ・マスク
PIM-SM Rendezvous Point address on multicast routers
マルチキャストルータ上でPIM-SMランデブーポイントアドレス
Authors' Addresses
著者のアドレス
Brian Carpenter Department of Computer Science University of Auckland PB 92019 Auckland 1142 New Zealand
オークランドPBのコンピュータサイエンス大学92019オークランド1142ニュージーランドのブライアン・カーペンター部門
EMail: brian.e.carpenter@gmail.com
メールアドレス：brian.e.carpenter@gmail.com
Randall Atkinson Extreme Networks PO Box 14129 Suite 100, 3306 East NC Highway 54 Research Triangle Park, NC 27709 USA
ランドール・アトキンソンエクストリームネットワーク私書箱14129スイート100、3306東NCハイウェイ54リサーチトライアングルパーク、NC 27709 USA
EMail: rja@extremenetworks.com
メールアドレス：rja@extremenetworks.com
Hannu Flinck Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンヌ・フリンクノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
EMail: hannu.flinck@nsn.com
メールアドレス：hannu.flinck@nsn.com