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
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
使用端口控制协议（PCP）更新动态DNS
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转换过程中，在地址共享上下文中使用动态DNS时遇到的问题（例如，双栈Lite（DS Lite）以及从IPv6客户端到IPv4服务器（NAT64）的网络地址和协议转换）。本备忘录中记录了问题和可能的解决方案。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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编辑批准发布的文件不适用于任何级别的互联网标准；见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.
版权所有（c）2014 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受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
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）是一种广泛部署的服务，用于方便在客户场所托管服务器（例如，访问网络摄像头、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]设备上配置相应的端口转发，以便从Internet发起的传入通信可以路由到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环境中，此问题会加剧，因为没有向客户场所设备（CPE）分配公共IPv4地址。
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为传入连接创建显式映射之后，有必要通知远程主机有关传入连接的IP地址、协议和端口号，以到达DS Lite CGN后面承载的服务。这通常是以特定于应用程序的方式完成的。例如，托管游戏服务器的机器可能使用特定于该游戏（或特定于该游戏开发人员）的会合服务器，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.
本文档没有指定任何协议扩展，而是侧重于问题空间的细化，并说明了如何重用现有工具来解决某些部署上下文中的问题。特别是，本文件不需要更改PCP或标准域名系统[RFC2136]中的动态更新；相反，它是一份可操作的文件，旨在使当前的DDNS服务提供商意识到IPv6转换和IPv4地址共享将给他们带来的影响和问题，并提供解决即将出现的问题的解决方案。当前的DDNS服务提供商通常采用基于web的表单来维护DDNS服务注册和更新。
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].
DS Lite的一般部署注意事项，包括基本桥接宽带（B4）远程管理和IPv4连接检查，可在[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]或苹果的“回到我的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:
如下所列，至少可以使用两种解决方案将端口号与服务关联：
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）允许在语法中携带端口号（例如mydomain。例如：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
1. 如果启用DDNS客户端，主机会定期发出（例如60分钟）生命周期短（例如30秒）的PCP映射请求（例如，图1中的消息1和2），以便查询外部IP地址和设置。如果目的是检测外部端口的任何更改，则主机必须发出
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).
要为内部服务器安装的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映射，它会发出PCP映射请求（例如，图1中的消息1和2），以查询外部IP地址并为传入连接设置端口转发映射。更改外部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) | |
| |------------------->| |
+---------------+ +-----------------+
+-----------------+
| 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
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
+--------------+ +--------+ +---------+ +--------+ +-------+
| 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]。PCP客户端和DDNS客户端在其上运行。PCP客户端在AFTR上建立映射后，最终用户可以通过DDNS客户端手动或自动向其DDNS服务提供商（DDNS服务器）注册其域名和外部IPv4地址以及端口号。稍后，同样，最终用户可以手动宣布或让DDNS客户端自动向DDNS服务器宣布IP地址和/或端口更改。
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
o DDNS服务器：维护一个表，该表将注册域名和注册主机的外部IPv4地址/端口号对关联起来。当从DDNS客户端收到IP地址和端口号更改的通知时，DDNS服务器将代表最终用户向DNS服务器宣布更新。[RFC2136]和[RFC3007]可以是
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.
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地址共享网络后面的服务的用户。他们发出标准DNS请求以定位服务，这将引导他们到DDNS服务器，前提是请求的服务已注册到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上下文中，他们必须考虑AFTR分配的外部端口可以是80以外的任何数字，以便保持域名与外部IP plus端口之间的正确映射。如果保持正确的映射，HTTP请求将重定向到AFTR，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 |
|<-------------------------------------|--------------------------|
| | |
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查询后向DDNS服务器发送HTTP GET消息时，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的解决方案示例，该解决方案允许在最终用户设备中运行的应用程序通过DNS SRV/TXT记录检索服务相关信息并列出可用服务。在这种应用程序不适用的情况下，以下为第三方（例如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 |
| <--------------------------------------------------------->|
| | | |
+-------------+ +-------------+ +----------+ 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客户端向DDNS服务器注册服务器信息，包括通过PCP获得的公共IP地址和端口、用户的FQDN以及其他必要信息。DDNS服务器还充当门户服务器；它将其IP地址、端口号和用户的FQDN注册到DNS系统，以便访问者可以访问web门户。
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 |
| |
| ...... |
| |
+-------------------------------------------------------------+
+-------------------------------------------------------------+
| |
| 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的应用程序也可以使用此解决方案交付。当用户单击链接时，将调用客户端操作系统中已注册的应用程序来处理该链接。如何实现这一点超出了本文件的范围。
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运营商。这些运营商应执行与安全相关的政策，以防止非法用户更改合法用户安装的记录或安装会吸引非法流量的虚假记录。应启用保护DDNS服务器免受拒绝服务（DoS）攻击的方法。请注意，这些注意事项并不特定于地址共享上下文，但通常适用于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，“统一资源标识符（URI）：通用语法”，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 63332011年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.，布卡达尔，M.，佩诺，R.，和P.Selkirk，“港口控制协议（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.，“端口控制协议（PCP）部署模型”，正在进行的工作，草稿-Boucadair-PCP-DEPLOYMENT-cases-032014年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，“域名系统中的动态更新（DNS更新）”，RFC 21361997年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 26061999年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 SRV）的DNS RR”，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]惠灵顿，B.，“安全域名系统（DNS）动态更新”，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 61462011年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.，和L.Zhang，“理解苹果的回到我的Mac（BTMM）服务”，RFC 62812011年6月<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.Krocmal，“基于DNS的服务发现”，RFC 67632013年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]Perreault，S.，Yamagata，I.，Miyakawa，S.，Nakagawa，A.，和H.Ashida，“载体级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]Cotton，M.，Vegoda，L.，Bonica，R.，和B.Haberman，“特殊用途IP地址注册”，BCP 153，RFC 68902013年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，“双堆栈Lite的部署注意事项”，RFC 69082013年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.
感谢Stuart Cheshire提出基于DNS的服务发现（SD）和[RFC6281]，其中涵盖了基于DNS的服务发现场景，并给出了应用程序如何作为解决方案解决动态DNS更新的方法的示例；在这种情况下，可以实现苹果的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
黄小红北京邮电大学中国电邮：huangxh@bupt.edu.cn
Yan Ma Beijing University of Posts and Telecommunications, China EMail: mayan@bupt.edu.cn
北京邮电大学，中国，电子邮件：mayan@bupt.edu.cn
Authors' Addresses
作者地址
Xiaohong Deng
家邓小虹
EMail: dxhbupt@gmail.com
EMail: dxhbupt@gmail.com
Mohamed Boucadair France Telecom Rennes 35000 France
穆罕默德·布卡达尔法国电信雷恩35000法国
EMail: mohamed.boucadair@orange.com
EMail: mohamed.boucadair@orange.com
Qin Zhao Beijing University of Posts and Telecommunications China
秦朝北京邮电大学中国
EMail: zhaoqin.bupt@gmail.com
EMail: zhaoqin.bupt@gmail.com
James Huang Huawei Technologies China
华为技术中国有限公司
EMail: james.huang@huawei.com
EMail: james.huang@huawei.com
Cathy Zhou Huawei Technologies China
华为技术中国有限公司
EMail: cathy.zhou@huawei.com
EMail: cathy.zhou@huawei.com