Network Working Group G. Bajko
Request for Comments: 5678 Nokia
Category: Standards Track S. Das
Telcordia Technologies Inc.
December 2009
Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery
動的ホスト構成プロトコル（DHCPv4とDHCPv6の）IEEE 802.21モビリティサービス（MOS）の発見のためのオプション
Abstract
抽象
This document defines new Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) options that contain a list of IP addresses and a list of domain names that can be mapped to servers providing IEEE 802.21 type of Mobility Service (MoS) (see RFC 5677). These Mobility Services are used to assist a mobile node (MN) in handover preparation (network discovery) and handover decision (network selection). The services addressed in this document are the Media Independent Handover Services defined in IEEE 802.21.
この文書では、IPアドレスのリストおよびモビリティサービス（MOS）のIEEE 802.21種類を提供するサーバにマッピングすることができるドメイン名のリストが含まれている新しい動的ホスト構成プロトコル（DHCPv4とDHCPv6の）オプションを定義します（RFC 5677を参照してください）。これらのモビリティサービスは、ハンドオーバの準備（ネットワークディスカバリ）とハンドオーバ決定（ネットワーク選択）内のモバイルノード（MN）を支援するために使用されています。本書で取り上げたサービスは、IEEE 802.21で定義されたメディア独立ハンドオーバサービスです。
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2009 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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 BSD License.
この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクション4.eに記載されており、BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................3
1.2. Terminology ................................................3
2. MoS IPv4 Address Option for DHCPv4 ..............................3
3. MoS Domain Name List Option for DHCPv4 ..........................5
4. MoS IPv6 Address Option for DHCPv6 ..............................7
5. MoS Domain Name List Option for DHCPv6 ..........................9
6. Option Usage ...................................................10
6.1. Usage of MoS Options for DHCPv4 ...........................10
6.2. Usage of MoS Options for DHCPv6 ...........................11
7. Security Considerations ........................................12
8. IANA Considerations ............................................12
9. Acknowledgements ...............................................13
10. References ....................................................13
10.1. Normative References .....................................13
10.2. Informative References ...................................14
IEEE 802.21 [IEEE802.21] defines three distinct service types to facilitate link layer handovers across heterogeneous technologies:
IEEE 802.21は、[IEEE802.21]異種技術を横切ってリンク層ハンドオーバを容易にするために、3つの異なるサービスタイプを定義します。
a) Information Services (IS) IS provides a unified framework to the higher-layer entities across the heterogeneous network environment to facilitate discovery and selection of multiple types of networks existing within a geographical area. The objective is to help the higher-layer mobility protocols acquire a global view of heterogeneous networks and perform seamless handover across these networks.
A）情報サービス（IS）IS地理的領域内の既存のネットワークの複数の種類の発見と選択を容易にするために、異種ネットワーク環境全体の上位層エンティティに統一されたフレームワークを提供します。目的は、上位層モビリティプロトコルは、異種ネットワークのグローバルビューを取得し、これらのネットワーク間でのシームレスなハンドオーバーを行うことを支援することです。
b) Event Services (ES) Events may indicate changes in state and transmission behavior of the physical, data link, and logical link layers, or predict state changes of these layers. The Event Service may also be used to indicate management actions or command status on the part of the network or some management entity.
B）イベントサービス（ES）イベント状態と物理、データリンクの送信動作、および論理リンク層の変化を示す、あるいはこれらの層の状態の変化を予測してもよいです。イベントサービスは、ネットワークの一部または一部の管理エンティティの管理アクションやコマンドのステータスを示すために使用することができます。
c) Command Services (CS) The command service enables higher layers to control the physical, data link, and logical link layers. The higher layers may control the reconfiguration or selection of an appropriate link through a set of handover commands.
c）コマンド・サービス（CS）コマンドサービスは、物理、データリンク、および論理リンク層を制御するために、より高い層を可能にします。上位レイヤは、ハンドオーバコマンドのセットを介して適切なリンクの再構成または選択を制御することができます。
In IEEE terminology, these services are called Media Independent Handover (MIH) services. While these services may be co-located, the different pattern and type of information they provide do not necessitate the co-location.
IEEEの用語では、これらのサービスは、メディア独立ハンドオーバ（MIH）サービスと呼ばれています。これらのサービスは、同じ場所に配置することができるが、それらが提供する情報の異なるパターンとタイプがコロケーションを必要としません。
A mobile node (MN) may make use of any of these MIH service types separately or any combination of them [RFC5677]. In practice, a Mobility Server may not necessarily host all three of these MIH services together; thus, there is a need to discover the MIH service types separately.
モバイルノード（MN）は、別々に、これらのMIHサービスタイプ、またはそれらの任意の組み合わせ[RFC5677]のいずれかを利用することができます。実際には、モビリティサーバは必ずしも一緒にこれらのMIHサービスの3つすべてをホストしていてもよいです。このように、個別にMIHサービスタイプを発見する必要があります。
This document defines new DHCPv4 and DHCPv6 options and sub-options called the MoS IP Address and Domain Name List Options, which allow the MN to locate a Mobility Server that hosts the desired service type (i.e., IS, ES, or CS) as defined in [IEEE802.21]. Apart from manual configuration, this is one of the possible solutions for locating a server providing Mobility Services.
この文書では、MNが希望するサービスの種類をホストモビリティサーバを見つけることができたMoS IPアドレスとドメイン名リストオプションと呼ばれる新しいDHCPv4とDHCPv6のオプションとサブオプションを定義する（すなわち、ES、またはCS IS）定義されています[IEEE802.21]インチ別に手動設定から、これは、モビリティサービスを提供するサーバを見つけるための可能な解決策の一つです。
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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Mobility Services: a set of services provided by the network to mobile nodes to facilitate handover preparation and handover decision. In this document, Mobility Services refer to the services defined in IEEE 802.21 specifications [IEEE802.21]
モビリティサービス：ハンドオーバの準備およびハンドオーバの決定を容易にするために、モバイルノードにネットワークが提供するサービスのセット。この文書では、モビリティサービスは、IEEE 802.21規格[IEEE802.21]で定義されたサービスを参照してください。
Mobility Server: a network node providing Mobility Services.
モビリティサーバ：モビリティサービスを提供するネットワークノード。
MIH: Media Independent Handover, as defined in [IEEE802.21].
MIH：メディア独立ハンドオーバ、[IEEE802.21]で定義されています。
MIH Service: IS, ES, or CS type of service, as defined in [IEEE802.21].
MIHサービス：[IEEE802.21]で定義されるように、サービスのES、またはCSタイプです。
This section describes the MoS IPv4 Address Option for DHCPv4. Whether the MN receives a MoS address from the local or home network will depend on the actual network deployment [RFC5677]. The MoS IPv4 Address Option begins with an option code followed by a length and sub-options. The value of the length octet does not include itself or the option code. The option layout is depicted below:
このセクションでは、DHCPv4ののMoSのIPv4アドレスオプションについて説明します。 MNは、ローカルまたはホームネットワークからのMoSアドレスを受信するかどうかは、実際のネットワークの展開[RFC5677]に依存します。 MoS IPv4アドレスオプションは、長さと、サブオプションに続くオプションコードから始まります。長さオクテットの値は、自身やオプションコードは含まれていません。オプションレイアウトが下に描かれています。
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option 1 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option n |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code
オプションコード
OPTION-IPv4_Address-MoS (139) - 1 byte
OPTION-IPv4_Address-MOS（139） - 1つのバイト
Length
長さ
An 8-bit field indicating the length of the option excluding the 'Option Code' and the 'Length' fields
「オプション・コード」と「長さ」フィールドを除いたオプションの長さを示す8ビットのフィールド
Sub-options
サブオプション
A series of DHCPv4 sub-options
DHCPv4のサブオプションのシリーズ
When the total length of a MoS IPv4 Address Option exceeds 254 octets, the procedure outlined in [RFC3396] MUST be employed to split the option into multiple, smaller options.
MoS IPv4アドレスオプションの全長が254個のオクテットを超える場合には、[RFC3396]に概説された手順は、複数のより小さなオプションにオプションを分割するために使用しなければなりません。
A sub-option begins with a sub-option code followed by a length and one or more IPv4 addresses. The sub-option layout is depicted below:
サブオプションの長さと1つのまたは複数のIPv4アドレスに続くサブオプションコードから始まります。サブオプションのレイアウトが下に描かれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-opt Code | Length | IP Address . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-option codes are summarized below.
サブオプションコードを以下にまとめます。
+--------------+---------------+
| Sub-opt | Service |
| Code | Name |
+==============+===============+
| 1 | IS |
+--------------+---------------+
| 2 | CS |
+--------------+---------------+
| 3 | ES |
+--------------+---------------+
If the length is followed by a list of IPv4 addresses indicating appropriate MIH servers available to the MN for a requested option, servers MUST be listed in order of preference and the client should process them in decreasing order of preference. In the case that there is no MIH server available, the length is set to 0; otherwise, it is a multiple of 4.
長さが要求されたオプションのためのMNに利用できる適切なMIHサーバを示すIPv4アドレスのリストが続いている場合、サーバは優先順にリストされている必要があり、クライアントは好みの順にそれらを処理しなければなりません。無MIHサーバ利用可能である場合には、長さが0に設定されています。それ以外の場合は、4の倍数です。
The sub-option has the following format:
サブオプションの形式は次のとおりです。
Code Len IPv4 Address 1 IPv4 Address 2
+-----+---+---+----+----+----+----+----+---
|1..3 | n |a1 | a2 |a3 | a4 | a1 | ...
+-----+---+---+----+----+----+-----+----+--
This section describes the MoS Domain Name List Option for DHCPv4. The general format of this option is depicted below:
このセクションでは、DHCPv4ののMoSドメイン名のリストオプションを記述する。このオプションの一般的なフォーマットは以下の描かれています。
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option 1 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option n |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code
オプションコード
OPTION-IPv4_FQDN-MoS (140) - 1 byte
OPTION-IPv4_FQDN-MOS（140） - 1つのバイト
Length
長さ
An 8-bit field indicating the length of the option excluding the 'Option Code' and the 'Length' fields
「オプション・コード」と「長さ」フィールドを除いたオプションの長さを示す8ビットのフィールド
Sub-options
サブオプション
A series of DHCPv4 sub-options.
DHCPv4のサブオプションのシリーズ。
When the total length of a MoS Domain Name List Option exceeds 254 octets, the procedure outlined in [RFC3396] MUST be employed to split the option into multiple, smaller options.
MoSドメイン名一覧オプションの合計の長さが254個のオクテットを超える場合には、[RFC3396]に概説された手順は、複数のより小さなオプションにオプションを分割するために使用しなければなりません。
A sub-option begins with a sub-option code followed by a length and one or more Fully Qualified Domain Names (FQDNs). The sub-option layout is depicted below:
サブオプションの長さと1つ以上の完全修飾ドメイン名（FQDN）が続くサブオプションコードから始まります。サブオプションのレイアウトが下に描かれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-opt Code | Length | FQDN(s) . . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-option codes are summarized below.
サブオプションコードを以下にまとめます。
+--------------+---------------+
| Sub-opt | Service |
| Code | Name |
+==============+===============+
| 1 | IS |
+--------------+---------------+
| 2 | CS |
+--------------+---------------+
| 3 | ES |
+--------------+---------------+
Thus, the sub-option for this encoding has the following format:
したがって、このエンコーディングのためのサブオプションの形式は次のとおりです。
Code Len DNS name of Mobility Server
+-----+----+----+-----+-----+-----+-----+--
|1..3 | n | s1 | s2 | s3 | s4 | s5 | ...
+-----+----+----+-----+-----+-----+-----+--
The sub-option begins with a sub-option code followed by a length and a sequence of labels that are encoded according to Section 8 of [RFC3315].
サブオプションの長さに続くサブオプションコードと[RFC3315]のセクション8に記載の符号化されたラベルのシーケンスで始まります。
The sub-option MAY contain multiple domain names, but these should refer to the NAPTR records of different providers, rather than different A records within the same provider. That is, the use of multiple domain names is not meant to replace NAPTR and SRV records, but rather to allow a single DHCP server to indicate MIH servers operated by multiple providers.
サブオプションは、複数のドメイン名を含んでいてもよいが、これらは同じプロバイダ内の異なるプロバイダではなく、別のAレコードのNAPTRレコードを参照する必要があります。これは、複数のドメイン名の使用はNAPTRとSRVレコードを交換するのではなく、単一のDHCPサーバが複数のプロバイダが運営するMIHサーバを示すことができるように意図されていない、です。
The client MUST try the records in the order listed, applying the mechanism described in [RFC5679] for each. The client only resolves the subsequent domain names if attempts to contact the first one failed or yielded no common transport protocols between the MN and the server.
クライアントは、それぞれの[RFC5679]で説明したメカニズムを適用し、リストされた順序でレコードを試みなければなりません。最初の1に連絡しようとする試みが失敗したか、MNとサーバの間に共通のトランスポートプロトコルは得られなかった場合、クライアントにのみ、その後のドメイン名を解決します。
As an example, consider the case where the server wants to offer two MIH IS servers, "example.com" and "example.net". These would be encoded as follows:
例として、サーバは2 MIHは、サーバ、「example.com」と「example.net」ISを提供したい場合を考えます。これらは以下のようにコード化されるだろう。
+-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|1..3 |26 | 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'c'|'o'|'m'| 0 |
+-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+---+---+---+---+---+---+---+---+---+---+---+---+---+
| 7 |'e'|'x'|'a'|'m'|'p'|'l'|'e'| 3 |'n'|'e'|'t'| 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+
This section describes the MoS IPv6 Address Option for DHCPv6. Whether the MN receives a MoS address from the local or home network will depend on the actual network deployment [RFC5677]. The MoS Discovery Option begins with an option code followed by a length and sub-options. The value of the length octet does not include itself or the option code. The option layout is depicted below:
このセクションでは、DHCPv6ののMoSのIPv6アドレスオプションについて説明します。 MNは、ローカルまたはホームネットワークからのMoSアドレスを受信するかどうかは、実際のネットワークの展開[RFC5677]に依存します。 MoSディスカバリオプションは、長さと、サブオプションに続くオプションコードから始まります。長さオクテットの値は、自身やオプションコードは含まれていません。オプションレイアウトが下に描かれています。
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option 1 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option n |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code
オプションコード
OPTION-IPv6_Address-MoS (54) - 2 bytes
OPTION-IPv6_Address-MOS（54） - 2つのバイト
Length
長さ
A 16-bit field indicating the length of the option excluding the 'Option Code' and the 'Length' fields.
「オプション・コード」と「長さ」フィールドを除いたオプションの長さを示す16ビットのフィールド。
Sub-options
サブオプション
A series of DHCPv6 sub-options
DHCPv6のサブオプションのシリーズ
The sub-options follow the same format (except the Sub-opt Code and Length value) as described in Section 2. The value of the Sub-opt Code and Length is 2 octets, and the Length does not include itself or the Sub-opt Code field. The sub-option layout is depicted below:
サブオプションは、セクション2で説明したようにサブ選ぶコードと長さの値は2つのオクテットであり、長さは、それ自体またはサブのを含まない（サブ選ぶコードと長さ値を除く）と同じフォーマットに従いますCodeフィールドを選びます。サブオプションのレイアウトが下に描かれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-opt Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Address |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-option codes are summarized below.
サブオプションコードを以下にまとめます。
+----------------+---------------+
| Sub-opt Code | Service Name |
+================+===============+
| 1 | IS |
+----------------+---------------+
| 2 | CS |
+----------------+---------------+
| 3 | ES |
+----------------+---------------+
If the length is followed by a list of IPv6 addresses indicating appropriate MIH servers available to the MN for a requested option, servers MUST be listed in order of preference and the client should
長さが要求されたオプションのためのMNに利用できる適切なMIHサーバを示すIPv6アドレスのリストが続いている場合、サーバは優先順にリストされている必要があり、クライアントはすべき
process them in decreasing order of preference. In the case where there is no MIH server available, the length is set to 0; otherwise, it is a multiple of 16.
好みの順にそれらを処理。利用可能なMIHサーバが存在しない場合には、長さが0に設定されています。それ以外の場合は、16の倍数です。
This section describes the MoS Domain List Option for DHCPv6. The general format of this option is depicted below:
このセクションでは、DHCPv6ののMoSドメインリストオプションを記述する。このオプションの一般的なフォーマットは以下の描かれています。
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 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option 1 |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Option n |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Code
オプションコード
OPTION-IPv6_FQDN-MoS (55) - 2 bytes
OPTION-IPv6_FQDN-MOS（55） - 2つのバイト
Length
長さ
A 16-bit field indicating the length of the option excluding the 'Option Code' and the 'Length' fields
「オプション・コード」と「長さ」フィールドを除いたオプションの長さを示す16ビットのフィールド
Sub-options
サブオプション
A series of DHCPv6 sub-options
DHCPv6のサブオプションのシリーズ
The sub-options follow the same format (except the Sub-opt Code and Length value) as described in Section 3. The value of the Sub-opt Code and Length is 2 octets, and the Length does not include itself or the Sub-opt Code field. The sub-option layout is depicted below:
サブオプションは、セクション3で説明したようにサブ選ぶコードと長さの値は2つのオクテットであり、長さは、それ自体またはサブのを含まない（サブ選ぶコードと長さ値を除く）と同じフォーマットに従いますCodeフィールドを選びます。サブオプションのレイアウトが下に描かれています。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| sub-opt Code | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FQDN(s) |
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sub-option codes are summarized below.
サブオプションコードを以下にまとめます。
+----------------+---------------+
| Sub-opt Code | Service Name |
+================+===============+
| 1 | IS |
+----------------+---------------+
| 2 | CS |
+----------------+---------------+
| 3 | ES |
+----------------+---------------+
The semantics and content of the DHCPv6 encoding of this option are exactly the same as the encoding described in Section 3, except the Option Code and Length value.
セマンティクスと、このオプションのDHCPv6のエンコーディングの内容は、オプション・コードと長さの値を除いて、第3節で説明したエンコーディングと全く同じです。
The requesting and sending of the proposed DHCPv4 options follow the rules for DHCP options in [RFC2131].
要求と提案したのDHCPv4オプションの送信には、[RFC2131]でのDHCPオプションの規則に従ってください。
The mobile node may perform a MoS discovery either during initial association with a network or when the mobility service is required. It may also try to perform the MoS discovery when it lacks the network information for MoS or needs to change the MoS for some reasons, for instance, to recover from the single point of failure of the existing MoS.
モバイルノードは、ネットワークまたはモビリティ・サービスが要求されると最初の関連付け中のMoS検出のいずれかを実行することができます。また、それは、MOSのためのネットワーク情報が欠けているか、または既存のMoSの単一障害点から回復するために、例えば、いくつかの理由のためのMoSを変更する必要がある場合のMoSの発見を実行しようとするかもしれません。
In order to discover the IP address or FQDN of a MoS, the mobile node (DHCP client) MUST include either a MoS IPv4 Address Option or a MoS Domain Name List Option in the Parameter Request List (PRL) in the respective DHCP messages as defined in [RFC2131].
定義されているのMoSのIPアドレスまたはFQDNを発見するためには、モバイルノード（DHCPクライアント）のMoSのIPv4アドレスオプションや、各DHCPメッセージにパラメータ要求リスト（PRL）のMOSドメイン名リストオプションのいずれかを含まなければなりません[RFC2131]インチ
The client MAY include a MoS IPv4 Address Option or a MoS Domain Name List Option that includes one or more sub-option(s) with the Sub-opt Code or Codes that represent the service(s) the mobile node is interested in. However, a client SHOULD be prepared to accept a response from a server that includes other sub-option(s) or does not include the requested sub-option(s).
クライアントは、モバイルノードが興味を持っているのMoSのIPv4アドレスオプションやサービス（複数可）を表すサブオプトコードまたはコードと1つ以上のサブオプション（s）などのMoSドメイン名リストオプションを含むかもしれません。しかし、 、クライアントは、他のサブオプション（複数可）を含むか、または要求されたサブオプション（複数可）を含んでいないサーバからの応答を受け入れるように準備されるべきです。
When the DHCP server receives either a MoS IPv4 Address Option or a MoS Domain Name List Option in the PRL, the DHCP server MUST include the option in its response message as defined in [RFC2131].
DHCPサーバは、MOSのIPv4アドレスオプションまたはPRLのMOSドメイン名リストオプションのいずれかを受信した場合、[RFC2131]で定義されるように、DHCPサーバは、その応答メッセージにオプションを含まなければなりません。
A server MAY use the sub-options in the received MoS IPv4 Address Option or MoS Domain Name List Option from the client's message to restrict its response to the client requested sub-options. In the case when the server cannot find any Mobility Server satisfying a requested sub-option, the server SHOULD return the MoS Option with that sub-option and the length of the sub-option set to 0.
サーバーは、クライアント要求のサブオプションへの応答を制限するために、クライアントのメッセージから受け取ったMoSのIPv4アドレスオプションやMOSドメイン名リストオプションでサブオプションを使用するかもしれません。サーバはどのモビリティサーバは要求されたサブオプションを満たす見つけることができない場合、サーバーはそのサブオプションと0に設定したサブオプションの長さを有するMOSオプションを返すべきです。
The requesting and sending of the proposed DHCPv6 options follow the rules for DHCP options in [RFC3315].
要求と提案したDHCPv6オプションの送信には、[RFC3315]でのDHCPオプションの規則に従ってください。
The mobile node may perform the MoS discovery either during initial association with a network or when the mobility service is required. It may also try to perform the MoS discovery when it lacks the network information for MoS or needs to change the MoS for some reasons, for instance, to recover from the single point of failure of the existing MoS.
モバイルノードは、ネットワークまたはモビリティ・サービスが要求されると最初の関連付け中のMoS検出のいずれかを実行することができます。また、それは、MOSのためのネットワーク情報が欠けているか、または既存のMoSの単一障害点から回復するために、例えば、いくつかの理由のためのMoSを変更する必要がある場合のMoSの発見を実行しようとするかもしれません。
In order to discover the IP address or FQDN of a MoS, the mobile node (DHCP client) MUST include either a MoS IPv6 Address Option or a MoS Domain Name List Option in the Option Request Option (ORO) in the respective DHCP messages as defined in [RFC3315].
定義されているのMoSのIPアドレスまたはFQDNを発見するためには、モバイルノード（DHCPクライアント）のMoSのIPv6アドレスオプションや、各DHCPメッセージにオプション要求オプション（ORO）のMOSドメイン名リストオプションのいずれかを含まなければなりません[RFC3315]インチ
The client MAY include a MoS IPv6 Address Option or a MoS Domain Name List Option that includes one or more sub-option(s) with the Sub-opt Code or Codes that represent the service(s) the mobile node is interested in. However, a client SHOULD be prepared to accept a response from a server that includes other sub-option(s) or does not include the requested sub-option(s).
クライアントは、モバイルノードが興味を持っているのMoSのIPv6アドレスオプションやサービス（複数可）を表すサブオプトコードまたはコードと1つ以上のサブオプション（s）などのMoSドメイン名リストオプションを含むかもしれません。しかし、 、クライアントは、他のサブオプション（複数可）を含むか、または要求されたサブオプション（複数可）を含んでいないサーバからの応答を受け入れるように準備されるべきです。
When the DHCP server receives either a MoS IPv6 Address Option or a MoS Domain Name List Option in the ORO, the DHCP server MUST include the option in its response message as defined in [RFC3315].
DHCPサーバは、MOSのIPv6アドレスオプションまたはOROのMOSドメイン名リストオプションのいずれかを受信した場合、[RFC3315]で定義されるように、DHCPサーバは、その応答メッセージにオプションを含まなければなりません。
A server MAY use the sub-options in the received MoS IPv6 Address Option or MoS Domain Name List Option from the client's message to restrict its response to the client-requested sub-options. In the case when the server cannot find any Mobility Server satisfying a requested sub-option, the server SHOULD return the MoS Option with that sub-option and the length of the sub-option set to 0.
サーバは、クライアントが要求したサブオプションへの応答を制限するために、クライアントのメッセージから受け取ったMoS IPv6アドレスオプションやMOSドメイン名リストオプションでサブオプションを使用するかもしれません。サーバはどのモビリティサーバは要求されたサブオプションを満たす見つけることができない場合、サーバーはそのサブオプションと0に設定したサブオプションの長さを有するMOSオプションを返すべきです。
The security considerations in [RFC2131] apply. If an adversary manages to modify the response from a DHCP server or insert its own response, an MN could be led to contact a rogue Mobility Server, possibly one that then would provide wrong information, event or command for handover.
[RFC2131]のセキュリティの考慮事項が適用されます。敵がDHCPサーバからの応答を変更したり、独自の応答を挿入するために管理している場合、MNはおそらく、その後、ハンドオーバーのために間違った情報、イベントやコマンドを提供するものを不正なモビリティサーバに連絡することを導くことができました。
It is recommended to use either DHCP authentication option described in [RFC3118] where available. This will also protect the denial-of-service attacks to DHCP servers. [RFC3118] provides mechanisms for both entity authentication and message authentication.
[RFC3118]利用可能に説明DHCP認証オプションのいずれかを使用することをお勧めします。また、これは、DHCPサーバへのDoS攻撃を保護します。 [RFC3118]は、エンティティ認証とメッセージ認証の両方のためのメカニズムを提供します。
In deployments where DHCP authentication is not available, lower-layer security services may be sufficient to protect DHCP messages.
DHCP認証が利用できない展開では、下位層のセキュリティサービスは、DHCPメッセージを保護するのに十分であり得ます。
Regarding domain name resolution, it is recommended to consider the usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational Practices [RFC4641]. Security considerations described in [RFC5679] also apply.
ドメイン名の解決については、DNSSEC [RFC4033]とDNSSEC運用プラクティスの側面[RFC4641]の利用を検討することをお勧めします。 [RFC5679]で説明されたセキュリティ上の考慮事項にも適用されます。
This document defines two new DHCPv4 options as described in Sections 2 and 3.
セクション2と3で説明したようにこの文書では、2つの新しいDHCPv4のオプションを定義します。
MoS IPv4 Address Option for DHCPv4 (OPTION-IPv4_Address-MoS) 139
DHCPv4ののMoSのIPv4アドレスオプション（OPTION-IPv4_Address-MOS）139
MoS Domain Name List option for DHCPv4 (OPTION-IPv4_FQDN-MoS) 140
DHCPv4（OPTION-IPv4_FQDN-MOS）140用のMOSドメイン名リスト]オプション
This document creates a new registry for the Sub-Option fields in the MoS DHCPv4 Address and FQDN options called the "IEEE 802.21 Service Type" (Section 2 and 3).
この文書では、MOSのDHCPv4アドレスとFQDNオプションでサブオプションフィールドの新しいレジストリは、「IEEE 802.21サービスタイプ」（第2および3）と呼ばれる作成されます。
IS 1
CS 2
ES 3
The values '0' and '255' are reserved. Values '1' through '3' are allocated as above, and the rest are available for allocation. New values can be allocated via Standards Action as defined in [RFC5226].
値「0」と「255」が予約されています。値「1」「3」を介して、上記のように割り当てられ、残りは、割り当てのために利用可能です。 [RFC5226]で定義された新しい値は、標準化アクションを経由して割り当てることができます。
This document also defines two DHCPv6 options as described in Sections 4 and 5.
セクション4および5に記載したように、このドキュメントは、2つのDHCPv6オプションを定義します。
MoS IPv6 Address Option for DHCPv6 (OPTION-IPv6_Address-MoS) 54
DHCPv6の（OPTION-IPv6_Address-MOS）用のMOSのIPv6アドレスオプション54
MoS Domain Name List option for DHCPv6 (OPTION-IPv6_FQDN-MoS) 55
DHCPv6の（OPTION-IPv6_FQDN-MOS）55用のMOSドメイン名リスト]オプション
This document creates a new registry for the sub-option field in the MoS DHCPv6 Address and FQDN options called the "IEEE 802.21 IPv6 Service Type" (Sections 4 and 5).
このドキュメントは、「IEEE 802.21のIPv6サービス・タイプ」と呼ばれるのMoS DHCPv6のアドレスとFQDNオプションでサブオプションフィールドのための新しいレジストリを作成します（セクション4および5）。
IS 1
CS 2
ES 3
The values '0' and '65535' are reserved. Values '1' through '3' are allocated as above, and the rest are available for allocation. New values can be allocated via Standards Action as defined in [RFC5226].
値「0」と「65535」が予約されています。値「1」「3」を介して、上記のように割り当てられ、残りは、割り当てのために利用可能です。 [RFC5226]で定義された新しい値は、標準化アクションを経由して割り当てることができます。
The authors would like to acknowledge the following individuals for their valuable comments: Alfred Hoenes, Bernie Volz, David W. Hankins, Jari Arkko, Telemaco Melia, Ralph Droms, Ted Lemon, Vijay Devarapalli, and Yoshihiro Ohba.
アルフレッドHoenes、バーニーフォルツ、デビッドW.ハンキンズ、ヤリArkko、Telemacoメリア、ラルフDroms、テッド・レモン、ビジェイDevarapalli、および義博大場：作者は彼らの貴重なコメントについて以下の個人を確認したいと思います。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[RFC3118] Droms, R., Ed., and W. Arbaugh, Ed., "Authentication for DHCP Messages", RFC 3118, June 2001.
[RFC3118] Droms、R.、エド。、およびW. Arbaugh、エド。、 "DHCPメッセージの認証"、RFC 3118、2001年6月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。
[RFC3396] Lemon, T. and S. Cheshire, "Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396, November 2002.
[RFC3396]レモン、T.とS.チェシャー、 "動的ホスト構成プロトコル（DHCPv4の）でエンコーディング長いオプション"、RFC 3396、2002年11月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 5226、2008年5月。
[RFC5677] Melia, T., Ed., Bajko, G., Das, S., Golmie, N., and JC. Zuniga, "IEEE 802.21 Mobility Services Framework Design (MSFD)", RFC 5677, December 2009.
[RFC5677]メリア、T.、エド。、Bajko、G.、ダス、S.、Golmie、N.、およびJC。スニガ、 "IEEE 802.21モビリティサービスフレームワークの設計（MSFD）"、RFC 5677、2009年12月。
[RFC5679] Bajko, G., "Locating IEEE 802.21 Mobility Services Using DNS", RFC 5679, December 2009.
[RFC5679] Bajko、G.、 "DNSを使用したIEEE 802.21モビリティサービスの検索"、RFC 5679、2009年12月。
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006.
[RFC4641] Kolkman、O.とR. Gieben、 "DNSSEC運用・プラクティス"、RFC 4641、2006年9月。
[IEEE802.21] "IEEE Standard for Local and Metropolitan Area Networks - Part 21: Media Independent Handover Services", IEEE LAN/MAN Std 802.21-2008, January 2009, http://www.ieee802.org/21/private/Published%20Spec/ 802.21-2008.pdf (access to the document requires membership).
[IEEE802.21] "ローカルおよびメトロポリタンエリアネットワークのIEEE規格 - パート21：メディア独立ハンドオーバサービス"、IEEE LAN / MAN STD 802.21から2008、2009年1月、http://www.ieee802.org/21/private/出版％20Spec / 802.21-2008.pdf（ドキュメントへのアクセスは、メンバーシップが必要です）。
Authors' Addresses
著者のアドレス
Gabor Bajko Nokia EMail: gabor.bajko@nokia.com
ガボールBajkoノキアEメール：gabor.bajko@nokia.com
Subir Das Telcordia Technologies Inc. EMail: subir@research.telcordia.com
Telcordia Technologies社株式会社た電子メールのアップ：subir@research.telcordia.com