この文書はRFC3879の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
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.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (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.
この文書はオリジナル形式のＩＰｖ６サイトローカルユニキャストアドレス
の使用についての問題を記述して、そして公式にそれらを廃止します。この
廃止は、代案が標準化され実装されるまで、それらの継続的使用を妨げませ
ん。
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.
しばらくの間、ＩＰｖ６ワーキンググループは「ローカルサイト」アドレス
の使用について問題を議論していました。２００３年３月のこれに関する会
合において、グループはこれらの問題が十分に重大で、オリジナル形式のサ
イトローカルアドレスの取り換えを正当化する処置に達しました。総意は満
場一致からはほど遠かったけれども、ワーキンググループはそのミーティン
グで２００３年７月にＩＰｖ６サイトローカルユニキャストアドレスを廃止
するためにこれらの問題と自然な決定を文書化する必要性に合意しました。
Site-local addresses are defined in the IPv6 addressing architecture
[RFC3513], especially in section 2.5.6.
サイトローカルアドレスがＩＰｖ６アドレス体系[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"と"SHALL"と
"SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"
はＢＣＰ１４、ＲＦＣ２１１９[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.
ＩＰｖ６ワーキンググループでの論議は、現在のサイトローカルアドレス範
囲のいくつかの欠陥を概説しました。これらの欠陥は２つの範囲のカテゴリー
に入ります：アドレスの曖昧さ、サイトの定義の曖昧性。
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"であると学ぶ、
あるいは覚えます、アプリケーションはソケットアドレス構造体にアドレス
を与え接続を生成しようとします、"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
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.
アプリケーション層でＩＰアドレス共有する単純なクライアント／サーバ型
アプリケーションがＩＰｖ６サイトローカルアドレスによりいっそう複雑に
されます。これらのアプリケーションはサイト境界の向こう側に渡されるべ
きアドレスとそうでないアドレスについて知的な決定をする必要があります。
これらの決定は、実際は、アプリケーションがいくらかのネットワークトポ
ロジの知識を獲得することを要求します。サイトローカルアドレスは、クラ
イアントとサーバが同じサイトにいる時に使われるかもしれませんが、クラ
イアントとサーバが異なったサイトにいる時、それらを使おうとすると意外
なエラー（すなわち、通信相手によってリセットされた接続）あるいは間違っ
たノードとの接続の設立をもたらすかもしれません。意外な相手にパケット
を送ることの強靭性とセキュリティの意味はアプリケーション毎に異なるで
しょう。
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.
アプリケーション層でＩＰアドレスを渡す多数のアプリケーションが特定の
挑戦を提示します。たとえノードがある通信相手ノードがローカルサイトに
属するか否かを正確に決定できるとしても、それらのアドレス宛のパケット
が結局どこに送られるか知る方法を持たないでしょう。これらのアプリケー
ションのための行動の最も良い方法はただグローバルアドレスだけを使うこ
とかもしれません。しかしながら、これはサイトローカルアドレスだけが利
用可能であるような孤立あるいは断続的に接続されたネットワークの上でこ
れらのアプリケーションを使用するのを妨げるでしょう、そしてある場合に
はアクセス制御のためサイトローカルアドレスの使用が不適合かもしれませ
ん。
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.
ＩＰｖ６サイトローカルアドレスの管理はＩＰｖ４ネットワークでのＲＦＣ
１９１８[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.
「プライベート」ホストの名前とリテラルアドレスがメールメッセージやウェ
ブページやファイルで漏洩します。プライベートアドレスが、例えばＤＮＳ
やｔｒａｃｅ−ｒｏｕｔｅで、ＴＣＰ要求やＵＤＰメッセージのソースや宛
先として用いられることになってしまうい、要求が失敗するか応答が疑いを
しないホストに到着します。プ
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.
ＲＦＣ１９１８のアドレスでの経験は、これらのアドレスをＩＰヘッダに置
く、ある単純でない漏れを見せます。プライベートアドレスはＲＦＣ１９１８
のためのＤＮＳ問合せの目標になり、無益にＤＮＳ基礎に負担をかけます。
一般に、直接ＩＰアドレスを使う多くのアプリケーションがアプリケーショ
ンペイロードでＲＦＣ１９１８のアドレスを渡し、混乱と障害を作ることに
なります。
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.
漏洩問題は大きく避けられません。あるアプリケーションが本質的に範囲を
持つが（例えば、ルータ広告や近隣探索）、多くのアプリケーションが範囲
の概念がなく、範囲を表現する方法がありません。結果として、「境界の向
こう側に漏洩します」。アドレスが曖昧であるので、ネットワーク管理者は
「誰がそれをしたか」を容易に見つけだすことができません。漏洩は修正が
難しく、多くの不満を生じます。
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.
曖昧なアドレスがマルチサイトルータ上にかなり明白な結果を生じます。
古典的なルータ構造で、出インタフェースは宛先アドレスの直接の関数で、
ひとつのルーティングテーブルで指定されます。しかしながら、もしルータ
が多数のサイトに接続しているなら、サイトローカルパケットのルーティン
グは、そのパケットが到着したインタフェースに依存します。インタフェー
スがサイトに関連づけられなければなりません、そしてサイトローカルアド
レスのルーティング項目はサイト依存です。これをサポートすることはルー
ティングプロトコルで特別な準備を、そして通常ＶＰＮに使われるルーティ
ングと転送テーブルの仮想化の技法を必要とします。これはルータ実装と管
理に追加の複雑さを作ります。
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. サイトは正しく定義されていない概念
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?
リンクローカルを別として、範囲境界線は正しく定義されていません。何が
サイトか？企業のネットワークの全体はサイトですか、あるいはサイトはひ
とつの地理的な場所に限定されていますか？多くのネットワークが、今日、
ファイアウォールによって切り離され、内部エリアと外縁「ＤＭＺ」に分け
られます。ＤＭＺの中のサーバはインターネット上の恐らく内部ホストと外
部ホストの両方にアクセスできます。ＤＭＺは内部ホストと同じサイトに属
しますか？
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.
我々が誰に尋ねるかによって、サイト範囲の定義は変化します。これは、セ
キュリティの境界や、到達可能性の境界や、ルーティングの境界や、ＱｏＳ
の境界や、管理上の境界や、資金上の境界や、何か他の種類の境界や、ある
いはこれらの組合せかもしれません。ひとつの範囲がこれらすべての条件に
一致するかは非常に不明確です。
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.
ある周知の重要な範囲を乱す事象があります、例えば、断続的に接続された
ネットワークや、移動ノードや、移動ネットワークや、ドメイン間ＶＰＮや、
ホストネットワークや、ネットワーク統合と分離などです。 特に、これは範
囲が、実際のリンク／ローカル／グローバルといった同心円のモデルに、対
応付け＊できない＊ことを意味します。範囲が互いに部分的な重なり合いや
拡張をします。２つのホストの間の範囲の関係は異なるプロトコルで異なる
かもしれません。
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/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.
エニキャストアドレスが残る１つの問題です。エニキャストアドレスは、定
義からエニキャストアドレスを割り当てられた任意のホストを参照するので、
構成上曖昧です。リンクローカルエニキャストアドレスあるいはグローバル
エニキャストアドレスが「コードに書込み」できます。リンクローカルとグ
ローバルの間の範囲のエニキャストアドレスの必要性について、今後の研究
が必要です。
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あるいはFEC0::/10、を廃止し
ます。このプレフィックスの特別な行動は新しい実装でサポートされてはな
りません(MUST)。プレフィックスは、将来のＩＥＴＦ標準行動を除き、他の
使用のために再割当してはなりません(MUST NOT)。アドレス体系[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].
サイトローカルアドレスへの参照は、インターネット・プロトコルバージョ
ン６のためのデフォルトアドレス選択[RFC3484]の修正と、ＩＰｖ６のために
基本的ソケットインタフェース拡張[RFC3493]の修正と、インターネット・プ
ロトコルバージョン６（ＩＰｖ６）アドレス体系[RFC3513]の修正から、実際
的な程度に早く削除されるべきです。サイトローカルアドレスへの付随的な
参照は、更新される時に、他のＩＥＴＦ文書からも取り除かれるべきです。
これらの文書は[RFC2772, RFC2894, RFC3082, RFC3111, RFC3142, RFC3177,
and RFC3316]を含みます。
Existing implementations and deployments MAY continue to use this
prefix.
既存の実装と展開がこのプレフィックスを使い続けるかもしれません(MAY)。
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.
曖昧なサイトローカルアドレスの使用は、２章で文書化されるように、漏れ
や、曖昧性や、潜在的ルーティング失敗により、ネットワークセキュリティ
に悪影響を与える可能性があります。曖昧なアドレスの使用を廃止すること
はこれらの問題の多くを解くことを助けます。
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.
サイトローカルユニキャストプレフィックスはファイアウォール規則とアド
レス選択規則である阻止動作を許し、これは、管理境界を渡るパケットを妨
げるから、一般にセキュリティ機能だと見なされます。このような阻止規則
はサイトローカルプレフィックスの代わりのどんなプレフィックスででも設
定ができます。もしこれらの阻止規則が実際に実施されるなら、サイトロー
カルプレフィックスの廃止はセキュリティを危険にさらしません。
6. IANA Considerations
6. ＩＡＮＡの考慮
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].
ＩＡＮＡは、この文書を示して、FEC0::/10プレフィックスに「廃止」と印す
事を求められます。どんな使用のためでもプレフィックスの再割当はＩＥＴＦ
標準化行動[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.
著者は文書の最初の版のレビューに対してFred TemplinとPeter Bieringerと
Chirayu PatelとPekka SavolaとAlain Baudotに感謝します。２.２章の文は
サイトローカルアドレスの影響を記述するMargaret Wassermanの版から引用
された２つの段落を含みます。Alain Durandはサイトローカルアドレスを参
照する既存のＲＦＣを修正する必要性を指摘しました。
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.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for
Writing an IANA Considerations Section in RFCs",
BCP 26, RFC 2434, October 1998.
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol
Version 6 (IPv6) Addressing Architecture", RFC
3513, April 2003.
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.
[RFC2772] Rockell, R. and R. Fink, "6Bone Backbone Routing
Guidelines", RFC 2772, February 2000.
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC
2894, August 2000.
[RFC3082] Kempf, J. and J. Goldschmidt, "Notification and
Subscription for SLP", RFC 3082, March 2001.
[RFC3111] Guttman, E., "Service Location Protocol
Modifications for IPv6", RFC 3111, May 2001.
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4
Transport Relay Translator", RFC 3142, June 2001.
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6
Address", RFC 3177, September 2001.
[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.
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February
2003.
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J.,
and W. Stevens, "Basic Socket Interface Extensions
for IPv6", RFC 3493, February 2003.
[Hinden/Haberman] Hinden, R. and B. Haberman, "Unique Local IPv6
Unicast Addresses", Work in Progress, June 2004.
[SCOPING] Deering, S., Haberman, B., Jinmei, T., Nordmark,
E., and B. Zill, "IPv6 Scoped Address
Architecture", Work in Progress, August 2004.
9. Authors' Addresses
9. 著者のアドレス
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
EMail: brc@zurich.ibm.com
10. Full Copyright Statement
10. 著作権表示全文
Copyright (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.
この文書はＢＣＰ７８に含まれる権利と許可と制限の適用を受け、そして
この中に明らかにされる以外は著者がすべての権利を維持します。
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.
この文書に記述された実装や技術に関して主張される知的財産権や他の権利の
正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
可能かの範囲について、ＩＥＴＦは何の立場もとりません；この様な権利を
認識する独立の調査をしたとは述べません。ＲＦＣ文書の権利に関する手続
きの情報はＢＣＰ７８とＢＣＰ７９を見てください。
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.
ＩＥＴＦ事務局に公開されたＩＰＲの写しと、利用可能な許可証と、仕様書
の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
試みの結果は、http://www.ietf.org/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-ipr@ietf.orgのＩＥＴＦに情報を伝えてください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the
Internet Society.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。