[要約] RFC 5887は、再番号付けの課題と改善点について述べたものです。その目的は、再番号付けのプロセスを改善し、ネットワークの運用を容易にすることです。
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.
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.
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
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].
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）は、IPv4 [RFC2131]およびIPv6 [RFC3315]で利用できます。IPv6には、ステートレスアドレスAutoconfiguration（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.
o 2つのサイトネットワークを1つまたは1つのネットワークを2つ以上に分割する合併。
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]、6/1 [6-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).
運用上の観点から、興味深い側面はローカルポリシーです。一部のサイトでは、Mac（Media Access Control）アドレスをセキュリティメジャーとして事前登録する必要がありますが、他のサイトではMACアドレスがIPアドレスを取得することができます。同様に、一部のサイトでは、DHCPを使用して毎回特定のMACアドレスに同じIPアドレスを提供します（これは「静的DHCP」と呼ばれることもあります）が、他のサイトはそうではありません（これは「動的DHCP」と呼ばれることもあります）。一部のデバイス（サーバー、Voice over IP（VoIP）ハンドセットなど）には、DHCPを介してプロビジョニングされる比較的静的なIPアドレスがあり、他のデバイス（ポータブルコンピューターなど）が毎回異なる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アドレス（ES）、およびさまざまな種類の他の管理情報が含まれています。このようなデータベースは、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）、アクセス制御リスト（ACLS）、およびサービス品質など、さまざまなパラメーターを持つ特定のユーザーのネットワーク接続のポイントを構成することがよくあります。（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よりも前に設計され、無人の自動構成が好まれるネットワークを目的としています。ルーターのない孤立したネットワークのケースを無視すると、Link-Localアドレスを無期限に使用しますが、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.
ここでは、Duplicateアドレス検出（DAD）、Neighbor Discovery（ND）、およびNeighbor Unerachability Discovery（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は複数のプレフィックスを示すことができ、複数のルーターが同じリンクにRASを送信できます。各プレフィックスについて、RAは2つの寿命を示します：「優先」と「有効」。このプレフィックスから派生したアドレスは、その寿命を継承する必要があります。有効な寿命が期限切れになった場合、プレフィックスは死んでおり、派生アドレスをこれ以上使用してはなりません。優先寿命の有効期限が切れる（またはゼロに設定されている）場合、プレフィックスは非推奨であり、新しいセッションに使用してはなりません。したがって、ゼロまたは有限の優先寿命を設定することは、変更が発生するというSLAACの警告です。SLAACは、新しいプレフィックスが非推奨のプレフィックスと並行して宣伝されると想定しているため、新しいセッションは新しいプレフィックスの下で構成されたアドレスを使用します。
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.
サイトに外部の世界への複数のアップストリームリンクがある環境では、サイトには複数の有効なルーティングプレフィックスがある場合があります。そのような場合、通常、サイト内のすべての有効なルーティングプレフィックスは同じプレフィックスの長さを持ちます。また、そのような場合、DHCPV6を使用してアドレスを取得して、ルーティングプレフィックスが現在有効である定期的なIPv6 RAメッセージから推測することにより、上流リンクの可用性について動的に学習するホストが望ましい場合があります。このアプリケーションは、IPv6 Neighbor Discovery Architecture内で可能であると思われますが、どこでも明確に指定されていないようです。したがって、現在、ホストが新しいアップストリームリンクの可用性や以前の上流リンクの損失について学ぶためのこのアプローチは、現在出荷するホストやルーターと連携することはほとんどありません。
"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]であり、各端のインターフェイス識別子の構成に使用され、その後、リンクローカルアドレスを通常の方法で作成できます。実際には、それぞれの側が独自の識別子を提案することができ、衝突がある場合、またはプロバイダーがサブスクライバーに特定のインターフェイス識別子の使用を強制したい場合にのみ再交渉が必要です。Link-Localアドレスが割り当てられ、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アップデート[RFC3007]を使用することです。この場合、ホストは新しいアドレスを受信したときに独自のDNSサーバーに通知します。
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ホストが使用するもの）、Microsoft 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 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サーバー（例：Windows Server）は、多くの場合、安全な動的DNSアップデートも有効に展開されます。場合によっては、DNSサーバーとDHCPサーバーの両方を有効にするだけで、自動副作用として安全な動的DNSアップデートが可能になる場合があります（[DNSBook]p。506）。したがって、場合によっては、サイトが気付かずに、Secure Dynamic 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）と安全な動的DNS更新仕様は十分に安全であり、DNSSECの展開を奨励していると考えています（[RFC3007] [RFC4033] [RFC4034] [RFC4035]）。
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は2009年2月上旬から運用上署名されていると報告されています。DNS全体のルートゾーンが非常に近い将来署名される可能性が高いようです。たとえば、<http://www.dnsec-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、Mac OS X、UNIX、およびWindowsシステムに広く展開されており、Link-Local Name ResolutionとDNSベースのダイナミックサービスディスカバリーの両方にも広く使用されています[MDNSも広く使用されています。] [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 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.
DHCPはもともとホスト構成のために構想されていましたが、ルーター構成のいくつかの側面にも使用できます。DHCPV6プレフィックス委任オプション[RFC3633]はこれを目的としています。たとえば、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).
[CPE]は、顧客がDHCPV6を使用して上流のISPからアドレスプレフィックスを取得し、IPv6 RAメッセージを使用してデフォルトのIPv6ルートを確立することを要求します（IPv6が使用されている場合）。
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]を使用することを選択する場合があります。すべてのオフサイト通信のアドレス。また、すべてのデバイスにULAを割り当てることにより、すべてのオンサイトネットワーク管理目的でULASを使用することも可能です。これにより、これらの現場でのアクティビティは、オフサイト通信に使用されるプレフィックス（ES）の名前を変更することに対して免れます。最後に、ULASは、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つのレベルで適用されます。サイト操作の混乱全般と、変更の瞬間に進行中の個々の申請セッションの中断です。IPv6の場合、[RFC4192]で説明されているように、古いプレフィックスと新しい接頭辞の使用を重複させる本質的な能力は、進行中のセッションの混乱を大幅に軽減します。このアプローチは、主にIPv4にステートレスアドレスAutoconfiguration（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 [RFC3203]のDHCPに対して定義されています。これは特にユニキャストのみです。DHCPクライアントは、マルチキャストForcerenewを破棄する必要があります。それにもかかわらず、これは、DHCPサーバーがすべてのクライアントを介してそれぞれにForcerenewを発行することで、変更プロセスをトリガーするために使用できます。DHCPV6には、同様の機能、つまりユニキャスト再構成メッセージがあり、各ホストに送信してDHCPV6サーバーを確認するために通知することができます。これらの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-to-IPアドレステーブルとDNSゾーンファイルが再生されます。DHCPおよびDNSタイマーは、一時的に小さな値に設定されます。DHCPおよびDNSサーバーに新しいファイルが供給され、以前のDHCPリースとDNS TTLが期限切れになるとすぐに、ホストIPレイヤーに関する限り、すべてが自動的に続きます。対照的に、アセット管理が弱く、カジュアルな運用アプローチでは、DHCPテーブルが手で再構成され、DNSゾーンファイルは手で編集され、これらの構成がインストールされると、古いものがあるまで混乱が発生します。リースとTTLが期限切れになります。DHCP ForcerEnewまたは再構成メッセージは、この混乱をある程度短縮する可能性があります。
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アドレス情報を掲載していませんが、一部の場合は（たとえば、オプション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メッセージには、Mビットとして知られる「管理された構成」フラグが含まれます。これは、DHCPV6が使用されていることを示すはずです。ただし、ホストがこのフラグを厳密に解釈する必要があるかどうかは不明確です（つまり、設定されている場合のみDHCPV6を起動する可能性があるか、RAが受信されない場合にのみ開始する必要がありますか）、またはデフォルトでDHCPV6を起動することが許可されるか、推奨されるかどうか。複雑さが追加されているのは、DHCPV6には「ステートレス」モード[RFC3736]があり、SLAACはアドレスを取得するために使用されますが、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ビットを受信したときにのみ起動する場合、系統的アドレス管理が妨げられます。
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応答も受信されず、ホストは自己割り当てされたLink-Localアドレスのみを維持することに注意する必要があります。また、マルチホームネットワークが1つのアドレスプレフィックスにSLAACを使用し、別のアドレスにDHCPV6を使用するという状況があります。
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アドレスが割り当てられているシステムのすべての場合に確実に機能しません。もちろん、静的アドレス指定を備えたシステムでさえ、DHCPを使用してIPアドレス（ES）を取得するように構成できます。このような「静的DHCP」の使用は、通常、必要になったときにサイトの変更を容易にします。ただし、他のケースでは、サイト固有であり、間違いなくヒューマンエラーが発生しやすい可能性が高い手動またはスクリプト駆動型の手順が必要です。サイトに固定された手動で構成されたアドレスを持つホストが1つさえある場合、完全に自動ホストの変更は不可能になる可能性が非常に高くなります。
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の場合、古いアドレスと新しいアドレスの重複はオプションである可能性は低く、いずれにせよ、ソフトウェアによって一般的にサポートされていません。したがって、動的エンドポイントアドレスの変更（[ハンドリー]など）を有効にするための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セッション[RFC4960] [RFC5061]を変更することにより、SCTPセッションは悪影響を受けるべきではありません。
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構成さえ維持していないという逸話的なレポートがあります。彼らはISPのリゾルバーを指し、ISPにサーバーのDNSエントリをインストールするように要求しますが、主にIPアドレスで内部で動作します。したがって、使用中のDNSサーバーが安全な動的DNSアップデートを有効にしていない限り、そのようなサイトを変更するには、サイトとそのISPの間の管理調整が必要になります。一部の商用DNSサービス会社には、DNSサービスサービスの一部としてSecure Dynamic 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エントリが一致することに注意する必要があります。サイトがRenumbersの場合、これらの逆エントリも更新する必要があります。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]で行われました。これにより、257の標準トラックのうち34または実験的なアプリケーション層RFCには、明示的なアドレス依存関係があることがわかりました。この研究は、IPv4からIPv6への遷移のコンテキストで行われましたが、これらのプロトコルはすべて変更に敏感である可能性があることは明らかです。ただし、実際の実装が変更に敏感であるかどうかを分析することで発見する方法がないという点で、状況はさらに悪いことです。実際、このような分析は、独自のアプリケーションの場合、非常に不可能かもしれません。
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が構成ファイルに保存されている場合でも、アプリケーションが起動するときに一度だけ解決され、その後無期限にキャッシュされることです。これは不十分です。もちろん、これはすべてのアプリケーションソフトウェアには適用されません。たとえば、いくつかのよく知られているWebブラウザーには、デフォルトのキャッシュの寿命が短いです。
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 Cookie、またはアプリケーションプロキシ構成です。（付録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（）を呼び出すことにより、アプリケーションが実質的にIPアドレスを保存することが奨励されていることに注意する必要があります。多くのアプリケーションが、ネットワーク層アドレスなどの低層オブジェクトを表示および使用するためにアプリケーションが必要とするAPIを使用することは非常に残念です。ただし、BSDソケットAPIは、ドメイン名システム（DNS）が作成される前に設計および展開されたため、当時は良いオプションはほとんどありませんでした。この問題は、これらの関数が住所の寿命を返さないため、アプリケーションにアドレスがいつ有効でないかを知る方法がないという事実によってさらに悪化します。IPv6をカバーする同じモデルの拡張は、この問題を多少複雑にしています。Socket APIを使用したアプリケーションは、特定のリモートホストの複数のアドレスの可用性から利益を得たい場合、明示的なロジックを含める必要があります。FQDNのみがアプリケーションにさらされ、アドレスがAPI内の適切な寿命でキャッシュされたプログラミングモデルが採用された場合、これらの問題のほとんどは消えます。少なくともこれの最初の部分は、いくつかのプログラミング環境ですでに利用可能であることに注意する必要があります。一般的な例はJavaです。ここでは、通常の状況ではFQDNのみをアプリケーションコードで処理する必要があり、実行時間システムによって処理される複数のアドレスを処理するために追加のアプリケーションロジックは必要ありません。これは、ネットワーキングの専門家ではないプログラマーにとって非常に有益であり、名前を変更する多くの側面からアプリケーションソフトウェアを隔離します。同様に抽象的な、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ピンニング」と呼ばれる手法でDNS TTLに意図的に違反しています。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で述べたように、サービス発見のためにSRVレコードを備えたサービスロケーションプロトコル（SLP）、およびマルチキャスト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.
o 一部の状況では、一部のルーターはIPアドレスをキャッシュします。そのため、サイトの変更の結果、ルーターを再起動する必要がある場合があります。
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.
o アドレスは、VPNトンネルを含む構成されたトンネルで使用される場合がありますが、少なくともインターネットキーエクスチェンジ（IKE）は、代わりに完全に資格のあるドメイン名の使用をサポートしています。
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 VPNSのエンドポイント名としてFQDNSを使用する機能は新しく、標準ではありません（[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.
IPv6では、アップストリームプロバイダーごとに1つのプレフィックスを備えた複数のプロバイダー総合（PA）ルーティングプレフィックスを使用してサイトをマルチホームしたい場合、インテリアルーターは、どのアップストリームプロバイダーとプレフィックスが現在到達可能（および有効）に到達できるかを学習するメカニズムが必要です。この場合、ルーター広告メッセージは、現在有効なルーティングプレフィックスをホストに広告するために動的に更新できます。これは、さまざまなプロバイダーのプレフィックスが長さが異なる場合、またはサイトに不均一なサブネットプレフィックスの長さがある場合、非常に複雑になります。
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が関与しているか複数のNATが関与しているかに応じて、マルチホームSCTP [SCTPNAT]の状況はより複雑です。
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自体が変更される可能性があり、変更イベント中に構成変更が必要になる場合があります。著者の1人には、DHCPクライアントとして行動することにより、住宅のインターネットサービスプロバイダーから外部住所を取得するNAT対応のホームゲートウェイがあります。ISPがDHCPを使用してゲートウェイの外部IPアドレスを変更した場合、その展開は運用上の問題に悩まされていません。その成功の重要な部分は、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]を介してホームサイトで使用される新しいグローバルルーティングプレフィックスを通知することができます。モバイルノードが変更イベントの時点でディタッチされている場合、モバイルノードがデタッチされている場合、ホームエージェントの有効なサブネットのaycastアドレスが知られていないため、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 Neighbor Discoveryのように）。一方、[RFC3306]で指定されたマルチキャストアドレスへのIPv6ユニキャストアドレスの埋め込みと、[RFC3956]の埋め込みRP（Rendezvous Point）は、変更時に問題を引き起こします。
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.
Any-Sourceマルチキャスト（ASM）を備えたIPv4またはIPv6の場合、変更は簡単です。ソースがルーティングの観点から変更された場合、同じマルチキャストグループ内に新しいソースがあるかのように、物事は振る舞います。ただし、アプリケーションの問題がある場合があります。動的RP発見にBootstrapルーター（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のため、サイトまたはネットワークは、独自の構成データに他のサイトまたはネットワークからアドレスを埋め込むことができます。（もちろん、可能な限り、代わりにFQDNSを埋め込むことが望ましいです。）したがって、変更すると、サイトとその隣人の更新のリップル効果が発生します。これらの更新がマニュアルである限り、コストがかかり、エラーが発生しやすくなります。独立したサイト間の更新を同期すると、予測不可能な遅延が発生する可能性があります。セクション4は、IPv6 ULASがこの問題を軽減できることを示唆していることに注意してください。もちろん、グローバルにルーティング可能なアドレスではなくULASに適したVPNとルートのみであることが示唆されています。構成される外部アドレスの大部分は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.
一部のアドレス構成データは比較的簡単に見つけることができます（たとえば、サイトファイアウォールルール、サイトボーダールーターのACL、およびDNS）。その他は広く分散しており、見つけるのがはるかに難しい場合があります（たとえば、ルーターを構築するための構成、個々のユーザーによって構成されたプリンターアドレス、および個人ファイアウォールの構成）。これらのいくつかは、関係者が問題に遭遇した場合にのみ、必然的に見直されるイベントの後にのみ見つかります。
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-in-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.
構成ファイルとデータベースで可能な限り生のIPアドレスではなくFQDNSの使用は、変更が必要であるか、その他の方法で発生したときに、そのような構成ファイルまたは管理データベースから生じる潜在的な問題を削減/軽減します。これは[RFC1958]（ポイント4.1）で提唱されています。アプリケーションのセクション5.1.4で述べたように、これはそれ自体が不十分です。ルーターなどの一部のデバイスは、起動時にFQDNSを一度だけ解決し、結果のアドレスを無期限に使用し続けることが知られています。これには、特定のタイムアウト後に再び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.
定義上、少なくとも1つの場所（つまり、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.
管理と管理の問題（つまり、アドレスが動的に調べられるのではなく保存されるすべてのインスタンスを追跡、記録、および更新する）は、変更の問題を考慮してマネージャーの支配的な懸念を形成することに注意する必要があります。これにより、多くのサイトにより、プロバイダーに依存しない（PI）プレフィックスを使用するPre-CIDR（クラスレスドメイン間ルーティング）アプローチを継続するようになりました。非常に大きな企業ネットワークを含む一部のサイトは、PIアドレス指定をNATと組み合わせています。他の人は、義務ではなく選択の問題として、個人的なアドレス指定とNATを採用しています。このさまざまな手法により、使用中のISPとは独立した計画に対処することができ、マルチホームへの簡単なアプローチが可能になります。変更の直接的なコストは、これらの代替案の間接コストを超えると認識されています。さらに、変更の複雑な依存関係に起因するリスク要素があります。変更が予期しないサービスの混乱を引き起こさず、追加のコストが不明につながることを完全に確信することは困難です。
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アドレスを使用して静的に構成され、ホストルーティングテーブルのプレフィックスリストを使用しても。FQDNSを使用してVPN構成を使用して、コーポレートVPNゲートウェイなどの固定エンドポイントに名前を付け、非アドレスIDタイプなど、IKEを使用した既存のIPセキュリティを使用することで、既存の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の場合、住所は、安全な近隣発見（送信）[RFC3971]によって隣接発見中の偽造から保護されることを目的としています。これは、攻撃者によるプロセスのハイジャックを防ぐために、ダイナミックな変更中の非常に有用な予防策のようです。自動改造スキームは、新しいアドレスが発表された瞬間に、そのようなハイジャックに潜在的にさらされる可能性があります。ただし、現在、送信が広く実装されているか、広く展開されるかどうかは不明です。
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システム、侵入検知システムなど）に埋め込まれている他のケース。これが事前に行われない場合、リソースへの合法的なアクセスは、変更イベントの後にブロックされる可能性があります。古いルールが迅速に削除されない場合、変更イベントの後に違法なアクセスが可能になる場合があります。したがって、セキュリティの更新は、2つの段階（イベントの直前と直後）で行う必要があります。
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）証明書にiPaddress [RFC5280]を含むSubjectAltName拡張機能が含まれている場合、および対応するノードがノードのPKIへの同時更新なしでIPアドレス変更を受ける場合、運用およびセキュリティの問題が発生します。証明書。これらの理由から、iPaddressではなく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.
構成でのFQDNSの代わりにIPアドレスを使用することは、セキュリティの必要性が認識されることによって駆動されることがあります。名前解決プロセスには歴史的に認証が不足しているため、管理者はアプリケーションがセキュリティに敏感な場合に生のIPアドレスを使用することを好みます（ファイアウォールとVPNは2つの典型的な例です）。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作業が「Border Router Discovery Protocol（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ネットワークのアドレス自動施設メカニズムに取り組んでいます。[Autoc]。この研究は、[autoc2]および[autoc3]で広範囲に調査されています。同じ分野での他の作業、例えば[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で上記で説明した隠された静的構成のタイプは、マネットでは単に耐えられません。したがって、マネの自動構成についてコンセンサスに到達した場合、選択されたソリューションは、より一般的な変更問題に適していない可能性があります。ただし、マネに機能するテクニックを従来のネットワークにも適用することを検討することは確かに価値があります。
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.
デフォルトのルーターアドレスに加えて、IPv6ホスト[DHRTOPT]に代替ルートを伝達できるDHCPV6拡張が提案されています。他のDHCPオプションもテーブルにあり、[DHSUBNET]や[DHMIFRT]などのDHCPまたはDHCPV6クライアントへのアドレスのプレフィックスとルーティングに関する情報を提供する場合があります。これらは、プレフィックスの変更を動的にホストに通知する方法として拡張される可能性があると考えられます。
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は、NetConfに基づいた名前サーバーコントロールプロトコル（NSCP）を考慮しており、潜在的なホストの変更イベント[DNSCont]を含む一貫したDNS管理の手段を提供します。
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.
すべてのプレフィックスが特定の期間後に自動的に期限切れになり、対応できない[クロッカー]になるという考えを使用して、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を追加することにより強化されます。たとえば、Sockaddr、IPアドレス、プロトコル、およびポート番号ではなく、FQDNとサービス名を使用できます。これは、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/ホスト、誰か？）のホストごとに単一のレジストリを持つことが役立つ場合があります。理想的には、これはリモートで構成可能になります。たとえば、IETFの現在の作業をネットワークデバイス構成プロトコル（NetConf）に関する現在の作業を活用します。このアプローチには独自のバージョンがありますが、時には軽量ディレクトリアクセスプロトコル（LDAP）に基づいていますが、完全に標準化されたアプローチが望ましいと思われます。
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の再構成の使用をどのように展開することができますか？特に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.
自発的または不随意の変更のために、完全に動作する小規模から中程度の固定サイトに適用するのに十分なしっかりしたマネソリューション。
A MANET-style solution that can be applied convincingly to large or very large sites for voluntary renumbering.
自発的な買い戻しのために、大規模または非常に大きなサイトに説得力を持って適用できるマネスタイルのソリューション。
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ゾーンに署名するだけでなく、すでに利用可能なDNSEC対応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展開計画には、将来の変更の提供を含める必要があることを強くお勧めします。ネットワークまたはネットワークサービスの構成の最初の行が書かれている場合、Nemumberingは初日から計画する必要があります。すべてのIPv6オペレーターは、いつかネットワークを変更する必要があり、このイベントを計画する必要があるはずです。
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.
認証方法が何であれ、重要な分布が重要な側面になります。おそらく、あるサイト間の既存の信頼関係を想定できないため、あるサイトから別のサイトに通過する変更の発表を認証するには、公開キーの暗号が必要になる可能性があります。
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のOlivier 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.
Jari Arkko、Fred Baker、Olivier Bonaventure、Teco Boot、Steco Boot、Stechane Bortzmeyer、Dale Carder、Gert Doering、Ralph Droms、Pasi Eronen、Vijay Gurbani、William Herrin、Cullen Jennings、El Leal、Jari Arkko、Fred Baker、Olivier Bonaventure、Teco Boot、Stephane Carder、Gert Doering、Ralph Dromsによって有用なコメントと貢献が行われました。、Darrel Lewis、Masataka Ohta、Dan Romascanu、Dave Thaler、Iljitsch Van Beijnum、Stig Venaas、Nathan Ward、James 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. Clausen、「モバイルアドホックネットワークアーキテクチャ」、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.、Calderon、M。、およびH. Moustafa、「MANETSの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.、Calderon、M。、およびH. Moustafa、「Ad-Hoc IP Autoconfiguration Solution Space Analysis」、2008年11月、作業進行中。
[BRDP] Boot, T. and A. Holtzer, "Border Router Discovery Protocol (BRDP) based Address Autoconfiguration", Work in Progress, July 2009.
[BRDP] Boot、T。およびA. Holtzer、「Border Router Discovery Protocol（BRDP）ベースのアドレスAutoconfiguration」、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] Singh、H.、Beebee、W.、Donley、C.、Stark、B。、およびO. Troan、ed。、「IPv6 Customer Edge Routersの基本要件」、2010年5月の進行中。
[CROCKER] Crocker, S., "Renumbering Considered Normal", 2006, <http://www.arin.net/meetings/minutes/ARIN_XVIII/PDF /wednesday/Renumbering_Crocker.pdf>.
[Crocker] Crocker、S。、「Nommumbering recound remarly」、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] Sun、T。およびH. Deng、「複数のインターフェイスを持つホストのDHCPV6オプションによるルート構成」、2009年3月、進行中の作業。
[DHRTOPT] Dec, W. and R. Johnson, "DHCPv6 Route Option", Work in Progress, March 2010.
[Dhrtopt] Dec、W。and R. Johnson、「Dhcpv6ルートオプション」、2010年3月の作業。
[DHSUBNET] Johnson, R., Kumarasamy, J., Kinnear, K., and M. Stapp, "Subnet Allocation Option", Work in Progress, May 2010.
[Dhsubnet] Johnson、R.、Kumarasamy、J.、Kinnear、K。、およびM. Stapp、「サブネット割り当てオプション」、2010年5月の作業。
[DNSBOOK] Albitz, P. and C. Liu, "DNS and BIND", 5th Edition, O'Reilly, 2006.
[dnsbook] Albitz、P。and C. Liu、「DNS and Bind」、第5版、O'Reilly、2006。
[DNSCONT] Dickinson, J., Morris, S., and R. Arends, "Design for a Nameserver Control Protocol", Work in Protocol, October 2008.
[DNSCONT] Dickinson、J.、Morris、S。、およびR. Arends、「名前サーバー制御プロトコルの設計」、2008年10月、プロトコルでの作業。
[DNSSD] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", Work in Progress, March 2010.
[DNSSD] Cheshire、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] Handley、M.、Wischik、D。、およびM. Bagnulo、「マルチパストランスポート、リソースプーリング、ルーティングへの影響」、2008年、<http://www.ietf.org/proceedings/08jul/ Slides/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]電気および電子機器エンジニアの研究所、「港ベースのネットワークアクセス制御：2009年12月、地元および大都市圏ネットワーク802.1x-2004のIEEE標準」。
[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] Atkinson、R。、「ILNP Operations of Operations」、Work in Progress、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] leroy、D。and O. bonaventure、「IPv6の改装の準備の準備」、International Journal of Network Management、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] Farinacci、D.、Fuller、V.、Meyer、D。、およびD. Lewis、「Locator/ID分離プロトコル（LISP）」、2010年4月の作業。
[MDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", Work in Progress, March 2010.
[MDNS] Cheshire、S。およびM. Krochmal、「Multicast DNS」、2010年3月の作業。
[NAT66] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address Translation (NAT66)", Work in Progress, March 2009.
[NAT66] Wasserman、M。およびF. Baker、「IPv6-to-IPV6ネットワークアドレス翻訳（NAT66）」、2009年3月、進行中の作業。
[RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992.
[RFC1332] McGregor、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] Carpenter、B。およびY. Rekhter、「Nemumbering Needs Work」、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] Berkowitz、H.、Ferguson、P.、Leland、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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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] Ferguson、P。およびH. Berkowitz、「ネットワークの名前を変更する概要：なぜ私はそれが欲しいのか、とにかくそれは何ですか？」、RFC 2071、1997年1月。
[RFC2072] Berkowitz, H., "Router Renumbering Guide", RFC 2072, January 1997.
[RFC2072] Berkowitz、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.
[RFC2407] Piper、D。、「ISAKMPの解釈のインターネットIPセキュリティドメイン」、RFC 2407、1998年11月。
[RFC2608] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999.
[RFC2608] Guttman、E.、Perkins、C.、Veizades、J。、およびM. Day、「サービスロケーションプロトコル、バージョン2」、RFC 2608、1999年6月。
[RFC2610] Perkins, C. and E. Guttman, "DHCP Options for Service Location Protocol", RFC 2610, June 1999.
[RFC2610] Perkins、C。およびE. Guttman、「サービスロケーションプロトコルの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] Crawford、M。およびC. Huitema、「IPv6アドレスの集約と改修をサポートするDNS拡張」、RFC 2874、2000年7月。
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[RFC2894] Crawford、M。、「IPv6の変更ルーター」、RFC 2894、2000年8月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「セキュアドメイン名システム（DNS）動的更新」、RFC 3007、2000年11月。
[RFC3059] Guttman, E., "Attribute List Extension for the Service Location Protocol", RFC 3059, February 2001.
[RFC3059] Guttman、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. de Schrijver、「DHCP Reconfigure Extension」、RFC 3203、2001年12月。
[RFC3224] Guttman, E., "Vendor Extensions for Service Location Protocol, Version 2", RFC 3224, January 2002.
[RFC3224] Guttman、E。、「サービスロケーションプロトコルのベンダー拡張、バージョン2」、RFC 3224、2002年1月。
[RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 Multicast Addresses", RFC 3306, August 2002.
[RFC3306] Haberman、B。およびD. Thaler、「Unicast-Prefixベースの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.、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、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] Zhao、W.、Schulzrinne、H.、Guttman、E.、Bisdikian、C。、およびW. Jerome、「サービスロケーションプロトコル（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、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[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.、Kempf、J。、およびE. Nordmark、「IPv6 Neighbor Discovery（ND）Trustモデルと脅威」、RFC 3756、2004年5月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775] Johnson、D.、Perkins、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] Sofia、R。およびP. Nesser、「現在展開されているIETFアプリケーションエリア標準の追跡および実験文書におけるIPv4アドレスの調査」、RFC 3795、2004年6月。
[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] Zhao、W.、Schulzrinne、H.、Guttman、E.、Bisdikian、C。、およびW. Jerome、「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. Haberman、「IPv6マルチキャストアドレスにRendezvous Point（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. Newton、「SRV RRSおよびThe Dynamic Deligation Discovery Service（DDDS）を使用したドメインベースのアプリケーションサービスの場所」、RFC 3958、2005年1月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（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] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「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] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「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. Thaler、「デフォルトのルーター設定とより固有のルート」、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] Baker、F.、Lear、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. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005.
[RFC4306] Kaufman、C。、「Internet Key Exchange（IKEV2）プロトコル」、RFC 4306、2005年12月。
[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, March 2006.
[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram混雑制御プロトコル（DCCP）」、RFC 4340、2006年3月。
[RFC4741] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006.
[RFC4741] ENNS、R。、「NetConf Configuration Protocol」、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.、Simpson、W。、およびH. Soliman、「IPバージョン6（IPv6）の近隣発見」、RFC 4861、2007年9月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、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. Krishnan、「IPv6のステートレスアドレスAutoconfigurationのプライバシー拡張」、RFC 4941、2007年9月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、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.、Gall、A.、Lingard、J。、およびS. Venaas、「ブートストラップルーター（BSR）プロトコル独立マルチキャスト（PIM）のメカニズム」、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] Stewart、R.、Xie、Q.、Tuexen、M.、Maruyama、S。、およびM. Kozuka、「Stream Control Transmission Protocol（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、Haskins、D。、およびE. Allen、「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] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW. Polk、 "Internet 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] Templin、F。、「Virtual Enterprise Traversal（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] Xie、Q.、Stewart、R.、Holdrege、M。、およびM. Tuexen、「SCTP Nat Traversalの考慮事項」、2007年11月、Work in Progress。
[SIX-ONE] Vogt, C., "Six/One: A Solution for Routing and Addressing in IPv6", Work in Progress, October 2009.
[Six-one] Vogt、C。、「Six/One：IPv6でのルーティングとアドレス指定のためのソリューション」、2009年10月、進行中の作業。
[THINK] Chown, T., "Things to think about when Renumbering an IPv6 network", Work in Progress, September 2006.
[Think] Chown、T。、「IPv6ネットワークを変更するときに考えるべきこと」、2006年9月、進行中の作業。
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
Web .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
ホストファイルを介してNIS/YPBIND
Some interface configurations
一部のインターフェイス構成
Unix portmap security masks
UNIXポートマップセキュリティマスク
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
Randall Atkinson Extreme Networks PO Box 14129 Suite 100, 3306 East NC Highway 54 Research Triangle Park, NC 27709 USA
ランドールアトキンソンエクストリームネットワークPOボックス14129スイート100、3306イーストNCハイウェイ54リサーチトライアングルパーク、NC 27709 USA
EMail: rja@extremenetworks.com
Hannu Flinck Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannu Flinck Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
EMail: hannu.flinck@nsn.com