この文書はインターネットドラフトの日本語訳（和訳）です。 翻訳者はこの文書の翻訳の正確さを保障しません。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 翻訳者はこの翻訳の配布に制限をしません。
Network Working Group Alain Durand
INTERNET-DRAFT SUN Microsystems, inc.
October 25, 2002 Jun-ichiro itojun Hagino
Expires April 2002 IIJ Research Laboratory
Dave Thaler
Microsoft
Well known site local unicast addresses
to communicate with recursive DNS servers
ＤＮＳサーバと通信するための
既知サイトローカルユニキャストアドレス
<draft-ietf-ipv6-dns-discovery-07.txt>
Status of this memo
このメモの状態
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
この文書はインターネットドラフトであって、そしてＲＦＣ２０２６の１０
章のすべての条項に完全適合です。
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 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 a "work in progress".
インターネットドラフトは最大６カ月間有効で、いつでも他の文書によって、
更新か、置換えか、時代遅れにされるかもしれません。インターネットドラ
フトは、「進行中の仕事」として以外に、参照材料あるいは引用として用い
ることは不適当です。
To view the list Internet-Draft Shadow Directories, see
http://www.ietf.org/shadow.html.
インターネットドラフトの影ディレクトリのリストは
http://www.ietf.org/shadow.html でアクセスできます。
Abstract
概要
This documents specifies 3 well known addresses to configure stub
resolvers on IPv6 nodes to enable them to communicate with recursive
DNS server with minimum configuration in the network and without
running a discovery protocol on the end nodes. This method may be
used when no other information about the addresses of recursive DNS
servers is available. Implementation of stub resolvers using this as
default configuration must provide a way to override this.
これ文書はＩＰｖ６ノードが再帰ＤＮＳサーバと通信するスタブリゾルバサー
バをネットワークの最小設定で、エンドノードの探索プロトコルなしで設定
する際の３つの既知アドレスを指定します。この方法は、他の再帰ＤＮＳサー
バアドレスの情報が利用可能ではない時に使われるかもしれません。これを
デフォルト設定として用いているスタブリゾルバの実装がこれに優先する方
法を供給しなくてはなりません。
Copyright notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
1. Introduction
1. はじめに
RFC 2462 [ADDRCONF] provides a way to autoconfigure nodes with one or
more IPv6 address and default routes.
ＲＦＣ２４６２[ADDRCONF]が１つ以上のＩＰｖ６アドレスとデフォルトルー
トをノードに自動設定する方法に提供します。
However, for a node to be fully operational on a network, many other
parameters are needed, such as the address of a name server that
offer recursive service (a.k.a. recursive DNS server), mail relays,
web proxies, etc. Except for name resolution, all the other services
are usually described using names, not addresses, such as
smtp.myisp.net or webcache.myisp.net. For obvious bootstrapping
reasons, a node needs to be configured with the IP address (and not
the name) of a recursive DNS server. As IPv6 addresses look much
more complex than IPv4 ones, there is some incentive to make this
configuration as automatic and simple as possible.
しかし、ノードがネットワーク上で完全に使用可能であるためには多くの他
のパラメータが必要です、例えば、再帰サービスを供給するネーム名前サー
バ（別名の回帰ＤＮＳサーバ）、メールリレー、ウェブプロキシなどです。
名前解決以外、すべての他のサービスは通常アドレスではなく、
smtp.myisp.netやwebcache.myisp.netのような名前を使って記述されます。
明白な起動処理の理由で、ノードが回帰ＤＮＳサーバについて（名前ではな
く）ＩＰアドレスで設定される必要があります。ＩＰｖ６アドレスがＩＰｖ
４よりずっと複雑に見えるから、この形状を可能な限り自動で、そして単純
にするある誘惑があります。
Although it would be desirable to have all configuration parameters
configured/discovered automatically, it is common practice in IPv4
today to ask the user to do manual configuration for some of them by
entering server names in a configuration form. So, a solution that
will allow for automatic configuration of the recursive DNS server is
seen as an important step forward in the autoconfiguration story.
すべての設定パラメータが設定／自動発見されることは望ましいけれども、
今日のＩＰｖ４でユーザがサーバ名を設定形式に入力する手動の設定は普通
の習慣です。それで、回帰ＤＮＳサーバの自動設定を考慮する解決が自動設
定のストーリーの促進への重要なステップだと見られます。
The intended usage scenario for this proposal is a home or enterprise
network where IPv6 nodes are plugged/unplugged with minimum
management and use local resources available on the network to
autoconfigure. This proposal is also useful in cellular networks
where all mobile devices are included within the same site.
この提案の意図する使い方のシナリオは、最小管理のＩＰｖ６ノードが接続
されたり切り離されたりし、自動設定でネットワーク上の利用可能なローカ
ル資源を使用する、ホームや企業ネットワークです。この提案は同じサイト
内にすべての移動装置が含まれるセルラのネットワークで同じく有用です。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [KEYWORDS].
この文書のキーワード"MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と"SHALL
NOT"と"SHOULD", "SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"は
[KEYWORDS]で記述されるように解釈されます。
2. Well known addresses vs discovery
2. 既知アドレス対探索
Some of the discussions in the past around DNS server discovery have
been trying to characterize the solution space into stateless versus
stateful or server oriented versus severless. It is not absolutely
clear how much state if any needs to be kept to perform DNS server
discovery, and, although the semantic differences between a router
and a server are well understood from a conceptual perspective, the
current implementations tend to blur the picture. In another attempt
to characterize different approaches, one can look at how much
intelligence a client needs to have in order to use the service.
過去のいくつかのＤＮＳサーバ探索の議論で、状態なしと状態ありやサーバ
依存とサーバなしの、解決方法の特性描写が試みられました。ＤＮＳサーバ
探索の実行を維持するためにどれだけの状態が必要かは絶対的に明確ではな
く、そして、ルータとサーバの間の意味の相違が概念的な見地からはよく理
解されるけれども、現在の実装は全体像をあいまいにする傾向があります。
異なる方法を描写する他の試みじゃ、１つはクライアントがサービスを使う
ためにどれぐらいの知性を持つ必要があるか調査することがす。
One avenue is to ask the IPv6 node to participate in a discovery
protocol, such as SLP or DHCP, learn the address of the server and
send packets to this server. Another one is to configure the IPv6
node with well known addresses and let the local routing system
forward packets to the right place. This document explores this
later avenue of configuration using well known addresses that does
not require participation of the end node in any discovery mechanism.
１つの道はＩＰｖ６ノードがＳＬＰやＤＨＣＰのような探索プロトコルに参
加し、サーバアドレスを学び、そしてサーバにパケットを送るように依頼す
る事です。もう１つは既知アドレスでＩＰｖ６ノードを設定し、そしてロー
カルルーティングシステムにパケットを正しい位置に転送させることです。
この文書はエンドノードがどんな探索メカニズムへの参加も必要としない既
知アドレスを使た設定の後の道を探究します。
3. Reserved prefix and addresses
3. 予約プレフィックスとアドレス
The mechanism described here is:
ここで記述されたメカニズムは以下です：
- intended for ongoing use and not not just for bootstrapping
- 起動時ではなく、進行中の処理の使用に対して意図。
- intended to populate a stub resolver's list of available
recursive servers only if that list is otherwise unpopulated
- 他にない場合に、スタブリゾルバの利用可能な回帰サーバリストに入
れることを意図。
- providing reliability through redundancy using three unicast
addresses.
- ３つのユニキャストアドレスの冗長性を使って信頼性を供給。
3.1 Stub resolver configuration
3.1 スタブリゾルバ設定
This memo reserved three well known IPv6 site local addresses.
このメモは３つの既知ＩＰｖ６サイトサイトアドレスを予約しました。
In the absence of any other information about the addresses of
recursive DNS servers, IPv6 stub-resolvers MAY use any of those three
IPv6 addresses in their list of candidate recursive DNS servers.
他のいかなる回帰ＤＮＳサーバのアドレスの情報がない場合、ＩＰｖ６スタ
ブリゾルバがそれらの、回帰ＤＮＳサーバ候補のリストでそれらの３つのＩ
Ｐｖ６アドレスを使うかもしれません(MAY)。
3.2 Recursive DNS servers configuration
3.2 回帰ＤＮＳサーバ設定
Within sites, one or more recursive DNS server SHOULD be configured
with any of those three addresses. It is RECOMMENDED that large sites
deploy 3 recursive DNS servers, one for each reserved address. Small
site could use only one recursive DNS server and assign the 3
addresses to it.
サイト内で、１つ以上の回帰ＤＮＳサーバがこれらの３つのアドレスのどれ
かで構成を設定されるべきです(SHOULD)。大きいサイトが３つの回帰ＤＮＳ
サーバのそれぞれで予約アドレスを働かせることは勧められます
(RECOMMENDED)。小さいサイトがただ１つだけの回帰ＤＮＳサーバを使い、
そして３つのアドレスをそれに割り当てることができます。
3.3 Rationale for the choice of three addresses
3.3 ３つのアドレスの選択の原理
Three was chosen based on common practice in many places in the
industry. While it's true that if the first one fails, that it's
unlikely the second one will succeed (due to there really being no
DNS server at all), using multiple addresses is important so that
when ones do exist, the host can fail over to a second server more
quickly than routing converges. Three servers is a compromise between
extra reliability and increased complexity (maintaining additional
servers, having multiple entries in the routing system, additional
delays before the stub resolver returns an error,...).
３は産業の多くの場所での共通の習慣に基づいて選択されました。もし最初
の１つが失敗したら（ＤＮＳサーバがそこにないだろうから）２つ目が成功
する可能性は低いでしょうが、複数のアドレスを使うとＤＮＳサーバあると
きに、ルーチングが収束するよりも速くホストは２番目のサーバを試せます。
３つのサーバは信頼性の向上と複雑さ（追加のサーバの管理、ルーティング
システムでの複数の項目の維持、スタブリゾルバがエラーを返す前にの遅れ
の追加）の減少の間の折衷案です。
Another reason to have multiple addresses is to avoid the need to use
of anycast addresses to achieve reliability through redundancy. On
top of the classic problems (TCP sessions, ICMP messages,...) using
an anycast address would hide the real locations of the recursive DNS
servers to the stub resolver, prohibiting it to keep track of which
servers are performing correctly. For this particular matter, using
well known addresses is no different than configuring the stub
resolver with regular addresses taken from the local site.
多数のアドレスを持つもう１つの理由は、冗長性による信頼性を成し遂げる
ためにエニキャストアドレスを使う必要を避けるためです。エニキャストア
ドレスを使う古典的な問題（ＴＣＰセッション、ＩＣＭＰメッセージ、・・
・）の最も大きいのは、これがＤＮＳサーバの本当の場所を隠し、スタブリ
ゾルバがどのサーバが正確に能力を発揮しているか記録・追跡する事を禁止
する事です。この特定の問題のために既知アドレスの使用は、スタブリゾル
バにとってローカルサイトの普通のアドレスを設定すること同じです。
3.4 Implementation considerations
3.4 実装の考慮
Stub resolver implementation MAY be configured by default using those
addresses. However, implementing only the mechanism described in this
memo may end up causing some interoperability problems when operating
in networks where no recursive DNS server is configured with any of
the well known addresses. Thus, stub resolvers MUST implement
mechanisms for overriding this default, for example: manual
configuration, L2 mechanisms and/or DHCPv6.
スタブリゾルバ実装がこれらのアドレスを使ってデフォルトで設定されるか
もしれません(MAY)。しかしながら、このメモに記述されたメカニズムだけを
実装することは、回帰ＤＮＳサーバが既知アドレスを使わずに構成を設定さ
れないネットワークで動作させるとき、いくつかの互換性問題を起こすこと
になってしまうかもしれません。それで、スタブリゾルバがこのデフォルト
を上書きするメカニズムを実装しなくてはなりません、例えば：手動設定、
Ｌ２メカニズム、ＤＨＣＰｖ６。
4. Routing
4. ルーティング
A solution to enable the stub resolvers to reach the recursive DNS
servers is to inject host routes in the local routing system.
Examples of methods for injecting host routes and a brief discussion
of their fate sharing properties are presented here:
スタブリゾルバが回帰ＤＮＳサーバに届くことができるようにする解決はロー
カルなルーティングシステムにホストルートを注入することです。ホストルー
トの注入方法の例とその運命の共有特性の短い論議がここで提出されます：
a) Manual injection of routes by a router on the same subnet.
If the node running the recursive DNS server goes down, the router
may or may not be notified and keep announcing the route.
a) 同じサブネット上のルータによるルートの手動の注入。もし回帰ＤＮ
Ｓサーバを動かすノードが停止するなら、ルータに通知があるかもしれず
ないかもしれず、そして経路を公表し続けるかもしれません。
b) Running a routing protocol on the same node running the DNS
resolver.
If the process running the recursive DNS server dies, the routing
protocol may or may not be notified and keep announcing the route.
b) ルーティングプロトコルをＤＮＳリゾルバを走らせている同じノード
上で走らせる。もし回帰ＤＮＳサーバを駆動しているプロセスが停止す
る、ルーティングプロトコルに通知があるかもしれずないかもしれず、
そして経路を公表し続けるかもしれません。
c) Running a routing protocol within the same process running the
recursive DNS server.
If the recursive DNS server and the routing protocol run in
separated threads, similar concerns as above are true.
c) 回帰ＤＮＳサーバを動かしている同じプロセスの中でルーティングプ
ロトコルを動かす。もし回帰ＤＮＳサーバとルーティングプロトコルが
切り離されたスレッド上で動作するなら、上記と類似の懸念は同じです。
d) Developing an "announcement" protocol that the recursive DNS
server could use to advertize the host route to the nearby router.
Details of such a protocol are out of scope of this document, but
something similar to [MLD] is possible. However, the three first
mechanisms should cover most cases.
d) 回帰ＤＮＳサーバが近くのルータにホスト経路を広告する「告知」プ
ロトコルを開発する。このようなプロトコルの詳細はこの文書の範囲外で
す、しかし[MLD]に類似している何かが可能です。しかしながら、最初の
３つの機構はたいていの場合をカバーするべきです。
An alternate solution is to configure a link with the well known
prefix and position the three recursive DNS servers on that link.
The advantage of this method is that host routes are not necessary ,
the well known prefix is advertised to the routing system by the
routers on the link. However, in the event of a problem on the
physical link, all resolvers will become unreachable.
代わりの解決が既知プレフィックスとでリンクの構成を設定して、そしてそ
のリンク上に３つの回帰ＤＮＳサーバを置くことです。この方法の利点はホ
ストルートが必要ではないということです、既知プレフィックスはリンク上
のルータによってルーティングシステムに広告されます。しかしながら、物
理リンク上に問題がある場合、すべてのリゾルバは到達不可能になるでしょ
う。
IANA considerations for this prefix are covered in Section 6.
このプレフィックスに対するＩＡＮＡの考慮が６章でカバーされます。
5. Site local versus global scope considerations
5. サイトローカル対グローバル範囲の考察
The rationales for having a site local prefix are:
サイトローカルプレフィックスを持原理は以下です：
-a) Using a site local prefix will ensure that the traffic to the
recursive DNS servers stays local to the site. This will prevent
the DNS requests from accidentally leaking out of the site.
However, the local resolver can implement a policy to forward DNS
resolution of non-local addresses to an external DNS resolver.
-a) サイトローカルプレフィックスを使うことは回帰ＤＮＳサーバへのト
ラフィックがサイトにローカルな状態でいることを保証するでしょう。こ
れは偶然にサイトから漏れることからＤＮＳ要求を妨げるでしょう。しか
しながら、ローカルリゾルバは非ローカルアドレスのＤＮＳ解決を外部の
ＤＮＳリゾルバに転送するポリシーを実行することができます。
-b) Reverse DNS resolution of site local addresses is only
meaningful within the site. Thus, making sure that such queries
are first sent to a recursive DNS server located within the site
perimeter increase their likelihood of success.
-b) サイトローカルアドレスの逆ＤＮＳ解決はサイト内でだけ有意義です。
それで、このような問合せが最初にサイト内に位置する回帰ＤＮＳサーバ
に送られることを確かにすることは成功の可能性を高めます。
6. Examples of use
6. 役に立つ例
This section presents example scenarios showing how the mechanism
described in this memo can co-exist with other techniques, namely
manual configuration and DHCPv6 discovery.
この章はどのようにこのメモで記述されたメカニズムが他の技術、すなわち、
手動設定とＤＨＣＰｖ６探索が共存できるか示しているシナリオ例を提出し
ます。
Note: those examples are just there to illustrate some usage
scenarios and in no way do they suggest any recommended practices.
メモ：これらの例はあるシナリオ使用を例証してるだけで、決して推薦され
た習慣を提案しません。
6.1 Simple case, general purpose recursive DNS server
6.1 単純な場合、汎用回帰ＤＮＳサーバ
This example shows the case of a network that manages one recursive
DNS server and a large number of nodes running DNS stub resolvers.
The recursive DNS server is performing (and caching) all the
recursive queries on behalf of the stub resolvers. The recursive DNS
server is configured with an IPv6 address taken from the prefix
delegated to the site and with the 3 well known addresses defined in
this memo. The stub resolvers are either configured with the "real"
IPv6 address of the recursive DNS server or with the well known site
local unicast addresses defined in this memo.
この例は１つの回帰ＤＮＳサーバとＤＮＳスタブリゾルバを走らせている多
数のノードを管理するネットワークの事例を示します。回帰ＤＮＳサーバは
スタブリゾルバのためにすべての回帰問合せを行い（そしてキャッシュし）
ます。回帰ＤＮＳサーバはこのサイトに委任されたプレフィックスから得ら
れたＩＰｖ６アドレスと、このメモで定義された３つの既知アドレスで構成
を設定されます。スタブリゾルバは、回帰ＤＮＳサーバの「本当の」ＩＰｖ
６アドレスか、あるいはこのメモで定義した既知サイトローカルユニキャス
トアドレスで設定されます。
--------------------------------------------
| |
| --------------------- |
| |DNS stub resolver | |
| |configured with the| |
| |"real" address of | |
| |the recursive DNS | |
| |server | |
| |ＤＮＳスタブリゾル | |
| |バが回帰ＤＮＳサー | |
| |バの「本当の」アド | |
| |レスで設定される。 | |
| --------------------- |
| ----------- | |
| |recursive| | |
| |DNS |<---------- |
| |server |<---------------- |
| |回帰ＤＮ | | |
| |Ｓサーバ | | |
| ----------- | |
| ---------------------- |
| |DNS stub resolver | |
| |configured with 3 | |
| |well known addresses| |
| |ＤＮＳスタブリゾルバ| |
| |が３つの既知アドレス| |
| |で設定される。 | |
| ---------------------- |
| |
--------------------------------------------
(The recursive DNS server is configured to listen both on
its IPv6 address and on the well known address)
（回帰ＤＮＳサーバはそのＩＰｖ６アドレスと既知アドレスの両
方で聞くように設定されます）
6.2 Three recursive DNS servers
6.2 ３つの回帰ＤＮＳサーバ
This is a similar example as above, except that three recursive DNS
resolvers are configured instead of just one.
これは、３つの回帰ＤＮＳリゾルバが、１つの代わりに構成を設定されるこ
と以外、上に例に類似です。
-------------------------------------------
| |
| --------------------- |
| |DNS stub resolver | |
| |configured with the| |
| |"real" address of | |
| |the recursive DNS | |
| |server | |
| |ＤＮＳスタブリゾル | |
| |バが回帰ＤＮＳサー | |
| |バの「本当の」アド | |
| |レスで設定される。 | |
| --------------------- |
| | |
| ----------- | |
| |recursive| | |
| |DNS |<---------| |
| |server 1 |<---------|------ |
| |回帰ＤＮ | | | |
| |Ｓサーバ1| | | |
| ----------- | | |
| | | |
| ----------- | | |
| |recursive| | | |
| |DNS |<---------| | |
| |server 2 |<---------|-----| |
| |回帰ＤＮ | | | |
| |Ｓサーバ2| | | |
| ----------- | | |
| | | |
| ----------- | | |
| |recursive| | | |
| |DNS |<---------- | |
| |server 3 |<---------------| |
| |回帰ＤＮ | | | |
| |Ｓサーバ3| | | |
| ----------- | |
| ---------------------- |
| |DNS stub resolver | |
| |configured with 3 | |
| |well known addresses| |
| |ＤＮＳスタブリゾルバ| |
| |が３つの既知アドレス| |
| |で設定される。 | |
| ---------------------- |
| |
-------------------------------------------
(The recursive DNS server is configured to listen both on
its IPv6 address and on the well known address)
（回帰的ＤＮＳサーバはそのＩＰｖ６アドレスと既知アドレス上
で聞くように設定されます）
6.3 DNS forwarder
6.3 ＤＮＳ転送者
A drawback of the choice of site local scope for the reserved
addresses for recursive DNS server is that, in the case of a
home/small office network connected to an ISP, DNS traffic cannot be
sent directly to the ISP recursive DNS server without having the ISP
and all its customers share the same definition of site.
回帰ＤＮＳサーバの予約アドレスのためのサイトローカル範囲の選択の欠点
は、ＩＳＰに接続したホーム／スモールオフィスネットワークの場合で、Ｄ
ＮＳトラフィックが直接ＩＳＰに送ることが出来ず、そしてすべてその顧客
がサイトの同じ定義を共有するということです。
In this scenario, the home/small office network is connected to the
ISP router (PE) via an edge router (CPE).
このシナリオで、ホーム／スモールオフィスネットワークはエッジルータ
（ＣＰＥ）によってＩＳＰルータ（ＰＥ）に接続しています。
-------------
/ |
-------- ----- / |
|ISP PE| |CPE| / Customer |
| |===========| |====< site |
| | | | \ 顧客サイト |
-------- ----- \ |
\ |
-------------
The customer router CPE could be configured on its internal interface
with one of the reserved site local addresses and listen for DNS
queries. It would be configured to use one (or several) of the well
known site local unicast addresses within the ISP's site to send its
own queries to. It would act as a DNS forwarder, forwarding queries
received on its internal interface to the ISP's recursive DNS server.
顧客ルータＣＰＥは予約のサイトローカルアドレスの１つが内部インタフェー
ス上で設定され、そしてＤＮＳ問合せに聞き耳をたてることができます。ルー
タ自身は問合せを送るべきＩＳＰサイトの中の既知サイトローカルユニキャ
ストアドレスの１（あるいはいくつか）を使うように設定されるでしょう。
これは、その内部インタフェース上で受信した問合せをＩＳＰの回帰ＤＮＳ
サーバに転送し、ＤＮＳ転送者の役を務めるでしょう。
-------------
/ |
---------- -------------- / |
|ISP | | CPE| / Customer |
|DNS |===========| DNS|====< site |
|server | <------|---forwarder|-----\---- |
|ＤＮＳ | | ＤＮＳ| \ 顧客サイト |
|サーバ | | 転送者| \ |
---------- -------------- -------------
In this configuration, the CPE is acting as a multi-sited router.
この設定で、ＣＰＥはマルチサイトルータの役を務めています。
6.4 DNS forwarder with DHCPv6 interactions
6.4 ＤＨＣＰｖ６対話を持つＤＮＳ転送者
In this variant scenario, DHCPv6 is be used between the PE and CPE to
do prefix delegation [DELEG] and recursive DNS server discovery.
このシナリオで、ＤＨＣＰｖ６はＰＥとＣＰＥの間でプレフィックス委任
[DELEG]と回帰ＤＮＳサーバ探索に使われます。
-------------
/ |
-------- -------------- / |
|ISP | |customer CPE| / Customer |
|DHCPv6|===========| DHCPv6|====< site |
|server| <------|------client| \ |
|DHCPv6| | DHCPv6| \ 顧客サイト |
|サーバ| | 転送者| \ |
-------- -------------- -------------
This example will show how DHCPv6 and well known site local unicast
addresses cooperate to enable the internal nodes to access DNS.
この例はどのようにＤＨＣＰｖ６と既知サイトローカルユニキャストアドレ
スが、内部ノードがＤＮＳアクセスすることができるようにするために協力
するかを示すでしょう。
The customer router CPE is configured on its internal interface with
one of the reserved site local addresses and listen for DNS queries.
It would act as a DNS forwarder, as in 5.2, forwarding those queries
to the recursive DNS server pointed out by the ISP in the DHCPv6
exchange.
顧客ルータＣＰＥは内部インタフェースで予約サイトローカルアドレスの１
つを設定されます、そしてＤＮＳ問合せに聞き耳をたます。これは５.２のよ
うにＤＮＳ転送者の役を務め、問合せをＤＨＣＰv６交換でＩＳＰの指定した
回帰ＤＮＳサーバに転送します。
-------------
/ |
---------- -------------- / |
|ISP | |customer CPE| / Customer |
|DNS |===========| DNS|====< site |
|resolver| <------|---forwarder|-----\---- |
|ＤＮＳ | | ＤＮＳ| \ 顧客サイト |
|リゾルバ| | 転送者| \ |
---------- -------------- -------------
The same CPE router could also implement a local DHCPv6 server and
advertizes itself as DNS forwarder.
同じＣＰＥルータは同じくローカルＤＨＣＰｖ６サーバを実装できて、そし
てＤＮＳ転送者としてそれ自身を広告します。
-------------
/ |
-------- -------------- / Customer |
|ISP PE| |customer CPE| / site |
| |===========|DHCPv6 |====< 顧客サイト |
| | |server------|-----\---> |
-------- |DHCPv6 | \ 顧客サイト |
|転送者 | \ |
-------------- -------------
Within the site:
サイト内で：
a) DHCPv6 aware clients use DHCPv6 to obtain the address of the
DNS forwarder...
a) ＤＨＣＰｖ６対応クライアントがＤＮＳ転送者...のアドレスを得る
ためにＤＨＣＰｖ６を使います。
-------------
/ Customer |
---------- -------------- / site |
|ISP | |customer CPE| / 顧客サイト |
|DNS |===========| DNS|====< DHCPv6 |
|resolver| <------|---forwarder|-----\----client |
|ＤＮＳ | | ＤＮＳ| \ DHCPv6 |
|リゾルバ| | 転送者| \クライアント|
---------- -------------- -------------
(The address of the DNS forwarder is acquired via DHCPv6.)
（ＤＮＳ転送者のアドレスはＤＨＣＰｖ６によって獲得されます）
b) other nodes simply send their DNS request to the reserved site
local addresses.
b) 他のノードが予約のサイトローカルアドレスにＤＮＳ要求を送ります。
-------------
/ |
---------- -------------- / customer |
|ISP | |customer CPE| / site |
|DNS |===========| DNS|====< 顧客サイト |
|resolver| <------|---forwarder|-----\----non DHCPv6|
|ＤＮＳ | | ＤＮＳ| \ 非DHCPv6 |
|リゾルバ| | 転送者| \クライアント|
---------- -------------- -------------
(Internal nodes use the reserved site local unicast address.)
（内部ノードが予約サイトローカルユニキャストアドレスを使います）
A variant of this scenario is the CPE can decide to pass the global
address of the ISP recursive DNS server in the DHCPv6 exchange with
the internal nodes.
このシナリオの変形がＣＰＥが内部のノードにＤＨＣＰｖ６交換でＩＳＰ回
帰ＤＮＳサーバのグローバルアドレスを渡すと決めることができるというこ
とです。
7. IANA considerations
7. ＩＡＮＡの考慮
The site local prefix fec0:0000:0000:ffff::/64 is to be reserved out
of the site local fec0::/10 prefix.
サイトローカルプレフィックスfec0:0000:0000:ffff::/64は、サイトローカ
ルプレフィックスfec0::/10から予約されるはずです。
The unicast addresses fec0:000:0000:ffff::1, fec0:000:0000:ffff::2
and fec0:000:0000:ffff::3 are to be reserved for recursive DNS server
configuration.
ユニキャストアドレスfec0:000:0000:ffff::1とfec0:000:0000:ffff::2と
fec0:000:0000:ffff::3は回帰ＤＮＳサーバ設定のために留保されます。
All other addresses within the fec0:0000:0000:ffff::/64 are reserved
for future use and are expected to be assigned only with IESG
approval.
すべてのfec0:0000:0000:ffff::/64の中の他のアドレスは未来の使用のた
めに確保されて、そしてＩＥＳＧ賛成でだけ割り当てられることを期待さ
れます。
8. Security Considerations
8. セキュリティの考察
Ensuring that queries reach a legitimate DNS server relies on the
security of the IPv6 routing infrastructure. The issues here are the
same as those for protecting basic IPv6 connectivity.
問合せが正当なＤＮＳサーバと連絡を取ることを保証することはＩＰｖ６ルー
ティング基盤のセキュリティに依存します。問題は基本的なＩＰｖ６接続性
を守ることと比べて同じです。
IPsec/IKE can be used as the well known addresses are used as unicast
addresses.
IPsec/IKEは、既知アドレスがユニキャストアドレスとして用いられるから、
使うことができます。
The payload can be protected using standard DNS security techniques.
If the client can preconfigure a well known private or public key
then TSIG [TSIG] can be used with the same packets presented for the
query. If this is not the case, then TSIG keys will have to be
negotiated using [TKEY]. After the client has the proper key then
the query can be performed.
ペイロードは標準的ＤＮＳセキュリティ技術を使って守ることができます。
もしクライアントが既知の秘密か公開鍵を事前設定できるなら、問い合わせ
と同じパケットでＴＳＩＧ[TSIG]が使えます。もしこうでなければ、ＴＳＩ
Ｇ鍵が[TKEY]を使って交渉されなければならないでしょう。クライアントが
適切な鍵を持ってから、質問を行うことが出来ます。
The use of site local addresses instead of global addresses will
ensure the DNS queries issued by host using this mechanism will not
leak out of the site.
グローバルアドレスの代わりのサイトローカルアドレスを使うのは、このメ
カニズムを使っているホストが出した問合せがサイトから漏れない事をＤＮ
Ｓに保証するでしょう。
9. References
9. 参考文献
[KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[ADDRCONF]
Thomson, S., and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[MLD]
Deering, S., Fenner, W., Haberman, B.,
"Multicast Listener Discovery (MLD) for IPv6",
RFC2710, October 1999.
[TSIG]
Vixie, P., Gudmundsson, O., Eastlake, D. and B. Wellington,
"Secret Key Transaction Authentication for DNS (TSIG)",
RFC2845, May 2000.
[TKEY]
D. Eastlake, "Secret Key Establishment for DNS (TKEY RR)",
RFC2930, September 2000.
[DHCPv6]
Bound, J., Carney, M., Perkins, C., Lemon, T., Volz, B. and
Droms, R. (ed.), "Dynamic host Configuration Protocol for IPv6
(DHCPv6)", draft-ietf-dhc-dhcpv6-27 (work in progress),
Februray 2002.
[DELEG]
Troan, O., Droms, R., "IPv6 Prefix Options for DHCPv6",
draft-troan-dhcpv6-opt-prefix-delegation-01.txt (work in progress),
February 2002.
10. Authors' Addresses
10. 著者のアドレス
Alain Durand
SUN microsystems, inc.
17 Network Circle, UMPK 17-202
Menlo Park, CA 94025
Email: Alain.Durand@sun.com
Jun-ichiro itojun HAGINO
Research Laboratory, Internet Initiative Japan Inc.
Takebashi Yasuda Bldg.,
3-13 Kanda Nishiki-cho,
Chiyoda-ku, Tokyo 101-0054, JAPAN
Email: itojun@iijlab.net
Dave Thaler
Microsoft
One Microsoft Way
Redmond, CA 98052, USA
Email: dthaler@microsoft.com
11. Full Copyright Statement
11. 著作権表示全文
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（Ｃ）インターネット学会（２００２）。すべての権利は保留される。
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 languages other than English.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
上に与えられた限定された許可は永久で、インターネット学会やその後継者
や譲渡者によって無効にされません。
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.
この文書とここに含む情報は無保証で供給され、そしてインターネット学会
とインターネット技術標準化タスクフォースは、特別にも暗黙にも、この情
報の利用が権利を侵害しないことや商業利用や特別の目的への利用に適当で
ある事の保障を含め、すべての保証を拒否します。