[要約] RFC 7227は、新しいDHCPv6オプションを作成するためのガイドラインです。その目的は、DHCPv6プロトコルの拡張性と互換性を向上させることです。
Internet Engineering Task Force (IETF) D. Hankins
Request for Comments: 7227 Google
BCP: 187 T. Mrugalski
Updates: 3315 M. Siodelski
Category: Best Current Practice ISC
ISSN: 2070-1721 S. Jiang
Huawei Technologies Co., Ltd.
S. Krishnan
Ericsson
May 2014
Guidelines for Creating New DHCPv6 Options
新しいDHCPv6オプションを作成するためのガイドライン
Abstract
概要
This document provides guidance to prospective DHCPv6 option developers to help them create option formats that are easily adoptable by existing DHCPv6 software. It also provides guidelines for expert reviewers to evaluate new registrations. This document updates RFC 3315.
このドキュメントは、既存のDHCPv6ソフトウェアで簡単に採用できるオプション形式を作成するのに役立つ、将来のDHCPv6オプション開発者へのガイダンスを提供します。また、エキスパートレビューアーが新規登録を評価するためのガイドラインも提供します。このドキュメントはRFC 3315を更新します。
Status of This Memo
本文書の状態
This memo documents an Internet Best Current Practice.
このメモは、インターネットの現在のベストプラクティスを文書化したものです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7227.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7227で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5
3. When to Use DHCPv6 . . . . . . . . . . . . . . . . . . . . . 5
4. General Principles . . . . . . . . . . . . . . . . . . . . . 5
5. Reusing Other Option Formats . . . . . . . . . . . . . . . . 6
5.1. Option with IPv6 Addresses . . . . . . . . . . . . . . . 7
5.2. Option with Single Flag (Boolean) . . . . . . . . . . . . 8
5.3. Option with IPv6 Prefix . . . . . . . . . . . . . . . . . 9
5.4. Option with 32-bit Integer Value . . . . . . . . . . . . 10
5.5. Option with 16-bit Integer Value . . . . . . . . . . . . 10
5.6. Option with 8-bit Integer Value . . . . . . . . . . . . . 11
5.7. Option with URI . . . . . . . . . . . . . . . . . . . . . 11
5.8. Option with Text String . . . . . . . . . . . . . . . . . 12
5.9. Option with Variable-Length Data . . . . . . . . . . . . 13
5.10. Option with DNS Wire Format Domain Name List . . . . . . 14
6. Avoid Conditional Formatting . . . . . . . . . . . . . . . . 15
7. Avoid Aliasing . . . . . . . . . . . . . . . . . . . . . . . 15
8. Choosing between an FQDN and an Address . . . . . . . . . . . 16
9. Encapsulated Options in DHCPv6 . . . . . . . . . . . . . . . 19
10. Additional States Considered Harmful . . . . . . . . . . . . 20
11. Configuration Changes Occur at Fixed Times . . . . . . . . . 21
12. Multiple Provisioning Domains . . . . . . . . . . . . . . . . 21
13. Chartering Requirements and Advice for Responsible Area
Directors . . . . . . . . . . . . . . . . . . . . . . . . . . 22
14. Considerations for Creating New Formats . . . . . . . . . . . 23
15. Option Size . . . . . . . . . . . . . . . . . . . . . . . . . 23
16. Singleton Options . . . . . . . . . . . . . . . . . . . . . . 24
17. Option Order . . . . . . . . . . . . . . . . . . . . . . . . 25
18. Relay Options . . . . . . . . . . . . . . . . . . . . . . . . 25
19. Clients Request Their Options . . . . . . . . . . . . . . . . 26
20. Transition Technologies . . . . . . . . . . . . . . . . . . . 26
21. Recommended Sections in the New Document . . . . . . . . . . 27
21.1. DHCPv6 Client Behavior Text . . . . . . . . . . . . . . 28
21.2. DHCPv6 Server Behavior Text . . . . . . . . . . . . . . 28
21.3. DHCPv6 Relay Agent Behavior Text . . . . . . . . . . . . 29
22. Should the New Document Update Existing RFCs? . . . . . . . . 29
23. Security Considerations . . . . . . . . . . . . . . . . . . . 29
24. Privacy Considerations . . . . . . . . . . . . . . . . . . . 31
25. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31
26. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
26.1. Normative References . . . . . . . . . . . . . . . . . . 31
26.2. Informative References . . . . . . . . . . . . . . . . . 32
Most protocol developers ask themselves if a protocol will work, or work efficiently. These are important questions, but another less frequently considered question is whether the proposed protocol presents itself needless barriers to adoption by deployed software.
ほとんどのプロトコル開発者は、プロトコルが機能するのか、それとも効率的に機能するのかを自問しています。これらは重要な質問ですが、提案されたプロトコルが、展開されたソフトウェアによる採用への不必要な障壁を提示するかどうかは、あまり考慮されない質問です。
DHCPv6 [RFC3315] software implementors are not merely faced with the task of handling a given option's format on the wire. The option must fit into every stage of the system's process, starting with the user interface used to enter the configuration up to the machine interfaces where configuration is ultimately consumed.
DHCPv6 [RFC3315]ソフトウェアの実装者は、特定のオプションのフォーマットをネットワーク上で処理するというタスクに直面するだけではありません。このオプションは、システムのプロセスのすべての段階に適合する必要があります。構成を入力するために使用されるユーザーインターフェイスから、構成が最終的に消費されるマシンインターフェイスまでです。
Another frequently overlooked aspect of rapid adoption is whether the option requires operators to be intimately familiar with the option's internal format in order to use it. Most DHCPv6 software provides a facility for handling unknown options at the time of publication. The handling of such options usually needs to be manually configured by the operator. But, if doing so requires extensive reading (more than can be covered in a simple FAQ, for example), it inhibits adoption.
急速に採用されて見過ごされがちなもう1つの側面は、オプションを使用するためにオペレーターがオプションの内部フォーマットに精通している必要があるかどうかです。ほとんどのDHCPv6ソフトウェアは、公開時に不明なオプションを処理する機能を提供します。このようなオプションの処理は、通常、オペレーターが手動で構成する必要があります。しかし、そうするために広範囲にわたる読み取りが必要な場合（たとえば、単純なFAQでカバーしきれないほど）、それは採用を阻害します。
So, although a given solution would work, and might even be space, time, or aesthetically optimal, a given option is presented with a series of ever-worsening challenges to be adopted:
したがって、特定のソリューションが機能し、スペース、時間、または審美的に最適である場合でも、特定のオプションが採用され、さらに悪化する一連の課題が提示されます。
o If it doesn't fit neatly into existing configuration files.
o 既存の構成ファイルにきちんと適合しない場合。
o If it requires source code changes to be adopted and, hence, upgrades of deployed software.
o ソースコードの変更を採用する必要がある場合、したがって、展開されたソフトウェアのアップグレード。
o If it does not share its deployment fate in a general manner with other options, standing alone in requiring code changes or reworking configuration file syntaxes.
o 展開の運命を他のオプションと一般的な方法で共有しない場合は、コードの変更または構成ファイルの構文の再構築が必要になるだけでスタンドアロンになります。
o If the option would work well in the particular deployment environment the proponents currently envision, but it has equally valid uses in some other environment where the proposed option format would fail or would produce inconsistent results.
o オプションが特定の展開環境でうまく機能する場合、支持者は現在想定していますが、提案されたオプション形式が失敗するか、一貫性のない結果が生じる他の環境でも同じように有効に使用できます。
There are many things DHCPv6 option creators can do to avoid the pitfalls in this list entirely, or failing that, to make software implementors' lives easier and improve its chances for widespread adoption.
DHCPv6オプションの作成者がこのリストの落とし穴を完全に回避したり、失敗したりして、ソフトウェアの実装者の生活を容易にし、広範囲にわたる採用の可能性を高めるためにできることはたくさんあります。
This document is envisaged as a help for protocol developers that define new options and for expert reviewers that review submitted proposals.
このドキュメントは、新しいオプションを定義するプロトコル開発者、および提出された提案をレビューする専門家のレビュー担当者向けのヘルプとして想定されています。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
Principally, DHCPv6 carries configuration parameters for its clients. Any knob, dial, slider, or checkbox on the client system, such as "my domain name servers", "my hostname", or even "my shutdown temperature", are candidates for being configured by DHCPv6.
主に、DHCPv6はクライアントの構成パラメーターを伝送します。 「マイドメインネームサーバー」、「マイホスト名」、「マイシャットダウン温度」など、クライアントシステムのノブ、ダイヤル、スライダー、またはチェックボックスは、DHCPv6による構成の候補です。
The presence of such a knob isn't enough, because DHCPv6 also presents the extension of an administrative domain -- the operator of the network to which the client is currently attached. Someone runs not only the local switching network infrastructure to which the client is directly (or wirelessly) attached but the various methods of accessing the external Internet via local assist services that the network must also provide (such as domain name servers or routers). This means that, even if a configuration parameter can be potentially delivered by DHCPv6, it is necessary to evaluate whether it is reasonable for this parameter to be under the control of the administrator of whatever network a client is attached to at any given time.
DHCPv6は、管理ドメイン（クライアントが現在接続しているネットワークのオペレーター）の拡張も提供するため、このようなノブの存在だけでは十分ではありません。誰かが、クライアントが直接（またはワイヤレスで）接続しているローカルスイッチングネットワークインフラストラクチャだけでなく、ネットワークが提供する必要があるローカルアシストサービス（ドメインネームサーバーやルーターなど）を介して外部インターネットにアクセスするさまざまな方法を実行します。つまり、構成パラメーターがDHCPv6によって配信される可能性がある場合でも、このパラメーターが、クライアントが接続されているネットワークの管理者の制御下にあることが妥当であるかどうかを常に評価する必要があります。
Note that the client is not required to configure any of these values received via DHCPv6 (e.g., due to having these values locally configured by its own administrator). But, it needs to be noted that overriding DHCPv6-provided values may cause the client to be denied certain services in the network to which it has attached. The possibility of having a higher level of control over client node configuration is one of the reasons that DHCPv6 is preferred in enterprise networks.
クライアントは、DHCPv6を介して受信したこれらの値を構成する必要がないことに注意してください（たとえば、これらの値が独自の管理者によってローカルに構成されているため）。ただし、DHCPv6が提供する値をオーバーライドすると、クライアントが接続しているネットワーク内の特定のサービスがクライアントに拒否される場合があることに注意する必要があります。クライアントノード構成をより高いレベルで制御できる可能性は、エンタープライズネットワークでDHCPv6が推奨される理由の1つです。
The primary guiding principle to follow in order to enhance an option's adoptability is reuse. The option should be created in such a way that does not require any new or special case software to support. If old software that is currently deployed and in the field can adopt the option through supplied configuration facilities, then it's fairly certain that new software can formally adopt it easily.
オプションの採用可能性を高めるために従うべき主要な指針となる原則は、再利用です。オプションは、新規または特別なケースのソフトウェアをサポートする必要がないような方法で作成する必要があります。現在展開されているフィールドにある古いソフトウェアが、提供された構成機能を介してオプションを採用できる場合、新しいソフトウェアが正式に簡単に採用できることはかなり確実です。
There are at least two classes of DHCPv6 options: simple options, which are provided explicitly to carry data from one side of the DHCPv6 exchange to the other (such as name servers, domain names, or time servers), and a protocol class of options, which require special processing on the part of the DHCPv6 software or are used during special processing (such as the Fully Qualified Domain Name (FQDN) option [RFC4704]), and so forth; these options carry data that is the result of a routine in some DHCPv6 software.
DHCPv6オプションには少なくとも2つのクラスがあります。DHCPv6交換の片側から反対側にデータを運ぶために明示的に提供されるシンプルなオプション（ネームサーバー、ドメイン名、タイムサーバーなど）とプロトコルのオプションクラスです。 DHCPv6ソフトウェアの特別な処理を必要とする、または特別な処理中に使用される（完全修飾ドメイン名（FQDN）オプション[RFC4704]など）、など。これらのオプションは、一部のDHCPv6ソフトウェアのルーチンの結果であるデータを伝送します。
The guidelines laid out here should be applied in a relaxed manner for the protocol class of options. Wherever a special case code is already required to adopt the DHCPv6 option, it is substantially more reasonable to format the option in a less generic fashion, if there are measurable benefits to doing so.
ここで説明するガイドラインは、プロトコルクラスのオプションにゆるやかに適用する必要があります。 DHCPv6オプションを採用するために特別なケースコードがすでに必要な場合は、測定可能なメリットがある場合は、それほど一般的ではない方法でオプションをフォーマットする方がはるかに合理的です。
The easiest approach to manufacturing trivially deployable DHCPv6 options is to assemble the option out of whatever common fragments fit, possibly allowing a group of data elements to repeat to fill the remaining space (if present) and thus provide multiple values. Place all fixed-size values at the start of the option and any variable -/indeterminate-sized values at the tail end of the option.
簡単に展開可能なDHCPv6オプションを製造する最も簡単な方法は、一般的なフラグメントが適合するものからオプションをアセンブルすることです。これにより、データ要素のグループを繰り返して残りのスペース（存在する場合）を埋め、複数の値を提供できるようになります。すべての固定サイズの値をオプションの先頭に配置し、変数のサイズが不定の値はオプションの末尾に配置します。
This means that implementations will likely be able to reuse code paths designed to support the other options.
これは、実装が他のオプションをサポートするように設計されたコードパスを再利用できる可能性が高いことを意味します。
There is a trade-off between the adoptability of previously defined option formats and the advantages that new or specialized formats can provide. In general, it is usually preferable to reuse previously used option formats.
以前に定義されたオプション形式の採用可能性と、新しい形式または特殊な形式が提供できる利点の間にはトレードオフがあります。一般的に、以前に使用されたオプション形式を再利用することが通常は望ましいです。
However, it isn't very practical to consider the bulk of DHCPv6 options already allocated and to consider which of those solve a similar problem. So, the following list of common option format data elements is provided as shorthand. Please note that it is not complete in terms of exampling every option format ever devised.
ただし、すでに割り当てられているDHCPv6オプションの大部分を検討し、それらのどれが同様の問題を解決するかを検討することは、あまり現実的ではありません。したがって、以下の一般的なオプション形式のデータ要素のリストは、省略形として提供されています。これまでに考案されたすべてのオプション形式を例示することに関して完全ではないことに注意してください。
If more complex options are needed, those basic formats mentioned here may be considered as primitives (or 'fragment types') that can be used to build more complex formats. It should be noted that it is often easier to implement two options with trivial formats than one option with a more complex format. That is not an unconditional requirement though. In some cases, splitting one complex option into two or more simple options introduces inter-option dependencies that should be avoided. In such a case, it is usually better to keep one complex option.
より複雑なオプションが必要な場合、ここで説明する基本的な形式は、より複雑な形式を構築するために使用できるプリミティブ（または「フラグメントタイプ」）と見なすことができます。多くの場合、より複雑な形式の1つのオプションよりも、簡単な形式の2つのオプションを実装する方が簡単です。ただし、これは無条件の要件ではありません。場合によっては、1つの複雑なオプションを2つ以上の単純なオプションに分割すると、回避すべきオプション間の依存関係が発生します。このような場合、通常は1つの複雑なオプションを保持することをお勧めします。
This option format is used to carry one or many IPv6 addresses. In some cases, the number of allowed addresses is limited (e.g., to one):
このオプション形式は、1つまたは複数のIPv6アドレスを運ぶために使用されます。場合によっては、許可されるアドレスの数が制限されています（例：1つ）：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| ipv6-address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Option with IPv6 Addresses
図1：IPv6アドレスのオプション
Examples of use:
使用例：
o DHCPv6 Server Unicast Address [RFC3315] (a single address only)
o DHCPv6サーバーユニキャストアドレス[RFC3315]（単一アドレスのみ）
o Session Initiation Protocol (SIP) Servers IPv6 Address List [RFC3319]
o セッション開始プロトコル（SIP）サーバーのIPv6アドレス一覧[RFC3319]
o DNS Recursive Name Servers [RFC3646]
o DNS再帰ネームサーバー[RFC3646]
o Network Information Service (NIS) Servers [RFC3898]
o ネットワーク情報サービス（NIS）サーバー[RFC3898]
o Simple Network Time Protocol (SNTP) Servers [RFC4075]
o 簡易ネットワークタイムプロトコル（SNTP）サーバー[RFC4075]
o Broadcast and Multicast Service Controller IPv6 Address Option for DHCPv6 [RFC4280]
o DHCPv6のブロードキャストおよびマルチキャストサービスコントローラーIPv6アドレスオプション[RFC4280]
o Mobile IPv6 (MIPv6) Home Agent Address [RFC6610] (a single address only)
o モバイルIPv6（MIPv6）ホームエージェントアドレス[RFC6610]（単一アドレスのみ）
o Network Time Protocol (NTP) Server Address [RFC5908] (a single address only)
o ネットワークタイムプロトコル（NTP）サーバーアドレス[RFC5908]（単一アドレスのみ）
o NTP Multicast Address [RFC5908] (a single address only)
o NTPマルチキャストアドレス[RFC5908]（単一アドレスのみ）
Sometimes, it is useful to convey a single flag that can take either on or off values. Instead of specifying an option with 1 bit of usable data and 7 bits of padding, it is better to define an option without any content. It is the presence or absence of the option that conveys the value. This approach has the additional benefit of the absent option designating the default; that is, the administrator has to take explicit actions to deploy the opposite of the default value.
オンまたはオフの値を取ることができる単一のフラグを伝えると便利な場合があります。 1ビットの使用可能なデータと7ビットのパディングでオプションを指定する代わりに、コンテンツなしでオプションを定義することをお勧めします。価値を伝えるのはオプションの有無です。このアプローチには、デフォルトを指定しないオプションの利点があります。つまり、管理者はデフォルト値の反対をデプロイするために明示的なアクションを実行する必要があります。
The absence of the option represents the default value, and the presence of the option represents the other value, but that does not necessarily mean that absence is "off" (or "false") and presence is "on" (or "true"). That is, if it's desired that the default value for a bistable option is "true"/"on", then the presence of that option would turn it off (make it false). If the option presence signifies an off/false state, that should be reflected in the option name, e.g., OPTION_DISABLE_FOO.
オプションの不在はデフォルト値を表し、オプションの存在は他の値を表しますが、必ずしも不在が「オフ」（または「偽」）であり、存在が「オン」（または「真」）であることを必ずしも意味しません）。つまり、双安定オプションのデフォルト値が「true」/「on」であることが望ましい場合は、そのオプションの存在によってオプションがオフになります（falseにします）。オプションの存在がオフ/偽の状態を示す場合、それはオプション名（OPTION_DISABLE_FOOなど）に反映される必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Option for Conveying Boolean
図2：ブール値を伝達するためのオプション
Examples of use:
使用例：
o DHCPv6 Rapid Commit [RFC3315]
o DHCPv6高速コミット[RFC3315]
Sometimes, there is a need to convey an IPv6 prefix. The information to be carried by such an option includes the 128-bit IPv6 prefix together with a length of this prefix taking values from 0 to 128. Using the simplest approach, the option could convey this data in two fixed-length fields: one carrying the prefix length and another carrying the prefix. However, in many cases, /64 or shorter prefixes are used. This implies that the large part of the prefix data carried by the option would have its bits set to 0 and would be unused. In order to avoid carrying unused data, it is recommended to store the prefix in the variable-length data field. The appropriate option format is defined as follows:
場合によっては、IPv6プレフィックスを伝える必要があります。このようなオプションによって運ばれる情報には、128ビットのIPv6プレフィックスと、0から128までの値を取るこのプレフィックスの長さが含まれます。最も単純なアプローチを使用すると、オプションはこのデータを2つの固定長フィールドで伝えることができます。プレフィックス長とプレフィックスを運ぶ別のもの。ただし、多くの場合、/ 64以下のプレフィックスが使用されます。これは、オプションによって運ばれるプレフィックスデータの大部分がそのビットが0に設定され、使用されないことを意味します。未使用のデータを運ばないようにするために、可変長データフィールドにプレフィックスを格納することをお勧めします。適切なオプション形式は次のように定義されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix6len | ipv6-prefix |
+-+-+-+-+-+-+-+-+ (variable length) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Option with IPv6 Prefix
図3：IPv6プレフィックス付きのオプション
option-length is set to 1 + length of the IPv6 prefix.
option-lengthは1 + IPv6プレフィックスの長さに設定されます。
prefix6len is 1 octet long and specifies the length in bits of the IPv6 prefix. Typically allowed values are 0 to 128.
prefix6lenは1オクテット長で、IPv6プレフィックスの長さをビット単位で指定します。通常、許可される値は0〜128です。
The ipv6-prefix field is a variable-length field that specifies the IPv6 prefix. The length is (prefix6len + 7) / 8. This field is padded with 0 bits up to the nearest octet boundary when prefix6len is not divisible by 8.
ipv6-prefixフィールドは、IPv6プレフィックスを指定する可変長フィールドです。長さは（prefix6len + 7）/ 8です。prefix6lenが8で割り切れない場合、このフィールドには最も近いオクテット境界まで0ビットが埋め込まれます。
Examples of use:
使用例：
o Default Mapping Rule [MAP]
o デフォルトのマッピングルール[MAP]
For example, the prefix 2001:db8::/60 would be encoded with an option-length of 9, prefix6-len would be set to 60, and the ipv6-prefix would be 8 octets and would contain octets 20 01 0d b8 00 00 00 00.
たとえば、プレフィックス2001：db8 :: / 60はオプション長9でエンコードされ、prefix6-lenは60に設定され、ipv6-prefixは8オクテットになり、オクテット20 01 0d b8 00が含まれます。 00 00 00。
It should be noted that the IAPREFIX option defined by [RFC3633] uses a full-length 16-octet prefix field. The concern about option length was not well understood at the time of its publication.
[RFC3633]で定義されているIAPREFIXオプションは、完全長の16オクテットプレフィックスフィールドを使用することに注意してください。オプションの長さに関する懸念は、その発表時点では十分に理解されていませんでした。
This option format can be used to carry a 32-bit signed or unsigned integer value:
このオプション形式は、32ビットの符号付きまたは符号なし整数値を運ぶために使用できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 32-bit-integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Option with 32-bit Integer Value
図4：32ビット整数値のオプション
Examples of use:
使用例：
o Information Refresh Time [RFC4242]
o 情報更新時間[RFC4242]
This option format can be used to carry 16-bit signed or unsigned integer values:
このオプション形式は、16ビットの符号付きまたは符号なし整数値を運ぶために使用できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 16-bit-integer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Option with 16-bit Integer Value
図5：16ビット整数値のオプション
Examples of use:
使用例：
o Elapsed Time [RFC3315]
o 経過時間[RFC3315]
This option format can be used to carry 8-bit integer values:
このオプション形式は、8ビット整数値を運ぶために使用できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 8-bit-integer |
+-+-+-+-+-+-+-+-+
Figure 6: Option with 8-bit Integer Value
図6：8ビット整数値のオプション
Examples of use:
使用例：
o DHCPv6 Preference [RFC3315]
o DHCPv6設定[RFC3315]
A Uniform Resource Identifier (URI) [RFC3986] is a compact sequence of characters that identifies an abstract or physical resource. The term "Uniform Resource Locator" (URL) refers to the subset of URIs that, in addition to identifying a resource, provide a means of locating the resource by describing its primary access mechanism (e.g., its network "location"). This option format can be used to carry a single URI:
Uniform Resource Identifier（URI）[RFC3986]は、抽象的または物理的なリソースを識別する文字のコンパクトなシーケンスです。 「Uniform Resource Locator」（URL）という用語は、URIのサブセットを指します。URIは、リソースを識別するだけでなく、その主要なアクセスメカニズム（ネットワークの「場所」など）を記述することでリソースを見つける手段を提供します。このオプション形式は、単一のURIを運ぶために使用できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. URI (variable length) .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Option with URI
図7：URIを使用したオプション
Examples of use:
使用例：
o Boot File URL [RFC5970]
o ブートファイルのURL [RFC5970]
An alternate encoding to support multiple URIs is available. An option must be defined to use either the single URI format above or the multiple URI format below depending on whether a single URI is always sufficient or if multiple URIs are possible.
複数のURIをサポートする代替エンコーディングが利用可能です。オプションは、単一のURIで常に十分か、複数のURIが可能かどうかに応じて、上記の単一のURI形式または以下の複数のURI形式のいずれかを使用するように定義する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. uri-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Option with Multiple URIs
図8：複数のURIを持つオプション
Each instance of the uri-data is formatted as follows:
uri-dataの各インスタンスは次のようにフォーマットされます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| uri-len | URI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The uri-len is 2 octets long and specifies the length of the URI data. Although the URI format in theory supports up to 64 KB of data, in practice, large chunks of data may be problematic. See Section 15 for details.
uri-lenは2オクテット長で、URIデータの長さを指定します。理論上、URI形式は最大64 KBのデータをサポートしますが、実際には、データの大きなチャンクが問題になる場合があります。詳細については、セクション15を参照してください。
A text string is a sequence of characters that have no semantics. The encoding of the text string MUST be specified. Unless otherwise specified, all text strings in newly defined options are expected to be Unicode strings that are encoded using UTF-8 [RFC3629] in Net-Unicode form [RFC5198]. Please note that all strings containing only 7-bit ASCII characters are also valid UTF-8 Net-Unicode strings.
テキスト文字列は、セマンティクスを持たない一連の文字です。テキスト文字列のエンコーディングを指定する必要があります。特に指定がない限り、新しく定義されたオプションのすべてのテキスト文字列は、UTF-8 [RFC3629]を使用してNet-Unicode形式[RFC5198]でエンコードされたUnicode文字列であると想定されます。 7ビットASCII文字のみを含むすべての文字列も、有効なUTF-8 Net-Unicode文字列であることに注意してください。
If a data format has semantics other than just being text, it is not a string; e.g., an FQDN is not a string, and a URI is also not a string because they have different semantics. A string must not include any terminator (such as a null byte). The null byte is treated as any other character and does not have any special meaning. This option format can be used to carry a text string:
データ形式がテキスト以外の意味を持つ場合、それは文字列ではありません。たとえば、FQDNは文字列ではなく、URIも文字列ではありません。セマンティクスが異なるためです。文字列には、終端文字（ヌルバイトなど）を含めないでください。 nullバイトは他の文字として扱われ、特別な意味はありません。このオプション形式は、テキスト文字列を運ぶために使用できます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. String .
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Option with Text String
図9：テキスト文字列を含むオプション
Examples of use:
使用例：
o Timezone Options for DHCPv6 [RFC4833]
o DHCPv6のタイムゾーンオプション[RFC4833]
An alternate encoding to support multiple text strings is available. An option must be defined to use either the single text string format above or the multiple text string format below, depending on whether a single text string is always sufficient or if multiple text strings are possible.
複数のテキスト文字列をサポートする別のエンコーディングが利用可能です。単一のテキスト文字列で常に十分か、複数のテキスト文字列が可能かどうかに応じて、上記の単一のテキスト文字列形式または以下の複数のテキスト文字列形式を使用するオプションを定義する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. text-data .
. . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Option with Multiple Text Strings
図10：複数のテキスト文字列を持つオプション
Each instance of the text-data is formatted as follows:
text-dataの各インスタンスは、次のようにフォーマットされます。
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
| text-len | String |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...-+-+-+-+-+-+-+
The text-len is 2 octets long and specifies the length of the string.
text-lenは2オクテット長で、文字列の長さを指定します。
This option can be used to carry variable-length data of any kind. Internal representation of carried data is option specific. Whenever this format is used by the new option being defined, the data encoding should be documented.
このオプションは、あらゆる種類の可変長データを運ぶために使用できます。運ばれたデータの内部表現はオプション固有です。このフォーマットが定義されている新しいオプションによって使用されるときはいつでも、データエンコーディングは文書化されるべきです。
This option format provides a lot of flexibility to pass data of almost any kind. Though, whenever possible, it is highly recommended to use more specialized options, with field types better matching carried data types.
このオプション形式は、ほとんどすべての種類のデータを渡すための多くの柔軟性を提供します。ただし、可能な場合は常に、より特殊なオプションを使用することを強くお勧めします。フィールドタイプの方が、運ばれるデータタイプとよりよく一致します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. variable-length data .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Option with Variable-Length Data
図11：可変長データのオプション
Examples of use:
使用例：
o Client Identifier [RFC3315]
o クライアント識別子[RFC3315]
o Server Identifier [RFC3315]
o サーバー識別子[RFC3315]
This option is used to carry 'domain search' lists or any host or domain name. It uses the same format as described in Section 5.9 but with the special data encoding, as described in Section 8 of [RFC3315]. This data encoding supports carrying multiple instances of hosts or domain names in a single option by terminating each instance with the byte value of 0.
このオプションは、「ドメイン検索」リストまたは任意のホストまたはドメイン名を運ぶために使用されます。 [RFC3315]のセクション8で説明されているように、セクション5.9で説明されているのと同じ形式を使用しますが、特別なデータエンコーディングを使用します。このデータエンコードでは、バイト値0で各インスタンスを終了することにより、ホストまたはドメイン名の複数のインスタンスを1つのオプションで運ぶことができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DNS Wire Format Domain Name List |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 12: Option with DNS Wire Format Domain Name List
図12：DNSワイヤー形式のドメイン名リストのオプション
Examples of use:
使用例：
o SIP Servers Domain Name List [RFC3319] (many domains)
o SIPサーバードメイン名リスト[RFC3319]（多くのドメイン）
o NIS Domain Name [RFC3898] (many domains) o Location-to-Service Translation (LoST) Server Domain Name [RFC5223]
o NISドメイン名[RFC3898]（多くのドメイン）oロケーションからサービスへの変換（LoST）サーバードメイン名[RFC5223]
o Location Information Server (LIS) Domain Name [RFC5986]
o ロケーション情報サーバー（LIS）のドメイン名[RFC5986]
o Dual-Stack Lite (DS-Lite) Address Family Transition Router (AFTR) Location [RFC6334] (a single FQDN)
o デュアルスタックライト（DS-Lite）アドレスファミリ遷移ルーター（AFTR）の場所[RFC6334]（単一のFQDN）
o Home Network Identifier [RFC6610] (a single FQDN)
o ホームネットワーク識別子[RFC6610]（単一のFQDN）
o Home Agent FQDN [RFC6610] (a single FQDN)
o ホームエージェントFQDN [RFC6610]（単一のFQDN）
Placing an octet at the start of the option that informs the software how to process the remaining octets of the option may appear simple to the casual observer. But, the only conditional formatting methods that are in widespread use today are 'protocol' class options. Therefore, conditional formatting requires new code to be written and complicates future interoperability should new conditional formats be added; existing code has to ignore conditional formats that it does not support.
オプションの残りのオクテットを処理する方法をソフトウェアに通知するオプションの最初にオクテットを置くことは、何気ない観察者には単純に見えるかもしれません。しかし、今日広く使用されている唯一の条件付き書式設定メソッドは、「プロトコル」クラスオプションです。したがって、条件付きフォーマットでは新しいコードを記述する必要があり、新しい条件付きフォーマットが追加された場合の将来の相互運用性が複雑になります。既存のコードは、サポートしていない条件付きフォーマットを無視する必要があります。
Options are said to be aliases of each other if they provide input to the same configuration parameter. A commonly proposed example is to configure the location of some new service ("my foo server") using a binary IP address, a domain name field, and a URL. This kind of aliasing is undesirable and is not recommended.
オプションは、同じ構成パラメーターへの入力を提供する場合、互いのエイリアスと呼ばれます。一般的に提案されている例は、バイナリIPアドレス、ドメイン名フィールド、およびURLを使用して、いくつかの新しいサービス（ "my foo server"）の場所を構成することです。この種のエイリアシングは望ましくないため、推奨されません。
In this case, where three different formats are supposed, it more than triples the work of the software involved, requiring support for not merely one format but support to produce and digest all three. Furthermore, code development and testing must cover all possible combinations of defined formats. Since clients cannot predict what values the server will provide, they must request all formats. So, in the case where the server is configured with all formats, DHCPv6 message bandwidth is wasted on option contents that are redundant. Also, the DHCPv6 option number space is wasted, as three new option codes are required rather than one.
この場合、3つの異なるフォーマットが想定されているため、関連するソフトウェアの作業が3倍以上になり、1つのフォーマットだけでなく、3つすべての生成とダイジェストのサポートも必要になります。さらに、コードの開発とテストでは、定義されたフォーマットのすべての可能な組み合わせをカバーする必要があります。クライアントはサーバーが提供する値を予測できないため、すべての形式を要求する必要があります。そのため、サーバーがすべての形式で構成されている場合、DHCPv6メッセージの帯域幅は、冗長なオプションコンテンツで無駄になります。また、1つではなく3つの新しいオプションコードが必要になるため、DHCPv6オプション番号スペースが無駄になります。
It also becomes unclear which types of values are mandatory and how configuring some of the options may influence the others. For example, if an operator configures the URL only, should the server synthesize a domain name and an IP address? A single configuration value on a host is probably presented to the operator (or other software on the machine) in a single field or channel. If that channel has a natural format, then any alternative formats merely make more work for intervening software in providing conversions.
また、必須の値のタイプと、一部のオプションの構成が他のオプションにどのように影響するかについても不明確になります。たとえば、オペレーターがURLのみを構成する場合、サーバーはドメイン名とIPアドレスを統合する必要がありますか？ホスト上の単一の構成値は、おそらく単一のフィールドまたはチャネルでオペレーター（またはマシン上の他のソフトウェア）に提示されます。そのチャネルが自然なフォーマットである場合、代替フォーマットは、介在するソフトウェアが変換を提供するための作業を増やすだけです。
So, the best advice is to choose the one method that best fulfills the requirements for simplicity (such as with an IP address and a port pair), late binding (such as with DNS), or completeness (such as with a URL).
したがって、最善のアドバイスは、単純化（IPアドレスとポートのペアなど）、遅延バインディング（DNSなど）、または完全性（URLなど）の要件を満たす1つの方法を選択することです。
Some parameters may be specified as an FQDN or an address. In most cases, one or the other should be used. This section discusses pros and cons of each approach and is intended to help make an informed decision in that regard. It is strongly discouraged to define both option types at the same time (see Section 7), unless there is sufficient motivation to do so.
一部のパラメーターは、FQDNまたはアドレスとして指定できます。ほとんどの場合、どちらか一方を使用する必要があります。このセクションでは、各アプローチの長所と短所について説明し、その点について十分な情報に基づいた決定を行うことを目的としています。十分な動機がない限り、両方のオプションタイプを同時に定義することは強くお勧めしません（セクション7を参照）。
There is no single recommendation that works for every case. It very much depends on the nature of the parameter being configured. For parameters that are network specific or represent certain aspects of network infrastructure, like available mobility services, in most cases addresses are a more usable choice. For parameters that can be considered an application-specific configuration, like SIP servers, it is usually better to use an FQDN.
すべてのケースで機能する単一の推奨事項はありません。これは、構成するパラメーターの性質に大きく依存します。ネットワーク固有のパラメーター、または利用可能なモビリティサービスなどのネットワークインフラストラクチャの特定の側面を表すパラメーターの場合、ほとんどの場合、アドレスの方が使用しやすい選択肢です。 SIPサーバーなど、アプリケーション固有の構成と見なすことができるパラメーターの場合、通常はFQDNを使用することをお勧めします。
Applications are often better suited to deal with FQDN failures than with address failures. Most operating systems provide a way to retry an FQDN resolution if the previous attempt fails. That type of error recovery is supported by a great number of applications. On the other hand, there is typically no API available for applications to reconfigure over DHCP to get a new address value if the one received is no longer appropriate. This problem may be usually addressed by providing a list of addresses rather than just a single one. That, on the other hand, requires a defined procedure on how multiple addresses should be used (all at once, round robin, try first and fail over to the next if it fails, etc.).
多くの場合、アプリケーションはアドレス障害よりもFQDN障害の処理に適しています。ほとんどのオペレーティングシステムは、前の試行が失敗した場合にFQDN解決を再試行する方法を提供します。このタイプのエラー回復は、多くのアプリケーションでサポートされています。一方、アプリケーションがDHCPを介して再構成して、受信したアドレスが適切でなくなった場合に新しいアドレス値を取得するために使用できるAPIは通常ありません。この問題は、通常、単一のアドレスではなくアドレスのリストを提供することで対処できます。その一方で、複数のアドレスの使用方法に関する定義済みの手順が必要です（一度にすべて、ラウンドロビン、最初に試行して、失敗した場合は次へフェイルオーバーするなど）。
An FQDN provides a higher level of indirection and ambiguity. In many cases, that may be considered a benefit, but it can be considered a flaw in others. For example, one operator suggested that the same name be resolved to different addresses, depending on the point of attachment of the host doing the resolution. This is one way to provide localized addressing. However, in order to do this, it is necessary to violate the DNS convention that a query on a particular name should always return the same answer (aside from the ordering of IP addresses in the response, which is supposed to be varied by the name server). This same locality of reference for configuration information can be achieved directly using DHCP, since the DHCP server must know the network topology in order to provide IP address or prefix configuration.
FQDNは、より高いレベルの間接性とあいまいさを提供します。多くの場合、それは利点と考えられるかもしれませんが、他の欠陥と考えることができます。たとえば、あるオペレーターは、解決を行うホストの接続ポイントに応じて、同じ名前を異なるアドレスに解決することを提案しました。これは、ローカライズされたアドレス指定を提供する1つの方法です。ただし、これを行うには、特定の名前に対するクエリが常に同じ回答を返す必要があるというDNS規則に違反する必要があります（名前による変化が想定されている応答でのIPアドレスの順序は別として）サーバ）。 DHCPサーバーはIPアドレスまたはプレフィックス構成を提供するためにネットワークトポロジを知っている必要があるため、構成情報のこの同じ参照の局所性はDHCPを使用して直接達成できます。
The other type of ambiguity is related to multiple provisioning domains (see Section 12). The stub resolver on the DHCP client cannot at present be assumed to make the DNS query for a DHCP-supplied FQDN on the same interface on which it received its DHCP configuration and may, therefore, get a different answer from the DNS than was intended.
他のタイプのあいまいさは、複数のプロビジョニングドメインに関連しています（セクション12を参照）。 DHCPクライアントのスタブリゾルバは、現時点では、DHCP構成を受信したのと同じインターフェイスでDHCP提供のFQDNに対してDNSクエリを実行するとは想定されていないため、DNSから意図したものとは異なる回答を取得する可能性があります。
This is particularly a problem when the normal expected use of the option makes sense with a private DNS zone(s), as might be the case on an enterprise network. It may also be the case that the client has an explicit DNS server configured and may, therefore, never query the enterprise network's internal DNS server.
これは、エンタープライズネットワークの場合のように、オプションの通常の予想される使用がプライベートDNSゾーンで意味をなす場合に特に問題になります。また、クライアントに明示的なDNSサーバーが構成されているため、エンタープライズネットワークの内部DNSサーバーにクエリを実行しない場合もあります。
An FQDN does require a resolution into an actual address. This implies the question as to when the FQDN resolution should be conducted. There are a couple of possible answers: a) by the server, when it is started, b) by the server, when it is about to send an option, c) by the client, immediately after receiving an option, and d) by the client, when the content of the option is actually consumed. For a), b), and possibly c), the option should really convey an address, not an FQDN. The only real incentive to use an FQDN is case d). It is the only case that allows possible changes in the DNS to be picked up by clients.
FQDNでは、実際のアドレスへの解決が必要です。これは、FQDN解決をいつ行うべきかという質問を意味します。考えられる答えは2つあります。a）サーバーが起動したとき、b）サーバーがオプションを送信しようとしているとき、c）クライアントがオプションを受信した直後、d）によってオプションのコンテンツが実際に消費されたときのクライアント。 a）、b）、および場合によってはc）の場合、オプションは実際にはFQDNではなくアドレスを伝える必要があります。 FQDNを使用する唯一の真のインセンティブは、ケースd）です。これは、DNSで起こりうる変更をクライアントが取得できる唯一のケースです。
If the parameter is expected to be used by constrained devices (low power, battery operated, and low capabilities) or in very lossy networks, it may be appealing to drop the requirement of performing the DNS resolution and use addresses. Another example of a constrained device is a network-booted device, where despite the fact that the node itself is very capable once it's booted, the boot prom is quite constrained.
パラメータが制約のあるデバイス（低電力、バッテリ駆動、低機能）で使用されることが予想される場合、または非常に損失の多いネットワークで使用される場合、DNS解決の実行要件を削除してアドレスを使用することは魅力的です。制約付きデバイスのもう1つの例は、ネットワークブートデバイスです。ノード自体は、いったんブートすると非常に機能しますが、ブートプロムはかなり制約されます。
Another aspect that should be considered is time required for the clients to notice any configuration changes. Consider a case where a server configures service A using an address and service B using an FQDN. When an administrator decides to update the configuration, he or she can update the DHCP server configuration to change both services. If the clients do not support reconfigure (which is an optional feature of RFC 3315 but in some environments, e.g., cable modems, is mandatory), the configuration will be updated on the clients after the T1 timer elapses. Depending on the nature of the change (is it a new server added to a cluster of already operating servers or a new server that replaces the only available server that crashed?), this may be an issue. On the other hand, updating service B may be achieved with a DNS record update. That information may be cached by caching DNS servers for up to Time to Live (TTL). Depending on the values of T1 and TTL, one update may be faster than another. Furthermore, depending on the nature of the change (planned modification or unexpected failure), T1 or TTL may be lowered before the change to speed up new configuration adoption.
考慮すべきもう1つの側面は、クライアントが構成の変更に気付くのに必要な時間です。サーバーがアドレスを使用してサービスAを構成し、FQDNを使用してサービスBを構成する場合を考えます。管理者が構成を更新する場合、DHCPサーバー構成を更新して両方のサービスを変更できます。クライアントが再構成をサポートしていない場合（これはRFC 3315のオプション機能ですが、ケーブルモデムなどの一部の環境では必須です）、T1タイマーの経過後に構成がクライアントで更新されます。変更の性質（既に動作しているサーバーのクラスターに追加された新しいサーバーなのか、それともクラッシュした利用可能な唯一のサーバーを置き換える新しいサーバーなのか）によっては、これが問題になることがあります。一方、サービスBの更新は、DNSレコードの更新で実現できます。その情報は、最大の存続時間（TTL）までDNSサーバーをキャッシュすることによってキャッシュされます。 T1とTTLの値によっては、1つの更新が別の更新よりも高速になる場合があります。さらに、変更の性質（計画的な変更または予期しない障害）によっては、T1またはTTLを変更前に下げて、新しい構成の採用をスピードアップする場合があります。
Simply speaking, protocol designers don't know what the TTL or the T1 time will be, so they can't make assumptions about whether a DHCP option will be refreshed more quickly based on T1 or TTL.
簡単に言えば、プロトコル設計者はTTLまたはT1時間がどうなるかわからないため、T1またはTTLに基づいてDHCPオプションをより迅速に更新するかどうかを想定できません。
Addresses have the benefit of being easier to implement and handle by the DHCP software. An address option is simpler to use, has validation that is trivial (multiple of 16 constitutes a valid option), is explicit, and does not allow any ambiguity. It is faster (does not require extra round-trip time), so it is more efficient, which can be especially important for energy-restricted devices. It also does not require that the client implements a DNS resolution.
アドレスには、DHCPソフトウェアによる実装と処理が容易になるという利点があります。アドレスオプションは使いやすく、簡単な検証（16の倍数が有効なオプションを構成します）で、明示的で、あいまいさを許可しません。これはより高速（追加の往復時間を必要としない）なので、より効率的です。これは、エネルギー制限のあるデバイスにとって特に重要です。また、クライアントがDNS解決を実装する必要もありません。
An FQDN imposes a number of additional failure modes and issues that should be dealt with:
FQDNには、追加の障害モードと対処する必要のある問題がいくつかあります。
1. The client must have knowledge about available DNS servers. That typically means that option DNS_SERVERS [RFC3646] is mandatory. This should be mentioned in the document that defines the new option. It is possible that the server will return the FQDN option but not the DNS server's option. There should be a brief discussion about it;
1. クライアントは、使用可能なDNSサーバーに関する知識が必要です。これは通常、オプションDNS_SERVERS [RFC3646]が必須であることを意味します。これは、新しいオプションを定義するドキュメントで言及する必要があります。サーバーがFQDNオプションを返すが、DNSサーバーのオプションは返さない可能性があります。それについて簡単な議論があるはずです。
2. The DNS may not be reachable;
2. DNSに到達できない可能性があります。
3. The DNS may be available but may not have appropriate information (e.g., no AAAA records for the specified FQDN);
3. DNSは利用可能である可能性がありますが、適切な情報がない可能性があります（たとえば、指定されたFQDNのAAAAレコードがない）。
4. The address family must be specified (A, AAAA, or any); the information being configured may require a specific address family (e.g., IPv6), but there may be a DNS record only of another type (e.g., A only with an IPv4 address).
4. アドレスファミリを指定する必要があります（A、AAAA、またはその他）。構成されている情報には特定のアドレスファミリ（IPv6など）が必要な場合がありますが、別のタイプのDNSレコードしか存在しない場合があります（IPv4アドレスのAのみなど）。
5. What should the client do if there are multiple records available (use only the first one, use all, use one and switch to the second if the first fails for whatever reason, etc.). This may be an issue if there is an expectation that the parameter being configured will need exactly one address;
5. 複数のレコードが利用可能な場合にクライアントが行うべきこと（最初のレコードのみを使用し、すべてを使用し、1つを使用し、何らかの理由で最初のレコードが失敗した場合は2番目に切り替えるなど）。構成されているパラメーターが正確に1つのアドレスを必要とすることが予想される場合、これは問題になる可能性があります。
6. Multihomed devices may be connected to different administrative domains with each domain providing different information in the DNS (e.g., an enterprise network exposing private domains). The client may send DNS queries to a different DNS server; and
6. マルチホームデバイスは、異なる管理ドメインに接続されている可能性があります。各ドメインは、DNSで異なる情報を提供します（プライベートドメインを公開するエンタープライズネットワークなど）。クライアントは別のDNSサーバーにDNSクエリを送信できます。そして
7. It should be mentioned if Internationalized Domain Names are allowed. If they are, DNS option encoding should be specified.
7. 国際化ドメイン名が許可されているかどうかについて言及する必要があります。ある場合は、DNSオプションのエンコーディングを指定する必要があります。
Address options that are used with overly long T1 (renew timer) values have some characteristics of hard-coded values. That is strongly discouraged. See [RFC4085] for an in-depth discussion. If the option may appear in Information-request, its lifetime should be controlled using the information refresh time option [RFC4242].
過度に長いT1（タイマーの更新）値で使用されるアドレスオプションには、ハードコードされた値のいくつかの特性があります。それは強くお勧めできません。詳細な説明については、[RFC4085]を参照してください。オプションがInformation-requestに表示される場合、その有効期間は情報更新時間オプション[RFC4242]を使用して制御する必要があります。
One specific case that makes the choice between an address and an FQDN not obvious is a DNS Security (DNSSEC) bootstrap scenario. DNSSEC validation imposes a requirement for clock sync (to the accuracy reasonably required to consider signature inception and expiry times). This often implies usage of NTP configuration.
アドレスとFQDNの間の選択を明確にしない1つの特定のケースは、DNSセキュリティ（DNSSEC）ブートストラップシナリオです。 DNSSEC検証では、クロック同期の要件が課されます（署名の開始と有効期限を検討するために合理的に必要な精度で）。これは多くの場合、NTP構成の使用を意味します。
However, if NTP is provided as an FQDN, there is no way to validate its DNSSEC signature. This is a somewhat weak argument though, as providing an NTP server as an address is also not verifiable using DNSSEC. If the trustworthiness of the configuration provided by the DHCP server is in question, DHCPv6 offers mechanisms that allow server authentication.
ただし、NTPがFQDNとして提供されている場合、DNSSEC署名を検証する方法はありません。ただし、アドレスとしてNTPサーバーを提供することもDNSSECを使用して検証できないため、これはやや弱い議論です。 DHCPサーバーによって提供される構成の信頼性が疑わしい場合、DHCPv6はサーバー認証を可能にするメカニズムを提供します。
Most options are conveyed in a DHCPv6 message directly. Although there is no codified normative language for such options, they are often referred to as top-level options. Many options may include other options. Such inner options are often referred to as encapsulated or nested options. Those options are sometimes called sub-options, but this term actually means something else and, therefore, should never be used to describe encapsulated options. It is recommended to use the term "encapsulated" as this terminology is used in [RFC3315]. The difference between encapsulated and sub-options is that the former uses normal DHCPv6 option numbers, while the latter uses option number space specific to a given parent option. It should be noted that, contrary to DHCPv4, there is no shortage of option numbers; therefore, almost all options share a common option space. For example, option type 1 meant different things in DHCPv4, depending if it was located in the top level or inside of the Relay Agent Information option. There is no such ambiguity in DHCPv6 (with the exception of [RFC5908], which SHOULD NOT be used as a template for future DHCP option definitions).
ほとんどのオプションはDHCPv6メッセージで直接伝えられます。そのようなオプションの体系化された規範的な言語はありませんが、それらはしばしばトップレベルのオプションと呼ばれます。多くのオプションには他のオプションが含まれる場合があります。このような内部オプションは、多くの場合、カプセル化またはネストされたオプションと呼ばれます。これらのオプションはサブオプションと呼ばれることもありますが、この用語は実際には別の意味を持っているため、カプセル化されたオプションを説明するために使用するべきではありません。この用語は[RFC3315]で使用されているため、「カプセル化」という用語を使用することをお勧めします。カプセル化オプションとサブオプションの違いは、前者は通常のDHCPv6オプション番号を使用するのに対し、後者は特定の親オプションに固有のオプション番号スペースを使用することです。 DHCPv4とは異なり、オプション番号が不足することはありません。したがって、ほとんどすべてのオプションが共通のオプションスペースを共有します。たとえば、オプションタイプ1は、それがトップレベルにあるか、リレーエージェント情報オプション内にあるかに応じて、DHCPv4で異なる意味を持ちます。 DHCPv6にはそのようなあいまいさはありません（[RFC5908]を除き、将来のDHCPオプション定義のテンプレートとして使用すべきではありません）。
From the implementation perspective, it is easier to implement encapsulated options rather than sub-options, as the implementors do not have to deal with separate option spaces and can use the same buffer parser in several places throughout the code.
実装の観点からは、サブオプションよりもカプセル化されたオプションを実装する方が簡単です。実装者は個別のオプションスペースを処理する必要がなく、コード全体のいくつかの場所で同じバッファパーサーを使用できるためです。
Such encapsulation is not limited to one level. There is at least one defined option that is encapsulated twice: Identity Association for Prefix Delegation (IA_PD), as defined in Section 9 of [RFC3633], conveys the Identity Association (IA) Prefix (IAPREFIX), as defined in Section 10 of [RFC3633]. Such a delegated prefix may contain an excluded prefix range that is represented by the PD_EXCLUDE option that is conveyed as encapsulated inside IAPREFIX (PD_EXCLUDE is defined in [RFC6603]). It seems awkward to refer to such options as sub-sub-option or doubly encapsulated option; therefore, the "encapsulated option" term is typically used, regardless of the nesting level.
このようなカプセル化は1つのレベルに限定されません。 2回カプセル化された定義済みオプションが少なくとも1つあります。[RFC3633]のセクション9で定義されているプレフィックス委任のIDアソシエーション（IA_PD）は、[10で定義されているIDアソシエーション（IA）プレフィックス（IAPREFIX）を伝えます。 RFC3633]。このような委任されたプレフィックスには、IAPREFIX内にカプセル化されて伝達されるPD_EXCLUDEオプションによって表される除外プレフィックス範囲が含まれる場合があります（PD_EXCLUDEは[RFC6603]で定義されています）。サブサブオプションや二重にカプセル化されたオプションなどのオプションを参照するのは扱いにくいようです。したがって、ネストレベルに関係なく、通常「カプセル化オプション」という用語が使用されます。
When defining a DHCP-based configuration mechanism for a protocol that requires something more complex than a single option, it may be tempting to group configuration values using sub-options. That should preferably be avoided, as it increases complexity of the parser. It is much easier, faster, and less error prone to parse a large number of options on a single (top-level) scope than to parse options on several scopes. The use of sub-options should be avoided as much as possible, but it is better to use sub-options rather than conditional formatting.
単一のオプションよりも複雑なものを必要とするプロトコルに対してDHCPベースの構成メカニズムを定義する場合、サブオプションを使用して構成値をグループ化したくなるかもしれません。パーサーの複雑さが増すので、それは避けるべきです。単一の（トップレベルの）スコープで多数のオプションを解析する方が、いくつかのスコープでオプションを解析するよりもはるかに簡単で、高速で、エラーも少なくなります。サブオプションの使用はできるだけ避ける必要がありますが、条件付き書式設定よりもサブオプションを使用することをお勧めします。
It should be noted that currently there is no clear way defined for requesting sub-options. Most known implementations are simply using the top-level Option Request Option (ORO) for requesting both top-level and encapsulated options.
現在、サブオプションをリクエストするための明確な方法は定義されていないことに注意してください。ほとんどの既知の実装では、最上位のオプションとカプセル化されたオプションの両方を要求するために、最上位のオプション要求オプション（ORO）を使用しています。
DHCP is designed for provisioning clients. Less experienced protocol designers often assume that it is easy to define an option that will convey a different parameter for each client in a network. Such problems arose during designs of the Mapping of Address and Port (MAP) [MAP] and IPv4 Residual Deployment (4rd) [SOLUTION-4rd]. While it would be easier for provisioned clients to get ready to use per-client option values, such a requirement puts exceedingly large loads on the server side. The new extensions may introduce new implementation complexity and additional database state on the server. Alternatives should be considered, if possible. As an example, [MAP] was designed in a way that all clients are provisioned with the same set of MAP options, and each provisioned client uses its unique address and delegated prefix to generate client-specific information. Such a solution does not introduce any additional state for the server and, therefore, scales better.
DHCPはクライアントのプロビジョニング用に設計されています。経験の浅いプロトコル設計者は、ネットワーク内のクライアントごとに異なるパラメーターを伝達するオプションを簡単に定義できると考えていることがよくあります。このような問題は、アドレスとポートのマッピング（MAP）[MAP]およびIPv4残余配備（4rd）[SOLUTION-4rd]の設計中に発生しました。プロビジョニングされたクライアントがクライアントごとのオプション値を使用する準備をするのは簡単ですが、そのような要件はサーバー側に非常に大きな負荷をかけます。新しい拡張機能により、サーバーに新しい実装の複雑さと追加のデータベース状態が導入される可能性があります。可能であれば、代替案を検討する必要があります。例として、[MAP]は、すべてのクライアントが同じMAPオプションのセットでプロビジョニングされ、プロビジョニングされた各クライアントが固有のアドレスと委任されたプレフィックスを使用してクライアント固有の情報を生成するように設計されています。このようなソリューションは、サーバーに追加の状態を導入しないため、拡張性が向上します。
It also should be noted that contrary to DHCPv4, DHCPv6 keeps several timers for renewals. Each IA_NA (addresses) and IA_PD (prefixes) contains T1 and T2 timers that designate time after which the client will initiate renewal. Those timers apply only to their associated IA containers. Refreshing other parameters should be initiated after a time specified in the information refresh time option (defined in [RFC4242]), carried in the Reply message, and returned in response to the Information-request message. Introducing additional timers make deployment unnecessarily complex and SHOULD be avoided.
DHCPv4とは異なり、DHCPv6は更新のためにいくつかのタイマーを保持することにも注意してください。各IA_NA（アドレス）およびIA_PD（プレフィックス）には、クライアントが更新を開始するまでの時間を指定するT1およびT2タイマーが含まれています。これらのタイマーは、関連するIAコンテナーにのみ適用されます。他のパラメータの更新は、情報更新時間オプション（[RFC4242]で定義）で指定された時間の後に開始され、応答メッセージで送信され、情報要求メッセージへの応答として返されます。追加のタイマーを導入すると、展開が不必要に複雑になるため、回避する必要があります。
In general, DHCPv6 clients only refresh configuration data from the DHCP server when the T1 timer expires. Although there is a Reconfigure mechanism that allows a DHCP server to request that clients initiate reconfiguration, support for this mechanism is optional and cannot be relied upon.
一般に、DHCPv6クライアントは、T1タイマーの期限が切れたときにのみDHCPサーバーから構成データを更新します。 DHCPサーバーがクライアントに再構成の開始を要求できるようにする再構成メカニズムがありますが、このメカニズムのサポートはオプションであり、信頼することはできません。
Even when DHCP clients refresh their configuration information, not all consumers of DHCP-sourced configuration data notice these changes. For instance, if a server is started using parameters received in an early DHCP transaction, but does not check for updates from DHCP, it may well continue to use the same parameter indefinitely. There are a few operating systems that take care of reconfiguring services when the client moves to a new network (e.g., based on mechanisms like [RFC4436], [RFC4957], or [RFC6059]), but it's worth bearing in mind that a renew may not always result in the client taking up new configuration information that it receives.
DHCPクライアントが構成情報を更新しても、DHCPソースの構成データのすべてのコンシューマーがこれらの変更に気付くとは限りません。たとえば、サーバーが初期のDHCPトランザクションで受信したパラメーターを使用して起動されたが、DHCPからの更新をチェックしない場合、同じパラメーターを無期限に使用し続ける可能性があります。クライアントが新しいネットワークに移動したときにサービスを再構成するオペレーティングシステムがいくつかあります（たとえば、[RFC4436]、[RFC4957]、または[RFC6059]のようなメカニズムに基づいています）が、更新することは覚えておく価値があります常にクライアントが受信した新しい構成情報を取得するわけではありません。
In light of the above, when designing an option you should take into consideration the fact that your option may hold stale data that will only be updated at an arbitrary time in the future.
上記を考慮して、オプションを設計するときは、オプションが将来の任意の時点でのみ更新される古いデータを保持する可能性があるという事実を考慮する必要があります。
In some cases, there could be more than one DHCPv6 server on a link, with each providing a different set of parameters. One notable example of such a case is a home network with a connection to two independent ISPs.
場合によっては、リンク上に複数のDHCPv6サーバーがあり、それぞれが異なるパラメーターのセットを提供することがあります。このようなケースの注目すべき例の1つは、2つの独立したISPに接続するホームネットワークです。
The DHCPv6 specification does not provide clear advice on how to handle multiple provisioning sources. Although [RFC3315] states that a client that receives more than one Advertise message may respond to one or more of them, such capability has not been observed in existing implementations. Existing clients will pick one server and will continue the configuration process with that server, ignoring all other servers.
DHCPv6仕様では、複数のプロビジョニングソースの処理方法に関する明確なアドバイスは提供されていません。 [RFC3315]は、複数のアドバタイズメッセージを受信するクライアントがそれらの1つ以上に応答する可能性があると述べていますが、そのような機能は既存の実装では確認されていません。既存のクライアントは1つのサーバーを選択し、他のすべてのサーバーを無視して、そのサーバーで構成プロセスを続行します。
In addition, a node that acts as a DHCPv6 client may be connected to more than one physical network. In most cases, it will operate a separate DHCP client state machine on each interface and acquire different, possibly conflicting, information through each. This information will not be acquired in any synchronized way.
さらに、DHCPv6クライアントとして機能するノードは、複数の物理ネットワークに接続できます。ほとんどの場合、それは各インターフェイスで個別のDHCPクライアントステートマシンを操作し、それぞれを通じて異なる、おそらく競合する情報を取得します。この情報は同期された方法で取得されません。
Existing nodes cannot be assumed to systematically segregate configuration information on the basis of its source; as a result, it is quite possible that a node may receive an FQDN on one network interface but do the DNS resolution on a different network interface, using different DNS servers. As a consequence, DNS resolution done by the DHCP server is more likely to behave predictably than DNS resolution done on a multi-interface or multihomed client.
既存のノードは、そのソースに基づいて構成情報を体系的に分離すると想定することはできません。その結果、ノードが1つのネットワークインターフェイスでFQDNを受信し、別のDNSサーバーを使用して別のネットワークインターフェイスでDNS解決を行う可能性があります。その結果、DHCPサーバーによって行われるDNS解決は、マルチインターフェイスまたはマルチホームクライアントで行われるDNS解決よりも予測どおりに動作する可能性が高くなります。
This is a generic DHCP issue and should not be dealt within each option separately. This issue is better dealt with using a protocol-level solution, and fixing this problem should not be attempted on a per-option basis. Work is ongoing in the IETF to provide a systematic solution to this problem.
これは一般的なDHCPの問題であり、各オプション内で個別に処理するべきではありません。この問題は、プロトコルレベルのソリューションを使用してより適切に処理されます。この問題の修正は、オプションごとに試みるべきではありません。 IETFでは、この問題を体系的に解決するための作業が進行中です。
Adding a simple DHCP option is straightforward and generally something that any working group (WG) can do, perhaps with some help from designated DHCP experts. However, when new fragment types need to be devised, this requires the attention of DHCP experts and should not be done in a WG that doesn't have a quorum of such experts. This is true whether the new fragment type has the same structure as an existing fragment type but with different semantics, or the new format has a new structure.
単純なDHCPオプションを追加するのは簡単で、通常、どのワーキンググループ（WG）でも、指定されたDHCPエキスパートの助けを借りて行うことができます。ただし、新しいフラグメントタイプを考案する必要がある場合、これはDHCPの専門家の注意が必要であり、そのような専門家の定足数のないWGでは行わないでください。これは、新しいフラグメントタイプが既存のフラグメントタイプと同じ構造であるが、セマンティクスが異なる場合でも、新しいフォーマットで新しい構造を持つ場合でも同じです。
Responsible Area Directors for WGs that wish to add a work item to a WG charter to define a new DHCP option should get clarity from the WG as to whether the new option will require a new fragment type or new semantics, or whether it is a simple DHCP option that fits existing definitions.
新しいDHCPオプションを定義するためにWGチャーターにワークアイテムを追加したいWGの担当エリアディレクターは、新しいオプションが新しいフラグメントタイプまたは新しいセマンティクスを必要とするかどうか、またはそれが単純かどうかについて、WGから明確にする必要があります既存の定義に適合するDHCPオプション。
If a WG needs a new fragment type, it is preferable to see if another WG exists whose members already have sufficient expertise to evaluate the new work. If such a working group is available, the work should be chartered in that working group instead. If there is no other WG with DHCP expertise that can define the new fragment type, the responsible AD should seek help from known DHCP experts within the IETF to provide advice and frequent early review as the original WG defines the new fragment type.
WGに新しいフラグメントタイプが必要な場合は、新しい作業を評価するのに十分な専門知識をメンバーがすでに持っている別のWGが存在するかどうかを確認することをお勧めします。そのようなワーキンググループが利用可能な場合は、代わりにそのワーキンググループで作業をチャーターする必要があります。新しいフラグメントタイプを定義できるDHCPの専門知識を持つ他のWGがない場合、担当のADはIETF内の既知のDHCPエキスパートに助言を求め、元のWGが新しいフラグメントタイプを定義するときにアドバイスと頻繁な早期レビューを提供する必要があります。
In either case, the new option should be defined in a separate document, and the work should focus on defining a new format that generalizes well and can be reused, rather than a single-use fragment type. The WG that needs the new fragment type can define their new option referencing the new fragment type document, and the work can generally be done in parallel, avoiding unnecessary delays. Having the definition in its own document will foster reuse of the new fragment type.
どちらの場合でも、新しいオプションは別のドキュメントで定義する必要があり、作業は、使い捨てのフラグメントタイプではなく、一般化されて再利用できる新しい形式の定義に重点を置く必要があります。新しいフラグメントタイプを必要とするWGは、新しいフラグメントタイプのドキュメントを参照する新しいオプションを定義できます。作業は通常、並行して行うことができ、不要な遅延を回避できます。独自のドキュメントに定義を含めると、新しいフラグメントタイプの再利用が促進されます。
The responsible AD should work with all relevant WG Chairs and DHCP experts to ensure that the new fragment type document has in fact been carefully reviewed by the experts and appears satisfactory.
責任あるADは、関連するすべてのWG議長およびDHCPの専門家と協力して、新しいフラグメントタイプのドキュメントが専門家によって実際に注意深くレビューされ、満足のいくものであることを確認する必要があります。
Responsible Area Directors for WGs that are considering defining options that actually update DHCP, as opposed to simple options, should go through a process similar to that described above when trying to determine where to do the work. Under no circumstances should a WG be given a charter deliverable to define a new DHCP option, and then on the basis of that charter item actually make updates to DHCP.
単純なオプションではなく、DHCPを実際に更新するオプションの定義を検討しているWGの担当エリアディレクターは、作業を行う場所を決定する際に、上記と同様のプロセスを実行する必要があります。いかなる状況においても、新しいDHCPオプションを定義するためにWGにチャーター成果物が提供されてはならず、そのチャーター項目に基づいて実際にDHCPを更新します。
When defining new options, one specific consideration to evaluate is whether or not options of a similar format would need to have multiple or single values encoded (whatever differs from the current option) and how that might be accomplished in a similar format.
新しいオプションを定義する場合、評価する1つの特定の考慮事項は、同様の形式のオプションで複数の値または単一の値をエンコードする必要があるかどうか（現在のオプションとは異なるもの）と、それを同様の形式で実現する方法です。
When defining a new option, it is best to synthesize the option format using fragment types already in use. However, in some cases, there may be no fragment type that accomplishes the intended purpose.
新しいオプションを定義するときは、すでに使用されているフラグメントタイプを使用してオプションフォーマットを合成するのが最適です。ただし、場合によっては、意図した目的を達成するフラグメントタイプがないことがあります。
The matter of size considerations and option order are further discussed in Sections 15 and 17.
サイズの考慮事項とオプションの順序については、セクション15と17でさらに説明します。
DHCPv6 [RFC3315] allows for packet sizes up to 64 KB. First, through its use of link-local addresses, it avoids many of the deployment problems that plague DHCPv4 and is actually a UDP over the IPv6-based protocol (compared to DHCPv4, which is mostly UDP over IPv4 but with layer-2 hacks). Second, RFC 3315 explicitly refers readers to Section 5 of [RFC2460], which describes an MTU of 1280 octets and a minimum fragment reassembly of 1500 octets. It's feasible to suggest that DHCPv6 is capable of having larger options deployed over it, and at least no common upper limit is yet known to have been encoded by its implementors. It is not really possible to describe a fixed limit that cleanly divides workable option sizes from those that are too big.
DHCPv6 [RFC3315]では、最大64 KBのパケットサイズが可能です。まず、リンクローカルアドレスを使用することにより、DHCPv4を悩ませる実際のIPv6ベースのプロトコル上のUDPである多くの展開の問題を回避します（ほとんどがIPv4上のUDPですが、レイヤー2のハックがあるDHCPv4と比較して）。 。第2に、RFC 3315は読者に[RFC2460]のセクション5を明示的に示しています。このセクションでは、MTUが1280オクテットであり、フラグメントの最小の再構成が1500オクテットであると説明しています。 DHCPv6は、DHCPv6を介してより大きなオプションを展開できることを示唆することは現実的であり、少なくとも一般的な上限は、その実装者によってエンコードされていることがまだわかっていません。実行可能なオプションのサイズを、大きすぎるオプションのサイズから明確に分割する固定制限を説明することは実際には不可能です。
It is advantageous to prefer option formats that contain the desired information in the smallest form factor that satisfies the requirements. Common sense still applies here. It is better to split distinct values into separate octets rather than propose overly complex bit-shifting operations to save several bits (or even an octet or two) that would be padded to the next octet boundary anyway.
要件を満たす最小のフォームファクタで目的の情報を含むオプション形式を選択することは有利です。ここでも常識が当てはまります。過度に複雑なビットシフト操作を提案して、とにかく次のオクテット境界にパディングされるいくつかのビット（または1オクテットまたは2オクテット）を保存するよりも、個別の値を別々のオクテットに分割する方が適切です。
DHCPv6 does allow for multiple instances of a given option, and they are treated as distinct values following the defined format; however, this feature is generally preferred to be restricted to protocol class features (such as the IA_* series of options). In such cases, it is better to define an option as an array if it is possible. It is recommended to clarify (with normative language) whether a given DHCPv6 option may appear once or multiple times. The default assumption is only once.
DHCPv6では、特定のオプションの複数のインスタンスが許可されており、定義された形式に従って異なる値として扱われます。ただし、この機能は一般に、プロトコルクラスの機能（IA_ *シリーズのオプションなど）に限定することが推奨されます。そのような場合、可能であればオプションを配列として定義することをお勧めします。特定のDHCPv6オプションが1回または複数回現れるかどうかを（規範的な言語で）明確にすることをお勧めします。デフォルトの仮定は一度だけです。
In general, if a lot of data needs to be configured (for example, some option lengths are quite large), DHCPv6 may not be the best choice to deliver such configuration information and SHOULD simply be used to deliver a URI that specifies where to obtain the actual configuration information.
一般に、大量のデータを構成する必要がある場合（たとえば、オプションの長さが非常に大きい場合）、DHCPv6はそのような構成情報を配信するのに最適な選択ではない可能性があり、取得先を指定するURIを配信するためだけに使用する必要があります（SHOULD）。実際の構成情報。
Although [RFC3315] states that each option type MAY appear more than once, the original idea was that multiple instances are reserved for stateful options, like IA_NA or IA_PD. For most other options, it is usually expected that they will appear once at most. Such options are called singleton options. Sadly, RFCs have often failed to clearly specify whether or not a given option can appear more than once.
[RFC3315]は各オプションタイプが複数回出現する可能性があると述べていますが、当初の考えでは、IA_NAやIA_PDなどの複数のインスタンスがステートフルオプション用に予約されていました。他のほとんどのオプションの場合、通常、これらのオプションはせいぜい一度だけ表示されることが予想されます。このようなオプションは、シングルトンオプションと呼ばれます。悲しいことに、RFCは多くの場合、特定のオプションを複数回表示できるかどうかを明確に指定できていません。
Documents that define new options SHOULD state whether or not these options are singletons. Unless otherwise specified, newly defined options are considered to be singletons. If multiple instances are allowed, the document MUST explain how to use them. Care should be taken not to assume that they will be processed in the order they appear in the message. See Section 17 for more details.
新しいオプションを定義するドキュメントは、これらのオプションがシングルトンかどうかを記載する必要があります。特に指定のない限り、新しく定義されたオプションはシングルトンと見なされます。複数のインスタンスが許可されている場合、ドキュメントではそれらの使用方法を説明する必要があります。メッセージに表示される順序で処理されると想定しないように注意してください。詳細については、セクション17を参照してください。
When deciding whether single or multiple option instances are allowed in a message, take into consideration how the content of the option will be used. Depending on the service being configured, it may or may not make sense to have multiple values configured. If multiple values make sense, it is better to explicitly allow that by using an option format that allows multiple values within one option instance.
メッセージで単一または複数のオプションインスタンスを許可するかどうかを決定するときは、オプションのコンテンツの使用方法を考慮してください。構成されているサービスによっては、複数の値を構成しても意味がない場合があります。複数の値に意味がある場合は、1つのオプションインスタンス内で複数の値を許可するオプション形式を使用して、明示的に許可することをお勧めします。
Allowing multiple option instances often leads to confusion. Consider the following example. Basic DS-Lite architecture assumes that the B4 element (DHCPv6 client) will receive the AFTR option and establish a single tunnel to the configured tunnel termination point (AFTR). During the standardization process of [RFC6334], there was a discussion whether multiple instances of the DS-Lite tunnel option should be allowed. This created an unfounded expectation that the clients receiving multiple instances of the option will somehow know when one tunnel endpoint goes offline and do some sort of failover between other values provided in other instances of the AFTR option. Others assumed that if there are multiple options, the client will somehow do load balancing between the provided tunnel endpoints. Neither failover nor load balancing was defined for the DS-Lite architecture, so it caused confusion. It was eventually decided to allow only one instance of the AFTR option.
複数のオプションインスタンスを許可すると、混乱が生じることがよくあります。次の例を考えてみましょう。基本的なDS-Liteアーキテクチャは、B4要素（DHCPv6クライアント）がAFTRオプションを受信し、構成されたトンネル終端ポイント（AFTR）への単一のトンネルを確立することを前提としています。 [RFC6334]の標準化プロセス中に、DS-Liteトンネルオプションの複数のインスタンスを許可する必要があるかどうかについての議論がありました。これにより、オプションの複数のインスタンスを受信するクライアントが、1つのトンネルエンドポイントがオフラインになったことを何らかの形で知り、AFTRオプションの他のインスタンスで提供される他の値の間で何らかのフェイルオーバーを実行するという根拠のない期待が生まれました。他の人たちは、複数のオプションがある場合、クライアントは提供されたトンネルエンドポイント間で何らかの形でロードバランシングを行うと想定していました。 DS-Liteアーキテクチャにはフェイルオーバーもロードバランシングも定義されていなかったため、混乱を招きました。最終的に、AFTRオプションの1つのインスタンスのみを許可することが決定されました。
Option order, either the order among many DHCPv6 options or the order of multiple instances of the same option, SHOULD NOT be significant. New documents MUST NOT assume any specific option processing order.
多くのDHCPv6オプション間の順序または同じオプションの複数のインスタンスの順序のいずれかであるオプションの順序は、重要ではありません。新しいドキュメントは、特定のオプション処理順序を想定してはなりません。
As there is no explicit order for multiple instances of the same option, an option definition SHOULD instead restrict ordering by using a single option that contains ordered fields.
同じオプションの複数のインスタンスには明示的な順序がないため、オプションの定義では、順序付けされたフィールドを含む単一のオプションを使用して順序を制限する必要があります（SHOULD）。
As [RFC3315] does not impose option order, some implementations use hash tables to store received options (which is a conformant behavior). Depending on the hash implementation, the processing order is almost always different then the order in which the options appeared in the packet on the wire.
[RFC3315]はオプションの順序を強制しないため、一部の実装ではハッシュテーブルを使用して受信したオプションを格納します（これは適合動作です）。ハッシュの実装に応じて、処理順序は、ほとんどの場合、オプションがワイヤ上のパケットに現れた順序とは異なります。
In DHCPv4, all relay options are organized as sub-options within the DHCP Relay Agent Information option [RFC3046]. And, an independent number space called "DHCP Relay Agent Sub-options" is maintained by IANA. Different from DHCPv4, in DHCPv6, relay options are defined in the same way as client/server options, and they also use the same option number space as client/server options. Future DHCPv6 relay options MUST be allocated from this single DHCPv6 option number space.
DHCPv4では、すべてのリレーオプションは、DHCPリレーエージェント情報オプション[RFC3046]内のサブオプションとして編成されています。また、「DHCPリレーエージェントサブオプション」と呼ばれる独立した番号スペースがIANAによって維持されます。 DHCPv4とは異なり、DHCPv6では、リレーオプションはクライアント/サーバーオプションと同じ方法で定義され、クライアント/サーバーオプションと同じオプション番号スペースを使用します。今後のDHCPv6リレーオプションは、この単一のDHCPv6オプション番号スペースから割り当てる必要があります。
For example, the Relay-Supplied Options option [RFC6422] may also contain some DHCPv6 options as permitted, such as the Extensible Authentication Protocol (EAP) Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option [RFC6440].
たとえば、Relay-Supplied Optionsオプション[RFC6422]には、拡張認証プロトコル（EAP）再認証プロトコル（ERP）ローカルドメイン名DHCPv6オプション[RFC6440]など、許可されたDHCPv6オプションも含まれている場合があります。
The DHCPv6 Option Request Option (OPTION_ORO) [RFC3315] is an option that serves two purposes -- to inform the server what options the client supports and what options the client is willing to consume.
DHCPv6オプション要求オプション（OPTION_ORO）[RFC3315]は、クライアントがサポートするオプションとクライアントが消費するオプションをサーバーに通知するという2つの目的を果たすオプションです。
For some options, such as the options required for the functioning of DHCPv6 itself, it doesn't make sense to require that they be explicitly requested using the Option Request Option. In all other cases, it is prudent to assume that any new option must be present on the relevant option request list if the client desires to receive it.
DHCPv6自体の機能に必要なオプションなど、一部のオプションについては、オプション要求オプションを使用して明示的に要求することを要求しても意味がありません。他のすべてのケースでは、クライアントがそれを受け取りたい場合、関連するオプション要求リストに新しいオプションが存在する必要があると想定するのが賢明です。
It is tempting to add text that requires the client to include a new option in the Option Request Option list, similar to this text: "Clients MUST place the foo option code on the Option Request Option list, clients MAY include option foo in their packets as hints for the server as values the desire, and servers MUST include option foo when the client requests it (and the server has been so configured)". Such text is discouraged as there are several issues with it. First, it assumes that client implementation that supports a given option will always want to use it. This is not true. The second and more important reason is that such text essentially duplicates the mechanism already defined in [RFC3315]. It is better to simply refer to the existing mechanism rather than define it again. See Section 21 for proposed examples on how to do that.
次のテキストのように、クライアントがオプション要求オプションリストに新しいオプションを含めることを要求するテキストを追加するのは魅力的です。「クライアントはオプション要求オプションリストにfooオプションコードを配置する必要があります。クライアントはオプションfooをパケットに含めることができます（MAY）サーバーへのヒントとしての値としての望み。サーバーは、クライアントが要求するときにオプションfooを含める必要があります（そしてサーバーはそのように構成されています）。このようなテキストにはいくつかの問題があるため、推奨されません。最初に、特定のオプションをサポートするクライアント実装が常にそれを使用することを想定しています。本当じゃない。 2番目のより重要な理由は、そのようなテキストが[RFC3315]ですでに定義されているメカニズムを本質的に複製していることです。再度定義するよりも、単に既存のメカニズムを参照する方が適切です。その方法の提案例については、セクション21を参照してください。
Creators of DHCPv6 options cannot assume special ordering of options either as they appear in the Option Request Option or as they appear within the packet. Although it is reasonable to expect that options will be processed in the order they appear in ORO, server software is not required to sort DHCPv6 options into the same order in Reply messages.
DHCPv6オプションの作成者は、オプション要求オプションに表示されるとき、またはパケット内に表示されるときに、オプションの特別な順序を想定できません。オプションがOROに表示される順序で処理されることを期待するのは合理的ですが、サーバーソフトウェアはDHCPv6オプションを返信メッセージで同じ順序にソートする必要はありません。
It should also be noted that options values are not required to be aligned within the DHCP packet; even the option code and option length may appear on odd-byte boundaries.
オプション値はDHCPパケット内で調整する必要がないことにも注意してください。オプションコードとオプションの長さも奇数バイトの境界に表示される場合があります。
The transition from IPv4 to IPv6 is progressing. Many transition technologies are proposed to speed it up. As a natural consequence, there are also DHCP options proposed to provision those proposals. The inevitable question is whether the required parameters should be delivered over DHCPv4 or DHCPv6. Authors often don't give much thought about it and simply pick DHCPv6 without realizing the consequences. IPv6 is expected to stay with us for many decades, and so is DHCPv6. There is no mechanism available to deprecate an option in DHCPv6, so any options defined will stay with us as long as the DHCPv6 protocol itself lasts. It seems likely that such options defined to transition from IPv4 will outlive IPv4 by many decades. From that perspective, it is better to implement provisioning of the transition technologies in DHCPv4, which will be obsoleted together with IPv4.
IPv4からIPv6への移行が進んでいます。それをスピードアップするために多くの移行技術が提案されています。当然の結果として、それらの提案をプロビジョニングするために提案されたDHCPオプションもあります。避けられない問題は、必要なパラメータをDHCPv4とDHCPv6のどちらで配信するかです。多くの場合、作成者はそれについてあまり考慮せず、結果を認識せずにDHCPv6を選択します。 IPv6は何十年も私たちと一緒にいることが期待されており、DHCPv6もそうです。 DHCPv6のオプションを廃止するためのメカニズムはありません。そのため、DHCPv6プロトコル自体が存続する限り、定義されたオプションはそのまま残ります。 IPv4から移行するように定義されたそのようなオプションは、何十年もの間IPv4よりも長く存続するようです。その観点から、IPv4と共に廃止されるDHCPv4で移行テクノロジのプロビジョニングを実装することをお勧めします。
When the network infrastructure becomes IPv6 only, the support for IPv4-only nodes may still be needed. In such a scenario, a mechanism for providing IPv4 configuration information over IPv6-only networks may be needed. See [IPv4-CONFIG] for further details.
ネットワークインフラストラクチャがIPv6のみになった場合でも、IPv4のみのノードのサポートが必要になることがあります。このようなシナリオでは、IPv6のみのネットワークを介してIPv4構成情報を提供するメカニズムが必要になる場合があります。詳細については、[IPv4-CONFIG]を参照してください。
There are three major entities in DHCPv6: server, relay agent, and client. It is very helpful for implementors to include separate sections that describe operation for those three major entities. Even when a given entity does not participate, it is useful to have a very short section stating that it must not send a given option and must ignore it when received.
DHCPv6には、サーバー、リレーエージェント、およびクライアントの3つの主要なエンティティがあります。これらの3つの主要なエンティティの操作を説明する個別のセクションを含めることは、実装者にとって非常に役立ちます。特定のエンティティが参加しない場合でも、特定のオプションを送信してはならず、受信時に無視する必要があることを示す非常に短いセクションがあると便利です。
There is also a separate entity called the "requestor", which is a special client-like type that participates in the leasequery protocol [RFC5007] [RFC5460]. A similar section for the requestor is not required, unless the new option has anything to do with the requestor (or it is likely that the reader may think that is has). It should be noted that while in the majority of deployments the requestor is co-located with the relay agent, those are two separate entities from the protocol perspective, and they may be used separately. There are stand-alone requestor implementations available.
「リクエスタ」と呼ばれる別のエンティティもあります。これは、leasequeryプロトコル[RFC5007] [RFC5460]に参加する、クライアントのような特殊なタイプです。新しいオプションがリクエスタと関係がある場合を除いて、リクエスタの同様のセクションは必要ありません（または、読者がそうであると考える可能性があります）。大部分の配置では、リクエスタはリレーエージェントと同じ場所に配置されますが、これらはプロトコルの観点からは2つの別個のエンティティであり、それらは別々に使用できます。スタンドアロンのリクエスタ実装が利用可能です。
The following sections include proposed text for such sections. That text is not required to appear, but it is appropriate in most cases. Additional or modified text specific to a given option is often required.
次のセクションには、そのようなセクションの提案されたテキストが含まれています。このテキストは表示する必要はありませんが、ほとんどの場合は適切です。多くの場合、特定のオプションに固有の追加または変更されたテキストが必要です。
Although the requestor is a somewhat uncommon functionality, its existence should be noted, especially when allowing or disallowing options to appear in certain messages or to be sent by certain entities. Additional message types may appear in the future, besides types defined in [RFC3315]. Therefore, authors are encouraged to familiarize themselves with a list of currently defined DHCPv6 messages available on the IANA website [IANA].
リクエスタはやや一般的ではない機能ですが、特にそのオプションを特定のメッセージに表示したり、特定のエンティティから送信したりすることを許可または禁止する場合は、その存在に注意する必要があります。 [RFC3315]で定義されているタイプに加えて、今後、追加のメッセージタイプが表示される可能性があります。したがって、作成者は、IANA Webサイト[IANA]で入手可能な、現在定義されているDHCPv6メッセージのリストをよく理解することをお勧めします。
Typically, new options are requested by clients and assigned by the server, so there is no specific relay behavior. Nevertheless, it is good to include a section for relay agent behavior and simply state that there are no additional requirements for relays. The same applies for client behavior if the options are to be exchanged between the relay and server.
通常、新しいオプションはクライアントによって要求され、サーバーによって割り当てられるため、特定のリレー動作はありません。それでも、リレーエージェントの動作に関するセクションを含めて、リレーに追加の要件はないことを示すだけでかまいません。オプションがリレーとサーバーの間で交換される場合、クライアントの動作にも同じことが当てはまります。
Sections that contain option definitions MUST include a formal verification procedure. Often it is very simple, e.g., an option that conveys an IPv6 address must be exactly 16-bytes long, but sometimes the rules are more complex. It is recommended to refer to existing documents (e.g., Section 8 of RFC 3315 for domain name encoding) rather than trying to repeat such rules.
オプション定義を含むセクションには、正式な検証手順を含める必要があります。多くの場合、それは非常に単純です。たとえば、IPv6アドレスを伝達するオプションは正確に16バイト長でなければなりませんが、ルールがより複雑になる場合があります。このようなルールを繰り返すのではなく、既存のドキュメント（ドメイン名のエンコードについてはRFC 3315のセクション8など）を参照することをお勧めします。
Clients MAY request option foo, as defined in [RFC3315], Sections 17.1.1, 18.1.1, 18.1.3, 18.1.4, 18.1.5, and 22.7. As a convenience to the reader, we mention here that the client includes requested option codes in the Option Request Option.
[RFC3315]、セクション17.1.1、18.1.1、18.1.3、18.1.4、18.1.5、および22.7で定義されているように、クライアントはオプションfooを要求できます（MAY）。読者の便宜のため、ここではクライアントがオプション要求オプションに要求されたオプションコードを含めることを述べます。
Optional text (if the client's hints make sense): The client also MAY include option foo in its Solicit, Request, Renew, Rebind, and Information-request messages as a hint for the server regarding preferred option values.
オプションのテキスト（クライアントのヒントに意味がある場合）：クライアントは、推奨オプション値に関するサーバーのヒントとして、要請メッセージ、要求、更新、再バインド、および情報要求メッセージにオプションfooを含めることもできます（MAY）。
Optional text (if the option contains an FQDN): If the client requests an option that conveys an FQDN, it is expected that the contents of that option will be resolved using DNS. Hence, the following text may be useful: Clients that request option foo SHOULD also request option OPTION_DNS_SERVERS as specified in [RFC3646].
オプションのテキスト（オプションにFQDNが含まれている場合）：クライアントがFQDNを伝えるオプションを要求した場合、そのオプションの内容はDNSを使用して解決されることが期待されます。したがって、次のテキストが役立つ場合があります。オプションfooを要求するクライアントは、[RFC3646]で指定されているオプションOPTION_DNS_SERVERSも要求する必要があります（SHOULD）。
Clients MUST discard option foo if it is invalid (i.e., it did not pass the validation steps defined in Section X.Y).
クライアントは、オプションfooが無効な場合（つまり、セクションX.Yで定義されている検証手順に合格しなかった場合）は破棄する必要があります。
Optional text (if option foo in expected to be exchanged between relays and servers): Option foo is exchanged between relays and servers only. Clients are not aware of the usage of option foo. Clients MUST ignore received option foo.
オプションのテキスト（オプションfooがリレーとサーバー間で交換されることが予想される場合）：オプションfooはリレーとサーバー間でのみ交換されます。クライアントはオプションfooの使用法を認識していません。クライアントは受信したオプションfooを無視する必要があります。
Sections 17.2.2 and 18.2 of [RFC3315] govern server operation in regards to option assignment. As a convenience to the reader, we mention here that the server will send option foo only if configured with specific values for foo and if the client requested it.
[RFC3315]のセクション17.2.2と18.2は、オプションの割り当てに関するサーバーの動作を管理します。ここでは、読者の便宜のために、サーバーがオプションfooを送信するのは、fooに特定の値が設定されていて、クライアントが要求した場合のみであることを述べます。
Optional text: Option foo is a singleton. Servers MUST NOT send more than one instance of the foo option.
オプションのテキスト：オプションfooはシングルトンです。サーバーは、fooオプションの複数のインスタンスを送信してはなりません（MUST NOT）。
Optional text (if the server is never supposed to receive option foo): Servers MUST ignore the incoming foo option.
オプションのテキスト（サーバーがオプションfooを受信することが想定されていない場合）：サーバーは着信fooオプションを無視する必要があります。
It's never appropriate for a relay agent to add options to a message heading toward the client, and relay agents don't actually construct Relay-reply messages anyway.
リレーエージェントがクライアントに向かうメッセージにオプションを追加することは決して適切ではなく、リレーエージェントは実際にはいずれにしてもリレー応答メッセージを作成しません。
Optional text (if the foo option is exchanged between the clients and server or between requestors and servers): there are no additional requirements for relays.
オプションのテキスト（fooオプションがクライアントとサーバー間またはリクエスターとサーバー間で交換される場合）：リレーに関する追加の要件はありません。
Optional text (if relays are expected to insert or consume option foo): Relay agents MAY include option foo in a Relay-forward message when forwarding packets from clients to the servers.
オプションのテキスト（リレーがオプションfooを挿入または消費すると予想される場合）：リレーエージェントは、クライアントからサーバーにパケットを転送するときに、リレー転送メッセージにオプションfooを含めることができます（MAY）。
Authors often ask themselves whether their proposal updates existing RFCs, especially RFC 3315. In April 2013, there were about 80 options defined. Had all documents that defined them also updated RFC 3315, comprehension of such a document set would be extremely difficult. It should be noted that "extends" and "updates" are two very different verbs. If a new document defines a new option that clients request and servers provide, it merely extends current standards, so "updates RFC 3315" is not required in the new document header. On the other hand, if a new document replaces or modifies existing behavior and includes clarifications or other corrections, it should be noted that it updates the other document. For example, [RFC6644] clearly updates [RFC3315] as it replaces existing text with new text.
著者はしばしば、自分の提案が既存のRFC、特にRFC 3315を更新するかどうかを自問します。2013年4月には、約80のオプションが定義されました。それらを定義したすべてのドキュメントがRFC 3315も更新した場合、そのようなドキュメントセットの理解は非常に困難になります。 「拡張」と「更新」は2つの非常に異なる動詞であることに注意してください。新しいドキュメントがクライアントの要求とサーバーが提供する新しいオプションを定義する場合、それは現在の標準を拡張するだけなので、新しいドキュメントヘッダーに「更新RFC 3315」は必要ありません。一方、新しいドキュメントが既存の動作を置き換えまたは変更し、説明やその他の修正が含まれている場合は、他のドキュメントを更新することに注意してください。たとえば、[RFC6644]は、既存のテキストを新しいテキストに置き換えるため、[RFC3315]を明確に更新します。
If in doubt, authors should try to determine whether an implementor reading the base RFC alone (without reading the new document) would be able to properly implement the software. If the base RFC is sufficient, then the new document probably does not update the base RFC. On the other hand, if reading your new document is necessary to properly implement the base RFC, then the new document most likely updates the base RFC.
疑わしい場合は、作成者は、ベースRFCだけを読んだ実装者が（新しいドキュメントを読まずに）ソフトウェアを適切に実装できるかどうかを判断する必要があります。ベースRFCで十分な場合は、新しいドキュメントでベースRFCが更新されない可能性があります。一方、ベースRFCを適切に実装するために新しいドキュメントを読む必要がある場合は、新しいドキュメントがベースRFCを更新する可能性が高くなります。
DHCPv6 does have an authentication mechanism [RFC3315] that makes it possible for DHCPv6 software to discriminate between authentic endpoints and man-in-the-middle. Other authentication mechanisms may optionally be deployed. Sadly, as of 2014, the authentication in DHCPv6 is rarely used, and support for it is not common in existing implementations. Some specific deployment types make it mandatory (or parts thereof, e.g., DOCSIS3.0-compatible cable modems require reconfigure-key support), so in certain cases, specific authentication aspects can be relied upon. That is not true in the generic case, though.
DHCPv6には認証メカニズム[RFC3315]があり、DHCPv6ソフトウェアが本物のエンドポイントと中間者を区別できるようにします。他の認証メカニズムをオプションで展開できます。悲しいことに、2014年の時点では、DHCPv6での認証はほとんど使用されておらず、そのサポートは既存の実装では一般的ではありません。一部の特定の導入タイプでは必須となっているため（またはその一部、たとえばDOCSIS3.0互換のケーブルモデムでは再構成キーのサポートが必要）、特定のケースでは、特定の認証の側面に依存できます。ただし、これは一般的なケースでは当てはまりません。
So, while creating a new option, it is prudent to assume that the DHCPv6 packet contents are always transmitted in the clear, and actual production use of the software will probably be vulnerable at least to man-in-the-middle attacks from within the network, even where the network itself is protected from external attacks by firewalls. In particular, some DHCPv6 message exchanges are transmitted to multicast addresses that are likely broadcast anyway.
そのため、新しいオプションを作成する際、DHCPv6パケットの内容は常にクリアテキストで送信されると想定するのが賢明です。ソフトウェアの実際の運用では、少なくとも中間者からの中間者攻撃に対して脆弱になる可能性があります。ネットワーク自体、ファイアウォールによる外部の攻撃から保護されている場合でも。特に、一部のDHCPv6メッセージ交換は、とにかくブロードキャストされる可能性が高いマルチキャストアドレスに送信されます。
If an option is of a specific fixed length, it is useful to remind the implementor of the option data's full length. This is easily done by declaring the specific value of the 'length' tag of the option. This helps to gently remind implementors to validate the option length before digesting them into likewise fixed-length regions of memory or stack.
オプションが特定の固定長である場合、オプションデータの完全な長さを実装者に思い出させることは有用です。これは、オプションの「length」タグの特定の値を宣言することで簡単に行えます。これは、オプションの長さをメモリまたはスタックの同様に固定長の領域に分解する前に、オプションの長さを検証するよう実装者に穏やかに思い出させるのに役立ちます。
If an option may be of variable size (such as having indeterminate length fields, such as domain names or text strings), it is advisable to explicitly remind the implementor to be aware of the potential for long options. Either define a reasonable upper limit (and suggest validating it) or explicitly remind the implementor that an option may be exceptionally long (to be prepared to handle errors rather than truncate values).
オプションのサイズが可変である場合（ドメイン名やテキスト文字列など、長さが不定のフィールドがある場合など）、長いオプションの可能性を認識するように実装者に明示的に通知することをお勧めします。妥当な上限を定義する（および検証を提案する）か、オプションが非常に長くなる可能性があることを実装者に明示的に通知します（値を切り捨てるのではなくエラーを処理する準備をするため）。
For some option contents, out-of-bound values may be used to breach security. An IP address field might be made to carry a loopback address or local multicast address, and depending on the protocol, this may lead to undesirable results. A domain name field may be filled with contrived contents that exceed the limitations placed upon domain name formatting; as this value is possibly delivered to "internal configuration" records of the system, it may be implicitly trusted without being validated.
一部のオプションのコンテンツでは、範囲外の値を使用してセキュリティを侵害する場合があります。 IPアドレスフィールドは、ループバックアドレスまたはローカルマルチキャストアドレスを伝送するために作成される場合があり、プロトコルによっては、これが望ましくない結果をもたらす可能性があります。ドメイン名フィールドには、ドメイン名のフォーマットに課せられた制限を超える不自然な内容が入力される場合があります。この値はシステムの「内部構成」レコードに配信される可能性があるため、検証されずに暗黙的に信頼される場合があります。
Authors of documents defining new DHCP options are, therefore, strongly advised to explicitly define validation measures that recipients of such options are required to do before processing such options. However, validation measures already defined by RFC 3315 or other specifications referenced by the new option document are redundant and can introduce errors, so authors are equally strongly advised to refer to the base specification for any such validation language rather than copying it into the new specification.
したがって、新しいDHCPオプションを定義するドキュメントの作成者は、そのようなオプションの受信者がそのようなオプションを処理する前に行う必要がある検証方法を明示的に定義することを強くお勧めします。ただし、RFC 3315または新しいオプションドキュメントで参照されている他の仕様ですでに定義されている検証方法は冗長であり、エラーを引き起こす可能性があるため、作成者は、新しい仕様にコピーするのではなく、そのような検証言語の基本仕様を参照することを強くお勧めします。 。
See also Section 24.
セクション24も参照してください。
As discussed in Section 23, the DHCPv6 packets are typically transmitted in the clear, so they are susceptible to eavesdropping. This should be considered when defining options that may convey personally identifying information (PII) or any other type of sensitive data.
セクション23で説明したように、DHCPv6パケットは通常、クリアテキストで送信されるため、盗聴される可能性があります。これは、個人を特定する情報（PII）またはその他の種類の機密データを伝達する可能性のあるオプションを定義するときに考慮する必要があります。
If the transmission of sensitive or confidential content is required, it is still possible to secure communication between relay agents and servers. Relay agents and servers communicating with relay agents must support the use of IPsec Encapsulating Security Payload (ESP) with encryption in transport mode, according to Section 3.1.1 of [RFC4303] and Section 21.1 of [RFC3315]. Sadly, this requirement is almost universally ignored in real deployments. Even if the communication path between the relay agents and server is secured, the path between the clients and relay agents or server is not.
機密コンテンツの送信が必要な場合でも、リレーエージェントとサーバー間の通信をセキュリティで保護することが可能です。 [RFC4303]のセクション3.1.1と[RFC3315]のセクション21.1によると、リレーエージェントとリレーエージェントと通信するサーバーは、トランスポートモードで暗号化されたIPsecカプセル化セキュリティペイロード（ESP）の使用をサポートする必要があります。悲しいことに、この要件は実際の展開ではほとんど例外なく無視されます。中継エージェントとサーバー間の通信経路が確保されていても、クライアントと中継エージェントまたはサーバー間の経路は確保されていません。
Unless underlying transmission technology provides a secure transmission channel, the DHCPv6 options SHOULD NOT include PII or other sensitive information. If there are special circumstances that warrant sending such information over unsecured DHCPv6, the dangers MUST be clearly discussed in the security considerations.
基盤となる伝送技術が安全な伝送チャネルを提供しない限り、DHCPv6オプションにはPIIまたはその他の機密情報を含めないでください。セキュリティで保護されていないDHCPv6を介してそのような情報を送信する必要がある特別な状況がある場合は、セキュリティの考慮事項で危険性を明確に説明する必要があります。
The authors would like to thank Simon Perreault, Bernie Volz, Ted Lemon, Bud Millwood, Ralph Droms, Barry Leiba, Benoit Claise, Brian Haberman, Richard Barnes, Stephen Farrell, and Stewart Bryant for their comments.
著者は、コメントについてSimon Perreault、Bernie Volz、Ted Lemon、Bud Millwood、Ralph Droms、Barry Leiba、Benoit Claise、Brian Haberman、Richard Barnes、Stephen Farrell、およびStewart Bryantに感謝します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、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.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[IANA] IANA, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", <http://www.iana.org/assignments/dhcpv6-parameters/>.
[IANA] IANA、「IPv6の動的ホスト構成プロトコル（DHCPv6）」、<http://www.iana.org/assignments/dhcpv6-parameters/>。
[IPv4-CONFIG] Rajtar, B. and I. Farrer, "Provisioning IPv4 Configuration Over IPv6 Only Networks", Work in Progress, February 2014.
[IPv4-CONFIG] Rajtar、B。およびI. Farrer、「Provisioning IPv4 Configuration over IPv6 Only Networks」、Work in Progress、2014年2月。
[MAP] Mrugalski, T., Troan, O., Farrer, I., Perreault, S., Dec, W., Bao, C., Yeh, L., and X. Deng, "DHCPv6 Options for configuration of Softwire Address and Port Mapped Clients", Work in Progress, March 2014.
[MAP] Mrugalski、T.、Troan、O.、Farrer、I.、Perreault、S.、Dec、W.、Bao、C.、Yeh、L。、およびX. Deng、「Softwireの構成のためのDHCPv6オプションアドレスとポートにマップされたクライアント」、進行中の作業、2014年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[RFC3046] Patrick、M。、「DHCPリレーエージェント情報オプション」、RFC 3046、2001年1月。
[RFC3319] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.
[RFC3319] Schulzrinne、H。およびB. Volz、「Session Initiation Protocol（SIP）サーバーの動的ホスト構成プロトコル（DHCPv6）オプション」、RFC 3319、2003年7月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[RFC3646] Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646] Droms、R。、「IPv6の動的ホスト構成プロトコル（DHCPv6）のDNS構成オプション」、RFC 3646、2003年12月。
[RFC3898] Kalusivalingam, V., "Network Information Service (NIS) Configuration Options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3898, October 2004.
[RFC3898] Kalusivalingam、V。、「IPv6の動的ホスト構成プロトコル（DHCPv6）のネットワーク情報サービス（NIS）構成オプション」、RFC 3898、2004年10月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
[RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) Configuration Option for DHCPv6", RFC 4075, May 2005.
[RFC4075] Kalusivalingam、V。、「DHCPv6の簡易ネットワークタイムプロトコル（SNTP）構成オプション」、RFC 4075、2005年5月。
[RFC4085] Plonka, D., "Embedding Globally-Routable Internet Addresses Considered Harmful", BCP 105, RFC 4085, June 2005.
[RFC4085] Plonka、D。、「有害と見なされるグローバルにルーティング可能なインターネットアドレスの埋め込み」、BCP 105、RFC 4085、2005年6月。
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh Time Option for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 4242, November 2005.
[RFC4242] Venaas、S.、Chown、T。、およびB. Volz、「IPv6の動的ホスト構成プロトコル（DHCPv6）の情報更新時間オプション」、RFC 4242、2005年11月。
[RFC4280] Chowdhury, K., Yegani, P., and L. Madour, "Dynamic Host Configuration Protocol (DHCP) Options for Broadcast and Multicast Control Servers", RFC 4280, November 2005.
[RFC4280] Chowdhury、K.、Yegani、P。、およびL. Madour、「ブロードキャストおよびマルチキャスト制御サーバーの動的ホスト構成プロトコル（DHCP）オプション」、RFC 4280、2005年11月。
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[RFC4303]ケント、S。、「IPカプセル化セキュリティペイロード（ESP）」、RFC 4303、2005年12月。
[RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006.
[RFC4436] Aboba、B.、Carlson、J。、およびS. Cheshire、「Detecting Network Attachment in IPv4（DNAv4）」、RFC 4436、2006年3月。
[RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option", RFC 4704, October 2006.
[RFC4704] Volz、B。、「IPv6の動的ホスト構成プロトコル（DHCPv6）クライアントの完全修飾ドメイン名（FQDN）オプション」、RFC 4704、2006年10月。
[RFC4833] Lear, E. and P. Eggert, "Timezone Options for DHCP", RFC 4833, April 2007.
[RFC4833] Lear、E。およびP. Eggert、「DHCPのタイムゾーンオプション」、RFC 4833、2007年4月。
[RFC4957] Krishnan, S., Montavont, N., Njedjou, E., Veerepalli, S., and A. Yegin, "Link-Layer Event Notifications for Detecting Network Attachments", RFC 4957, August 2007.
[RFC4957]クリシュナン、S。、モンタボント、N.、Njedjou、E.、Veerepalli、S。、およびA. Yegin、「ネットワークアタッチメントを検出するためのリンク層イベント通知」、RFC 4957、2007年8月。
[RFC5007] Brzozowski, J., Kinnear, K., Volz, B., and S. Zeng, "DHCPv6 Leasequery", RFC 5007, September 2007.
[RFC5007] Brzozowski、J.、Kinnear、K.、Volz、B。、およびS. Zeng、「DHCPv6 Leasequery」、RFC 5007、2007年9月。
[RFC5198] Klensin, J. and M. Padlipsky, "Unicode Format for Network Interchange", RFC 5198, March 2008.
[RFC5198] Klensin、J。およびM. Padlipsky、「Network InterchangeのUnicode形式」、RFC 5198、2008年3月。
[RFC5223] Schulzrinne, H., Polk, J., and H. Tschofenig, "Discovering Location-to-Service Translation (LoST) Servers Using the Dynamic Host Configuration Protocol (DHCP)", RFC 5223, August 2008.
[RFC5223] Schulzrinne、H.、Polk、J。、およびH. Tschofenig、「Discovering Location-to-Service Translation（LoST）Servers Using the Dynamic Host Configuration Protocol（DHCP）」、RFC 5223、2008年8月。
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, February 2009.
[RFC5460] Stapp、M。、「DHCPv6 Bulk Leasequery」、RFC 5460、2009年2月。
[RFC5908] Gayraud, R. and B. Lourdelet, "Network Time Protocol (NTP) Server Option for DHCPv6", RFC 5908, June 2010.
[RFC5908] Gayraud、R。およびB. Lourdelet、「DHCPv6のネットワークタイムプロトコル（NTP）サーバーオプション」、RFC 5908、2010年6月。
[RFC5970] Huth, T., Freimann, J., Zimmer, V., and D. Thaler, "DHCPv6 Options for Network Boot", RFC 5970, September 2010.
[RFC5970] Huth、T.、Freimann、J.、Zimmer、V。、およびD. Thaler、「DHCPv6 Options for Network Boot」、RFC 5970、2010年9月。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010.
[RFC5986] Thomson、M.およびJ. Winterbottom、「Discovering the Local Location Information Server（LIS）」、RFC 5986、2010年9月。
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, November 2010.
[RFC6059] Krishnan、S.およびG. Daley、「Simple Procedures Detecting Network Attachment in IPv6」、RFC 6059、2010年11月。
[RFC6334] Hankins, D. and T. Mrugalski, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Option for Dual-Stack Lite", RFC 6334, August 2011.
[RFC6334] Hankins、D。およびT. Mrugalski、「Dynamic Host Configuration Protocol for IPv6（DHCPv6）Option for Dual-Stack Lite」、RFC 6334、2011年8月。
[RFC6422] Lemon, T. and Q. Wu, "Relay-Supplied DHCP Options", RFC 6422, December 2011.
[RFC6422] Lemon、T。およびQ. Wu、「Relay-Supplied DHCP Options」、RFC 6422、2011年12月。
[RFC6440] Zorn, G., Wu, Q., and Y. Wang, "The EAP Re-authentication Protocol (ERP) Local Domain Name DHCPv6 Option", RFC 6440, December 2011.
[RFC6440] Zorn、G.、Wu、Q。、およびY. Wang、「EAP再認証プロトコル（ERP）ローカルドメイン名DHCPv6オプション」、RFC 6440、2011年12月。
[RFC6603] Korhonen, J., Savolainen, T., Krishnan, S., and O. Troan, "Prefix Exclude Option for DHCPv6-based Prefix Delegation", RFC 6603, May 2012.
[RFC6603] Korhonen、J.、Savolainen、T.、Krishnan、S。、およびO. Troan、「DHCPv6ベースのプレフィックス委任のプレフィックス除外オプション」、RFC 6603、2012年5月。
[RFC6610] Jang, H., Yegin, A., Chowdhury, K., Choi, J., and T. Lemon, "DHCP Options for Home Information Discovery in Mobile IPv6 (MIPv6)", RFC 6610, May 2012.
[RFC6610] Jang、H.、Yegin、A.、Chowdhury、K.、Choi、J。、およびT. Lemon、「モバイルIPv6（MIPv6）でのホーム情報検出のためのDHCPオプション」、RFC 6610、2012年5月。
[RFC6644] Evans, D., Droms, R., and S. Jiang, "Rebind Capability in DHCPv6 Reconfigure Messages", RFC 6644, July 2012.
[RFC6644] Evans、D.、Droms、R。、およびS. Jiang、「DHCPv6 Reconfigureメッセージの再バインド機能」、RFC 6644、2012年7月。
[SOLUTION-4rd] Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd)", Work in Progress, October 2013.
[ソリューション4rd] Despres、R.、Jiang、S.、Penno、R.、Lee、Y.、Chen、G。、およびM. Chen、「IPv6によるIPv4の残りの展開-ステートレスソリューション（4番目）」、作業中、2013年10月。
Authors' Addresses
著者のアドレス
David W. Hankins Google, Inc. 1600 Amphitheatre Parkway Mountain View, CA 94043 USA
David W. Hankins Google、Inc. 1600 Amphitheatre Parkway Mountain View、CA 94043 USA
EMail: dhankins@google.com
Tomek Mrugalski Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA
Internet Systems Consortium、Inc.のTomek Mrigalski氏೯೫೦ Charter Street Redwood City、K Kアメリカ合衆国
Phone: +1-650-423-1345
EMail: tomasz.mrugalski@gmail.com
Marcin Siodelski Internet Systems Consortium, Inc. 950 Charter Street Redwood City, CA 94063 USA
Marcin Siodelski Internet Systems Consortium、Inc. 950 Charter Street Redwood City、CA 94063 USA
Phone: +1-650-423-1431
EMail: msiodelski@gmail.com
Sheng Jiang Huawei Technologies Co., Ltd. Q14, Huawei Campus, No. 156 Beiqing Road Hai-Dian District, Beijing, 100095 P.R. China
S横江胡Aはテクノロジー株式会社です。Q14、胡Aはキャンパスです。番号156はi青道路ですHAI-Dイアン地区、北京、中国、中国
EMail: jiangsheng@huawei.com
Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal, Quebec Canada
Suresh Krishnan Ericsson 8400 Blvd Decarie Town of Mount Royal、Quebec Canada
EMail: suresh.krishnan@ericsson.com