Using Port Control Protocol (PCP) to update dynamic DNS
draft-deng-pcp-ddns-06

Abstract

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.

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 December 13, 2014.

Copyright Notice

Copyright (c) 2014 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 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. Introduction
• 1.1. Problem Statement
• 1.2. Scope and Goals
• 2. Solution Space
• 2.1. Locate a Service Port
• 2.2. Create Explicit Mappings for Incoming Connections
• 2.3. Detect Changes
• 3. Some Deployment Solutions
• 3.1. Reference Topology
• 3.2. For Web Service
• 3.3. For Non-web Service
• 4. Security Considerations
• 5. IANA Considerations
• 6. Contributors
• 7. Acknowledgements
• 8. References
• 8.1. Normative References
• 8.2. Informative References
• Authors' Addresses

1. Introduction

1.1. Problem Statement

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.

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, [RFC6888]) devices, so that incoming communications initiated from Internet can be routed to the appropriate server behind the 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], NAT64 [RFC6146]). Below are listed the main challenges:

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.

Allow for incoming connections:

Appropriate means to instantiate port mappings in the address sharing device must be supported.

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.

1.2. Scope and Goals

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.

This document sketches deployment considerations based on the PCP (Port Control Protocol, [RFC6887]). Note DDNS may be considered as an implementation of the Rendezvous service mentioned in [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, and a client using DNS-Based Service Discovery [RFC6763] would use DNS Update [RFC2136][RFC3007], etc. PCP does not provide this rendezvous function.

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.

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 [RFC2136], 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.

Generic deployment considerations for DS-Lite, including 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 [I-D.boucadair-pcp-deployment-cases].

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].

IPv4 addresses used in the examples are derived from the IPv4 block reserved for documentation in [RFC6890]. DNS name examples follow [RFC2606].

2. Solution Space

2.1. Locate a Service Port

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) 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 [RFC2782]. Unfortunately, the majority of browsers do not support this record type.

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.

2.2. Create Explicit Mappings for Incoming Connections

PCP is used to install the appropriate mapping(s) in the CGN so that incoming packets can be delivered to the appropriate server.

2.3. Detect Changes

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:

1. If the DDNS client is enabled, the host issues periodically (e.g., 60 minutes) 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 accordingly (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., 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 Figure 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.

                                    +-----------------+
                                    |  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)       |                 |
|               |------------------->|                 |
+---------------+                    +-----------------+

+--------------+   +--------+    +---------+   +--------+   +-------+
| 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

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            |
|<-------------------------------------|--------------------------|
|                                      |                          |

+-------------+    +-------------+    +----------+ 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              |
    | <-------------------------------------------------------->|
    |                    |                 |                    |

  +-------------------------------------------------------------+
  |                                                             |
  |              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                 |
  |                                                             |
  |    ......                                                   |
  |                                                             |
  +-------------------------------------------------------------+

  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