[要約] 要約：RFC 7393は、Port Control Protocol（PCP）を使用して動的DNSを更新するための手法を提案しています。 目的：このRFCの目的は、PCPを使用してネットワークデバイスが動的DNSエントリを更新できるようにすることです。
Independent Submission X. Deng
Request for Comments: 7393
Category: Informational M. Boucadair
ISSN: 2070-1721 France Telecom
Q. Zhao
Beijing University of Posts and Telecommunications
J. Huang
C. Zhou
Huawei Technologies
November 2014
Using the Port Control Protocol (PCP) to Update Dynamic DNS
動的DNSを更新するためのポート制御プロトコル（PCP）の使用
Abstract
概要
This document focuses on the problems encountered when using dynamic DNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) and Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64)) during IPv6 transition. Both issues and possible solutions are documented in this memo.
このドキュメントでは、IPv6の移行中にアドレス共有のコンテキスト（例：Dual-Stack Lite（DS-Lite）およびIPv6クライアントからIPv4サーバー（NAT64）へのネットワークアドレスおよびプロトコル変換）で動的DNSを使用するときに発生する問題に焦点を当てています。このメモには、問題と考えられる解決策の両方が記載されています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc7393.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7393で入手できます。
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.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope and Goals . . . . . . . . . . . . . . . . . . . . . 4
2. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Locate a Service Port . . . . . . . . . . . . . . . . . . 5
2.2. Create Explicit Mappings for Incoming Connections . . . . 5
2.3. Detect Changes . . . . . . . . . . . . . . . . . . . . . 5
3. Some Deployment Solutions . . . . . . . . . . . . . . . . . . 7
3.1. Reference Topology . . . . . . . . . . . . . . . . . . . 7
3.2. For Web Service . . . . . . . . . . . . . . . . . . . . . 8
3.3. For Non-web Service . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.1. Normative References . . . . . . . . . . . . . . . . . . 12
5.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Dynamic DNS (DDNS) is a widely deployed service to facilitate hosting servers (e.g., access to a webcam, HTTP server, FTP server, etc.) at customers' premises. There are a number of providers that offer a DDNS service, working in a client and server mode, which mostly use web-form-based communication. DDNS clients are generally implemented in the user's router or computer; once changes are detected to its assigned IP address, an update message is automatically sent to the DDNS server. The communication between the DDNS client and the DDNS server is not standardized, varying from one provider to another, although a few standard web-based methods of updating have emerged over time.
ダイナミックDNS（DDNS）は、顧客の施設でホスティングサーバー（Webカメラ、HTTPサーバー、FTPサーバーなどへのアクセス）を容易にするために広く展開されているサービスです。クライアントおよびサーバーモードで動作するDDNSサービスを提供するプロバイダーは多数あります。これらのプロバイダーは、主にWebフォームベースの通信を使用します。 DDNSクライアントは通常、ユーザーのルーターまたはコンピューターに実装されます。割り当てられたIPアドレスへの変更が検出されると、更新メッセージがDDNSサーバーに自動的に送信されます。 DDNSクライアントとDDNSサーバー間の通信は標準化されておらず、プロバイダーごとに異なりますが、標準的なWebベースの更新方法がいくつか登場しました。
In address-sharing contexts, well-known port numbers (e.g., port 80) won't be available for every user [RFC6269]. As such, the DDNS client will have to register the IP address and/or the external port(s) on which the service is listening. Also, the DDNS client has to report any change of this IP address and/or the external port(s). It will also require the ability to configure corresponding port forwarding on Carrier-Grade NAT (CGN) [RFC6888] devices so that incoming communications initiated from the Internet can be routed to the appropriate server behind the CGN.
アドレス共有のコンテキストでは、既知のポート番号（ポート80など）は、すべてのユーザーが使用できるわけではありません[RFC6269]。そのため、DDNSクライアントは、サービスがリッスンしているIPアドレスや外部ポートを登録する必要があります。また、DDNSクライアントは、このIPアドレスや外部ポートの変更を報告する必要があります。また、キャリアグレードNAT（CGN）[RFC6888]デバイスで対応するポート転送を構成して、インターネットから開始された着信通信をCGNの背後にある適切なサーバーにルーティングできるようにする必要もあります。
Issues encountered in address sharing are documented in [RFC6269]. This document focuses on the problems encountered when using dynamic DNS in address-sharing contexts (e.g., DS-Lite [RFC6333] and NAT64 [RFC6146]). The main challenges are listed below:
アドレス共有で発生した問題は、[RFC6269]に文書化されています。このドキュメントでは、アドレス共有コンテキスト（DS-Lite [RFC6333]およびNAT64 [RFC6146]など）で動的DNSを使用するときに発生する問題に焦点を当てています。主な課題は次のとおりです。
Announce and discover an alternate service port: The DDNS service must be able to maintain an alternative port number instead of the default port number.
代替サービスポートのアナウンスと検出：DDNSサービスは、デフォルトのポート番号ではなく代替ポート番号を維持できる必要があります。
Allow for incoming connections: Appropriate means to instantiate port mappings in the address-sharing device must be supported.
着信接続を許可する：アドレス共有デバイスでポートマッピングをインスタンス化する適切な手段がサポートされている必要があります。
Detect changes and trigger DDNS updates: The DDNS client must be triggered by the change of the external IP address and the port number. Concretely, upon change of the external IP address (and/ or external port number), the DDNS client must refresh the DNS records; otherwise, the server won't be reachable from outside. This issue is exacerbated in the DS-Lite context because no public IPv4 address is assigned to the Customer Premises Equipment (CPE).
変更の検出とDDNS更新のトリガー：DDNSクライアントは、外部IPアドレスとポート番号の変更によってトリガーされる必要があります。具体的には、外部IPアドレス（または外部ポート番号、あるいはその両方）が変更されると、DDNSクライアントはDNSレコードを更新する必要があります。そうしないと、サーバーは外部から到達できません。この問題は、DS-Liteコンテキストでは悪化します。これは、IPv6パブリックアドレスがCustomer Premises Equipment（CPE）に割り当てられていないためです。
This document describes some candidate solutions to resolve the aforementioned issues with a particular focus on DS-Lite. These solutions may also be valid for other address-sharing schemes.
このドキュメントでは、DS-Liteに特に焦点を当てて、前述の問題を解決するためのいくつかの候補ソリューションについて説明します。これらのソリューションは、他のアドレス共有スキームにも有効です。
This document sketches deployment considerations based on the Port Control Protocol (PCP) [RFC6887]. Note that DDNS may be considered as an implementation of the rendezvous service mentioned in [RFC6887].
このドキュメントでは、ポート制御プロトコル（PCP）[RFC6887]に基づいた配備に関する考慮事項について説明します。 DDNSは、[RFC6887]で言及されているランデブーサービスの実装と見なされる場合があることに注意してください。
Indeed, after creating an explicit mapping for incoming connections using PCP, it is necessary to inform remote hosts about the IP address, protocol, and port number for the incoming connection to reach the services hosted behind a DS-Lite CGN. This is usually done in an application-specific manner. For example, a machine hosting a game server might use a rendezvous server specific to that game (or specific to that game developer), a SIP phone would use a SIP proxy, a client using DNS-Based Service Discovery [RFC6763] would use DNS Update [RFC2136][RFC3007], etc. PCP does not provide this rendezvous function.
実際、PCPを使用して着信接続の明示的なマッピングを作成した後、着信接続がDS-Lite CGNの背後でホストされているサービスに到達するためのIPアドレス、プロトコル、およびポート番号をリモートホストに通知する必要があります。これは通常、アプリケーション固有の方法で行われます。たとえば、ゲームサーバーをホストするマシンは、そのゲームに固有の（またはそのゲーム開発者に固有の）ランデブーサーバーを使用し、SIP電話はSIPプロキシを使用し、クライアントはDNSベースのサービスディスカバリ[RFC6763]を使用してDNSを使用します[RFC2136] [RFC3007]などの更新。PCPはこのランデブー機能を提供していません。
The rendezvous function may support IPv4, IPv6, or both. Depending on that support and the application's support of IPv4 or IPv6, the PCP client may need an IPv4 mapping, an IPv6 mapping, or both. An example illustrating how the DDNS server may implement such a service notification functionality if necessary is provided in Section 3.
ランデブー機能は、IPv4、IPv6、またはその両方をサポートする場合があります。そのサポートとアプリケーションのIPv4またはIPv6のサポートに応じて、PCPクライアントはIPv4マッピング、IPv6マッピング、またはその両方を必要とする場合があります。セクション3で、必要に応じてDDNSサーバーがこのようなサービス通知機能を実装する方法を示す例を示します。
This document does not specify any protocol extension but instead focuses on the elaboration of the problem space and illustrates how existing tools can be reused to solve the problem for some deployment contexts. Particularly, this document requires no changes to PCP or dynamic updates in the standard domain name system [RFC2136]; rather, it is an operational document to make the current DDNS service providers aware of the impacts and issues that IPv6 transitioning and IPv4 address sharing will bring to them, and it gives solutions to address the forthcoming issues. The current DDNS service providers usually employ a web-based form to maintain DDNS service registration and updates.
このドキュメントでは、プロトコル拡張は指定していませんが、代わりに問題空間の詳細に焦点を当てており、既存のツールを再利用して一部の展開コンテキストの問題を解決する方法を示しています。特に、このドキュメントでは、標準ドメインネームシステム[RFC2136]でのPCPの変更や動的更新は必要ありません。むしろ、現在のDDNSサービスプロバイダーにIPv6移行とIPv4アドレス共有がもたらす影響と問題を認識させるための運用ドキュメントであり、今後の問題に対処するためのソリューションを提供します。現在のDDNSサービスプロバイダーは通常、DDNSサービスの登録と更新を維持するためにWebベースのフォームを採用しています。
Generic deployment considerations for DS-Lite, including Basic Bridging BroadBand (B4) remote management and IPv4 connectivity check, can be found in [RFC6908]. This document complements [RFC6908] with deployment considerations related to rendezvous service maintenance. Additional PCP-related deployment considerations are available at [PCP-DEPLOYMENT].
基本的なブリッジングBroadBand（B4）リモート管理やIPv4接続チェックなど、DS-Liteの一般的な導入に関する考慮事項は、[RFC6908]にあります。このドキュメントは、ランデブーサービスメンテナンスに関連する展開に関する考慮事項で[RFC6908]を補足します。 PCP関連の展開に関するその他の考慮事項は、[PCP-DEPLOYMENT]で入手できます。
Solutions relying on DNS-Based Service Discovery [RFC6763] or Apple's Back to My Mac (BTMM) Service [RFC6281] are not considered in this document. Moreover, this document does not assume that DDNS service relies on [RFC2136].
このドキュメントでは、DNSベースのサービスディスカバリ[RFC6763]またはAppleのBack to My Mac（BTMM）サービス[RFC6281]に依存するソリューションは考慮されていません。さらに、このドキュメントは、DDNSサービスが[RFC2136]に依存していることを想定していません。
IPv4 addresses used in the examples are derived from the IPv4 block reserved for documentation in [RFC6890]. DNS name examples follow [RFC2606].
例で使用されているIPv4アドレスは、[RFC6890]のドキュメント用に予約されているIPv4ブロックから派生しています。 DNS名の例は[RFC2606]に従います。
As listed below, at least two solutions can be used to associate a port number with a service:
以下に示すように、少なくとも2つのソリューションを使用して、ポート番号をサービスに関連付けることができます。
1. Use service URIs (e.g., FTP, SIP, HTTP) that embed an explicit port number. Indeed, the Uniform Resource Identifier (URI) defined in [RFC3986] allows the port number to be carried in the syntax (e.g., mydomain.example:15687).
1. 明示的なポート番号を埋め込んだサービスURI（FTP、SIP、HTTPなど）を使用します。実際、[RFC3986]で定義されているURI（Uniform Resource Identifier）では、ポート番号を構文で運ぶことができます（例：mydomain.example：15687）。
2. Use SRV records [RFC2782]. Unfortunately, the majority of browsers do not support this record type.
2. SRVレコードを使用する[RFC2782]。残念ながら、ほとんどのブラウザはこのレコードタイプをサポートしていません。
The DDNS client and DDNS server are to be updated so that an alternate port number is signaled and stored by the DDNS server. Requesting remote hosts will be then notified with the IP address and port number to reach the server.
DDNSクライアントとDDNSサーバーは、代替ポート番号が通知され、DDNSサーバーによって保存されるように更新されます。要求するリモートホストには、サーバーに到達するためのIPアドレスとポート番号が通知されます。
PCP is used to install the appropriate mapping(s) in the CGN so that incoming packets can be delivered to the appropriate server.
PCPを使用して適切なマッピングをCGNにインストールし、着信パケットを適切なサーバーに配信できるようにします。
In a network as described in Figure 1, a DDNS client/PCP client can be running on either a CPE or the host that is hosting some services itself. There are several possible ways to address the problems stated in Section 1.1:
図1で説明されているネットワークでは、DDNSクライアント/ PCPクライアントは、CPEまたはいくつかのサービス自体をホストしているホストのいずれかで実行できます。セクション1.1で述べられている問題に対処するには、いくつかの可能な方法があります。
1. If the DDNS client is enabled, the host periodically issues (e.g., 60 minutes) PCP MAP requests (e.g., messages 1 and 2 in Figure 1) with short lifetimes (e.g., 30s) for the purpose of inquiring an external IP address and setting. If the purpose is to detect any change to the external port, the host must issue a PCP mapping to install for the internal server. Upon change of the external IP address, the DDNS client updates the records accordingly (e.g., message 3 in Figure 1).
1. DDNSクライアントが有効になっている場合、ホストは外部IPアドレスを照会する目的で、ライフタイムが短い（30秒など）PCP MAP要求（たとえば、図1のメッセージ1および2）を定期的に発行（60分など）します。と設定。目的が外部ポートへの変更を検出することである場合、ホストはPCPマッピングを発行して内部サーバーにインストールする必要があります。外部IPアドレスが変更されると、DDNSクライアントはそれに応じてレコードを更新します（図1のメッセージ3など）。
2. If the DDNS client is enabled, it checks the local mapping table maintained by the PCP client. This process is repeated periodically (e.g., 5 minutes, 30 minutes, 60 minutes). If there is no PCP mapping created by the PCP client, it issues a PCP MAP request (e.g., messages 1 and 2 in Figure 1) for the purpose of inquiring an external IP address and setting up port forwarding mappings for incoming connections. Upon change of the external IP address, the DDNS client updates the records in the DDNS server, e.g., message 3 in Figure 1.
2. DDNSクライアントが有効になっている場合は、PCPクライアントによって維持されているローカルマッピングテーブルをチェックします。このプロセスは定期的に繰り返されます（たとえば、5分、30分、60分）。 PCPクライアントによって作成されたPCPマッピングがない場合は、外部IPアドレスを照会し、着信接続のポート転送マッピングを設定するために、PCP MAP要求（図1のメッセージ1と2など）を発行します。外部IPアドレスが変更されると、DDNSクライアントはDDNSサーバーのレコードを更新します（図1のメッセージ3など）。
+-----------------+
| DDNS Server |
+-----------------+
^
|
|3. DDNS updates
| (if any)
|
+---------------+ +-----------------+
|DDNS Client |1. PCP MAP request | CGN/PCP Server |
|PCP Client/IWF |------------------->| (PCP mapping for|80:8080+------+
|on CPE or |2. PCP MAP response | port forwarding)|<------|Client|
|the host itself|<-------------------| | +------+
| |3. DDNS updates | |
| | (if any) | |
| |------------------->| |
+---------------+ +-----------------+
IWF = Internetworking Function
Figure 1: Flow Chart
図1：フローチャート
Figure 2 illustrates the topology used for the deployment solutions elaborated in the following subsections.
図2は、次のサブセクションで詳しく説明する展開ソリューションに使用されるトポロジを示しています。
+--------------+ +--------+ +---------+ +--------+ +-------+
| Service | | DDNS | | CGN/ | | PCP | |Servers|
| User |---| Server|----| PCP |---| Client |---| |
| | | | | Server | | /DDNS | | |
| | | | | | | Client | | |
+--------------+ +--------+ +---------+ +--------+ +-------+
A user DDNS Server AFTR B4(CPE) A host
from Internet behind B4
Figure 2: Implementation Topology
図2：実装トポロジ
Figure 2 involves the following entities:
図2には、次のエンティティが含まれます。
o Servers: Refers to the servers that are deployed in the DS-Lite network, or more generally, an IP address-sharing environment. They are usually running on a host that has been assigned with a private IPv4 address. Having created a proper mapping via PCP in the Address Family Transition Router (AFTR), these services have been made available to Internet users. The services may provide web, FTP, SIP, and other services though these may not be able to be seen as using a well-known port from the outside anymore, in the IP address-sharing context.
o サーバー：DS-Liteネットワークに展開されているサーバー、またはより一般的にはIPアドレス共有環境を指します。これらは通常、プライベートIPv4アドレスが割り当てられているホスト上で実行されています。アドレスファミリ移行ルーター（AFTR）でPCPを介して適切なマッピングを作成すると、これらのサービスはインターネットユーザーが利用できるようになります。これらのサービスは、Web、FTP、SIP、およびその他のサービスを提供する可能性がありますが、IPアドレス共有のコンテキストでは、外部からの既知のポートを使用しているとは見なされない可能性があります。
o B4(CPE): An endpoint of an IPv4-in-IPv6 tunnel [RFC6333]. A PCP client together with a DDNS client are running on it. After a PCP client establishes a mapping on the AFTR, an end user may register its domain name and its external IPv4 address plus port number to its DDNS service provider (DDNS server), manually or automatically by a DDNS client. Later, likewise, end users may manually announce or let the DDNS client automatically announce IP address and/or port changes to the DDNS server.
o B4（CPE）：IPv4-in-IPv6トンネルのエンドポイント[RFC6333]。その上で、DDNSクライアントと一緒にPCPクライアントが実行されています。 PCPクライアントがAFTRでマッピングを確立した後、エンドユーザーは、ドメイン名と外部IPv4アドレスとポート番号をDDNSクライアントによって手動または自動でDDNSサービスプロバイダー（DDNSサーバー）に登録できます。その後、同様に、エンドユーザーは手動でアナウンスするか、DDNSクライアントにIPアドレスやポートの変更をDDNSサーバーに自動的にアナウンスさせることができます。
o AFTR: Responsible for maintaining mappings between an IPv6 address, the internal IPv4 address plus internal port, and the external IPv4 address plus port [RFC6333].
o AFTR：IPv6アドレス、内部IPv4アドレス+内部ポート、および外部IPv4アドレス+ポート[RFC6333]間のマッピングを維持する責任があります。
o DDNS server: Maintains a table that associates a registered domain name and a registered host's external IPv4 address/port number pair. When being notified of IP address and port number changes from a DDNS client, the DDNS server announces the updates to DNS servers on behalf of the end user. [RFC2136] and [RFC3007] may be used by DDNS servers to send updates to DNS servers. In many current practices, a DDNS service provider usually announces its own IP address as the registered domain names of end users. When HTTP requests reach the DDNS server, they may employ URL Forwarding or HTTP 301 redirection to redirect the request to a proper registered end user by looking up the maintained link table.
o DDNSサーバー：登録済みドメイン名と登録済みホストの外部IPv4アドレス/ポート番号のペアを関連付けるテーブルを保持します。 DDNSクライアントからIPアドレスとポート番号の変更が通知されると、DDNSサーバーはエンドユーザーに代わってDNSサーバーに更新を通知します。 [RFC2136]と[RFC3007]は、DDNSサーバーがDNSサーバーに更新を送信するために使用できます。現在の多くの慣行では、DDNSサービスプロバイダーは通常、エンドユーザーの登録済みドメイン名として独自のIPアドレスをアナウンスします。 HTTP要求がDDNSサーバーに到達すると、URL転送またはHTTP 301リダイレクションを使用して、維持されているリンクテーブルを検索することにより、要求を適切に登録されたエンドユーザーにリダイレクトできます。
o Service users: Refers to users who want to access services behind an IP address-sharing network. They issue standard DNS requests to locate the services, which will lead them to a DDNS server, provided that the requested services have been registered to a DDNS service provider. The DDNS server will then handle the rest in the same way as described before.
o サービスユーザー：IPアドレス共有ネットワークの背後にあるサービスにアクセスするユーザーを指します。要求されたサービスがDDNSサービスプロバイダーに登録されている場合、サービスを見つけるために標準のDNS要求を発行し、サービスをDDNSサーバーに導きます。その後、DDNSサーバーは、前述と同じ方法で残りを処理します。
Current DDNS server implementations typically assume that the end servers host web servers on the default 80 port. In the DS-Lite context, they will have to take into account that external ports assigned by the AFTR may be any number other than 80, in order to maintain proper mapping between domain names and the external IP plus port. If a proper mapping is maintained, the HTTP request would be redirected to the AFTR, which serves the specific end host that is running the servers.
現在のDDNSサーバーの実装では、通常、エンドサーバーがデフォルトの80ポートでWebサーバーをホストしていると想定しています。 DS-Liteのコンテキストでは、ドメイン名と外部IPプラスポート間の適切なマッピングを維持するために、AFTRによって割り当てられた外部ポートが80以外であることを考慮に入れる必要があります。適切なマッピングが維持されている場合、HTTP要求はAFTRにリダイレクトされ、サーバーを実行している特定のエンドホストにサービスを提供します。
Figure 3 depicts how messages are handled in order to be delivered to the right server.
図3は、適切なサーバーに配信されるためにメッセージがどのように処理されるかを示しています。
Web Visitor DDNS Server AFTR B4(CPE) Web Server
behind B4
| HTTP GET* | | | |
|---------------------->| | | |
| ip_DDNS_server |------------->| | |
| | HTTP 301 | | |
| |<-------------| | |
| HTTP GET* ip_aftr:8001 | | |
|------------------------------------->| |
| | HTTP GET* ip_websrv:8000 |
| |------------------------->|
| | |
| HTTP response | HTTP response |
|<-------------------------------------|--------------------------|
| | |
Figure 3: HTTP Service Messages
図3：HTTPサービスメッセージ
When a web user sends out an HTTP GET message to the DDNS server after a standard DNS query, the DDNS server redirects the request to a registered web server, in this case, by responding with an HTTP 301 message. Then, the HTTP GET message will be sent out to the AFTR, which will in turn find the proper hosts behind it. For simplicity, messages among AFTR, B4, and the web server behind B4 are not shown completely; for communications among those nodes, refer to [RFC6333].
Webユーザーが標準のDNSクエリの後でHTTP GETメッセージをDDNSサーバーに送信すると、DDNSサーバーは、この場合はHTTP 301メッセージで応答することにより、登録されたWebサーバーに要求をリダイレクトします。次に、HTTP GETメッセージがAFTRに送信され、AFTRが背後にある適切なホストを検出します。簡単にするために、AFTR、B4、およびB4の背後にあるWebサーバー間のメッセージは完全には表示されていません。これらのノード間の通信については、[RFC6333]を参照してください。
For non-web services, as mentioned in Section 2, other means will be needed to inform the users about the service information.
非Webサービスの場合、セクション2で述べたように、サービス情報についてユーザーに通知する他の手段が必要になります。
[RFC6763] includes an example of a DNS-based solution that allows an application running in the end user's device to retrieve service-related information via DNS SRV/TXT records and list available services. In a scenario where such an application is not applicable, the following provides another solution for a third party, e.g., a DDNS service provider, to disclose services to Internet users.
[RFC6763]には、エンドユーザーのデバイスで実行されているアプリケーションがDNS SRV / TXTレコードを介してサービス関連情報を取得し、利用可能なサービスを一覧表示できるようにするDNSベースのソリューションの例が含まれています。このようなアプリケーションが適用できないシナリオでは、以下は、DDNSサービスプロバイダーなどのサードパーティがインターネットユーザーにサービスを開示するための別のソリューションを提供します。
A web portal can be used to list available services. A DDNS server maintains a web portal for each user's Fully Qualified Domain Name (FQDN), which provides service links to users. Figure 4 assumes "websrv.example.com" is a user's FQDN provided by a DDNS service provider.
Webポータルを使用して、利用可能なサービスを一覧表示できます。 DDNSサーバーは、各ユーザーの完全修飾ドメイン名（FQDN）のWebポータルを維持し、ユーザーにサービスリンクを提供します。図4では、「websrv.example.com」がDDNSサービスプロバイダーによって提供されるユーザーのFQDNであると想定しています。
+-------------+ +-------------+ +----------+ Internet +-------+
|DDNS Client /| |DDNS Server /| |DNS Server| |Visitor|
| Web Server | | Web Portal | | | | |
+-------------+ +-------------+ +----------+ +-------+
| register | | |
|<------------------>| | |
| websrv.example.com | update DNS | |
| 192.0.2.1:2000 | <-------------> | |
| |websrv.example.com| |
| | portal's IP | |
| +-------------+ | |
| |update portal| | |
| +-------------+ | DNS resolve for |
| | | <----------------> |
| | | websrv.example.com |
| | | get portal's IP |
| | | |
| | visit portal of websrv.example.com |
| | <-----------------------------------> |
| | | |
| visit http://192.0.2.1:2000 |
| <--------------------------------------------------------->|
| | | |
Figure 4: Update Web Portal
図4：Webポータルの更新
The DDNS client registers the server's information to the DDNS server, including the public IP address and port obtained via PCP, the user's FQDN, and other necessary information. The DDNS server also behaves as a portal server; it registers its IP address, port number, and the user's FQDN to the DNS system so that visitors can access the web portal.
DDNSクライアントは、PCPを介して取得したパブリックIPアドレスとポート、ユーザーのFQDN、およびその他の必要な情報を含む、サーバーの情報をDDNSサーバーに登録します。 DDNSサーバーはポータルサーバーとしても動作します。訪問者がWebポータルにアクセスできるように、IPアドレス、ポート番号、およびユーザーのFQDNをDNSシステムに登録します。
A DDNS server also maintains a web portal for each user's FQDN and updates the portal according to registered information from the DDNS client. When a visitor accesses "websrv.example.com", a DNS query will resolve the portal server's address and port number, and the visitor will see the portal and the available services.
DDNSサーバーは、各ユーザーのFQDNのWebポータルも維持し、DDNSクライアントからの登録情報に従ってポータルを更新します。訪問者が「websrv.example.com」にアクセスすると、DNSクエリによってポータルサーバーのアドレスとポート番号が解決され、訪問者にはポータルと利用可能なサービスが表示されます。
+-------------------------------------------------------------+
| |
| Portal: websrv.example.com |
| |
| Service1: web server |
| Link: http://192.0.2.1:2000 |
| |
| Service2: video |
| Link: rtsp://192.0.2.1:8080/test.sdp |
| |
| ...... |
| |
+-------------------------------------------------------------+
Figure 5: An Example of a Web Portal
図5：Webポータルの例
As shown in Figure 5, the web portal shows the service URLs that are available to be accessed. Multiple services are accessible per a user's FQDN.
図5に示すように、Webポータルには、アクセス可能なサービスURLが表示されます。ユーザーのFQDNごとに複数のサービスにアクセスできます。
Some applications that are not HTTP based can also be delivered using this solution. When a user clicks on a link, the registered application in the client OS will be invoked to handle the link. How this can be achieved is out of the scope of this document.
HTTPベースではない一部のアプリケーションも、このソリューションを使用して配信できます。ユーザーがリンクをクリックすると、クライアントOSに登録されているアプリケーションが呼び出されてリンクが処理されます。これを達成する方法は、このドキュメントの範囲外です。
This document does not introduce a new protocol, nor does it specify protocol extensions. Security-related considerations related to PCP [RFC6887] and DS-Lite [RFC6333] should be taken into account.
このドキュメントでは、新しいプロトコルを紹介することも、プロトコル拡張を指定することもありません。 PCP [RFC6887]およびDS-Lite [RFC6333]に関連するセキュリティ関連の考慮事項を考慮する必要があります。
The protocol between the DDNS client and DDNS server is proprietary in most cases; some extensions may be necessary, which is up to the DDNS operators. These operators should enforce security-related policies in order to keep illegitimate users from altering records installed by legitimate users or installing fake records that would attract illegitimate traffic. Means to protect the DDNS server against Denial of Service (DoS) should be enabled. Note that these considerations are not specific to address-sharing contexts but are valid for DDNS services in general.
DDNSクライアントとDDNSサーバー間のプロトコルは、ほとんどの場合独自のものです。 DDNSオペレーター次第で、いくつかの拡張が必要になる場合があります。これらの事業者は、不正なユーザーが正当なユーザーがインストールしたレコードを変更したり、不正なトラフィックを引き付ける偽のレコードをインストールしたりしないように、セキュリティ関連のポリシーを適用する必要があります。サービス拒否（DoS）からDDNSサーバーを保護する手段を有効にする必要があります。これらの考慮事項は、アドレス共有コンテキストに固有のものではありませんが、一般的にDDNSサービスに有効であることに注意してください。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月、<http：//www.rfc- editor.org/info/rfc3986>。
[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011, <http://www.rfc-editor.org/info/rfc6333>.
[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、2011年8月、<http：//www.rfc- editor.org/info/rfc6333>。
[RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>.
[RFC6887] Wing、D.、Cheshire、S.、Boucadair、M.、Penno、R。、およびP. Selkirk、「Port Control Protocol（PCP）」、RFC 6887、2013年4月、<http：// www。 rfc-editor.org/info/rfc6887>。
[PCP-DEPLOYMENT] Boucadair, M., "Port Control Protocol (PCP) Deployment Models", Work in Progress, draft-boucadair-pcp-deployment-cases-03, July 2014.
[PCP-DEPLOYMENT] Boucadair、M。、「Port Control Protocol（PCP）Deployment Models」、Work in Progress、draft-boucadair-pcp-deployment-cases-03、2014年7月。
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997, <http://www.rfc-editor.org/info/rfc2136>.
[RFC2136] Vixie、P.、Thomson、S.、Rekhter、Y。、およびJ. Bound、「Dynamic Updates in the Domain Name System（DNS UPDATE）」、RFC 2136、1997年4月、<http：// www。 rfc-editor.org/info/rfc2136>。
[RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, June 1999, <http://www.rfc-editor.org/info/rfc2606>.
[RFC2606] Eastlake、D。およびA. Panitz、「予約済みトップレベルDNS名」、BCP 32、RFC 2606、1999年6月、<http://www.rfc-editor.org/info/rfc2606>。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000, <http://www.rfc-editor.org/info/rfc2782>.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、2000年2月、<http：//www.rfc-editor .org / info / rfc2782>。
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000, <http://www.rfc-editor.org/info/rfc3007>.
[RFC3007] Wellington、B。、「Secure Domain Name System（DNS）Dynamic Update」、RFC 3007、2000年11月、<http://www.rfc-editor.org/info/rfc3007>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「ステートフルNAT64：IPv6クライアントからIPv4サーバーへのネットワークアドレスおよびプロトコル変換」、RFC 6146、2011年4月、<http：//www.rfc -editor.org/info/rfc6146>。
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011, <http://www.rfc-editor.org/info/rfc6269>.
[RFC6269]フォード、M。、ブーカデア、M。、デュランド、A。、リーバイス、P。、およびP.ロバーツ、「IPアドレス共有の問題」、RFC 6269、2011年6月、<http：//www.rfc -editor.org/info/rfc6269>。
[RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, "Understanding Apple's Back to My Mac (BTMM) Service", RFC 6281, June 2011, <http://www.rfc-editor.org/info/rfc6281>.
[RFC6281] Cheshire、S.、Zhu、Z.、Wakikawa、R.、and L. Zhang、 "Understanding Apple's Back to My Mac（BTMM）Service"、RFC 6281、June 2011、<http：//www.rfc -editor.org/info/rfc6281>。
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, February 2013, <http://www.rfc-editor.org/info/rfc6763>.
[RFC6763] Cheshire、S。およびM. Krochmal、「DNS-Based Service Discovery」、RFC 6763、2013年2月、<http://www.rfc-editor.org/info/rfc6763>。
[RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, April 2013, <http://www.rfc-editor.org/info/rfc6888>.
[RFC6888]ペロー、S、山形、I、宮川、S、中川、A、および芦田H、「キャリアグレードNAT（CGN）の共通要件」、BCP 127、RFC 6888、2013年4月、 <http://www.rfc-editor.org/info/rfc6888>。
[RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, "Special-Purpose IP Address Registries", BCP 153, RFC 6890, April 2013, <http://www.rfc-editor.org/info/rfc6890>.
[RFC6890]綿、M。、ベゴダ、L。、ボニカ、R。、およびB.ハーバーマン、「特別な目的のIPアドレスレジストリ」、BCP 153、RFC 6890、2013年4月、<http：//www.rfc- editor.org/info/rfc6890>。
[RFC6908] Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M. Boucadair, "Deployment Considerations for Dual-Stack Lite", RFC 6908, March 2013, <http://www.rfc-editor.org/info/rfc6908>.
[RFC6908] Lee、Y.、Maglione、R.、Williams、C.、Jacquenet、C。、およびM. Boucadair、「Dual-Stack Liteの導入に関する考慮事項」、RFC 6908、2013年3月、<http：// www .rfc-editor.org / info / rfc6908>。
Acknowledgements
謝辞
Thanks to Stuart Cheshire for bringing up DNS-Based Service Discovery (SD) and [RFC6281], which covers a DNS-based SD scenario and gives an example of how the application is a means for a solution to address dynamic DNS updates; in this case, Apple's BTMM can be achieved.
DNSベースのサービスディスカバリ（SD）と[RFC6281]を取り上げてくれたStuart Cheshireに感謝します。これは、DNSベースのSDシナリオをカバーし、アプリケーションが動的DNS更新に対処するソリューションの手段である方法の例を示しています。この場合、AppleのBTMMを実現できます。
Many thanks to D. Wing, D. Thaler, and J. Abley for their comments.
D. Wing、D。Thaler、J。Ableyのコメントに感謝します。
Contributors
貢献者
The following individuals contributed text to the document:
次の個人が文書にテキストを寄稿しました。
Xiaohong Huang Beijing University of Posts and Telecommunications, China EMail: huangxh@bupt.edu.cn
Xiaohong Huang北京郵電大学、中国Eメール：huangxh@bupt.edu.cn
Yan Ma Beijing University of Posts and Telecommunications, China EMail: mayan@bupt.edu.cn
Yan Ma北京郵電大学、中国Eメール：mayan@bupt.edu.cn
Authors' Addresses
著者のアドレス
Xiaohong Deng
ξAO Red Deng
EMail: dxhbupt@gmail.com
Mohamed Boucadair France Telecom Rennes 35000 France
Mohamed Boucadair France Telecom Rennes 35000 France
EMail: mohamed.boucadair@orange.com
Qin Zhao Beijing University of Posts and Telecommunications China
秦趙北京郵電大学中国
EMail: zhaoqin.bupt@gmail.com
James Huang Huawei Technologies China
James Huang hu Aテクノロジー中国
EMail: james.huang@huawei.com
Cathy Zhou Huawei Technologies China
Cathy Zhou hu Aテクノロジー中国
EMail: cathy.zhou@huawei.com