この文書はRFC3879の日本語訳(和訳)です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識や情報を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のRFC同様に無制限です。


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).

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ワーキンググループは「ローカルサイト」アドレス
   の使用について問題を議論していました。2003年3月のこれに関する会
   合において、グループはこれらの問題が十分に重大で、オリジナル形式のサ
   イトローカルアドレスの取り換えを正当化する処置に達しました。総意は満
   場一致からはほど遠かったけれども、ワーキンググループはそのミーティン
   グで2003年7月にIPv6サイトローカルユニキャストアドレスを廃止
   するためにこれらの問題と自然な決定を文書化する必要性に合意しました。

   Site-local addresses are defined in the IPv6 addressing architecture
   [RFC3513], especially in section 2.5.6.
   サイトローカルアドレスがIPv6アドレス体系[RFC3513]の特に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.
   この文書の残りが上記の定義に従ってサイトローカルアドレスの逆効果を記
   述し、そして公式にこれらを廃止します。

   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"
   はBCP14、RFC2119[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"であると学ぶ、
   あるいは覚えます、アプリケーションはソケットアドレス構造体にアドレス
   を与え接続を生成しようとします、"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.
   アプリケーション層で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.
   まとめると、サイトローカルアドレスの曖昧性は、アプリケーションペイロー
   ドがローカルサイト外でこれらのアドレスを運ぶ時、意外なアプリケーショ
   ン行動を導きます。

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ネットワークでのRFC
   1918[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.
   「プライベート」ホストの名前とリテラルアドレスがメールメッセージやウェ
   ブページやファイルで漏洩します。プライベートアドレスが、例えばDNS
   やtrace−routeで、TCP要求やUDPメッセージのソースや宛
   先として用いられることになってしまうい、要求が失敗するか応答が疑いを
   しないホストに到着します。プ

   The experience with RFC 1918 addresses also shows some non trivial
   leaks, besides placing these addresses in IP headers.  Private
   addresses also end up being used as targets of reverse DNS queries
   for RFC 1918, uselessly overloading the DNS infrastructure.  In
   general, many applications that use IP addresses directly end up
   passing RFC 1918 addresses in application payloads, creating
   confusion and failures.
   RFC1918のアドレスでの経験は、これらのアドレスをIPヘッダに置
   く、ある単純でない漏れを見せます。プライベートアドレスは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.
   漏洩問題は大きく避けられません。あるアプリケーションが本質的に範囲を
   持つが(例えば、ルータ広告や近隣探索)、多くのアプリケーションが範囲
   の概念がなく、範囲を表現する方法がありません。結果として、「境界の向
   こう側に漏洩します」。アドレスが曖昧であるので、ネットワーク管理者は
   「誰がそれをしたか」を容易に見つけだすことができません。漏洩は修正が
   難しく、多くの不満を生じます。

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.
   曖昧なアドレスがマルチサイトルータ上にかなり明白な結果を生じます。
   古典的なルータ構造で、出インタフェースは宛先アドレスの直接の関数で、
   ひとつのルーティングテーブルで指定されます。しかしながら、もしルータ
   が多数のサイトに接続しているなら、サイトローカルパケットのルーティン
   グは、そのパケットが到着したインタフェースに依存します。インタフェー
   スがサイトに関連づけられなければなりません、そしてサイトローカルアド
   レスのルーティング項目はサイト依存です。これをサポートすることはルー
   ティングプロトコルで特別な準備を、そして通常VPNに使われるルーティ
   ングと転送テーブルの仮想化の技法を必要とします。これはルータ実装と管
   理に追加の複雑さを作ります。
 
   Network management complexity is also increased by the fact that
   though sites could be supported using existing routing constructs--
   such as domains and areas--the factors driving creation and setting
   the boundaries of sites are different from the factors driving those
   of areas and domains.
   サイトが−ドメインやエリアのような−既存のルーティング概念を使ってサ
   ポートできるが、サイトにはエリアとドメインと異なる要素があるという事
   実によって、ネットワーク管理の複雑さが増加します。

   In multi-homed routers, such as for example site border routers, the
   forwarding process should be complemented by a filtering process, to
   guarantee that packets sourced with a site local address never leave
   the site.  This filtering process will in turn interact with the
   forwarding of packets, for example if implementation defects cause
   the drop of packets sent to a global address, even if that global
   address happen to belong to the target site.
   例えば、サイト境界ルータのような、マルチホームルータの転送プロセスは、
   サイトローカルアドレスのソースを持つパケットがサイトからけして離れな
   いように、フィルタプロセスで補完されるべきです。例えば、もし実装欠陥
   がグローバルアドレスに送られたパケットを廃棄しても、たとえそのグロー
   バルアドレスが目標サイトにあってもこのフィルタプロセスはパケットの転
   送と相互作用するでしょう。

   In summary, the ambiguity of site local addresses makes them hard to
   manage in multi-sited routers, while the requirement to support
   disjoint sites and existing routing protocol constructs creates a
   demand for such routers.
   まとめると、サイトローカルアドレスの曖昧性は、それらをマルチサイトルー
   タで管理することが難しくし、他方連続していないサイトや既存のルーティ
   ングプロトコルをサポートする必要条件はこのようなルータに対する要求を
   作ります。

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?
   リンクローカルを別として、範囲境界線は正しく定義されていません。何が
   サイトか?企業のネットワークの全体はサイトですか、あるいはサイトはひ
   とつの地理的な場所に限定されていますか?多くのネットワークが、今日、
   ファイアウォールによって切り離され、内部エリアと外縁「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.
   まとめると、サイトの現在の概念は未熟で、そして運用上の必要条件に対応
   しません。

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.
   エニキャストアドレスが残る1つの問題です。エニキャストアドレスは、定
   義からエニキャストアドレスを割り当てられた任意のホストを参照するので、
   構成上曖昧です。リンクローカルエニキャストアドレスあるいはグローバル
   エニキャストアドレスが「コードに書込み」できます。リンクローカルとグ
   ローバルの間の範囲のエニキャストアドレスの必要性について、今後の研究
   が必要です。

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]で定義されたIPv6サイトローカルユニキャス
   トプレフィックス、すなわち2進数1111111011あるいはFEC0::/10、を廃止し
   ます。このプレフィックスの特別な行動は新しい実装でサポートされてはな
   りません(MUST)。プレフィックスは、将来のIETF標準行動を除き、他の
   使用のために再割当してはなりません(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].
   サイトローカルアドレスへの参照は、インターネット・プロトコルバージョ
   ン6のためのデフォルトアドレス選択[RFC3484]の修正と、IPv6のために
   基本的ソケットインタフェース拡張[RFC3493]の修正と、インターネット・プ
   ロトコルバージョン6(IPv6)アドレス体系[RFC3513]の修正から、実際
   的な程度に早く削除されるべきです。サイトローカルアドレスへの付随的な
   参照は、更新される時に、他のIETF文書からも取り除かれるべきです。
   これらの文書は[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.
   曖昧なサイトローカルアドレスの使用は、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.
   サイトローカルユニキャストプレフィックスはファイアウォール規則とアド
   レス選択規則である阻止動作を許し、これは、管理境界を渡るパケットを妨
   げるから、一般にセキュリティ機能だと見なされます。このような阻止規則
   はサイトローカルプレフィックスの代わりのどんなプレフィックスででも設
   定ができます。もしこれらの阻止規則が実際に実施されるなら、サイトロー
   カルプレフィックスの廃止はセキュリティを危険にさらしません。

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
   標準化行動[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に感謝します。2.2章の文は
   サイトローカルアドレスの影響を記述するMargaret Wassermanの版から引用
   された2つの段落を含みます。Alain Durandはサイトローカルアドレスを参
   照する既存の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.

   [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).
   著作権(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.
   この文書とここに含まれる情報はあるがままに供給されます、貢献者と貢献
   者が代表するか貢献者を後援する組織(もしあれば)とインターネット学会
   とインターネット技術標準化タスクフォースは、明確にも暗黙にも、この情
   報の使用が権利の侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、全ての保証を拒否します。

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は何の立場もとりません;この様な権利を
   認識する独立の調査をしたとは述べません。RFC文書の権利に関する手続
   きの情報はBCP78とBCP79を見てください。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.
   IETF事務局に公開されたIPRの写しと、利用可能な許可証と、仕様書
   の実装者や利用者によってされた一般的な許可書や許可を得るためにされた
   試みの結果は、http://www.ietf.org/iprにあるIETFオンラインIPR
   貯蔵庫で得られます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.
   IETFは興味を持った誰からでもこの標準を実行するのに必要な技術をカ
   バーする著作権や特許や特許出願や他の所有権の注意を持ってくるように求
   めます。どうかietf-ipr@ietf.orgのIETFに情報を伝えてください。

Acknowledgement
謝辞

   Funding for the RFC Editor function is currently provided by the
   Internet Society.
   RFCエディタ機能のための資金供給が現在インターネット学会によって
   供給されます。

Japanese translation by Ishida So