RFC4361 日本語訳

Network Working Group                                           T. Lemon
Request for Comments: 4361                                       Nominum
Updates: 2131, 2132, 3315                                 B. Sommerfield
Category: Standards Track                               Sun Microsystems
                                                           February 2006

コメントを求めるワーキンググループT.レモン要求をネットワークでつないでください: 4361のNominumアップデート: 2131、2132、3315B.ソマーフィールドカテゴリ: 標準化過程サン・マイクロシステムズ2006年2月

                  Node-specific Client Identifiers for
       Dynamic Host Configuration Protocol Version Four (DHCPv4)

Dynamic Host Configuration ProtocolバージョンFourのためのノード特有のクライアント識別子(DHCPv4)

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

要約

   This document specifies the format that is to be used for encoding
   Dynamic Host Configuration Protocol Version Four (DHCPv4) client
   identifiers, so that those identifiers will be interchangeable with
   identifiers used in the DHCPv6 protocol.  This document also
   addresses and corrects some problems in RFC 2131 and RFC 2132 with
   respect to the handling of DHCP client identifiers.

このドキュメントはDynamic Host Configuration ProtocolバージョンFour(DHCPv4)クライアント識別子をコード化するのに使用されることになっている形式を指定します、識別子がDHCPv6プロトコルに使用されている状態でそれらの識別子が交換可能になるように。 また、このドキュメントは、DHCPクライアント識別子の取り扱いに関してRFC2131とRFC2132のいくつかの問題を扱って、修正します。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Applicability ...................................................2
   4. Problem Statement ...............................................3
      4.1. Client identities are ephemeral. ...........................3
      4.2. Clients can accidentally present multiple identities. ......3
      4.3. RFC 2131/2132 and RFC 3315 identifiers are incompatible. ...4
      4.4. RFC 2131 does not require the use of a client identifier. ..4
   5. Requirements ....................................................4
   6. Implementation ..................................................6
      6.1. DHCPv4 Client Behavior .....................................6
      6.2. DHCPv6 Client Behavior .....................................7
      6.3. DHCPv4 Server Behavior .....................................7
      6.4. Changes from RFC 2131 ......................................8
      6.5. Changes from RFC 2132 ......................................9

1. 序論…2 2. 用語…2 3. 適用性…2 4. 問題声明…3 4.1. クライアントのアイデンティティははかないです。 ...........................3 4.2. クライアントは偶然複数のアイデンティティを提示できます。 ......3 4.3. RFC2131/2132とRFC3315識別子は両立しないです。 ...4 4.4. RFC2131はクライアント識別子の使用を必要としません。 ..4 5. 要件…4 6. 実装…6 6.1. DHCPv4クライアントの振舞い…6 6.2. DHCPv6クライアントの振舞い…7 6.3. DHCPv4サーバの振舞い…7 6.4. RFC2131からの変化…8 6.5. RFC2132からの変化…9

Lemon & Sommerfield         Standards Track                     [Page 1]

RFC 4361          Node-specific Identifiers for DHCPv4     February 2006

DHCPv4 February 2006のためのレモンとソマーフィールド標準化過程[1ページ]RFC4361のノード特有の識別子

   7. Notes on DHCP Clients in Multi-stage Network Booting ............9
   8. Security Considerations ........................................10
   9. References .....................................................10
      9.1. Normative References ......................................10
      9.2. Informative References ....................................10

7. マルチ段階のDHCPクライアントに関する注は穂ばらみをネットワークでつなぎます…9 8. セキュリティ問題…10 9. 参照…10 9.1. 標準の参照…10 9.2. 有益な参照…10

1.  Introduction

1. 序論

   This document specifies the way in which Dynamic Host Configuration
   Protocol Version 4 [RFC2131] clients should identify themselves.
   DHCPv4 client implementations that conform to this specification use
   a DHCP Unique Identifier (DUID) as specified in Dynamic Host
   Configuration Protocol for IPv6 (DHCPv6) [RFC3315].  The DUID is
   encapsulated in a DHCPv4 client identifier option, as described in
   "DHCP Options and BOOTP Vendor Extensions" [RFC2132].  The behaviour
   described here supersedes the behavior specified in RFC2131 and
   RFC2132.

このドキュメントはDynamic Host Configuration Protocolバージョン4[RFC2131]クライアントが身元を明らかにするべきである方法を指定します。 この仕様に従うDHCPv4クライアント実装はIPv6(DHCPv6)[RFC3315]に、Dynamic Host Configuration Protocolにおける指定されるとしてのDHCP Unique Identifier(DUID)を使用します。 DUIDは「DHCPオプションとBOOTPベンダー拡張子」[RFC2132]で説明されるようにDHCPv4クライアント識別子オプションでカプセル化されます。 ここで説明されたふるまいはRFC2131とRFC2132で指定された振舞いに取って代わります。

   The reason for making this change is that as we make the transition
   from IPv4 to IPv6, there will be network devices that must use both
   DHCPv4 and DHCPv6.  Users of these devices will have a smoother
   network experience if the devices identify themselves consistently,
   regardless of the version of DHCP they are using at any given moment.
   Most obviously, DNS updates made by the DHCP server on behalf of the
   client will be handled more correctly.  This change also addresses
   certain limitations in the functioning of RFC 2131/2132-style DHCP
   client identifiers.

この変更を行う理由は私たちがIPv4からIPv6までの変遷をするのでDHCPv4とDHCPv6の両方を使用しなければならないネットワークデバイスがあるということです。 これらのデバイスのユーザには、デバイスが一貫して自分たちを特定すると、より滑らかなネットワーク経験があって、DHCPのバージョンにかかわらずそれらはいつなんどきでも使用しています。 最も明らかに、DHCPサーバによってクライアントを代表してされたDNSアップデートは、より正しく扱われるでしょう。 また、この変化は2131/2132スタイルのRFC DHCPクライアント識別子の機能における、ある制限を扱います。

   This document first describes the problem to be solved.  It then
   states the new technique that is to be used to solve the problem.
   Finally, it describes the specific changes that one would have to
   make to RFC 2131 and RFC 2132 in order for those documents not to
   contradict what is described in this document.

このドキュメントは最初に、解決すべき課題について説明します。 そして、それは問題を解決するのに使用されることになっている新しいやり方を述べます。 最終的に、それらのドキュメントが本書では説明されることに矛盾しないように、それは1つがRFC2131とRFC2132にしなければならない特定の変更について説明します。

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 RFC 2119 [RFC2119].

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

3.  Applicability

3. 適用性

   This document updates RFC 2131 and RFC 2132.  This document also
   specifies behavior that is required of DHCPv4 and DHCPv6 clients that
   are intended to operate in a dual-stack configuration.  Finally, this
   document recommends behavior for host configurations where more than
   one DHCP client must operate in sequence in order to fully configure

このドキュメントはRFC2131とRFC2132をアップデートします。 また、このドキュメントはDHCPv4が要求される振舞いとデュアルスタック構成で作動することを意図するDHCPv6クライアントを指定します。 1人以上のDHCPクライアントが連続して働かなければならないところで最終的に、このドキュメントがホスト構成のための振舞いを推薦する、完全に構成します。

Lemon & Sommerfield         Standards Track                     [Page 2]

RFC 4361          Node-specific Identifiers for DHCPv4     February 2006

DHCPv4 February 2006のためのレモンとソマーフィールド標準化過程[2ページ]RFC4361のノード特有の識別子

   the client (e.g., a network boot loader and the operating system it
   loads).

クライアント(例えば、ネットワークブーツ荷物を積む人とそれが積み込むオペレーティングシステム)。

   DHCPv4 clients and servers that are implemented according to this
   document should be implemented as if the changes specified in
   sections 6.3 and 6.4 have been made to RFC 2131 and RFC 2132.  DHCPv4
   clients should, in addition, follow the behavior specified in section
   6.1.  DHCPv6 clients should follow the behavior specified in section
   6.2.  DHCPv4 servers should additionally follow the behavior
   specified in section 6.3.

このドキュメントによると、実装されるDHCPv4クライアントとサーバはまるでセクション6.3と6.4で指定された変更をRFC2131とRFC2132にしたかのように実装されるべきです。 DHCPv4クライアントはさらに、セクション6.1で指定された振舞いの後をつけるべきです。 DHCPv6クライアントはセクション6.2で指定された振舞いの後をつけるべきです。 DHCPv4サーバはさらに、セクション6.3で指定された振舞いに続くべきです。

4.  Problem Statement

4. 問題声明

4.1.  Client identities are ephemeral.

4.1. クライアントのアイデンティティははかないです。

   RFC 2132 recommends that client identifiers be generated by using the
   permanent link-layer address of the network interface that the client
   is trying to configure.  One result of this recommendation is that
   when the network interface hardware on a client computer is replaced,
   the identity of the client changes.  The client loses its IP address
   and any other resources associated with its old identifier (for
   example, its domain name as published through the DHCPv4 server).

RFC2132は、クライアント識別子がクライアントが構成しようとしているネットワーク・インターフェースの永久的なリンクレイヤアドレスを使用することによって生成されることを勧めます。 クライアントコンピュータの上のネットワーク・インターフェースハードウェアを取り替えるとき、この推薦の1つの結果がそれです、クライアント変化のアイデンティティ。 クライアントは古い識別子(例えばDHCPv4サーバを通して発行されるドメイン名)に関連しているIPアドレスといかなる他のリソースも失います。

4.2.  Clients can accidentally present multiple identities.

4.2. クライアントは偶然複数のアイデンティティを提示できます。

   Consider a DHCPv4 client that has two network interfaces, one of
   which is wired and one of which is wireless.  The DHCPv4 client will
   succeed in configuring either zero, one, or two network interfaces.
   Under the current specification, each network interface will receive
   a different IP address.  The DHCPv4 server will treat each network
   interface as a completely independent DHCPv4 client, on a completely
   independent host.

それの1つがワイヤードであり、それの1つがワイヤレスである2つのネットワーク・インターフェースを持っているDHCPv4クライアントを考えてください。 DHCPv4クライアントは、ゼロ、1、または2つのネットワーク・インターフェースを構成するのに成功するでしょう。 現在の仕様では、各ネットワーク・インターフェースは異なったIPアドレスを受け取るでしょう。 DHCPv4サーバは完全に独立しているホストの上で完全に独立しているDHCPv4クライアントとして各ネットワーク・インターフェースを扱うでしょう。

   Thus, when the client presents some information to be updated in a
   network directory service, such as the DNS, the name that is
   presented will be the same on both interfaces, but the identity that
   is presented will be different.  What will happen is that one of the
   two interfaces will get the name, and will retain that name as long
   as it has a valid lease, even if it loses its connection to the
   network, while the other network interface will never get the name.
   In some cases, this will achieve the desired result; when only one
   network interface is connected, sometimes its IP address will be
   published.  In some cases, the one connected interface's IP address
   will not be the one that is published.  When there are two
   interfaces, sometimes the correct one will be published, and
   sometimes not.

クライアントがDNSなどのネットワークディレクトリサービスでアップデートするために何らかの情報を提示するとき、したがって、提示される名前は両方のインタフェースで同じになるでしょうが、提示されるアイデンティティは異なるでしょう。 起こることは2つのインタフェースの1つが名前を得て、それに有効なリースがある限り、その名前を保有するということです、ネットワークに接続を失っても、もう片方のネットワーク・インターフェースは名前を決して得ないでしょうが。 いくつかの場合、これは必要な結果を獲得するでしょう。 1つのネットワーク・インターフェースだけが接続されているとき、時々、IPアドレスは発表されるでしょう。 いくつかの場合、1つの接続インタフェースのIPアドレスは発行されるものにならないでしょう。 2つのインタフェースがあるとき、正しい方は、時々、発行されて、時々そうしていないでしょう。

Lemon & Sommerfield         Standards Track                     [Page 3]

RFC 4361          Node-specific Identifiers for DHCPv4     February 2006

DHCPv4 February 2006のためのレモンとソマーフィールド標準化過程[3ページ]RFC4361のノード特有の識別子

   This is likely to be a particular problem with modern laptops, which
   usually have built-in wireless ethernet and wired ethernet.  When the
   user is near a wired outlet, he or she may want the additional speed
   and privacy provided by a wired connection, but that same user may
   unplug from the wired network and wander around, still connected to
   the wireless network.  When a transition like this happens, under the
   current scheme, if the address of the wired interface is the one that
   gets published, this client will be seen by hosts attempting to
   connect to it as if it has intermittent connectivity, even though it
   actually has continuous network connectivity through the wireless
   port.

これは現代のラップトップに関する特定の問題である傾向があります。(通常、ラップトップには、内蔵のワイヤレスのイーサネットとワイヤードなイーサネットがあります)。 ユーザがワイヤードなアウトレットの近くにいるとき、その人がワイヤードな接続に追加速度とプライバシーを提供して欲しいかもしれませんが、その同じユーザは、有線ネットワークからプラグを抜いて、ぶらつくかもしれません、まだワイヤレス・ネットワークに関連しています。 このような変遷が現在の体系の下で起こると、このクライアントはワイヤードなインタフェースのアドレスが発行されるものであるなら、まるでそれには間欠接続性があるかのようにそれに接続するのを試みるホストによって会われるでしょう、実際にワイヤレスのポートを通して連続したネットワークの接続性を持っていますが。

   Another common case of a duplicate identity being presented occurs
   when a boot monitor such as a Pre-Boot Execution Environment (PXE)
   loader specifies one DHCP client identifier, and then the operating
   system loaded by the boot loader specifies a different identity.

Pre-ブーツExecution Environment(PXE)荷物を積む人などのブーツモニターが1つのDHCPクライアント識別子を指定するとき、提示される写しのアイデンティティの別のよくある例は現れます、そして、次に、ブーツ荷物を積む人によってロードされたオペレーティングシステムは異なったアイデンティティを指定します。

4.3.  RFC 2131/2132 and RFC 3315 identifiers are incompatible.

4.3. RFC2131/2132とRFC3315識別子は両立しないです。

   The 'client identifier' option is used by DHCPv4 clients and servers
   to identify clients.  In some cases, the value of the 'client
   identifier' option is used to mediate access to resources (for
   example, the client's domain name, as published through the DHCPv4
   server).  RFC 2132 and RFC 3315 specify different methods for
   deriving client identifiers.  These methods guarantee that the DHCPv4
   and DHCPv6 identifiers will be different.  This means that mediation
   of access to resources using these identifiers will not work
   correctly in cases where a node may be configured using DHCPv4 in
   some cases and DHCPv6 in other cases.

'クライアント識別子'オプションはDHCPv4クライアントとサーバによって使用されて、クライアントを特定します。 いくつかの場合、'クライアント識別子'オプションの値がリソースへのアクセスを調停するのに使用される、(例えば、DHCPv4サーバを通して発行されるようなクライアントのドメイン名 RFC2132とRFC3315はクライアント識別子を引き出すための異なったメソッドを指定します。 これらのメソッドは、DHCPv4とDHCPv6識別子が異なるのを保証します。 これは、これらの識別子を使用するリソースへのアクセスの仲介がノードがいくつかの場合、DHCPv4を使用することで構成されるかもしれないケースとDHCPv6で他の場合で正しく働かないことを意味します。

4.4.  RFC 2131 does not require the use of a client identifier.

4.4. RFC2131はクライアント識別子の使用を必要としません。

   RFC 2131 allows the DHCPv4 server to identify clients either by using
   the client identifier option sent by the client or, if the client did
   not send one, the client's link-layer address.  Like the client
   identifier format recommended by RFC 2131, this suffers from the
   problems previously described in sections 4.2 and 4.3.

RFC2131は、どんなクライアントによって送られたクライアント識別子オプションもクライアントが1つを送らなかったときのクライアントのリンクレイヤアドレスも使用しないことでクライアントの身元を確認するためにDHCPv4サーバを許容します。 RFC2131によって推薦されたクライアント識別子書式のように、これは以前にセクション4.2と4.3で説明された問題に苦しみます。

5.  Requirements

5. 要件

   In order to address the problems stated in section 4, DHCPv4 client
   identifiers must have the following characteristics:

セクション4で述べられたその問題を訴えるために、DHCPv4クライアント識別子には、以下の特性がなければなりません:

   - They must be persistent, in the sense that a particular host's
     client identifier must not change simply because a piece of network
     hardware is added or removed.

- それらは永続的であるに違いありません、単に、1個のネットワークハードウェアが加えられるか、または取り外されるので特定のホストのクライアント識別子が変化してはいけないという意味で。

Lemon & Sommerfield         Standards Track                     [Page 4]

RFC 4361          Node-specific Identifiers for DHCPv4     February 2006

DHCPv4 February 2006のためのレモンとソマーフィールド標準化過程[4ページ]RFC4361のノード特有の識別子

   - It must be possible for the client to represent itself as having
     more than one network identity, for example, so that a client with
     two network interfaces can express to the DHCPv4 server that these
     two network interfaces are to receive different IP addresses, even
     if they happen to be connected to the same link.

- 例えば2つのネットワーク・インターフェースをもっているクライアントが、これらの2つのネットワーク・インターフェースが異なったIPアドレスを受け取ることになっているとDHCPv4サーバに言い表すことができるように1つ以上のネットワークのアイデンティティを持っている称するクライアントにとって、それは可能であるに違いありません、たまたま同じリンクに接続されてもさえ。

   - In cases where the DHCPv4 client is expressing more than one
     network identity at the same time, it must nevertheless be possible
     for the DHCPv4 server to determine that the two network identities
     belong to the same host.

- DHCPv4クライアントが同時に1つ以上のネットワークのアイデンティティを言い表す場合では、それにもかかわらず、DHCPv4サーバが、2つのネットワークのアイデンティティが同じホストのものであることを決定するのは、可能であるに違いありません。

   - In some cases it may be desirable for a DHCP client to present the
     same identity on two interfaces, so that if they both happen to be
     connected to the same network, they will both receive the same IP
     address.  In such cases, it must be possible for the client to use
     exactly the same identifier for each interface.

- いくつかの場合、DHCPクライアントが2つのインタフェースに同じアイデンティティを提示するのは、望ましいかもしれません、それらの両方がたまたま同じネットワークに関すると、彼らがともに同じIPアドレスを受け取るように。 そのような場合、クライアントが各インタフェースにまさに同じ識別子を使用するのは、可能でなければなりません。

   - DHCPv4 servers that do not conform to this specification, but that
     are compliant with the older client identifier specification, must
     correctly handle client identifiers sent by clients that conform to
     this specification.

- 従っていませんが、より古いクライアント識別子仕様でこの仕様に対応であるDHCPv4サーバは正しくこの仕様に従うクライアントによって送られたクライアント識別子を扱わなければなりません。

   - DHCPv4 servers that do conform to this specification must
     interoperate correctly with DHCPv4 clients that do not conform to
     this specification, except that when configuring such clients,
     behaviors such as those described in section 2 may occur.

- この仕様に従うDHCPv4サーバはこの仕様に従わないDHCPv4クライアントと共に正しく共同利用しなければなりません、そのようなクライアントを構成するとき、セクション2で説明されたものなどの振舞いが起こるかもしれないのを除いて。

   - The use by DHCPv4 clients of the chaddr field of the DHCPv4 packet
     as an identifier must be deprecated.

- 識別子としてのDHCPv4パケットのchaddr分野のDHCPv4クライアントによる使用は推奨しないに違いありません。

   - DHCPv4 client identifiers used by dual-stack hosts that also use
     DHCPv6 must use the same host identification string for both DHCPv4
     and DHCPv6.  For example, a DHCPv4 server that uses the client's
     identity to update the DNS on behalf of a DHCPv4 client must
     register the same client identity in the DNS that would be
     registered by the DHCPv6 server on behalf of the DHCPv6 client
     running on that host, and vice versa.

- また、DHCPv6を使用するデュアルスタックホストによって使用されたDHCPv4クライアント識別子はDHCPv4とDHCPv6の両方に同じホスト識別ストリングを使用しなければなりません。 例えば、DHCPv4クライアントを代表してDNSをアップデートするのにクライアントのアイデンティティを使用するDHCPv4サーバはそのホストで走りながら、DHCPv6サーバによってDHCPv6クライアントを代表して登録されるDNSに同じクライアントのアイデンティティを示さなければなりません、逆もまた同様に。

   In order to satisfy all but the last of these requirements, we need
   to construct a DHCPv4 client identifier out of two parts.  One part
   must be unique to the host on which the client is running.  The other
   must be unique to the network identity being presented.  The DHCP
   Unique Identifier (DUID) and Identity Association Identifier (IAID)
   specified in RFC 3315 satisfy these requirements.

これらの要件の最終以外のすべてを満たすために、私たちは、2つの部品からDHCPv4クライアント識別子を構成する必要があります。 一部がクライアントが走っているホストにユニークであるに違いありません。 もう片方が提示されるネットワークのアイデンティティにユニークであるに違いありません。 RFC3315で指定されたDHCP Unique Identifier(DUID)とIdentity Association Identifier(IAID)はこれらの要件を満たします。

Lemon & Sommerfield         Standards Track                     [Page 5]

RFC 4361          Node-specific Identifiers for DHCPv4     February 2006

DHCPv4 February 2006のためのレモンとソマーフィールド標準化過程[5ページ]RFC4361のノード特有の識別子

   In order to satisfy the last requirement, we must use the DUID to
   identify the DHCPv4 client.  So, taking all the requirements
   together, the DUID and IAID described in RFC 3315 are the only
   possible solution.

最後の要件を満たして、私たちは、DHCPv4クライアントを特定するのにDUIDを使用しなければなりません。 それで、RFC3315で説明されたすべての要件を一緒に取る、DUID、およびIAIDは唯一の可能なソリューションです。

   By following these rules, a compliant DHCPv4 client will interoperate
   correctly with both compliant and non-compliant DHCPv4 servers.  A
   non-compliant DHCPv4 client will also interoperate correctly with a
   compliant DHCPv4 server.  If either server or client is not
   compliant, the goals stated in the document are not met, but there is
   no loss of functionality.

これらの規則に従うことで、言いなりになっているDHCPv4クライアントは言いなりになっているものと同様に不従順なDHCPv4サーバで正しく共同利用するでしょう。 また、不従順なDHCPv4クライアントは対応するDHCPv4サーバで正しく共同利用するでしょう。サーバかクライアントのどちらかが対応でないなら、目標は、ドキュメントに会われませんが、機能性の損失が全くないと述べました。

6.  Implementation

6. 実装

   Here we specify changes to the behavior of DHCPv4 clients and
   servers.  We also specify changes to the wording in RFC 2131 and RFC
   2132.  DHCPv4 clients, servers, and relay agents that conform to this
   specification must implement RFC 2131 and RFC 2132 with the wording
   changes specified in sections 6.3 and 6.4.

ここで、私たちはDHCPv4クライアントとサーバの働きへの変化を指定します。 また、私たちはRFC2131とRFC2132の言葉遣いへの変化を指定します。 言葉遣い変化がセクション6.3と6.4で指定されている状態で、この仕様に従うDHCPv4クライアント、サーバ、および中継エージェントは、RFC2131とRFCが2132であると実装しなければなりません。

6.1.  DHCPv4 Client Behavior

6.1. DHCPv4クライアントの振舞い

   DHCPv4 clients conforming to this specification MUST use stable
   DHCPv4 node identifiers in the dhcp-client-identifier option.  DHCPv4
   clients MUST NOT use client identifiers based solely on layer two
   addresses that are hard-wired to the layer two device (e.g., the
   ethernet MAC address) as suggested in RFC 2131, except as allowed in
   section 9.2 of RFC 3315.  DHCPv4 clients MUST send a 'client
   identifier' option containing an Identity Association Unique
   Identifier, as defined in section 10 of RFC 3315, and a DHCP Unique
   Identifier, as defined in section 9 of RFC 3315.  These together
   constitute an RFC 3315-style binding identifier.

この仕様に従うDHCPv4クライアントはdhcpクライアント識別子オプションに安定したDHCPv4ノード識別子を使用しなければなりません。 DHCPv4クライアントは唯一RFC2131に示されるように層twoのデバイス(例えば、イーサネットMACアドレス)に配線される層twoのアドレスに基づくクライアント識別子を使用してはいけません、RFC3315のセクション9.2に許容されているのを除いて。 DHCPv4クライアントはIdentity Association Unique Identifierを含む'クライアント識別子'オプションを送らなければなりません、RFC3315のセクション10、およびDHCP Unique Identifierで定義されるように、RFC3315のセクション9で定義されるように。 これら、一緒にいる、3315スタイルのRFCの拘束力がある識別子を構成してください。

   The general format of the DHCPv4 'client identifier' option is
   defined in section 9.14 of RFC 2132.

DHCPv4'クライアント識別子'オプションの一般形式はRFC2132のセクション9.14で定義されます。

   To send an RFC 3315-style binding identifier in a DHCPv4 'client
   identifier' option, the type of the 'client identifier' option is set
   to 255.  The type field is immediately followed by the IAID, which is
   an opaque 32-bit quantity.  The IAID is immediately followed by the
   DUID, which consumes the remaining contents of the 'client
   identifier' option.  The format of the 'client identifier' option is
   as follows:

DHCPv4'クライアント識別子'オプションにおける3315スタイルのRFCの拘束力がある識別子を送るために、'クライアント識別子'オプションのタイプは255に用意ができています。 タイプ野原はすぐに、IAIDによって続かれています。(IAIDは不透明な32ビットの量です)。 IAIDはすぐに、DUIDによって続かれています。(DUIDは'クライアント識別子'オプションの残っているコンテンツを消費します)。 'クライアント識別子'オプションの形式は以下の通りです:

       Code  Len  Type  IAID                DUID
       +----+----+-----+----+----+----+----+----+----+---
       | 61 | n  | 255 | i1 | i2 | i3 | i4 | d1 | d2 |...
       +----+----+-----+----+----+----+----+----+----+---

コードレンタイプIAID DUID+----+----+-----+----+----+----+----+----+----+--- | 61 | n| 255 | i1| i2| i3| i4| d1| d2|... +----+----+-----+----+----+----+----+----+----+---

Lemon & Sommerfield         Standards Track                     [Page 6]

RFC 4361          Node-specific Identifiers for DHCPv4     February 2006

DHCPv4 February 2006のためのレモンとソマーフィールド標準化過程[6ページ]RFC4361のノード特有の識別子

   Any DHCPv4 client that conforms to this specification SHOULD provide
   a means by which an operator can learn what DUID the client has
   chosen.  Such clients SHOULD also provide a means by which the
   operator can configure the DUID.  A device that is normally
   configured by both a DHCPv4 and DHCPv6 client SHOULD automatically
   use the same DUID for DHCPv4 and DHCPv6 without any operator
   intervention.

SHOULDがオペレータがクライアントのDUIDが選んだことを学ぶことができる手段を提供するこの仕様に従うどんなDHCPv4クライアント。 また、そのようなクライアントSHOULDはオペレータがDUIDを構成できる手段を提供します。 通常、DHCPv4とDHCPv6クライアントSHOULDの両方によって自動的に構成されるデバイスはDHCPv4とDHCPv6に少しもオペレータ介入なしで同じDUIDを使用します。

   DHCPv4 clients that support more than one network interface SHOULD
   use the same DUID on every interface.  DHCPv4 clients that support
   more than one network interface SHOULD use a different IAID on each
   interface.

1つ以上のネットワーク・インターフェースがSHOULDであるとサポートするDHCPv4クライアントがあらゆるインタフェースの同じDUIDを使用します。 1つ以上のネットワーク・インターフェースがSHOULDであるとサポートするDHCPv4クライアントが各インタフェースの異なったIAIDを使用します。

   A DHCPv4 client that generates a DUID and that has stable storage
   MUST retain this DUID for use in subsequent DHCPv4 messages, even
   after an operating system reboot.

DUIDを生成して、安定貯蔵を持っているDHCPv4クライアントはその後のDHCPv4メッセージにおける使用のためのこのDUIDを保有しなければなりません、オペレーティングシステムリブートの後にさえ。

6.2.  DHCPv6 Client Behavior

6.2. DHCPv6クライアントの振舞い

   Any DHCPv6 client that conforms to this specification SHOULD provide
   a means by which an operator can learn what DUID the client has
   chosen.  Such clients SHOULD also provide a means by which the
   operator can configure the DUID.  A device that is normally
   configured by both a DHCPv4 and DHCPv6 client SHOULD automatically
   use the same DUID for DHCPv4 and DHCPv6 without any operator
   intervention.

SHOULDがオペレータがクライアントのDUIDが選んだことを学ぶことができる手段を提供するこの仕様に従うどんなDHCPv6クライアント。 また、そのようなクライアントSHOULDはオペレータがDUIDを構成できる手段を提供します。 通常、DHCPv4とDHCPv6クライアントSHOULDの両方によって自動的に構成されるデバイスはDHCPv4とDHCPv6に少しもオペレータ介入なしで同じDUIDを使用します。

6.3.  DHCPv4 Server Behavior

6.3. DHCPv4サーバの振舞い

   This document does not require any change to DHCPv4 or DHCPv6 servers
   that follow RFC 2131 and RFC 2132.  However, some DHCPv4 servers can
   be configured not to conform to RFC 2131 and RFC 2132, in the sense
   that they ignore the 'client identifier' option and use the client's
   hardware address instead.

このドキュメントはRFC2131とRFC2132に続いて起こるDHCPv4へのどんな変化かDHCPv6サーバも必要としません。 しかしながら、RFC2131とRFC2132に従わないようにいくつかのDHCPv4サーバを構成できます、'クライアント識別子'オプションを無視して、代わりにクライアントのハードウェア・アドレスを使用するという意味で。

   DHCPv4 servers that conform to this specification MUST use the
   'client identifier' option to identify the client if the client sends
   it.

クライアントがそれを送るなら、この仕様に従うDHCPv4サーバは、クライアントを特定するのに'クライアント識別子'オプションを使用しなければなりません。

   DHCPv4 servers MAY use administrator-supplied values for chaddr and
   htype to identify the client in the case where the administrator is
   assigning a fixed IP address to the client, even if the client sends
   a client identifier option.  This is ONLY permitted in the case where
   the DHCPv4 server administrator has provided the values for chaddr
   and htype, because in this case if it causes a problem, the
   administrator can correct the problem by removing the offending
   configuration information.

chaddrとhtypeが管理者が固定IPアドレスをクライアントに割り当てている場合でクライアントを特定するのにDHCPv4サーバは管理者供給値を使用するかもしれません、クライアントがクライアント識別子オプションを送っても。 これはDHCPv4サーバアドミニストレータがchaddrとhtypeに値を供給した場合で受入れられるだけです、問題を引き起こすなら、管理者がこの場合怒っている設定情報を取り除くことによって問題を修正できるので。

Lemon & Sommerfield         Standards Track                     [Page 7]

RFC 4361          Node-specific Identifiers for DHCPv4     February 2006

DHCPv4 February 2006のためのレモンとソマーフィールド標準化過程[7ページ]RFC4361のノード特有の識別子

6.4.  Changes from RFC 2131

6.4. RFC2131からの変化

   In section 2 of RFC 2131, on page 9, the text that reads "; for
   example, the 'client identifier' may contain a hardware address,
   identical to the contents of the 'chaddr' field, or it may contain
   another type of identifier, such as a DNS name" is deleted.

「9ページ、読むテキストのRFC2131のセクション2」。 「例えば、'クライアント識別子'はハードウェア・アドレスを含むかもしれません、'chaddr'分野のコンテンツと同じであるか、または別のタイプに関する識別子を含むかもしれません、DNS名のように」。削除されます。

   In section 4.2 of RFC 2131, the text "The client MAY choose to
   explicitly provide the identifier through the 'client identifier'
   option.  If the client supplies a 'client identifier', the client
   MUST use the same 'client identifier' in all subsequent messages, and
   the server MUST use that identifier to identify the client.  If the
   client does not provide a 'client identifier' option, the server MUST
   use the contents of the 'chaddr' field to identify the client." is
   replaced by the text "The client MUST explicitly provide a client
   identifier through the 'client identifier' option.  The client MUST
   use the same 'client identifier' option for all messages."

「クライアントは、'クライアント識別子'オプションで明らかに識別子を提供するのを選ぶかもしれない」というRFC2131、テキストのセクション4.2で。 クライアントが'クライアント識別子'を供給するなら、クライアントはすべてのその後のメッセージの同じ'クライアント識別子'を使用しなければなりません、そして、サーバはクライアントを特定するのにその識別子を使用しなければなりません。 「クライアントが'クライアント識別子'オプションを提供しないなら、サーバはクライアントを特定するのに'chaddr'分野のコンテンツを使用しなければなりません」。. 「クライアントは'クライアント識別子'オプションで明らかにクライアント識別子を提供しなければならない」テキストに取り替えます。 「クライアントはすべてのメッセージに同じ'クライアント識別子'オプションを使用しなければなりません。」

   In the same section, the text "Use of 'chaddr' as the client's unique
   identifier may cause unexpected results, as that identifier may be
   associated with a hardware interface that could be moved to a new
   client.  Some sites may choose to use a manufacturer's serial number
   as the 'client identifier', to avoid unexpected changes in a client's
   network address due to transfer of hardware interfaces among
   computers.  Sites may also choose to use a DNS name as the 'client
   identifier', causing address leases to be associated with the DNS
   name rather than a specific hardware box." is replaced by the text
   "The DHCP client MUST NOT rely on the 'chaddr' field to identify it."

同じセクション、「その識別子が新しいクライアントに動かすことができたハードウェア・インタフェースに関連しているとき、クライアントのユニークな識別子としての'chaddr'の使用は予期しなかった結果を引き起こすかもしれない」テキストで。 いくつかのサイトが、'クライアント識別子'として製造番号を使用して、ハードウェア・インタフェースの転送のためコンピュータの中でクライアントのネットワーク・アドレスの意外な変化を避けるのを選ぶかもしれません。 「また、サイトは、'クライアント識別子'としてDNS名を使用するのを選ぶかもしれません、アドレスリースが特定のハードウェア箱よりむしろDNS名に関連していることを引き起こして」。. テキスト「DHCPクライアントはそれを特定するために'chaddr'分野を当てにしてはいけない」と取り替えます。

   In section 4.4.1 of RFC 2131, the text "The client MAY include a
   different unique identifier" is replaced with "The client MUST
   include a unique identifier".

.1セクション4.4RFC2131では、テキスト「クライアントは異なったユニークな識別子を入れるかもしれないこと」を「クライアントはユニークな識別子を入れなければならない」と取り替えます。

   In section 3.1, items 4 and 6; section 3.2 item 3 and 4; and section
   4.3.1, where RFC 2131 says that 'chaddr' may be used instead of the
   'client identifier' option, the text "or 'chaddr'" and "'chaddr' or"
   is deleted.

セクション3.1、項目4と6で。 セクション3.2の品目3と4。 または、そして、.1か、RFC2131が、どこで'chaddr'が'クライアント識別子'オプション、テキストの代わりに使用されるかもしれないと言うか「'chaddr'」というセクション4.3と「'chaddr'、」 削除されます。

   Note that these changes do not relieve the DHCPv4 server of the
   obligation to use 'chaddr' as an identifier if the client does not
   send a 'client identifier' option.  Rather, they oblige clients that
   conform with this document to send a 'client identifier' option, and
   not rely on 'chaddr' for identification.  DHCPv4 servers MUST use
   'chaddr' as an identifier in cases where 'client identifier' is not
   sent, in order to support old clients that do not conform with this
   document.

クライアントが'クライアント識別子'オプションを送らないならこれらの変化が識別子として'chaddr'を使用する義務をDHCPv4サーバに取り除かないことに注意してください。 むしろ、彼らは、このドキュメントに従うクライアントが'クライアント識別子'オプションを送って、識別のために'chaddr'を当てにしないのを強います。 DHCPv4サーバは'クライアント識別子'が送られないケースの中の識別子として'chaddr'を使用しなければなりません、このドキュメントに従わない年取ったクライアントをサポートするために。

Lemon & Sommerfield         Standards Track                     [Page 8]

RFC 4361          Node-specific Identifiers for DHCPv4     February 2006

DHCPv4 February 2006のためのレモンとソマーフィールド標準化過程[8ページ]RFC4361のノード特有の識別子

6.5.  Changes from RFC 2132

6.5. RFC2132からの変化

   The text in section 9.14, beginning with "The client identifier MAY
   consist of" through "that meet this requirement for uniqueness." is
   replaced with "the client identifier consists of a type field whose
   value is normally 255, followed by a four-byte IA_ID field, followed
   by the DUID for the client as defined in RFC 3315, section 9."  The
   text "its minimum length is 2" in the following paragraph is deleted.

「識別子が成るかもしれないクライアント」と共に始まって、テキストは「それはユニークさのためのこの必要条件を満たすこと」を通して中で9.14を区分します。. 「クライアント識別子は通常クライアントのためにRFC3315で定義されるようにDUIDによって続かれた4バイトのアイオワ_ID野原が値をいうことになった255であるタイプ分野から成ります、セクション9」に取り替えます。 テキスト、「最小の長さは以下のパラグラフの2インチが削除されるということです」。

7.  Notes on DHCP Clients in Multi-stage Network Booting

7. マルチステージネットワーク起動におけるDHCPクライアントに関する注

   In some cases a single device may actually run more than one DHCP
   client in sequence, in the process of loading an operating system
   over the network.  In such cases, it may be that the first-stage boot
   uses a different client identifier, or no client identifier, than the
   subsequent stage or stages.

いくつかの場合、単一のデバイスは実際に連続して1人以上のDHCPクライアントを車で送るかもしれません、ネットワークの上でオペレーティングシステムをロードすることの途中に。 異なったクライアント識別子を使用しますが、そのような場合、そして、多分、第一段階ブーツはどんなクライアント識別子も使用しません、その後のステージかステージより。

   The effect of this, under the DHCPv4 protocol, is that the two (in
   some cases more than two!) boot stages will present different
   identities.  A DHCPv4 server will therefore allocate two different IP
   addresses to the two different boot stages.

この効果はDHCPv4プロトコルの下で2回(いくつかの場合2以上!)の穂孕み期が異なったアイデンティティを提示するということです。 したがって、DHCPv4サーバは2回の異なった穂孕み期まで2つの異なったIPアドレスを割り当てるでしょう。

   Some DHCP servers work around this problem for the common case where
   the boot Programmable Read Only Memory (PROM) presents no client
   identifier, and the operating system DHCP client presents a client
   identifier constructed from the Message Authentication Code (MAC)
   address of the network interface -- both are treated as the same
   identifier.  This prevents the consumption of an extra IP address.

オペレーティングシステムDHCPクライアントはネットワーク・インターフェースのメッセージ立証コード(MAC)アドレスから構成されたクライアント識別子を提示します--いくつかのDHCPサーバにブーツProgrammable Read Only Memory(PROM)がクライアント識別子を全く提示しないよくある例のためにこの問題の周りで取り組みます、そして、ともに同じ識別子として扱われます。 これは付加的なIPアドレスの消費を防ぎます。

   A compliant DHCPv4 client does not use a client identifier
   constructed from the MAC address of the network interface, because
   network interfaces are not stable.  So a compliant DHCPv4 client
   cannot be supported by a simple hack like the one described
   previously; this may have some significant impact at some sites.

言いなりになっているDHCPv4クライアントはネットワーク・インターフェースのMACアドレスから構成されたクライアント識別子を使用しません、ネットワーク・インターフェースが安定していないので。 それで、以前に説明されたもののような純真なハッキングは言いなりになっているDHCPv4クライアントをサポートすることができません。 これはいくつかのサイトで何らかの重要な影響を与えるかもしれません。

   We cannot state the solution to this problem as a set of
   requirements, because the circumstances in which this occurs vary too
   widely.  However, we can make some suggestions.

私たちは1セットの要件としてこの問題にソリューションを述べることができません、これが起こる事情がまた、ばらつきが大きいので。 しかしながら、私たちはいくつかの提案をすることができます。

   First, we suggest that DHCP clients in network boot loaders request
   short lease times, so that their IP addresses are not retained.  Such
   clients should send a DHCPRELEASE message to the DHCP server before
   moving on to the next stage of the boot process.  Such clients should
   provide a way for the operating system DHCP client to configure a
   DUID to use in subsequent boots.  DHCP clients in the final stage
   should, where possible, configure the DUID used by the boot PROM to
   be the same as the DUID used by the operating system.

まず最初に、私たちは、ネットワークブーツ荷物を積む人のDHCPクライアントが短いリース時間を要求することを提案します、それらのIPアドレスが保有されないように。 そのようなクライアントはブートのプロセスの次のステージに移行する前に、DHCPRELEASEメッセージをDHCPサーバに送るべきです。 そのようなクライアントはオペレーティングシステムDHCPクライアントがその後のブーツにおける使用にDUIDを構成する方法を提供するべきです。 最終段階のDHCPクライアントは、可能であるところでブーツPROMによって使用されるDUIDがオペレーティングシステムで使用されるDUIDと同じであることを構成するべきです。

Lemon & Sommerfield         Standards Track                     [Page 9]

RFC 4361          Node-specific Identifiers for DHCPv4     February 2006

DHCPv4 February 2006のためのレモンとソマーフィールド標準化過程[9ページ]RFC4361のノード特有の識別子

   Second, implementors of DHCPv4 clients that are expected to only be
   used in a multi-stage network boot configuration, that are not
   expected ever to network boot using DHCPv6, and that have a MAC
   address that cannot be easily changed may not need to implement the
   changes described in this specification.  There is some danger in
   making this assumption--the first solution suggested is definitely
   better.  A compromise might be to have the final-stage DHCP client
   detect whether it is running on legacy hardware; if it is, it uses
   the old identifier; if it is not, it follows the scheme described in
   the previous paragraph.

2番目に、マルチステージネットワークブート構成に使用されるだけであると予想されて、今までにDHCPv6、およびそれを使用することでブーツをネットワークでつながないと予想されるDHCPv4クライアントの作成者は容易に変えることができないアドレスがこの仕様で説明された変化を実装する必要はないかもしれないMACを持っています。 この仮定をするのにおいて何らかの危険があります--確実により良いです最初のソリューションが、示唆した。 感染はそれがレガシーハードウェアで動いているかどうか最終段階DHCPクライアントに検出させることであるかもしれません。 そうなら、古い識別子を使用します。 そうでないなら、それは前のパラグラフで説明された体系に続きます。

8.  Security Considerations

8. セキュリティ問題

   This document raises no new security issues.  Potential exposure to
   attack in the DHCPv4 protocol is discussed in section 7 of the DHCP
   protocol specification [RFC2131] and in Authentication for DHCP
   messages [RFC3118].  Potential exposure to attack in the DHCPv6
   protocol is discussed in section 23 of RFC 3315.

このドキュメントはどんな新しい安全保障問題も提起しません。 DHCPv4プロトコルで攻撃する潜在被曝はDHCPプロトコル仕様のセクション7[RFC2131]とDHCPメッセージのためのAuthentication[RFC3118]で論じられます。 RFC3315のセクション23でDHCPv6プロトコルで攻撃する潜在被曝について議論します。

9.  References

9. 参照

9.1.  Normative References

9.1. 引用規格

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

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

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

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

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

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

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

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

9.2.  Informative References

9.2. 有益な参照

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

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

Lemon & Sommerfield         Standards Track                    [Page 10]

RFC 4361          Node-specific Identifiers for DHCPv4     February 2006

DHCPv4 February 2006のためのレモンとソマーフィールド標準化過程[10ページ]RFC4361のノード特有の識別子

Authors' Addresses

作者のアドレス

   Ted Lemon
   Nominum
   2385 Bay Road
   Redwood City, CA 94063 USA

テッドレモンNominum2385湾のRoadカリフォルニア94063レッドウッドシティー(米国)

   Phone: +1 650 381 6000
   EMail: mellon@nominum.com

以下に電話をしてください。 +1 6000年の650 381メール: mellon@nominum.com

   Bill Sommerfeld
   Sun Microsystems
   1 Network Drive
   Burlington, MA 01824

ビルゾンマーフェルトサン・マイクロシステムズ1ネットワークドライブバーリントン、MA 01824

   Phone: +1 781 442 3458
   EMail: sommerfeld@sun.com

以下に電話をしてください。 +1 3458年の781 442メール: sommerfeld@sun.com

Lemon & Sommerfield         Standards Track                    [Page 11]

RFC 4361          Node-specific Identifiers for DHCPv4     February 2006

DHCPv4 February 2006のためのレモンとソマーフィールド標準化過程[11ページ]RFC4361のノード特有の識別子

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

Lemon & Sommerfield         Standards Track                    [Page 12]

レモンとソマーフィールド標準化過程[12ページ]