この文書はインターネットドラフトの日本語訳（和訳）です。 翻訳者はこの文書の翻訳の正確さを保障しません。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 翻訳者はこの翻訳の配布に制限をしません。
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].
この文書はインターネットドラフトであって、そしてＲＦＣ２０２６の１０
章のすべての条項に完全適合です。
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.
インターネットドラフトはインターネット技術タスクフォース（ＩＥＴＦ）
とそのエリアとその作業グループの作業文書です。他のグループがインター
ネットドラフトとして同じく作業文書を配るかもしれないことに注意してく
ださい。
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."
インターネットドラフトは最大６カ月間有効なドラフト文書で、いつでも他
の文書によって、更新か、置換えか、時代遅れにされるかもしれません。イ
ンターネットドラフトは、「進行中の仕事」として以外に、参照材料あるい
は引用として用いることは不適当です。
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.
多くのネットワーク管理者がＩＰｖ４でプライベートアドレスを快適に利用
しました、そして彼らがＩＰｖ６で探す最初のものは類似のメカニズムです。
彼らのフィルタリングののための絶対条件は壊れたアプリケーションに関す
る苦情の札です。これを達成する共通メカニズムは、あるローカルネットワー
クかサイト範囲に限定されたアドレス空間の一部を指定する事です。既知の
サイトローカルアドレスプレフィックスが、サイト ／ グローバル空間の同
時のサポートを供給することで、ネットワークの全ノードが同じフィルタリ
ング空間を持つＩＰｖ４の共通モデルを適用する機会を提供します。ネット
ワーク管理者の受け入れを得るために、彼らがセキュリティを判断する際に
使う道具が正確にＩＰｖ４と同じ点から始めなければなりません。その時ロー
カルとグローバルプレフィックスの同時使用はネットワーク機能を拡大する
機会があります。
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.
ローカル利用に定義されたプレフィックスが一意に限定された管理上ドメイ
ンに提供するアドレスを識別します。このプレフィックスは、公共のネット
ワークへの注入を制限する明確なフィルターを確立すると同様に、安定した
アドレス範囲をネットワーク管理者に提供します。「サイト」は、意図的に、
厳密に定義されません（ＩＧＰでエリアが厳密に定義されないように）、し
かし一般的に、オフィスやオフィスビル群やキャンパスのような、ひとつ組
織やひとつの地理的な場所をカバーすることを期待されます。そして、サイ
ト境界の一般的な使い方の例はＩＧＰとＥＧＰ間の境界線であるでしょう。
アプリケーションが参照ドメインの境界に遭遇するか知ることは難しいから、
サイト外の接続にローカル範囲アドレスを使うのは強くおろかなことです。
アプリケーションがサイト境界線を超えて動作することが期待される時、参
加しているすべてにノードがグローバル範囲アドレスを利用可能であるよう
にすることを保証する注意がとられるべきです。
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 ----
| |
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.
このネットワーク環境の必要条件の１つは、ＡあるいはＢへの到達に関して
トポロジー情報をＣに提供する事を意図するどんな処理でも、それが正しい
くて有用な情報をＣに提供することができるように、トポロジーを理解する
必要があるということです。
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.
この代わりの表現はルーティング階層面を共有するＡとＢの公共側を関連づ
けます。結果はトポロジー情報をＣに提供する意図をもつ処理は、有用な情
報を供給するためローカルとグローバル範囲の相違を認識してトポロジーを
理解することを要求します。
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).
次の論議を単純化するために、同じ絵でラベルを変えます。ローカルプレ
フィックスはＰ（ｌ）と示され、他方グローバル公共プレフィックスは
Ｐ（ｇ）で示されます。
---- 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.
この一連のネットワーク図は限定された範囲が今日多くのＩＰｖ４ネットワー
ク展開で存在することを示すために提示しました。これらの展開を動かすポ
リシーの追加の議論が、提案されたプロバイダ非依存（ＰＩ）アドレス空間
の派遣と使用の議論[2]に見いだすことができます。ここで特定のＰＩメカ
ニズムが問題ではなく、公共ネットワークサービスプロバイダによって制御
されないアドレス空間の展開の動かすポリシーが問題です。サイト制御され
た空間のための必要条件のこれ以上の論議が次章で続きます。
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.
安定−ＩＳＰ変更や、ネットワークの断続的接続の両方で。ローカル使用に
利用可能なアドレス空間は外部の関係者の変化の影響を受ず、そしてプロバ
イダの実際のあるいは人工的な囲い込みになってはなりません。
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.
安定したアドレス空間に対する強い要求は同じくネットワーク管理者がグロー
バルアクセスを欲する場合に当てはまります。あるネットワーク管理者がサー
ビスプロバイダにローカル範囲アドレスをグローバルにルーティングするこ
とを要求する懸念があります。それらが特にＰＩ空間であるよう意図されな
いなら、ローカル範囲アドレスがローカル状態でいて、そしてグローバルルー
ティングシステムの中に漏れてはなりません。問題は設計された集約特性な
しで、それらを受け入れることはグローバルルーティングテーブルの爆発を
導くということです。この理由のために、ローカルに使用するアドレス範囲
で、合理的な集約特性を持つＰＩメカニズムが開発される必要があります。
１つの方法がＩＰｖ６プロバイダ非依存グローバルユニキャストアドレス
フォーマット[3]で提言されます。これがＰＡ方法とと比べて同じほど集約し
ませんが、これは控えめな集約特性を持つ空間を用意します。ローカル使用
アドレス空間は集約特性を持たず、そして任意にルーティングされてはなり
ません。
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.
サイトの境界は意図的に不確定です。組織がサイト境界が正確にＩＧＰエリ
アあるいはＩＧＰ／ＥＧＰ境界と一致するという仮定で恐らく始まるべきで
す、しかしネットワークで意味があるなら、さらに限定するか、あるい拡大
することに決めてもよいです。サイトとＩＧＰエリアの概念は、それらがど
れぐらい情報が管理境界を超えれるを制限する点で、類似です。どんな場合
にでもポリシー境界線が公共インターネットに接続する点で存在するでしょ
う、それでここが範囲境界を実行する非常にありそうな場所です。
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:
以前の事例がローカルとグローバルのトポロジーを物理的に分けましたが、
ひとつのアドレスを持つ多数のインタフェースとひとつのインタフェースに
多数のアドレスでは、まったく同じです。この特徴はもう１つのネットワー
ク例の絵をもたらします：
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).
この設定はインタフェース毎に多数のアドレスを実装することが比較的難し
いから、ＩＰｖ４ネットワークで一般的ではありません。この絵で、ルータ
ＲはＡとＢの使っているのの中からグローバルプレフィックスだけを公共の
ネットワークに知らせるか、あるいはもしローカルプレフィックスがグロー
バルプレフィックスの一部なら、Ｒがローカル使用部に明示的にアクセス制
御をします。いずの方法でも、ＡとＢはＰ（ｇ）でもＰ（ｌ）でも到達する
が、ＣはただＡ（ｇ）とＢ（ｇ）に到達するだけです。どんな場合でも、
Ｐ（ｌ）の制限されたルーティング範囲によって生じた問題は、最初の多数
のインタフェースの場合と同じで、完全にＰ（ｌ）の割当源と独立です。
Adding a little more detail to the drawing, shows the distinction
between the customer premise equipment (CPE) router, and the
provider edge (PE) router.
絵にもう少し細部を加えて、顧客宅内機器（ＣＥＰ）ルータとプロバイダ
エッジ（ＰＥ）ルータ間の区別を示します。
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.
問題は変わっていません、これはただＰ（ｇ）とＰ（ｌ）がそれらのポイン
トのそれぞれでどのようにに処理されるかの論議を許します。
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).
短い共通プレフィックス下にすべてのローカル使用プレフィックスを置くこ
とは、サービスプロバイダが全Ｒ（ｐｅ）境界で共通のbogonフィルタを許
します。この追加のレベルフィルタは公共ネットワークからＰ（ｌ）までア
クセスを許すようにＲ（ｃｐｅ）が間違って設定された場合にバックアップ
を供給します。Ｐ（ｌ）がＰ（ｇ）の一部である時に同じ程度の分離を達成
することは、すべてのＲ（ｐｅ）でユニークな設定を必要とし、そして
Ｒ（ｃｐｅ）の設定誤りの場合に明示的にグローバルアクセスにＰ（ｌ）を
さらすでしょう。
訳注：経路制御の世界では広告可能アドレスとして登録されていないアドレス
ブロックやＡＳ番号が広告されている状態を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.
もう１つのプライベートアドレス空間の重要な使用がテストネットワークで
す。しばしばこれらは公共とプライベートのアドレス空間の混合を持つ大き
く手の込んだネットワークです。ランダムな割り当てられていない空間の使
用は、遠隔ネットワーク上の正しいアドレスとの衝突の危険を持ちます。
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.
会社Ｘがグローバルに１２５,０００人の従業員を抱え、通常の再編成が地域
間に絶え間がないオフィス変更を起こすとします。各従業員がラップトップ
を持っていて、そしてそれはグローバルアクセスを持ち、グローバルなアク
セスを持たないであろうネットワーク接続されたプリンタを持つでしょう
（我々がここでネットワーク接続された残りの装置を無視します）。インター
ネットへの１００の接続点があり、３つの主要なものが多数のＯＣ−４８ア
クセスループを動かします。
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.
「境界での明示的なフィルタリスト」モデルは、常に変化する１００のテー
ブルの同期を取り、そして境界の３つで、すべてのパケットについて、ＯＣ
−４８レートで、１２５,０００項目の解析を必要とします。
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.
「境界の周知のＳＬフィルタ」モデルは、プリンタ製造業者に販売するすべ
ての装置を、ＲＡからのＳＬプレフィックスだけを受け入れる自動設定をす
るように、事前設定するように（広く必要な項目でありそう）、そしてすべ
ての境界で静的な２つの項目を入れるように、言う組織を必要とします。加
えて、これは境界の向こうの通信相手がフィルタリストを一致するバージョ
ンに維持するのが妥当であり期待されます。
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.
「部分毎に２つの公共プレフィックスを使う」妥協モデルは、すべての境界
で２つの静的項目を許し、これは境界ピアに一致するのが合理的であると思
うかもしれず、思わないかもしれません。これはプリンタ製造業者に他の顧
客に対応する事前設定オプションを用意しません、そしてたとえそれがされ
たとしても、会社Ｘがプロバイダを変えるとすぐに、彼らは新しい設定のた
めに手作業ですべてのプリンタに触れなければなりません。
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.
これらの３場合でネームサービスを単純にするために、会社Ｘが続けざまの
標準的ＤＮＳサーバを動かすことに決めます。主サーバ群は内部を見てダイ
ナミック更新を受け入れ、スレーブサーバ群は外部を向きます。周期的なプ
ロセスがサーバの内部に面している「真実のソース」から外部に情報を写す
でしょう、しかしセキュリティチームはそこから内部のみのノードのすべて
のレコードを取り除くように要求します。
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.
モデル１で、取り除き処理は（いずれが真実の現在のソースかを決めた後で）
境界フィルターリストを使用し、どの項目を複製するか決定するために、す
べての２５０,０００項目を解析をしなければならないでしょう。
For model 2, the scrubbing process simply has to drop records with
the SL prefix and replicate all others.
モデル２で、取り除き処理は、ＳＬプレフィックスのレコードを捨て、そし
てすべての他のものを複製しなければなりません。
For model 3, the scrubbing process has to look for the set of
prefixes that identify private-use, and replicate all others.
モデル３で、取り除き処理は、プライベート使用を識別するプレフィックス
集合をを探し、そしてすべての他のものを複製しなければなりません。
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.
これらの処理のどれかが完了すると、すべてのノードは内部範囲の名前でア
クセス可能で、そして外部からアクセスされるべきであるすべてのノードは
グローバルな範囲の名前でアクセス可能です。境界を越えて動くことを期待
されるアプリケーションがグローバルな範囲のアドレスを持つでしょう。名
前文字列照会を使う多者アプリケーションが境界を越えて動作するでしょう
が、ＳＬリテラルを使う人たちは計画的に失敗するでしょう（ノート：ＳＬ
の使用==境界を超えないことを期待）。フィルタされたグローバル範囲アド
レスの使用はアプリケーションがなぜ接続に失敗したか知ることを不可能に
します。
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.
あるアプリケーションデベロッパーが、体系上に空間を持つことはいつ接続
性が壊れるか知ることをより容易にすることを理解しましたが、他のものが
理解しませんでした。それを理解しなかった人たちの議論は、そうなった時
に理解するより「接続性破壊」を許さないという事です。現実はネットワー
ク管理者は利益があれば接続性を壊すことを望み、それに反対するＩＥＴＦ
の文書がどれだけあってもそれを防げないでしょう。
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.
アクセス制御はＳＬが提供するものの１つの側面です。サービスプロバイダ
が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.
同時に、ＳＬを使う多数のサイトが、それらをＩＧＰ内に渡すべきプレフィッ
クスとして取り扱うでしょう。企業間でそれらのプレフィックスが漏れるに
は、両者が設定誤りをしなければならず、彼らはそれらを使うことについて
いっそう安全に感じるでしょう。この単純な理由のために、我々は彼の快適
な地域でネットワーク管理者に会って、そしてよく知られた道具を供給する
必要があります。
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