[要約] RFC 3879は、サイトローカルアドレスの非推奨化に関するものであり、IPv6ネットワークでの使用を推奨しています。その目的は、グローバルなアドレス空間の使用を促進し、インターネットのスケーラビリティと運用の改善を図ることです。
Network Working Group C. Huitema
Request for Comments: 3879 Microsoft
Category: Standards Track B. Carpenter
IBM
September 2004
Deprecating Site Local Addresses
現場のローカルアドレスを非難します
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document describes the issues surrounding the use of IPv6 site-local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented.
このドキュメントでは、IPv6 Site-Local Unicastアドレスを元の形式で使用することを取り巻く問題について説明し、それらを正式に非難します。この非推奨は、交換が標準化され、実装されるまで、継続的な使用を妨げません。
For some time, the IPv6 working group has been debating a set of issues surrounding the use of "site local" addresses. In its meeting in March 2003, the group reached a measure of agreement that these issues were serious enough to warrant a replacement of site local addresses in their original form. Although the consensus was far from unanimous, the working group confirmed in its meeting in July 2003 the need to document these issues and the consequent decision to deprecate IPv6 site-local unicast addresses.
しばらくの間、IPv6ワーキンググループは、「サイトローカル」アドレスの使用を取り巻く一連の問題について議論してきました。2003年3月の会議で、グループは、これらの問題が元の形でサイトのローカルアドレスを置き換えることを保証するのに十分深刻であるという合意の尺度に達しました。コンセンサスは全会一致とはほど遠いものでしたが、ワーキンググループは、2003年7月の会議で、これらの問題を文書化する必要性と、IPv6サイトローカルユニキャストアドレスを非難する結果を記録する必要性を確認しました。
Site-local addresses are defined in the IPv6 addressing architecture [RFC3513], especially in section 2.5.6.
サイトローカルアドレスは、特にセクション2.5.6で、IPv6アドレスのアーキテクチャ[RFC3513]で定義されています。
The remainder of this document describes the adverse effects of site-local addresses according to the above definition, and formally deprecates them.
このドキュメントの残りの部分は、上記の定義に従ってサイトローカルアドレスの悪影響について説明し、それらを正式に非難します。
Companion documents will describe the goals of a replacement solution and specify a replacement solution. However, the formal deprecation allows existing usage of site-local addresses to continue until the replacement is standardized and implemented.
コンパニオンドキュメントでは、交換ソリューションの目標を説明し、交換ソリューションを指定します。ただし、正式な非推奨により、サイトローカルアドレスの既存の使用法は、交換が標準化され、実装されるまで継続することができます。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、BCP 14、RFC 2119 [RFC2119]に記載されているように解釈される。
Discussions in the IPv6 working group outlined several defects of the current site local addressing scope. These defects fall in two broad categories: ambiguity of addresses, and fuzzy definition of sites.
IPv6ワーキンググループでの議論は、現在のサイトのローカルアドレス指定範囲のいくつかの欠陥を概説しました。これらの欠陥は、アドレスのあいまいさとサイトのファジーな定義という2つの広範なカテゴリにあります。
As currently defined, site local addresses are ambiguous: an address such as FEC0::1 can be present in multiple sites, and the address itself does not contain any indication of the site to which it belongs. This creates pain for developers of applications, for the designers of routers and for the network managers. This pain is compounded by the fuzzy nature of the site concept. We will develop the specific nature of this pain in the following section.
現在定義されているように、サイトのローカルアドレスはあいまいです。FEC0:: 1などのアドレスは複数のサイトに存在することができ、アドレス自体にはそれが属するサイトの兆候は含まれていません。これにより、アプリケーションの開発者、ルーターの設計者、ネットワークマネージャーにとって痛みが生じます。この痛みは、サイトの概念のファジーな性質によって悪化します。次のセクションで、この痛みの特定の性質を発達させます。
Early feedback from developers indicates that site local addresses are hard to use correctly in an application. This is particularly true for multi-homed hosts, which can be simultaneously connected to multiple sites, and for mobile hosts, which can be successively connected to multiple sites.
開発者からの早期フィードバックは、サイトのローカルアドレスをアプリケーションで正しく使用するのが難しいことを示しています。これは、複数のサイトに同時に接続できるマルチホームホストと、複数のサイトに連続的に接続できるモバイルホストに特に当てはまります。
Applications would learn or remember that the address of some correspondent was "FEC0::1234:5678:9ABC", they would try to feed the address in a socket address structure and issue a connect, and the call will fail because they did not fill up the "site identifier" variable, as in "FEC0::1234:5678:9ABC%1". (The use of the % character as a delimiter for zone identifiers is specified in [SCOPING].) The problem is compounded by the fact that the site identifier varies with the host instantiation, e.g., sometimes %1 and sometimes %2, and thus that the host identifier cannot be remembered in memory, or learned from a name server.
アプリケーションは、一部の特派員の住所が「FEC0 :: 1234：5678：9ABC」であることを学び、覚えています。「FEC0 :: 1234：5678：9ABC％1」のように、「サイト識別子」変数を上げます。（ゾーン識別子の区切り文字としての％文字の使用は、[スコーピング]で指定されています。）問題は、サイト識別子がホストのインスタンス化、たとえば％1、時には％2、したがって、ホストのインスタンス化によって変化するという事実によって悪化します。ホスト識別子をメモリで記憶することも、名前サーバーから学習できないこと。
In short, the developer pain is caused by the ambiguity of site local addresses. Since site-local addresses are ambiguous, application developers have to manage the "site identifiers" that qualify the addresses of the hosts. This management of identifiers has proven hard to understand by developers, and also hard to execute by those developers who understand the concept.
要するに、開発者の痛みは、サイトのローカルアドレスのあいまいさによって引き起こされます。サイトローカルアドレスは曖昧であるため、アプリケーション開発者はホストのアドレスを適格にする「サイト識別子」を管理する必要があります。この識別子の管理は、開発者が理解しにくいことが証明されており、概念を理解している開発者によっても実行することは困難です。
Simple client/server applications that do share IP addresses at the application layer are made more complex by IPv6 site-local addressing. These applications need to make intelligent decisions about the addresses that should and shouldn't be passed across site boundaries. These decisions, in practice, require that the applications acquire some knowledge of the network topology. Site local addresses may be used when client and server are in the same site, but trying to use them when client and server are in different sites may result in unexpected errors (i.e., connection reset by peer) or the establishment of connections with the wrong node. The robustness and security implications of sending packets to an unexpected end-point will differ from application to application.
アプリケーションレイヤーでIPアドレスを共有するシンプルなクライアント/サーバーアプリケーションは、IPv6サイトローカルアドレス指定により複雑になります。これらのアプリケーションは、サイトの境界を越えて渡されるべきではないアドレスについてインテリジェントな決定を下す必要があります。これらの決定は、実際には、アプリケーションがネットワークトポロジに関する何らかの知識を取得することを要求しています。サイトのアドレスは、クライアントとサーバーが同じサイトにあるときに使用できますが、クライアントとサーバーが異なるサイトにあるときにそれらを使用しようとすると、予期しないエラー（つまり、ピアによる接続リセット）または間違った接続の確立が生じる可能性がありますノード。パケットを予期しないエンドポイントに送信することの堅牢性とセキュリティの意味は、アプリケーションごとに異なります。
Multi-party applications that pass IP addresses at the application layer present a particular challenge. Even if a node can correctly determine whether a single remote node belongs or not to the local site, it will have no way of knowing where those addresses may eventually be sent. The best course of action for these applications might be to use only global addresses. However, this would prevent the use of these applications on isolated or intermittently connected networks that only have site-local addresses available, and might be incompatible with the use of site-local addresses for access control in some cases.
アプリケーションレイヤーでIPアドレスを渡すマルチパーティアプリケーションは、特定の課題を提示します。ノードが単一のリモートノードがローカルサイトに属しているかどうかを正しく判断できる場合でも、これらのアドレスが最終的に送信される可能性があることを知る方法はありません。これらのアプリケーションの最良のアクションコースは、グローバルアドレスのみを使用することです。ただし、これにより、サイトローカルアドレスのみが利用可能な孤立したまたは断続的に接続されたネットワークでこれらのアプリケーションを使用することが妨げられ、場合によってはアクセス制御のためのサイトローカルアドレスの使用と互換性がない可能性があります。
In summary, the ambiguity of site local addresses leads to unexpected application behavior when application payloads carry these addresses outside the local site.
要約すると、サイトのローカルアドレスのあいまいさは、アプリケーションのペイロードがローカルサイトの外側にこれらのアドレスを運ぶ場合、予期しないアプリケーション動作につながります。
The management of IPv6 site local addresses is in many ways similar to the management of RFC 1918 [RFC1918] addresses in some IPv4 networks. In theory, the private addresses defined in RFC 1918 should only be used locally, and should never appear in the Internet. In practice, these addresses "leak". The conjunction of leaks and ambiguity ends up causing management problems.
IPv6サイトローカルアドレスの管理は、一部のIPv4ネットワークでのRFC 1918 [RFC1918]アドレスの管理と多くの点で似ています。理論的には、RFC 1918で定義されているプライベートアドレスはローカルでのみ使用されるべきであり、インターネットに表示されるべきではありません。実際には、これらのアドレス「リーク」。漏れとあいまいさの接続詞は、管理上の問題を引き起こすことになります。
Names and literal addresses of "private" hosts leak in mail messages, web pages, or files. Private addresses end up being used as source or destination of TCP requests or UDP messages, for example in DNS or trace-route requests, causing the request to fail, or the response to arrive at unsuspecting hosts.
「プライベート」ホストの名前とリテラルアドレスは、メールメッセージ、Webページ、またはファイルのリークをホストします。プライベートアドレスは、DNSやTrace-routeリクエストなど、TCPリクエストまたはUDPメッセージのソースまたは宛先として使用され、リクエストが失敗したり、疑いを持たないホストに到着する応答を引き起こします。
The experience with RFC 1918 addresses also shows some non trivial leaks, besides placing these addresses in IP headers. Private addresses also end up being used as targets of reverse DNS queries for RFC 1918, uselessly overloading the DNS infrastructure. In general, many applications that use IP addresses directly end up passing RFC 1918 addresses in application payloads, creating confusion and failures.
RFC 1918アドレスの経験は、これらのアドレスをIPヘッダーに配置することに加えて、いくつかの些細なリークも示しています。また、プライベートアドレスは、RFC 1918の逆DNSクエリのターゲットとして使用され、DNSインフラストラクチャを無意識に過負荷にします。一般に、IPアドレスを使用する多くのアプリケーションは、アプリケーションのペイロードでRFC 1918アドレスを直接渡すことになり、混乱と障害が生じます。
The leakage issue is largely unavoidable. While some applications are intrinsically scoped (e.g., Router Advertisement, Neighbor Discovery), most applications have no concept of scope, and no way of expressing scope. As a result, "stuff leaks across the borders". Since the addresses are ambiguous, the network managers cannot easily find out "who did it". Leaks are thus hard to fix, resulting in a lot of frustration.
漏れの問題はほとんど避けられません。一部のアプリケーションは本質的にスコープされていますが（例：ルーター広告、近隣発見）、ほとんどのアプリケーションには範囲の概念がなく、範囲を表現する方法もありません。その結果、「スタッフが国境を漏らします」。アドレスはあいまいなので、ネットワークマネージャーは「誰がそれをしたか」を簡単に見つけることができません。したがって、漏れは修正が困難であるため、多くのフラストレーションが生じます。
The ambiguity of site local addresses also creates complications for the routers. In theory, site local addresses are only used within a contiguous site, and all routers in that site can treat them as if they were not ambiguous. In practice, special mechanisms are needed when sites are disjoint, or when routers have to handle several sites.
サイトローカルアドレスのあいまいさは、ルーターの合併症も生成します。理論的には、サイトのローカルアドレスは隣接するサイト内でのみ使用され、そのサイトのすべてのルーターは曖昧ではないかのようにそれらを扱うことができます。実際には、サイトがばらばらになっている場合、またはルーターがいくつかのサイトを処理する必要がある場合、特別なメカニズムが必要です。
In theory, sites should never be disjoint. In practice, if site local addressing is used throughout a large network, some elements of the site will not be directly connected for example, due to network partitioning. This will create a demand to route the site-local packets across some intermediate network (such as the backbone area) that cannot be dedicated for a specific site. In practice, this leads to an extensive use of tunneling techniques, or the use of multi-sited routers, or both.
理論的には、サイトは決してばらばらすべきではありません。実際には、大規模なネットワーク全体でサイトのローカルアドレス指定が使用されている場合、ネットワークのパーティション化により、サイトの一部の要素は直接接続されません。これにより、特定のサイトに専念できない中間ネットワーク（バックボーン領域など）にサイトローカルパケットをルーティングする需要が生じます。実際には、これはトンネル技術の広範な使用、またはマルチサイズのルーターの使用、またはその両方につながります。
Ambiguous addresses have fairly obvious consequences on multi-sited routers. In classic router architecture, the exit interface is a direct function of the destination address, as specified by a single routing table. However, if a router is connected to multiple sites, the routing of site local packets depends on the interface on which the packet arrived. Interfaces have to be associated to sites, and the routing entries for the site local addresses are site-dependent. Supporting this requires special provisions in routing protocols and techniques for routing and forwarding table virtualization that are normally used for VPNs. This contributes to additional complexity of router implementation and management.
あいまいなアドレスは、マルチサイズのルーターにかなり明らかな結果をもたらします。クラシックルーターアーキテクチャでは、Exitインターフェイスは、単一のルーティングテーブルで指定されているように、宛先アドレスの直接関数です。ただし、ルーターが複数のサイトに接続されている場合、サイトローカルパケットのルーティングは、パケットが到着したインターフェイスに依存します。インターフェイスはサイトに関連付けられている必要があり、サイトのローカルアドレスのルーティングエントリはサイトに依存します。これをサポートするには、通常VPNに使用されるルーティングおよび転送テーブル仮想化のためのルーティングプロトコルと手法に特別な規定が必要です。これは、ルーターの実装と管理の追加の複雑さに貢献します。
Network management complexity is also increased by the fact that though sites could be supported using existing routing constructs-- such as domains and areas--the factors driving creation and setting the boundaries of sites are different from the factors driving those of areas and domains.
ネットワーク管理の複雑さは、ドメインやエリアなどの既存のルーティングコンストラクトを使用してサイトをサポートできますが、サイトの作成を促進し、サイトの境界を設定する要因は、エリアとドメインの要因を促進する要因とは異なります。
In multi-homed routers, such as for example site border routers, the forwarding process should be complemented by a filtering process, to guarantee that packets sourced with a site local address never leave the site. This filtering process will in turn interact with the forwarding of packets, for example if implementation defects cause the drop of packets sent to a global address, even if that global address happen to belong to the target site.
サイトボーダールーターなどのマルチホームのルーターでは、フィルタリングプロセスによって転送プロセスを補完する必要があります。このフィルタリングプロセスは、たとえば、実装の欠陥がグローバルアドレスに送信されたパケットのドロップを引き起こす場合、たとえそのグローバルアドレスがターゲットサイトに属している場合でも、パケットの転送と相互作用します。
In summary, the ambiguity of site local addresses makes them hard to manage in multi-sited routers, while the requirement to support disjoint sites and existing routing protocol constructs creates a demand for such routers.
要約すると、サイトのローカルアドレスのあいまいさにより、マルチサイズのルーターでの管理が困難になります。一方、分離サイトと既存のルーティングプロトコルコンストラクトをサポートする要件は、そのようなルーターの需要を生み出します。
The current definition of scopes follows an idealized "concentric scopes" model. Hosts are supposed to be attached to a link, which belongs to a site, which belongs to the Internet. Packets could be sent to the same link, the same site, or outside that site. However, experts have been arguing about the definition of sites for years and have reached no sort of consensus. That suggests that there is in fact no consensus to be reached.
スコープの現在の定義は、理想化された「同心のスコープ」モデルに従います。ホストは、インターネットに属するサイトに属するリンクに接続されることになっています。パケットは、同じリンク、同じサイト、またはそのサイトの外側に送信できます。しかし、専門家は長年サイトの定義について議論しており、一種のコンセンサスに達していません。それは、実際には到達するコンセンサスがないことを示唆しています。
Apart from link-local, scope boundaries are ill-defined. What is a site? Is the whole of a corporate network a site, or are sites limited to single geographic locations? Many networks today are split between an internal area and an outside facing "DMZ", separated by a firewall. Servers in the DMZ are supposedly accessible by both the internal hosts and external hosts on the Internet. Does the DMZ belong to the same site as the internal host?
Link-Localとは別に、スコープ境界は不明確です。サイトとは何ですか？コーポレートネットワーク全体はサイトですか、それともサイトは単一の地理的場所に限定されていますか？今日の多くのネットワークは、ファイアウォールで区切られた内部領域と「DMZ」に面した「DMZ」に面した外側の間に分割されています。DMZのサーバーは、インターネット上の内部ホストと外部ホストの両方がアクセスできると思われます。DMZは内部ホストと同じサイトに属しますか？
Depending on whom we ask, the definition of the site scope varies. It may map security boundaries, reachability boundaries, routing boundaries, QOS boundaries, administrative boundaries, funding boundaries, some other kinds of boundaries, or a combination of these. It is very unclear that a single scope could satisfy all these requirements.
誰に尋ねるかによって、サイトの範囲の定義は異なります。セキュリティの境界、到達可能性の境界、ルーティング境界、QoS境界、管理境界、資金調達境界、その他の種類の境界、またはこれらの組み合わせをマッピングする場合があります。単一のスコープがこれらすべての要件を満たすことができることは非常に不明です。
There are some well known and important scope-breaking phenomena, such as intermittently connected networks, mobile nodes, mobile networks, inter-domain VPNs, hosted networks, network merges and splits, etc. Specifically, this means that scope *cannot* be mapped into concentric circles such as a naive link/local/global model. Scopes overlap and extend into one another. The scope relationship between two hosts may even be different for different protocols.
断続的に接続されたネットワーク、モバイルノード、モバイルネットワーク、インタードメインVPN、ホストネットワーク、ネットワーク合併、スプリットなど、いくつかのよく知られた重要な範囲を破る現象があります。特に、これはスコープ *がマッピングできないことを意味しますナイーブリンク/ローカル/グローバルモデルなどの同心円に。スコープは重複して互いに拡張します。2つのホスト間のスコープ関係は、プロトコルによって異なる場合があります。
In summary, the current concept of site is naive, and does not map operational requirements.
要約すると、サイトの現在の概念は素朴であり、運用要件をマッピングしません。
The previous section reviewed the arguments against site-local addresses. Obviously, site locals also have some benefits, without which they would have been removed from the specification long ago. The perceived benefits of site local are that they are simple, stable, and private. However, it appears that these benefits can be also obtained with an alternative architecture, for example [Hinden/Haberman], in which addresses are not ambiguous and do not have a simple explicit scope.
前のセクションでは、サイトローカルアドレスに対する議論をレビューしました。明らかに、サイトの地元の人々にもいくつかの利点があり、それなしでは彼らはずっと前に仕様から削除されていたでしょう。地元のサイトの知覚された利点は、それらがシンプルで安定していて、プライベートであるということです。ただし、これらの利点は、たとえば[Hinden/Haberman]などの代替アーキテクチャでも取得できるように見えます。
Having non-ambiguous address solves a large part of the developers' pain, as it removes the need to manage site identifiers. The application can use the addresses as if they were regular global addresses, and the stack will be able to use standard techniques to discover which interface should be used. Some level of pain will remain, as these addresses will not always be reachable; however, applications can deal with the un-reachability issues by trying connections at a different time, or with a different address. Speculatively, a more sophisticated scope mechanism might be introduced at a later date.
非曖昧な住所を持つことは、サイト識別子を管理する必要性を排除するため、開発者の痛みの大部分を解決します。アプリケーションは、アドレスを通常のグローバルアドレスであるかのように使用でき、スタックは標準手法を使用して使用するインターフェイスを発見することができます。これらのアドレスが常に到達できるとは限らないため、ある程度の痛みが残ります。ただし、アプリケーションは、別の時間に接続を試すか、別のアドレスを使用することにより、非通信可能性の問題に対処できます。投機的に、より洗練されたスコープメカニズムが後日導入される場合があります。
Having non ambiguous addresses will not eliminate the leaks that cause management pain. However, since the addresses are not ambiguous, debugging these leaks will be much simpler.
曖昧でないアドレスを持つことは、管理の痛みを引き起こす漏れを排除しません。ただし、アドレスは曖昧ではないため、これらの漏れをデバッグするのははるかに簡単になります。
Having non ambiguous addresses will solve a large part of the router issues: since addresses are not ambiguous, routers will be able to use standard routing techniques, and will not need different routing tables for each interface. Some of the pain will remain at border routers, which will need to filter packets from some ranges of source addresses; this is however a fairly common function.
曖昧でないアドレスを持つことで、ルーターの問題の大部分が解決されます。アドレスはあいまいではないため、ルーターは標準的なルーティングテクニックを使用でき、インターフェイスごとに異なるルーティングテーブルは必要ありません。痛みの一部は、ボーダールーターに残ります。これは、いくつかの範囲のソースアドレスからパケットをフィルタリングする必要があります。ただし、これはかなり一般的な機能です。
Avoiding the explicit declaration of scope will remove the issues linked to the ambiguity of the site concept. Non-reachability can be obtained by using "firewalls" where appropriate. The firewall rules can explicitly accommodate various network configurations, by accepting of refusing traffic to and from ranges of the new non-ambiguous addresses.
範囲の明示的な宣言を回避すると、サイトの概念のあいまいさにリンクされた問題が削除されます。必要に応じて「ファイアウォール」を使用することにより、非到達性を取得できます。ファイアウォールルールは、新しい非曖昧なアドレスの範囲との間でトラフィックを拒否することを受け入れることにより、さまざまなネットワーク構成に明示的に対応できます。
One question remains, anycast addressing. Anycast addresses are ambiguous by construction, since they refer by definition to any host that has been assigned a given anycast address. Link-local or global anycast addresses can be "baked in the code". Further study is required on the need for anycast addresses with scope between link-local and global.
1つの質問が残り、Anycastアドレス指定。Anycastアドレスは、特定のAnycastアドレスを割り当てられたホストに定義上紹介するため、建設により曖昧です。Link-LocalまたはGlobal Anycastアドレスは、「コードで焼き付け」できます。Link-LocalとGlobalの間の範囲を持つAnycastアドレスの必要性については、さらなる研究が必要です。
This document formally deprecates the IPv6 site-local unicast prefix defined in [RFC3513], i.e., 1111111011 binary or FEC0::/10. The special behavior of this prefix MUST no longer be supported in new implementations. The prefix MUST NOT be reassigned for other use except by a future IETF standards action. Future versions of the addressing architecture [RFC3513] will include this information.
このドキュメントは、[RFC3513]で定義されているIPv6サイトローカルユニキャストプレフィックス、つまり1111111011バイナリまたはFEC0 ::/10を正式に廃止します。このプレフィックスの特別な動作は、新しい実装ではサポートされていない必要があります。プレフィックスは、将来のIETF標準アクションによる場合を除き、他の使用のために再割り当てしてはなりません。アドレス指定アーキテクチャ[RFC3513]の将来のバージョンには、この情報が含まれます。
However, router implementations SHOULD be configured to prevent routing of this prefix by default.
ただし、デフォルトでこのプレフィックスのルーティングを防ぐようにルーターの実装を構成する必要があります。
The references to site local addresses should be removed as soon as practical from the revision of the Default Address Selection for Internet Protocol version 6 [RFC3484], the revision of the Basic Socket Interface Extensions for IPv6 [RFC3493], and from the revision of the Internet Protocol Version 6 (IPv6) Addressing Architecture [RFC3513]. Incidental references to site local addresses should be removed from other IETF documents if and when they are updated. These documents include [RFC2772, RFC2894, RFC3082, RFC3111, RFC3142, RFC3177, and RFC3316].
サイトローカルアドレスへの参照は、インターネットプロトコルバージョン6 [RFC3484]のデフォルトアドレス選択の改訂、IPv6 [RFC3493]の基本ソケットインターフェイス拡張の改訂、および、および、およびその改訂版の改訂から、すぐに削除する必要があります。インターネットプロトコルバージョン6（IPv6）アーキテクチャへの対処[RFC3513]。サイトのローカルアドレスへの偶発的な参照は、更新された場合、他のIETFドキュメントから削除する必要があります。これらの文書には、[RFC2772、RFC2894、RFC3082、RFC3111、RFC3142、RFC3177、およびRFC3316]が含まれます。
Existing implementations and deployments MAY continue to use this prefix.
既存の実装と展開は、このプレフィックスを引き続き使用する場合があります。
The use of ambiguous site-local addresses has the potential to adversely affect network security through leaks, ambiguity and potential misrouting, as documented in section 2. Deprecating the use of ambiguous addresses helps solving many of these problems.
セクション2で文書化されているように、曖昧なサイトローカルアドレスの使用は、漏れ、あいまいさ、潜在的な誤った誤った誤りを通じてネットワークセキュリティに悪影響を与える可能性があります。
The site-local unicast prefix allows for some blocking action in firewall rules and address selection rules, which are commonly viewed as a security feature since they prevent packets crossing administrative boundaries. Such blocking rules can be configured for any prefix, including the expected future replacement for the site-local prefix. If these blocking rules are actually enforced, the deprecation of the site-local prefix does not endanger security.
Site-Local Unicastプレフィックスは、ファイアウォールルールでのブロッキングアクションを可能にし、選択ルールに対処します。これは、パケットが管理境界を通過するのを防ぐため、一般的にセキュリティ機能と見なされます。このようなブロッキングルールは、サイトローカルプレフィックスの予想される将来の交換を含む、任意のプレフィックスに対して構成できます。これらのブロッキングルールが実際に施行されている場合、サイトローカルプレフィックスの非推奨はセキュリティを危険にさらしません。
IANA is requested to mark the FEC0::/10 prefix as "deprecated", pointing to this document. Reassignment of the prefix for any usage requires justification via an IETF Standards Action [RFC2434].
IANAは、FEC0 ::/10プレフィックスを「非推奨」としてマークするように要求され、このドキュメントを指しています。使用するためのプレフィックスの再割り当てには、IETF標準アクション[RFC2434]を介して正当化が必要です。
The authors would like to thank Fred Templin, Peter Bieringer, Chirayu Patel, Pekka Savola, and Alain Baudot for their review of the initial version of the document. The text of section 2.2 includes 2 paragraphs taken from a version by Margaret Wasserman describing the impact of site local addressing. Alain Durand pointed out the need to revise existing RFC that make reference to site local addresses.
著者は、ドキュメントの初期バージョンのレビューをしてくれたフレッド・テンプリン、ピーター・ビーリンガー、チラユ・パテル、ペッカ・サヴォラ、アラン・ボーコットに感謝したいと思います。セクション2.2のテキストには、Margaret Wassermanによるバージョンから取られた2つの段落が含まれています。Alain Durandは、サイトのローカルアドレスを参照する既存のRFCを修正する必要性を指摘しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513] Hinden、R。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2772] Rockell, R. and R. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000.
[RFC2772] Rockell、R。およびR. Fink、「6boneバックボーンルーティングガイドライン」、RFC 2772、2000年2月。
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[RFC2894] Crawford、M。、「IPv6の変更ルーター」、RFC 2894、2000年8月。
[RFC3082] Kempf, J. and J. Goldschmidt, "Notification and Subscription for SLP", RFC 3082, March 2001.
[RFC3082] Kempf、J。およびJ. Goldschmidt、「SLPの通知とサブスクリプション」、RFC 3082、2001年3月。
[RFC3111] Guttman, E., "Service Location Protocol Modifications for IPv6", RFC 3111, May 2001.
[RFC3111] Guttman、E。、「IPv6のサービスロケーションプロトコル変更」、RFC 3111、2001年5月。
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport Relay Translator", RFC 3142, June 2001.
[RFC3142] Hagino、J。およびK. Yamamoto、「IPv6-to-IPV4 Transport Relay Translator」、RFC 3142、2001年6月。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address", RFC 3177, September 2001.
[RFC3177] IABおよびIESG、「IPv6アドレスに関するIAB/IESG推奨」、RFC 3177、2001年9月。
[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, "Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts", RFC 3316, April 2003.
[RFC3316] Arkko、J.、Kuijpers、G.、Soliman、H.、Loughney、J.、およびJ. Wiljakka、「インターネットプロトコルバージョン6（IPv6）2番目および第3世代のセルラー宿主のための」、RFC 3316、4月2003年。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493] Gilligan、R.、Thomson、S.、Bound、J.、McCann、J。、およびW. Stevens、「IPv6の基本ソケットインターフェイス拡張」、RFC 3493、2003年2月。
[Hinden/Haberman] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", Work in Progress, June 2004.
[ヒンデン/ハーバーマン]ヒンデン、R。およびB.ハーバーマン、「ユニークなローカルIPv6ユニキャストアドレス」、2004年6月、進行中の作業。
[SCOPING] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", Work in Progress, August 2004.
[Scoping] Deering、S.、Haberman、B.、Jinmei、T.、Nordmark、E。、およびB. Zill、「IPv6スコープアドレスアーキテクチャ」、2004年8月の作業。
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA
Christian Huitema Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399 USA
EMail: huitema@microsoft.com
Brian Carpenter IBM Corporation Sauemerstrasse 4 8803 Rueschlikon Switzerland
ブライアンカーペンターIBMコーポレーションSauemerstrasse 4 8803 Rueschlikon Switzerland
EMail: brc@zurich.ibm.com
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」と貢献者、彼が代表する組織（もしあれば）が後援する組織、インターネット社会、インターネットエンジニアリングタスクフォースがすべての保証を拒否し、表明または、ここでの情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。