[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 7393

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]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/