Skip to main content

Using PCP to update dynamic DNS
draft-deng-pcp-ddns-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7393.
Authors Xiaohong Deng , Mohamed Boucadair , Xu Wang
Last updated 2012-07-06
RFC stream (None)
Formats
IETF conflict review conflict-review-deng-pcp-ddns, conflict-review-deng-pcp-ddns, conflict-review-deng-pcp-ddns, conflict-review-deng-pcp-ddns, conflict-review-deng-pcp-ddns, conflict-review-deng-pcp-ddns
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 7393 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-deng-pcp-ddns-00
Internet Engineering Task Force                                   X.Deng             
Internet Draft                                               M.Boucadair     
Intended status: Informational                            France Telecom 
Expires: January 4, 2013                                          X.Wang 
                                                                    BUPT             
                                                            July 3, 2012 
                                     
                                     
                                     
                     Using PCP to update dynamic DNS 
                       draft-deng-pcp-ddns-00.txt 

Abstract 

    

  This document focuses on the problems encountered when using dynamic 
  DNS in address sharing contexts (e.g., DS-Lite, NAT64, A+P)during 
  IPv6 transition. Issues, possible solutions and preliminary  
  implementation and validation of one of the 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 January 4, 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 

 
Deng, et al.           Expires January 4, 2013                [Page 1] 

 
Internet-Draft            PCP DDNS updates                   July 2012 
 
 
  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. Problem statement ........................................... 2 
  2. Solution Space .............................................. 3 
     2.1. Locate a service port................................... 3 
     2.2. Detect the changes ..................................... 4 
  3. Implementation & Validation ................................. 7 
  4. References .................................................. 8 
     4.1. Normative References.................................... 8 
     4.2. Informative References.................................. 8 
  5. Authors' Addresses .......................................... 9 
   
1. Problem statement 

    

  Dynamic DNS (DDNS) is a widely deployed service to facilitate hosting 
  servers (e.g., to host webcam and http server) at home premises. 
  There are a number of providers who offer a DDNS service, working in 
  a client and server mode. 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 
  standardised, varying from one provider to another, although a few 
  standard web-based methods of updating have 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 a 
  well know port numbers, e.g. port 80 will no longer be available to 
  every web server. It will also require the ability to configuring 
  corresponding port forwarding on CGN devices, so that incoming 
  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, A+P). Below 
  are listed the main challenges to us:  

 
 
Deng, et al.           Expires January 4, 2013                [Page 2] 

 
Internet-Draft            PCP DDNS updates                   July 2012 
 
 
  (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 event 
  exacerbated in the DS-Lite context because no IPv4 address is 
  assigned to the CPE.   

  This document describes solutions to counter the issues listed above 
  in the particular case of DS-Lite. 

  Note DDNS may be considered as an implementation of the Rendez-vous 
  service mentioned in [I-D.ietf-pcp-base]. 

  "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.  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 [I-D.cheshire-dnsext-dns-sd] would use DNS Update 
  [RFC2136][RFC3007].  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." 

  Dynamic Updates in the standard Domain Name System (DNS UPDATE) 
  (RFC2136) is out of scope of this memo. 

   

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) 

 
 
Deng, et al.           Expires January 4, 2013                [Page 3] 

 
Internet-Draft            PCP DDNS updates                   July 2012 
 
 
  (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 signalled and stored by the server. Requesting remote 
  hosts will be then notified with the IP address and port number to 
  use to reach the server.  

2.2. Detect the changes 

 
                                           
 
 
 
 
 
                                       +-----------------+ 
                                       |  DDNS Server    | 
                                       |                 | 
                                       +-----------------+  
                                              ^ 
                                              |  
                                              |3. DDNS updates 
                                              |  (if any) 
                                              | 
   +-----------------+                    +-----------------+ 
   |DDNS Client      |1. PCP MAP request  | CGN/PCP Server  |  
   |PCP Client/IWF ON|------------------->| (PCP mapping for 80:8080   +------+            
   |CPE or           |2. PCP MAP response | port forwarding)|<---------|Client|                    
   |the host itself  |<-------------------|                 |          |      |    
   |                 |3. DDNS updates     |                 |          +------+             
   |                 |     (if any)       |                 | 
   |                 |------------------->|                 | 
   +-----------------+                    +-----------------+ 
 
 
                          Figure 1 : Flow chat   

  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 
 
 
Deng, et al.           Expires January 4, 2013                [Page 4] 

 
Internet-Draft            PCP DDNS updates                   July 2012 
 
 
  on the host that is hosting some services, itself.  There are 
  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 caused by PCP 
  client losing states for example, 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. 

 

  (3)If the DDNS client is enabled, the A/AAAA records of DNS (which 
  could be normal one as using on the Internet now) were set to point 
  the DDNS Server. DDNS is responsible for the translation between 
  public IPv4 address (address of DDNS) with specific port (E.g. web 
  with 80 port) and public IPv4 address (outside IPv4 address and port 
  number of mappings). Show as Figure 2. 

 

  (4)If a user of another client outside DS-Lite network wants to 
  access a server behind AFTR, the role of DDNS started to become 
  important. Before that the following mappings should had been 
  configured well: 

      a. PCP mappings: private IPv4 address: port number <--> public 
  IPv4 address: port number 

      b. DDNS mappings: public IPv4 address: port number <--> domain 
  name 

 
 
Deng, et al.           Expires January 4, 2013                [Page 5] 

 
Internet-Draft            PCP DDNS updates                   July 2012 
 
 
      c. DNS Resolution: A/AAAA Records (point to the DDNS server) <--> 
  domain name 

 

  Customer        DDNS             AFTR         CPE            Visitor  

     | DNS request | public         |encapsulated |               |  

     |------------>| address: port  |private      |               | 

     |             |--------------->|address: port|               | 

     |             |                |------------>| IPv4 request  | 

     |             |            response          |-------------->| 

     |<------------|----------------|-------------|---------------| 

     |             |                |             |               | 

                     Figure 2 : Time Sequence Chart 

  (5) A domain resolution request is sent from host of customer who 
  asking service. The request is sent to the DNS server. And DNS server 
  would return a response with A/AAAA records pointing to the DDNS 
  server. If the request is sent to the DDNS directly, it would 
  redirect the request to the pointed IPv4 address and port number 
  which has been configured in the mappings. 

  (6) After redirection the request is routed to the AFTR. AFTR would 
  translate it from public IPv4 address and port number into private 
  IPv4 address and port. The request finished AFTR translation and is 
  encapsulated into a IPv4-in-IPv6 package until CPE. 

  (7) At last the request would be decapsulated to an IPv4 package and 
  is sent to the service provider. And the response would return to the 
  customer as requested routine. The whole communication process is 
  finished successfully. 

 
 
Deng, et al.           Expires January 4, 2013                [Page 6] 

 
Internet-Draft            PCP DDNS updates                   July 2012 
 
 
3. Implementation & Validation                            

  So far the topology of network was implemented as Figure 1. Based on 
  the DS-Lite environment some new roles added into it such as DDNS. It 
  could be implemented by Apache or other applications which has 
  virtual host functions. The DDNS need to be configured as a virtual 
  host and redirect corresponding request to the pointed IPv4 address 
  and port number. It could be validated as Figure 3 shows. 
   
                                     
  ----------------   ----------    -----------   ----------   --------- 
  |Service Server|   |  PCP   |    |  CGN&   |   | DDNS   |   |User's | 
  | DDNS client  |---|  Client|----|  PCP    |---| Server |---|Host   | 
  |              |   |        |    |  Server |   |        |   |       | 
  ----------------   ----------    -----------   ----------   --------- 
   Service provider      B4           AFTR          DDNS       Visitor 
                                     
                     Figure 3 : Implementation Chart 

    Service provider: Web server was deployed in the DS-Lite network 
  environment. It just has private IPv4 address and with a mapping in 
  AFTR to the public network. The server may offer Web, FTP, SIP 
  service and so on. And these services may not be set as their 
  specific port. (this also is the reason why introducing DDNS into DS-
  Lite environment) 

    B4 (CPE): An endpoint of IPv4-in-v6 tunnel, and PCP client also 
  runs on it. A package from Service Server is encapsulated into a 
  IPv4-in-v6 one and is sent to the AFTR. A package from AFTR will be 
  decapsulated to a normal IPv4 package and to their destination. 

    AFTR: Responsible for mappings between internal IPv4 Address: port 
  and external IPv4 address: port. It maintains a table to restore 
  these data to keep state of every mapping. 

    DDNS: Maintaining mappings between domain name and external IPv4 
  address: port. If a DNS request was sent to it, DDNS server could 
  resolve it to the AFTR which contains that IPv4 address and port 
  number. 

    Visitor: Some users who need to access service on the Service 
  Server. They send service request needed to resolve domain name. And 
  the response would returned to their hosts as the ways of request 
  reached to the Service Server. 

    From the view of visitor, the location of service server is on DDNS, 
  just like a virtual host. It at least has three advantages. Firstly, 

 
 
Deng, et al.           Expires January 4, 2013                [Page 7] 

 
Internet-Draft            PCP DDNS updates                   July 2012 
 
 
  hackers and other attackers couldn't reach the real host and do 
  something bad. The security is assured. Secondly, many domain name or 
  space ISPs also provide service of domain and port mapping. However, 
  some companies may use iframe or 301 redirection technology. Those 
  means could lead to lower speed and affect PR weights to the search 
  engine. Click-through rate and visits was 'stolen'. That could not be 
  introduced into Carrier Scale Network. Hence, generation of DDNS has 
  its unique meaning. Thirdly, DDNS solution could solve the problems 
  of IP address + port mapping almost perfectly. Under DS-Lite network 
  environment normal DNS resolution couldn't point a domain name to a 
  IP address and a port. Because of designing defect of traditional DNS 
  protocol a DNS request just could be resolve to be a A/AAAA record 
  (the services have their own specific port. Such as web is 80 and ftp 
  is 21, etc.). So DDNS as a supplementary was introduced into DS-Lite 
  to play a role of mapping between domain name and IP address and port 
  number.  

4. References 

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

  [RFC3986] 

            T. Berners-Lee, et. al. " Uniform Resource Identifier (URI): 
            Generic Syntax", January 2005. 

4.2. Informative References   

  [I-D.ietf-pcp-base] 

            D. Wing, et. al. " Port Control Protocol (PCP)", June 5, 
            2012. 

     

 
 
Deng, et al.           Expires January 4, 2013                [Page 8] 

 
Internet-Draft            PCP DDNS updates                   July 2012 
 
 
   
5. 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 
   
   
   Xu Wang 
   Beijing University of Posts and Telecommunications, China 
   Email: cngesaint@gmail.com 
   
      
   
    
   
   
   
   
   
    

 
 
Deng, et al.           Expires January 4, 2013                [Page 9]