One document matched: draft-deng-pcp-ddns-06.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-deng-pcp-ddns-06" ipr="trust200902">
<front>
<title abbrev="PCP DDNS updates">Using Port Control Protocol (PCP) to
update dynamic DNS</title>
<author fullname="Xiaohong Deng" initials="X." surname="Deng">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<email>dxhbupt@gmail.com</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange.com</email>
</address>
</author>
<author fullname="Qin Zhao" initials="Q." surname="Zhao">
<organization>Beijing University of Posts and
Telecommunications</organization>
<address>
<postal>
<street></street>
<country>China</country>
</postal>
<email>zhaoqin.bupt@gmail.com</email>
</address>
</author>
<author fullname="James Huang" initials="J." surname="Huang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<region></region>
<country>China</country>
</postal>
<phone></phone>
<email>james.huang@huawei.com</email>
</address>
</author>
<author fullname="Cathy Zhou" initials="C." surname="Zhou">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street></street>
<country>China</country>
</postal>
<email>cathy.zhou@huawei.com</email>
</address>
</author>
<date day="11" month="June" year="2014" />
<abstract>
<t>This document focuses on the problems encountered when using dynamic
DNS in address sharing contexts (e.g., DS-Lite, NAT64) during IPv6
transition. Both issues and possible solutions are documented in this
memo.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t></t>
<section anchor="ps" title="Problem Statement">
<t>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 which
offer a DDNS service, working in a client and server mode, which
mostly use a web-form based communication. DDNS clients are generally
implemented in the user's router or computer, which once detects
changes to its assigned IP address it automatically sends an update
message 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 emerged
over time.</t>
<t>When the network architecture evolves towards an IPv4 sharing
architecture during IPv6 transition, the DDNS client will have to not
only inform the IP address updates if any, but also to notify the
changes of external port on which the service is listening, because
well known port numbers, e.g., port 80 will no longer be available to
every web server. It will also require the ability to configure
corresponding port forwarding on CGN (Carrier Grade NAT, <xref
target="RFC6888"></xref>) devices, so that incoming communications
initiated from Internet can be routed to the appropriate server behind
the CGN.</t>
<t>Issues encountered in address sharing are documented in <xref
target="RFC6269"></xref>. This document focuses on the problems
encountered when using dynamic DNS in address sharing contexts (e.g.,
DS-Lite <xref target="RFC6333"></xref>, NAT64 <xref
target="RFC6146"></xref>). Below are listed the main challenges:<list
counter="20" style="hanging">
<t hangText="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.</t>
<t hangText="Allow for incoming connections:">Appropriate means to
instantiate port mappings in the address sharing device must be
supported.</t>
<t hangText="Detect changes and trigger DDNS updates:">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 CPE.</t>
</list></t>
<t></t>
</section>
<section title="Scope and Goals">
<t>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.</t>
<t>This document sketches deployment considerations based on the PCP
(Port Control Protocol, <xref target="RFC6887"></xref>). Note DDNS may
be considered as an implementation of the Rendezvous service mentioned
in <xref target="RFC6887"></xref>.</t>
<t>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,
and a client using DNS-Based Service Discovery <xref
target="RFC6763"></xref> would use DNS Update <xref
target="RFC2136"></xref><xref target="RFC3007"></xref>, etc. PCP does
not provide this rendezvous function.</t>
<t>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 <xref
target="cs"></xref>.</t>
<t>This document does not specify any protocol extension, but instead
it focuses on the elaboration of the problem space and illustrate how
existing tools can be re-used 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 <xref
target="RFC2136"></xref>, but is rather an operational document to
make the current DDNS service providers be aware of the impacts and
issues that the IPv6 transitioning and IPv4 address sharing will bring
to them, and gives solutions address the forthcoming issues. The
current DDNS service providers usually employs a web-based form to
maintain DDNS service registration and updates.</t>
<t>Generic deployment considerations for DS-Lite, including B4 remote
management and IPv4 connectivity check, can be found in <xref
target="RFC6908"></xref>. This document complements <xref
target="RFC6908"></xref> with deployment considerations related to
Rendezvous service maintenance. Additional PCP-related deployment
considerations are available at <xref
target="I-D.boucadair-pcp-deployment-cases"></xref>.</t>
<t>Solutions relying on DNS-based Service Discovery <xref
target="RFC6763"></xref> or Apple's Back to My Mac (BTMM) Service
<xref target="RFC6281"></xref> are not considered in this document.
Moreover, this document does not assume that DDNS service relies on
<xref target="RFC2136"></xref>.</t>
<t>IPv4 addresses used in the examples are derived from the IPv4 block
reserved for documentation in <xref target="RFC6890"></xref>. DNS name
examples follow <xref target="RFC2606"></xref>.</t>
</section>
</section>
<section anchor="sol" title="Solution Space">
<t></t>
<section title="Locate a Service Port">
<t>As listed below, at least two solutions can be used to associate a
port number with a service: <list style="numbers">
<t>Use service URIs (e.g., FTP, SIP, HTTP) which embed an explicit
port number. Indeed, Uniform Resource Identifier (URI) defined in
<xref target="RFC3986"></xref> allows to carry port number in the
syntax (e.g., mydomain.example:15687).</t>
<t>Use SRV records <xref target="RFC2782"></xref>. Unfortunately,
the majority of browsers do not support this record type.</t>
</list></t>
<t>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.</t>
</section>
<section title="Create Explicit Mappings for Incoming Connections">
<t>PCP is used to install the appropriate mapping(s) in the CGN so
that incoming packets can be delivered to the appropriate server.</t>
</section>
<section title="Detect Changes">
<t>In a network described in <xref target="FlowChart"></xref>, DDNS
client/ PCP client can either be running on a Customer Premise
Equipment (CPE) or be running on the host that is hosting some
services itself. There are several possible ways to address the
problems stated in <xref target="ps"></xref>:</t>
<t><list style="numbers">
<t> If the DDNS client is enabled, the host issues periodically
(e.g., 60 minutes) PCP MAP requests (e.g., messages 1 and 2 in
<xref target="FlowChart"></xref>) with short lifetime (e.g., 30s)
for the purpose of enquiring external IP address and setting. If
the purpose is to detect any change of external port, the host
must issues a PCP mapping to install a mapping for the internal
server. Upon change of the external IP address, the DDNS client
updates the records accordingly (e.g., message 3 in <xref
target="FlowChart"></xref>). </t>
<t>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 PCP client, it issues a PCP MAP
request (e.g., messages 1 and 2 in <xref
target="FlowChart"></xref>) for the purpose of enquiring 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
<xref target="FlowChart"></xref>.</t>
</list></t>
<t><figure align="center" anchor="FlowChart" title="Flow Chart">
<artwork><![CDATA[ +-----------------+
| 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) | |
| |------------------->| |
+---------------+ +-----------------+
]]></artwork>
</figure></t>
</section>
</section>
<section anchor="cs" title="Some Deployment Solutions">
<t></t>
<section title="Reference Topology">
<t><xref target="topo"></xref> illustrates the topology used for the
deployment solutions elaborated in the following sub-sections.</t>
<t><figure align="center" anchor="topo"
title="Implementation Topology">
<artwork><![CDATA[+--------------+ +--------+ +---------+ +--------+ +-------+
| 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]]></artwork>
</figure></t>
<t><xref target="topo"></xref> involves of the following
entities:<list style="symbols">
<t>Servers: refer 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
AFTR, these services have been made available to the Internet
users. The services may provide Web, FTP, SIP and other services
though these ones may not be able to been seen as using a well
known port from the outside anymore, in the IP address sharing
context. </t>
<t>B4 (CPE): An endpoint of IPv4-in-v6 tunnel <xref
target="RFC6333"></xref>. A PCP client together with a DDNS client
are running on it. After 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 DDNS client. Later,
likewise, end users may manually or let DDNS client on behalf of
it, to automatically announce IP address and/or port changes to
the DDNS server. </t>
<t>AFTR: Responsible for maintaining mappings between internal
IPv4 Address plus port and external IPv4 address plus port <xref
target="RFC6333"></xref>. </t>
<t>DDNS server: Maintains a table that associates a registered
domain name and a pair of registered host's external IPv4 address
plus port number. When being notified IP address and port number
changes from DDNS client, DDNS server announces the updates to DNS
servers on behalf of end user. <xref target="RFC2136"></xref> and
<xref target="RFC3007"></xref> may be used by DDNS server to send
updates to DNS servers. In many current practices, DDNS server
provider usually announce 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.</t>
<t>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 way as described before.</t>
</list></t>
<t></t>
</section>
<section title="For Web Service">
<t>Current DDNS server implementations typically assume that the end
servers host web server on the default 80 port. In the DS-Lite
context, they will have to take into account that external port
assigned by AFTR may be any number other than 80, in order to maintain
proper mapping between domain names and external IP plus port. By
doing such changes, the HTTP request would be redirected to the AFTR
which servers the specific end host that are running servers. </t>
<t><xref target="ws"></xref> depicts how messages are handled in order
to be delivered to the right server.</t>
<t><figure align="center" anchor="ws" title="Http Service Messages">
<artwork><![CDATA[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 |
|<-------------------------------------|--------------------------|
| | |]]></artwork>
</figure></t>
<t>When a web user sends out a HTTP GET message to DDNS server after a
standard DNS query, DDNS server redirects the request to a registered
web server, in this case, by responding with a HTTP 301 message. Then,
the HTTP GET message will be sent out to the AFTR, which will in turn
finds the proper hosts behind it. For simplicity, messages among AFTR,
B4 and web server behind B4 are not shown completely; for
communications among those nodes, refer to <xref
target="RFC6333"></xref>.</t>
</section>
<section title="For Non-web Service">
<t>For non-web services, as mentioned in <xref target="sol"></xref>,
other means will be needed to inform the users about the service
information.</t>
<t><xref target="RFC6763"></xref> includes an example of DNS-based
solution which 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 application is not
applicable, following provides another solution for a third party,
e.g., DDNS service provider, to disclose services to the Internet
users.</t>
<t>A web portal can be used to list available services. DDNS server
maintains a web portal for each user FQDN (Fully Qualified Domain
Name), which provides users service links. <xref target="wpu"></xref>
assumes "websrv.example.com" is a user's FQDN provided by a DDNS
service provider.</t>
<t><figure align="center" anchor="wpu" title="Update Web Portal">
<artwork><![CDATA[+-------------+ +-------------+ +----------+ 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 |
| <-------------------------------------------------------->|
| | | |
]]></artwork>
</figure></t>
<t>The DDNS client registers the servers' information to the DDNS
server, including public IP address and port obtained via PCP, user's
FQDN and other necessary information. The DDNS server also behaves as
portal server, it registers its IP address, port number, and user's
FQDN to the DNS system, so that visitors can access the web
portal.</t>
<t>DDNS server also maintains a web portal for each user's FQDN,
update the portal according to registered information from DDNS
client. When a visitor accesses "websrv.example.com", a DNS query will
resolve to portal server's address, port number, and the visitor will
see the portal and the available services.</t>
<t><figure align="center" anchor="wp" title="An Example of Web Portal">
<artwork><![CDATA[ +-------------------------------------------------------------+
| |
| 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 |
| |
| ...... |
| |
+-------------------------------------------------------------+]]></artwork>
</figure></t>
<t>As shown in <xref target="wp"></xref>, the web portal shows the
service URLs that are available to be accessed. Multiple services are
accessible per user's FQDN. </t>
<t>Some applications which 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.</t>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>This document does not introduce a new protocol nor specify protocol
extensions. Security-related considerations related to PCP <xref
target="RFC6887"></xref> and DS-Lite <xref target="RFC6333"></xref>
should be taken into account. </t>
<t>The protocol between the DDNS client and DDNS server is proprietary
in most cases, some extensions may be necessary, which is up to DDNS
operators. These operators should enforce security-related policies to
avoid that illegitimate users alter records installed by legitimate
users or install fake records that would lead to attract illegitimate
traffic. Means to protect the DDNS server against DoS (Denial of
Service) should be enabled. Note these considerations are not specific
to address sharing contexts but are valid for DDNS service in
general.</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>This document does not require any action from IANA.</t>
</section>
<section title="Contributors">
<t>The following individuals contributed text to the document:</t>
<t><figure>
<artwork><![CDATA[ Xiaohong Huang
Beijing University of Posts and Telecommunications, China
Email: huangxh@bupt.edu.cn
Yan Ma
Beijing University of Posts and Telecommunications, China
Email: mayan@bupt.edu.cn]]></artwork>
</figure></t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Stuart Cheshire for bringing up DNS-Based Service Discovery
and <xref target="RFC6281"></xref> where covers DNS-based SD scenario
and gives an example of how the application means of solution to address
dynamic DNS update, in this case, apple' BTMM, can be achieved.</t>
<t>Many thanks to D. Wing, D. Thaler, and J. Abley for their
comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.3986'?>
<?rfc include='reference.RFC.6333'?>
<?rfc include="reference.RFC.6887"?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.3007'?>
<?rfc include='reference.RFC.6890'?>
<?rfc include='reference.RFC.2606'?>
<?rfc include='reference.RFC.2136'?>
<?rfc include='reference.RFC.6888'?>
<?rfc include='reference.RFC.6908'?>
<?rfc include='reference.RFC.2782'?>
<?rfc include='reference.RFC.6763'?>
<?rfc include='reference.RFC.6269'?>
<?rfc include='reference.RFC.6281'?>
<?rfc include='reference.RFC.6146'?>
<?rfc include='reference.I-D.boucadair-pcp-deployment-cases'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:41:32 |