[要約] 要約：RFC 5678は、IEEE 802.21モビリティサービス（MoS）の発見のためのDHCPv4およびDHCPv6オプションに関する仕様です。 目的：このRFCの目的は、ネットワーク上のデバイスがIEEE 802.21モビリティサービスを発見できるようにするためのDHCPオプションを提供することです。
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
IEEE 802.21モビリティサービス（MOS）発見のための動的ホスト構成プロトコル（DHCPV4およびDHCPV6）オプション
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アドレスのリストとIEEE 802.21のモビリティサービス（MOS）のタイプを提供するサーバーにマッピングできるドメイン名のリストを含む新しい動的ホスト構成プロトコル（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.
Copyright（c）2009 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 BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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) Information Services（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用語では、これらのサービスはMedia Independent Handover（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.
このドキュメントでは、MOS IPアドレスとドメイン名リストオプションと呼ばれる新しいDHCPV4およびDHCPV6オプションとサブオプションを定義します。これにより、MNは、定義された希望のサービスタイプ（IS、ES、またはCS）をホストするモビリティサーバーを見つけることができます。[IEEE802.21]で。手動構成とは別に、これはモビリティサービスを提供するサーバーを見つけるための可能なソリューションの1つです。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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]で定義されているように、IS、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:
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 byte
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 byte
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つ以上の完全に適格なドメイン名（FQDNS）で始まります。サブオプションレイアウトを以下に示します。
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.
サブオプションには複数のドメイン名が含まれている場合がありますが、これらは同じプロバイダー内の異なるレコードではなく、異なるプロバイダーの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]に記載されているメカニズムを適用して、リストされた順序でレコードを試してみる必要があります。クライアントは、最初のドメイン名に連絡しようとする場合にのみ、後続のドメイン名を解決します。
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」のサーバーです。これらは次のようにエンコードされます。
+-----+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|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:
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で説明されているのと同じ形式（サブOPTコードと長さの値を除く）に従います。サブOPTコードと長さの値は2オクテットであり、長さにはそれ自体またはサブサブが含まれません。コードフィールドを選択します。サブオプションレイアウトを以下に示します。
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で説明されているのと同じ形式（サブOPTコードと長さの値を除く）に従います。サブOPTコードと長さの値は2オクテットであり、長さにはそれ自体またはサブサブが含まれません。コードフィールドを選択します。サブオプションレイアウトを以下に示します。
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のネットワーク情報が不足している場合、または既存のMOの単一の障害の点から回復するために、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アドレスオプションまたは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つ以上のサブオプションを含む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サーバーがPRLのMOS IPv4アドレスオプションまたはMOSドメイン名リストオプションのいずれかを受信する場合、DHCPサーバーは[RFC2131]で定義されているように、応答メッセージにオプションを含める必要があります。
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のネットワーク情報が不足している場合、または既存のMOの単一の障害の点から回復するために、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アドレスオプションまたはMOSドメイン名リストオプションオプションリクエストオプション（ORO）に、定義されたDHCPメッセージのいずれかを含める必要があります。[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つ以上のサブオプションを含む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サーバーがOROのMOS IPv6アドレスオプションまたはMOSドメイン名リストオプションのいずれかを受信する場合、DHCPサーバーは[RFC3315]で定義されているように、応答メッセージにオプションを含める必要があります。
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をRogue Mobility Serverに連絡するように導かれる可能性があります。
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サーバーへのサービス拒否攻撃も保護されます。[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（option-ipv4_address-mos）のMOSIPv4アドレスオプション139
MoS Domain Name List option for DHCPv4 (OPTION-IPv4_FQDN-MoS) 140 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).
DHCPV4のMOSドメイン名リストオプション（オプション-IPV4_FQDN-MOS）140このドキュメントは、「IEE 802.21サービスタイプ」（セクション2および3）と呼ばれるMOS DHCPV4アドレスとFQDNオプションのサブオプションフィールドの新しいレジストリを作成します。
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のMOSIPv6アドレスオプション（オプション-IPv6_Address-mos）54
MoS Domain Name List option for DHCPv6 (OPTION-IPv6_FQDN-MoS) 55
dhcpv6（option-ipv6_fqdn-mos）のMOSドメイン名リストオプション55
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サービスタイプ」（セクション4および5）と呼ばれるMOS DHCPV6アドレスとFQDNオプションのサブオプションフィールドの新しいレジストリを作成します。
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.
著者は、Alfred Hoenes、Bernie Volz、David W. Hankins、Jari Arkko、Telemaco Melia、Ralph Droms、Ted Lemon、Vijay Devarapalli、Yoshihiro Ohbaなど、貴重なコメントについて、次の個人を認めたいと考えています。
[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月。
[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.、ed。、およびW. Arbaugh、ed。、「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.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6のダイナミックホスト構成プロトコル」、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] Lemon、T。およびS. Cheshire、「ダイナミックホスト構成プロトコル（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] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「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] Melia、T.、Ed。、Bajko、G.、Das、S.、Golmie、N。、およびJC。Zuniga、「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
gabor bajko nokiaメール：gabor.bajko@nokia.com
Subir Das Telcordia Technologies Inc. EMail: subir@research.telcordia.com
Subir Das Telcordia Technologies Inc.電子メール：subir@research.telcordia.com