RFC4477 日本語訳

Network Working Group                                           T. Chown
Request for Comments: 4477                     University of Southampton
Category: Informational                                        S. Venaas
                                                                 UNINETT
                                                               C. Strauf
                                      Clausthal University of Technology
                                                                May 2006

Chownがコメントのために要求するワーキンググループT.をネットワークでつないでください: 4477年のサウサンプトン大学カテゴリ: 技術2006年5月の情報のS.Venaas UNINETT C.Strauf Clausthal大学

              Dynamic Host Configuration Protocol (DHCP):
                    IPv4 and IPv6 Dual-Stack Issues

Dynamic Host Configuration Protocol(DHCP): IPv4とIPv6デュアルスタック問題

Status of This Memo

このメモの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

Abstract

要約

   A node may have support for communications using IPv4 and/or IPv6
   protocols.  Such a node may wish to obtain IPv4 and/or IPv6
   configuration settings via the Dynamic Host Configuration Protocol
   (DHCP).  The original version of DHCP (RFC 2131) designed for IPv4
   has now been complemented by a new DHCPv6 (RFC 3315) for IPv6.  This
   document describes issues identified with dual IP version DHCP
   interactions, the most important aspect of which is how to handle
   potential problems in clients processing configuration information
   received from both DHCPv4 and DHCPv6 servers.  The document makes a
   recommendation on the general strategy on how best to handle such
   issues and identifies future work to be undertaken.

ノードには、コミュニケーションのサポートが、IPv4、そして/または、IPv6プロトコルを使用することであるかもしれません。 Dynamic Host Configuration Protocol(DHCP)でそのようなノードはIPv4、そして/または、IPv6構成設定を得たがっているかもしれません。 IPv4のために設計されているDHCP(RFC2131)のオリジナルバージョンは現在、IPv6のために新しいDHCPv6(RFC3315)によって補足となられました。 このドキュメントは二元的なIPバージョンDHCP相互作用(それの重要な一面が処理設定情報がDHCPv4とDHCPv6サーバの両方から受けたクライアントでどのように潜在的な問題を扱うかということである大部分)と同一視された問題について説明します。 ドキュメントは、どのようにそのような問題を最もよく扱うかに関する一般的な戦略で勧告して、引き受けられるために今後の活動を特定します。

Chown, et al.                Informational                      [Page 1]

RFC 4477                DHCP: Dual-Stack Issues                 May 2006

Chown、他 情報[1ページ]のRFC4477DHCP: デュアルスタックは2006年5月を発行します。

Table of Contents

目次

   1. Introduction ....................................................3
   2. Configuration Scenarios .........................................3
   3. Dual-Stack Issues ...............................................4
      3.1. Handling Multiple Responses ................................4
      3.2. Different Administrative Management ........................5
      3.3. Multiple Interfaces ........................................5
      3.4. DNS Load Balancing .........................................5
      3.5. DNS Search Path Issues .....................................5
      3.6. Protocol Startup Sequence ..................................6
      3.7. DHCP Option Variations .....................................6
      3.8. Security Issues ............................................6
   4. Potential Solutions .............................................7
      4.1. Separate DHCP Servers ......................................7
      4.2. Single DHCPv6 Server .......................................8
      4.3. Optimising for Failure with Lists of Addresses .............9
      4.4. Administrative and Other Areas ............................10
   5. Summary ........................................................10
   6. Security Considerations ........................................12
   7. Acknowledgements ...............................................12
   8. Informative References .........................................12

1. 序論…3 2. 構成シナリオ…3 3. デュアルスタック問題…4 3.1. 複数の応答を扱います…4 3.2. 異なった行政運営…5 3.3. 倍数は連結します…5 3.4. DNSロードバランシング…5 3.5. DNSは経路問題を捜します…5 3.6. 始動系列について議定書の中で述べてください…6 3.7. DHCPオプション変化…6 3.8. セキュリティ問題…6 4. 潜在的ソリューション…7 4.1. DHCPサーバを切り離してください…7 4.2. DHCPv6サーバを選抜してください…8 4.3. 失敗によって、アドレスのリストで最適化します。9 4.4. 管理の、そして、他の領域…10 5. 概要…10 6. セキュリティ問題…12 7. 承認…12 8. 有益な参照…12

Chown, et al.                Informational                      [Page 2]

RFC 4477                DHCP: Dual-Stack Issues                 May 2006

Chown、他 情報[2ページ]のRFC4477DHCP: デュアルスタックは2006年5月を発行します。

1.  Introduction

1. 序論

   The original specification of the Dynamic Host Configuration Protocol
   (DHCP) was made with only IPv4 in mind.  That specification has been
   subsequently revised, up to the latest version of DHCP [1].  With the
   arrival of IPv6, a new DHCP specification for IPv6 has been designed
   and published as DHCPv6 [4].

Dynamic Host Configuration Protocol(DHCP)に関する正式仕様書はIPv4だけと共に念頭で作られました。 その仕様は次に、DHCP[1]の最新版まで改訂されました。 IPv6の到着で、IPv6のための新しいDHCP仕様は、DHCPv6[4]として設計されていて、発表されました。

   These protocols allow nodes to communicate via IPv4 or IPv6
   (respectively) to retrieve configuration settings for operation in a
   managed environment.  While an IPv6 node may acquire address-related
   configuration settings via IPv6 stateless address autoconfiguration
   [2], such a node may wish to use stateless DHCPv6 [5] for other
   administratively configured options, such as DNS or NTP.

これらのプロトコルで、ノードは、管理された環境における操作のために構成設定を検索するためにIPv4かIPv6(それぞれ)を通って交信できます。 IPv6ノードがIPv6の状態がないアドレス自動構成[2]でアドレス関連の構成設定を取得しているかもしれない間、そのようなノードは他の行政上構成されたオプションに状態がないDHCPv6[5]を使用したがっているかもしれません、DNSやNTPのように。

   In early IPv6 deployments, a dual-stack mode of operation is
   typically used.  There will thus be nodes that require both IPv4 and
   IPv6 configuration settings.  This document discusses issues with
   obtaining such settings in a dual-stack environment.

早めのIPv6展開では、デュアルスタック運転モードは通常使用されます。 その結果、IPv4とIPv6構成設定の両方を必要とするノードがあるでしょう。 このドキュメントはデュアルスタック環境でそのような設定を得る問題について議論します。

   There is a general multihoming issue to be solved for DHCP.  A host
   might simultaneously be connected to multiple networks managed by
   multiple parties.  Also, IPv4 and IPv6 might be managed by separate
   parties.  While these issues are touched on in this document, here we
   focus on the specific issues for operating DHCP in a mixed (typically
   dual-stack) IPv4 and IPv6 environment within a single administrative
   domain.

DHCPのために解決されるために、一般的なマルチホーミング問題があります。 ホストは同時に、複数のパーティーによって経営された複数のネットワークに接続されるかもしれません。 また、IPv4とIPv6は別々のパーティーによって管理されるかもしれません。 これらの問題が本書では触れられている間、ここで、私たちは操作DHCPのためにただ一つの管理ドメインの中の混ぜられた(通常デュアルスタック)IPv4とIPv6環境で特定の問題に焦点を合わせます。

   In this document, we refer to a "DHCP server" as a server
   implementing the original DHCP [1], and a "DHCPv6 server" as a server
   implementing DHCPv6 [4] or its stateless subset [5].

本書では、私たちは、オリジナルのDHCPが[1]であると実装するサーバに「DHCPサーバ」について言及して、DHCPv6が[4]であると実装するサーバかその状態がない部分集合[5]として「DHCPv6サーバ」について言及します。

2.  Configuration Scenarios

2. 構成シナリオ

   For a node in an IPv4-only or IPv6-only environment, the choice of
   DHCP server is a straightforward one; a DHCP server for IPv4, or a
   DHCPv6 server for IPv6.

IPv4だけかIPv6だけ環境におけるノードに関しては、DHCPサーバの選択は簡単なものです。 IPv4のためのDHCPサーバ、またはIPv6のためのDHCPv6サーバ。

   In a dual-stack environment a node in a managed environment will need
   to obtain both IPv4 and IPv6 configuration settings, such as the
   following:

デュアルスタック環境で、管理された環境におけるノードは、IPv4とIPv6構成設定の両方を得る必要があるでしょう、以下などのように:

   o  IPv4 address

o IPv4アドレス

   o  IPv6 address

o IPv6アドレス

   o  NTP server

o NTPサーバ

Chown, et al.                Informational                      [Page 3]

RFC 4477                DHCP: Dual-Stack Issues                 May 2006

Chown、他 情報[3ページ]のRFC4477DHCP: デュアルスタックは2006年5月を発行します。

   o  DNS server

o DNSサーバ

   o  NIS server

o NISサーバ

   o  DNS search path

o DNS検索経路

   While the format of address settings will be IP specific, the node
   may equally well acquire IPv4 or IPv6 addresses for some settings,
   such as for DNS or NTP, if those services are available via IPv4 or
   IPv6 transport.  Currently, a DHCP server returns IPv4 data, while a
   DHCPv6 server returns IPv6 data.

アドレス設定の形式がIP特有になる間、ノードは等しくいくつかの設定へのIPv4かIPv6アドレスをよく獲得するかもしれません、DNSやNTPなどのように、それらのサービスがIPv4かIPv6輸送で利用可能であるなら。 現在、DHCPサーバはデータをIPv4に返しますが、DHCPv6サーバはデータをIPv6に返します。

   It is worth noting that in an IPv4 environment, with a DHCP server,
   the choice of whether to use DHCP is made by the node.  In an IPv6
   environment, the use of the managed and other bits in the Router
   Advertisement can offer a hint to the node whether or not to use full
   DHCPv6 or its stateless variant.  It is perhaps not clear whether a
   dual-stack node should do DHCP for IPv4 if Managed and OtherConfig
   flags in the Router Advertisement are both off; it seems most
   appropriate that the decision to use DHCP for IPv4 or not should be
   as if the host were IPv4-only.

ノードでDHCPサーバがあるIPv4環境で、選択をDHCPを使用するかどうかすることに注意する価値があります。 IPv6環境で、Router Advertisementにおける管理されて他のビットの使用はノードへの完全なDHCPv6を使用するか、そして、その状態がない異形をヒントに提供できます。 Router AdvertisementのManagedとOtherConfig旗がともにオフであるならデュアルスタックノードがIPv4のためにDHCPをするはずであるかどうかは、恐らく明確ではありません。 IPv4にDHCPを使用するという決定がまるでホストがIPv4専用であるかのようにそうであるべきであることは最も適切に見えます。

3.  Dual-Stack Issues

3. デュアルスタック問題

   In this section, we list issues that have been raised to date,
   related to dual-stack DHCP operation.

このセクションで、私たちはデュアルスタックDHCP操作に関連する日付まで提起された問題を記載します。

   It has been noted from comments that the first four, and possibly
   five, subsections here may also be viewed as multihoming issues.

コメントから、また、最初の4、およびことによると5、ここの小区分がマルチホーミング問題として見なされるかもしれないことに注意されました。

3.1.  Handling Multiple Responses

3.1. 複数の応答を扱います。

   The general question is how to handle configuration information that
   may be gathered from multiple sources.  Where those sources are DHCP
   and DHCPv6 servers (which may be two physical nodes or two servers
   running on the same node) the client node needs to know whether to
   use the most recent data, or whether to perform some merger or union
   of the responses by certain rules.  A method for merging lists of
   addresses, for options that carry such information, may also be
   required.  A node may choose to ask a DHCPv6 server and only use a
   DHCP server if no response is received.

一般疑問はどう複数のソースから集められるかもしれない設定情報を扱うかということです。 それらのソースがDHCPとDHCPv6サーバ(同じノードで動く2つの物理的なノードか2つのサーバであるかもしれない)であるところでは、クライアントノードは、最新のデータを使用するかどうか、またはいくらかの合併か組合を実行するかどうかをある規則で応答を知る必要があります。 また、アドレスのリストを合併するそのような情報を運ぶオプションのためのメソッドが必要であるかもしれません。 どんな応答も受け取られていないなら、ノードは、DHCPv6サーバを尋ねて、DHCPサーバを使用するだけであるのを選ぶかもしれません。

   Merging is possible, but is likely to be complex.  There could be
   some priority, so that if both DHCP and DHCPv6 servers offer a value,
   only one is used.  Or the node could choose to store and use both, in
   some order of its choosing.  Merging issues are further discussed
   later in this document.

合併は、可能ですが、複雑である傾向があります。 何らかの優先権があるかもしれないので、DHCPとDHCPv6サーバの両方が値を提供するなら、1つだけが使用されています。 または、ノードは、選ぶ何らかの注文で両方を保存して、使用するのを選ぶかもしれません。 後でさらに本書では合併している問題について議論します。

Chown, et al.                Informational                      [Page 4]

RFC 4477                DHCP: Dual-Stack Issues                 May 2006

Chown、他 情報[4ページ]のRFC4477DHCP: デュアルスタックは2006年5月を発行します。

   A node may also obtain information from other sources, such as a
   manual configuration file (for example, /etc/resolv.conf for DNS data
   on many UNIX systems).  A node configured manually to use an IPv6 DNS
   server may lose that configuration if it is in a dual-stack
   environment and uses DHCP to obtain IPv4 settings; the new IPv4
   settings from the DHCP response may then overwrite the manual IPv6
   DNS setting.

また、ノードは他のソースから情報を得るかもしれません、手動の構成ファイル(例えば、多くのUNIXシステムに関するDNSデータのための/etc/resolv.conf)のように。 デュアルスタック環境にはあって、IPv4設定を得るのにDHCPを使用するなら、IPv6 DNSサーバを使用するために手動で構成されたノードはその構成を失うかもしれません。 そして、DHCP応答からの新しいIPv4設定は手動のIPv6 DNS設定を上書きするかもしれません。

3.2.  Different Administrative Management

3.2. 異なった行政運営

   In some deployments, the IPv4 and IPv6 services may not be
   administered by the same organisation or people, such as in a
   community wireless environment.  This poses problems for consistency
   of data offered by either DHCP version.

いくつかの展開では、IPv4とIPv6サービスは同じ機構か人々によって管理されないかもしれません、共同体ワイヤレス環境などのように。 これはどちらのDHCPバージョンによっても提供されたデータの一貫性のために問題を引き起こします。

   There may also be different connectivity for the protocols, and the
   client may gain advantage from knowing which 'administrative domain'
   is supplying which information.  A client may need to use different
   received information depending on which connectivity is being used.
   In the example of the community wireless environment, the question of
   which connectivity is 'better' is a separate issue.

また、プロトコルのための異なった接続性があるかもしれません、そして、どの'管理ドメイン'がどの情報を提供しているかを知るのからクライアントは利点を獲得するかもしれません。 クライアントは、どの接続性が使用されているかによる異なった受信された情報を使用する必要があるかもしれません。 共同体ワイヤレス環境に関する例では、どの接続性が'より良いか'に関する質問は別個問題です。

3.3.  Multiple Interfaces

3.3. 複数のインタフェース

   A node may have multiple interfaces and run IPv4 and IPv6 on
   different interfaces.  A question then is whether the settings are
   per interface or per node.

ノードは、異なったインタフェースに複数のインタフェースを持って、IPv4とIPv6を実行するかもしれません。 その時、設定がインタフェースかノード単位であるという質問があります。

   Per-interface settings can be complex because a client node needs to
   know which interface system settings, like NTP server, came from.
   And it may not be apparent which setting should be used if, for
   example, an NTP server option is received on multiple interfaces,
   potentially over different protocols.

クライアントノードが、インタフェース・システム設定がNTPサーバのようにどれから来たかを知る必要があるので、1インタフェースあたりの設定は複雑である場合があります。 そして、例えば、複数のインタフェースに潜在的にNTPサーバオプションを異なったプロトコルの上に受け取るならどの設定を使用するべきであるかは明らかでないかもしれません。

3.4.  DNS Load Balancing

3.4. DNSロードバランシング

   In some cases it is preferable to list DNS server information in an
   ordered way per node for load balancing, giving different responses
   to different clients.  Responses from different DHCP and DHCPv6
   servers may make such configuration problematic, if the knowledge of
   the load balancing is not available to both servers.

いくつかの場合、ロードバランシングのために1ノードあたり1つの規則正しい方法でDNSサーバ情報をリストアップするのは望ましいです、異なったクライアントへの異なった応答を与えて。 異なったDHCPとDHCPv6サーバからの応答でそのような構成は問題が多くなるかもしれません、ロードバランシングに関する知識が両方のサーバに利用可能でないなら。

3.5.  DNS Search Path Issues

3.5. DNS検索経路問題

   The DNS search path may vary for administrative reasons.  For
   example, a site under the domain example.com may choose to place an
   early IPv6 deployment under the subdomain ipv6.example.com, until it
   is confident of offering a full dual-stack service under its main

DNS検索経路は管理理由で異なるかもしれません。 例えば、ドメインexample.comの下のサイトは、早めのIPv6展開をサブドメインipv6.example.comの下に置くのを選ぶかもしれません、それがメインの下で完全なデュアルスタックサービスを提供するのに自信があるまで

Chown, et al.                Informational                      [Page 5]

RFC 4477                DHCP: Dual-Stack Issues                 May 2006

Chown、他 情報[5ページ]のRFC4477DHCP: デュアルスタックは2006年5月を発行します。

   domain.  The subtlety here is that the DNS search path then affects
   the choice of protocol used, such as IPv6 for nodes in
   ipv6.example.com.

ドメイン。 ここの微妙さは次に、DNS検索経路がipv6.example.comのノードのためのIPv6などのように使用されるプロトコルの選択に影響するということです。

3.6.  Protocol Startup Sequence

3.6. プロトコル始動系列

   In the dual-stack environment, one needs to consider what happens if,
   for example, the IPv6 interface (transport) is started after DHCPv4
   was used to configure the client.  Should the client then simply
   discard the current IPv4 information, or merge it with a subsequent
   IPv6 response?  It may also be possible that one protocol is shut
   down or started while the system is running.  There are similarities
   here to issues when DHCP renewals have information that may appear
   that previously was not available (or no longer carry information
   that has been removed).

デュアルスタック環境で、人は、DHCPv4がクライアントを構成するのに使用された後に例えば、IPv6インタフェース(輸送)が始められるなら何が起こるかを考える必要があります。 クライアントは、次に、単に現在のIPv4情報を捨てるべきですか、またはその後のIPv6応答にそれを合併するべきですか? また、システムが動く間、1つのプロトコルが止められるか、または始められるのも、可能であるかもしれません。 DHCP更新にそれが現れるかもしれないという以前に利用可能でなかった情報があるとき(もう取り除かれた情報を運ばないでください)、問題には類似性がここにあります。

3.7.  DHCP Option Variations

3.7. DHCPオプション変化

   Some options in DHCP are not available in DHCPv6 and vice versa.
   Some IP-version limitations naturally apply; for example, only IPv6
   addresses can be in an IPv6 NTP option.  The DHCP and DHCPv6 option
   numbers may be different.

DHCPのいくつかのオプションはDHCPv6で逆もまた同様に利用可能ではありません。 いくつかのIP-バージョン制限が自然に適用されます。 例えば、IPv6アドレスしかIPv6 NTPオプションであることができません。 DHCPとDHCPv6オプション番号は異なっているかもしれません。

   Some sites may choose to use IPv4-mapped addresses in DHCPv6-based
   options.  The merits and drawbacks of such an approach need
   discussion.

いくつかのサイトが、DHCPv6ベースのオプションにIPv4によって写像されたアドレスを使用するのを選ぶかもしれません。 そのようなアプローチの長所と欠点は議論を必要とします。

   A site administrator may wish to configure all their dual-stack nodes
   with (say) two NTP servers, one of which has an IPv4 address, the
   other an IPv6 address.  In this case, it may be desirable for an NTP
   option to carry a list of addresses, where some may be IPv4 and some
   may be IPv6.  In general one could consider having DHCPv6 options
   that can carry a mix of IPv4 and IPv6 addresses.

サイトの管理者は2つの(言います)NTPサーバで彼らのすべてのデュアルスタックノードを構成したがっているかもしれなくて、もう片方がIPv6アドレスです。その1つには、IPv4アドレスがあります。 この場合、NTPオプションが住所録を運ぶのは、望ましいかもしれません。(そこでは、何かがIPv4であるかもしれなく、何かがIPv6であるかもしれません)。 一般に、人は、IPv4のミックスを載せることができるDHCPv6オプションとIPv6アドレスを持っていると考えることができました。

3.8.  Security Issues

3.8. 安全保障問題

   This document does not introduce any new security issues per se.  A
   detailed analysis of DHCP and DHCPv6 security is out of scope for
   this document.

このドキュメントはそういうものとして少しの新しい安全保障問題も紹介しません。 このドキュメントのための範囲の外にDHCPとDHCPv6セキュリティの詳細に渡る分析があります。

   While there is a specification for authentication for DHCP messages
   [3], the standard seems to have very few, if any, implementations.
   Thus DHCP and DHCPv6 servers are still liable to be spoofed.  Adding
   an additional protocol may give an extra avenue for attack, should an
   attacker perhaps spoof a DHCPv6 server but not a DHCP server.

DHCPメッセージ[3]のための認証のための仕様がありますが、規格はほんのわずかを持っているように思えます、もしあれば、実装。 したがって、DHCPとDHCPv6サーバは偽造されるのにおいてまだ責任があります。 追加議定書を加えると、付加的な大通りは攻撃のために与えられるかもしれません、攻撃者が恐らくDHCPサーバではなく、DHCPv6サーバを偽造するなら。

Chown, et al.                Informational                      [Page 6]

RFC 4477                DHCP: Dual-Stack Issues                 May 2006

Chown、他 情報[6ページ]のRFC4477DHCP: デュアルスタックは2006年5月を発行します。

4.  Potential Solutions

4. 潜在的ソリューション

   Here we discuss the two broad solution strategies proposed within the
   IETF dhc WG.  The first is to run separate DHCP and DHCPv6 servers
   (with the client merging information received from both where
   necessary, or perhaps choosing to query a particular version first).
   The second is to run only a DHCPv6 server and relay IPv4
   configuration information within (new) IPv4 configuration options.

ここで、私たちはIETF dhc WGの中で提案された2つの広いソリューション戦略について議論します。 1番目は別々のDHCPとDHCPv6サーバ(クライアントが、必要であるところで両方から受け取られた情報を合併するか、または最初に特定のバージョンについて質問するのを恐らく選んでいる)を実行することです。 2番目は(新しい)のIPv4設定オプションの中でDHCPv6サーバとリレーIPv4設定情報だけを実行することです。

4.1.  Separate DHCP Servers

4.1. 別々のDHCPサーバ

   One solution is to run separate DHCP and DHCPv6 servers.  These may
   or may not be run on the same physical node.  The information served
   from the DHCP servers could be generated from a single database
   instance for consistency.  One might have a single server instance
   supporting both DHCPv4 and DHCPv6 protocols.

1つのソリューションは別々のDHCPとDHCPv6サーバを実行することです。 これらは同じ物理的なノードで実行されるかもしれません。 一貫性のためにただ一つのデータベースインスタンスからDHCPサーバから役立たれる情報は生成することができました。 1つには、DHCPv4とDHCPv6の両方にプロトコルをサポートするただ一つのサーバインスタンスがあるかもしれません。

   In this approach, some best practice guidance is required for how
   multiple responses are handled or merged.  Administrators have the
   onus to maintain consistency (for example, scripts may generate
   common DHCP and DHCPv6 configuration files).

このアプローチでは、何らかの最も良い習慣指導が、複数の応答が扱われるか、またはどう合併されているかに必要です。 管理者には、一貫性を維持する重荷があります(例えば、スクリプトは、一般的なDHCPとDHCPv6が構成ファイルであると生成するかもしれません)。

   In some cases, inconsistencies may not matter.  In a simple case, an
   NTP server will give the same time whether accessed by IPv4 or IPv6.
   Even if different recursive DNS servers are offered via DHCP or
   DHCPv6, then those name servers should provide the same response to a
   given query.  In cases where sites may be operating a 'two-faced
   DNS', this will still hold true if the node is on the same
   topological point on the network from an IPv4 or IPv6 perspective.
   The order of DNS servers in a node's configuration is not important,
   unless DNS load balancing is required.

いくつかの場合、矛盾は重要でないかもしれません。 簡単な場合では、IPv4かIPv6によってアクセスされるか否かに関係なく、NTPサーバは同時間を与えるでしょう。 DHCPかDHCPv6を通して異なった再帰的なDNSサーバを提供しても、それらのネームサーバは与えられた質問への同じ応答を提供するべきです。 サイトが'偽善的なDNS'を操作しているかもしれない場合では、それでも、ノードがネットワークの同じ位相的なポイントの上でIPv4かIPv6見解から来ていると、これは有効でしょう。 DNSロードバランシングは必要でない場合、ノードの構成における、DNSサーバの注文が重要ではありません。

   In other cases, inconsistencies may be an issue; for example, where
   lists of values are returned, an algorithm is needed for list merger
   (e.g., "alternate, DHCPv6 first").  Or there may be incompatible
   configuration values where, for example, DHCPv6 supplies domain names
   (such the SMTP or POP servers) whereas DHCPv4 provides only IPv4
   addresses.

他の場合では、矛盾は問題であるかもしれません。 例えば、値のリストを返すところでは、アルゴリズムは必要な繰返し要素の並び合併(例えば、「DHCPv6代替の1番目」)です。 または、例えばDHCPv6がドメイン名を供給する両立しない構成値(そのようなSMTPかPOPサーバ)があるかもしれませんが、DHCPv4はIPv4アドレスだけを提供します。

   In the case of separate servers, there are some options, like DNS
   search path, that aren't used in a specific IP protocol context.

別々のサーバの場合には、DNS検索経路のような特定のIPプロトコル文脈で使用されないいくつかのオプションがあります。

   The multiple server approach will have some simplifications.  The
   DHCPv4 and DHCPv6 servers may provide the same value for a particular
   parameter, in which case there is no conflict.  In some cases, the
   value may be different, but the effect should be the same (such as an

複数のサーバアプローチには、いくつかの簡素化があるでしょう。 DHCPv4とDHCPv6サーバは同じ値を特定のパラメタに提供するかもしれません、闘争が全くどのケースにないかで。 いくつかの場合、値が異なるかもしれませんが、効果が同じであるべきである、(

Chown, et al.                Informational                      [Page 7]

RFC 4477                DHCP: Dual-Stack Issues                 May 2006

Chown、他 情報[7ページ]のRFC4477DHCP: デュアルスタックは2006年5月を発行します。

   NTP server).  The crux of the issue is to identify where differences
   may occur and where these differences will have an impact on node
   behaviour.

NTPサーバ) 問題の要所は違いがどこに起こるかもしれないか、そして、これらの違いがノードのふるまいにどこに影響を与えるかを特定することです。

   One possible solution is to have per-host preferences, or an ordered
   list of preferences, for example, "use manually configured", "prefer
   DHCPv4", or "prefer DHCPv6", assuming the host can act based upon
   which protocol is used.  It is then up to the site administrator to
   ensure that values returned from either DHCP are consistent (a
   principle that extends if other methods are used, such as NIS or
   Service Location Protocol (SLP)).

1つの可能なソリューションは1ホストあたりの好み、または好みの規則正しいリストを持つことです、例えば、「使用は手動で構成した」、「DHCPv4"、または「DHCPv6"を好んでください、ホストがどのプロトコルが使用されているかに基づくのに行動できると仮定して」好んでください。 そして、確実にするサイトの管理者まで、DHCPから返された値は一貫しています(他のメソッドがNISやService Locationプロトコル(SLP)のように使用されるなら敷衍される原則)。

4.2.  Single DHCPv6 Server

4.2. ただ一つのDHCPv6サーバ

   There is an argument for not having to configure and operate both
   DHCP and DHCPv6 servers in a dual-stack site environment.  The use of
   both servers may also lead to some redundancy in the information
   served.  Thus, one solution may be to modify DHCPv6 to be able to
   return IPv4 information.  This solution is hinted at in the DHCPv6
   [4] specification: "If there is sufficient interest and demand,
   integration can be specified in a document that extends DHCPv6 to
   carry IPv4 addresses and configuration information."  This solution
   may allow DHCP for IPv4 to be completely replaced by DHCPv6 with
   additional IPv4 information options, for dual-stack nodes.

デュアルスタックサイト環境にはDHCPとDHCPv6サーバの両方を構成して、操作する必要はないためには議論があります。 また、両方のサーバの使用は役立たれる情報の何らかの冗長につながるかもしれません。 したがって、1つのソリューションは情報をIPv4に返すことができるようにDHCPv6を変更することであるかもしれません。 このソリューションはDHCPv6[4]仕様でほのめかされます: 「十分な関心と要求があれば、IPv4アドレスと設定情報を運ぶためにDHCPv6を広げるドキュメントで統合を指定できます。」 このソリューションは追加IPv4情報オプションでIPv4をDHCPv6に完全に取り替えるためにDHCPを許容するかもしれません、デュアルスタックノードのために。

   A general argument is that which DHCP protocol is used (whether it's
   over IPv4 or IPv6) shouldn't affect what kind of addresses you can
   get configured with it, and that simplicity and predictability come
   from using a single server over a single transport.  IPv4-capable
   hosts will likely remain for at least 10 years, probably much longer;
   do we want dual-stack hosts (which will become the norm) to do both
   DHCPv4 and DHCPv6 forever while dual-stack?  If you need both servers
   to configure interfaces with addresses, and get other configurations,
   then you rely on two separate protocols to work (servers and relays,
   etc.) in order for the host to behave correctly.

一般的な議論はどのDHCPプロトコルが使用されているかが(IPv4かIPv6の上にそれがあるか否かに関係なく)あなたが得ることができるどういうアドレスが、それ、およびそれで簡単さと予見性がただ一つの輸送の上でただ一つのサーバを使用するのから来るのを構成したかに影響するべきでないということです。 IPv4有能なホストははるかに長いときにたぶん少なくとも10年間おそらく残るでしょう。 私たちは、デュアルスタックである間、デュアルスタックホスト(標準になるでしょう)にいつまでもDHCPv4とDHCPv6の両方をして欲しいですか? アドレスとのインタフェースを構成して、他の構成を得るために両方のサーバを必要とするなら、あなたは、ホストが正しく振る舞うように働く(サーバとリレーなど)ために2つの別々のプロトコルを当てにします。

   This approach may require the listing of a mix of IPv4 and IPv6
   addresses for an option.  This could then be considered when new IPv6
   options are introduced.  There could be just two options needed, one
   new option for the address delegation, and one for doing
   encapsulation.

このアプローチはオプションのためのIPv4とIPv6アドレスのミックスのリストを必要とするかもしれません。 そして、新しいIPv6オプションが紹介されると、これは考えられるかもしれません。 必要である、ちょうど2つのオプション、アドレス委譲のための1つの新しいオプション、およびカプセル化をするための1つがあるかもしれません。

   Also, there are a number of paradigms in DHCPv6 that we miss in
   DHCPv4.  An example is movement away from using MAC addresses for
   per-host address assignment and instead using DHCP Unique Identifier
   (DUIDs) or Identity Association Identifiers (IAIDs).  As stated in
   Section 9 of RFC3315, DHCPv6 servers use DUIDs to identify clients
   for the selection of configuration parameters and in the association

また、多くのパラダイムが私たちがDHCPv4でいなくて寂しいDHCPv6にあります。 例は1ホスト・アドレスあたりの課題にMACアドレスを使用して、代わりに、DHCP Unique Identifier(DUIDs)かIdentity Association Identifiers(IAIDs)を使用するのから遠くの動きです。 RFC3315のセクション9に述べられているように、DHCPv6サーバは設定パラメータの品揃えと協会でクライアントを特定するのにDUIDsを使用します。

Chown, et al.                Informational                      [Page 8]

RFC 4477                DHCP: Dual-Stack Issues                 May 2006

Chown、他 情報[8ページ]のRFC4477DHCP: デュアルスタックは2006年5月を発行します。

   of IAs with clients.  DHCPv6 clients use DUIDs to identify a server
   in messages where a server needs to be identified.  However, in this
   particular example, the new DHCPv6 functionality has recently been
   retrofitted to IPv4 via a specification for DUIDs for DHCPv4 [6].

クライアントがいるIAsについて。 DHCPv6クライアントは、サーバが特定される必要があるメッセージのサーバを特定するのにDUIDsを使用します。 しかしながら、この特定の例では、最近、DHCPv4[6]のためにDUIDsのための仕様で新しいDHCPv6の機能性をIPv4に改装してあります。

   However, there are a number of potential problems with this approach:

しかしながら、このアプローチには多くの潜在的な問題があります:

   o  IPv4-only nodes would not have any DHCP service available to them;
      such an approach is only possible in a fully dual-stack
      environment.

o IPv4だけノードには、それらに、利用可能な少しのDHCPサービスもないでしょう。 そのようなアプローチは単にaで完全に可能です。デュアルスタック環境。

   o  The client node may then be IPv6-only and receive IPv4
      configuration settings that it does not want or be able to handle
      meaningfully.

o クライアントノードは、意味深長に、そしてIPv6専用であり、それが欲しくなく、扱うことができないIPv4構成設定を受けるかもしれません。

   o  The DHCPv4 servers need to be configured anyway to support IPv4-
      only hosts, so there is still duplication of information.

o DHCPv4サーバが、IPv4にホストだけをサポートするためにとにかく構成される必要があるので、情報の複製がまだあります。

   o  What happens if there are DHCPv6 servers that don't return IPv4
      information?  Does this mean the client can't run IPv4 (since it
      won't do DHCPv4)?

o 情報をIPv4に返さないDHCPv6サーバがあれば、何が起こりますか? これは、クライアントがIPv4を実行できないことを(DHCPv4をしないので)意味しますか?

   o  If IPv4 information is served from a DHCPv6 server as well as an
      IPv4 DHCP server, IPv4 address space will need to be allocated to
      both servers, fragmenting the potentially precious IPv4 global
      address resource for the site.

o IPv4情報がIPv4 DHCPサーバと同様にDHCPv6サーバから役立たれていると、IPv4アドレス空間は、両方のサーバに割り当てられる必要があるでしょう、サイトのための潜在的に貴重なIPv4グローバルアドレスリソースを断片化して。

4.3.  Optimising for Failure with Lists of Addresses

4.3. アドレスのリストがある失敗のための最適化

   There is a generic issue with any option that includes a list of
   addresses of servers (such as DNS server addresses).  The list is
   offered to cater for resilience, such as whether the listed server
   itself fails or connectivity to the server fails.  If the client does
   not know the cause of failure, its optimal strategy is to try a
   different server, via a different protocol.  The problem today is
   that the IPv4 list is returned via DHCPv4, and the IPv6 list via
   DHCPv6; the client really has no way to "try a different server",
   since that information is lost by the protocol, even though it may be
   known by the server.

サーバ(DNSサーバアドレスなどの)に関する住所録を含んでいるどんなオプションにはジェネリック問題もあります。 弾力を満たすためにリストを提供します、記載されたサーバ自体が失敗するか、またはサーバへの接続性が失敗するのなどように。 クライアントが失敗の原因を知らないなら、最適戦略は異なったサーバを試みることです、異なったプロトコルで。 今日の問題はDHCPv6を通してDHCPv4、およびIPv6リストでIPv4リストを返すということです。 クライアントには、「異なったサーバを試みる」方法が全く本当にありません、その情報がプロトコルによって失われているので、それはサーバによって知られているかもしれませんが。

   Just putting merging heuristics in the client cannot provide the best
   behaviour, since information is lost.  By comparison, if IPv4-mapped
   addresses were included in the DHCPv6 option along with IPv6
   addresses, the DHCP server can give an intelligent order that takes
   into account which addresses are of the same DNS/whatever server.
   IPv6-only clients have to know to discard the IPv4-mapped addresses
   in this solution, and it's much easier to solve this in the combined-
   DHCP-server case than in the two-server case.

情報が無くなるので、発見的教授法を合併するのをクライアントにただ入れるのが最も良いふるまいを提供できません。 IPv4によって写像されたアドレスがIPv6アドレスに伴うDHCPv6オプションに含まれていたなら、比較で、DHCPサーバがサーバIPv6だけクライアントが、このソリューションにおけるIPv4によって写像されたアドレスを捨てるのを何を知らなければならなくてもそれのアドレスが同じDNS/のものであるアカウントを連れていく知的なオーダーを与えることができて、結合したDHCP-サーバ場合でこれを解決するのは2サーバのケースよりはるかに簡単です。

Chown, et al.                Informational                      [Page 9]

RFC 4477                DHCP: Dual-Stack Issues                 May 2006

Chown、他 情報[9ページ]のRFC4477DHCP: デュアルスタックは2006年5月を発行します。

   One can argue that this is only an optimisation, and in many cases
   the list has only two elements, so the "next" choice is forced.
   However, this particular issue highlights the subtleties of merging
   responses from separate servers.

1つが、これが最適化にすぎないと主張できて、多くの場合、リストには2つの要素しかないので、「次」の選択は無理矢理であっています。 しかしながら、この特定の問題は別々のサーバから合併している応答の微妙さを強調します。

4.4.  Administrative and Other Areas

4.4. 管理の、そして、他の領域

   There are also administrative issues or best practice that could be
   promoted.  For example, it may be recommended that sites do not split
   their DNS name space for IPv6-specific testbeds.

また、管理問題か促進できた中で最も良い習慣があります。 例えば、サイトがそれらのDNS名前スペースをIPv6特有のテストベッドに分けないのは、お勧めであるかもしれません。

   It may be worth considering whether separate manual configuration
   files should be kept for IPv4 and IPv6 settings, such as separate
   /etc/resolv.conf files for DNS settings on UNIX systems.  However,
   this seems a complex solution.  The problem should be better solved
   by other, more generalised methods.

別々の手動の構成ファイルがIPv4とIPv6設定に保たれるべきであるかどうか考える価値があるかもしれません、UNIXシステムの上のDNS設定のための別々の/etc/resolv.confファイルなどのように。しかしながら、これは複雑なソリューションに見えます。 問題は他の、そして、さらに一般化されたメソッドで解決されるべきであるほうがよいです。

   It may be important at times to be able to distinguish DHCP client
   and server identities.  DHCPv6 introduces the idea of a DHCP Unique
   Identifier (DUID).  The DUID concept has also been retrofitted to
   DHCPv4 [6], and thus it may form the basis of part of the solution
   space for the problem at hand.

DHCPクライアントとサーバのアイデンティティを区別できるのは時には、重要であるかもしれません。 DHCPv6はDHCP Unique Identifier(DUID)の考えを紹介します。 また、DHCPv4[6]にDUID概念を改装してあります、そして、その結果、それは当面の問題のためにソリューションスペースの一部の基礎を形成するかもしれません。

   Some differences in DHCP and DHCPv6 may not be reconciled, but may
   not need to be, such as different ways to assign addresses by DUID in
   DHCPv6, or the lack of a comparable option in both DHCP versions.

DHCPv6のDUID、または両方のDHCPバージョンにおける、匹敵するオプションの不足でアドレスを割り当てる異なった方法などに似る必要はないかもしれない以外に、DHCPとDHCPv6のいくつかの違いは和解しないかもしれません。

5.  Summary

5. 概要

   There are a number of issues in the operation of DHCP and DHCPv6
   servers for nodes in dual-stack environments that should be
   clarified.  While some differences in the protocols may not be
   reconciled, there may not be a need to do so.  However, with DHCPv6
   deployment growing, there is an operational requirement to determine
   best practice for DHCP server provision in dual-stack environments,
   which may or may not imply additional protocol requirements.  The
   principal choice is whether separate DHCP and DHCPv6 services should
   be maintained by a site, or whether DHCPv6 should be extended to
   carry IPv4 configuration settings for dual-stack nodes.

ノードのためのDHCPとDHCPv6サーバの操作には多くの問題がはっきりさせられるべきであるデュアルスタック環境であります。 プロトコルのいくつかの違いが和解していないかもしれない間、そうする必要がないかもしれません。 しかしながら、DHCPv6展開が成長している状態で、デュアルスタック環境へのDHCPサーバ支給のために決定するという中で習慣最も良い操作上の要件があります。環境は追加議定書要件を含意するかもしれません。 主要な選択は別々のDHCPとDHCPv6サービスがサイトによって維持されるべきであるかどうか、またはDHCPv6がデュアルスタックノードのためにIPv4構成設定を運ぶために広げられるべきであるかどうかということです。

   It can certainly be argued that until a site is completely dual-
   stack, an IPv4 DHCP service will always be required (for example,
   while there are still legacy printers, IP webcams, or other devices
   that still configure via DHCPv4), and a single IPv6 transport DHCP
   server offering configuration information for both protocols will
   then not be sufficient.  In that case, IPv4 DHCP is required, and
   thus there

確かに、IPv4 DHCPサービスがサイトが完全に二元的なスタックになるまでいつも必要であると(それがDHCPv4を通してまだ構成しているレガシープリンタ、IPウェブカメラ、または対向機器が例えばまだありますが)主張できて、両方のプロトコルのために設定情報を提供するただ一つのIPv6輸送DHCPサーバはそして十分ではありません。 その場合、IPv4 DHCPがそこでこのようにして必要です。

Chown, et al.                Informational                     [Page 10]

RFC 4477                DHCP: Dual-Stack Issues                 May 2006

Chown、他 情報[10ページ]のRFC4477DHCP: デュアルスタックは2006年5月を発行します。

   is a good rationale for focusing effort on how to combine the
   information received from separate IPv4 DHCP and (stateless) DHCPv6
   servers.

別々のIPv4 DHCPと(状態がない)のDHCPv6サーバから取り組みの焦点を合わせるためのどう情報を結合するかに関する良い原理を受け取りますか?

   In theory, it should be relatively straightforward to write a
   configuration manager that would accept a single configuration
   specification from the service manager and distribute the correct
   (and consistent) configurations to the DHCPv4 and DHCPv6 servers
   (whether on the same host or not).  In this case, maintaining
   coordinated configurations in two servers is an interface issue, not
   a protocol issue.  The question then is whether the client has all
   the information it needs to make reasonable choices.  We are aware of
   one implementation of separate DHCPv4 and DHCPv6 clients that is
   using a preference option for assisting client-side merging of the
   received information.

理論上、サービス・マネージャからただ一つの構成仕様を受け入れて、正しくて(一貫する)の構成をDHCPv4とDHCPv6に分配する構成マネージャにサーバを書くのは比較的簡単であるべきです(同じホストであるか否かに関係なく)。 この場合、2つのサーバでの連携構成を維持するのは、プロトコル問題ではなく、インタフェース問題です。 その時、クライアントにはそれが正当な選択をするように必要とするすべての情報があるかどうかという質問があります。 私たちは受信された情報のクライアントサイド合併を補助するのに好みのオプションを使用している別々のDHCPv4とDHCPv6クライアントの1つの実装を意識しています。

   Another issue for discussion is whether a combined DHCP service only
   available over IPv6 transport is a desirable longer-term goal for
   networks containing only dual-stack or IPv6-only nodes (or IPv4-only
   nodes where DHCPv4 is not needed).  The transition to the long-term
   position may easily take more than 10 years.

議論のための別の問題はIPv6輸送の上で利用可能なだけの結合したDHCPサービスがデュアルスタックかIPv6だけノード(または、DHCPv4は必要でないIPv4だけノード)だけを含むネットワークの望ましいより長い期間目標であるかどうかということです。 長期の位置への変遷は容易に10年以上かかるかもしれません。

   Upon reflection on the above observations, the dhc WG reached a
   strong consensus to adopt the two-server approach (separate DHCP and
   DHCPv6 servers), rather than have a combined single server returning
   IPv4 information over IPv6.  The two servers may be co-located on a
   single node and may have consistent configuration information
   generated from a single asset database.

上の観測に関する反省のときに、dhc WGは、IPv6の上で情報をIPv4に返しながら、結合したただ一つのサーバを持っているよりむしろ2サーバのアプローチ(別々のDHCPとDHCPv6サーバ)を取る強いコンセンサスに達しました。 2つのサーバで、ただ一つのノードの上に共同位置していて、一貫した設定情報は単一資産データベースから発生するかもしれません。

   It should be noted that deployment experience of DHCPv6 is still in
   its infancy; thus, a full understanding of the issues may only
   develop over time, but we feel we have reached the best consensus
   given the current status.  Future work is now required to determine
   best practice for merging information from multiple servers,
   including merger of lists of addresses where options carry such
   information.

DHCPv6の展開経験がまだ揺かご期にあることに注意されるべきです。 したがって、問題の十分な理解は時間がたつにつれて、展開するだけであるかもしれませんが、私たちは、現在の状態を考えて、最も良いコンセンサスに達したと感じます。 今後の活動が現在複数のサーバからの情報を合併するために最も良い習慣を決定するのに必要です、オプションがそのような情報を運ぶアドレスのリストの合併を含んでいて。

   As a footnote, we note that this work has overlap with multihoming
   and multi-interface configuration issues.  It is also interwoven with
   the Detecting Network Attachment area, for example, where a node may
   move from an IPv4-only network to a dual-stack network, or vice
   versa.  Both aspects may be best abstracted for discussion and
   progression in the respective IETF multi6, shim6, and dna WGs, in
   parallel with the two-server progression in the dhc WG.

脚注として、私たちは、この仕事がマルチホーミングとマルチインタフェース構成問題にオーバラップを持っていることに注意します。 また、例えば、それはノードがIPv4だけネットワークからデュアルスタックネットワークまで動くかもしれないところでDetecting Network Attachment領域で織り合わせられるか、逆もまた同様です。 それぞれのIETF multi6、shim6、およびdna WGsでの議論と進行のために両方の局面を抜き取るかもしれないのが最も良い、dhc WGでの2サーバの進行と平行して。

Chown, et al.                Informational                     [Page 11]

RFC 4477                DHCP: Dual-Stack Issues                 May 2006

Chown、他 情報[11ページ]のRFC4477DHCP: デュアルスタックは2006年5月を発行します。

6.  Security Considerations

6. セキュリティ問題

   There are no security considerations in this problem statement per
   se, as it does not propose a new protocol.

新しいプロトコルを提案しないとき、この問題声明にはセキュリティ問題が全くそういうものとしてありません。

7.  Acknowledgements

7. 承認

   The authors thank the following people for input to this document:
   Bernie Volz, AK Vijayabhaskar, Ted Lemon, Ralph Droms, Robert Elz,
   Changming Liu, Margaret Wasserman, Dave Thaler, Mark Hollinger, and
   Greg Daley.  The document may not necessarily fully reflect the views
   of each of these individuals.

作者はこのドキュメントへの入力について以下の人々に感謝します: バーニー・フォルツ、AK Vijayabhaskar、テッドLemon、ラルフDroms、ロバートElz、Changmingリュウ、マーガレット・ワッサーマン、デーヴThalerはホリンガー、およびグレッグ・デイリーをマークします。 ドキュメントは必ず完全にこれらの個人各人の視点を反映するかもしれないというわけではありません。

   The authors would also like to thank colleagues on the 6NET project
   for contributions to this document.

また、作者はこのドキュメントへの貢献のための6NETプロジェクトで同僚に感謝したがっています。

8.  Informative References

8. 有益な参照

   [1]  Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
        March 1997.

[1]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC2131、1997年3月。

   [2]  Thomson, S. and T. Narten, "IPv6 Stateless Address
        Autoconfiguration", RFC 2462, December 1998.

[2] トムソンとS.とT.Narten、「IPv6の国がないアドレス自動構成」、RFC2462、1998年12月。

   [3]  Droms, R. and W. Arbaugh, "Authentication for DHCP Messages",
        RFC 3118, June 2001.

[3]DromsとR.とW.Arbaugh、「DHCPメッセージのための認証」、RFC3118、2001年6月。

   [4]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
        Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
        RFC 3315, July 2003.

[4] Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。

   [5]  Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
        Service for IPv6", RFC 3736, April 2004.

[5]Droms、R.「(DHCP)がIPv6"、RFC3736年のために修理する国がないダイナミックなホスト構成プロトコル、2004年4月」。

   [6]  Lemon, T. and B. Sommerfeld, "Node-specific Client Identifiers
        for Dynamic Host Configuration Protocol Version Four (DHCPv4)",
        RFC 4361, February 2006.

[6] レモン、T.、およびB.ゾンマーフェルト、「ダイナミックなホスト構成のためのノード特有のクライアント識別子はバージョンFour(DHCPv4)について議定書の中で述べます」、RFC4361、2006年2月。

Chown, et al.                Informational                     [Page 12]

RFC 4477                DHCP: Dual-Stack Issues                 May 2006

Chown、他 情報[12ページ]のRFC4477DHCP: デュアルスタックは2006年5月を発行します。

Authors' Addresses

作者のアドレス

   Tim Chown
   University of Southampton
   School of Electronics and Computer Science
   Southampton, Hampshire  SO17 1BJ
   United Kingdom

エレクトロニクスのティムChownサウサンプトン大学学校とコンピュータサイエンスサウサンプトン、ハンプシャーSO17 1BJイギリス

   EMail: tjc@ecs.soton.ac.uk

メール: tjc@ecs.soton.ac.uk

   Stig Venaas
   UNINETT
   Trondheim  NO 7465
   Norway

スティVenaas UNINETTトロンヘイムNO7465ノルウェー

   EMail: venaas@uninett.no

メール: venaas@uninett.no

   Christian Strauf
   Clausthal University of Technology
   Erzstr. 51
   Clausthal-Zellerfeld  D-38678
   Germany

技術ErzstrのクリスチャンのStrauf Clausthal大学。 51 Clausthal-Zellerfeld D-38678ドイツ

   EMail: strauf@rz.tu-clausthal.de

メール: strauf@rz.tu-clausthal.de

Chown, et al.                Informational                     [Page 13]

RFC 4477                DHCP: Dual-Stack Issues                 May 2006

Chown、他 情報[13ページ]のRFC4477DHCP: デュアルスタックは2006年5月を発行します。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

Copyright(C)インターネット協会(2006)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Chown, et al.                Informational                     [Page 14]

Chown、他 情報[14ページ]