Network Working Group J. Korhonen
Request for Comments: 5149 U. Nilsson
Category: Informational TeliaSonera
V. Devarapalli
Azaire
February 2008
Service Selection for Mobile IPv6
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Abstract
抽象
In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription. A capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers on provisioning multiple services to one mobility service subscription. This document describes a Service Selection Mobility Option for both conventional Mobile IPv6 and Proxy Mobile IPv6 that is intended to assist home agents to make a specific service selection for the mobility service subscription during the binding registration procedure.
一部のモバイルIPv6展開では、モバイルノードまたはモビリティ・サービス加入者を識別することは、おそらく前記モバイルノードと、モビリティ・サービス・サブスクリプションにプロビジョニングされた複数のサービスを区別するのに十分ではありません。モバイルノードのアイデンティティに加えて、さまざまなサービスを指定する機能は、1つのモビリティサービスのサブスクリプションに複数のサービスをプロビジョニングするにモビリティ・サービス・プロバイダのための柔軟性を提供するために活用することができます。この文書では、バインディング登録手続きの際にモビリティサービス加入のための特定のサービスの選択を行うためにホームエージェントを支援するためのものです、従来のモバイルIPv6およびプロキシモバイルIPv6の両方のためのサービス選択モビリティ・オプションについて説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Service Selection Mobility Option . . . . . . . . . . . . . . . 3
4. Processing Considerations . . . . . . . . . . . . . . . . . . . 4
4.1. Mobile Node Considerations . . . . . . . . . . . . . . . . 4
4.2. Home Agent Considerations . . . . . . . . . . . . . . . . . 5
4.3. Correspondent Node Considerations . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . . 7
Mobile IPv6 [2] can identify mobile nodes in various ways, including home addresses [2], Network Access Identifiers (NAIs) [6][7], and credentials suitable for the Internet Key Exchange Protocol version 2 (IKEv2) [10]. In some Mobile IPv6 deployments, identifying the mobile node or the mobility service subscriber via a Proxy Mobile IPv6 client [5] (hereafter, the mobile node and the Proxy Mobile IPv6 client are used interchangeably) is not enough to distinguish between multiple services possibly provisioned to the said mobile node and its mobility service subscription.
モバイルIPv6 [2] [2]、ネットワークアクセス識別子（のNAI）のホームアドレスを含む様々な方法でモバイルノードを識別することができる[6] [7]、およびインターネット鍵交換プロトコルバージョン2（IKEv2の）に適した資格情報[10] 。一部のモバイルIPv6展開では、[5]（以下、モバイルノードとプロキシモバイルIPv6クライアントは互換的に使用される）プロキシモバイルIPv6クライアントを介してモバイルノードまたはモビリティ・サービス加入者を識別することは、おそらくプロビジョニング複数のサービスを区別するのに十分ではありませんモバイルノードとそのモビリティ・サービスのサブスクリプションへ。
The capability to specify different services in addition to the mobile node identity can be leveraged to provide flexibility for mobility service providers to provide multiple services within the same mobility service subscription. For example:
モバイルノードのアイデンティティに加えて、さまざまなサービスを指定する機能は同じモビリティサービスのサブスクリプション内で複数のサービスを提供するために、モビリティ・サービス・プロバイダのための柔軟性を提供するために活用することができます。例えば：
o Provide an enterprise data access for which the mobility service provider hosts connectivity and mobility services on behalf of the enterprise.
Oモビリティサービスプロバイダが企業に代わって接続性とモビリティサービスをホストするために企業データへのアクセスを提供します。
o Provide access to service domains that are otherwise not accessible from public networks because of some mobility service provider's business reasons.
Oそれ以外の理由は、いくつかのモビリティ・サービス・プロバイダーのビジネス上の理由のパブリックネットワークからアクセスできないサービスドメインへのアクセスを提供します。
o Provide simultaneous access to different service domains that are separated based on policies of the mobility service provider.
Oモビリティ・サービス・プロバイダーのポリシーに基づいて分離されている異なるサービスドメインへの同時アクセスを提供します。
o Enable easier policy and quality of service assignment for mobility service providers based on the subscribed services.
O加入したサービスに基づいてモビリティ・サービス・プロバイダのためのより容易なポリシーとサービスの割り当ての品質を有効にします。
o In the absence of a specifically indicated service, the home agent MUST act as if the default service, plain Internet access, had been requested. There is no absolute requirement that this default service be allowed to all subscribers, but it is highly RECOMMENDED in order to avoid having normal subscribers employ operator-specific configuration values in order to get basic service.
デフォルトのサービス、プレーンなインターネットアクセスを、要求されたかのようにO具体的に示されたサービスが存在しない場合には、ホームエージェントが行動しなければなりません。そここのデフォルトのサービスは、すべての加入者に許可される絶対的な要件はありませんが、それは非常に通常の加入者が基本的なサービスを得るためにオペレータ固有の設定値を採用するのを避けるために推奨されます。
This document describes a Service Selection Mobility Option for Mobile IPv6 that is intended to assist home agents to make specific service selections for the mobility service subscription during the binding registration procedure. The service selection may affect home agent routing decisions, Home Address or Home Network Prefix assignment policies, firewall settings, and security policies. The Service Selection option should be used in every Binding Update that makes a new registration to the home agent.
この文書では、バインディング登録手続きの際にモビリティサービス加入のための特定のサービスの選択を行うためにホームエージェントを支援するためのものですモバイルIPv6のためのサービス選択モビリティ・オプションについて説明します。サービス選択は、ホームエージェントのルーティングの決定、自宅住所やホームネットワークプレフィックスの割り当てポリシー、ファイアウォールの設定、およびセキュリティポリシーに影響を与える可能性があります。サービス選択オプションは、ホームエージェントへの新規登録を行うすべてのバインディング更新で使用されるべきです。
Some of the potential use-cases were listed earlier in this section. The general aim is better manageability of services and service provisioning from the point of view of both operators and service providers. However, it should be understood that there are potential deployment possibilities where selecting a certain service may restrict simultaneous access to other services from a user's point of view. For example, services may be located in different administrative domains or external customer networks that practice excessive filtering of inbound and outbound traffic.
潜在的なユースケースの一部は、以前、このセクションでリストされていました。一般的な目的は、事業者やサービスプロバイダの両方の観点から、サービスとサービス・プロビジョニングの優れた管理性です。しかし、特定のサービスを選択すると、ユーザーの観点から、他のサービスへの同時アクセスを制限することができる潜在的な展開の可能性があることを理解すべきです。例えば、サービスは、異なる管理ドメインまたはインバウンドとアウトバウンドのトラフィックの過度のフィルタリングを練習外部の顧客のネットワークに配置することができます。
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 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[1]に記載のように解釈されます。
At most one Service Selection Mobility Option MAY be included in any Binding Update message. If the Binding Update message includes any authorization-related options (such as the Binding Authorization Data option [2]) or authentication related options (such as the Mobility Message Authentication option [8]), then the Service Selection option MUST appear before any mobility message authorization- or authentication-related options.
多くても1つのサービス選択モビリティオプションで任意のBinding Updateメッセージに含まれるかもしれません。 Binding Updateメッセージは、任意の認証関連のオプションが含まれている場合（例えば結合認証データオプションとしての[2]）または認証関連のオプション（例えばモビリティメッセージ認証オプションとして[8]）、[サービスの選択]オプションは、任意のモビリティの前に現れなければなりませんメッセージauthorization-または認証関連のオプション。
The Service Selection option SHOULD NOT be sent to a correspondent node. The mobile node cannot assume that the correspondent node has any knowledge about a specific service selection made between the mobile node and the home agent.
サービス選択オプションは、コレスポンデントノードに送るべきではありません。モバイルノードは、コレスポンデントノードは、モバイルノードとホームエージェントとの間で行われ、特定のサービスの選択についての知識を持っていると仮定することはできません。
The Service Selection option has no alignment requirement as such.
サービス選択オプションは、次のような何のアライメント要件を持っていません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 20 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Service Selection Mobility Option
サービス選択モビリティオプション
o Type: 8-bit identifier set to 20 of the type of the skipable mobility option.
O型：skipableモビリティオプションのタイプの20に設定された8ビットの識別子。
o Length: 8-bit unsigned integer, representing the length of the Service Selection Mobility Option in octets, excluding the Option Type and Option Length fields. A value of zero (0) is not allowed.
Oの長さ：8ビットの符号なし整数、オプションタイプとオプション長フィールドを除く、オクテットでサービス選択モビリティオプションの長さを表します。ゼロ（0）の値は許されません。
o Identifier: A variable-length encoded service identifier string used to identify the requested service. The identifier string length is between 1 and 255 octets. This specification allows international identifier strings that are based on the use of Unicode characters, encoded as UTF-8 [3], and formatted using Normalization Form KC (NFKC) as specified in [4].
O識別子：要求されたサービスを識別するために使用される可変長符号化されたサービス識別子ストリング。識別子の文字列の長さは1〜255オクテットです。この仕様は、[3] UTF-8としてエンコードされ、Unicode文字の使用に基づく国際識別文字列を可能にして、[4]で指定されるように正規化形式KC（NFKC）を使用してフォーマットされました。
'ims', 'voip', and 'voip.companyxyz.example.com' are valid examples of Service Selection option Identifiers. At minimum, the Identifier MUST be unique among the home agents to which the mobile node is authorized to register.
「IMS」、「VoIPの」、および「voip.companyxyz.example.com」がサービス選択オプション識別子の有効な例です。最低でも、識別子は、モバイルノードが登録することを許可されているホームエージェントの間で一意でなければなりません。
A mobile node or a Proxy Mobile IPv6 client MAY include, at most, one Service Selection Mobility Option into a Binding Update message. The option is used to identify the service to be associated with the binding registration and SHOULD only be included into the initial Binding Update message sent to a home agent. If the mobile node wishes to change the selected service, it is RECOMMENDED that the mobile node de-register the existing binding with the home agent before proceeding with a binding registration for a different service. The provisioning of the service identifiers to the mobile node or to the Proxy Mobile IPv6 client is out of the scope of this specification.
モバイルノードまたはプロキシモバイルIPv6クライアントは、最大で、Binding Updateメッセージに1つのサービス選択モビリティオプションを含むかもしれません。オプションは、バインディング登録に関連付けられるサービスを識別するために使用され、唯一のホームエージェントに送信された初期のBinding Updateメッセージに含まれるべきです。モバイルノードが選択されているサービスを変更したい場合は、モバイルノードの異なるサービスのためのバインディング登録を進める前に、既存のホームエージェントとの結合を解除は、登録することを推奨しています。モバイルノードまたはプロキシモバイルIPv6クライアントへのサービス識別子のプロビジョニングは、本明細書の範囲外です。
The placement of the Service Selection option is as follows: when present, this option MUST appear after the Mobile Node-Network Access Identifier (MN-NAI) option, if the MN-NAI option is present, and before any authorization- and authentication-related options. The Service Selection option can be used with any mobile node identification method such as a home address, an MN-NAI, and credentials suitable for IKEv2.
次のようにサービス選択オプションの配置は次のとおりです。存在する場合、このオプションは、MN-NAIオプションが存在する場合、モバイルノード、ネットワークアクセス識別子（MN-NAI）オプションの後に表示され、任意のauthorization-とauthentication-前にしなければなりません関連のオプション。サービス選択のオプションは、ホームアドレス、MN-NAI、およびIKEv2のに適した資格情報などの任意のモバイルノードの識別方法で使用することができます。
If the mobile node receives a Binding Acknowledgement with a Status Code set to SERVICE_AUTHORIZATION_FAILED and the mobile node has an existing binding with the Home Address or the Home Network Prefix used in the failed Binding Update message, the mobile node MUST delete the existing binding. If there is no existing binding, the mobile node proceeds as with any failed initial binding registration.
モバイルノードSERVICE_AUTHORIZATION_FAILEDに設定するステータスコードと結合肯定応答を受信し、移動ノードは、既存のホームアドレスやホームネットワークプレフィックスと結合したが、失敗したBinding Updateメッセージで使用される場合は、モバイルノードは、既存のバインディングを削除しなければなりません。既存の結合が存在しない場合は、任意のと同様に、移動ノード進んで最初の結合の登録に失敗しました。
Upon receiving a Binding Update message with a Service Selection option, the home agent authenticates and authorizes the mobile node. If the home agent supports the Service Selection, it MUST also verify that the mobile node is authorized for the service it included in the Service Selection option. The services the mobile node is authorized for SHOULD be part of the general mobile node subscription profile. If the mobile node is not authorized for the service, the home agent MUST deny the registration and send a Binding Acknowledgement with a Status Code set to SERVICE_AUTHORIZATION_FAILED (151).
サービスの選択]オプションでBinding Updateメッセージを受信すると、ホームエージェントは認証し、モバイルノードを許可します。ホームエージェントはサービス選択をサポートしている場合、それはまた、モバイルノードが、それがサービス選択オプションに含まれるサービスのために承認されていることを確かめなければなりません。モバイルノードがために許可されているサービスは、一般的な移動ノードのサブスクリプション・プロファイルの一部である必要があります。モバイルノードがサービスのために許可されていない場合は、ホームエージェントは登録を拒否しSERVICE_AUTHORIZATION_FAILED（151）に設定するステータスコードと結合謝辞を送らなければなりません。
The Service Selection option is used to assist the authorization and identifies a specific service that is to be authorized. The Service Selection option MAY also affect the Home Address or the Home Network Prefix allocation when, for example, used with the MN-NAI option. For example, for the same NAI there MAY be different Home Addresses or Home Network Prefixes depending on the identified service. Furthermore, the Service Selection option MAY also affect the routing of the outbound IP packets in the home agent depending on the selected service. The home agent MAY also apply different policy or quality of service treatment to traffic flows based on the selected service.
サービス選択オプションは、認可を支援するために使用して許可される特定のサービスを識別しています。例えば、MN-NAIオプションと一緒に使用する場合、サービスの選択オプションもホームアドレスやホームネットワークプレフィックスの割り当てに影響を与える可能性があります。例えば、同じNAIに異なるホームアドレスがあってもよく、あるいはホームネットワークプレフィックスが特定のサービスに依存します。さらに、サービスの選択オプションも選択したサービスに応じて、ホームエージェントにおけるアウトバウンドIPパケットのルーティングに影響を与える可能性があります。ホームエージェントはまた、異なるポリシーやトラフィックへのサービス処理の品質選択したサービスに基づいてフローを適用することができます。
If the newly arrived Binding Update message with a Service Selection option indicates a change in the selected service, then the home agent MUST re-authorize the mobile node. Depending on the home agent policies, the services policies, Home Address or Home Network Prefix allocation policies, and the subscription policies, the home agent may or may not be able to authorize the mobile node to the new service. For example, the existing service and the new service could require different Home Network Prefixes. If the authorization fails, then the home agent MUST deny the registration, delete any binding with the existing Home Address or Home Network Prefix, and send a Binding Acknowledgement with a Status Code set to SERVICE_AUTHORIZATION_FAILED (151).
サービス選択オプションを使用して新たに到着したBinding Updateメッセージは、選択したサービスの変化を示している場合は、ホームエージェントは、モバイルノードを再認証しなければなりません。ホームエージェントポリシーに応じて、サービスポリシー、自宅住所やホームネットワークプレフィックスの割り当てポリシー、およびサブスクリプションポリシーは、ホームエージェントは、または新しいサービスへのモバイルノードを承認することができない可能性があります。たとえば、既存のサービスや新しいサービスが異なるホームネットワークプレフィックスを必要とする可能性があります。認証が失敗した場合、ホームエージェントは、既存のホームアドレスやホームネットワークプレフィックスとの結合を削除し、登録を拒否し、SERVICE_AUTHORIZATION_FAILED（151）に設定するステータスコードと結合謝辞を送らなければなりません。
Unless the correspondent node and the home agent share the same knowledge about mobility services, the Service Selection option is more or less useless information to the correspondent node. The correspondent node SHOULD silently ignore the Service Selection option in this case.
コレスポンデントノードとホームエージェントは、モビリティサービスに関する同じ知識を共有していない限り、サービスの選択オプションは、コレスポンデントノードに多かれ少なかれ役に立たない情報です。コレスポンデントノードは静かに、この場合のサービス選択のオプションを無視します。
There are deployment cases where the home agent and a correspondent node, for example, belong to the same administrative domain. In this case, it is possible that the correspondent node shares the same knowledge of the services as the home agent. Therefore, the correspondent node is, for example, able to provide service-based traffic handling to mobile nodes.
ホームエージェントとコレスポンデントノードは、例えば、同じ管理ドメインに属している展開のケースがあります。この場合、コレスポンデントノードは、ホームエージェントとしてサービスの同じ知識を共有することも可能です。したがって、通信相手ノードは、例えば、モバイルノードにサービスベースのトラフィック処理を提供することができます。
The protection for the Service Selection Mobility Option depends on the service that is being identified and eventually selected. If the service selection information should not be revealed on the wire, Binding Updates and Binding Acknowledgements should use Encapsulating Security Payload (ESP) [9] in transport mode with a non-null encryption transform to provide message confidentiality.
サービス選択モビリティオプションの保護が識別され、最終的に選択されているサービスに依存します。サービス選択情報は、ワイヤ上で明らかにすべきではない場合は、アップデートをバインドと謝辞がnull以外の暗号化とトランスポートモードで[9]カプセル化セキュリティペイロード（ESP）を使用する必要がありバインディングメッセージの機密性を提供するために変換します。
A new Mobile IPv6 Mobility Option type has been assigned for the following new mobility option described in Section 3:
新しいモバイルIPv6モビリティオプションの種類は、第3節で説明した次の新しいモビリティ・オプションのために割り当てられています。
Service Selection Mobility Option is set to 20
サービス選択モビリティオプションが20に設定されています
A new Mobile IPv6 registration denied by home agent Status Code has been assigned. The Status Code was allocated from the range 128-255:
ホームエージェントステータスコードによって拒否された新しいモバイルIPv6の登録が割り当てられています。ステータスコードは128〜255から割り当てられました。
SERVICE_AUTHORIZATION_FAILED is set to 151
SERVICE_AUTHORIZATION_FAILEDは151に設定されています
Jouni Korhonen would like to thank the TEKES MERCoNe project for providing funding to work on this document. The authors would like to thank Jari Arkko for his thorough review.
Jouni Korhonenは、この文書で作業するために資金を提供するためのTEKES MERCoNeプロジェクトに感謝したいと思います。作者は彼の徹底的なレビューのためにヤリArkkoに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[2]ジョンソン、D.、パーキンス、C.、およびJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年6月。
[3] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[3] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[4] Davis, M. and M. Duerst, "Unicode Standard Annex #15; Unicode Normalization Forms", Unicode 5.0.0, October 2006.
[4]デイビス、M.とM. Duerstを、 "Unicode規格附属書＃15：Unicode正規化フォーム" のUnicode 5.0.0、2006年10月。
[5] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", Work in Progress, December 2007.
[5] gundavelli、S。、Leunjiは、K.、Devarapalliは、VEの。進歩、2007年12月に、Chaudhuriの、K.、aとb。パティル、 "プロキシモバイル20 6"、仕事を。
[6] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[6] Aboba、B.、Beadles、M.、Arkko、J.、およびP. Eronen、 "ネットワークアクセス識別子"、RFC 4282、2005年12月。
[7] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Mobile Node Identifier Option for Mobile IPv6 (MIPv6)", RFC 4283, November 2005.
[7]パテル、A.、レオン、K.、カリル、M.、アクタール、H.、およびK.チョードリ、 "モバイルIPv6（MIPv6の）のためのモバイルノード識別子オプション"、RFC 4283、2005年11月。
[8] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. Chowdhury, "Authentication Protocol for Mobile IPv6", RFC 4285, January 2006.
[8]パテル、A.、レオン、K.、カリル、M.、アクタール、H.、およびK.チョードリ、 "モバイルIPv6のための認証プロトコル"、RFC 4285、2006年1月。
[9] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[9]ケント、S.、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 4303、2005年12月。
[10] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture", RFC 4877, April 2007.
[10] Devarapalli、V.とF.デュポン、 "IKEv2のと改訂のIPsecアーキテクチャとのモバイルIPv6の操作"、RFC 4877、2007年4月。
Authors' Addresses
著者のアドレス
Jouni Korhonen TeliaSonera Corporation P.O. Box 970 FIN-00051 Sonera Finland
Jouni Korhonenテリアソネラ社、P。ボックス970 FIN-00051テリアソネラフィンランド
EMail: jouni.korhonen@teliasonera.com
メールアドレス：jouni.korhonen@teliasonera.com
Ulf Nilsson TeliaSonera Corporation Marbackagatan 11 S-123 86 Farsta Sweden
ウルフ・ニルソンテリアソネラ社Marbackagatan 11のS-123 86 Farsta、スウェーデン
EMail: ulf.s.nilsson@teliasonera.com
メールアドレス：ulf.s.nilsson@teliasonera.com
Vijay Devarapalli Azaire Networks 4800 Great America Pkwy Santa Clara, CA 95054 USA
ビジェイDevarapalli Azaireネットワーク4800グレートアメリカパークウェイサンタクララ、CA 95054 USA
EMail: vijay.devarapalli@azairenet.com
メールアドレス：vijay.devarapalli@azairenet.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2008).
著作権（C）IETFトラスト（2008）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。