[要約] RFC 5679は、IEEE 802.21モビリティサービスをDNSを使用して特定するための方法を提案しています。このRFCの目的は、モビリティサービスの検索と特定を簡素化し、モビリティ管理を向上させることです。
Network Working Group G. Bajko
Request for Comments: 5679 Nokia
Category: Standards Track December 2009
Locating IEEE 802.21 Mobility Services Using DNS
DNSを使用したIEEE 802.21モビリティサービスの検索
Abstract
概要
This document defines application service tags that allow service location without relying on rigid domain naming conventions, and DNS procedures for discovering servers that provide IEEE 802.21-defined Mobility Services. Such Mobility Services are used to assist a Mobile Node (MN) supporting IEEE 802.21, in handover preparation (network discovery) and handover decision (network selection). The services addressed by this document are the Media Independent Handover Services defined in IEEE 802.21.
このドキュメントでは、リジッドドメインの命名規則に依存せずにサービスの場所を許可するアプリケーションサービスタグと、IEEE 802.21定義のモビリティサービスを提供するサーバーを発見するためのDNS手順を定義します。このようなモビリティサービスは、IEEE 802.21をサポートするモバイルノード（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. Discovering a Mobility Server ...................................3
2.1. Selecting a Mobility Service ...............................5
2.2. Selecting the Transport Protocol ...........................5
2.3. Determining the IP Address and Port ........................6
3. IANA Considerations .............................................7
4. Security Considerations .........................................8
5. Normative References ............................................8
6. Informative References ..........................................9
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) MIH Information Service (MIHIS) IS provide 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, with the objective to help the higher-layer mobility protocols to acquire a global view of the heterogeneous networks and perform seamless handover across these networks.
a) MIH Information Service（MIHIS）は、不均一なネットワーク環境全体の高層エンティティに統一されたフレームワークを提供し、地理的領域内に存在する複数のタイプのネットワークの発見と選択を促進し、高層モビリティプロトコルを支援する目的で、不均一なネットワークのグローバルビューを取得し、これらのネットワーク全体でシームレスなハンドオーバーを実行します。
b) MIH Event Service (MIHES) 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 Services may also be used to indicate management actions or command status on the part of the network or some management entity.
b) MIHイベントサービス（MIHES）イベントは、物理、データリンク、論理リンクレイヤーの状態および伝送挙動の変化を示している場合があります。イベントサービスは、ネットワーク側または一部の管理エンティティの管理アクションまたはコマンドステータスを示すためにも使用できます。
c) MIH Command Service (MIHCS) 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) MIHコマンドサービス（MIHCS）コマンドサービスにより、高レイヤーが物理、データリンク、および論理リンクレイヤーを制御することができます。高層は、ハンドオーバーコマンドのセットを介して適切なリンクの再構成または選択を制御する場合があります。
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）サービスと呼ばれます。これらのサービスは共同住宅である可能性がありますが、それらが提供するさまざまなパターンと情報の種類は、共同ロケーションを必要としません。
"Service Management" service messages, i.e., MIH registration, MIH capability discovery and MIH event subscription messages, are considered as MIHES and MIHCS when transporting MIH messages over L3 transport.
「サービス管理」サービスメッセージ、つまりMIH登録、MIH機能発見、MIHイベントサブスクリプションメッセージは、L3トランスポートを介してMIHメッセージを輸送する際にMIHEおよびMIHCと見なされます。
A Mobile Node (MN) may make use of any of these MIH service types separately or any combination of them.
モバイルノード（MN）は、これらのMIHサービスタイプのいずれかを個別に使用するか、それらの任意の組み合わせを使用する場合があります。
It is anticipated that a Mobility Server will not necessarily host all three of these MIH services together, thus there is a need to discover the MIH service types separately.
モビリティサーバーは、これら3つのMIHサービスの3つすべてを一緒にホストするとは限らないため、MIHサービスタイプを個別に発見する必要があると予想されます。
This document defines a number of application service tags that allow service location without relying on rigid domain naming conventions.
このドキュメントでは、剛性ドメインの命名規則に依存せずにサービスの場所を許可する多くのアプリケーションサービスタグを定義します。
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: composed of a set of different services provided by the network to mobile nodes to facilitate handover preparation and handover decision, as described in [IEEE802.21] and [RFC5164].
モビリティサービス：[IEEE802.21]および[RFC5164]で説明されているように、ハンドオーバーの準備と引き渡しの決定を容易にするために、ネットワークがモバイルノードに提供するさまざまなサービスのセットで構成されています。
Mobility Server: a network node providing IEEE 802.21 Mobility Services.
モビリティサーバー：IEEE 802.21モビリティサービスを提供するネットワークノード。
MIH: Media Independent Handover, as defined in [IEEE802.21].
MIH：[IEEE802.21]で定義されているメディア独立したハンドオーバー。
Application service: is a generic term for some type of application, independent of the protocol that may be used to offer it. Each application service will be associated with an IANA-registered tag.
アプリケーションサービス：それを提供するために使用されるプロトコルとは無関係に、何らかのタイプのアプリケーションの一般的な用語です。各アプリケーションサービスは、IANA登録タグに関連付けられます。
Application protocol: is used to implement the application service. These are also associated with IANA-registered tags.
アプリケーションプロトコル：アプリケーションサービスの実装に使用されます。これらは、IANA登録タグにも関連付けられています。
Home domain: the DNS suffix of the operator with which the Mobile Node has a subscription service. The suffix is usually stored in the Mobile Node as part of the subscription.
ホームドメイン：モバイルノードにサブスクリプションサービスがあるオペレーターのDNSサフィックス。接尾辞は通常、サブスクリプションの一部としてモバイルノードに保存されます。
The Dynamic Delegation Discovery System (DDDS) [RFC3401] is used to implement lazy binding of strings to data, in order to support dynamically configured delegation systems. The DDDS functions by mapping some unique string to data stored within a DDDS database by iteratively applying string transformation rules until a terminal condition is reached. When DDDS uses DNS as a distributed database of rules, these rules are encoded using the Naming Authority Pointer (NAPTR) Resource Record (RR). One of these rules is the First Well Known Rule, which says where the process starts.
動的委任ディスカバリーシステム（DDDS）[RFC3401]は、動的に構成された委任システムをサポートするために、データへの文字列の怠zyな結合を実装するために使用されます。DDDSは、端末条件に達するまで文字列変換ルールを反復的に適用することにより、DDDSデータベース内に保存されたデータにいくつかの一意の文字列をマッピングすることにより機能します。DDDSがDNSをルールの分散データベースとして使用する場合、これらのルールは、命名権限ポインター（NAPTR）リソースレコード（RR）を使用してエンコードされます。これらのルールの1つは、最初によく知られているルールであり、プロセスが始まる場所を示しています。
In current specifications, the First Well Known Rule in a DDDS application [RFC3403] is assumed to be fixed, i.e., the domain in the tree where the lookups are to be routed to, is known. This document proposes the input to the First Well Known Rule to be dynamic, based on the search path the resolver discovers or is configured with.
現在の仕様では、DDDSアプリケーション[RFC3403]で最初によく知られているルールが固定されていると想定されています。つまり、ルックアップがルーティングされるツリー内のドメインが既知であると想定されています。このドキュメントでは、リゾルバーが発見または構成されている検索パスに基づいて、最初によく知られているルールへの入力が動的であることを提案します。
The search path of the resolver can either be pre-configured, discovered using DHCP, or learned from a previous MIH Information Services (IS) query [IEEE802.21] as described in [RFC5677].
Resolverの検索パスは、[RFC5677]に記載されているように、事前に構成され、DHCPを使用して発見された、または以前のMIH情報サービス（IEE802.21]から学習することができます。
When the MN needs to discover Mobility Services in its home domain, the input to the First Well Known Rule MUST be the MN's home domain, which is assumed to be pre-configured in the MN.
MNがホームドメインでモビリティサービスを発見する必要がある場合、最初によく知られているルールへの入力はMNのホームドメインでなければなりません。これはMNで事前に構成されていると想定されています。
When the MN needs to discover Mobility Services in a local (visited) domain, it SHOULD use DHCP as described in [RFC5678] to discover the IP address of the server hosting the desired service, and contact it directly. In some instances, the discovery may result in a per protocol/application list of domain names that are then used as starting points for the subsequent NAPTR lookups. If neither the IP address or domain name can be discovered with the above procedure, the MN MAY request a domain search list, as described in [RFC3397] and [RFC3646], and use it as input to the DDDS application.
MNがローカル（訪問）ドメインでモビリティサービスを発見する必要がある場合、[RFC5678]に記載されているDHCPを使用して、目的のサービスをホストするサーバーのIPアドレスを発見し、直接連絡する必要があります。場合によっては、発見により、ドメイン名のプロトコル/アプリケーションリストが作成される場合があり、その後、その後のNAPTR検索の出発点として使用されます。上記の手順でIPアドレスまたはドメイン名のいずれも発見できない場合、MNは[RFC3397]および[RFC3646]で説明されているようにドメイン検索リストを要求し、DDDSアプリケーションへの入力として使用できます。
The MN may also have a list of cached domain names of Service Providers, learned from a previous MIH Information Services (IS) query [IEEE802.21]. If the cache entries have not expired, they can be used as input to the DDDS application.
MNには、以前のMIH情報サービス（IE）クエリ[IEEE802.21]から学習したサービスプロバイダーのキャッシュドメイン名のリストも含まれている場合があります。キャッシュエントリの有効期限が切れていない場合、DDDSアプリケーションへの入力として使用できます。
When the MN does not find valid domain names using the procedures above, it MUST stop any attempt to discover MIH services.
上記の手順を使用してMNが有効なドメイン名を見つけられない場合、MIHサービスを発見する試みを停止する必要があります。
The dynamic rule described above SHOULD NOT be used for discovering services other than MIH services described in this document, unless stated otherwise by a future specification.
上記の動的ルールは、将来の仕様で特に述べられていない限り、このドキュメントに記載されているMIHサービス以外のサービスを発見するために使用されるべきではありません。
The procedures defined here result in an IP address, port, and transport protocol where the MN can contact the Mobility Server that hosts the service the MN is looking for.
ここで定義されている手順により、MNが探しているサービスをホストするモビリティサーバーに連絡できるIPアドレス、ポート、および輸送プロトコルが作成されます。
The MN should know the characteristics of the Mobility Services defined in [IEEE802.21], and based on that, it should be able to select the service it wants to use to facilitate its handover. The services it can choose from are: - Information Services (MIHIS) - Event Services (MIHES) - Command Services (MIHCS)
MNは、[IEEE802.21]で定義されているモビリティサービスの特性を知っている必要があり、それに基づいて、ハンドオーバーを容易にするために使用するサービスを選択できるはずです。選択できるサービスは次のとおりです。
The service identifiers for the services are "MIHIS", "MIHES", and "MIHCS", respectively. The server supporting any of the above services MUST support at least UDP and TCP as transport, as described in [RFC5677]. SCTP and other transport protocols MAY also be supported.
サービスのサービス識別子は、それぞれ「MIHIS」、「MIHES」、および「MIHCS」です。上記のサービスのいずれかをサポートするサーバーは、[RFC5677]で説明されているように、輸送として少なくともUDPおよびTCPをサポートする必要があります。SCTPおよびその他の輸送プロトコルもサポートされる場合があります。
After the desired service has been chosen, the client selects the transport protocol it prefers to use. Note that transport selection may impact the handover performance.
目的のサービスが選択された後、クライアントは使用することを好むトランスポートプロトコルを選択します。輸送の選択は、ハンドオーバーパフォーマンスに影響を与える可能性があることに注意してください。
The services relevant for the task of transport protocol selection are those with NAPTR service fields with values "ID+M2X", where ID is the service identifier defined in the previous section, and X is a letter that corresponds to a transport protocol supported by the domain. This specification defines M2U for UDP, M2T for TCP and M2S for SCTP. This document also establishes an IANA registry for mappings of NAPTR service name to transport protocol.
輸送プロトコル選択のタスクに関連するサービスは、値「ID M2X」を持つNAPTRサービスフィールドを持つものです。ここで、IDは前のセクションで定義されているサービス識別子であり、Xはドメインでサポートされている輸送プロトコルに対応する文字です。この仕様では、UDPのM2U、TCPのM2T、SCTPのM2Tを定義します。このドキュメントでは、NAPTRサービス名のマッピングのIANAレジストリを輸送プロトコルに確立します。
These NAPTR [RFC3403] records provide a mapping from a domain to the SRV [RFC2782] record for contacting a server with the specific transport protocol in the NAPTR services field. The resource record MUST contain an empty regular expression and a replacement value, which indicates the domain name where the SRV record for that particular transport protocol can be found. If the server supports multiple transport protocols, there will be multiple NAPTR records, each with a different service value. As per [RFC3403], the client discards any records whose services fields are not applicable.
これらのNAPTR [RFC3403]レコードは、ドメインからSRV [RFC2782]レコードへのマッピングを提供し、NAPTRサービスフィールドの特定のトランスポートプロトコルとサーバーに接触するためのレコードを提供します。リソースレコードには、空の正規表現と交換値が含まれている必要があります。これには、その特定の輸送プロトコルのSRVレコードが見つかるドメイン名が示されています。サーバーが複数のトランスポートプロトコルをサポートしている場合、それぞれが異なるサービス値を持つ複数のNAPTRレコードがあります。[RFC3403]によると、クライアントは、サービスフィールドが適用されないレコードを破棄します。
The MN MUST discard any service fields that identify a resolution service whose value is not "M2X", for values of X that indicate transport protocols supported by the client. The NAPTR processing as described in RFC 3403 will result in the discovery of the most preferred transport protocol of the server that is supported by the client, as well as an SRV record for the server.
MNは、クライアントがサポートする輸送プロトコルを示すXの値に対して、値が「M2X」ではない解像度サービスを識別するサービスフィールドを破棄する必要があります。RFC 3403で説明されているNAPTR処理により、クライアントがサポートするサーバーの最も優先されるトランスポートプロトコルと、サーバーのSRVレコードが発見されます。
As an example, consider a client that wishes to find MIHIS service in the example.com domain. The client performs a NAPTR query for that domain, and the following NAPTR records are returned:
例として、example.comドメインでMIHISサービスを見つけたいクライアントを検討してください。クライアントは、そのドメインに対してNAPTRクエリを実行し、次のNAPTRレコードが返されます。
Order Pref Flags Service Regexp Replacement IN NAPTR 50 50 "s" "MIHIS+M2T" "" _MIHIS._tcp.example.com IN NAPTR 90 50 "s" "MIHIS+M2U" "" _MIHIS._udp.example.com
NAPTR 50 "s" "Mihis M2T" "" _mihis._tcp.example.comのNaptr 50 "s" "Mihis M2TのRegexp交換を注文する注文
This indicates that the domain does have a server providing MIHIS services over TCP and UDP, in that order of preference. Since the client supports TCP and UDP, TCP will be used, targeted to a host determined by an SRV lookup of _MIHIS._tcp.example.com. That lookup would return:
これは、ドメインがその好みの順に、TCPおよびUDPを介してMIHISサービスを提供するサーバーを持っていることを示しています。クライアントはTCPとUDPをサポートしているため、TCPが使用され、_mihis._tcp.example.comのSRV検索によって決定されるホストをターゲットにします。その検索は戻ります：
;; Priority Weight Port Target IN SRV 0 1 XXXX server1.example.com IN SRV 0 2 XXXX server2.example.com
;;SRVの優先ウェイトポートターゲット1 xxxx server1.example.com in srv 0 2 xxxx server2.example.com
where XXXX represents the port number at which the service is reachable.
xxxxは、サービスに到達可能なポート番号を表します。
If no NAPTR records are found, the client constructs SRV queries for those transport protocols it supports, and does a query for each. Queries are done using the service identifier "_MIHIS" for the MIH Information Service, "_MIHES" for the MIH Event Service and "_MIHCS" for the MIH Command Service. A particular transport is supported if the query is successful. The client MAY use any transport protocol it desires that is supported by the server.
NAPTRレコードが見つからない場合、クライアントはサポートするトランスポートプロトコルのSRVクエリを構築し、それぞれに対してクエリを行います。クエリは、MIH情報サービスのサービス識別子「_Mihis」、MIHイベントサービスの_MIHES」、MIHコマンドサービスの「_MIHCS」を使用して行われます。クエリが成功した場合、特定のトランスポートがサポートされています。クライアントは、サーバーによってサポートされている任意の輸送プロトコルを使用する場合があります。
Note that the regexp field in the NAPTR example above is empty. The regexp field MUST NOT be used when discovering MIH services, as its usage can be complex and error prone. Also, the discovery of the MIH services does not require the flexibility provided by this field over a static target present in the TARGET field.
上記のNAPTR例のregexpフィールドは空であることに注意してください。MIHサービスを発見するときは、その使用が複雑でエラーが発生する可能性があるため、Regexpフィールドを使用してはなりません。また、MIHサービスの発見では、ターゲットフィールドに存在する静的なターゲットを介してこのフィールドが提供する柔軟性を必要としません。
If the client is already configured with the information about which transport protocol is used for a mobility service in a particular domain, it can directly perform an SRV query for that specific transport using the service identifier of the Mobility Service. For example, if the client knows that it should be using TCP for MIHIS service, it can perform a SRV query directly for _MIHIS._tcp.example.com.
クライアントが特定のドメインのモビリティサービスに使用されるトランスポートプロトコルに関する情報で既に構成されている場合、モビリティサービスのサービス識別子を使用して、その特定のトランスポートのSRVクエリを直接実行できます。たとえば、クライアントがMIHISサービスにTCPを使用する必要があることを知っている場合、_mihis._tcp.example.comのSRVクエリを直接実行できます。
Once the server providing the desired service and the transport protocol has been determined, the next step is to determine the IP address and port.
目的のサービスと輸送プロトコルを提供するサーバーが決定されたら、次のステップはIPアドレスとポートを決定することです。
The response to the SRV DNS query contains the port number in the Port field of the SRV RDATA.
SRV DNSクエリへの応答には、SRV RDATAのポートフィールドにポート番号が含まれています。
According to the specification of SRV RRs in [RFC2782], the TARGET field is a fully qualified domain name (FQDN) that MUST have one or more address records; the FQDN must not be an alias, i.e., there MUST NOT be a CNAME or DNAME RR at this name. Unless the SRV DNS query already has reported a sufficient number of these address records in the Additional Data section of the DNS response (as recommended by [RFC2782]), the MN needs to perform A and/or AAAA record lookup(s) of the domain name, as appropriate. The result will be a list of IP addresses, each of which can be contacted using the transport protocol determined previously.
[RFC2782]のSRV RRSの仕様によると、ターゲットフィールドは、1つ以上のアドレスレコードが必要な完全に適格なドメイン名（FQDN）です。FQDNはエイリアスであってはなりません。つまり、この名前にCNAMEまたはDNAME RRを存在してはなりません。SRV DNSクエリがDNS応答の追加データセクション（[RFC2782]で推奨されているように）に十分な数のこれらのアドレスレコードをすでに報告していない限り、MNはAおよび/またはAAAAレコード検索を実行する必要があります。必要に応じてドメイン名。結果は、以前に決定されたトランスポートプロトコルを使用して、それぞれに連絡できるIPアドレスのリストになります。
The usage of NAPTR records described here requires well-known values for the service fields for each transport supported by Mobility Services. The table of mappings from service field values to transport protocols is to be maintained by IANA.
ここで説明するNAPTRレコードの使用には、モビリティサービスがサポートする各輸送のサービスフィールドのよく知られた値が必要です。サービスフィールド値から輸送プロトコルへのマッピングの表は、IANAによって維持されます。
The registration in the RFC MUST include the following information:
RFCへの登録には、次の情報を含める必要があります。
Service Field: The service field being registered.
サービスフィールド：登録されているサービスフィールド。
Protocol: The specific transport protocol associated with that service field. This MUST include the name and acronym for the protocol, along with reference to a document that describes the transport protocol.
プロトコル：そのサービスフィールドに関連付けられた特定の輸送プロトコル。これには、プロトコルの名前と頭字語が含まれ、トランスポートプロトコルを説明するドキュメントを参照する必要があります。
Name and Contact Information: The name, address, email address, and telephone number for the person performing the registration.
名前と連絡先情報：登録を実行している人の名前、住所、メールアドレス、電話番号。
The following values have been placed into the registry:
次の値がレジストリに配置されています。
Service Fields Protocol
MIHIS+M2T TCP
MIHIS+M2U UDP
MIHIS+M2S SCTP
MIHES+M2T TCP
MIHES+M2U UDP
MIHES+M2S SCTP
MIHCS+M2T TCP
MIHCS+M2U UDP
MIHCS+M2S SCTP
New Service Fields are to be added via Standards Action as defined in [RFC5226].
[RFC5226]で定義されているように、新しいサービスフィールドは標準アクションを介して追加されます。
New entries to the table that specify additional transport protocols for the existing Service Fields may similarly be registered by IANA through Standards Action [RFC5226].
既存のサービスフィールドに追加の輸送プロトコルを指定するテーブルへの新しいエントリも、標準アクション[RFC5226]を通じてIANAによって同様に登録される場合があります。
IANA is also requested to register MIHIS, MIHES, MIHCS as service names in the Protocol and Service Names registry.
IANAは、MIHI、MIHES、MIHCSをプロトコルおよびサービス名レジストリのサービス名として登録することも要求されています。
A list of known threats to services using DNS is documented in [RFC3833]. For most of those identified threats, the DNS Security Extensions [RFC4033] does provide protection. It is therefore recommended to consider the usage of DNSSEC [RFC4033] and the aspects of DNSSEC Operational Practices [RFC4641] when deploying IEEE 802.21 Mobility Services.
DNSを使用したサービスに対する既知の脅威のリストは、[RFC3833]に文書化されています。これらの特定された脅威のほとんどについて、DNSセキュリティ拡張[RFC4033]は保護を提供します。したがって、IEEE 802.21モビリティサービスを展開する際のDNSSEC [RFC4033]の使用とDNSSEC運用慣行[RFC4641]の側面を考慮することをお勧めします。
In deployments where DNSSEC usage is not feasible, measures should be taken to protect against forged DNS responses and cache poisoning as much as possible. Efforts in this direction are documented in [RFC5452].
DNSSECの使用が実行不可能な展開では、偽造されたDNS応答とキャッシュ中毒から可能な限り保護するための対策を講じる必要があります。この方向への取り組みは、[RFC5452]に記録されています。
Where inputs to the procedure described in this document are fed via DHCP, DHCP vulnerabilities can also cause issues. For instance, the inability to authenticate DHCP discovery results may lead to the mobility service results also being incorrect, even if the DNS process was secured.
このドキュメントで説明されている手順への入力がDHCPを介して供給される場合、DHCPの脆弱性も問題を引き起こす可能性があります。たとえば、DHCP発見の結果を認証できないと、DNSプロセスが確保されていても、モビリティサービスの結果も間違っている可能性があります。
[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月。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月。
[RFC3397] Aboba, B. and S. Cheshire, "Dynamic Host Configuration Protocol (DHCP) Domain Search Option", RFC 3397, November 2002.
[RFC3397] Aboba、B。およびS. Cheshire、「動的ホスト構成プロトコル（DHCP）ドメイン検索オプション」、RFC 3397、2002年11月。
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[RFC3403] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート3：ドメイン名システム（DNS）データベース」、RFC 3403、2002年10月。
[RFC3646] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[RFC3646] DROMS、R.、ed。、「IPv6（DHCPV6）の動的ホスト構成プロトコルのDNS構成オプション」、RFC 3646、2003年12月。
[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月。
[RFC5678] Bajko, G. and S. Das, "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Options for IEEE 802.21 Mobility Services (MoS) Discovery", RFC 5678, December 2009.
[RFC5678] Bajko、G。およびS. Das、「IEEE 802.21 Mobility Services（MOS）Discoveryのダイナミックホスト構成プロトコル（DHCPV4およびDHCPV6）オプション」、RFC 5678、2009年12月。
[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（ドキュメントへのアクセスにはメンバーシップが必要です）。
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3401] Mealling、M。、「Dynamic Delogation Discovery System（DDDS）パート1：包括的なDDDS」、RFC 3401、2002年10月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833] Atkins、D。およびR. Austein、「ドメイン名システムの脅威分析（DNS）」、RFC 3833、2004年8月。
[RFC4641] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", RFC 4641, September 2006.
[RFC4641] Kolkman、O。およびR. Gieben、「DNSSEC運用慣行」、RFC 4641、2006年9月。
[RFC5164] Melia, T., Ed., "Mobility Services Transport: Problem Statement", RFC 5164, March 2008.
[RFC5164] Melia、T.、ed。、「Mobility Services Transport：Problem Statement」、RFC 5164、2008年3月。
[RFC5452] Hubert, A. and R. van Mook, "Measures for Making DNS More Resilient against Forged Answers", RFC 5452, January 2009.
[RFC5452] Hubert、A。およびR. Van Mook、「Forged Answersに対してDNSをより回復力のあるものにするための対策」、RFC 5452、2009年1月。
Author's Address
著者の連絡先
Gabor Bajko Nokia EMail: gabor.bajko@nokia.com
gabor bajko nokiaメール：gabor.bajko@nokia.com