RFC4703 日本語訳

Network Working Group                                           M. Stapp
Request for Comments: 4703                                       B. Volz
Category: Standards Track                            Cisco Systems, Inc.
                                                            October 2006

コメントを求めるワーキンググループM.スタップ要求をネットワークでつないでください: 4703年のB.フォルツカテゴリ: 標準化過程シスコシステムズInc.2006年10月

       Resolution of Fully Qualified Domain Name (FQDN) Conflicts
        among Dynamic Host Configuration Protocol (DHCP) Clients

Dynamic Host Configuration Protocol(DHCP)クライアントの中の完全修飾ドメイン名(FQDN)闘争の解決

Status of This 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 (2006).

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

Abstract

要約

   The Dynamic Host Configuration Protocol (DHCP) provides a mechanism
   for host configuration that includes dynamic assignment of IP
   addresses and fully qualified domain names.  To maintain accurate
   name-to-IP-address and IP-address-to-name mappings in the DNS, these
   dynamically assigned addresses and fully qualified domain names
   (FQDNs) require updates to the DNS.  This document identifies
   situations in which conflicts in the use of fully qualified domain
   names may arise among DHCP clients and servers, and it describes a
   strategy for the use of the DHCID DNS resource record (RR) in
   resolving those conflicts.

Dynamic Host Configuration Protocol(DHCP)はIPアドレスと完全修飾ドメイン名のダイナミックな課題を含んでいるホスト構成にメカニズムを提供します。 これらのDNSの正確な名前からIPアドレスと命名するIPアドレスマッピング、ダイナミックに割り当てられたアドレス、および完全修飾ドメイン名(FQDNs)を維持するには、DNSにアップデートを必要としてください。 このドキュメントは完全修飾ドメイン名の使用における闘争がDHCPクライアントとサーバの中に起こるかもしれない状況を特定します、そして、それはそれらの闘争を解決することにおけるDHCID DNSリソース記録(RR)の使用のための戦略を説明します。

Stapp & Volz                Standards Track                     [Page 1]

RFC 4703              Resolution of FQDN Conflicts          October 2006

スタップとフォルツStandardsは2006年10月にFQDN闘争のRFC4703解決を追跡します[1ページ]。

Table of Contents

目次

   1. Introduction ....................................................3
   2. Terminology .....................................................3
   3. Issues with DNS Update in DHCP Environments .....................4
      3.1. Client Misconfiguration ....................................4
      3.2. Multiple DHCP Servers ......................................5
   4. Use of the DHCID RR .............................................5
   5. Procedures for Performing DNS Updates ...........................6
      5.1. Error Return Codes .........................................6
      5.2. Dual IPv4/IPv6 Client Considerations .......................6
      5.3. Adding A and/or AAAA RRs to DNS ............................7
           5.3.1. Initial DHCID RR Request ............................7
           5.3.2. DNS UPDATE When FQDN in Use .........................7
           5.3.3. FQDN in Use by Another Client .......................8
      5.4. Adding PTR RR Entries to DNS ...............................8
      5.5. Removing Entries from DNS ..................................9
      5.6. Updating Other RRs ........................................10
   6. Security Considerations ........................................10
   7. Acknowledgements ...............................................11
   8. References .....................................................11
      8.1. Normative References ......................................11
      8.2. Informative References ....................................11

1. 序論…3 2. 用語…3 3. DNSの問題はDHCPで環境をアップデートします…4 3.1. クライアントMisconfiguration…4 3.2. 複数のDHCPサーバ…5 4. DHCID RRの使用…5 5. DNSアップデートを実行するための手順…6 5.1. 誤り復帰コード…6 5.2. 二元的なIPv4/IPv6クライアント問題…6 5.3. A、そして/または、AAAA RRsをDNSに加えます…7 5.3.1. DHCID RR要求に頭文字をつけてください…7 5.3.2. DNSは使用中のいつFQDNをアップデートするか…7 5.3.3. 別のクライアントで使用中のFQDN…8 5.4. PTR RRエントリーをDNSに加えます…8 5.5. DNSからエントリーを取り除きます…9 5.6. 他のRRsをアップデートします…10 6. セキュリティ問題…10 7. 承認…11 8. 参照…11 8.1. 標準の参照…11 8.2. 有益な参照…11

Stapp & Volz                Standards Track                     [Page 2]

RFC 4703              Resolution of FQDN Conflicts          October 2006

スタップとフォルツStandardsは2006年10月にFQDN闘争のRFC4703解決を追跡します[2ページ]。

1.  Introduction

1. 序論

   "The Client FQDN Option" [8] includes a description of the operation
   of [4] clients and servers that use the DHCPv4 client FQDN option.
   "The DHCPv6 Client FQDN Option" [9] includes a description of the
   operation of [5] clients and servers that use the DHCPv6 client FQDN
   option.  Through the use of the client FQDN option, DHCP clients and
   servers can negotiate the client's FQDN and the allocation of
   responsibility for updating the DHCP client's A and/or AAAA RRs.
   This document identifies situations in which conflicts in the use of
   FQDNs may arise among DHCP clients and servers, and it describes a
   strategy for the use of the DHCID DNS resource record [2] in
   resolving those conflicts.

「Client FQDN Option」[8]は[4] DHCPv4クライアントFQDNオプションを使用するクライアントとサーバの操作の記述を含んでいます。 「DHCPv6 Client FQDN Option」[9]は[5] DHCPv6クライアントFQDNオプションを使用するクライアントとサーバの操作の記述を含んでいます。 クライアントFQDNオプションの使用で、DHCPクライアントとサーバはDHCPクライアントのA、そして/または、AAAA RRsをアップデートすることへの責任のクライアントのFQDNと配分を交渉できます。 このドキュメントはFQDNsの使用における闘争がDHCPクライアントとサーバの中に起こるかもしれない状況を特定します、そして、それはそれらの闘争を解決することにおけるDHCID DNSリソース記録[2]の使用のための戦略を説明します。

   In any case, whether a site permits all, some, or no DHCP servers and
   clients to perform DNS updates ([3], [10]) into the zones that it
   controls is entirely a matter of local administrative policy.  This
   document does not require any specific administrative policy, and
   does not propose one.  The range of possible policies is very broad,
   from sites where only the DHCP servers have been given credentials
   that the DNS servers will accept, to sites where each individual DHCP
   client has been configured with credentials that allow the client to
   modify its own FQDN.  Compliant implementations MAY support some or
   all of these possibilities.  Furthermore, this specification applies
   only to DHCP client and server processes; it does not apply to other
   processes that initiate DNS updates.

どのような場合でも、サイトが、すべて、DHCPサーバ、およびいくつかではなく、クライアントがDNSアップデート([3]を実行することを許可するか否かに関係なく、それが制御するゾーンへの[10])は完全にローカルの施政方針の問題です。 このドキュメントは、少しの特定の施政方針も必要としないで、また1つを提案しません。 可能な方針の範囲は非常に広いです、DNSサーバが受け入れる資格証明書がDHCPサーバだけに与えられているサイトから、それぞれの個々のDHCPクライアントがクライアントがそれ自身のFQDNを変更できる資格証明書によって構成されたサイトに。 対応する実装はこれらの可能性のいくつかかすべてをサポートするかもしれません。 その上、この仕様はDHCPクライアントとサーバプロセスだけに適用されます。 それはDNSアップデートを開始する他のプロセスに適用されません。

2.  Terminology

2. 用語

   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 [1].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[1]で説明されるように本書では解釈されることであるべきですか?

   This document assumes familiarity with DNS terminology defined in [6]
   and DHCP terminology defined in [4] and [5].

このドキュメントは[6]で定義されるDNS用語と[4]と[5]で定義されるDHCP用語への親しみを仮定します。

   FQDN, or Fully Qualified Domain Name, is the full name of a system,
   rather than just its hostname.  For example, "venera" is a hostname,
   and "venera.isi.edu" is an FQDN.  See [7].

FQDN、またはFully Qualified Domain Nameがまさしくホスト名よりむしろシステムのフルネームです。 例えば、"venera"はホスト名です、そして、"venera.isi.edu"はFQDNです。 [7]を見てください。

   DOCSIS, or Data-Over-Cable Service Interface Specifications, is
   defined by CableLabs.

DOCSIS、またはData過剰Cable Service Interface SpecificationsがCableLabsによって定義されます。

Stapp & Volz                Standards Track                     [Page 3]

RFC 4703              Resolution of FQDN Conflicts          October 2006

スタップとフォルツStandardsは2006年10月にFQDN闘争のRFC4703解決を追跡します[3ページ]。

3.  Issues with DNS Update in DHCP Environments

3. DNSの問題はDHCPで環境をアップデートします。

   There are two DNS update situations that require special
   consideration in DHCP environments: cases where more than one DHCP
   client has been configured with the same FQDN, and cases where more
   than one DHCP server has been given authority to perform DNS updates
   in a zone.  In these cases, it is possible for DNS records to be
   modified in inconsistent ways unless the updaters have a mechanism
   that allows them to detect anomalous situations.  If DNS updaters can
   detect these situations, site administrators can configure the
   updaters' behavior so that the site's policies can be enforced.  This
   specification describes a mechanism designed to allow updaters to
   detect these situations and suggests that DHCP implementations use
   this mechanism by default.

DHCP環境には特別の配慮を必要とする2つのDNSアップデート状況があります: 1人以上のDHCPクライアントが同じFQDNによって構成されたケース、およびゾーンでDNSアップデートを実行する権威が1つ以上のDHCPサーバに与えられているケース。 これらの場合では、updatersに彼らが変則的な状況を検出できるメカニズムがないなら、DNS記録が矛盾した方法で変更されるのは、可能です。 DNS updatersがこれらの状況を検出できるなら、サイトの管理者は、サイトの方針を励行されることができるように、updatersの振舞いを構成できます。 この仕様は、updatersがこれらの状況を検出するのを許容するように設計されたメカニズムについて説明して、DHCP実装がデフォルトでこのメカニズムを使用するのを示します。

3.1.  Client Misconfiguration

3.1. クライアントMisconfiguration

   Administrators may wish to maintain a one-to-one relationship between
   active DHCP clients and FQDNs, and to maintain consistency between a
   client's A, AAAA, and PTR RRs.  Clients that are not represented in
   the DNS, or clients that inadvertently share an FQDN with another
   client may encounter inconsistent behavior or may not be able to
   obtain access to network resources.  Whether each DHCP client is
   configured with an FQDN by its administrator or whether the DHCP
   server is configured to distribute the clients' FQDN, the consistency
   of the DNS data is entirely dependent on the accuracy of the
   configuration procedure.  Sites that deploy [10] may configure
   credentials for each client and its assigned FQDN in a way that is
   more error-resistant, as both the FQDN and credentials must match.

管理者は、活発なDHCPクライアントとFQDNsとの1〜1つの関係を維持して、クライアントのAと、AAAAと、PTR RRsの間の一貫性を維持したがっているかもしれません。 表されないで、DNS、またはうっかり共有するクライアントでは別のクライアントがいるFQDNが無節操な振舞いに遭遇できないかもしれないか、ネットワーク資源へのアクセスを得ることができないかもしれないということであるクライアント。 それぞれのDHCPクライアントがFQDNによって管理者によって構成されるか、またはDHCPサーバがクライアントのFQDNを分配するために構成されることにかかわらず、DNSデータの一貫性は構成手順の精度に完全に依存しています。 [10]を配布するサイトは各クライアントとその割り当てられたFQDNのためにFQDNと資格証明書の両方が合わなければならなくて、以上がエラーレジスタントである方法で資格証明書を構成するかもしれません。

   Consider an example in which two DHCP clients in the "example.com"
   network are both configured with the hostname "foo".  The clients are
   permitted to perform their own DNS updates.  The first client, client
   A, is configured via DHCP.  It adds an A RR to "foo.example.com", and
   its DHCP server adds a PTR RR corresponding to its assigned IP
   address.  When the second client, client B, boots, it is also
   configured via DHCP, and it also begins to update "foo.example.com".

"example.com"ネットワークにおける2人のDHCPクライアントが"foo"というホスト名によってともに構成される例を考えてください。 クライアントがそれら自身のDNSアップデートを実行することが許可されています。 最初のクライアント(クライアントA)はDHCPを通して構成されます。 それは"foo.example.com"にA RRを加えます、そして、DHCPサーバは割り当てられたIPアドレスに対応するPTR RRを加えます。 クライアントB、2番目のクライアントであるときに、ブーツであり、また、それはDHCPを通して構成されます、そして、また、"foo.example.com"をアップデートし始めます。

   At this point, the "example.com" administrators may wish to establish
   some policy about DHCP clients' FQDNs.  If the policy is that each
   client that boots should replace any existing A RR that matches its
   FQDN, Client B can proceed, though Client A may encounter problems.
   In this example, Client B replaces the A RR associated with
   "foo.example.com".  Client A must have some way to recognize that the
   RR associated with "foo.example.com" now contains information for
   Client B, so that it can avoid modifying the RR.  When Client A's
   assigned IP address expires, for example, it should not remove an RR
   that reflects Client B's DHCP-assigned IP address.

ここに、"example.com"管理者はDHCPクライアントのFQDNsに関する何らかの方針を確立したがっているかもしれません。 方針がそれがブートする各クライアントがFQDNに合っているどんな既存のA RRも取り替えるべきであるということであるなら、Client Bは続くことができます、Client Aは問題に行きあたるかもしれませんが。この例では、Client Bは"foo.example.com"に関連しているA RRを取り替えます。 クライアントAには、"foo.example.com"に関連しているRRが現在Client Bのための情報を含むと認める何らかの方法がなければなりません、RRを変更するのを避けることができるように。 Client Aが割り当てられたとき、IPアドレスは期限が切れます、例えば、それがビーズのDHCPによって割り当てられたIPが扱うClientを反映するRRを取り外すべきではありません。

Stapp & Volz                Standards Track                     [Page 4]

RFC 4703              Resolution of FQDN Conflicts          October 2006

スタップとフォルツStandardsは2006年10月にFQDN闘争のRFC4703解決を追跡します[4ページ]。

   If the policy is that the first DHCP client with a given FQDN should
   be the only client associated with that FQDN, Client B needs to be
   able to determine if it is not the client associated with
   "foo.example.com".  It could be that Client A booted first, and that
   Client B should choose another FQDN.  Or it could be that B has
   booted on a new subnet and received a new IP address assignment, in
   which case B should update the DNS with its new IP address.  It must
   either retain persistent state about the last IP address it was
   assigned (in addition to its current IP address) or it must have some
   other way to detect that it was the last updater of "foo.example.com"
   in order to implement the site's policy.

方針が与えられたFQDNをもっている最初のDHCPクライアントがそのFQDNに関連している唯一のクライアントであるということであるなら、Client Bは、それが"foo.example.com"に関連しているクライアントでないかどうか決定できる必要があります。 Client Aが1番目をブートして、Client Bが別のFQDNを選ぶはずであるということであるかもしれません。 または、Bが新しいサブネットで受け取られているところで新しいIPアドレス課題をブートして、その場合、Bが新しいIPアドレスでDNSをアップデートするべきであるということであるかもしれません。 それはそれが割り当てられたか(現在のIPアドレスに加えて)、またはサイトの政策を実施するためにそれがそれを検出するためには、"foo.example.com"の最後のupdaterであったある他の方法で持たなければならない最後のIPアドレスに関して永続的な状態を保有しなければなりません。

3.2.  Multiple DHCP Servers

3.2. 複数のDHCPサーバ

   It is possible to arrange for DHCP servers to perform A and/or AAAA
   RR updates on behalf of their clients.  If a single DHCP server
   manages all of the DHCP clients at a site, it can maintain a database
   of the FQDNs in use and can check that database before assigning an
   FQDN to a client.  Such a database is necessarily proprietary,
   however, and the approach does not work once more than one DHCP
   server is deployed.

DHCPサーバが彼らのクライアントを代表してA、そして/または、AAAA RRアップデートを実行するように手配するのは可能です。 ただ一つのDHCPサーバがサイトでDHCPクライアントのすべてを管理するなら、それは、使用中のFQDNsに関するデータベースを維持できて、FQDNをクライアントに割り当てる前に、そのデータベースをチェックできます。 しかしながら、そのようなデータベースが必ず独占であり、アプローチはもう一度、1つのDHCPサーバが配布されるほど働いていません。

   When multiple DHCP servers are deployed, the servers require a way to
   coordinate the identities of DHCP clients.  Consider an example in
   which DHCPv4 Client A boots, obtains an IP address from Server S1,
   presenting the hostname "foo" in a Client FQDN option [8] in its
   DHCPREQUEST message.  Server S1 updates the FQDN "foo.example.com",
   adding an A RR containing the IP address assigned to A.  The client
   then moves to another subnet, served by Server S2.  When Client A
   boots on the new subnet, Server S2 will assign it a new IP address
   and will attempt to add an A RR containing the newly assigned IP
   address to the FQDN "foo.example.com".  At this point, without some
   communication mechanism that S2 can use to ask S1 (and every other
   DHCP server that updates the zone) about the client, S2 has no way to
   know whether Client A is currently associated with the FQDN, or
   whether A is a different client configured with the same FQDN.  If
   the servers cannot distinguish between these situations, they cannot
   enforce the site's naming policies.

複数のDHCPサーバが配布されるとき、サーバはDHCPクライアントのアイデンティティを調整する方法を必要とします。 どのDHCPv4 Client Aブーツで例を考えてくださいか、Server S1からIPアドレスを得て、DHCPREQUESTメッセージにおけるClient FQDNオプション[8]で"foo"というホスト名を提示して。 サーバS1はFQDN"foo.example.com"をアップデートして、次に、IPアドレスを含むA RRがA.にクライアントを選任したと言い足すのがServer S2によって役立たれた別のサブネットに移行します。 新しいサブネットのClient Aブーツであるときに、Server S2は、新しいIPアドレスをそれに割り当てて、FQDN"foo.example.com"に新たに割り当てられたIPアドレスを含むA RRを加えるのを試みるでしょう。 ここに、S2がクライアントに関してS1(そして、ゾーンをアップデートする他のあらゆるDHCPサーバ)に尋ねるのに使用できる何らかのコミュニケーションメカニズムがなければ、S2には、Client Aが現在、FQDNに関連しているかどうかかそれとも、Aが同じFQDNによって構成された異なったクライアントであるかどうかを知る方法が全くありません。 サーバがこれらの状況を見分けることができないなら、それらは、サイトが方針を命名するのを実施できません。

4.  Use of the DHCID RR

4. DHCID RRの使用

   A solution to both of these problems is for the updater (a DHCP
   client or DHCP server) to be able to determine which DHCP client has
   been associated with an FQDN, in order to offer administrators the
   opportunity to configure updater behavior.

これらの問題の両方へのソリューションはupdater(DHCPクライアントかDHCPサーバ)が、どのDHCPクライアントがFQDNに関連しているかを決定することであることができます、updaterの振舞いを構成する機会を管理者に提供するために。

Stapp & Volz                Standards Track                     [Page 5]

RFC 4703              Resolution of FQDN Conflicts          October 2006

スタップとフォルツStandardsは2006年10月にFQDN闘争のRFC4703解決を追跡します[5ページ]。

   For this purpose, a DHCID RR, specified in [2], is used to associate
   client identification information with an FQDN and the A, AAAA, and
   PTR RRs associated with that FQDN.  When either a client or server
   adds A, AAAA, or PTR RRs for a client, it also adds a DHCID RR that
   specifies a unique client identity, based on data from the client's
   DHCP message.  In this model, only one client is associated with a
   given FQDN at a time.

このために、[2]で指定されたDHCID RRは、そのFQDNに関連しているFQDN、A、AAAA、およびPTR RRsにクライアント識別情報を関連づけるのに使用されます。 また、クライアントかサーバのどちらかがクライアントのためにA、AAAA、またはPTR RRsを加えるとき、ユニークなクライアントのアイデンティティを指定するDHCID RRを加えます、クライアントのDHCPメッセージからのデータに基づいて。 このモデルでは、1人のクライアントだけが一度に、与えられたFQDNに関連しています。

   By associating this ownership information with each FQDN, cooperating
   DNS updaters may determine whether their client is currently
   associated with a particular FQDN and implement the appropriately
   configured administrative policy.  In addition, DHCP clients that
   currently have FQDNs may move from one DHCP server to another without
   losing their FQDNs.

この所有権情報を各FQDNに関連づけることによって、協力DNS updatersは彼らのクライアントが現在特定のFQDNに関連しているかどうか決定して、適切に構成された施政方針を実装するかもしれません。 さらに、彼らのFQDNsをなくさないで、現在FQDNsを持っているDHCPクライアントは1つのDHCPサーバから別のサーバまで移行するかもしれません。

   The specific algorithm utilizing the DHCID RR to signal client
   ownership is explained below.  The algorithm only works in the case
   where the updating entities all cooperate -- this approach is
   advisory only and is not a substitute for DNS security, nor is it
   replaced by DNS security.

クライアント所有権に合図するのにDHCID RRを利用する特定のアルゴリズムは以下で説明されます。 唯一のアルゴリズムは、アップデート実体はすべて、協力します--このアプローチが顧問である場合だけで働いて、DNSセキュリティの代用品ではありません、そして、それはDNSセキュリティに取り替えられません。

5.  Procedures for Performing DNS Updates

5. DNSアップデートを実行するための手順

5.1.  Error Return Codes

5.1. 誤り復帰コード

   Certain RCODEs defined in [3] indicate that the destination DNS
   server cannot perform an update, i.e., FORMERR, SERVFAIL, REFUSED,
   NOTIMP.  If one of these RCODEs is returned, the updater MUST
   terminate its update attempt.  Other RCODEs [13] may indicate that
   there are problems with the key being used and may mean to try a
   different key, if available, or to terminate the operation.  Because
   some errors may indicate a misconfiguration of the updater or the DNS
   server, the updater MAY attempt to signal to its administrator that
   an error has occurred, e.g., through a log message.

[3]で定義されたあるRCODEsは、目的地DNSサーバがアップデート、FORMERR、SERVFAIL、REFUSED、すなわち、NOTIMPを実行できないのを示します。 これらのRCODEsの1つを返すなら、updaterはアップデート試みを終えなければなりません。 他のRCODEs[13]は、使用されるキーに関する問題があるのを示して、利用可能であるなら異なったキーを試すか、または操作を終えることを意味するかもしれません。 いくつかの誤りがupdaterかDNSサーバのmisconfigurationを示すかもしれないので、updaterは、誤りが発生したと管理者に合図するのを試みるかもしれません、例えば、ログメッセージを通して。

5.2.  Dual IPv4/IPv6 Client Considerations

5.2. 二元的なIPv4/IPv6クライアント問題

   At the time of publication of this document, a small minority of DHCP
   clients support both IPv4 and IPv6.  We anticipate, however, that a
   transition will take place over a period of time, and more sites will
   have dual-stack clients present.  IPv6 clients require updates of
   AAAA RRs; IPv4 client require updates of A RRs.  The administrators
   of mixed deployments will likely wish to permit a single FQDN to
   contain A and AAAA RRs from the same client.

このドキュメントの公表時点で、DHCPクライアントのわずかな数の小数はIPv4とIPv6の両方をサポートします。 しかしながら、私たちは、変遷が期間の間行われると予期します、そして、より多くのサイトには、クライアントが提示するデュアルスタックがあるでしょう。 IPv6クライアントはAAAA RRsのアップデートを必要とします。 IPv4クライアントはA RRsのアップデートを必要とします。 複雑な展開の管理者は、独身のFQDNが同じクライアントからのAとAAAA RRsを含むことをおそらく許可したくなるでしょう。

   Sites that wish to permit a single FQDN to contain both A and AAAA
   RRs MUST make use of DHCPv4 clients and servers that support using
   the DHCP Unique Identifier (DUID) for DHCPv4 client identifiers such

独身のFQDNがAとAAAA RRsの両方を含むことを許可したがっているサイトはそのようなものをDHCPv4クライアントとサーバのDHCPv4クライアント識別子のために使用がDHCP Unique Identifier(DUID)であるとサポートする使用にしなければなりません。

Stapp & Volz                Standards Track                     [Page 6]

RFC 4703              Resolution of FQDN Conflicts          October 2006

スタップとフォルツStandardsは2006年10月にFQDN闘争のRFC4703解決を追跡します[6ページ]。

   that this DUID is used in computing the RDATA of the DHCID RR by both
   DHCPv4 and DHCPv6 for the client; see [11].  Otherwise, a dual-stack
   client that uses older-style DHCPv4 client identifiers (see [4] and
   [12]) will only be able to have either its A or AAAA records in DNS
   under a single FQDN because of the DHCID RR conflicts that result.

このDUIDはクライアントのためにDHCPv4とDHCPv6の両方でDHCID RRのRDATAを計算する際に使用されます。 [11]を見てください。 それは、より古いスタイルDHCPv4クライアント識別子を使用します。そうでなければ、デュアルスタッククライアント、([4]と[12])が結果として生じるDHCID RR闘争のために独身のFQDNの下にDNSにAかAAAA記録のどちらかを持つことができるだけであるのを確実にしてください。

5.3.  Adding A and/or AAAA RRs to DNS

5.3. A、そして/または、AAAA RRsをDNSに加えます。

   When a DHCP client or server intends to update A and/or AAAA RRs, it
   starts with the UPDATE request in Section 5.3.1.

DHCPクライアントかサーバがA、そして/または、AAAA RRsをアップデートするつもりであるとき、それはセクション5.3.1におけるUPDATE要求から始まります。

   As the update sequence below can result in loops, implementers SHOULD
   limit the total number of attempts for a single transaction.

以下のアップデート系列が輪をもたらすことができる間、implementers SHOULDは単一取引のための試みの総数を制限します。

5.3.1.  Initial DHCID RR Request

5.3.1. 初期のDHCID RR要求

   The updater prepares a DNS UPDATE request that includes as a
   prerequisite the assertion that the FQDN does not exist.  The update
   section of the request attempts to add the new FQDN and its IP
   address mapping (A and/or AAAA RRs) and the DHCID RR with its unique
   client identity.

updaterは前提条件としてFQDNが存在していないという主張を含んでいるDNS UPDATE要求を準備します。 要求のアップデート部は、ユニークなクライアントのアイデンティティで新しいFQDN、IPアドレス・マッピング(A、そして/または、AAAA RRs)、およびDHCID RRを加えるのを試みます。

   If the UPDATE request succeeds, the A and/or AAAA RR update is now
   complete (and a client updater is finished, while a server would then
   proceed to perform a PTR RR update).

UPDATE要求が成功するなら、A、そして/または、AAAA RRアップデートは現在、完全です(クライアントupdaterが完成していますが、次に、サーバはPTR RRアップデートを実行しかけるでしょう)。

   If the response to the UPDATE returns YXDOMAIN, the updater can now
   conclude that the intended FQDN is in use and proceeds to
   Section 5.3.2.

UPDATEへの応答がYXDOMAINを返すなら、updaterは現在、意図しているFQDNが使用中であると結論を下すことができて、セクション5.3.2に続きます。

   If any other status is returned, the updater SHOULD NOT attempt an
   update (see Section 5.1).

他の状態が返されるなら、updater SHOULDはアップデートを試みません(セクション5.1を見てください)。

5.3.2.  DNS UPDATE When FQDN in Use

5.3.2. 使用中のFQDNであることのDNSアップデート

   The updater next attempts to confirm that the FQDN is not being used
   by some other client by preparing an UPDATE request in which there
   are two prerequisites.  The first prerequisite is that the FQDN
   exists.  The second is that the desired FQDN has attached to it a
   DHCID RR whose contents match the client identity.  The update
   section of the UPDATE request contains:

次のupdaterは、FQDNが2つの前提条件があるUPDATE要求を準備することによってある他のクライアントによって使用されていないと確認するのを試みます。 第一条件によるFQDNが存在しているということです。 2番目は必要なFQDNがコンテンツがクライアントのアイデンティティに合っているDHCID RRをそれに取り付けたということです。 UPDATE要求のアップデート部は以下を含みます。

   1.  A delete of any existing A RRs on the FQDN if this is an A update
       or an AAAA update and the updater does not desire A records on
       the FQDN, or if this update is adding an A and the updater only
       desires a single IP address on the FQDN.

1. 願望A記録はFQDNでこれがAアップデートかそれともAAAAアップデートであるか、そして、updaterがそうしないFQDNの上のどんな既存のA RRsも削除するか、またはAはFQDNでこのアップデートがAを加えているか、そして、単一のIPが扱うより多くのupdaterに唯一の願望を削除します。

Stapp & Volz                Standards Track                     [Page 7]

RFC 4703              Resolution of FQDN Conflicts          October 2006

スタップとフォルツStandardsは2006年10月にFQDN闘争のRFC4703解決を追跡します[7ページ]。

   2.  A delete of the existing AAAA RRs on the FQDN if the updater does
       not desire AAAA records on the FQDN, or if this update is adding
       an AAAA and the updater only desires a single IP address on the
       FQDN.

2. Aが削除する、存在では、FQDNの上のAAAA RRsはupdaterであるならFQDNかそれともこのアップデートがAAAAを加えるかどうかに関するAAAA記録を望んでいなくて、updaterはFQDNに関するただ一つのIPアドレスを望んでいるだけです。

   3.  An add (or adds) of the A RR that matches the DHCP binding if
       this is an A update.

3. これがAアップデートであるなら付くDHCPに合っているA RRを加えてください(または、加えます)。

   4.  Adds of the AAAA RRs that match the DHCP bindings if this is an
       AAAA update.

4. これがAAAAアップデートであるならDHCP結合に合っているAAAA RRsを加えます。

   Whether A or AAAA RRs are deleted depends on the updater or updater's
   policy.  For example, if the updater is the client or configured as
   the only DHCP server for the link on which the client is located, the
   updater may find it beneficial to delete all A and/or AAAA RRs and
   then add the current set of A and/or AAAA RRs, if any, for the
   client.

AかAAAA RRsが削除されるかどうかがupdaterかupdaterの方針によります。 例えば、updaterがクライアントであるかリンクへのクライアントが見つけられている唯一のDHCPサーバとして構成されて、updaterは、すべてのA、そして/または、AAAA RRsを削除して、次に、A、そして/または、AAAA RRsの現在のセットを加えるのが有益であることがわかるかもしれません、もしあれば、クライアントのために。

   If the UPDATE request succeeds, the updater can conclude that the
   current client was the last client associated with the FQDN, and that
   the FQDN now contains the updated A and/or AAAA RRs.  The update is
   now complete (and a client updater is finished, while a server would
   then proceed to perform a PTR RR update).

UPDATE要求が成功するなら、updaterは、現在のクライアントがFQDNに関連している最後のクライアントであり、FQDNが現在アップデートされたA、そして/または、AAAA RRsを含むと結論を下すことができます。 アップデートは現在、完全です(クライアントupdaterが完成していますが、次に、サーバはPTR RRアップデートを実行しかけるでしょう)。

   If the response to the UPDATE request returns NXDOMAIN, the FQDN is
   no longer in use, and the updater proceeds back to Section 5.3.1.

UPDATE要求への応答がNXDOMAINを返すなら、FQDNはもう使用中ではありません、そして、updaterはセクション5.3.1に続いて戻ります。

   If the response to the UPDATE request returns NXRRSET, there are two
   possibilities: there are no DHCID RRs for the FQDN, or the DHCID RR
   does not match.  In either case, the updater proceeds to
   Section 5.3.3.

UPDATE要求への応答がNXRRSETを返すなら、2つの可能性があります: FQDNのためのDHCID RRsが全くないか、またはDHCID RRは合っていません。 どちらの場合ではも、updaterはセクション5.3.3に続きます。

5.3.3.  FQDN in Use by Another Client

5.3.3. 別のクライアントで使用中のFQDN

   As the FQDN appears to be in use by another client or is not
   associated with any client, the updater SHOULD either choose another
   FQDN and restart the update process with this new FQDN or terminate
   the update with a failure.

FQDNが別のクライアントで使用中であるように見えるか、またはどんなクライアントにも関連づけられないのに従って、updater SHOULDは別のFQDNを選んで、この新しいFQDNと共に更新処理を再開するか、または失敗でアップデートを終えます。

   Techniques that may be considered to disambiguate FQDNs include
   adding some suffix or prefix to the hostname portion of the FQDN or
   randomly generating a hostname.

FQDNsのあいまいさを除くと考えられるかもしれないテクニックは、FQDNのホスト名一部に何らかの接尾語か接頭語を加えるか、または手当たりしだいにホスト名を生成するのを含んでいます。

5.4.  Adding PTR RR Entries to DNS

5.4. PTR RRエントリーをDNSに加えます。

   The DHCP server submits a DNS UPDATE request that deletes all of the
   PTR RRs associated with the client's assigned IP address and adds a
   PTR RR whose data is the client's (possibly disambiguated) FQDN.  The

DHCPサーバはクライアントの割り当てられたIPアドレスに関連しているPTR RRsのすべてを削除して、データがクライアント(ことによるとあいまいさを除かれる)のFQDNであるPTR RRを加えるDNS UPDATE要求を提出します。 The

Stapp & Volz                Standards Track                     [Page 8]

RFC 4703              Resolution of FQDN Conflicts          October 2006

スタップとフォルツStandardsは2006年10月にFQDN闘争のRFC4703解決を追跡します[8ページ]。

   server MAY also add a DHCID RR as specified in Section 4, in which
   case it would include a delete of all of the DHCID RRs associated
   with the client's assigned IP address and would add a DHCID RR for
   the client.

また、サーバがセクション4における指定されるとしてのDHCID RRを加えるかもしれなくて、それがどの場合にaを含んでいるだろうかが、クライアントのためのDHCID RRをクライアントの割り当てられたIPアドレスに関連しているDHCID RRsのすべてを削除して、加えるでしょう。

   There is no need to validate the DHCID RR for PTR updates as the DHCP
   server (or servers) only assigns an address to a single client at a
   time.

DHCPサーバ(または、サーバ)が一度に独身のクライアントにアドレスを割り当てるだけであるときPTRアップデートのためにDHCID RRを有効にする必要は全くありません。

5.5.  Removing Entries from DNS

5.5. DNSからエントリーを取り除きます。

   The most important consideration in removing DNS entries is to be
   sure that an entity removing a DNS entry is only removing an entry
   that it added, or for which an administrator has explicitly assigned
   it responsibility.

DNSエントリーを取り除くのにおいて最も重要な考慮すべき事柄はいかにも、DNSエントリーを取り除く実体が加えたか、または管理者が明らかに責任をそれに割り当てたエントリーを取り除いているだけであるということです。

   When an address' lease time or valid lifetime expires or a DHCP
   client issues a DHCPRELEASE [4] or Release [5] request, the DHCP
   server SHOULD delete the PTR RR that matches the DHCP binding, if one
   was successfully added.  The server's UPDATE request SHOULD assert
   that the domain name (PTRDNAME field) in the PTR record matches the
   FQDN of the client whose address has expired or been released and
   should delete all RRs for the FQDN.

アドレスのリース時間か有効な寿命が呼吸が絶えるか、またはDHCPクライアントがDHCPRELEASE[4]かRelease[5]要求を出すとき、DHCPサーバSHOULDは1つが首尾よく加えられたなら付くDHCPに合っているPTR RRを削除します。 サーバのUPDATEは、SHOULDが、PTR記録のドメイン名(PTRDNAME分野)がアドレスが吐き出されたか、またはリリースされたクライアントのFQDNを合わせて、FQDNのためにすべてのRRsを削除するべきであると断言するよう要求します。

   The entity chosen to handle the A or AAAA records for this client
   (either the client or the server) SHOULD delete the A or AAAA records
   that were added when the address was assigned to the client.
   However, the updater should only remove the DHCID RR if there are no
   A or AAAA RRs remaining for the client.

実体のAかAAAAがこのクライアントのために記録するハンドルに選ばれた(クライアントかサーバのどちらか)SHOULDはアドレスがクライアントに割り当てられたとき加えられたAかAAAA記録を削除します。 しかしながら、クライアントのために残っているどんなAもAAAA RRsもない場合にだけ、updaterはDHCID RRを取り外すはずです。

   In order to perform this A or AAAA RR delete, the updater prepares an
   UPDATE request that contains a prerequisite that asserts that the
   DHCID RR exists whose data is the client identity described in
   Section 4 and contains an update section that deletes the client's
   specific A or AAAA RR.

働いてください。このAかAAAA RRが削除する、updaterはデータがセクション4で説明されたクライアントのアイデンティティであるDHCID RRが存在すると断言する前提条件を含んでいて、クライアントの特定のAかAAAA RRを削除するアップデート部を含むUPDATE要求を準備します。

   If the UPDATE request succeeds, the updater prepares a second UPDATE
   request that contains three prerequisites and an update section that
   deletes all RRs for the FQDN.  The first prerequisite asserts that
   the DHCID RR exists whose data is the client identity described in
   Section 4.  The second prerequisite asserts that there are no A RRs.
   The third prerequisite asserts that there are no AAAA RRs.

UPDATE要求が成功するなら、updaterは3つの前提条件を含むUPDATEが要求する1秒とFQDNのためにすべてのRRsを削除するアップデート部を準備します。 第一条件は、データがセクション4で説明されたクライアントのアイデンティティであるDHCID RRが存在すると断言します。 2番目の前提条件は、A RRsが全くないと断言します。 3番目の前提条件は、AAAA RRsが全くないと断言します。

   If either request fails, the updater MUST NOT delete the FQDN.  It
   may be that the client whose address has expired has moved to another
   network and obtained an address from a different server, which has
   caused the client's A or AAAA RR to be replaced.  Or, the DNS data
   may have been removed or altered by an administrator.

どちらの要求も失敗するなら、updaterはFQDNを削除してはいけません。 アドレスが期限が切れたクライアントは、異なったサーバから多分、別のネットワークに移行して、アドレスを得ました。(それは、クライアントのAかAAAA RRを取り替えました)。 または、DNSデータは、管理者によって取り除かれたか、または変更されたかもしれません。

Stapp & Volz                Standards Track                     [Page 9]

RFC 4703              Resolution of FQDN Conflicts          October 2006

スタップとフォルツStandardsは2006年10月にFQDN闘争のRFC4703解決を追跡します[9ページ]。

5.6.  Updating Other RRs

5.6. 他のRRsをアップデートします。

   The procedures described in this document only cover updates to the
   A, AAAA, PTR, and DHCID RRs.  Updating other types of RRs is outside
   the scope of this document.

本書では説明された手順はA、AAAA、PTR、およびDHCID RRsにアップデートをカバーするだけです。 このドキュメントの範囲の外にRRsの他のタイプをアップデートするのがあります。

6.  Security Considerations

6. セキュリティ問題

   Administrators should be wary of permitting unsecured DNS updates to
   zones, whether or not they are exposed to the global Internet.  Both
   DHCP clients and servers SHOULD use some form of update request
   authentication (e.g., TSIG [13]) when performing DNS updates.

管理者はunsecured DNSがゾーンにアップデートする可能にするのに用心深いはずです、それらが世界的なインターネットに暴露されるか否かに関係なく。 DHCPクライアントとサーバSHOULDの両方が何らかの形式の更新要求認証を使用する、(例えば、TSIG、[13]) DNSアップデートを実行するとき。

   Whether a DHCP client may be responsible for updating an FQDN-to-IP-
   address mapping, or whether this is the responsibility of the DHCP
   server, is a site-local matter.  The choice between the two
   alternatives may be based on the security model that is used with the
   Dynamic DNS Update protocol (e.g., only a client may have sufficient
   credentials to perform updates to the FQDN-to-IP-address mapping for
   its FQDN).

-DHCPクライアントはFQDNをアップデートするのに責任があるかもしれないか否かに関係なく、-IP-アドレス・マッピングかそれともこれがDHCPサーバの責任であるかどうかには、サイト地域にかかわる事柄があります。 2つの選択肢の選択はDynamic DNS Updateプロトコルと共に使用される機密保護モデルに基づくかもしれません(例えば、クライアントだけには、IPへのFQDNがFQDNに関してマッピングを扱うのにアップデートを実行できるくらいの資格証明書があるかもしれません)。

   Whether a DHCP server is always responsible for updating the FQDN-
   to-IP-address mapping (in addition to updating the IP-to-FQDN
   mapping), regardless of the wishes of an individual DHCP client, is
   also a site-local matter.  The choice between the two alternatives
   may be based on the security model that is being used with dynamic
   DNS updates.  In cases where a DHCP server is performing DNS updates
   on behalf of a client, the DHCP server should be sure of the FQDN to
   use for the client, and of the identity of the client.

個々のDHCPクライアントの願望にかかわらず、また、DHCPサーバがいつもFQDNをアップデートするのにIPアドレス・マッピングであることで(IPからFQDNへのマッピングをアップデートすることに加えた)原因となるかどうかが、サイト地域にかかわる事柄です。 2つの選択肢の選択はダイナミックなDNSアップデートと共に使用されている機密保護モデルに基づくかもしれません。 DHCPサーバがクライアントを代表してDNSアップデートを実行している場合では、DHCPサーバはクライアントの使用へのFQDN、およびクライアントのアイデンティティが確かであるべきです。

   Currently, it is difficult for DHCP servers to develop much
   confidence in the identities of their clients, given the absence of
   entity authentication from the DHCP protocol itself.  There are many
   ways for a DHCP server to develop an FQDN to use for a client, but
   only in certain relatively rare circumstances will the DHCP server
   know for certain the identity of the client.  If [14] becomes widely
   deployed, this may become more customary.

現在、DHCPサーバが彼らのクライアントのアイデンティティにおける多くの信用を発生するのは、難しいです、DHCPプロトコル自体からの実体認証の欠如を考えて。 DHCPサーバがクライアントの使用にFQDNを開発する多くの方法がありますが、ある比較的まれな事情だけでは、DHCPサーバは確かにクライアントのアイデンティティを知るでしょう。 [14]が広く配布されるようになるなら、これは、より通例になるかもしれません。

   One example of a situation that offers some extra assurances is when
   the DHCP client is connected to a network through a DOCSIS cable
   modem, and the Cable Modem Termination System (head-end) of the cable
   modem ensures that MAC address spoofing simply does not occur.
   Another example of a configuration that might be trusted is when
   clients obtain network access via a network access server using PPP.
   The Network Access Server (NAS) itself might be obtaining IP
   addresses via DHCP, encoding client identification into the DHCP
   client-id option.  In this case, the NAS as well as the DHCP server
   might be operating within a trusted environment, in which case the

いくつかの付加的な保証を提供する状況に関する1つの例がDHCPクライアントがDOCSISケーブルモデムを通してネットワークに接続される時です、そして、ケーブルモデムのCable Modem Termination System(ギヤエンド)はMACアドレススプーフィングが絶対に起こらないのを確実にします。 信じられるかもしれない構成に関する別の例はクライアントがPPPを使用することでネットワークアクセス・サーバーでネットワークアクセスを得る時です。 Network Access Server(NAS)自身はDHCPを通してIPアドレスを得ているかもしれません、DHCPクライアントイドオプションにクライアント識別をコード化して。 この場合、DHCPサーバと同様にNASは信じられた環境の中で作動しているかもしれません、その場合

Stapp & Volz                Standards Track                    [Page 10]

RFC 4703              Resolution of FQDN Conflicts          October 2006

スタップとフォルツStandardsは2006年10月にFQDN闘争のRFC4703解決を追跡します[10ページ]。

   DHCP server could be configured to trust that the user authentication
   and authorization processing of the NAS was sufficient, and would
   therefore trust the client identification encoded within the DHCP
   client-id.

DHCPサーバは、NASのユーザー認証と承認処理が十分であったと信じるために構成できて、したがって、DHCPクライアントイドの中でコード化されたクライアント識別を信じるでしょう。

7.  Acknowledgements

7. 承認

   Many thanks to Mark Beyer, Jim Bound, Ralph Droms, Robert Elz, Peter
   Ford, Olafur Gudmundsson, Edie Gunter, Andreas Gustafsson, David W.
   Hankins, R. Barr Hibbs, Kim Kinnear, Stuart Kwan, Ted Lemon, Ed
   Lewis, Michael Lewis, Josh Littlefield, Michael Patton, Pekka Savola,
   and Glenn Stump for their review and comments.

彼らのレビューとコメントのためにマークBeyer、ジムBound、ラルフDroms、ロバートElz、ピーター・フォード、Olafurグドムンソン、エディGunter、アンドレアス・グスタファソン、デヴィッド・W.ハンキンズ、R.バール・ヒッブス、キム・キネア、スチュアート・クワン、テッドLemon、Ed Lewis、マイケル・ルイス、ジョッシュ・リトルフィールド、マイケル・パットン、ペッカSavola、およびグレンStumpをありがとうございます。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [2]  Stapp, M., Lemon, T., and A. Gustafsson, "A DNS Resource Record
        (RR) for Encoding Dynamic Host Configuration Protocol (DHCP)
        Information (DHCID RR), RFC 4701, October 2006.

[2] スタップ、M.、レモン、T.、およびA.グスタファソン、「2006年10月にDynamic Host Configuration Protocol(DHCP)情報(DHCID RR)、RFC4701をコード化するためのDNSリソース記録(RR)。」

   [3]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
        Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
        April 1997.

Vixie、P.、トムソン、S.、Rekhter、Y.、およびJ.が縛った[3]、「ドメインネームシステムにおけるダイナミックなアップデート(DNSアップデート)」、RFC2136(1997年4月)。

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

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

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

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

8.2.  Informative References

8.2. 有益な参照

   [6]   Mockapetris, P., "Domain names - implementation and
         specification", STD 13, RFC 1035, November 1987.

[6]Mockapetris、P.、「ドメイン名--、実現と仕様、」、STD13、RFC1035、11月1987日

   [7]   Malkin, G., "Internet Users' Glossary", FYI 18, RFC 1983,
         August 1996.

[7] マルキン、G.、「インターネットユーザの用語集」、FYI18、RFC1983、1996年8月。

   [8]   Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
         Configuration Protocol (DHCP) Client Fully Qualified Domain
         Name (FQDN) Option", RFC 4702, October 2006.

[8] スタップ、M.、フォルツ、B.、およびY.Rekhter、「Dynamic Host Configuration Protocol(DHCP)クライアント完全修飾ドメイン名(FQDN)オプション」、RFC4702(2006年10月)。

Stapp & Volz                Standards Track                    [Page 11]

RFC 4703              Resolution of FQDN Conflicts          October 2006

スタップとフォルツStandardsは2006年10月にFQDN闘争のRFC4703解決を追跡します[11ページ]。

   [9]   Volz, B., "The Dynamic Host Configuration Protocol for IPv6
         (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC
         4704, October 2006.

[9] フォルツ、B.、「IPv6(DHCPv6)クライアント完全修飾ドメイン名(FQDN)オプションのためのDynamic Host Configuration Protocol」、RFC4704(2006年10月)。

   [10]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
         Update", RFC 3007, November 2000.

[10] ウェリントン、2000年11月、B.、「安全なドメインネームシステム(DNS)ダイナミック・アップデート」RFC3007。

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

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

   [12]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
         Extensions", RFC 2132, March 1997.

[12] アレクサンダーとS.とR.Droms、「DHCPオプションとBOOTP業者拡大」、RFC2132、1997年3月。

   [13]  Vixie, P., Gudmundsson, O., Eastlake, D., and B. Wellington,
         "Secret Key Transaction Authentication for DNS (TSIG)",
         RFC 2845, May 2000.

[13] Vixie(P.、グドムンソン、O.、イーストレーク、D.、およびB.ウェリントン、「DNS(TSIG)のための秘密鍵取引認証」、RFC2845)は2000がそうするかもしれません。

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

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

Authors' Addresses

作者のアドレス

   Mark Stapp
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA  01719
   USA

スタップシスコシステムズInc.1414マサチューセッツAveをマークしてください。 Boxborough、MA01719米国

   Phone: 978.936.1535
   EMail: mjs@cisco.com

以下に電話をしてください。 978.936.1535 メールしてください: mjs@cisco.com

   Bernie Volz
   Cisco Systems, Inc.
   1414 Massachusetts Ave.
   Boxborough, MA  01719
   USA

バーニーフォルツシスコシステムズInc.1414マサチューセッツAve。 Boxborough、MA01719米国

   Phone: 978.936.0382
   EMail: volz@cisco.com

以下に電話をしてください。 978.936.0382 メールしてください: volz@cisco.com

Stapp & Volz                Standards Track                    [Page 12]

RFC 4703              Resolution of FQDN Conflicts          October 2006

スタップとフォルツStandardsは2006年10月にFQDN闘争のRFC4703解決を追跡します[12ページ]。

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)によって提供されます。

Stapp & Volz                Standards Track                    [Page 13]

スタップとフォルツ標準化過程[13ページ]