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）インターネット協会（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サイトローカルユニキャストアドレスの使用を取り巻く問題について説明し、正式にそれらを非難します。交換が標準化され、実施されるまで、この廃止は、その継続的な使用を防ぐことはできません。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります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」、彼らは接続をソケットアドレス構造体のアドレスを供給し、発行しようとするだろう、と彼らは記入しなかったため、呼び出しは失敗します"：5678：9ABC％1 FEC0 :: 1234" "サイト識別子" 変数、のようにアップ。例えば、時には1％、時には％2、問題はサイト識別子は、ホストインスタンスによって変化するという事実によって悪化する（ゾーン識別子の区切り文字として％文字を使用することは。[SCOPING]で指定され）、従ってホスト識別子をメモリに記憶されることができない、またはネームサーバから学びました。
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またはトレースルートのリクエスト、例えば、ソースまたは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ヘッダにこれらのアドレスを配置する以外にも、いくつかの非自明なリークを示しています。プライベートアドレスも無駄DNSインフラストラクチャの過負荷を、RFC 1918のリバース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.
あいまいなアドレスは、マルチ土地を選定ルータ上でかなり明白な影響を持っています。単一のルーティングテーブルで指定された古典的なルータ・アーキテクチャでは、出口インタフェースは、宛先アドレスの直接の関数です。ルータが複数のサイトに接続している場合は、サイトローカルパケットのルーティングは、パケットが到着したインターフェイスに依存します。インタフェースは、サイトに関連していることがあり、サイトローカルアドレスにルーティングエントリは、サイトに依存しています。これをサポートする通常の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.
要因の作成を駆動し、サイトの境界が地域やドメインのそれらを駆動する要因異なる設定 - ネットワーク管理の複雑さも、サイトが既存のルーティングを使用してサポートすることができても、そのようなドメインや領域としてconstructs--という事実によって増加されます。
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?
別にリンクローカルから、スコープの境界は不明確です。このサイトは何ですか？企業ネットワークの全体は、サイトで、またはサイトは、単一の地理的な場所に制限されていますか？多くのネットワーク今日はファイアウォールで分離内部領域と「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と/ハーバーマン]これらの利点はまた、例えば、代替アーキテクチャを得ることができると思われます。
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.
一つの疑問は、エニーキャストアドレス指定、残ります。彼らは与えられたエニーキャストアドレスが割り当てられている任意のホストに定義によって参照するため、エニーキャストアドレスは、工事によってあいまいです。リンクローカルまたはグローバルエニーキャストアドレスは、「コードで焼く」ことができます。さらなる研究が、リンクローカルとグローバルの間スコープでエニーキャストアドレスの必要性について必要とされます。
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]の改定から、とのリビジョンから実用として削除する必要がありますアーキテクチャ[RFC3513]をアドレッシングインターネットプロトコルバージョン6（IPv6）の。それらが更新された場合ならば、サイトローカルアドレスに付随する参照は、他の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に記載されているように、悪影響が漏れ、あいまいさや潜在的misroutingを介してネットワークのセキュリティに影響を与える可能性があります。
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.
サイトローカルユニキャストプレフィックスは、彼らが管理境界を横断するパケットを防ぐため、一般的なセキュリティ機能として表示されているファイアウォールルールとアドレス選択規則、でいくつかの遮断作用が可能になります。このようなブロックルールは、サイトローカルプレフィックスの予想される将来の交換を含む、任意のプレフィックスに設定することができます。これらのブロックルールが実際に施行されている場合は、サイトローカルプレフィックスの廃止は、セキュリティを危険にさらすことはありません。
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.
著者は、文書の最初のバージョンの彼らのレビューのためにフレッド・テンプリン、ピーターBieringer、Chirayuパテル、ペッカSavola、およびアランボドーに感謝したいと思います。セクション2.2のテキストは、アドレッシングローカルサイトの影響を説明するマーガレットワッサーマンによってバージョンから採取した2つの段落を含みます。アラン・デュランは、サイトローカルアドレスへの参照を作成し、既存のRFCを改訂する必要性を指摘しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.デアリング、 "インターネットプロトコルバージョン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.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[RFC2772] Rockell, R. and R. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000.
[RFC2772]ロッケル、R.とR.フィンク、 "6boneのバックボーンルーティングガイドライン"、RFC 2772、2000年2月。
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[RFC2894]クロフォード、M.、 "IPv6のルータリナンバリング"、RFC 2894、2000年8月。
[RFC3082] Kempf, J. and J. Goldschmidt, "Notification and Subscription for SLP", RFC 3082, March 2001.
[RFC3082]ケンプ、J.とJ.ゴールドシュミット、 "SLPの通知およびサブスクリプション"、RFC 3082、2001年3月。
[RFC3111] Guttman, E., "Service Location Protocol Modifications for IPv6", RFC 3111, May 2001.
[RFC3111]グットマン、E.、 "IPv6のサービスロケーションプロトコルの変更"、RFC 3111、2001年5月。
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport Relay Translator", RFC 3142, June 2001.
[RFC3142]萩野、J.及びK.山本の "IPv6からIPv4輸送リレー翻訳"、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.、ソリマン、H.、Loughney、J.、およびJ. Wiljakka、 "いくつかの第二および第三世代の細胞宿主のためのインターネット・プロトコル・バージョン6（IPv6）"、RFC 3316年4月2003。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、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]ギリガン、R.、トムソン、S.、バウンド、J.、マッキャン、J.、およびW.スティーブンス、 "IPv6の基本的なソケットインタフェース拡張"、RFC 3493、2003年2月。
[Hinden/Haberman] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", Work in Progress, June 2004.
[Hindenと/ハーバーマン] Hindenと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]デアリング、S.、ハーバーマン、B.、神明、T.、Nordmarkと、E.、およびB. Zill、 "IPv6のスコープアドレスアーキテクチャ"、進歩、2004年8月での作業。
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA
クリスチャンのHuitemaマイクロソフト社1つのマイクロソフト道、レドモンド、WA 98052-6399 USA
EMail: huitema@microsoft.com
メールアドレス：huitema@microsoft.com
Brian Carpenter IBM Corporation Sauemerstrasse 4 8803 Rueschlikon Switzerland
ブライアン・カーペンターIBMコーポレーションSauemerstrasse 4 8803リュシュリコンスイス
EMail: brc@zurich.ibm.com
メールアドレス：brc@zurich.ibm.com
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（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.
この文書とここに含まれている情報は、基礎とHEが表すCONTRIBUTOR、ORGANIZATION HE / S OR（もしあれば）後援されており、インターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示、「そのまま」で提供されていますOR情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証を含むがこれらに限定されないで、黙示。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。