IPv6ユニキャストアドレス割り当て体系(プライベートアドレス)

広告

広告

原文

最終更新
2006-10-19T00:00:00+09:00
この記事のURI参照
https://www.7key.jp/rfc/1887/rfc1887_48.html#source

IPv6ユニキャストアドレスの割り当て体系(和訳)

最終更新
2006-10-30T00:00:00+09:00
この記事のURI参照
https://www.7key.jp/rfc/1887/rfc1887_48.html#translation

4.8 プライベートアドレス

   Many domains will have hosts which, for one reason or another, will
   not require globally unique IPv6 addresses.  A domain which decides
   to use IPv6 addresses out of the private address space is able to do
   so without address allocation from any authority.  Conversely, the
   private address prefix need not be advertised throughout the public
   portion of the Internet.

多くのドメインは、ある理由から、グローバルに一意なIPv6アドレスを要求しないホストを有するだろう。ドメインがプライベートアドレス空間からIPv6アドレスを用いることを決定する場合、オーソリティからアドレスを割り当てをなされる必要はない。また、プライベートアドレスプレフィックスをインターネットの公の部分全体にアドバタイズする必要はない。

   In order to use private address space, a domain needs to determine
   which hosts do not need to have network layer connectivity outside
   the domain in the foreseeable future.  Such hosts will be called
   private hosts, and may use the private addresses described above if
   it is topologically convenient.  Private hosts can communicate with
   all other hosts inside the domain, both public and private.  However,
   they cannot have IPv6 connectivity to any external host.  While not
   having external network layer connectivity, a private host can still
   have access to external services via application layer relays.
   Public hosts do not have connectivity to private hosts outside of
   their own domain.

プライベートアドレス空間を用いるために、ドメインは近い将来ドメイン外部のネットワーク層への接続を必要としないホストを決定する必要がある。そのようなホストは、プライベートホストと呼ばれ、トポロジ的に都合がよい場合に既述のプライベートアドレスを用いてもよい。プライベートホストは、パブリック及びプライベートなドメイン内部の他の全てのホストと通信を行うことができる。しかし、それらは外部のホストとIPv6接続を行うことはできない。外部のネットワーク層接続をとらないため、プライベートホストは今まで通りアプリケーション層を中継することによって外部サービスにアクセスすることができる。パブリックホストは、自ドメイン外部のプライベートホストへ接続をすることはできない。

   Because private addresses have no global meaning, reachability
   information associated with the private address space shall not be
   propagated on inter-domain links, and packets with private source or
   destination addresses should not be forwarded across such links.
   Routers in domains not using private address space, especially those
   of Internet service providers, are expected to be configured to
   reject (filter out) routing information that carries reachability
   information associated with private addresses.  If such a router
   receives such information the rejection shall not be treated as a
   routing protocol error.

プライベートアドレスがグローバルな意味を持たないため、プライベートアドレス空間に関連した到達性情報はドメイン間リンクで広められるべきではなく、プライベートアドレスを発信元又は宛先に持つパケットはドメイン間リンクで伝送されるべきではない。プライベートアドレス空間を用いないドメインのルータ、特にインターネットサービスプロバイダのものには、プライベートアドレスに関した到達性情報を伝送するルーティング情報を拒絶(フィル―タアウト)する設定がなされることが期待される。そのようなルータがそのような情報を得る場合、拒絶はルーティングプロトコルエラーとして扱われないものとすべきである。

   In addition, indirect references to private addresses should be
   contained within the enterprise that uses these addresses. Prominent
   example of such references are DNS Resource Records.  A possible
   approach to avoid leaking of DNS RRs is to run two nameservers, one
   external server authoritative for all globally unique IP addresses of
   the enterprise and one internal nameserver authoritative for all IP
   addresses of the enterprise, both public and private.  In order to
   ensure consistency both these servers should be configured from the
   same data of which the external nameserver only receives a filtered
   version.  The resolvers on all internal hosts, both public and
   private, query only the internal nameserver.  The external server
   resolves queries from resolvers outside the enterprise and is linked
   into the global DNS.  The internal server forwards all queries for
   information outside the enterprise to the external nameserver, so all
   internal hosts can access the global DNS.  This ensures that
   information about private hosts does not reach resolvers and
   nameservers outside the enterprise.

加えて、プライベートアドレスの間接的な参照は、これらのアドレスを用いる企業内にふくまれるべきである。そのような参照の顕著な例はDNSリソースレコードである。DNS RRの漏洩を回避する方法は、企業の全てのグローバルで一意なIPアドレスのための権威ある外部サーバと、企業の全てのパブリック及びプライベートなIPアドレスのための権威ある内部サーバの2つのネームサーバを運用することである。一貫性を保証するために、これらの両サーバは外部ネームサーバがフィルタをかけたもののみを受け取るのと同じデータから設定されるべきである。パブリック及びプライベートな全ての内部ホストのリゾルバは、内部ネームサーバのみにクエリを送信する。外部サーバのリゾルバは、企業外部リゾルバからのクエリを解決し、グローバルなDNSにリンクされる。内部サーバは外部ネームサーバへ企業外部の全てのクエリ情報伝送するため、全ての内部ホストはグローバルなDNSにアクセスすることができる。これは、プライベートホストについての情報が企業外部のリゾルバとネームサーバに達しないことを保証するものである。

広告

Copyright (C) 2006 七鍵 key@do.ai 初版:2006年10月19日 最終更新:2006年10月30日