この文書はインターネットドラフトの日本語訳(和訳)です。 翻訳者はこの文書の翻訳の正確さを保障しません。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 翻訳者はこの翻訳の配布に制限をしません。


INTERNET DRAFT                                              C. Huitema
< draft-ietf-ipv6-deprecate-site-local-00.txt>               Microsoft
August 16, 2003                                           B. Carpenter
Expires February 16, 2003                                          IBM


              Deprecating Site Local Addresses
              サイトローカルアドレスへの不賛成

Status of this memo
このメモの状態

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.
   この文書はインターネットドラフトであって、そしてRFC2026の10
   章のすべての条項に完全適合です。

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.
   インターネットドラフトはインターネット技術タスクフォース(IETF)
   とそのエリアとその作業グループの作業文書です。他のグループがインター
   ネットドラフトとして同じく作業文書を配るかもしれないことに注意してく
   ださい。

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."
   インターネットドラフトは最大6カ月間有効なドラフト文書で、いつでも他
   の文書によって、更新か、置換えか、時代遅れにされるかもしれません。イ
   ンターネットドラフトは、「進行中の仕事」として以外に、参照材料あるい
   は引用として用いることは不適当です。

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.
   現在のインターネットドラフトのリストは
   http://www.ietf.org/ietf/1id-abstracts.txt でアクセスできます。

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.
   インターネットドラフトの影ディレクトリのリストは
   http://www.ietf.org/shadow.html でアクセスできます。

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 decided in its meeting in July
   2003 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 [Hain/Templin] and specify a replacement solution
   [Hinden/Haberman]. However, the formal deprecation allows existing
   usage of site-local addresses to continue until the replacement is
   standardized and implemented.
   関連文書が代わりの対応策の目標を記述し[Hain/Templin]、代わりの対応策
   を指定するでしょう[Hinden/Haberman]。しかしながら、代案が標準化され
   て実装されるまで、正式の不賛成はサイトローカルアドレスの既存の使用を
   継続することを許します。

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
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 problem is compounded
   by the fact that the site identifier varies with the host
   instantiation, e.g. sometimes &1 and sometimes &2, and thus that the
   host identifier cannot be remembered in memory, or learned from a
   name server.
   アプリケーションがある通信相手が"FEC0::1234:5678:9ABC"であると学ぶか
   覚えています、アプリケーションはソケットアドレス構造体にアドレスを与
   え、接続を生成し、"FEC0::1234:5678:9ABC&1"の様に「サイト識別子」変数
   を指定しないので失敗するでしょう。問題はサイト識別子がホスト時間と共
   に変化する事です、例えばある時は&1で、ある時は&2で、それでホスト識別
   子をメモリで覚えているか、あるいはネームサーバから学ぶ事ができません。

   In short, the developer pain is caused by the ambiguity of site
   local addresses. Since site-local addresses are ambiguous,
   application developers have to manage the "site identifiers" that
   qualify the addresses of the hosts. This management of identifiers
   has proven hard to understand by developers, and also hard to
   execute by those developers who understand the concept.
   要するに、デベロッパーの痛みはサイトローカルアドレスのあいまい性によっ
   て起こされます。サイトローカルアドレスがあいまいであるので、アプリケー
   ションデベロッパーがホストアドレスを適格とする「サイト識別子」を管理
   しなければなりません。この識別子の管理は概念は、デベロッパーが理解す
   ることが難しくて、理解するデベロッパーが実行するのが難しいと分かりま
   した。

2.2 Manager pain, leaks
2.2 管理者の痛み、漏洩

   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. Private addresses
   also end up being used as targets of reverse lookup requests in the
   DNS, uselessly overloading the DNS infrastructure.
   「プライベート」ホストの名前とリテラルアドレスがメールメッセージやウェ
   ブページやファイルで漏洩します。プライベートアドレスが、例えばDNS
   やtrace−routeで、TCP要求やUDPメッセージのソースや宛
   先として用いられることになってしまうい、要求が失敗するか応答が疑いを
   しないホストに到着します。プライベートアドレスが同じくDNSの逆検索
   要求の目標として用いられることになり、無益にDNSインフラに負担をか
   け過ぎます。

   The leakage issue is largely unavoidable. While some applications
   are intrinsically scoped (eg. RA, ND), 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.
   漏洩問題は大きく避けられません。あるアプリケーションが本質的に範囲を
   持つが(例えば、RAやND)、多くのアプリケーションが範囲の概念がな
   く、範囲を表現する方法がありません。結果として、「境界の向こう側に漏
   洩します」。アドレスがあいまいであるので、ネットワーク管理者は「誰が
   それをしたか」を容易に見つけだすことができません。漏洩は修正が難しく、
   多くの不満を生じます。

2.3 Router pain, routing tables
2.3 ルータの痛み、ルーティングテーブル

   The ambiguity of site local addresses also creates problems 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, problem occurs 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. This will create a
   demand to route the site-local packets across some intermediate
   network. 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.
   The route management software and the routing protocols have to
   account for the site boundaries.
   あいまいなアドレスがマルチサイトルータ上にかなり明白な結果を生じます。
   古典的なルータ構造で、出インタフェースは宛先アドレスの直接関数で、ひ
   とつのルーティングテーブルで指定されます。しかしながら、もしルータが
   多数のサイトに接続しているなら、サイトローカルパケットのルーティング
   は、そのパケットが到着したインタフェースに依存します。インタフェース
   がサイトに関連づけられなければなりません、そしてサイトローカルアドレ
   スのルーティング項目はサイト依存です。経路管理ソフトウェアとルーティ
   ングプロトコルはサイト境界を評価しなければなりません。

   In multi-homed routers, such as for example site border routers, the
   routing 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
   routing of packets, as it may 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 creates a demand for such routers.
   まとめると、サイトローカルアドレスのあいまい性は、それらをマルチサイ
   トルータで管理することが難しくし、他方連続していないサイトをサポート
   する必要条件はこのようなルータに対する要求を作ります。

2.4 Site is an ill-defined concept
2.4 サイトが正しく定義されていない概念

   The current definition of scopes follows an idealized "concentric
   scope" 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. 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 [Hain/Templin]. 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.
   前章はサイトローカルアドレスに対する議論を再検討しました。明らかにサ
   イトローカルは利点があり、それがなければずっと前に仕様書から削除され
   ていたでしょう。サイトローカルの認識されている利点は、それが単純で、
   安定していて、私的な事です[Hain/Templin]。しかしながら、この利点は他
   の体系でも得られるように思われ、例えば[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 link-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)。

   Existing implementations and deployments MAY continue to use this
   prefix.
   既存の実装と展開がこのプレフィックスを使い続けるかもしれません(MAY)。

5 Security Considerations
5 セキュリティの考察

   The link-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. However, such blocking rules can be
   configured for any prefix, including the expected future replacement
   for the site-local prefix. Thus the deprecation of the site-local
   prefix does not endanger security.
   リンクローカルユニキャストプレフィックスはファイアウォール規則のある
   阻止動作とアドレス選択規則を許し、これらが管理境界線をまたぐパケット
   を妨げるから、これらは一般にセキュリティ機能と見なされます。しかしな
   がら、このような阻止規則は、サイトローカルプレフィックスの期待された
   将来の置換えを含め、どんなプレフィックスに対しての設定できます。それ
   でサイトローカルプレフィックスの不賛成はセキュリティを危険にさらしま
   せん。

6 IANA Considerations
6 IANAの考慮

   IANA is specifically requested not to reassign the 1111111011 binary
   or FEC0::/10 prefix unless requested to do so by a future IETF
   standards action.
   IANAは、将来のIETF標準行動で要請されない限り、特に2進数の
   1111111011あるいはFEC0::/10プレフィックスを再割り当てしないように要請
   されます。

7 Copyright
7 著作権

   The following copyright notice is copied from RFC 2026 [Bradner,
   1996], Section 10.4, and describes the applicable copyright for this
   document.
   以下の著作権表示はRFC2026[Bradner, 1996]の10.4章からコピー
   され、この文書に適用される著作権を記述します。

   Copyright (C) The Internet Society August 13, 2003. All Rights
   Reserved.
   著作権(C)インターネット学会2003年8月13日。すべての権利は保留される。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.
   上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
   この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
   を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
   版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
   ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
   や他のインターネット組織は著作権表示や参照を削除されるような変更がで
   きません、インターネット標準を開発する場合はインターネット標準化プロ
   セスで定義された著作権の手順に従われます。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assignees.
   上に与えられた限定された許可は永久で、インターネット学会やその後継者
   や譲渡者によって無効にされません。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS 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.
   この文書とここに含む情報は無保証で供給され、そしてインターネット学会
   とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
   報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
   ある事の保障を含め、すべての保証を拒否します。

8 Intellectual Property
8 知的所有権宣言

   The following notice is copied from RFC 2026 [Bradner, 1996],
   Section 10.4, and describes the position of the IETF concerning
   intellectual property claims made against this document.
   以下の表示はRFC2026[Bradner, 1996]の10.4章からコピーされ、
   この文書で作られる知的所有権項目に関するIETFの立場を記述します。

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use other technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication 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 Secretariat.
   この文書に記述された実装や技術に関して主張される知的財産や他の権利の
   正当性や範囲について、この様な権利の元でライセンスが利用可能か利用不
   可能かの範囲について、IETFは何の立場もとりません;この様な権利を
   認識する調査をしたとは述べません。IETF標準手続きと標準関連文書で
   の権利に関しての手順の情報はBCP11を見てください。出版に利用する
   権利の利用可能性とライセンスの保証の利用可能性か、あるいはこの仕様書
   の実装者や利用者のこの様な所有権の一般的ライセンスや許可を得る試みの
   結果はIETF事務局で得られます。

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

9 Acknowledgements
9 謝辞

10 References
10 参考文献

   Normative References
   基準的参考文献
   [RFC3513] Hinden, R. and S. Deering, "IP Version 6 Addressing
   Architecture", RFC 3513, April 2003

   Informative references
   教育的参考文献

   [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
   J. and E. Lear, "Address Allocation for Private Internets", RFC
   1918, February 1996

   [Hain/Templin] Hain, T. and F. Templin, "Addressing Requirements for
   Local Communications within Sites", work in progress.

   [Hinden/Haberman] Hinden, R. and B. Haberman, "Unique Local IPv6
   Unicast Addresses", work in progress.

11 Authors' Addresses
11 著者のアドレス

   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

[]Japanese translation by Ishida So