[要約] RFC 7286は、ALTOサーバーの発見に関する標準化された手法を提供する。その目的は、アプリケーション層のトラフィック最適化を実現するために、ALTOサーバーを効果的に見つけることである。
Internet Engineering Task Force (IETF) S. Kiesel
Request for Comments: 7286 University of Stuttgart
Category: Standards Track M. Stiemerling
ISSN: 2070-1721 NEC Europe Ltd.
N. Schwan
Thales Deutschland
M. Scharf
Alcatel-Lucent Bell Labs
H. Song
Huawei
November 2014
Application-Layer Traffic Optimization (ALTO) Server Discovery
アプリケーション層トラフィック最適化（ALTO）サーバーの検出
Abstract
概要
The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance, it needs to discover one or more ALTO servers.
アプリケーション層トラフィック最適化（ALTO）の目標は、目的のリソースを提供できる候補のセットから1つまたは複数のホストを選択する必要があるアプリケーションにガイダンスを提供することです。 ALTOは、クライアントサーバープロトコルによって実現されます。 ALTOクライアントはガイダンスを要求する前に、1つ以上のALTOサーバーを検出する必要があります。
This document specifies a procedure for resource-consumer-initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer.
このドキュメントでは、リソースコンシューマーが開始するALTOサーバーの検出手順を説明しています。これは、ALTOクライアントがリソースコンシューマーに埋め込まれている場合に使用できます。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7286.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7286で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2014 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 Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology and Requirements Language . . . . . . . . . . 3
2. ALTO Server Discovery Procedure Overview . . . . . . . . . . 3
3. ALTO Server Discovery Procedure Specification . . . . . . . . 4
3.1. Step 1: Retrieving the Domain Name . . . . . . . . . . . 5
3.1.1. Step 1, Option 1: Local Configuration . . . . . . . . 5
3.1.2. Step 1, Option 2: DHCP . . . . . . . . . . . . . . . 5
3.2. Step 2: U-NAPTR Resolution . . . . . . . . . . . . . . . 6
4. Deployment Considerations . . . . . . . . . . . . . . . . . . 7
4.1. Issues with Home Gateways . . . . . . . . . . . . . . . . 7
4.2. Issues with Multihoming, Mobility, and Changing IP
Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
6.1. Integrity of the ALTO Server's URI . . . . . . . . . . . 9
6.2. Availability of the ALTO Server Discovery Procedure . . . 11
6.3. Confidentiality of the ALTO Server's URI . . . . . . . . 11
6.4. Privacy for ALTO Clients . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 14
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource [RFC5693]. ALTO is realized by a client-server protocol; see requirement AR-1 in [RFC6708]. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide guidance to this specific client.
アプリケーション層トラフィック最適化（ALTO）の目的は、希望するリソースを提供できる候補のセットから1つまたは複数のホストを選択する必要があるアプリケーションにガイダンスを提供することです[RFC5693]。 ALTOはクライアント/サーバープロトコルによって実現されます。 [RFC6708]の要件AR-1を参照してください。 ALTOクライアントがガイダンスを要求する前に、この特定のクライアントにガイダンスを提供できる1つ以上のALTOサーバーを発見する必要があります。
This document specifies a procedure for resource-consumer-initiated ALTO server discovery, which can be used if the ALTO client is embedded in the resource consumer. In other words, this document meets requirement AR-32 in [RFC6708] while AR-33 is out of scope. A different approach, which tries to meet requirement AR-33, i.e., third-party ALTO server discovery, is addressed in [3PDISC].
このドキュメントでは、リソースコンシューマーが開始するALTOサーバーの検出手順を説明しています。これは、ALTOクライアントがリソースコンシューマーに埋め込まれている場合に使用できます。言い換えると、このドキュメントは[RFC6708]の要件AR-32を満たしていますが、AR-33は範囲外です。要件AR-33、つまりサードパーティのALTOサーバーの検出を満たそうとする別のアプローチは、[3PDISC]で対処されています。
A more detailed discussion of various options on where to place the functional entities comprising the overall ALTO architecture can be found in [ALTO-DEPLOY].
ALTOアーキテクチャ全体を構成する機能エンティティを配置する場所に関するさまざまなオプションの詳細については、[ALTO-DEPLOY]を参照してください。
The ALTO protocol specification [RFC7285] is based on HTTP and expects the discovery procedure to yield the HTTP(S) URI of an ALTO server's Information Resource Directory (IRD). Therefore, this procedure is based on a combination of the Dynamic Host Configuration Protocol (DHCP) or local configuration and URI-enabled Naming Authority Pointer (U-NAPTR) resource records in the Domain Name System (DNS), in order to deliver such URIs.
ALTOプロトコル仕様[RFC7285]はHTTPに基づいており、ディスカバリ手順がALTOサーバーの情報リソースディレクトリ（IRD）のHTTP（S）URIを生成することを期待しています。したがって、この手順は、動的ホスト構成プロトコル（DHCP）またはローカル構成と、URIを配信するためのドメインネームシステム（DNS）のURI対応ネーミングオーソリティポインター（U-NAPTR）リソースレコードの組み合わせに基づいています。 。
This document makes use of the ALTO terminology defined in [RFC5693].
このドキュメントでは、[RFC5693]で定義されているALTO用語を使用しています。
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 RFC 2119 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [RFC2119]で説明されているように解釈されます。
The ALTO protocol specification [RFC7285] expects that the ALTO discovery procedure yields the HTTP(S) URI [RFC7230] of the ALTO server's Information Resource Directory (IRD), which gives further information about the capabilities and services provided by that ALTO server.
ALTOプロトコル仕様[RFC7285]では、ALTO検出手順によって、ALTOサーバーの情報リソースディレクトリ（IRD）のHTTP（S）URI [RFC7230]が生成され、ALTOサーバーによって提供される機能とサービスに関する詳細情報が提供されることが想定されています。
On hosts with more than one interface or address family (IPv4/v6), the ALTO server discovery procedure has to be run for every interface and address family. For more details see Section 4.2.
複数のインターフェイスまたはアドレスファミリ（IPv4 / v6）を持つホストでは、すべてのインターフェイスおよびアドレスファミリに対してALTOサーバーの検出手順を実行する必要があります。詳細については、セクション4.2を参照してください。
The ALTO server discovery procedure is performed in two steps:
ALTOサーバーの検出手順は、次の2つの手順で実行されます。
1. One DNS domain name is retrieved for each combination of interface and address family, either by local configuration (e.g., manual input into a menu or configuration file) or by means of DHCP.
1. ローカル構成（たとえば、メニューまたは構成ファイルへの手動入力）またはDHCPのいずれかによって、インターフェースとアドレスファミリの組み合わせごとに1つのDNSドメイン名が取得されます。
2. These DNS domain names are used for U-NAPTR lookups yielding one or more URIs. Further DNS lookups may be necessary to determine the ALTO server's IP address(es).
2. これらのDNSドメイン名は、1つ以上のURIを生成するU-NAPTRルックアップに使用されます。 ALTOサーバーのIPアドレスを特定するには、さらにDNSルックアップが必要になる場合があります。
The primary means for retrieving the DNS domain name is DHCP. However, there may be situations where DHCP is not available or does not return a suitable value. Furthermore, there might be situations in which the user wishes to override the value that could be retrieved from DHCP. In these situations, local configuration may be used. Consequently, the algorithm first checks for a locally configured override, before it tries to retrieve a value from DHCP.
DNSドメイン名を取得する主な手段はDHCPです。ただし、DHCPを使用できない場合や、適切な値を返さない場合があります。さらに、ユーザーがDHCPから取得できる値を上書きしたい場合があります。これらの状況では、ローカル構成を使用できます。その結果、アルゴリズムはDHCPから値を取得しようとする前に、まずローカルに構成されたオーバーライドをチェックします。
Typically, but not necessarily, the DNS domain name is the domain name in which the client is located, i.e., a PTR lookup on the client's IP address (according to [RFC1035], Section 3.5 for IPv4 or [RFC3596], Section 2.5 for IPv6) would yield a similar name. However, due to the widespread use of Network Address Translation (NAT), trying to determine the DNS domain name through a PTR lookup on an interface's IP address is not recommended for resource consumer initiated ALTO server discovery (see also [RFC3424]).
通常、DNSドメイン名は、クライアントが配置されているドメイン名です。つまり、クライアントのIPアドレスでのPTRルックアップです（[RFC1035]、セクション3.5 for IPv4または[RFC3596]、セクション2.5 for IPv6）でも同様の名前になります。ただし、ネットワークアドレス変換（NAT）が広く使用されているため、インターフェイスのIPアドレスでPTRルックアップを使用してDNSドメイン名を決定することは、リソースコンシューマーが開始するALTOサーバーの検出には推奨されません（[RFC3424]も参照）。
As already outlined in Section 2, the ALTO server discovery procedure is performed for every address family on every interface the application considers for communicating with resource providers.
セクション2で既に概説したように、ALTOサーバー検出手順は、リソースプロバイダーとの通信のためにアプリケーションが検討するすべてのインターフェイス上のすべてのアドレスファミリに対して実行されます。
First, the algorithm checks for a locally configured domain name, as specified in Section 3.1.1. If no such name was configured, it tries to retrieve one from DHCP, as specified in Section 3.1.2. If still no domain name could be found, the procedure has failed and terminates with an appropriate error code.
まず、アルゴリズムは、セクション3.1.1で指定されているように、ローカルに構成されたドメイン名をチェックします。そのような名前が構成されていない場合、セクション3.1.2で指定されているように、DHCPから名前を取得しようとします。それでもドメイン名が見つからない場合、手順は失敗し、適切なエラーコードで終了します。
If one or more domain names were found, they will be used as U-NAPTR/ DDDS (URI-Enabled NAPTR/Dynamic Delegation Discovery Service) [RFC4848] application-unique strings for a DNS lookup, as specified in Section 3.2.
セクション3.2で指定されているように、1つ以上のドメイン名が見つかった場合、それらはU-NAPTR / DDDS（URI対応のNAPTR /動的委任発見サービス）[RFC4848] DNSルックアップのアプリケーション固有の文字列として使用されます。
The preferred way to acquire a domain name related to an interface's point of network attachment is the use of DHCP (see Section 3.1.2). However, in some network deployment scenarios, there is no DHCP server available. Furthermore, a user may want to use an ALTO service instance provided by an entity that is not the operator of the underlying IP network. Therefore, we allow the user to specify a DNS domain name, for example, in a configuration file option. An example domain name is:
インターフェースのネットワーク接続ポイントに関連するドメイン名を取得するための推奨される方法は、DHCPの使用です（セクション3.1.2を参照）。ただし、一部のネットワーク導入シナリオでは、使用可能なDHCPサーバーがありません。さらに、ユーザーは、基盤となるIPネットワークの運営者ではないエンティティによって提供されるALTOサービスインスタンスを使用したい場合があります。したがって、たとえば構成ファイルオプションでDNSドメイン名を指定することができます。ドメイン名の例は次のとおりです。
my-alternative-alto-provider.example.org
ｍｙーあｌてｒなちゔぇーあｌとーｐろゔぃでｒ。えぁｍｐぇ。おｒｇ
Implementations MAY give the user the opportunity (e.g., by means of configuration file options or menu items) to specify an individual domain name for every address family on every interface. Implementations SHOULD allow the user to specify a default name that is used if no more specific name has been configured.
実装は、すべてのインターフェースのすべてのアドレスファミリに個別のドメイン名を指定する機会を（たとえば、構成ファイルオプションまたはメニュー項目を使用して）ユーザーに提供する場合があります。実装では、特定の名前が構成されていない場合に使用されるデフォルト名をユーザーが指定できるようにする必要があります（SHOULD）。
Network operators may provide the domain name to be used for service discovery within an access network using DHCP.
ネットワークオペレータは、DHCPを使用してアクセスネットワーク内でサービスを検出するために使用するドメイン名を提供する場合があります。
RFC 5986 [RFC5986] defines DHCP IPv4 and IPv6 access network domain name options to identify a domain name that is suitable for service discovery within the access network. RFC 2132 [RFC2132] defines the DHCP IPv4 domain name option. While this option is less suitable, it still may be useful if the RFC 5986 option is not available.
RFC 5986 [RFC5986]は、DHCP IPv4およびIPv6アクセスネットワークドメイン名オプションを定義して、アクセスネットワーク内のサービス検出に適したドメイン名を識別します。 RFC 2132 [RFC2132]は、DHCP IPv4ドメイン名オプションを定義しています。このオプションはあまり適切ではありませんが、RFC 5986オプションが利用できない場合は、依然として役立つ場合があります。
For IPv6, the ALTO server discovery procedure MUST try to retrieve DHCP option 57 (OPTION_V6_ACCESS_DOMAIN). If no such option can be retrieved the procedure fails for this interface. For IPv4, the ALTO server discovery procedure MUST try to retrieve DHCP option 213 (OPTION_V4_ACCESS_DOMAIN). If no such option can be retrieved, the procedure SHOULD try to retrieve option 15 (Domain Name). If neither option can be retrieved, the procedure fails for this interface. If a result can be retrieved, it will be used as an input for the next step (U-NAPTR resolution). One example result could be:
IPv6の場合、ALTOサーバーの検出手順はDHCPオプション57（OPTION_V6_ACCESS_DOMAIN）の取得を試行する必要があります。そのようなオプションを取得できない場合、このインターフェースの手順は失敗します。 IPv4の場合、ALTOサーバーの検出手順はDHCPオプション213（OPTION_V4_ACCESS_DOMAIN）の取得を試行する必要があります。そのようなオプションを取得できない場合、プロシージャはオプション15（ドメイン名）の取得を試みるべきです（SHOULD）。どちらのオプションも取得できない場合、このインターフェースの手順は失敗します。結果を取得できる場合は、次のステップ（U-NAPTR解決）の入力として使用されます。結果の一例は次のとおりです。
example.net
えぁｍｐぇ。ねｔ
The first step of the ALTO server discovery procedure (see Section 3.1) retrieved one or -- in case of multiple interfaces and/ or IPv4/v6 dual-stack operation -- several domain names, which will be used as U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic Delegation Discovery Service) [RFC4848] application unique strings. An example is:
ALTOサーバー検出手順の最初のステップ（セクション3.1を参照）は、1つまたは複数のインターフェースやIPv4 / v6デュアルスタック操作の場合に、U-NAPTR / DDDSとして使用される複数のドメイン名を取得しました（URI対応のNAPTR /動的委任検出サービス）[RFC4848]アプリケーション固有の文字列。例は次のとおりです。
example.net
えぁｍｐぇ。ねｔ
In the second step, the ALTO server discovery procedure uses a U-NAPTR [RFC4848] lookup with the "ALTO" Application Service Tag and either the "http" or the "https" Application Protocol Tag to obtain one or more URIs (indicating protocol, host, and possibly path elements) for the ALTO server's Information Resource Directory. In this document, only the HTTP and HTTPS URI schemes are defined, as the ALTO protocol specification defines the access over both protocols, but no other [RFC7285]. Note that the result can be any valid HTTP(S) URI.
2番目のステップでは、ALTOサーバーの検出手順は、「ALTO」アプリケーションサービスタグと「http」または「https」アプリケーションプロトコルタグのいずれかを使用してU-NAPTR [RFC4848]ルックアップを使用し、1つ以上のURI（プロトコルを示す）を取得します。 、ホスト、場合によってはパス要素）をALTOサーバーの情報リソースディレクトリに使用します。このドキュメントでは、HTTPおよびHTTPS URIスキームのみが定義されています。これは、ALTOプロトコル仕様が両方のプロトコルを介したアクセスを定義しているためであり、他の[RFC7285]は定義していません。結果は任意の有効なHTTP（S）URIになる可能性があることに注意してください。
The following two U-NAPTR resource records can be used for mapping "example.net" to the HTTPS URIs "https://alto1.example.net/ird" and "https://alto2.example.net/ird", with the former being preferred.
次の2つのU-NAPTRリソースレコードは、「example.net」をHTTPS URI「https://alto1.example.net/ird」および「https://alto2.example.net/ird」にマッピングするために使用できます。前者が好ましい。
example.net.
えぁｍｐぇ。ねｔ。
IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://alto1.example.net/ird!" ""
IN NAPTR 100 20 "u" "ALTO:https"
"!.*!https://alto2.example.net/ird!" ""
If no ALTO-specific U-NAPTR records can be retrieved, the discovery procedure fails for this domain name (and the corresponding interface and IP protocol version). If further domain names retrieved by Step 1 are known, the discovery procedure may perform the corresponding U-NAPTR lookups immediately. However, before retrying a lookup that has failed, a client MUST wait a time period that is appropriate for the encountered error (NXDOMAIN, timeout, etc.).
ALTO固有のU-NAPTRレコードを取得できない場合、このドメイン名（および対応するインターフェイスとIPプロトコルバージョン）の検出手順は失敗します。手順1で取得したドメイン名がさらにわかっている場合は、検出手順で対応するU-NAPTRルックアップをすぐに実行できます。ただし、失敗した検索を再試行する前に、クライアントは発生したエラー（NXDOMAIN、タイムアウトなど）に適した時間待機する必要があります。
Section 3.1.2 describes the usage of a DHCP option that provides a means for the network operator of the network in which the ALTO client is located to provide a DNS domain name. However, this assumes that this particular DHCP option is correctly passed from the DHCP server to the actual host with the ALTO client, and that the particular host understands this DHCP option. This memo assumes the client to be able to understand the proposed DHCP option; otherwise, there is no further use of the DHCP option, but the client has to use the other proposed mechanisms.
セクション3.1.2では、ALTOクライアントが配置されているネットワークのネットワークオペレーターがDNSドメイン名を提供する手段を提供するDHCPオプションの使用法について説明します。ただし、これは、この特定のDHCPオプションがDHCPサーバーからALTOクライアントを使用して実際のホストに正しく渡され、特定のホストがこのDHCPオプションを理解していることを前提としています。このメモは、クライアントが提案されたDHCPオプションを理解できることを前提としています。それ以外の場合、DHCPオプションはそれ以上使用されませんが、クライアントは提案されている他のメカニズムを使用する必要があります。
There are well-known issues with the handling of DHCP options in home gateways. One issue is that unknown DHCP options are not passed through some home gateways, effectively eliminating the DHCP option.
ホームゲートウェイでのDHCPオプションの処理には、よく知られている問題があります。 1つの問題は、不明なDHCPオプションが一部のホームゲートウェイを通過せず、DHCPオプションが効果的に排除されることです。
Another well-known issue is the use of home-gateway-specific DNS domain names that "override" the DNS domain name provided by the network operator. For instance, a host behind a home gateway may receive a DNS domain name ".local" instead of "example.net". In general, this domain name is not usable for the server discovery procedure, unless a DNS server in the home gateway resolves the corresponding NAPTR lookup correctly, e.g., by means of a DNS split horizon approach.
もう1つのよく知られている問題は、ネットワークオペレーターによって提供されたDNSドメイン名を「上書き」する、ホームゲートウェイ固有のDNSドメイン名の使用です。たとえば、ホームゲートウェイの背後にあるホストは、「example.net」ではなく「.local」というDNSドメイン名を受け取ることがあります。一般に、このドメイン名は、たとえばDNSスプリットホライズンアプローチなどを使用して、ホームゲートウェイのDNSサーバーが対応するNAPTRルックアップを正しく解決しない限り、サーバー検出手順に使用できません。
If the user decides to enter only one (default) DNS domain name in the local configuration facility (see Section 3.1.1), only one set of ALTO servers will be discovered, irrespective of multihoming and mobility. Particularly in mobile scenarios, this can lead to undesirable results.
ユーザーがローカル構成機能（セクション3.1.1を参照）に1つ（デフォルト）のDNSドメイン名のみを入力する場合、マルチホーミングとモビリティーに関係なく、ALTOサーバーの1つのセットのみが検出されます。特にモバイルシナリオでは、これは望ましくない結果につながる可能性があります。
The DHCP-based discovery method can discover different sets of ALTO servers for each interface and address family (i.e., IPv4/v6). In general, if a client wishes to communicate using one of its interfaces and using a specific IP address family, it SHOULD query the ALTO server or servers that have been discovered for this specific interface and address family. How to select an interface and IP address family as well as how to compare results returned from different ALTO servers are out of the scope of this document.
DHCPベースのディスカバリー方式では、インターフェースおよびアドレス・ファミリー（IPv4 / v6など）ごとに、ALTOサーバーの異なるセットをディスカバーできます。一般に、クライアントがそのインターフェイスの1つと特定のIPアドレスファミリを使用して通信する場合、この特定のインターフェイスとアドレスファミリに対して検出されたALTOサーバーにクエリを実行する必要があります。インターフェイスとIPアドレスファミリを選択する方法、および異なるALTOサーバーから返された結果を比較する方法は、このドキュメントの範囲外です。
A change of the IP address at an interface invalidates the result of the ALTO server discovery procedure. For instance, if the IP address assigned to a mobile host changes due to host mobility, it is required to re-run the ALTO server discovery procedure without relying on earlier gained information.
インターフェイスでIPアドレスを変更すると、ALTOサーバーの検出手順の結果が無効になります。たとえば、モバイルホストに割り当てられたIPアドレスがホストモビリティのために変更された場合、以前に取得した情報に依存せずに、ALTOサーバーの検出手順を再実行する必要があります。
There are several challenges with DNS on hosts with multiple interfaces [RFC6418], which can affect the ALTO server discovery. If the DNS resolution is performed on the wrong interface, it can return an ALTO server that could provide suboptimal or wrong guidance. Finding the best ALTO server for multi-interfaced hosts is outside the scope of this document.
複数のインターフェースを持つホスト[RFC6418]のDNSにはいくつかの課題があり、ALTOサーバーの検出に影響を与える可能性があります。 DNS解決が間違ったインターフェイスで実行された場合、最適ではない、または誤ったガイダンスを提供する可能性のあるALTOサーバーを返す可能性があります。マルチインターフェースホストに最適なALTOサーバーを見つけることは、このドキュメントの範囲外です。
When using Virtual Private Network (VPN) connections, there is usually no DHCP. The user has to enter the DNS domain name in the local configuration facility. For good optimization results, a DNS domain name corresponding to the VPN concentrator, not corresponding to the user's current location, has to be entered. Similar considerations apply for Mobile IP.
仮想プライベートネットワーク（VPN）接続を使用する場合、通常DHCPはありません。ユーザーは、ローカル構成機能でDNSドメイン名を入力する必要があります。適切な最適化結果を得るには、VPNコンセントレータに対応し、ユーザーの現在の場所に対応していないDNSドメイン名を入力する必要があります。同様の考慮事項がモバイルIPにも適用されます。
IANA has registered the following U-NAPTR [RFC4848] application service tag for ALTO:
IANAは、ALTOの次のU-NAPTR [RFC4848]アプリケーションサービスタグを登録しました。
Application Service Tag: ALTO
アプリケーションサービスタグ：ALTO
Intended usage: see [RFC5693] or: "The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource."
使用目的：[RFC5693]または「アプリケーションレイヤートラフィック最適化（ALTO）の目的は、目的のリソースを提供できる候補のセットから1つまたは複数のホストを選択する必要があるアプリケーションにガイダンスを提供することです。」
Defining Publication: The specification contained within this document
出版物の定義：このドキュメントに含まれる仕様
Contact information: The authors of this document
連絡先情報：このドキュメントの作成者
Author/Change controller: The IESG
作成者/変更コントローラ：IESG
Interoperability considerations: No interoperability issues are known or expected. This tag is to be registered specifically for ALTO, which is a new application without any legacy deployments.
相互運用性に関する考慮事項：相互運用性に関する問題は既知ではありません。このタグは、ALTO専用に登録されます。これは、レガシーデプロイメントのない新しいアプリケーションです。
Security considerations: see Section 6 of this document.
セキュリティに関する考慮事項：このドキュメントのセクション6を参照してください。
Related publications: This document specifies a procedure for discovering an HTTP or HTTPS URI of an ALTO server. HTTP and HTTPS are specified in [RFC7230]. The HTTP(S)-based ALTO protocol is specified in [RFC7285].
関連資料：このドキュメントでは、ALTOサーバーのHTTPまたはHTTPS URIを検出する手順について説明します。 HTTPとHTTPSは[RFC7230]で指定されています。 HTTP（S）ベースのALTOプロトコルは、[RFC7285]で指定されています。
Application Protocol Tag: This document specifies how to use the application service tag "ALTO" with the application protocol tags "http" and "https", which have already been registered in the relevant IANA registry. Therefore, IANA is not requested by this document to register any new application protocol tag.
アプリケーションプロトコルタグ：このドキュメントでは、アプリケーションサービスタグ「ALTO」を、関連するIANAレジストリに既に登録されているアプリケーションプロトコルタグ「http」と「https」で使用する方法を指定します。したがって、このドキュメントでは、IANAは新しいアプリケーションプロトコルタグの登録を要求されていません。
A high-level discussion of security issues related to ALTO is part of the ALTO problem statement [RFC5693]. A classification of unwanted information disclosure risks, as well as specific security-related requirements can be found in the ALTO requirements document [RFC6708].
ALTOに関連するセキュリティ問題の高レベルの議論は、ALTO問題ステートメント[RFC5693]の一部です。不要な情報開示リスクの分類、および特定のセキュリティ関連の要件は、ALTO要件ドキュメント[RFC6708]に記載されています。
The remainder of this section focuses on security threats and protection mechanisms for the ALTO server discovery procedure as such. Once the ALTO server's URI has been discovered and the communication between the ALTO client and the ALTO server starts, the security threats and protection mechanisms discussed in the ALTO protocol specification [RFC7285] apply.
このセクションの残りの部分では、ALTOサーバーの検出手順自体のセキュリティの脅威と保護メカニズムに焦点を当てています。 ALTOサーバーのURIが検出され、ALTOクライアントとALTOサーバー間の通信が開始されると、ALTOプロトコル仕様[RFC7285]で説明されているセキュリティの脅威と保護メカニズムが適用されます。
Scenario Description An attacker could compromise the ALTO server discovery procedure or infrastructure in a way that ALTO clients would discover a "wrong" ALTO server URI.
シナリオの説明攻撃者は、ALTOクライアントが「間違った」ALTOサーバーURIを発見する方法で、ALTOサーバーの発見手順またはインフラストラクチャを危険にさらす可能性があります。
Threat Discussion This is probably the most serious security concern related to ALTO server discovery. The discovered "wrong" ALTO server might not be able to give guidance to a given ALTO client at all, or it might give suboptimal or forged information. In the latter case, an attacker could try to use ALTO to affect the traffic distribution in the network or the performance of applications (see also Section 15.1. of [RFC7285]). Furthermore, a hostile ALTO server could threaten user privacy (see also Section 5.2.1, case (5a) in [RFC6708]).
脅威のディスカッションこれはおそらく、ALTOサーバーの検出に関連する最も深刻なセキュリティ問題です。検出された「間違った」ALTOサーバーは、特定のALTOクライアントにまったくガイダンスを提供できないか、最適ではない情報または偽造された情報を提供する可能性があります。後者の場合、攻撃者はALTOを使用してネットワーク内のトラフィック分散やアプリケーションのパフォーマンスに影響を与える可能性があります（[RFC7285]のセクション15.1も参照）。さらに、敵対的なALTOサーバーはユーザーのプライバシーを脅かす可能性があります（セクション5.2.1、[RFC6708]のケース（5a）も参照）。
However, it should also be noted that, if an attacker was able to compromise DHCP and/or DNS servers used for ALTO server discovery (see below), (s)he could also launch significantly more serious other attacks (e.g., redirecting various application protocols).
ただし、攻撃者がALTOサーバーの発見に使用されるDHCPサーバーやDNSサーバーを侵害できた場合（以下を参照）、（s）他の攻撃を起動することもできます（たとえば、さまざまなアプリケーションのリダイレクトなど）プロトコル）。
Protection Strategies and Mechanisms The ALTO server discovery procedure consists of three building blocks (local configuration, DHCP, and DNS) and each of them is a possible attack vector.
保護戦略とメカニズムALTOサーバーの検出手順は、3つのビルディングブロック（ローカル構成、DHCP、DNS）で構成されており、それぞれが攻撃の可能性があります。
The problem of users possibly following "bad advice" that tricks them into manually configuring unsuitable ALTO servers cannot be solved by technical means and is out of the scope of this document.
ユーザーをだまして不適切なALTOサーバーを手動で構成するように仕向ける「悪いアドバイス」に従う可能性のあるユーザーの問題は、技術的な手段では解決できず、このドキュメントの範囲外です。
Due to the nature of the protocol, DHCP is rather prone to attacks. As already mentioned, an attacker that is able to inject forged DHCP replies into the network may do significantly more harm than only configuring a wrong ALTO server. Best current practices for safely operating DHCP should be followed.
プロトコルの性質上、DHCPは攻撃を受けやすい傾向があります。すでに述べたように、偽のDHCP応答をネットワークに挿入できる攻撃者は、間違ったALTOサーバーを構成するだけの場合よりもはるかに大きな害を与える可能性があります。 DHCPを安全に運用するための現在のベストプラクティスに従う必要があります。
A further threat is the possible alteration of the DNS records used in U-NAPTR resolution. If an attacker was able to modify or spoof any of the DNS records used in the DDDS resolution, this URI could be replaced by a forged URI. The application of DNS security (DNSSEC) [RFC4033] provides a means to limit attacks that rely on modification of the DNS records used in U-NAPTR resolution. Security considerations specific to U-NAPTR are described in more detail in [RFC4848].
さらなる脅威は、U-NAPTR解決で使用されるDNSレコードの変更の可能性です。攻撃者がDDDS解決で使用されたDNSレコードのいずれかを変更またはスプーフィングできた場合、このURIは偽造されたURIに置き換えられる可能性があります。 DNSセキュリティ（DNSSEC）[RFC4033]のアプリケーションは、U-NAPTR解決で使用されるDNSレコードの変更に依存する攻撃を制限する手段を提供します。 U-NAPTRに固有のセキュリティの考慮事項は、[RFC4848]でより詳細に説明されています。
A related risk is the impersonation of the ALTO server (i.e., attacks after the correct URI has been discovered). This threat and protection strategies are discussed in Section 15.1 of [RFC7285]. Note that if Transport Layer Security (TLS) is used to protect ALTO, the server certificate will contain the host name (CN). Consequently, only the host part of the HTTPS URI will be authenticated, i.e., the result of the ALTO server discovery procedure. The U-NAPTR based mapping within the ALTO server discovery procedure needs to be secured as described above, e.g., by using DNSSEC.
関連するリスクは、ALTOサーバーの偽装（つまり、正しいURIが発見された後の攻撃）です。この脅威と保護戦略については、[RFC7285]のセクション15.1で説明されています。トランスポート層セキュリティ（TLS）を使用してALTOを保護する場合、サーバー証明書にはホスト名（CN）が含まれることに注意してください。その結果、HTTPS URIのホスト部分のみ、つまりALTOサーバーの検出手順の結果が認証されます。 ALTOサーバー検出手順内のU-NAPTRベースのマッピングは、DNSSECを使用するなど、上記のように保護する必要があります。
In addition to active protection mechanisms, users and network operators can monitor application performance and network traffic patterns for poor performance or abnormalities. If it turns out that relying on the guidance of a specific ALTO server does not result in better-than-random outcomes, the use of the ALTO server may be discontinued (see also Section 15.2 of [RFC7285]).
アクティブな保護メカニズムに加えて、ユーザーとネットワークオペレーターは、パフォーマンスの低下や異常がないか、アプリケーションのパフォーマンスとネットワークトラフィックのパターンを監視できます。特定のALTOサーバーのガイダンスに依存しても結果がランダムではないことが判明した場合、ALTOサーバーの使用が中止される可能性があります（[RFC7285]のセクション15.2も参照）。
Scenario Description An attacker could compromise the ALTO server discovery procedure or infrastructure in a way that ALTO clients would not be able to discover any ALTO server.
シナリオの説明攻撃者は、ALTOクライアントがALTOサーバーを発見できないように、ALTOサーバーの発見手順またはインフラストラクチャを危険にさらす可能性があります。
Threat Discussion If no ALTO server can be discovered (although a suitable one exists), applications have to make their decisions without ALTO guidance. As ALTO could be temporarily unavailable for many reasons, applications must be prepared to do so. However, the resulting application performance and traffic distribution will correspond to a deployment scenario without ALTO.
脅威に関するディスカッションALTOサーバーが見つからない場合（適切なサーバーが存在する場合）、アプリケーションはALTOガイダンスなしで決定を行う必要があります。 ALTOは多くの理由で一時的に利用できなくなる可能性があるため、アプリケーションはそのための準備をする必要があります。ただし、結果として得られるアプリケーションのパフォーマンスとトラフィックの分散は、ALTOを使用しない展開シナリオに対応します。
Protection Strategies and Mechanisms Operators should follow best current practices to secure their DHCP, DNS, and ALTO (see Section 15.5 of [RFC7285]) servers against Denial-of-Service (DoS) attacks.
保護戦略とメカニズムオペレーターは、サービス拒否（DoS）攻撃からDHCP、DNS、およびALTO（[RFC7285]のセクション15.5を参照）サーバーを保護するために、現在のベストプラクティスに従う必要があります。
Scenario Description An unauthorized party could invoke the ALTO server discovery procedure, or intercept discovery messages between an authorized ALTO client and the DHCP and DNS servers, in order to acquire knowledge of the ALTO server's URI.
シナリオの説明無許可のパーティは、ALTOサーバーのURIの情報を取得するために、ALTOサーバーの検出手順を呼び出したり、許可されたALTOクライアントとDHCPサーバーおよびDNSサーバーの間の検出メッセージを傍受したりできます。
Threat Discussion
脅威の議論
In the ALTO use cases that have been described in the ALTO problem statement [RFC5693] and/or discussed in the ALTO working group, the ALTO server's URI as such has always been considered as public information that does not need protection of confidentiality.
ALTO問題ステートメント[RFC5693]で説明されている、またはALTOワーキンググループで議論されているALTOユースケースでは、ALTOサーバーのURIは常に、機密性の保護を必要としない公開情報と見なされてきました。
Protection Strategies and Mechanisms No protection mechanisms for this scenario have been provided, as it has not been identified as a relevant threat. However, if a new use case is identified that requires this kind of protection, the suitability of this ALTO server discovery procedure as well as possible security extensions have to be re-evaluated thoroughly.
保護戦略とメカニズムこのシナリオは、関連する脅威として識別されていないため、提供されていません。ただし、この種の保護を必要とする新しいユースケースが特定された場合は、このALTOサーバーの検出手順の適合性と可能なセキュリティ拡張機能を徹底的に再評価する必要があります。
Scenario Description An unauthorized party could intercept discovery messages between an ALTO client and the DHCP and DNS servers, and thereby find out the fact that said ALTO client uses (or at least tries to use) the ALTO service.
シナリオの説明権限のない者がALTOクライアントとDHCPおよびDNSサーバーの間の検出メッセージを傍受し、それにより、ALTOクライアントがALTOサービスを使用する（または少なくとも使用しようとする）事実を発見する可能性があります。
Threat Discussion In the ALTO use cases that have been described in the ALTO problem statement [RFC5693] and/or discussed in the ALTO working group, this scenario has not been identified as a relevant threat.
脅威の議論ALTO問題ステートメント[RFC5693]で説明されているか、ALTOワーキンググループで議論されているALTOの使用例では、このシナリオは関連する脅威として識別されていません。
Protection Strategies and Mechanisms No protection mechanisms for this scenario have been provided, as it has not been identified as a relevant threat. However, if a new use case is identified that requires this kind of protection, the suitability of this ALTO server discovery procedure as well as possible security extensions have to be re-evaluated thoroughly.
保護戦略とメカニズムこのシナリオは、関連する脅威として識別されていないため、提供されていません。ただし、この種の保護を必要とする新しいユースケースが特定された場合は、このALTOサーバーの検出手順の適合性と可能なセキュリティ拡張機能を徹底的に再評価する必要があります。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor Extensions", RFC 2132, March 1997, <http://www.rfc-editor.org/info/rfc2132>.
[RFC2132] Alexander、S。およびR. Droms、「DHCPオプションとBOOTPベンダー拡張」、RFC 2132、1997年3月、<http://www.rfc-editor.org/info/rfc2132>。
[RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007, <http://www.rfc-editor.org/info/rfc4848>.
[RFC4848] Daigle、L。、「URIおよび動的委任検出サービス（DDDS）を使用したドメインベースのアプリケーションサービスの場所」、RFC 4848、2007年4月、<http://www.rfc-editor.org/info/rfc4848 >。
[RFC5986] Thomson, M. and J. Winterbottom, "Discovering the Local Location Information Server (LIS)", RFC 5986, September 2010, <http://www.rfc-editor.org/info/rfc5986>.
[RFC5986] Thomson、M.およびJ. Winterbottom、「Discovering the Local Location Information Server（LIS）」、RFC 5986、2010年9月、<http://www.rfc-editor.org/info/rfc5986>。
[RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, September 2014, <http://www.rfc-editor.org/info/rfc7285>.
[RFC7285] Alimi、R.、Penno、R.、Yang、Y.、Kiesel、S.、Previdi、S.、Roome、W.、Shalunov、S。、およびR. Woundy、「アプリケーション層トラフィックの最適化（ ALTO）プロトコル」、RFC 7285、2014年9月、<http://www.rfc-editor.org/info/rfc7285>。
[3PDISC] Kiesel, S., Krause, K., and M. Stiemerling, "Third-Party ALTO Server Discovery (3pdisc)", Work in Progress, draft-kist-alto-3pdisc-05, January 2014.
[3PDISC]キーゼル、S。、クラウス、K。、およびM.スティーマーリング、「サードパーティのALTOサーバーの検出（3pdisc）」、作業中、draft-kist-alto-3pdisc-05、2014年1月。
[ALTO-DEPLOY] Stiemerling, M., Kiesel, S., Previdi, S., and M. Scharf, "ALTO Deployment Considerations", Work in Progress, draft-ietf-alto-deployments-10, July 2014.
[ALTO-DEPLOY] Stiemerling、M.、Kiesel、S.、Previdi、S。、およびM. Scharf、「ALTO導入に関する考慮事項」、Work in Progress、draft-ietf-alto-deployments-10、2014年7月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P。、「ドメイン名-実装および仕様」、STD 13、RFC 1035、1987年11月、<http://www.rfc-editor.org/info/rfc1035>。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002, <http://www.rfc-editor.org/info/rfc3424>.
[RFC3424] Daigle、L。およびIAB、「ネットワークアドレス変換を介したUNilateral Self-Address Fixing（UNSAF）に関するIABの考慮事項」、RFC 3424、2002年11月、<http://www.rfc-editor.org/info/rfc3424 >。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003, <http://www.rfc-editor.org/info/rfc3596>.
[RFC3596] Thomson、S.、Huitema、C.、Ksinant、V。、およびM. Souissi、「DNS Extensions to Support IP Version 6」、RFC 3596、2003年10月、<http：//www.rfc-editor。 org / info / rfc3596>。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005, <http://www.rfc-editor.org/info/rfc4033>.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、2005年3月、<http：//www.rfc -editor.org/info/rfc4033>。
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, October 2009, <http://www.rfc-editor.org/info/rfc5693>.
[RFC5693] Seedorf、J。およびE. Burger、「Application-Layer Traffic Optimization（ALTO）Problem Statement」、RFC 5693、2009年10月、<http://www.rfc-editor.org/info/rfc5693>。
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and Provisioning Domains Problem Statement", RFC 6418, November 2011, <http://www.rfc-editor.org/info/rfc6418>.
[RFC6418] Blanchet、M。およびP. Seite、「Multiple Interfaces and Provisioning Domains Problem Statement」、RFC 6418、2011年11月、<http://www.rfc-editor.org/info/rfc6418>。
[RFC6708] Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", RFC 6708, September 2012, <http://www.rfc-editor.org/info/rfc6708>.
[RFC6708]キーゼル、S。、プレビディ、S。、スティームリング、M。、ウウンディ、R。、およびY.ヤン、「アプリケーション層トラフィック最適化（ALTO）要件」、RFC 6708、2012年9月、<http：/ /www.rfc-editor.org/info/rfc6708>。
[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230] Fielding、R。およびJ. Reschke、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、2014年6月、<http://www.rfc-editor.org/info/rfc7230 >。
Acknowledgments
謝辞
Olafur Gudmundsson provided an excellent DNS expert review on an earlier version of this document. Thanks to Tina Tsou for an accurate security review.
Olafur Gudmundssonは、このドキュメントの以前のバージョンに関する優れたDNSエキスパートレビューを提供しました。正確なセキュリティレビューを提供してくれたTina Tsouに感謝します。
Michael Scharf is supported by the German-Lab project <http://www.german-lab.de> funded by the German Federal Ministry of Education and Research (BMBF).
Michael Scharfは、ドイツ連邦教育研究省（BMBF）が資金提供するGerman-Labプロジェクト<http://www.german-lab.de>によってサポートされています。
Martin Stiemerling is partially supported by the CHANGE project <http://www.change-project.eu>, a research project supported by the European Commission under its 7th Framework Program (contract no. 257422). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the CHANGE project or the European Commission.
Martin Stiemerlingは、第7回フレームワークプログラム（契約番号257422）に基づいて欧州委員会が支援する研究プロジェクトであるCHANGEプロジェクト<http://www.change-project.eu>によって部分的に支援されています。ここに含まれている見解と結論は著者の見解と結論であり、必ずしもCHANGEプロジェクトまたは欧州委員会の公式のポリシーまたは承認を、明示または暗示を問わず表すものとして解釈されるべきではありません。
Contributors
貢献者
The initial version of this document was coauthored by Marco Tomsu.
このドキュメントの最初のバージョンは、Marco Tomsuによって共同執筆されました。
Hannes Tschofenig provided the initial input to the U-NAPTR solution part. Hannes and Martin Thomson provided excellent feedback and input to the server discovery.
Hannes Tschofenigは、U-NAPTRソリューションパーツへの初期入力を提供しました。 HannesとMartin Thomsonは、サーバーの発見に優れたフィードバックと入力を提供しました。
The authors would also like to thank the following persons for their contribution to this document or its predecessors: Richard Alimi, David Bryan, Roni Even, Gustavo Garcia, Jay Gu, Xingfeng Jiang, Enrico Marocco, Victor Pascual, Y. Richard Yang, Yu-Shun Wang, Yunfei Zhang, Ning Zong.
著者はまた、このドキュメントまたはその前身への貢献に対して次の人々に感謝したいと思います。 -Shun Wang、Yunfei Zhang、Ning Zong。
Authors' Addresses
著者のアドレス
Sebastian Kiesel University of Stuttgart Information Center Networks and Communication Systems Department Allmandring 30 Stuttgart 70550 Germany
セバスチャンキーゼルシュトゥットガルト大学情報センターネットワークおよび通信システム学科Allmandring 30シュトゥットガルト70550ドイツ
EMail: ietf-alto@skiesel.de
URI: http://www.rus.uni-stuttgart.de/nks/
Martin Stiemerling NEC Laboratories Europe Kurfuerstenanlage 36 Heidelberg 69115 Germany
Martin Stiemerling NEC Laboratories Europe Kurfuerstenanlage 36 Heidelberg 69115 Germany
Phone: +49 6221 4342 113
EMail: mls.ietf@gmail.com
URI: http://ietf.stiemerling.org
Nico Schwan Thales Deutschland Thalesplatz 1 Ditzingen 71254 Germany
Nico Schwan ThalesドイツThalesplatz 1ディッツィンゲン71254ドイツ
EMail: ietf@nico-schwan.de
Michael Scharf Alcatel-Lucent Bell Labs Lorenzstrasse 10 Stuttgart 70435 Germany
Michael Scharf Alcatel-Lucent Bell Labs Lorenzstrasse 10シュトゥットガルト70435ドイツ
EMail: michael.scharf@alcatel-lucent.com
Haibin Song Huawei
H AI bin Songhuaは
EMail: haibin.song@huawei.com