RFC3736 日本語訳

Network Working Group                                           R. Droms
Request for Comments: 3736                                 Cisco Systems
Category: Standards Track                                     April 2004

Dromsがコメントのために要求するワーキンググループR.をネットワークでつないでください: 3736年のシスコシステムズカテゴリ: 標準化過程2004年4月

 Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6

IPv6のための状態がないDynamic Host Configuration Protocol(DHCP)サービス

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2004).  All Rights Reserved.

Copyright(C)インターネット協会(2004)。 All rights reserved。

Abstract

要約

   Stateless Dynamic Host Configuration Protocol service for IPv6
   (DHCPv6) is used by nodes to obtain configuration information, such
   as the addresses of DNS recursive name servers, that does not require
   the maintenance of any dynamic state for individual clients.  A node
   that uses stateless DHCP must have obtained its IPv6 addresses
   through some other mechanism, typically stateless address
   autoconfiguration.  This document explains which parts of RFC 3315
   must be implemented in each of the different kinds of DHCP agents so
   that agent can support stateless DHCP.

IPv6(DHCPv6)のための状態がないDynamic Host Configuration Protocolサービスはノードによって利用されて、DNSの再帰的なネームサーバのアドレスなどのようなそれが個々のクライアントのためにどんな動態のメインテナンスも必要としないという設定情報を得ます。 状態がないDHCPを使用するノードはある他のメカニズム、通常状態がないアドレス自動構成を通してIPv6アドレスを得たに違いありません。 このドキュメントで、そのエージェントが状態がないDHCPをサポートすることができるようにそれぞれのDHCPエージェントの異種でRFC3315のどの部分を実装しなければならないかがわかります。

1.  Introduction

1. 序論

   Nodes that have obtained IPv6 addresses through some other mechanism,
   such as stateless address autoconfiguration [6] or manual
   configuration, can use stateless DHCP to obtain other configuration
   information such as a list of DNS recursive name servers or SIP
   servers.  A stateless DHCP server provides only configuration
   information to nodes and does not perform any address assignment.
   Such a server is called "stateless" because it need not maintain any
   dynamic state for individual clients.

状態がないアドレス自動構成[6]か手動の構成などのある他のメカニズムを通してIPv6アドレスを得たノードは、DNSの再帰的なネームサーバかSIPサーバのリストなどの他の設定情報を得るのに状態がないDHCPを使用できます。 状態がないDHCPサーバは、設定情報だけをノードに提供して、どんなアドレス課題も実行しません。 個々のクライアントのために少しの動態も維持する必要はないので、そのようなサーバは「状態がない」と呼ばれます。

   While the DHCP specification [1] defines more than 10 protocol
   messages and 20 options, only a subset of those messages and options
   are required for stateless DHCP service.  This document explains
   which messages and options defined in RFC 3315 are required for
   stateless DHCP service.  The intended use of the document is to guide

DHCP仕様[1]が10以上プロトコルを定義している間、それらのメッセージとオプションのメッセージと20のオプション、部分集合だけが状態がないDHCPサービスに必要です。 このドキュメントで、RFC3315で定義されたどのメッセージとオプションが状態がないDHCPサービスに必要であるかがわかります。 ガイドにはドキュメントの意図している使用があります。

Droms                       Standards Track                     [Page 1]

RFC 3736            Stateless DHCP Service for IPv6           April 2004

IPv6 April 2004のためのDroms標準化過程[1ページ]RFC3736の状態がないDHCPサービス

   the interoperable implementation of clients and servers that use
   stateless DHCP service.

状態がないDHCPサービスを利用するクライアントとサーバの共同利用できる実装。

   The operation of relay agents is the same for stateless and stateful
   DHCP service.  The operation of relay agents is described in the DHCP
   specification.

状態がない、そして、stateful DHCPサービスに、中継エージェントの操作は同じです。 中継エージェントの操作はDHCP仕様で説明されます。

   Section 4 of this document lists the sections of the DHCP document
   that an implementor should read for an overview of the DHCP
   specification and the basic requirements of a DHCP service.  Section
   5 lists the specific messages and options that are specifically
   required for stateless DHCP service.  Section 6 describes how
   stateless and stateful DHCP servers interact to provide service to
   clients that require address assignment and clients that require only
   stateless service.

このドキュメントのセクション4は作成者がDHCP仕様の概要とDHCPサービスの基本的な要件のために読むべきであるDHCPドキュメントのセクションを記載します。 セクション5は状態がないDHCPサービスに明確に必要である特定のメッセージとオプションをリストアップします。 セクション6は状態がない、そして、stateful DHCPサーバがアドレス課題を必要とするクライアントと状態がないサービスだけを必要とするクライアントに対するサービスを提供するためにどう相互作用するかを説明します。

2.  Terminology

2. 用語

   Throughout this document, "DHCP" refers to DHCP for IPv6.

このドキュメント中では、"DHCP"はIPv6についてDHCPを示します。

   This document uses the terminology defined in RFC 2460 [2], the DHCP
   specification [1], and the DHCP DNS configuration options
   specification [3].

このドキュメントはRFC2460[2]で定義された用語、DHCP仕様[1]、およびDHCP DNS設定オプション仕様[3]を使用します。

   "Stateless DHCP" refers to the use of DHCP to provide configuration
   information to clients that does not require the server to maintain
   dynamic state about the DHCP clients.

「状態がないDHCP」は、クライアントへのDHCPクライアントに関して動態を維持するためにサーバを必要としない設定情報を提供するためにDHCPの使用を示します。

3.  Overview

3. 概要

   This document assumes that a node using stateless DHCP configuration
   is not using DHCP for address assignment, and that a node has
   determined at least a link-local address as described in section 5.3
   of RFC 2461 [4].

このドキュメントは、状態がないDHCP構成を使用するノードがアドレス課題にDHCPを使用していなくて、ノードがRFC2461[4]のセクション5.3で説明されるように少なくともリンクローカルアドレスを決定したと仮定します。

   To obtain configuration parameters through stateless DHCP, a node
   uses the DHCP Information-request message.  DHCP servers respond to
   the node's message with a Reply message that carries configuration
   parameters for the node.  The Reply message from the server can carry
   configuration information, such as a list of DNS recursive name
   servers [3] and SIP servers [5].

状態がないDHCPを通して設定パラメータを得るために、ノードはDHCP情報要求メッセージを使用します。 DHCPサーバはノードのための設定パラメータを運ぶReplyメッセージでノードのメッセージに反応します。 サーバからのReplyメッセージはDNSの再帰的なネームサーバ[3]とSIPサーバ[5]のリストなどの設定情報を運ぶことができます。

   This document does not apply to the function of DHCP relay agents as
   described in RFC 3315.  A network element can provide both DHCP
   server and DHCP relay service.  For example, a network element can
   provide stateless DHCP service to hosts requesting stateless DHCP
   service, while relaying messages from hosts requesting address
   assignment through DHCP to another DHCP server.

このドキュメントはRFC3315で説明されるようにDHCP中継エージェントの機能に適用されません。 ネットワーク要素はDHCPサーバとDHCPリレーサービスの両方を提供できます。 例えば、ネットワーク要素はDHCPを通したアドレス課題を要求するホストから別のDHCPサーバまでメッセージをリレーしている間に状態がないDHCPサービスを要求するホストに対する状態がないDHCPサービスを提供できます。

Droms                       Standards Track                     [Page 2]

RFC 3736            Stateless DHCP Service for IPv6           April 2004

IPv6 April 2004のためのDroms標準化過程[2ページ]RFC3736の状態がないDHCPサービス

4.  Basic Requirements for Implementation of DHCP

4. DHCPの実装のための基本的な要件

   Several sections of the DHCP specification provide background
   information or define parts of the specification that are common to
   all implementations:

DHCP仕様の数人のセクションが、基礎的な情報を提供するか、または仕様のすべての実装に共通の部分を定義します:

   1-4:   give an introduction to DHCP and an overview of DHCP message
          flows

1-4: DHCPメッセージ流れのDHCPと概要に序論を与えてください。

   5:     defines constants used throughout the protocol specification

5: プロトコル仕様中で使用される定数を定義します。

   6, 7:  illustrate the format of DHCP messages

6, 7: DHCPメッセージの形式を例証してください。

   8:     describes the representation of Domain Names

8: Domain Namesの表現について説明します。

   9:     defines the "DHCP unique identifier" (DUID)

9: 「DHCPのユニークな識別子」を定義します。(DUID)

   13-16: describe DHCP message transmission, retransmission, and
          validation

13-16: DHCPメッセージ送信、「再-トランスミッション」、および合法化について説明してください。

   21:    describes authentication for DHCP

21: DHCPのために認証について説明します。

5.  Implementation of Stateless DHCP

5. 状態がないDHCPの実装

   The client indicates that it is requesting configuration information
   by sending an Information-request message that includes an Option
   Request option specifying the options that it wishes to receive from
   the DHCP server.  For example, if the client is attempting to obtain
   a list of DNS recursive name servers, it identifies the DNS Recursive
   Name Server option in the Information-request message.  The server
   determines the appropriate configuration parameters for the client
   based on its configuration policies and responds with a Reply message
   containing the requested parameters.  In this example, the server
   would respond with DNS configuration parameters.

クライアントは、DHCPサーバから受信したがっているというOption Requestオプションを含んでいる情報要求メッセージにオプションを指定させるのによる設定情報を要求しているのを示します。例えば、クライアントが、DNSの再帰的なネームサーバのリストを得るのを試みているなら、それは情報要求メッセージにおけるDNS Recursive Name Serverオプションを特定します。 サーバは、構成方針に基づくクライアントのために適切な設定パラメータを決定して、Replyメッセージが要求されたパラメタを含んでいて、反応します。 この例では、サーバはDNS設定パラメータで反応するでしょう。

   As described in section 18.1.5 of RFC 3315, a node may include a
   Client Identifier option in the Information-request message to
   identify itself to a server, because the server administrator may
   want to customize the server's response to each node, based on the
   node's identity.

.5セクション18.1RFC3315で説明されるように、ノードはサーバにそれ自体を特定する情報要求メッセージにClient Identifierオプションを含むかもしれません、サーバアドミニストレータが各ノードへのサーバの応答をカスタマイズしたがっているかもしれないので、ノードのアイデンティティに基づいて。

   RFC 3315 does not define any mechanisms through which the time at
   which a host uses an Information-request message to obtain updated
   configuration parameters can be controlled.  The DHC WG has
   undertaken the development of such a mechanism or mechanisms which
   will be published as Standards-track RFC(s).

RFC3315はホストがアップデートされた設定パラメータを得る情報要求メッセージを使用する時を制御できるどんなメカニズムも定義しません。 DHC WGはStandards-道のRFC(s)のような発表されるメカニズムかメカニズムの開発を引き受けました。

Droms                       Standards Track                     [Page 3]

RFC 3736            Stateless DHCP Service for IPv6           April 2004

IPv6 April 2004のためのDroms標準化過程[3ページ]RFC3736の状態がないDHCPサービス

   RFC 3315 also does not provide any guidance about when a host might
   use an Information-request message to obtain updated configuration
   parameters when the host has moved to a new link.  The DHC WG is
   reviewing a related document, "Detection of Network Attachment (DNA)
   in IPv4" [8], which describes how a host using IPv4 can determine
   when to use DHCPv4.  Either the DHC WG or a WG formed from the DNA
   BOF will undertake development of a similar document for IPv6.

RFC3315もホストがホストが新しいリンクに移行したときアップデートされた設定パラメータを得る情報要求メッセージを使用するかもしれない時に関して少しの指導も提供しません。 DHC WGは関連するドキュメント、「IPv4を使用しているホストが、いつDHCPv4を使用するかをどう決心できるかを説明するIPv4"[8]でのネットワーク付属(DNA)の検出」を見直しています。 DNA BOFから形成されたDHC WGかWGのどちらかがIPv6のための同様のドキュメントの開発を引き受けるでしょう。

5.1.  Messages Required for Stateless DHCP Service

5.1. メッセージが状態がないDHCPサービスに必要です。

   Clients and servers implement the following messages for stateless
   DHCP service; the section numbers in this list refer to the DHCP
   specification:

クライアントとサーバは状態がないDHCPサービスへの以下のメッセージを実装します。 このリストのセクション番号はDHCP仕様を示します:

   Information-request: sent by a DHCP client to a server to request
                        configuration parameters (sections 18.1.5 and
                        18.2.5)

情報要求: 設定パラメータを要求するためにDHCPクライアントによってサーバに送られます。(セクション18.1 .5と18.2、.5)

   Reply:               sent by a DHCP server to a client containing
                        configuration parameters (sections 18.2.6 and
                        18.2.8)

回答: DHCPサーバで、設定パラメータを含むクライアントに発信します。(セクション18.2 .6と18.2、.8)

   In addition, servers and relay agents implement the following
   messages for stateless DHCP service; the section numbers in this list
   refer to the DHCP specification:

さらに、サーバと中継エージェントは状態がないDHCPサービスへの以下のメッセージを実装します。 このリストのセクション番号はDHCP仕様を示します:

   Relay-forward: sent by a DHCP relay agent to carry the client message
                  to a server (section 15.13)

-前方に以下をリレーしてください。 クライアントメッセージをサーバに伝えるためにDHCP中継エージェントによって送られます。(セクション15.13)

   Relay-reply:   sent by a DHCP server to carry a response message to
                  the relay agent (section 15.14)

リレー回答: DHCPサーバで送って、中継エージェントまで応答メッセージを運びます。(セクション15.14)

5.2.  Options Required for Stateless DHCP Service

5.2. オプションが状態がないDHCPサービスに必要です。

   Clients and servers implement the following options for stateless
   DHCP service; the section numbers in this list refer to the DHCP
   specification:

クライアントとサーバは状態がないDHCPサービスのための以下のオプションを実装します。 このリストのセクション番号はDHCP仕様を示します:

   Option Request:    specifies the configuration information that the
                      client is requesting from the server (section
                      22.7)

オプション要求: クライアントがサーバから要求している設定情報を指定します。(セクション22.7)

   Status Code:       used to indicate completion status or other status
                      information (section 22.13)

ステータスコード: 完成状態か他の状態情報を示すために、使用されます。(セクション22.13)

   Server Identifier: used to identify the server responding to a client
                      request (section 22.3)

サーバ識別子: クライアント要求にサーバの応じることを特定するために、使用されます。(セクション22.3)

Droms                       Standards Track                     [Page 4]

RFC 3736            Stateless DHCP Service for IPv6           April 2004

IPv6 April 2004のためのDroms標準化過程[4ページ]RFC3736の状態がないDHCPサービス

   Servers and relay agents implement the following options for
   stateless DHCP service; the section numbers in this list refer to the
   DHCP specification:

サーバと中継エージェントは状態がないDHCPサービスのための以下のオプションを実装します。 このリストのセクション番号はDHCP仕様を示します:

   Client message: sent by a DHCP relay agent in a Relay-forward message
                   to carry the client message to a server (section 20)

クライアントメッセージ: DHCP中継エージェントで、クライアントメッセージをサーバに伝えるRelay前進のメッセージで発信します。(セクション20)

   Server message: sent by a DHCP server in a Relay-reply message to
                   carry a response message to the relay agent (section
                   20)

サーバメッセージ: 中継エージェントまで応答メッセージを運ぶRelay-応答メッセージのDHCPサーバで、発信します。(セクション20)

   Interface-ID:   sent by the DHCP relay agent and returned by the
                   server to identify the interface to be used when
                   forwarding a message to the client (section 22.18)

インタフェースID: DHCP中継エージェントが送って、サーバで返して、メッセージをクライアントに転送するとき、使用されるためにインタフェースを特定します。(セクション22.18)

5.3.  Options Used for Configuration Information

5.3. 設定情報に使用されるオプション

   Clients and servers use the following options to pass configuration
   information to clients; note that other options for configuration
   information may be specified in future Internet Standards:

クライアントとサーバは設定情報をクライアントに渡すのに以下のオプションを使用します。 設定情報のための別の選択肢が将来のインターネットStandardsで指定されるかもしれないことに注意してください:

   DNS Recursive Name Servers: specifies the DNS recursive name servers
                               [7] the client uses for name resolution;
                               see "DNS Configuration options for
                               DHCPv6" [3]

DNSの再帰的なネームサーバ: クライアントが名前解決に使用するDNSの再帰的なネームサーバ[7]を指定します。 「DHCPv6"のためのDNS Configurationオプション」を見てください。[3]

   DNS search list:            specifies the domain names to be searched
                               during name resolution; see "DNS
                               Configuration options for DHCPv6" [3]

DNSはリストを捜します: 名前解決の間、捜されるためにドメイン名を指定します。 「DHCPv6"のためのDNS Configurationオプション」を見てください。[3]

   SIP Servers:                specifies the SIP servers the client uses
                               to obtain a list of domain names of IPv6
                               addresses that can be mapped to one or
                               more SIP outbound proxy servers [5]

サーバをちびちび飲んでください: クライアントが1つ以上のSIPの外国行きのプロキシサーバに写像できるIPv6アドレスのドメイン名のリストを得るのに使用するSIPサーバを指定します。[5]

5.4.  Other Options Used in Stateless DHCP

5.4. 状態がないDHCPで使用される別の選択肢

   Clients and servers may implement the following options for stateless
   DHCP service; the section numbers in this list refer to the DHCP
   specification:

クライアントとサーバは状態がないDHCPサービスのための以下のオプションを実装するかもしれません。 このリストのセクション番号はDHCP仕様を示します:

   Preference:     sent by a DHCP server to indicate the preference
                   level for the server (section 22.8)

好み: DHCPサーバで送って、サーバのために好みのレベルを示します。(セクション22.8)

   Elapsed time:   sent by a DHCP client to indicate the time since the
                   client began the DHCP configuration process (section
                   22.9)

経過時間: クライアントがDHCPコンフィギュレーションプロセスを始めて以来の時間示すDHCPクライアントで、発信します。(セクション22.9)

Droms                       Standards Track                     [Page 5]

RFC 3736            Stateless DHCP Service for IPv6           April 2004

IPv6 April 2004のためのDroms標準化過程[5ページ]RFC3736の状態がないDHCPサービス

   User Class:     sent by a DHCP client to give additional information
                   to the server for selecting configuration parameters
                   for the client (section 22.15)

ユーザ・クラス: クライアントのために設定パラメータを選択するためのサーバに追加情報を与えるためにDHCPクライアントによって送られます。(セクション22.15)

   Vendor Class:   sent by a DHCP client to give additional information
                   about the client vendor and hardware to the server
                   for selecting configuration parameters for the client
                   (section 22.16)

ベンダーのクラス: クライアントベンダーとハードウェアに関する追加情報をクライアントのために設定パラメータを選択するためのサーバに与えるためにDHCPクライアントによって送られます。(セクション22.16)

   Vendor-specific Information: used to pass information to clients in
                                options defined by vendors (section
                                22.17)

ベンダー特殊情報: ベンダーによって定義されたオプションで情報をクライアントに渡すために、使用されます。(セクション22.17)

   Client Identifier: sent by a DHCP client to identify itself (section
                      22.2).  Clients are not required to send this
                      option; servers send the option back if included
                      in a message from a client

クライアント識別子: それ自体(セクション22.2)を特定するためにDHCPクライアントによって送られます。 クライアントはこのオプションを送る必要はありません。 クライアントからのメッセージに含まれているなら、サーバはオプションを返送します。

   Authentication: used to provide authentication of DHCP messages
                   (section 21)

認証: DHCPメッセージの認証を提供するために、使用されます。(セクション21)

6.  Interaction with DHCP for Address Assignment

6. アドレス課題のためのDHCPとの相互作用

   In some networks, there may be both clients that are using stateless
   address autoconfiguration and DHCP for DNS configuration and clients
   that are using DHCP for stateful address configuration.  Depending on
   the deployment and configuration of relay agents, DHCP servers that
   are intended only for stateless configuration may receive messages
   from clients that are performing stateful address configuration.

いくつかのネットワークには、DNS構成に状態がないアドレスの自動構成とDHCPを使用しているクライアントとstatefulアドレス構成にDHCPを使用しているクライアントの両方があるかもしれません。 中継エージェントの展開と構成によって、状態がない構成のためだけに意図するDHCPサーバはstatefulアドレス構成を実行しているクライアントからメッセージを受け取るかもしれません。

   A DHCP server that is only able to provide stateless configuration
   information through an Information-request/Reply message exchange
   discards any other DHCP messages it receives.  Specifically, the
   server discards any messages other than Information-Request or
   Relay-forward it receives, and the server does not participate in any
   stateful address configuration message exchanges.  If there are other
   DHCP servers that are configured to provide stateful address
   assignment, one of those servers will provide the address assignment.

情報要求/回答交換処理で状態がない設定情報を提供できるだけであるDHCPサーバはそれが受け取るいかなる他のDHCPメッセージも捨てます。 明確に、サーバは情報要求かそれが受け取るRelay-フォワード以外のどんなメッセージも捨てます、そして、サーバはどんなstatefulアドレス構成交換処理にも参加しません。 statefulアドレス課題を提供するために構成される他のDHCPサーバがあると、それらのサーバの1つはアドレス課題を提供するでしょう。

7.  Security Considerations

7. セキュリティ問題

   Stateless DHCP service is a proper subset of the DHCP service
   described in the DHCP specification, RFC 3315 [1].  Therefore,
   stateless DHCP service introduces no additional security
   considerations beyond those discussed in sections 21, 22.11, and 23
   of the DHCP specification [1].

状態がないDHCPサービスはDHCP仕様、RFC3315[1]で説明されたDHCPサービスの真部分集合です。 したがって、状態がないDHCPサービスはDHCP仕様[1]のセクション21、22.11、および23で議論したものを超えて追加担保問題を全く紹介しません。

Droms                       Standards Track                     [Page 6]

RFC 3736            Stateless DHCP Service for IPv6           April 2004

IPv6 April 2004のためのDroms標準化過程[6ページ]RFC3736の状態がないDHCPサービス

   Configuration information provided to a node through stateless DHCP
   service may be used to mount spoofing, man-in-the-middle, denial-of-
   service, and other attacks.  These attacks are described in more
   detail in the specifications for each of the options that carry
   configuration information.  Authenticated DHCP, as described in
   sections 21 and 22.11 of the DHCP specification [1], can be used to
   avoid attacks mounted through the stateless DHCP service.

状態がないDHCPサービスでノードに提供された設定情報はスプーフィングを仕掛けるのに使用されるかもしれません、中央の男性、否定、-、サービス、および他の攻撃について。 これらの攻撃はさらに詳細に設定情報を運ぶそれぞれのオプションのための仕様で説明されます。 状態がないDHCPサービスで仕掛けられた攻撃を避けるのにDHCP仕様[1]のセクション21と22.11で説明される認証されたDHCPは使用できます。

8.  Acknowledgments

8. 承認

   Jim Bound, Ted Lemon, and Bernie Volz reviewed this document and
   contributed editorial suggestions.  Thanks to Peter Barany, Tim
   Chown, Christian Huitema, Tatuya Jinmei, Pekka Savola, and Juha
   Wiljakka for their review and comments.

ジムBound、テッドLemon、およびバーニー・フォルツはこのドキュメントと寄付された編集の提案を再検討しました。 彼らのレビューとコメントをピーター・バラニー、ティムChown、クリスチャンのHuitema、Tatuya Jinmei、ペッカSavola、およびユハWiljakkaをありがとうございます。

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

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

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

   [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6)
       Specification", RFC 2460, December 1998.

[2] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日

9.2.  Informative References

9.2. 有益な参照

   [3] Droms, R., Ed., "DNS Configuration options for Dynamic Host
       Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December
       2003.

[3]Droms、R.、エド、「IPv6(DHCPv6)のためのDynamic Host Configuration ProtocolのためのDNS Configurationオプション」、RFC3646、12月2003日

   [4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for
       IP Version 6 (IPv6)", RFC 2461, December 1998.

[4]NartenとT.とNordmarkとE.とW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。

   [5] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol
       (DHCPv6) Options for Session Initiation Protocol (SIP) Servers",
       RFC 3319, July 2003.

[5] Schulzrinne、H.、およびB.フォルツ、「セッション開始のためのDynamic Host Configuration Protocol(DHCPv6)オプションは(一口)サーバについて議定書の中で述べます」、RFC3319、2003年7月。

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

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

   [7] Mockapetris, P., "Domain names - concepts and facilities", STD
       13, RFC 1034, November 1987.

[7]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日

   [8] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", Work
       in Progress.

[8]Aboba、B.、「IPv4"、進行中の仕事における、ネットワーク付属(DNA)の検出。」

Droms                       Standards Track                     [Page 7]

RFC 3736            Stateless DHCP Service for IPv6           April 2004

IPv6 April 2004のためのDroms標準化過程[7ページ]RFC3736の状態がないDHCPサービス

10.  Author's Address

10. 作者のアドレス

   Ralph Droms
   Cisco Systems
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   USA

ラルフDromsシスコシステムズ1414マサチューセッツ通りBoxborough、MA01719米国

   Phone: +1 978 497 4733
   EMail: rdroms@cisco.com

以下に電話をしてください。 +1 4733年の978 497メール: rdroms@cisco.com

Droms                       Standards Track                     [Page 8]

RFC 3736            Stateless DHCP Service for IPv6           April 2004

IPv6 April 2004のためのDroms標準化過程[8ページ]RFC3736の状態がないDHCPサービス

11.  Full Copyright Statement

11. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).  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.

Copyright(C)インターネット協会(2004)。 このドキュメントは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 currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Droms                       Standards Track                     [Page 9]

Droms標準化過程[9ページ]