RFC3879 日本語訳
3879 Deprecating Site Local Addresses. C. Huitema, B. Carpenter. September 2004. (Format: TXT=24142 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Huitema Request for Comments: 3879 Microsoft Category: Standards Track B. Carpenter IBM September 2004
Huitemaがコメントのために要求するワーキンググループC.をネットワークでつないでください: 3879年のマイクロソフトカテゴリ: 標準化過程B.大工IBM2004年9月
Deprecating Site Local Addresses
サイトのローカルのアドレスを非難します。
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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サイトローカルのユニキャストアドレスの使用を囲む問題について説明して、正式にそれらを非難します。 交換が標準化されて、実装されるまで、この不賛成は彼らの継続的な使用を防ぎません。
1. Introduction
1. 序論
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ワーキンググループは「サイト地方」のアドレスの使用を囲む1セットの問題について討論しています。 2003年3月のミーティングでは、グループはこれらの問題が元の形のままサイトのローカルのアドレスの交換を保証できるくらい重大であったという協定の手段に達しました。 コンセンサスは全く満場一致ではありませんでしたが、ワーキンググループはミーティングでこれらの問題を記録する2003年7月の必要性とIPv6のサイトローカルのユニキャストアドレスを非難するという結果の決定を確認しました。
Site-local addresses are defined in the IPv6 addressing architecture [RFC3513], especially in section 2.5.6.
サイトローカルのアドレスはアーキテクチャが[RFC3513]であると扱うIPv6と、特にセクション2.5.6で定義されます。
The remainder of this document describes the adverse effects of site-local addresses according to the above definition, and formally deprecates them.
このドキュメントの残りは、上の定義に従ってサイトローカルのアドレスの悪影響について説明して、正式にそれらを非難します。
Huitema & Carpenter Standards Track [Page 1] RFC 3879 Deprecating Site Local Addresses September 2004
Huitemaと2004年9月にサイトのローカルのアドレスを非難する大工標準化過程[1ページ]RFC3879
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14RFC2119[RFC2119]で説明されるように本書では解釈されることであるべきです。
2. Adverse Effects of Site Local Addresses
2. サイトのローカルのアドレスの悪影響
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は複数のサイトに存在している場合があります、そして、アドレス自体はそれが属するサイトのどんなしるしも保管していません。 これはアプリケーションの開発者、ルータのデザイナー、およびネットワークマネージャに関する痛みを引き起こします。 この痛みはサイト概念のあいまいな本質によって悪化させられます。 私たちは以下のセクションのこの痛みの特定の自然を開発するつもりです。
2.1. Developer Pain, Scope Identifiers
2.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」、彼らはaが接続して、彼らが「サイト識別子」を満たさなかったので呼び出しが失敗するソケットアドレス構造と問題のアドレスを可変に与えようとするでしょう、コネとして「FEC0:、:、」1234:5678:9ABC%、1インチ。 (デリミタとしての%キャラクタのゾーン識別子の使用は[SCOPING]で指定されます。) その結果、ホスト識別子についてサイト識別子がホスト具体化で異なって、例えば、時々%が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
要するに、開発者痛みはサイトのローカルのアドレスのあいまいさによって引き起こされます。 サイトローカルのアドレスがあいまいであるので、アプリケーション開発者は資格を得る「サイト識別子」を管理しなければなりません。
Huitema & Carpenter Standards Track [Page 2] RFC 3879 Deprecating Site Local Addresses September 2004
Huitemaと2004年9月にサイトのローカルのアドレスを非難する大工標準化過程[2ページ]RFC3879
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.
ホストのアドレス。 識別子のこの管理は概念を理解している開発者で実行するのも開発者で分かりにくくて、また、困難であると判明しました。
2.2. Developer Pain, Local Addresses
2.2. 開発者痛み、ローカルのアドレス
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.
IPv6のサイトローカルのアドレシングで応用層でIPアドレスを共有する簡単なクライアント/サーバ・アプリケーションをより複雑にします。 これらのアプリケーションは、通過されるべきであり、サイト境界の向こう側に通過されるべきでないアドレスは知的な決定をする必要があります。 これらの決定は、実際にはアプリケーションがネットワーク形態に関する何らかの知識を習得するのを必要とします。 クライアントとサーバが同じサイトにあるとき、サイトのローカルのアドレスは使用されるかもしれませんが、クライアントとサーバが異なったサイトにあるとき、それらを使用しようとするなら、予期せぬエラー(すなわち、同輩によってリセットされた接続)か間違ったノードとの接続の設立がもたらされるかもしれません。 予期していなかったエンドポイントへの送付パケットの丈夫さとセキュリティ含意はアプリケーションからアプリケーションまで異なるでしょう。
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.
アプリケーションペイロードがローカル・サイトの外までこれらのアドレスを運ぶとき、概要では、サイトのローカルのアドレスのあいまいさは予期していなかったアプリケーションの振舞いにつながります。
2.3. Manager Pain, Leaks
2.3. マネージャ痛み、漏出
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ネットワークにおけるRFC1918[RFC1918]アドレスの管理と同様の多くの方法であります。 理論上、RFC1918で定義されたプライベート・アドレスは、局所的に使用されるだけであるべきであり、インターネットに決して現れるべきではありません。 実際には、これらのアドレスは「漏れます」。 漏出とあいまいさの接続詞は結局、管理問題を引き起こします。
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.
「個人的な」ホストの名前と文字通りのアドレスはメール・メッセージ、ウェブページ、またはファイルを漏らせます。 結局TCP要求かUDPメッセージのソースか目的地としてプライベート・アドレスは使用されます、例えば、DNSかトレースルート要求で、失敗するという要求、または応答が疑わないホストに到着することを引き起こして。
Huitema & Carpenter Standards Track [Page 3] RFC 3879 Deprecating Site Local Addresses September 2004
Huitemaと2004年9月にサイトのローカルのアドレスを非難する大工標準化過程[3ページ]RFC3879
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.
また、さらにこれらのアドレスをIPヘッダーに置いて、RFC1918の経験は、ショーがいくつかの非些細な漏出であると扱います。 また、結局RFC1918に逆のDNS質問の目標としてプライベート・アドレスは使用されます、無益にDNSインフラストラクチャを積みすぎて。 一般に、IPアドレスを使用する多くのアプリケーションが結局直接アプリケーションペイロードのアドレスをRFC1918に通過します、混乱と失敗を作成して。
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.
漏出問題は主に避けられません。 いくつかのアプリケーションが本質的に見られている間(例えば、Router Advertisement、Neighborディスカバリー)、ほとんどのアプリケーションには、範囲にもかかわらず、範囲を急送する方法がない概念が全くありません。 その結果、「境界の向こう側に漏出を詰めてください。」 アドレスがあいまいであるので、ネットワークマネージャは、「だれがそれをしましたか。」と容易に見つけることができません。 その結果、多くのフラストレーションをもたらして、漏出は修理しにくいです。
2.4. Router Pain, Increased Complexity
2.4. ルータ痛み、増強された複雑さ
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.
あいまいなアドレスはマルチ位置しているルータに明白な結果を公正に持っています。 古典的なルータアーキテクチャでは、出口インタフェースは送付先アドレスの一次関数です、単一の経路指定テーブルによって指定されるように。 しかしながら、ルータが複数のサイトに関連づけられるなら、サイトの地方のパケットのルーティングはパケットが到着したインタフェースによります。 インタフェースはサイトに関連づけられなければなりません、そして、サイトのローカルのアドレスのためのルーティングエントリーはサイト依存しています。 これをサポートするのは通常、VPNsに使用されるルーティングと推進テーブル仮想化のためにルーティング・プロトコルとテクニックで特別条項を必要とします。 これはルータ実装と管理の追加複雑さに貢献します。
Huitema & Carpenter Standards Track [Page 4] RFC 3879 Deprecating Site Local Addresses September 2004
Huitemaと2004年9月にサイトのローカルのアドレスを非難する大工標準化過程[4ページ]RFC3879
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.
概要では、サイトのローカルのアドレスのあいまいさは、マルチ位置しているルータでそれらを管理するのを困難にします、サポートする要件がサイトをばらばらにならせます、そして、プロトコル構造物を発送しながら存在するのはそのようなルータの要求を作成しますが。
2.5. Site is an Ill-Defined Concept
2.5. サイトはIllによって定義されたConceptです。
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は内部のホストと同じサイトに属しますか?
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
ネットワークが断続的に接続されたネットワーク、モバイルノード、モバイルネットワーク、相互ドメインVPNs、接待されたネットワークなどのように合併するいくつかのよく知られていて重要な範囲を壊す現象と股割りなどがあります。 明確に、これが、範囲*がそうすることができないことを意味する、*写像されてください。
Huitema & Carpenter Standards Track [Page 5] RFC 3879 Deprecating Site Local Addresses September 2004
Huitemaと2004年9月にサイトのローカルのアドレスを非難する大工標準化過程[5ページ]RFC3879
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.
地方の、または、ナイーブなリンク/グローバルなモデルなどの同心円に。 範囲は、お互いに重なって、広がっています。 異なったプロトコルにおいて、2人のホストの間の範囲関係は異なりさえするかもしれません。
In summary, the current concept of site is naive, and does not map operational requirements.
概要では、サイトの現在の概念は、ナイーブであり、操作上の要件を写像しません。
3. Development of a Better Alternative
3. より良い代替手段の開発
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.
範囲の明示宣言を避けると、サイト概念のあいまいさにリンクされた問題は取り除かれるでしょう。 適切であるところで「ファイアウォール」を使用することによって、非の可到達性を得ることができます。 ファイアウォール規則は明らかに様々なネットワーク・コンフィギュレーションを収容できます、範囲と新しい非あいまいなアドレスの範囲からトラフィックを拒否するのを受け入れることによって。
Huitema & Carpenter Standards Track [Page 6] RFC 3879 Deprecating Site Local Addresses September 2004
Huitemaと2004年9月にサイトのローカルのアドレスを非難する大工標準化過程[6ページ]RFC3879
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アドレスが割り当てられたどんなホストについても言及するので。 リンク地方の、または、グローバルなanycastアドレスを「コードにおける焼くことができます」。 リンク地方でグローバルであることの間には、範囲がある状態で、さらなる研究がanycastアドレスの必要性で必要です。
4. Deprecation
4. 不賛成
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]、1111111011バイナリーで定義されたIPv6のサイトローカルのユニキャスト接頭語かFEC0を非難します:、:/10. もう新しい実装でこの接頭語の特別な振舞いをサポートしてはいけません。 今後のIETF規格動作以外に、他の使用のために接頭語を再選任してはいけません。 アドレッシング体系[RFC3513]の将来のバージョンはこの情報を含むでしょう。
However, router implementations SHOULD be configured to prevent routing of this prefix by default.
しかしながら、ルータ実装SHOULD、構成されて、デフォルトでこの接頭語のルーティングを防いでください。
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].
サイトのローカルのアドレスの参照は同じくらいすぐDefault Address Selectionの改正によってインターネットプロトコルバージョン6[RFC3484]に実用的に取り除かれるべきです、IPv6[RFC3493]と、インターネットプロトコルバージョン6の改正(IPv6)からのBasic Socket Interface Extensionsの改正がArchitecture[RFC3513]を扱って。 それらをアップデートするなら、他のIETFドキュメントからサイトのローカルのアドレスの付帯的な参照を取り除くべきです。 これらのドキュメントは[RFC2772、RFC2894、RFC3082、RFC3111、RFC3142、RFC3177、およびRFC3316]を含んでいます。
Existing implementations and deployments MAY continue to use this prefix.
既存の実装と展開は、この接頭語を使用し続けるかもしれません。
5. Security Considerations
5. セキュリティ問題
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.
あいまいなサイトローカルのアドレスの使用には、漏出、あいまいさ、および潜在的misroutingでネットワークセキュリティに悪影響を与える可能性があります、セクション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.
サイトローカルのユニキャスト接頭語はファイアウォール規則とアドレス選択規則で何らかのブロッキング動作を考慮します。(パケットが管理境界を越えるのを防ぐので、規則はセキュリティ機能として一般的に見なされます)。 サイトのローカルの接頭語との予想された今後の交換を含むどんな接頭語のためにも規則をそのような妨げるのであるのを構成できます。 規則を妨げるこれらが実際に実施されるなら、サイトローカルの接頭語の不賛成はセキュリティを危険にさらしません。
Huitema & Carpenter Standards Track [Page 7] RFC 3879 Deprecating Site Local Addresses September 2004
Huitemaと2004年9月にサイトのローカルのアドレスを非難する大工標準化過程[7ページ]RFC3879
6. IANA Considerations
6. IANA問題
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 Standards Action[RFC2434]を通して正当化を必要とします。
7. Acknowledgements
7. 承認
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、およびアランBaudotに感謝したがっています。 セクション2.2のテキストはサイトのローカルのアドレシングの影響について説明するマーガレット・ワッサーマンによってバージョンから取られた2つのパラグラフを含んでいます。 アラン・ジュランドはサイトのローカルのアドレスについて言及する既存のRFCを改訂する必要性を指摘しました。
8. References
8. 参照
8.1. Normative References
8.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(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)アドレッシング体系」、RFC3513、2003年4月。
8.2. Informative References
8.2. 有益な参照
[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.、deグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(1996年2月)。
[RFC2772] Rockell, R. and R. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000.
[RFC2772] RockellとR.とR.密告者、「6Boneバックボーンルート設定ガイドライン」、RFC2772、2000年2月。
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[RFC2894] クロフォード、M.、「IPv6"、RFC2894、2000年8月のためのルータの番号を付け替えること」。
[RFC3082] Kempf, J. and J. Goldschmidt, "Notification and Subscription for SLP", RFC 3082, March 2001.
[RFC3082] ケンフ、J.、およびJ.ゴールドシュミット、「SLPのための通知と購読」(RFC3082)は2001を行進させます。
Huitema & Carpenter Standards Track [Page 8] RFC 3879 Deprecating Site Local Addresses September 2004
Huitemaと2004年9月にサイトのローカルのアドレスを非難する大工標準化過程[8ページ]RFC3879
[RFC3111] Guttman, E., "Service Location Protocol Modifications for IPv6", RFC 3111, May 2001.
[RFC3111]Guttman(E.)は「2001年5月にIPv6"、RFC3111年の位置のプロトコル変更を修理します」。
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport Relay Translator", RFC 3142, June 2001.
[RFC3142]HaginoとJ.とK.山本、「IPv6からIPv4への輸送リレー翻訳者」(RFC3142)2001年6月。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address", RFC 3177, September 2001.
[RFC3177] IABとIESG、「IPv6アドレスにおけるIAB/IESG推薦」、RFC3177、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、「何人かの2番目と第三世代のセルホストのためのインターネットプロトコルバージョン6(IPv6)」、RFC3316(2003年4月)。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、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"、RFC3493、2003年2月のための基本的なソケットインタフェース拡大。」
[Hinden/Haberman] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", Work in Progress, June 2004.
「ユニークなローカルのIPv6ユニキャストアドレス」という[Hinden/ハーバーマン]Hinden、R.、およびB.ハーバーマンは進歩、2004年6月に働いています。
[SCOPING] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", Work in Progress, August 2004.
[見ます] デアリング、S.、ハーバーマン、B.、Jinmei、T.、Nordmark、E.、B.Zill、「IPv6はアドレス体系を見たこと」が進行中(2004年8月)で働いています。
9. Authors' Addresses
9. 作者のアドレス
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA
クリスチャンのHuitemaマイクロソフト社1マイクロソフト道ワシントン98052-6399レッドモンド(米国)
EMail: huitema@microsoft.com
メール: huitema@microsoft.com
Brian Carpenter IBM Corporation Sauemerstrasse 4 8803 Rueschlikon Switzerland
ブライアン大工IBM社のSauemerstrasse4 8803Rueschlikonスイス
EMail: brc@zurich.ibm.com
メール: brc@zurich.ibm.com
Huitema & Carpenter Standards Track [Page 9] RFC 3879 Deprecating Site Local Addresses September 2004
Huitemaと2004年9月にサイトのローカルのアドレスを非難する大工標準化過程[9ページ]RFC3879
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (2004).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
彼が代理をするか、または(もしあれば)後援される/S、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄して、急行か暗示していて、含んでいる他はあらゆる保証です。「そのままで」という基礎と貢献者の上でこのドキュメントとここに含まれた情報を提供して、組織が彼である、情報の使用はここにどんな権利か市場性のどんな黙示的な保証か特定目的への適合性も侵害しないでしょう。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Huitema & Carpenter Standards Track [Page 10]
Huitemaと大工標準化過程[10ページ]
一覧
スポンサーリンク