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


   IPv6                                                  
   Internet Draft                                               T. Hain
   Document: draft-hain-ipv6-sitelocal-01.txt                     Cisco
   Expires: November 2003                                      May 2003


                     Local Scope Address Requirements
                      ローカル範囲アドレス必要条件


Status of this Memo
このメモの状態

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

   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
   The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.
   現在のインターネットドラフトのリストは
   http://www.ietf.org/ietf/1id-abstracts.txt でアクセスできます。
   インターネットドラフトの影ディレクトリのリストは
   http://www.ietf.org/shadow.html でアクセスできます。

Abstract
概要

   This memo will discuss the site network manager's requirements for
   an address range available for use in a local routing scope.
   このメモはローカルルーティング範囲で利用可能なアドレス範囲について、
   サイトネットワーク管理者の必要条件を論じるでしょう。


   Status of this Memo
   このメモの状態
   Abstract
   概要
   Introduction
   はじめに
   What is a private use address space, and why is it discussed here? 
   何がプライベート使用アドレス空間で、なぜここで議論するのか?
   Requirements for a local scope address space
   ローカル範囲アドレス空間の必要条件
   Global routing impact
   グローバルルーティングへの影響
   Address range
   アドレス範囲
   Local scope
   ローカル範囲
   Applications of private address space today
   今日のプライベートアドレス空間割当
   Potential applications of private address space
   プライベートのアドレス空間の可能性があるアプリケーション
   Summary
   要約
   Security Considerations
   セキュリティの考察
   References
   参考文献
   Acknowledgments
   謝辞
   Author's Addresses
   著者のアドレス


Introduction
はじめに

   There has been much discussion lately about the role of site-local
   addresses. This memo will discuss the requirements, architectural
   role of a limited scope address range for local use, as well as some
   real world deployment examples.
   最近、サイトローカルアドレス役割についてのたくさんの論議がありました。
   このメモは必要条件と、ローカルな使用に限定されたアドレス範囲の体系の
   役割と、いくつかの実世界での展開例を論じるでしょう。

   Many network managers have developed a comfort level with private
   addresses in IPv4, and the first thing they look for in IPv6 is the
   comparable mechanism. Their absolute requirement for filtering will
   trump any complaints about broken applications. A common mechanism
   for accomplishing this is to designate some parts of the address
   space as limited to the scope of the local network or site. Well-
   known site-local address prefix provides an opportunity to move
   beyond the common IPv4 model where all nodes in a network use the
   same single scope of filtered space, by providing simultaneous
   support for site/global space. To gain the acceptance of network
   managers, tools they use as security measures must start from
   exactly the same point they are in IPv4. Then with simultaneous use
   of local and global prefixes there is an opportunity to expand the
   functionality of the network.
   多くのネットワーク管理者がIPv4でプライベートアドレスを快適に利用
   しました、そして彼らがIPv6で探す最初のものは類似のメカニズムです。
   彼らのフィルタリングののための絶対条件は壊れたアプリケーションに関す
   る苦情の札です。これを達成する共通メカニズムは、あるローカルネットワー
   クかサイト範囲に限定されたアドレス空間の一部を指定する事です。既知の
   サイトローカルアドレスプレフィックスが、サイト / グローバル空間の同
   時のサポートを供給することで、ネットワークの全ノードが同じフィルタリ
   ング空間を持つIPv4の共通モデルを適用する機会を提供します。ネット
   ワーク管理者の受け入れを得るために、彼らがセキュリティを判断する際に
   使う道具が正確にIPv4と同じ点から始めなければなりません。その時ロー
   カルとグローバルプレフィックスの同時使用はネットワーク機能を拡大する
   機会があります。

   Most of the arguments against the use of the currently defined site-
   local address prefix amount to wanting applications to work even in
   the presence of this intentional filtering imposed by the network
   manager. These arguments to remove local scope addresses from the
   architecture is equivalent to; we should prevent you from doing harm
   to yourself by insisting that scissors were never invented, that way
   we don't have to keep telling you not to run with them. Filtering
   will exist in networks, so there will be domains of applicability,
   or local scopes. Applications that insist on passing topology
   information outside the domain of applicability will fail to operate
   correctly in this environment.
   現在定義されたサイトローカルアドレスプレフィックスの使用に対する議論
   の大部分が、アプリケーションがこの意図的なフィルターで働くことを望む
   ネットワーク管理者が課すことになります。体系からローカル範囲アドレス
   を削除する主張は以下と同じです;我々は、はさみが発明されてないと主張
   することで、あなたがあなたを傷つけるのを阻止するべきです、それで我々
   はあなたに彼らと走らないように言い続けなくてもよいです。フィルタがネッ
   トワークで存在し、適用ドメインあるいはローカル範囲は存在するでしょう。
   適用ドメイン外のトポロジー情報を渡すことを強く主張するアプリケーショ
   ンがこの環境で正確に稼働しないでしょう。

   A defined prefix for local use uniquely identifies addresses that
   have a limited administrative domain of applicability. This prefix
   provides a network manager with a stable address range, as well as
   establishes a clear filter to limit introduction into the public
   network. A "site" is, by intent, not rigorously defined (just as
   Areas are not rigorously defined in an IGP), but is typically
   expected to cover a region of topology that belongs to a single
   organization and is located within a single geographic location,
   such as an office, an office complex, or a campus. As such, one
   common use instance of a site border will be the boundary between
   the IGP and EGP. Use of local scope addresses for connections
   external to a site is strongly discouraged, because it is difficult
   to know when applications will encounter the boundary of the domain
   of reference. When applications are expected to work across the site
   boundary, care should be taken to ensure all participating nodes
   have global scope addresses available.
   ローカル利用に定義されたプレフィックスが一意に限定された管理上ドメイ
   ンに提供するアドレスを識別します。このプレフィックスは、公共のネット
   ワークへの注入を制限する明確なフィルターを確立すると同様に、安定した
   アドレス範囲をネットワーク管理者に提供します。「サイト」は、意図的に、
   厳密に定義されません(IGPでエリアが厳密に定義されないように)、し
   かし一般的に、オフィスやオフィスビル群やキャンパスのような、ひとつ組
   織やひとつの地理的な場所をカバーすることを期待されます。そして、サイ
   ト境界の一般的な使い方の例はIGPとEGP間の境界線であるでしょう。
   アプリケーションが参照ドメインの境界に遭遇するか知ることは難しいから、
   サイト外の接続にローカル範囲アドレスを使うのは強くおろかなことです。
   アプリケーションがサイト境界線を超えて動作することが期待される時、参
   加しているすべてにノードがグローバル範囲アドレスを利用可能であるよう
   にすることを保証する注意がとられるべきです。

What is a private use address space, and why is it discussed here? 
何がプライベート使用アドレス空間で、なぜここで議論するのか?

   For purposes of this discussion, a private use address space is any
   set of addresses that can not be reached from a significant portion
   of the public Internet. The reasons for lack of ability to reach
   these addresses are based on policy local to the network using them
   vs. policy at an arbitrary remote network.
   この議論の目的で、プライベート使用アドレス空間が公共インターネットの
   主要部分からの届かない任意のアドレス集合です。これらのアドレスに到達
   できない理由は、これらを使うネットワークのローカルポリシーと任意の遠
   隔ネットワークのポリシーに基づいています。

   The implementation mechanism used to accomplish that policy could be
   simply restricting the range of routing announcements, or explicit
   access controls in a device along the path. In either of those
   cases, the result is a local scope with a well defined boundary
   controlled by the network manager using the addresses. A consequence
   of the implemented policy is that any packets destined for locations
   within the limited scope, must originate and stay within that scope,
   as there is no way to deliver packets from outside the defined
   scope.
   そのポリシーを達成するために使われた実行メカニズムは、単純に経路広告
   の範囲を制限するか、パス上の装置での明示的なアクセス制御があり得ます。
   それらの場合のいずれかで、結果は、アドレスを使っているネットワーク管
   理者が制御する明確な境界を持つローカル範囲です。実行された政策の帰結
   は、パケットは限定された範囲にだけ届き、範囲内から発信され、範囲内に
   留まり、外から定義された範囲にパケットを届ける方法がありません。

   As a simple example, take the case below where A & B have a choice
   of addresses that they can use to reach each other, but C can only
   reach the Public addresses of either.
   単純な例として、A&Bが彼らがお互いに通信に使うことができるアドレス
   の選択肢を持っているが、Cはそれぞれから公共アドレスでしか到達できな
   い、以下の場合を考えます。

        ---- A ----
          |      |
          L      P
          o      u
          c      b
          a      l ---- C
          l      i
          |      c
          |      |
        ---- B ----

   One of the requirements of this network environment is that any
   process that intends to provide C with topology information for
   reaching A or B, needs to understand the topology so that it can
   provide C with correct and useful information.
   このネットワーク環境の必要条件の1つは、AあるいはBへの到達に関して
   トポロジー情報をCに提供する事を意図するどんな処理でも、それが正しい
   くて有用な情報をCに提供することができるように、トポロジーを理解する
   必要があるということです。

   An alternate way to draw the example network is:
   例のネットワークを描く代わりの方法が以下です:

        ---- A ----      -
          |      |       |
          L      G       P
          o      l       u
          c      o       b
          a      b - R - l ---- C
          l      a       i
          |      l       c
          |      |       |
        ---- B ----      -

   This alternate view correlates the public side of A & B where they
   share some aspect of the routing hierarchy. The result still
   requires that any process that intends to provide C with topology
   information understands the topology to recognize the local and
   global scope differences to provide useful information.
   この代わりの表現はルーティング階層面を共有するAとBの公共側を関連づ
   けます。結果はトポロジー情報をCに提供する意図をもつ処理は、有用な情
   報を供給するためローカルとグローバル範囲の相違を認識してトポロジーを
   理解することを要求します。

   To simplify subsequent discussion, the labels will be changed using
   that same view. The local prefix will be shown as P(l), while the
   global public prefix will be shown as P(g).
   次の論議を単純化するために、同じ絵でラベルを変えます。ローカルプレ
   フィックスはP(l)と示され、他方グローバル公共プレフィックスは
   P(g)で示されます。

        ---- A ----         -
          |      |          |
          |      |          P
          |      |          u
          |      |          b
          P(l)   P(g) - R - l ---- C
          |      |          i
          |      |          c
          |      |          |
        ---- B ----         -

   This sequence of network drawings has been presented to show that
   limited scopes exist in many IPv4 network deployments today.
   Additional discussion of the policies that drive these deployments
   can be found in a discussion on deployment and use of a proposed
   Provider Independent (PI) address space [2]. Any specific PI
   mechanism is not the issue here, so much as the policies that drive
   deployment of an address space that is not controlled by the public
   network service provider. Further discussion of the requirements for
   site controlled space follow in the next section.
   この一連のネットワーク図は限定された範囲が今日多くのIPv4ネットワー
   ク展開で存在することを示すために提示しました。これらの展開を動かすポ
   リシーの追加の議論が、提案されたプロバイダ非依存(PI)アドレス空間
   の派遣と使用の議論[2]に見いだすことができます。ここで特定のPIメカ
   ニズムが問題ではなく、公共ネットワークサービスプロバイダによって制御
   されないアドレス空間の展開の動かすポリシーが問題です。サイト制御され
   た空間のための必要条件のこれ以上の論議が次章で続きます。

Requirements for a local scope address space
ローカル範囲アドレス空間の必要条件

   Easy to get - No public registration, payment, customer/provider
   relationship, or approval required. Network managers have stated,
   and historical experience has shown, that there is a need for
   address space that does not require public registration.
   入手が容易−公共の登録なし、支払いなし、顧客/プロバイダ関係なし、認
   可要求なし。ネットワーク管理者の意見と歴史的経験から、公共登録を必要
   としないアドレス空間が必要です。

   Stable - Both during ISP changes, and for intermittently connected
   networks. The address space available for local use must not be
   subject to change by an external entity, and must not create a real
   or artificial lock-in to any provider.
   安定−ISP変更や、ネットワークの断続的接続の両方で。ローカル使用に
   利用可能なアドレス空間は外部の関係者の変化の影響を受ず、そしてプロバ
   イダの実際のあるいは人工的な囲い込みになってはなりません。

   Private ・Well known routing filter provides multiple levels of
   filtering to ensure a single error does not expose the network to
   global access. While the local use address space is generally for
   use within a network, it is often used in private interconnects.
   This may be to avoid exposing the relationship, or may be to provide
   a dedicated resource between the networks. In any case, the goal of
   restricting these addresses to a local scope is to prevent access
   from the public network.
   私的。既知のルーティングフィルタは、ひとつのエラーがネットワークをグ
   ローバルアクセスにさらさないことを保証するために、多段フィルタを供給
   します。ローカル利用アドレス空間が一般にネットワーク内で使用するが、
   プライベートの相互接続でもしばしば使われます。これが関係の露出を避け
   るためかもしれないし、あるいはネットワーク間に専用資源を供給するため
   かもしれません。どんな場合でも、ローカル範囲にこれらのアドレスを限定
   することの目的は公共ネットワークからのアクセスを妨げる事です。

   There is a strong requirement for an easy-to-get, stable, private
   address space for use in local networks. In some cases this is
   simply to avoid the necessary costs associated with running a
   registration infrastructure, but in others it is to avoid exposing
   their internal network plans to competitors. Placing all local use
   address space in a common short prefix allows everyone to filter it
   which prevents unwanted exposure in the case of single point
   configuration errors.
   ローカルネットワークで使用するための、入手が容易と安定と私的なアドレ
   ス空間の強い要求があります。ある場合にはこれは登録インフラを運営する
   ことに関連した経費を避けますが、他方で競争者に内部ネットワーク計画を
   暴露するのを避けるはずです。すべてのローカル利用アドレス空間を共通の
   短いプレフィックスに入れることは、全ての人がそのフィルターを可能にし、
   一点での設定誤りの場合での望まれない危険性を妨げます。


Global routing impact
グローバルルーティングへの影響

   The strong demand for stable address space also applies to cases
   where network managers want global access. There is a concern that
   some network managers will demand that their service providers route
   the local scope address range globally. Unless they are specifically
   designed to be PI space, local scope addresses must stay local, and
   not be leaked into the global routing system. The issue is that
   without designed aggregation properties, accepting them will lead to
   a global routing table explosion. For this reason a PI mechanism
   with reasonable aggregation properties needs to be developed along
   side the local use address range. One approach is proposed in An
   IPv6 Provider-Independent Global Unicast Address Format [3]. While
   this does not aggregate to the same degree as the PA approach, it
   does provide a stable space that has modest aggregation properties.
   The local use address space has no aggregation properties, and must
   not be routed arbitrarily.
   安定したアドレス空間に対する強い要求は同じくネットワーク管理者がグロー
   バルアクセスを欲する場合に当てはまります。あるネットワーク管理者がサー
   ビスプロバイダにローカル範囲アドレスをグローバルにルーティングするこ
   とを要求する懸念があります。それらが特にPI空間であるよう意図されな
   いなら、ローカル範囲アドレスがローカル状態でいて、そしてグローバルルー
   ティングシステムの中に漏れてはなりません。問題は設計された集約特性な
   しで、それらを受け入れることはグローバルルーティングテーブルの爆発を
   導くということです。この理由のために、ローカルに使用するアドレス範囲
   で、合理的な集約特性を持つPIメカニズムが開発される必要があります。
   1つの方法がIPv6プロバイダ非依存グローバルユニキャストアドレス
   フォーマット[3]で提言されます。これがPA方法とと比べて同じほど集約し
   ませんが、これは控えめな集約特性を持つ空間を用意します。ローカル使用
   アドレス空間は集約特性を持たず、そして任意にルーティングされてはなり
   ません。


Address range
アドレス範囲

   The address range provided for local use is an architecturally
   supported, end-user-controlled address space. The address range is
   set aside as a block that network managers can use without any
   registration, payment, or approval from external sources.
   ローカル使用に提供されたアドレス範囲は体系的にサポートされ、エンドユー
   ザが管理するアドレス空間です。アドレス範囲はネットワーク管理者が外部
   への登録や、支払いや、認可なしで使うことができるブロックとしておかれ
   ます。

   Using the well-known prefix range for local usage provides a hint
   that a filtering policy has been applied somewhere in this network,
   though it does not by itself indicate where the boundaries are.
   Given the presence of a local scope address, an application that
   chooses to check can infer that there is an explicit filter
   somewhere in the network. That filter may or may not be between it
   and the application peer.
   ローカルな使用のために既知プレフィックス範囲を使うことは、これがひと
   りでに境界を示さないけれども、このネットワークのフィルタポリシに適用
   されたポリシーにヒントを供給します。ローカル範囲アドレスの存在という
   条件のもとで、調査を決めるアプリケーションがネットワークのどこかに明
   示的なフィルタがあると推量することができます。そのフィルタはアプリケー
   ションとアプリケーションの相手の間にあるかもしれないし、ないかもしれ
   ません。

   The only difference between a individual network defined non-
   routable global prefix and a well-known local use prefix is the
   coordination and verification of filters. Any prefix can be used in
   a local-only context, but the ability to detect a configuration
   error which leads to open routing is limited unless it is well-
   known.
   ルーチングできないグローバルプレフィックスで定義された個別ネットワー
   クと、既知のローカル使用プレフィックスの個別ネットワークとの間の唯一
   の相違は、調整とフィルタ検証です。どのプレフィックスもローカルでのみ
   の意味で使うことができます、しかしオープンルーティングに導く設定誤り
   を検出する能力は、それがよく知られていないなら、限定されています。

Local scope
ローカル範囲

   The concept of address scoping is nothing more than a formalization
   of the existing deployments of limited route announcements, or
   explicit filtering. Defining a well-known address range for local
   use allows broad deployment of filters at the edge of the public
   network without additional site specific coordination.
  アドレス範囲の概念は、制限された経路広告や明示的フィルタリングの既
   存の展開の形式化以上のものではありません。ローカル使用のために既知
   のアドレス範囲を定義することは追加のサイト特定の調整無しで公共ネッ
   トワークのエッジでフィルターの広範囲の実装を許します。
 
   Concurrent use of local & global scope addresses allows neighboring
   nodes on a network to have individual policies about global
   visibility. This moves the policy decision from the edge to the
   originating device, which allows the application which has enough
   information decide the appropriate action, rather than the
   alternative brute force edge approach one-size-fits-all policy. In
   the case of devices that move between subnets, it also mitigates the
   need for continuous changes of access controls at the edge.
   ローカルとグローバル範囲アドレスの同時使用がネットワーク上の隣接する
   ノードにグローバル範囲について個別のポリシを持つことを許します。これ
   はポリシ決定をエッジから出発装置に動かそ、これはエッジでの同じ基準を
   全て適用する力づくの手段ではなく、十分な情報を持つアプリケーションが
   適切な行動を決める事を許します。サブネット間を行き来する装置の場合に、
   これはエッジでのアクセス制御装置の絶え間がない変更の必要を和らげます。

   The boundaries of a site are intentionally undefined. An
   organization should probably start with the assumption that a site
   boundary is exactly congruent with an IGP area or IGP/EGP boundary,
   but they may choose to restrict it further, or expand it when it
   makes sense for their network. The concepts of sites and IGP areas
   are similar in that they are about limiting how much information is
   exposed across administrative borders. In any case a policy boundary
   will exist at any attachment point to the public Internet, so that
   is a very likely place to implement a scope boundary.
   サイトの境界は意図的に不確定です。組織がサイト境界が正確にIGPエリ
   アあるいはIGP/EGP境界と一致するという仮定で恐らく始まるべきで
   す、しかしネットワークで意味があるなら、さらに限定するか、あるい拡大
   することに決めてもよいです。サイトとIGPエリアの概念は、それらがど
   れぐらい情報が管理境界を超えれるを制限する点で、類似です。どんな場合
   にでもポリシー境界線が公共インターネットに接続する点で存在するでしょ
   う、それでここが範囲境界を実行する非常にありそうな場所です。

   While the earlier examples showed a physical separation between the
   local and global topology, the scenario is identical between
   multiple interfaces with a single address, and individual interfaces
   with multiple addresses. This characteristic results in another view
   of the example network:
   以前の事例がローカルとグローバルのトポロジーを物理的に分けましたが、
   ひとつのアドレスを持つ多数のインタフェースとひとつのインタフェースに
   多数のアドレスでは、まったく同じです。この特徴はもう1つのネットワー
   ク例の絵をもたらします:


        A ----          -
            |           |
            |           P
            |           u
            |           b
        P(l)&P(g) - R - l ---- C
            |           i
            |           c
            |           |
        B ----          -

   This configuration is not typical in IPv4 networks because
   implementing multiple addresses per interface is relatively
   difficult. In this view, the router R either informs the public
   network of only the global prefix A & B are using, or if the local
   use prefix is a subset of the global prefix, R explicitly controls
   access to the local use portion. Either way, C can only reach A(g) &
   B(g), while A & B can reach either P(g) or P(l). In any case, the
   issues raised by the limited routing scope of P(l) are the same as
   they were in the multiple interface case we started with, and
   completely independent of the allocation source of P(l).
   この設定はインタフェース毎に多数のアドレスを実装することが比較的難し
   いから、IPv4ネットワークで一般的ではありません。この絵で、ルータ
   RはAとBの使っているのの中からグローバルプレフィックスだけを公共の
   ネットワークに知らせるか、あるいはもしローカルプレフィックスがグロー
   バルプレフィックスの一部なら、Rがローカル使用部に明示的にアクセス制
   御をします。いずの方法でも、AとBはP(g)でもP(l)でも到達する
   が、CはただA(g)とB(g)に到達するだけです。どんな場合でも、
   P(l)の制限されたルーティング範囲によって生じた問題は、最初の多数
   のインタフェースの場合と同じで、完全にP(l)の割当源と独立です。

   Adding a little more detail to the drawing, shows the distinction
   between the customer premise equipment (CPE) router, and the
   provider edge (PE) router.
   絵にもう少し細部を加えて、顧客宅内機器(CEP)ルータとプロバイダ
   エッジ(PE)ルータ間の区別を示します。

        A ----                       -
            |                        |
            |                        P
            |                        u
            |                        b
        P(l)&P(g) ・R(cpe) ・R(pe) - l ---- C
            |                        i
            |                        c
            |                        |
        B ----                       -

   Again, the issues don't change, this simply allows discussion about
   how P(g) & P(l) are handled at each of those points.
   問題は変わっていません、これはただP(g)とP(l)がそれらのポイン
   トのそれぞれでどのようにに処理されるかの論議を許します。

   Placing all the local use prefixes under a common shorter prefix
   allows the service provider to have a common bogon filter at all
   R(pe) borders. This additional level of filtering provides a backup
   in the case that R(cpe) is misconfigured in a way that would allow
   access to P(l) from the public network. Accomplishing the same
   degree of isolation when P(l) is a subset of P(g), would require a
   unique configuration for every R(pe), and would explicitly expose
   P(l) to global access in the case of a configuration error in
   R(cpe).
   短い共通プレフィックス下にすべてのローカル使用プレフィックスを置くこ
   とは、サービスプロバイダが全R(pe)境界で共通のbogonフィルタを許
   します。この追加のレベルフィルタは公共ネットワークからP(l)までア
   クセスを許すようにR(cpe)が間違って設定された場合にバックアップ
   を供給します。P(l)がP(g)の一部である時に同じ程度の分離を達成
   することは、すべてのR(pe)でユニークな設定を必要とし、そして
   R(cpe)の設定誤りの場合に明示的にグローバルアクセスにP(l)を
   さらすでしょう。

訳注:経路制御の世界では広告可能アドレスとして登録されていないアドレス
   ブロックやAS番号が広告されている状態をBogonと言うそうです。
    --- JPNIC News & Views vol.97より ---

Applications of private address space today
今日のプライベートアドレス空間割当

   Network managers limit specific applications to internal use, so
   they configure them to only work with a filtered address range. This
   simplifies the border filter to an address prefix, rather than
   needing to employ deep packet inspection to track a potentially
   dynamic range of ports.
   ネットワーク管理者が特定のアプリケーションを内部使用に制限します、そ
   れで彼らはフィルタされたアドレス範囲でだけそれらを動くように設定しま
   す。これは潜在的に動的な範囲のポートを追跡するための深いパケット検査
   をせずに、アドレスプレフィックスによるように、境界フィルタを単純化し
   ます。

   Research ships at sea intermittently connect via INMARSAT, or when
   in port, the shipboard network is connected to shore via Ethernet.
   Of utmost importance is that the systems on board the ship all
   function, providing data collection and analysis without
   interruption. Static addressing is used on most intra-ship network
   components and servers. It's quite expensive to operate a research
   ship, so eliminating points of failure is important. Scientists on
   board collaborate with colleagues back home by sharing of data and
   email. Currently private address space is employed for several
   reasons: 1) it provides the ability to allocate significant address
   space to each ship without needing to worry about how many computers
   will be on a given cruise. 2) it provides separate address space for
   each ship. 3) it simplifies filtering to ensure shipboard traffic is
   not permitted to transmit out or bring up expensive satellite links.
   洋上の研究船が、インマルサットで断続的に接続するか、港では船ネットワー
   クをイーサネットで陸に接続します。最大限に重要性なのは、船の船内シス
   テムすべてが、妨害なしでデータ収集と分析を供給して、機能するというこ
   とです。静的アドレスがたいていの船内のネットワーク要素とサーバで使わ
   れます。研究船を操作することは非常に高価で、それで障害個所を排除する
   ことは重要です。科学者がデータ共有と電子メールによって船内で家に戻っ
   た同僚と協力します。現在プライベートアドレス空間がいくつかの理由のた
   めに利用されます:1)これは何台のコンピュータがこの船内にあるか心配せ
   ずに、各船に重要なアドレス空間を割り当てる能力を供給します。2)これは
   それぞれの船に別のアドレス空間を提供します。3)これは、外に出すのが許
   されないか、高価な人工衛星リンク使うのを許されない、船トラフィックの
   許されないことを保証するためのフィルタを簡単にします。

   Private space is used to avoid exposing to competitors what internal
   networks they are deploying and which office is coordinating that
   effort. Network managers also don't have to expose business plans to
   a registrar for evaluation for networks that are not attached to the
   global Internet. Some have stated that if they are required to
   register for public space for every internal use network, they are
   more likely to pick random numbers than tip off the competition.
   プライベート空間が競争者に内部のネットワークに何を配置しているか、そ
   してどのオフィスがその努力を調整しているかを暴露するのを避けるために
   使われます。ネットワーク管理者が同じくグローバルインターネットに置か
   れないネットワークの評価のために登記係にビジネス計画を暴露しなくても
   よいです。幾人かが、もしすべての内部使用ネットワークのために公共登録
   を要求されるなら、彼らが競争相手への助言よりも乱数を選ぶ可能性が高い
   と述べました。

   Another significant use of private address space is test networks.
   Frequently these are large, elaborate networks with a mix of public
   and private address space. Use of random unallocated space runs the
   risk of collision with legitimate addresses on remote networks.
   もう1つのプライベートアドレス空間の重要な使用がテストネットワークで
   す。しばしばこれらは公共とプライベートのアドレス空間の混合を持つ大き
   く手の込んだネットワークです。ランダムな割り当てられていない空間の使
   用は、遠隔ネットワーク上の正しいアドレスとの衝突の危険を持ちます。


Potential applications of private address space
プライベートのアドレス空間の可能性があるアプリケーション

   A well-known prefix than can be embedded in appliances so they are
   easy to sell to the average consumer and a simple filter limits
   access to the home network. Such a prefix would also simplify the
   case of file system mounts between nodes on an intermittently
   connected network. If the mount dropped every time a connect event
   caused addresses to change, the consumer would quickly find another
   product.
   装置に埋め込みの既知プレフィックスは、一般消費者に簡単に販売され、
   単純なフィルタがホームネットワークへのアクセスを制限します。このよ
   うなプレフィックスは断続的に接続されたネットワーク上でノード間の
   ファイルシステムマウントの場面を単純化するでしょう。もし接続イベン
   トでアドレスが変化する度にマウントが止まるなら、消費者はすぐに他の
   製品を買うでしょう。

   Company X has 125,000 employees globally, with regular
   reorganizations causing constant office shuffles between regions.
   Each employee has a laptop, which will have global access, and a
   network connected printer which will not have global access (we
   won't bother with the rest of the network connected devices here).
   There are 100 touch-points to the Internet, with the 3 primary ones
   running multiple OC-48 access loops.
   会社Xがグローバルに125,000人の従業員を抱え、通常の再編成が地域
   間に絶え間がないオフィス変更を起こすとします。各従業員がラップトップ
   を持っていて、そしてそれはグローバルアクセスを持ち、グローバルなアク
   セスを持たないであろうネットワーク接続されたプリンタを持つでしょう
   (我々がここでネットワーク接続された残りの装置を無視します)。インター
   ネットへの100の接続点があり、3つの主要なものが多数のOC−48ア
   クセスループを動かします。

   The 'explicit filter lists at the border' model requires keeping 100
   tables in sync in the face of constant change, and parsing a 125,000
   entry list at OC-48 rates for every packet at 3 of the borders.
   「境界での明示的なフィルタリスト」モデルは、常に変化する100のテー
   ブルの同期を取り、そして境界の3つで、すべてのパケットについて、OC
   −48レートで、125,000項目の解析を必要とします。

   The 'well-known SL filter at the border' model requires the
   organization to tell their printer manufacturer to preconfigure all
   the devices they buy to only accept and auto-configure SL prefixes
   from the RA (likely a widely demanded item), and put in a 2 entry
   list that remains static at every border. In addition, it is
   reasonable and expected that the peer across the border will
   maintain a matching version of the filter list.
   「境界の周知のSLフィルタ」モデルは、プリンタ製造業者に販売するすべ
   ての装置を、RAからのSLプレフィックスだけを受け入れる自動設定をす
   るように、事前設定するように(広く必要な項目でありそう)、そしてすべ
   ての境界で静的な2つの項目を入れるように、言う組織を必要とします。加
   えて、これは境界の向こうの通信相手がフィルタリストを一致するバージョ
   ンに維持するのが妥当であり期待されます。

   The compromise model of 'using 2 public prefixes per segment' allows
   for a 2 entry static list at every border, which may or may not be
   considered reasonable to match by the border peer. It does not
   provide the printer manufacturer a preconfiguration option that
   matches other customers, and even if it was done, as soon as Company
   X changes providers, they have to manually touch every printer for
   the new configuration.
   「部分毎に2つの公共プレフィックスを使う」妥協モデルは、すべての境界
   で2つの静的項目を許し、これは境界ピアに一致するのが合理的であると思
   うかもしれず、思わないかもしれません。これはプリンタ製造業者に他の顧
   客に対応する事前設定オプションを用意しません、そしてたとえそれがされ
   たとしても、会社Xがプロバイダを変えるとすぐに、彼らは新しい設定のた
   めに手作業ですべてのプリンタに触れなければなりません。

   To make the name service simple in these 3 cases, Company X chooses
   to run back-to-back normal dns servers. The primary set facing
   internally to accommodate dynamic updates, with a slave set facing
   externally. A periodic process will replicate the information from
   the source-of-truth internal facing servers to the external ones,
   but the security team requires it to scrub out all records for
   internal-only nodes.
   これらの3場合でネームサービスを単純にするために、会社Xが続けざまの
   標準的DNSサーバを動かすことに決めます。主サーバ群は内部を見てダイ
   ナミック更新を受け入れ、スレーブサーバ群は外部を向きます。周期的なプ
   ロセスがサーバの内部に面している「真実のソース」から外部に情報を写す
   でしょう、しかしセキュリティチームはそこから内部のみのノードのすべて
   のレコードを取り除くように要求します。

   For model 1, the scrubbing process would have to contact the border
   filter list (after deciding which was the current source of truth),
   then parse through it for all 250,000 entries to decide which are
   replicated.
   モデル1で、取り除き処理は(いずれが真実の現在のソースかを決めた後で)
   境界フィルターリストを使用し、どの項目を複製するか決定するために、す
   べての250,000項目を解析をしなければならないでしょう。

   For model 2, the scrubbing process simply has to drop records with
   the SL prefix and replicate all others.
   モデル2で、取り除き処理は、SLプレフィックスのレコードを捨て、そし
   てすべての他のものを複製しなければなりません。

   For model 3, the scrubbing process has to look for the set of
   prefixes that identify private-use, and replicate all others.
   モデル3で、取り除き処理は、プライベート使用を識別するプレフィックス
   集合をを探し、そしてすべての他のものを複製しなければなりません。

   Once any one of these processes completes, all nodes are accessible
   by name in the internal scope, and all nodes that should be accessed
   from the outside are accessible by name in the global scope.
   Applications that are expected to work across the border will have
   global scope addresses to use. Multi-party apps that use name-string
   referrals will work across the border, but those that use SL
   literals will fail by design (note: use of SL == expected to fail
   across border). Use of filtered global scope addresses makes it
   impossible for the application to know why it failed to connect.
   これらの処理のどれかが完了すると、すべてのノードは内部範囲の名前でア
   クセス可能で、そして外部からアクセスされるべきであるすべてのノードは
   グローバルな範囲の名前でアクセス可能です。境界を越えて動くことを期待
   されるアプリケーションがグローバルな範囲のアドレスを持つでしょう。名
   前文字列照会を使う多者アプリケーションが境界を越えて動作するでしょう
   が、SLリテラルを使う人たちは計画的に失敗するでしょう(ノート:SL
   の使用==境界を超えないことを期待)。フィルタされたグローバル範囲アド
   レスの使用はアプリケーションがなぜ接続に失敗したか知ることを不可能に
   します。





Summary
要約

   Filtering creates a scoped address space, no matter where the bits
   come from. The point is that some addresses are only valid within
   the scope defined by the local network manager.
   フィルタはどこからビットが来るかに関わらず範囲を持つアドレス空間を作
   ります。要点はあるアドレスがローカルネットワーク管理者によって定義さ
   れた範囲の中でだけ正当であるということです。

   In the simple case, hosts that are allowed external access have a
   policy that allows them to configure a global prefix along with the
   local one, while those that are not allowed global access have a
   policy that only allows configuring the local prefix. Address
   selection rules will prefer the smallest scope, so internal
   communications use the local scope and are forced to stay internal
   by the hard filter at the border. This puts the burden of policy
   application at the address assignment time (very infrequent) rather
   than deep parsing every packet to figure out which app sent it.
   単純な場合で、外部アクセスを許されるホストがローカルプレフィックスと
   共にグローバルプレフィックスの設定を許すポリシーを持ちます、しかしグ
   ローバルアクセスを許されないホストがローカルプレフィックスの設定だけ
   しか許されません。アドレス選択規則が最小範囲の方を優先します、それで
   内部通信がローカル範囲を使用し、そして境界でのハードフィルタによって
   内部に留まる事を強いられます。これはいずれのアプリケーションがパケッ
   トを送ったか理解するためにすべてのパケットを深く解析する野ではなく、
   ポリシー適用の重荷を(非常にたまにしか行わない)アドレス割当時にしま
   す。

   If an app chooses to assert a policy that is different from the
   network manager's filtering rules, it will fail. Having a well
   defined address space that is known to have filtering applied allows
   apps to have a hint about potential scope restrictions. That hint
   may or may not be helpful, but lack of it leaves the app in complete
   trial & error mode.
   もしアプリケーションがネットワーク管理者のフィルタ規則と異なるポリシー
   を主張することに決めるなら、それは失敗するでしょう。応用されるフィル
   タを知られている明瞭なアドレス空間を持つことは、アプリケーションが可
   能性がある範囲制限についてヒントを持つことを許します。そのヒントは助
   けになるかもしれない、あるいはそうでないかもしれませんが、それがなけ
   ればアプリケーションは完全試行とエラーの方法ができます。

   Some application developers have figured out that having an
   architected space makes it easier for them to know when connectivity
   will be broken, but others have not. The arguments by those that
   have not figured it out are much more about disallowing 'broken
   connectivity' than they are about figuring out when that happens.
   Reality says that network managers want to, and will break
   connectivity when it is in their interest, and no amount of IETF
   documentation to the contrary will prevent that.
   あるアプリケーションデベロッパーが、体系上に空間を持つことはいつ接続
   性が壊れるか知ることをより容易にすることを理解しましたが、他のものが
   理解しませんでした。それを理解しなかった人たちの議論は、そうなった時
   に理解するより「接続性破壊」を許さないという事です。現実はネットワー
   ク管理者は利益があれば接続性を壊すことを望み、それに反対するIETF
   の文書がどれだけあってもそれを防げないでしょう。

   We can choose to leave the network managers to figure out their own
   adhoc mechanisms, or we can put them in a structured space so that
   apps will have a chance to react appropriately.
   我々はネットワーク管理者に彼ら自身の特別メカニズムを理解するように委
   ねると決めることができます、あるいは我々はアプリケーションが適切に反
   応するチャンスを持つように、体系上の空間にそれらを入れることができま
   す。


Security Considerations
セキュリティの考察

   The concept of route filtering is frequently used as a tool to aid
   in network security, so having a well-known range to filter enhances
   the deployment of that tool.
   経路フィルタの概念はしばしばネットワークセキュリティを援助するツール
   として用いられます、それでフィルターする周知の範囲を持つことはその道
   具の展開を強めます。

   Access control is one aspect of what SL provides. It is a clear
   address space that service providers can put in bogon filters, and
   enterprise managers can filter without having to go into detail
   about which specific devices on a subnet are allowed in or not. It
   does not comprise a full service security solution, and should not
   be sold as such. It is simply a way to clearly articulate the
   difference between public and private endpoints.
   アクセス制御はSLが提供するものの1つの側面です。サービスプロバイダ
   がbogonフィルターに入れることができ、そして企業管理者がサブネット上
   の特定の装置が許可されているかどうかを詳細に知らずにフィルターするこ
   とができる明確なアドレス空間があります。これは完全なサービスセキュリ
   ティ解決策を含まなくて、そして完全な物として売るべきではありません。
   これは公共とプライベート端末の違いを明らかにする簡単な方法です。

   At the same time the majority of sites that use SL, will simply
   treat them as a set of prefixes to be passed around in their IGP.
   Since it will require both parties to misconfigure BGP to get those
   prefixes leaked between enterprises, they will feel more secure
   about using them. For this simple reason we need to meet the network
   manager at his comfort zone and provide a familiar tool.
   同時に、SLを使う多数のサイトが、それらをIGP内に渡すべきプレフィッ
   クスとして取り扱うでしょう。企業間でそれらのプレフィックスが漏れるに
   は、両者が設定誤りをしなければならず、彼らはそれらを使うことについて
   いっそう安全に感じるでしょう。この単純な理由のために、我々は彼の快適
   な地域でネットワーク管理者に会って、そしてよく知られた道具を供給する
   必要があります。

References
参考文献


   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
      9, RFC 2026, October 1996.

   2 draft-hain-ipv6-pi-addr-use-04.txt, Hain, T.

   3 draft-hain-ipv6-pi-addr-04.txt, Hain, T., An IPv6 Provider-
      Independent Global Unicast Address Format


Acknowledgments
謝辞

   Daniel Senie, Tim Hartrick, Michel Py, and Stephen Sprunk provided
   valuable input in the creation of this document.
   Daniel SenieとTim HartrickとMichel PyとStephen Sprunkはこの文書の作
   成で貴重な入力を供給しました。


Author's Addresses
著者のアドレス

   Tony Hain
   Cisco Systems, Inc.
   500 108th Ave. NE, Bellevue, Wa.
   Email: alh-ietf@tndh.net

[]Japanese translation by Ishida So