Network Working Group G. Bajko
Request for Comments: 5679 Nokia
Category: Standards Track December 2009
Locating IEEE 802.21 Mobility Services Using DNS
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.
著作権（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. 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情報サービス（MIHIS）は、上位層モビリティを支援する目的で、地理的領域内の既存のネットワークの複数の種類の発見と選択を容易にするために、異種ネットワーク環境全体の上位層エンティティに統一されたフレームワークを提供IS異種ネットワークのグローバルなビューを取得し、これらのネットワーク間のシームレスなハンドオーバを実行するためのプロトコル。
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の用語では、これらのサービスは、メディア独立ハンドオーバ（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.
L3トランスポートを介してMIHメッセージを転送するときに、「サービス管理」サービスメッセージ、すなわち、MIH登録、MIH性能発見とMIHイベントサブスクリプション・メッセージは、MIHESとMIHCSとして考えられています。
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.
モビリティサーバが必ずしもので別途MIHサービスタイプを発見する必要があり、一緒にこれらのMIHサービスの3つのすべてをホストしていことが予想されます。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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]は動的に構成委譲システムをサポートするために、データの列の遅延バインディングを実装するために使用されます。 DDDS機能端末状態が達成されるまで反復文字列変換規則を適用することによって、DDDSデータベース内に格納されたデータにいくつかのユニークな文字列をマッピングすることによって。 DDDSルールの分散データベースとしてDNSを使用する場合、これらのルールは、命名権限ポインタ（NAPTR）リソースレコード（RR）を使用して符号化されます。これらのルールの一つは、プロセスが始まると言うまずよく知られているルールです。
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].
レゾルバの検索パスのいずれか、事前構成されたDHCPを使用して発見された、または以前MIH情報サービスから学習することができる（IS）クエリ[IEEE802.21] [RFC5677]に記載されているように。
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は、ローカルにモビリティサービスを発見する必要がある場合には、所望のサービスをホストするサーバーのIPアドレスを発見するために、[RFC5678]で説明したようにDHCPを使用して、それを直接連絡してください、ドメイン（訪問）。いくつかの例において、発見は、その後の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情報サービス（IS）クエリ[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は、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]で定義されたモビリティサービスの特性を知っている必要がありますし、それに基づいて、そのハンドオーバを容易にするために、使用したいサービスを選択することができるはずです。それが選択できるサービスは以下のとおりです。 - インフォメーションサービス（MIHIS） - イベントサービス（MIHES） - コマンドサービス（MIHCS）
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.
サービスのサービス識別子は、それぞれ、「MIHES」、および「MIHCS」、「MIHIS」です。 [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は、前のセクションで定義されたサービスの識別子であり、Xは、によってサポートされるトランスポートプロトコルに対応する文字である場合、トランスポートプロトコルの選択のタスクに関連するサービスは、値「ID + M2X」のNAPTRサービスフィールドを有するものですドメイン。この仕様は、TCPとSCTPのためM2SのためにUDP、M2TためM2Uを定義します。この文書はまた、トランスポートプロトコルに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]のレコードは、NAPTRサービスフィールドに特定のトランスポートプロトコルを使用してサーバに接触するためにSRV [RFC2782]レコードへのドメインからのマッピングを提供します。リソースレコードは、その特定のトランスポートプロトコルのための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」ではありません解決サービスを識別する任意のサービスフィールドを捨てなければなりません。 NAPTR処理RFC 3403に記載されているように、クライアントによってサポートされているサーバの最も好適なトランスポートプロトコル、ならびにサーバの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 50 "秒" "MIHIS + M2T" "" _MIHIS._tcp.example.com NAPTR 90 50 "S" "MIHIS + M2U" "" _MIHIS._udp.example.com順番県の国旗サービス正規表現の交換
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 0 2 XXXX server2.example.com、IN SRV 0 1 XXXX server1.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イベントサービスとMIHコマンドサービスの「_MIHCS」の「_MIHES」行われます。クエリが成功した場合、特定のトランスポートがサポートされています。クライアントは、サーバによってサポートされている、それが希望する任意のトランスポートプロトコルを使用してもよいです。
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例の正規表現のフィールドが空であることに留意されたいです。 MIHサービスを発見したときに、その使用が複雑で、エラーが発生しやすいことができるよう正規表現のフィールドは、使用してはいけません。また、MIHサービスの発見は、TARGETフィールドに存在する静的ターゲット上でこのフィールドが提供する柔軟性を必要としません。
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 RRの仕様によれば、対象フィールドは、一つ以上のアドレスレコードを持たなければならない完全修飾ドメイン名（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
サービスフィールドのプロトコル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はまた、プロトコルおよびサービス名レジストリ内のサービス名としてMIHIS、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]は保護を提供します。したがって、DNSSEC [RFC4033]の使用状況やDNSSEC運用プラクティス[RFC4641]展開IEEE 802.21モビリティサービスの側面を考慮することをお勧めします。
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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.チェシャー、 "動的ホスト構成プロトコル（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.、 "ダイナミックな委譲発見システム（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.、エド。、RFC 3646、2003年12月、 "IPv6の動的ホスト構成プロトコル（DHCPv6）のためのDNSの設定オプション"。
[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月。
[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.ダス、 "動的ホスト構成プロトコル（DHCPv4とDHCPv6の）IEEE 802.21モビリティサービス（MOS）の発見のためのオプション"、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.、 "ダイナミックな委譲発見システム（DDDS）第一部：総合DDDS"、RFC 3401、2002年10月。
[RFC3833] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[RFC3833]アトキンス、D.とR. Austeinと、RFC 3833 "ドメインネームシステム（DNS）の脅威分析"、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]メリア、T.、エド、 "モビリティサービス交通：問題文"。、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]ヒューバート、A.とR.バンムック、RFC 5452、2009年1月 "鍛造回答に対するDNSは、より弾力性を作るための措置"。
Author's Address
著者のアドレス
Gabor Bajko Nokia EMail: gabor.bajko@nokia.com
ガボールBajkoノキアEメール：gabor.bajko@nokia.com