One document matched: draft-deng-pcp-ddns-05.txt
Differences from draft-deng-pcp-ddns-04.txt
DNSOP Working Group X.Deng
Internet Draft M.Boucadair
Intended status: Informational France Telecom
Expires: September 20, 2014 Q.Zhao
BUPT
J.Huang
C.Zhou
Huawei
March 19, 2014
Using PCP to update dynamic DNS
draft-deng-pcp-ddns-05.txt
Abstract
This document focuses on the problems encountered when using dynamic
DNS in address sharing contexts (e.g., DS-Lite, NAT64) during IPv6
transition. Issues and possible solutions are documented in this memo.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 16, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
Deng, et al. Expires April 16, 2013 [Page 1]
Internet-Draft PCP DDNS updates February 2014
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.
Table of Contents
1. Problem Statement ........................................... 2
2. Solution Space .............................................. 4
2.1. Locate a Service Port .................................. 4
2.2. Detect Changes ......................................... 4
3. Possible Solutions .......................................... 6
3.1. Topology ............................................... 6
3.2. For Web Service ........................................ 7
3.3. For Non-web Service .................................... 8
4. Security Considerations ..................................... 9
5. IANA Considerations ........................................ 10
6. Additional Authors' Addresses .............................. 10
7. Acknowledgments ............................................ 10
8. References ................................................. 10
8.1. Normative References................................... 10
8.2. Informative References ................................ 11
9. Authors' Addresses ......................................... 12
1. Problem Statement
Dynamic DNS (DDNS) is a widely deployed service to facilitate hosting
servers (e.g., to host webcam and http server) at premises. There are
a number of providers who 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 IP address it
automatically sends an update message to the DDNS server. The
communication between the client and the server is not standardized,
varying from one provider to another, although a few standard web-
based methods of updating emerged over time.
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 devices, so that incoming
Deng, et al. Expires July 12, 2014 [Page 2]
Internet-Draft PCP DDNS updates February 2014
communications initiated from outside can be routed to the
appropriate server behind the CGN.
This document focuses on the problems encountered when using dynamic
DNS in address sharing contexts (e.g., DS-Lite, NAT64). Below are
listed the main challenges:
(1) The DDNS service MUST be able to maintain an alternative port
number instead of the default port number.
(2) Appropriate means to instantiate port mapping in the address
sharing device MUST be supported.
(3) 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, 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.
This document describes solutions to resolve issues listed above in
the particular case of DS-Lite.
Note DDNS may be considered as an implementation of the Rendezvous
service mentioned in [RFC6887].
After creating a mapping for incoming connections, it is necessary to
inform remote computers about the IP address, protocol, and port 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 computer game 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 [RFC6763]
would use DNS Update [RFC2136][RFC3007]. PCP does not provide this
rendezvous function. RFC6281 shows an good example of how to use the
DNS-Based Service Discovery to make the service announcement
available, in an application manner. 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. In the solution section, it
gives an example how the DDNS server may implement such a service
notification functionality if necessary.
This document requires no changes to PCP protocol or dynamic updates
in the standard domain name system [RFC2136], but is rather an
Deng, et al. Expires July 12, 2014 [Page 3]
Internet-Draft PCP DDNS updates February 2014
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. For DNS-based Service Discovery, or DNS-SD and updates,
[RFC6763] intensively describes how to use DNS resource records and
standard DNS queries to facilitate service discovery, and [RFC6281]
elaborates an implementation of it with an Apple's Back to My Mac
(BTMM) Service.
2. Solution Space
2.1. Locate a Service Port
At least two solutions can be used to associate a port number with a
service identified:
(1) Use service URIs (e.g., FTP, SIP, HTTP) which embed an explicit
port number. Indeed, Uniform Resource Identifier (URI) defined in
[RFC3986] allows to carry port number in the syntax (e.g.,
mydomain.example:15687)
(2) Use SRV records. Unfortunately, the majority of browsers do not
support this record type.
DDNS client and server are to be updated so that an alternative port
number is also signaled and stored by the server. Requesting remote
hosts will be then notified with the IP address and port number to
reach the server.
2.2. Detect Changes
Deng, et al. Expires July 12, 2014 [Page 4]
Internet-Draft PCP DDNS updates February 2014
+-----------------+
| 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) | |
| |------------------->| |
+---------------+ +-----------------+
Figure 1 : Flow Chart
First of all, PCP MUST be used to install the appropriate mapping in
the CGN so that incoming packets can be delivered to the appropriate
server.
In a network described in figure 1, 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 section 1.
(1) If the DDNS client is enabled, the host issues periodically (e.g.,
1h) PCP MAP requests (e.g., messages 1 and 2 in Figure 1) 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 (e.g., message 3 in Figure 1).
(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., 5mn, 30mn, 1h). If there is no PCP mapping created by PCP
client, it issues a PCP MAP request (e.g., messages 1 and 2 in Figure
Deng, et al. Expires July 12, 2014 [Page 5]
Internet-Draft PCP DDNS updates February 2014
1) 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 Figure 1.
3. Possible Solutions
3.1. Topology
+--------------+ +--------+ +---------+ +--------+ +-------+
| 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
Servers: 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.
B4 (CPE): An endpoint of IPv4-in-v6 tunnel. 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 and port changes to the DDNS server.
AFTR: Responsible for maintaining mappings between internal IPv4
Address plus port and external IPv4 address plus port.
DDNS server: Maintains a table linking 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 then announces the updates to DNS servers on
behalf of end user. RFC 2136 and RFC 2137 may be used by DDNS server
Deng, et al. Expires July 12, 2014 [Page 6]
Internet-Draft PCP DDNS updates February 2014
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.
Service users: Users who want to access services behind an IP address
sharing network. They send out 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.
Then the DDNS server will handle the rest in the way as described
before.
3.2. For Web Service
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 to implementation, the HTTP request would
be redirected to the AFTR which servers the specific end host that
are running servers. The following chart shows how the messages reach
the right server.
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
Deng, et al. Expires July 12, 2014 [Page 7]
Internet-Draft PCP DDNS updates February 2014
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, please refer to [RFC6333].
3.3. For Non-web Service
For non-web services, as mentioned in Section 2, other means will be
needed to inform the users about the service information.
[RFC6763] shows an good example of DNS based solution to do so, in
which case an application running in the end user's device will
retrieve service information via DNS SRV/TXT records, and list
available services. In a scenario where such application is not
applicable, following provides another means for a third party, e.g.
DDNS service provider, to disclose services to the Internet users.
A web portal can be used to list available services. DDNS server
maintains a web portal for each user FQDN, which provides a users
service links. In the figure below, it assumes websrv.myip.org is a
user's FQDN provided by a DDNS service provider.
+-------------+ +-------------+ +----------+ Internet +-------+
|DDNS client /|----|DDNS server /|----|DNS server|----------|Visitor|
| Web Server | | web portal | | | | |
+-------------+ +-------------+ +----------+ +-------+
| register | | |
|<------------------> | | |
| websrv.myip.org | update DNS | |
| 100.1.1.2:2000 | <-------------> | |
| | websrv.myip.org | |
| | portal's IP | |
| +-------------+ | |
| |update portal| | |
| +-------------+ | DNS resolve for |
| | | <----------------> |
| | | websrv.myip.org |
| | | get portal's IP |
| | | |
| | visit portal of websrv.myip.org |
| | <----------------------------------> |
| | | |
| visit http://100.1.1.2:2000 |
| <--------------------------------------------------------> |
Figure 4 Update Web Portal
Deng, et al. Expires July 12, 2014 [Page 8]
Internet-Draft PCP DDNS updates February 2014
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 works as portal
server, it registers its IP address and user's FQDN to the DNS system,
so that visitors can visit the web portal.
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 visits websrv.myip.org, DNS query will resolve to portal
server's address, and the visitor will see the portal and the
available services.
+-------------------------------------------------------------+
| |
| Portal of websrv.myip.org |
| |
| Service1: web server |
| Link: http://100.1.1.2:2000 |
| |
| Service2: video |
| Link: rtsp://100.1.1.2:8080/test.sdp |
| |
| ...... |
| |
+-------------------------------------------------------------+
Figure 5 An Example of Web Portal
The web portal in the above figure shows service links that are
available to be accessed. Multiple services is accessible per user's
FQDN. Some applications which are not http based can also be
supported via this solution. When user click 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.
4. Security Considerations
This memo does not introduce a new protocol, but makes use of
existing protocols, including PCP, DNS, HTTP redirect. The protocol
Deng, et al. Expires July 12, 2014 [Page 9]
Internet-Draft PCP DDNS updates February 2014
between the DDNS client and server is proprietary in most cases, some
extension may be necessary, which is up to DDNS operators.
5. IANA Considerations
This draft does not request any action from IANA.
6. Additional Authors' Addresses
This work is made available also from additional authors'
contribution and work.
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
7. Acknowledgments
Thanks to Stuart Cheshire for bringing up DNS-Based Service Discovery
and RFC6281 where covers DNS-based SD scenario and gives a good
example of how the application means of solution to address dynamic
DNS update, in this case, apple' BTMM, can be achieved.
8. References
8.1. Normative References
[RFC2136]
P. Vixie, et. al." Dynamic Updates in the Domain Name
System (DNS UPDATE)", April 1997.
[RFC3007]
B. Wellington, " Secure Domain Name System (DNS) Dynamic
Update", November 2000.
Deng, et al. Expires July 12, 2014 [Page 10]
Internet-Draft PCP DDNS updates February 2014
[RFC3986]
T. Berners-Lee, et. al. " Uniform Resource Identifier (URI):
Generic Syntax", January 2005.
[RFC6281]
S. Cheshire, et. Al. " Understanding Apple's Back to My Mac
(BTMM) Service", June 2011.
[RFC6333]
A. Durand, et. Al. " Dual-Stack Lite Broadband Deployments
Following IPv4 Exhaustion", August 2011.
8.2. Informative References
[RFC6887]
D. Wing, et. al. " Port Control Protocol (PCP)", April 2013.
[RFC6763]
S. Cheshire, et. al. " DNS-Based Service Discovery ",
February 2013
Deng, et al. Expires July 12, 2014 [Page 11]
Internet-Draft PCP DDNS updates February 2014
9. Authors' Addresses
Xiaohong Deng
France Telecom
Rennes,35000 France
Email: dxhbupt@gmail.com
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
Email: james.huang@huawei.com
Cathy Zhou
Huawei Technologies
Email: cathy.zhou@huawei.com
Deng, et al. Expires July 12, 2014 [Page 12]
| PAFTECH AB 2003-2026 | 2026-04-24 01:14:46 |