[要約] RFC 6866は、企業ネットワーク内の静的IPv6ホストの再番号付けに関する問題を説明しています。このRFCの目的は、再番号付けプロセスの課題を特定し、効果的な解決策を提供することです。
Internet Engineering Task Force (IETF) B. Carpenter
Request for Comments: 6866 Univ. of Auckland
Category: Informational S. Jiang
ISSN: 2070-1721 Huawei Technologies Co., Ltd.
February 2013
Problem Statement for Renumbering IPv6 Hosts with Static Addresses in Enterprise Networks
エンタープライズネットワークで静的アドレスを使用してIPv6ホストを再番号付けするための問題ステートメント
Abstract
概要
This document analyses the problems of updating the IPv6 addresses of hosts in enterprise networks that, for operational reasons, require static addresses.
このドキュメントでは、運用上の理由から静的アドレスが必要なエンタープライズネットワークのホストのIPv6アドレスを更新する際の問題を分析します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 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/rfc6866.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6866で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Analysis ........................................................3
2.1. Static Addresses Imply Static Prefixes .....................3
2.2. Other Hosts Need Literal Address ...........................4
2.3. Static Server Addresses ....................................5
2.4. Static Virtual Machine Addresses ...........................6
2.5. Asset Management and Security Tracing ......................6
2.6. Primitive Software Licensing ...............................7
2.7. Network Elements ...........................................7
2.8. Access Control Lists .......................................7
2.9. Management Aspects .........................................8
3. Summary of Problem Statement ....................................8
4. Security Considerations .........................................9
5. Acknowledgements ...............................................10
6. Informative References .........................................10
A problem that is frequently mentioned in discussions of renumbering enterprise networks [RFC5887] [RFC6879] [GAP-ANALYSIS] is that of statically assigned addresses. The scope of the present document is to analyse the problems caused for enterprise networks during renumbering by static addresses and to identify related gaps in existing technology. Some aspects also apply to small office and home networks, but these are not the intended scope of the document.
エンタープライズネットワークの再番号付け[RFC5887] [RFC6879] [GAP-ANALYSIS]の議論で頻繁に言及される問題は、静的に割り当てられたアドレスの問題です。このドキュメントの範囲は、静的アドレスによる再番号付け中に企業ネットワークで発生する問題を分析し、既存のテクノロジーに関連するギャップを特定することです。一部の側面は小規模オフィスおよびホームネットワークにも適用されますが、これらはドキュメントの対象範囲ではありません。
A static address can be defined as an IP address that is intended by the network manager to remain constant over a long period of time, possibly many years, regardless of system restarts or any other unpredictable events. Static addressing often implies manual address assignment, including manual preparation of configuration scripts. An implication of hosts having static addresses is that subnets must have static prefixes, which also requires analysis.
静的アドレスは、システムの再起動やその他の予測できないイベントに関係なく、ネットワーク管理者が長期間、場合によっては何年も一定に保つことを目的としたIPアドレスとして定義できます。静的アドレス指定は、多くの場合、構成スクリプトの手動準備を含む、手動アドレス割り当てを意味します。静的アドレスを持つホストの意味は、サブネットにも静的プレフィックスが必要であることであり、これには分析も必要です。
In a sense, the issue of static addresses is a result of history. As discussed in Section 3.2 of [RFC6250], various properties of IP addresses that have long been assumed by programmers and operators are no longer true today, although they were true when almost all addresses were manually assigned. In some cases, the resulting operational difficulties are avoided by static addressing.
ある意味では、静的アドレスの問題は履歴の結果です。 [RFC6250]のセクション3.2で説明したように、プログラマやオペレータが長い間想定していたIPアドレスのさまざまなプロパティは、ほとんどすべてのアドレスが手動で割り当てられた場合には当てはまりましたが、現在は当てはまりません。場合によっては、静的アドレッシングを使用することで、その結果生じる運用上の問題を回避できます。
Although static addressing is, in general, problematic for renumbering, hosts inside an enterprise may have static addresses for a number of operational reasons: o For some reason, other hosts need to be configured with a literal numeric address for the host in question, so its address must be static.
静的アドレッシングは一般的に、番号の付け替えに問題がありますが、企業内のホストは、いくつかの運用上の理由から静的アドレスを持っている可能性があります：o何らかの理由で、他のホストは問題のホストのリテラル数値アドレスで構成する必要があるため、そのアドレスは静的でなければなりません。
o Even if a site has local DNS support and this is normally used to locate servers, some operators wish their servers to have static addresses so that issues of address lifetime and DNS Time to Live (TTL) cannot affect connectivity.
o サイトにローカルDNSサポートがあり、これが通常サーバーの検索に使用されている場合でも、一部のオペレーターはサーバーに静的アドレスを設定して、アドレスの有効期間とDNSの存続時間（TTL）の問題が接続に影響を及ぼさないようにします。
o Some approaches to virtual server farms require static addressing.
o 仮想サーバーファームへのいくつかのアプローチでは、静的アドレス指定が必要です。
o On some sites, the network operations staff require hosts to have static addresses for asset management purposes and for address-based backtracking of security incidents.
o 一部のサイトでは、ネットワーク運用スタッフは、資産管理の目的およびセキュリティインシデントのアドレスベースのバックトラッキングのために、ホストに静的アドレスが必要です。
o Certain software licensing mechanisms are based on IP addresses.
o 特定のソフトウェアライセンスメカニズムはIPアドレスに基づいています。
o Network elements, such as routers, are usually assigned static addresses, which are also configured into network monitoring and management systems.
o ルーターなどのネットワーク要素には通常、静的アドレスが割り当てられます。これは、ネットワークの監視および管理システムにも構成されます。
o Access Control Lists and other security mechanisms are often configured using IP addresses.
o 多くの場合、アクセス制御リストやその他のセキュリティメカニズムは、IPアドレスを使用して構成されます。
Static addressing is not the same thing as manual addressing. Static addresses may be configured automatically, for example, by stateful DHCPv6. In that case, the database from which the static address is derived may itself have been created automatically in some fashion, or configured manually. If a host's address is configured manually by the host's administrator, it is by definition static.
静的アドレス指定は、手動アドレス指定と同じではありません。静的アドレスは、たとえば、ステートフルDHCPv6によって自動的に構成されます。その場合、静的アドレスの導出元のデータベース自体が何らかの方法で自動的に作成されたか、手動で構成されている可能性があります。ホストのアドレスがホストの管理者によって手動で構成されている場合、そのアドレスは定義上静的です。
This document analyses these issues in more detail and presents a problem statement. Where obvious alternatives to static addresses exist, they are mentioned.
このドキュメントでは、これらの問題をより詳細に分析し、問題の説明を示します。静的アドレスの明らかな代替手段が存在する場合は、それらについて説明します。
Host addresses can only be static if subnet prefixes are also static. Static prefixes are such a long-established practice in enterprise networks that it is hard to discern the reason for them. Originally, before DHCP became available, there was simply no alternative. Thus it became accepted practice to assign subnet prefixes manually and build them into static router configurations. Today, the static nature of subnet prefixes has become a diagnostic tool in itself, at least in the case of IPv4 where prefixes can easily be memorised. If several users sharing a subnet prefix report problems, the fault can readily be localised.
ホストアドレスは、サブネットプレフィックスも静的である場合にのみ静的にすることができます。静的プレフィックスは、エンタープライズネットワークで長年にわたって確立されている手法であり、その理由を特定することは困難です。本来、DHCPが利用可能になる前は、代替手段はありませんでした。したがって、サブネットプレフィックスを手動で割り当てて、静的ルーター構成に組み込むことが慣例となりました。今日、サブネットプレフィックスの静的な性質自体が、少なくともプレフィックスを簡単に記憶できるIPv4の場合は、それ自体が診断ツールになっています。サブネットプレフィックスを共有する複数のユーザーが問題を報告した場合、障害はすぐに特定できます。
This model is being challenged for the case of unmanaged home IPv6 networks, in which it is possible to assign subnet prefixes automatically, at least in a cold start scenario [PREFIX]. For an enterprise network, the question arises whether automatic subnet prefix assignment can be made using the "without a flag day" approach to renumbering. [RFC4192] specifies that "the new prefix is added to the network infrastructure in parallel with (and without interfering with) the old prefix". Any method for automatic prefix assignment needs to support this.
このモデルは、少なくともコールドスタートのシナリオで[PREFIX]サブネットプレフィックスを自動的に割り当てることができる、管理されていないホームIPv6ネットワークの場合に挑戦されています。エンタープライズネットワークの場合、再番号付けの「フラグデイなし」アプローチを使用して自動サブネットプレフィックス割り当てを行うことができるかどうかという疑問が生じます。 [RFC4192]は、「新しいプレフィックスは、古いプレフィックスと並行して（かつ、干渉することなく）ネットワークインフラストラクチャに追加される」ことを指定しています。自動プレフィックス割り当てのメソッドは、これをサポートする必要があります。
This issue commonly arises in small networks without local DNS support, for devices such as printers, that all other hosts need to reach. In this case, not only does the host in question have a static address but that address is also configured in the other hosts. It is a long-established practice in small IPv4 enterprise networks that printers, in particular, are manually assigned a fixed address (typically, an [RFC1918] address) and that users are told to manually configure printer access using that fixed address. For a small network, the work involved in doing this is much less than the work involved in doing it "properly" by setting up DNS service, whether local or hosted by an ISP, to give the printer a name. Also, although the Service Location Protocol (SLP) [RFC2608] is widely available for tasks such as printer discovery, it is not widely used in enterprise networks. In consequence, if the printer is renumbered for any reason, the manual configuration of all users' hosts must be updated in many enterprises.
この問題は通常、ローカルDNSがサポートされていない小規模なネットワークで、他のすべてのホストが到達する必要があるプリンターなどのデバイスで発生します。この場合、問題のホストには静的アドレスがあるだけでなく、そのアドレスは他のホストでも構成されます。小規模なIPv4エンタープライズネットワークでは、特にプリンタに手動で固定アドレス（通常は[RFC1918]アドレス）が割り当てられ、その固定アドレスを使用してプリンタアクセスを手動で構成するようユーザーに通知することが、長年の慣習です。小規模なネットワークの場合、これを行うのに必要な作業は、プリンターに名前を付けるためにローカルまたはISPによってホストされているかどうかに関係なくDNSサービスを設定することによって、「適切に」行う場合の作業よりもはるかに少ないです。また、Service Location Protocol（SLP）[RFC2608]はプリンターの検出などのタスクで広く利用できますが、エンタープライズネットワークでは広く使用されていません。その結果、何らかの理由でプリンターの番号が変更された場合、すべてのユーザーのホストの手動構成を多くの企業で更新する必要があります。
In the case of IPv6, exactly the same situation would be created by numbering the printer statically under the site's Unique Local Address (ULA) prefix [RFC4193]. Although this address would not change if the site's globally routable prefix is changed, internal renumbering for any other reason would be troublesome. Additionally, the disadvantage compared to IPv4 is that an IPv6 address is harder to communicate reliably, compared to something as simple as "10.1.1.10". The process will be significantly more error-prone for IPv6.
IPv6の場合、サイトの一意のローカルアドレス（ULA）プレフィックス[RFC4193]の下でプリンターに静的に番号を付けることで、まったく同じ状況が発生します。サイトのグローバルにルーティング可能なプレフィックスが変更されてもこのアドレスは変更されませんが、その他の理由で内部の番号を付け直すのは面倒です。さらに、IPv4と比較した場合の短所は、IPv6アドレスは「10.1.1.10」のような単純なものと比較して、信頼性の高い通信が難しいことです。このプロセスでは、IPv6のエラーが大幅に発生しやすくなります。
If such a host is numbered out of a globally routable prefix that is potentially subject to renumbering, then a renumbering event will require a configuration change in all hosts using the device in question, and such configuration data are by no means stored in the network layer.
そのようなホストが再ルーティングされる可能性のあるグローバルにルーティング可能なプレフィックスから番号が付けられている場合、再番号付けイベントでは、問題のデバイスを使用するすべてのホストの構成を変更する必要があり、そのような構成データは決してネットワーク層に保存されません。 。
At least two simple alternatives exist to avoid static numbering of simple devices, such as printers, by giving them local names. One is the use of Multicast DNS (mDNS) [RFC6762] in combination with DNS Service Discovery [RFC6763]. The other is the Service Location Protocol [RFC2608]. Both of these solutions are widely implemented, but seemingly not widely deployed in enterprise networks.
ローカル名を与えることにより、プリンタなどの単純なデバイスの静的な番号付けを回避するために、少なくとも2つの単純な代替手段が存在します。 1つは、マルチキャストDNS（mDNS）[RFC6762]をDNSサービス検出[RFC6763]と組み合わせて使用することです。もう1つはService Location Protocol [RFC2608]です。これらのソリューションはどちらも広く実装されていますが、エンタープライズネットワークに広く展開されていないようです。
On larger sites, it is safe to assume that servers of all kinds, including printers, are identified in user configurations and applications by DNS names. However, it is very widespread operational practice that servers have static IP addresses. If they did not, whenever an address assigned by stateless address autoconfiguration [RFC4862] or DHCPv6 [RFC3315] expired, and if the address actually changed for some extraneous reason, sessions in progress might fail (depending on whether the address deprecation period was long enough).
大規模なサイトでは、プリンターを含むすべての種類のサーバーが、ユーザー構成およびアプリケーションでDNS名によって識別されると想定しても安全です。ただし、サーバーに静的IPアドレスを設定することは、非常に広く行われています。そうでない場合、ステートレスアドレス自動構成[RFC4862]またはDHCPv6 [RFC3315]によって割り当てられたアドレスが期限切れになるたびに、アドレスが実際に何らかの無関係な理由で変更された場合、進行中のセッションが失敗する可能性があります（アドレスの非推奨期間が十分長いかどうかによって異なります） ）。
DNS aspects of renumbering are discussed in more detail in [RFC6879]. Here, we note that one reason for widespread use of static server addresses is the lack of deployment of Secure Dynamic DNS update [RFC3007], or some other method of prompt DNS updates, in enterprise networks. A separate issue is that even with such updates in place, remote users of a server would attempt to use the wrong address until the DNS TTL expired, as discussed in [RFC4192].
再番号付けのDNSの側面は、[RFC6879]でより詳細に説明されています。ここで、静的サーバーアドレスが広く使用されている理由の1つは、エンタープライズネットワークでセキュアダイナミックDNSアップデート[RFC3007]、またはその他のプロンプトDNSアップデートの方法が導入されていないことです。別の問題は、[RFC4192]で説明されているように、このような更新が行われている場合でも、サーバーのリモートユーザーがDNS TTLが期限切れになるまで間違ったアドレスを使用しようとすることです。
Server addresses can be managed centrally, even if they are static, by using DHCPv6 in stateful mode to ensure that the same address is always assigned to a given server. Consistency with DNS can be ensured by generating both DHCPv6 data and DNS data from a common configuration database using a suitable configuration tool. This does normally carry the implication that the database also contains the hardware (Media Access Control (MAC)) addresses of the relevant LAN interfaces on the servers, so that the correct IPv6 address can be delivered whenever a server requests an address. Not every operator wishes to maintain such a costly database, however, and some sites are therefore likely today to fall back on manual configuration of server addresses as a result.
DHCPv6をステートフルモードで使用して、同じアドレスが常に特定のサーバーに割り当てられるようにすることで、サーバーアドレスが静的であっても集中管理できます。 DNSとの整合性は、適切な構成ツールを使用して、共通の構成データベースからDHCPv6データとDNSデータの両方を生成することによって保証できます。これは通常、データベースにサーバー上の関連するLANインターフェイスのハードウェア（メディアアクセス制御（MAC））アドレスも含まれているため、サーバーがアドレスを要求するたびに正しいIPv6アドレスを配信できることを意味します。ただし、すべてのオペレーターがこのような高額なデータベースを維持したいと思っているわけではないため、今日では一部のサイトがサーバーアドレスの手動構成にフォールバックする可能性があります。
In the event of renumbering the prefix covering such servers, the situation should be manageable if there is a common configuration database; the "without a flag day" procedure [RFC4192] could be followed. However, if there is no such database, a manual procedure would have to be adopted.
このようなサーバーをカバーするプレフィックスの番号を付け直す場合、共通の構成データベースがあれば、状況は管理できるはずです。 「旗の日なし」の手順[RFC4192]に従うことができた。ただし、そのようなデータベースがない場合は、手動の手順を採用する必要があります。
According to [PROBLEM], the placement and live migration of Virtual Machines (VMs) in a physical network requires that their IP addresses be fixed and static. Otherwise, when a VM is migrated to a different physical server, its IP address would change and transport sessions in progress would be lost. In effect, this is a special case of the previous one.
[問題]によれば、物理ネットワークでの仮想マシン（VM）の配置とライブマイグレーションでは、IPアドレスが固定されていて静的である必要があります。そうしないと、VMが別の物理サーバーに移行されると、そのIPアドレスが変更され、進行中のトランスポートセッションが失われます。実際には、これは前のケースの特別なケースです。
If VMs are numbered out of a prefix that is subject to renumbering, there is a direct conflict with application session continuity, unless a procedure similar to [RFC4192] is followed.
再番号付けの対象となるプレフィックスからVMに番号が付けられている場合、[RFC4192]と同様の手順に従わない限り、アプリケーションセッションの継続性と直接競合します。
There are some large (campus-sized) sites that not only capture the MAC addresses of servers in a configuration system, but also do so for desktop client machines with wired connections that are then given static IP addresses. Such hosts are not normally servers, so the two preceding cases do not apply. One motivation for this approach is straightforward asset management (Who has which computer?, Connected to which cable?). Another, more compelling, reason is security incident handling. If, as occurs with reasonable frequency on any large network, a particular host is found to be generating some form of unwanted traffic, it is urgent to be able to track back from its IP address to its physical location so that an appropriate intervention can be made. A static binding between the MAC address and the IPv6 address might be preferred for this purpose.
構成システム内のサーバーのMACアドレスをキャプチャするだけでなく、静的IPアドレスが付与された有線接続を備えたデスクトップクライアントマシンでもキャプチャする大規模な（キャンパスサイズの）サイトがいくつかあります。このようなホストは通常サーバーではないため、前述の2つのケースは当てはまりません。このアプローチの1つの動機は、簡単な資産管理です（誰がどのコンピューターを持っているか、どのケーブルに接続されているか）。さらに説得力のあるもう1つの理由は、セキュリティインシデントの処理です。大規模なネットワークで妥当な頻度で発生するように、特定のホストが何らかの形で不要なトラフィックを生成していることが判明した場合、適切な介入ができるように、IPアドレスから物理的な場所まで追跡できることが緊急です。製。このためには、MACアドレスとIPv6アドレス間の静的バインディングが適している場合があります。
Such users will not, in most circumstances, be significantly inconvenienced by prefix renumbering, as long as it follows the [RFC4192] procedure. The address deprecation mechanism would allow for clean termination of current sessions, including those in which their machine was actually operating as a server, e.g., for a peer-to-peer application. The only users who would be seriously affected would be those running extremely long transport sessions that might outlive the address deprecation period.
このようなユーザーは、[RFC4192]の手順に従っている限り、ほとんどの状況で、プレフィックスの再番号付けによって大きな不便を感じることはありません。アドレスの非推奨メカニズムにより、現在のセッションを完全に終了できます。これには、ピアツーピアアプリケーションなど、マシンが実際にサーバーとして動作していたセッションも含まれます。深刻な影響を受ける唯一のユーザーは、アドレスの非推奨期間を超える可能性のある、非常に長いトランスポートセッションを実行しているユーザーです。
Note that such large campus sites generally allocate addresses dynamically to wireless hosts, since (in an IPv4 world) addresses are scarce and allocating static addresses to intermittent users is not acceptable. Also, a wireless user may appear on different subnets at different times, so it cannot be given a single static address. These users will, in most circumstances, only be slightly inconvenienced, if at all, by prefix renumbering.
（IPv4の世界では）アドレスは不足しており、断続的なユーザーに静的アドレスを割り当てることは受け入れられないため、このような大規模なキャンパスサイトは通常、ワイヤレスホストに動的にアドレスを割り当てます。また、ワイヤレスユーザーは異なるサブネットに異なるタイミングで現れる可能性があるため、単一の静的アドレスを与えることはできません。これらのユーザーは、ほとんどの場合、プレフィックスの番号を付け直しても、少しでも不便です。
Although it has many disadvantages and cannot be recommended as a solution, software licensing based on IP addresses or prefixes is still quite widely used in various forms. It is to be expected that this practice will continue for IPv6. If so, there is no alternative to informing the licensing party of the new address(es) by whatever administrative process is required. In an RFC 4192 renumbering procedure, the licenses for the old and new addresses or prefixes would have to overlap.
これには多くの欠点があり、解決策としてはお勧めできませんが、IPアドレスまたはプレフィックスに基づくソフトウェアライセンスは、さまざまな形式で非常に広く使用されています。このプラクティスはIPv6でも継続すると予想されます。その場合は、必要な管理プロセスによって新しいアドレスをライセンスパーティに通知する以外の方法はありません。 RFC 4192の再番号付け手順では、新旧のアドレスまたはプレフィックスのライセンスは重複する必要があります。
If acceptable to the licensing mechanism, using addresses under an enterprise's ULA prefix for software licensing would avoid this problem.
ライセンスメカニズムに受け入れられる場合は、企業のULAプレフィックスの下のアドレスをソフトウェアライセンスに使用すると、この問題を回避できます。
Each interface of a router needs an IP address, and so do other network elements, such as firewalls, proxies, and load balancers. Since these are critical infrastructures, they must be monitored and in some cases controlled by a network management system. A conventional approach to this is to assign the necessary IP addresses statically, and to configure those addresses in the monitoring and management systems. It is common practice that some such addresses will have no corresponding DNS entry. If these addresses need to be changed, there will be considerable ramifications. A restart of the network element might be needed, interrupting all user sessions in progress. Simultaneously, the monitoring and management system configurations must be updated, and in the case of a default router, its clients must be informed. To avoid such disruption, network elements must be renumbered according to an [RFC4192] procedure, like any other host.
ルーターの各インターフェイスにはIPアドレスが必要であり、ファイアウォール、プロキシ、ロードバランサーなどの他のネットワーク要素も必要です。これらは重要なインフラストラクチャであるため、監視し、場合によってはネットワーク管理システムで制御する必要があります。これに対する従来のアプローチは、必要なIPアドレスを静的に割り当て、それらのアドレスを監視および管理システムで構成することです。このようなアドレスには、対応するDNSエントリがないことが一般的です。これらのアドレスを変更する必要がある場合、かなりの影響があります。ネットワーク要素の再起動が必要な場合があり、進行中のすべてのユーザーセッションを中断します。同時に、監視および管理システムの構成を更新する必要があります。デフォルトのルーターの場合は、そのクライアントに通知する必要があります。このような混乱を回避するには、他のホストと同様に、[RFC4192]手順に従ってネットワーク要素の番号を変更する必要があります。
There is a school of thought that to minimise renumbering problems for network elements and to keep the simplicity of static addressing for them, network elements should all have static ULA addresses for management and monitoring purposes, regardless of what other global addresses they may have.
ネットワーク要素の再番号付けの問題を最小限に抑え、静的アドレッシングのシンプルさを維持するために、ネットワーク要素には、他のグローバルアドレスに関係なく、管理と監視のために静的ULAアドレスが必要です。
Access Control Lists (ACLs) and other security mechanisms are often configured using static IP addresses. This may occur in network elements or hosts. If they are not updated promptly during a renumbering event, the result may be the opening of security loopholes, the blocking of legitimate traffic, or both. Such security loopholes may never be detected until they are successfully exploited.
アクセス制御リスト（ACL）やその他のセキュリティメカニズムは、多くの場合、静的IPアドレスを使用して構成されます。これは、ネットワーク要素またはホストで発生する可能性があります。番号の付け直しイベント中にそれらがすぐに更新されない場合、セキュリティループホールが開いたり、正当なトラフィックがブロックされたり、またはその両方が発生する可能性があります。このようなセキュリティの抜け穴は、悪用されるまで検出されない場合があります。
As noted in the Introduction, static addressing and manual address configuration are not the same thing. In terms of managing a renumbering event, static addressing derived automatically from a central database, e.g., by stateful DHCPv6, is clearly better than manual configuration by an administrator. This remains true even if the database itself requires manual changes, since, otherwise, an administrator would have to log in to every host concerned, a time-consuming and error-prone task. In cases where static addresses cannot be avoided, they could be assigned automatically from a central database using a suitable protocol, such as stateful DHCPv6. Clearly, the database needs to be supported by a suitable configuration tool, to minimise manual updates and to eliminate manual configuration of individual hosts.
「はじめに」で述べたように、静的アドレス指定と手動アドレス設定は同じものではありません。再番号付けイベントの管理に関しては、ステートフルDHCPv6などによって中央データベースから自動的に取得される静的アドレス指定は、管理者が手動で構成するよりも明らかに優れています。これは、データベース自体に手動の変更が必要な場合でも当てはまります。そうしないと、管理者は関係するすべてのホストにログインする必要があり、時間がかかり、エラーが発生しやすくなります。静的アドレスを回避できない場合は、ステートフルDHCPv6などの適切なプロトコルを使用して中央データベースから自動的に割り当てることができます。明らかに、手動更新を最小限に抑え、個々のホストの手動構成を排除するために、データベースは適切な構成ツールによってサポートされる必要があります。
If subnet prefixes are statically assigned, various network elements and the network management system must be updated when they are renumbered. To avoid loss of existing user sessions, the old prefixes need to be removed only after a period of overlap.
サブネットプレフィックスが静的に割り当てられている場合、さまざまなネットワーク要素とネットワーク管理システムは、番号が付け直されたときに更新する必要があります。既存のユーザーセッションが失われないようにするために、古いプレフィックスを削除する必要があるのは、一定の期間が経過した後だけです。
If a printer or similar local server is statically addressed, and has no DNS or mDNS name and no discovery protocol, renumbering will require configuration changes in all hosts using that server. Most likely, these changes will be manual; therefore, this type of configuration should be avoided except for very small networks. Even if the server is under a ULA prefix, any subnet rearrangement that causes it to be renumbered will have the same effect.
プリンターまたは同様のローカルサーバーが静的にアドレス指定され、DNSまたはmDNS名がなく、検出プロトコルがない場合、番号を付け直すには、そのサーバーを使用するすべてのホストで構成を変更する必要があります。ほとんどの場合、これらの変更は手動で行われます。したがって、非常に小規模なネットワークを除いて、このタイプの構成は避けてください。サーバーがULAプレフィックスの下にある場合でも、サーバーの番号が付け直される原因となるサブネットの再配置は同じ効果があります。
If a server with a DNS name is statically addressed via a common configuration database that supports both DHCPv6 and DNS, then it can be renumbered "without a flag day" by following RFC 4192. However, if there is no common configuration database, then present technology requires manual intervention. Similar considerations apply to virtual servers with static addresses.
DNS名を持つサーバーがDHCPv6とDNSの両方をサポートする共通の構成データベースを介して静的にアドレス指定されている場合、RFC 4192に従って「フラグ日なし」に番号を付け直すことができます。ただし、共通の構成データベースがない場合は、テクノロジーには手動による介入が必要です。静的アドレスを持つ仮想サーバーにも同様の考慮事項が適用されます。
If client computers, such as desktops, are statically addressed via a common configuration database and stateful DHCPv6, they can also be renumbered "without a flag day." But other statically addressed clients will need manual intervention, so DHCPv6 should be used if possible.
デスクトップなどのクライアントコンピューターが共通の構成データベースとステートフルDHCPv6を介して静的にアドレス指定されている場合は、「フラグ日なし」で番号を付け直すこともできます。ただし、静的にアドレス指定された他のクライアントは手動での介入が必要になるため、可能であればDHCPv6を使用する必要があります。
If address-based software licensing is unavoidable, requiring static addresses, and ULAs cannot be used for this case, an administrative procedure during renumbering seems unavoidable.
アドレスベースのソフトウェアライセンスが避けられず、静的アドレスが必要であり、この場合にULAを使用できない場合、番号を付け直す際の管理手順は避けられないようです。
If network elements have static addresses, the network management system and affected client hosts must be informed when they are renumbered. Even if a network element is under a ULA prefix, any subnet rearrangement that causes it to be renumbered will have the same effect.
ネットワーク要素に静的アドレスがある場合、ネットワーク管理システムと影響を受けるクライアントホストは、番号が付け直されたときに通知を受ける必要があります。ネットワーク要素がULAプレフィックスの下にある場合でも、番号が付け直される原因となるサブネットの再配置は同じ効果があります。
ACLs configured with static addresses must be updated during renumbering.
静的アドレスで構成されたACLは、番号を付け直すときに更新する必要があります。
It appears that the majority of the above problems can be largely mitigated if the following measures are taken:
上記の問題の大部分は、次の対策を講じれば大幅に軽減できると思われます。
1. The site uses a general configuration management database and an associated tool that manage all prefixes and all DHCPv6, DNS, and router and security configurations in a consistent and integrated way. Even if static addresses are used, they are always configured with this tool, and never manually. Specification of such a tool is out of scope for the present document.
1. このサイトでは、一般的な構成管理データベースと、すべてのプレフィックスとすべてのDHCPv6、DNS、ルーターとセキュリティの構成を一貫性のある統合された方法で管理する関連ツールを使用しています。静的アドレスが使用されている場合でも、それらは常にこのツールで構成され、手動で構成されることはありません。このようなツールの仕様は、このドキュメントの範囲外です。
2. All printers and other local servers are always accessed via a DNS or mDNS name, or via a discovery protocol. User computers are configured only with names for such servers and never with their addresses.
2. すべてのプリンタおよびその他のローカルサーバーは、常にDNSまたはmDNS名、または検出プロトコルを介してアクセスされます。ユーザーのコンピューターは、このようなサーバーの名前だけで構成され、アドレスで構成されることはありません。
3. Internal traffic uses a ULA prefix, such that disturbance to such traffic is avoided if the externally used prefix changes.
3. 内部トラフィックはULAプレフィックスを使用するため、外部で使用されるプレフィックスが変更された場合に、そのようなトラフィックへの妨害が回避されます。
4. If prefix renumbering is required, the RFC 4192 procedure is followed.
4. プレフィックスの再番号付けが必要な場合は、RFC 4192手順に従います。
Remaining open questions are:
残りの未解決の質問は次のとおりです。
1. Is minor residual loss of extremely long-living transport sessions during renumbering operationally acceptable?
1. 運用上、番号を付け直している間に、非常に長持ちするトランスポートセッションのわずかな残存損失は許容されますか？
2. Can automatic network element renumbering be performed without interrupting any user sessions?
2. ユーザーセッションを中断することなく、ネットワーク要素の自動再番号付けを実行できますか？
3. Do any software licensing systems require manual intervention?
3. ソフトウェアライセンスシステムには手動による介入が必要ですか？
This document does not define a protocol, so it does not introduce any new security exposures. However, security configurations, such as ACLs, are affected by the renumbering of static addresses.
このドキュメントではプロトコルを定義していないため、新しいセキュリティの危険性は紹介されていません。ただし、ACLなどのセキュリティ構成は、静的アドレスの再番号付けの影響を受けます。
Valuable comments and contributions were made by Ran Atkinson, Ralph Droms, Adrian Farrel, Wes George, Brian Haberman, Bing Liu, Pete Resnick, and other participants in the 6renum WG.
貴重なコメントと貢献は、Ran Atkinson、Ralph Droms、Adrian Farrel、Wes George、Brian Haberman、Bing Liu、Pete Resnick、および6renum WGの他の参加者によって行われました。
[GAP-ANALYSIS] Liu, B., Jiang, S., Carpenter, B., Venaas, S., and W. George, "IPv6 Site Renumbering Gap Analysis", Work in Progress, December 2012.
[ギャップ分析] Liu、B.、Jiang、S.、Carpenter、B.、Venaas、S。、およびW. George、「IPv6 Site Renumbering Gap Analysis」、Work in Progress、2012年12月。
[PREFIX] Baker, F. and R. Droms, "IPv6 Prefix Assignment in Small Networks", Work in Progress, March 2012.
[前置]ベイカー、F。およびR.ドロムス、「小規模ネットワークでのIPv6プレフィックス割り当て」、作業中、2012年3月。
[PROBLEM] Narten, T., Ed., Gray, E., Ed., Black, D., Dutt, D., Fang, L., Kreeger, L., Napierala, M., and M. Sridharan, "Problem Statement: Overlays for Network Virtualization", Work in Progress, October 2012.
[問題] Narten、T.、Ed。、Gray、E.、Ed。、Black、D.、Dutt、D.、Fang、L.、Kreeger、L.、Napierala、M。、およびM. Sridharan、「 Problem Statement：Overlays for Network Virtualization "、Work in Progress、2012年10月。
[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、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[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、「Service Location Protocol、バージョン2」、RFC 2608、1999年6月。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[RFC3007]ウェリントン、B。、「Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、2000年11月。
[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.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[RFC4192]ベイカー、F。、リア、E。、およびR.ドロムス、「フラグデーのない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、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月。
[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月。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887] Carpenter、B.、Atkinson、R。、およびH. Flinck、「Renumbering Still Needs Work」、RFC 5887、2010年5月。
[RFC6250] Thaler, D., "Evolution of the IP Model", RFC 6250, May 2011.
[RFC6250]ターラーD。、「IPモデルの進化」、RFC 6250、2011年5月。
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, February 2013.
[RFC6762] Cheshire、S。およびM. Krochmal、「マルチキャストDNS」、RFC 6762、2013年2月。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNSベースのサービスディスカバリ」、RFC 6763、2013年2月。
[RFC6879] Jiang, S., Liu, B., and B. Carpenter, "IPv6 Enterprise Network Renumbering Scenarios, Considerations, and Methods", RFC 6879, February 2013.
[RFC6879] Jiang、S.、Liu、B。、およびB. Carpenter、「IPv6 Enterprise Network Renumbering Scenarios、Considerations、and Methods」、RFC 6879、2013年2月。
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
Sheng Jiang Huawei Technologies Co., Ltd. Q14, Huawei Campus No.156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China
S横江hu Aはテクノロジー株式会社です。Q14、hu Aはキャンパス番号156です。i青道路H艾-Dイアン地区、北京100095 P.R.中国
EMail: jiangsheng@huawei.com