doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc7393.txt b/doc/rfc/rfc7393.txt
new file mode 100644
index 0000000..eb73ffc
--- /dev/null
+++ b/doc/rfc/rfc7393.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Independent Submission                                           X. Deng
+Request for Comments: 7393
+Category: Informational                                     M. Boucadair
+ISSN: 2070-1721                                           France Telecom
+                                                                 Q. Zhao
+                      Beijing University of Posts and Telecommunications
+                                                                J. Huang
+                                                                 C. Zhou
+                                                     Huawei Technologies
+                                                           November 2014
+
+
+      Using the Port Control Protocol (PCP) to Update Dynamic DNS
+
+Abstract
+
+   This document focuses on the problems encountered when using dynamic
+   DNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) and
+   Network Address and Protocol Translation from IPv6 Clients to IPv4
+   Servers (NAT64)) during IPv6 transition.  Both issues and possible
+   solutions are documented in this memo.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This is a contribution to the RFC Series, independently of any other
+   RFC stream.  The RFC Editor has chosen to publish this document at
+   its discretion and makes no statement about its value for
+   implementation or deployment.  Documents approved for publication by
+   the RFC Editor are not a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7393.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deng, et al.                  Informational                     [Page 1]
+
+RFC 7393                    PCP DDNS Updates               November 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.
+
+Table of Contents
+
+   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
+     1.1.  Problem Statement . . . . . . . . . . . . . . . . . . . .   3
+     1.2.  Scope and Goals . . . . . . . . . . . . . . . . . . . . .   4
+   2.  Solution Space  . . . . . . . . . . . . . . . . . . . . . . .   5
+     2.1.  Locate a Service Port . . . . . . . . . . . . . . . . . .   5
+     2.2.  Create Explicit Mappings for Incoming Connections . . . .   5
+     2.3.  Detect Changes  . . . . . . . . . . . . . . . . . . . . .   5
+   3.  Some Deployment Solutions . . . . . . . . . . . . . . . . . .   7
+     3.1.  Reference Topology  . . . . . . . . . . . . . . . . . . .   7
+     3.2.  For Web Service . . . . . . . . . . . . . . . . . . . . .   8
+     3.3.  For Non-web Service . . . . . . . . . . . . . . . . . . .   9
+   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
+   5.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
+     5.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
+     5.2.  Informative References  . . . . . . . . . . . . . . . . .  12
+   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  13
+   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
+   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deng, et al.                  Informational                     [Page 2]
+
+RFC 7393                    PCP DDNS Updates               November 2014
+
+
+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 that offer a
+   DDNS service, working in a client and server mode, which mostly use
+   web-form-based communication.  DDNS clients are generally implemented
+   in the user's router or computer; once changes are detected to its
+   assigned IP address, an update message is automatically sent 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 have emerged
+   over time.
+
+   In address-sharing contexts, well-known port numbers (e.g., port 80)
+   won't be available for every user [RFC6269].  As such, the DDNS
+   client will have to register the IP address and/or the external
+   port(s) on which the service is listening.  Also, the DDNS client has
+   to report any change of this IP address and/or the external port(s).
+   It will also require the ability to configure corresponding port
+   forwarding on Carrier-Grade NAT (CGN) [RFC6888] devices so that
+   incoming communications initiated from the 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] and NAT64
+   [RFC6146]).  The main challenges are listed below:
+
+   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:  The 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 Customer Premises Equipment (CPE).
+
+
+
+
+
+
+Deng, et al.                  Informational                     [Page 3]
+
+RFC 7393                    PCP DDNS Updates               November 2014
+
+
+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 Port
+   Control Protocol (PCP) [RFC6887].  Note that 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,
+   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
+   focuses on the elaboration of the problem space and illustrates how
+   existing tools can be reused 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]; rather,
+   it is an operational document to make the current DDNS service
+   providers aware of the impacts and issues that IPv6 transitioning and
+   IPv4 address sharing will bring to them, and it gives solutions to
+   address the forthcoming issues.  The current DDNS service providers
+   usually employ a web-based form to maintain DDNS service registration
+   and updates.
+
+   Generic deployment considerations for DS-Lite, including Basic
+   Bridging BroadBand (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 [PCP-DEPLOYMENT].
+
+
+
+
+
+Deng, et al.                  Informational                     [Page 4]
+
+RFC 7393                    PCP DDNS Updates               November 2014
+
+
+   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) that embed an explicit
+       port number.  Indeed, the Uniform Resource Identifier (URI)
+       defined in [RFC3986] allows the port number to be carried in the
+       syntax (e.g., mydomain.example:15687).
+
+   2.  Use SRV records [RFC2782].  Unfortunately, the majority of
+       browsers do not support this record type.
+
+   The 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 as described in Figure 1, a DDNS client/PCP client can
+   be running on either a CPE or 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 periodically issues
+       (e.g., 60 minutes) PCP MAP requests (e.g., messages 1 and 2 in
+       Figure 1) with short lifetimes (e.g., 30s) for the purpose of
+       inquiring an external IP address and setting.  If the purpose is
+       to detect any change to the external port, the host must issue a
+
+
+
+
+
+Deng, et al.                  Informational                     [Page 5]
+
+RFC 7393                    PCP DDNS Updates               November 2014
+
+
+       PCP mapping to install 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 the PCP client, it issues a PCP MAP
+       request (e.g., messages 1 and 2 in Figure 1) for the purpose of
+       inquiring an 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)       |                 |
+ |               |------------------->|                 |
+ +---------------+                    +-----------------+
+
+ IWF = Internetworking Function
+
+                           Figure 1: Flow Chart
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deng, et al.                  Informational                     [Page 6]
+
+RFC 7393                    PCP DDNS Updates               November 2014
+
+
+3.  Some Deployment Solutions
+
+3.1.  Reference Topology
+
+   Figure 2 illustrates the topology used for the deployment solutions
+   elaborated in the following subsections.
+
+   +--------------+   +--------+    +---------+   +--------+   +-------+
+   | 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
+
+   Figure 2 involves the following entities:
+
+   o  Servers: Refers 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
+      the Address Family Transition Router (AFTR), these services have
+      been made available to Internet users.  The services may provide
+      web, FTP, SIP, and other services though these may not be able to
+      be seen as using a well-known port from the outside anymore, in
+      the IP address-sharing context.
+
+   o  B4(CPE): An endpoint of an IPv4-in-IPv6 tunnel [RFC6333].  A PCP
+      client together with a DDNS client are running on it.  After a 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 a DDNS client.  Later, likewise, end users may manually
+      announce or let the DDNS client automatically announce IP address
+      and/or port changes to the DDNS server.
+
+   o  AFTR: Responsible for maintaining mappings between an IPv6
+      address, the internal IPv4 address plus internal port, and the
+      external IPv4 address plus port [RFC6333].
+
+   o  DDNS server: Maintains a table that associates a registered domain
+      name and a registered host's external IPv4 address/port number
+      pair.  When being notified of IP address and port number changes
+      from a DDNS client, the DDNS server announces the updates to DNS
+      servers on behalf of the end user.  [RFC2136] and [RFC3007] may be
+
+
+
+Deng, et al.                  Informational                     [Page 7]
+
+RFC 7393                    PCP DDNS Updates               November 2014
+
+
+      used by DDNS servers to send updates to DNS servers.  In many
+      current practices, a DDNS service provider usually announces 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.
+
+   o  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 same way as described before.
+
+3.2.  For Web Service
+
+   Current DDNS server implementations typically assume that the end
+   servers host web servers on the default 80 port.  In the DS-Lite
+   context, they will have to take into account that external ports
+   assigned by the AFTR may be any number other than 80, in order to
+   maintain proper mapping between domain names and the external IP plus
+   port.  If a proper mapping is maintained, the HTTP request would be
+   redirected to the AFTR, which serves the specific end host that is
+   running the servers.
+
+   Figure 3 depicts how messages are handled in order to be delivered to
+   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.                  Informational                     [Page 8]
+
+RFC 7393                    PCP DDNS Updates               November 2014
+
+
+   When a web user sends out an HTTP GET message to the DDNS server
+   after a standard DNS query, the DDNS server redirects the request to
+   a registered web server, in this case, by responding with an HTTP 301
+   message.  Then, the HTTP GET message will be sent out to the AFTR,
+   which will in turn find the proper hosts behind it.  For simplicity,
+   messages among AFTR, B4, and the web server behind B4 are not shown
+   completely; for communications among those nodes, 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] includes an example of a DNS-based solution that 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 an application is not applicable,
+   the following provides another solution for a third party, e.g., a
+   DDNS service provider, to disclose services to Internet users.
+
+   A web portal can be used to list available services.  A DDNS server
+   maintains a web portal for each user's Fully Qualified Domain Name
+   (FQDN), which provides service links to users.  Figure 4 assumes
+   "websrv.example.com" is a user's FQDN provided by a DDNS service
+   provider.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deng, et al.                  Informational                     [Page 9]
+
+RFC 7393                    PCP DDNS Updates               November 2014
+
+
+   +-------------+    +-------------+    +----------+ 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               |
+       | <--------------------------------------------------------->|
+       |                    |                  |                    |
+
+                        Figure 4: Update Web Portal
+
+   The DDNS client registers the server's information to the DDNS
+   server, including the public IP address and port obtained via PCP,
+   the user's FQDN, and other necessary information.  The DDNS server
+   also behaves as a portal server; it registers its IP address, port
+   number, and the user's FQDN to the DNS system so that visitors can
+   access the web portal.
+
+   A DDNS server also maintains a web portal for each user's FQDN and
+   updates the portal according to registered information from the DDNS
+   client.  When a visitor accesses "websrv.example.com", a DNS query
+   will resolve the portal server's address and port number, and the
+   visitor will see the portal and the available services.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deng, et al.                  Informational                    [Page 10]
+
+RFC 7393                    PCP DDNS Updates               November 2014
+
+
+     +-------------------------------------------------------------+
+     |                                                             |
+     |              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                 |
+     |                                                             |
+     |    ......                                                   |
+     |                                                             |
+     +-------------------------------------------------------------+
+
+                   Figure 5: An Example of a Web Portal
+
+   As shown in Figure 5, the web portal shows the service URLs that are
+   available to be accessed.  Multiple services are accessible per a
+   user's FQDN.
+
+   Some applications that 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.
+
+4.  Security Considerations
+
+   This document does not introduce a new protocol, nor does it specify
+   protocol extensions.  Security-related considerations related to PCP
+   [RFC6887] and DS-Lite [RFC6333] should be taken into account.
+
+   The protocol between the DDNS client and DDNS server is proprietary
+   in most cases; some extensions may be necessary, which is up to the
+   DDNS operators.  These operators should enforce security-related
+   policies in order to keep illegitimate users from altering records
+   installed by legitimate users or installing fake records that would
+   attract illegitimate traffic.  Means to protect the DDNS server
+   against Denial of Service (DoS) should be enabled.  Note that these
+   considerations are not specific to address-sharing contexts but are
+   valid for DDNS services in general.
+
+
+
+
+
+
+
+
+
+
+
+Deng, et al.                  Informational                    [Page 11]
+
+RFC 7393                    PCP DDNS Updates               November 2014
+
+
+5.  References
+
+5.1.  Normative References
+
+   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
+              Resource Identifier (URI): Generic Syntax", STD 66, RFC
+              3986, January 2005,
+              <http://www.rfc-editor.org/info/rfc3986>.
+
+   [RFC6333]  Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-
+              Stack Lite Broadband Deployments Following IPv4
+              Exhaustion", RFC 6333, August 2011,
+              <http://www.rfc-editor.org/info/rfc6333>.
+
+   [RFC6887]  Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P.
+              Selkirk, "Port Control Protocol (PCP)", RFC 6887, April
+              2013, <http://www.rfc-editor.org/info/rfc6887>.
+
+5.2.  Informative References
+
+   [PCP-DEPLOYMENT]
+              Boucadair, M., "Port Control Protocol (PCP) Deployment
+              Models", Work in Progress, draft-boucadair-pcp-deployment-
+              cases-03, July 2014.
+
+   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
+              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
+              RFC 2136, April 1997,
+              <http://www.rfc-editor.org/info/rfc2136>.
+
+   [RFC2606]  Eastlake, D. and A. Panitz, "Reserved Top Level DNS
+              Names", BCP 32, RFC 2606, June 1999,
+              <http://www.rfc-editor.org/info/rfc2606>.
+
+   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
+              specifying the location of services (DNS SRV)", RFC 2782,
+              February 2000, <http://www.rfc-editor.org/info/rfc2782>.
+
+   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
+              Update", RFC 3007, November 2000,
+              <http://www.rfc-editor.org/info/rfc3007>.
+
+   [RFC6146]  Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
+              NAT64: Network Address and Protocol Translation from IPv6
+              Clients to IPv4 Servers", RFC 6146, April 2011,
+              <http://www.rfc-editor.org/info/rfc6146>.
+
+
+
+
+
+Deng, et al.                  Informational                    [Page 12]
+
+RFC 7393                    PCP DDNS Updates               November 2014
+
+
+   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
+              Roberts, "Issues with IP Address Sharing", RFC 6269, June
+              2011, <http://www.rfc-editor.org/info/rfc6269>.
+
+   [RFC6281]  Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang,
+              "Understanding Apple's Back to My Mac (BTMM) Service", RFC
+              6281, June 2011, <http://www.rfc-editor.org/info/rfc6281>.
+
+   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
+              Discovery", RFC 6763, February 2013,
+              <http://www.rfc-editor.org/info/rfc6763>.
+
+   [RFC6888]  Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A.,
+              and H. Ashida, "Common Requirements for Carrier-Grade NATs
+              (CGNs)", BCP 127, RFC 6888, April 2013,
+              <http://www.rfc-editor.org/info/rfc6888>.
+
+   [RFC6890]  Cotton, M., Vegoda, L., Bonica, R., and B. Haberman,
+              "Special-Purpose IP Address Registries", BCP 153, RFC
+              6890, April 2013,
+              <http://www.rfc-editor.org/info/rfc6890>.
+
+   [RFC6908]  Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M.
+              Boucadair, "Deployment Considerations for Dual-Stack
+              Lite", RFC 6908, March 2013,
+              <http://www.rfc-editor.org/info/rfc6908>.
+
+Acknowledgements
+
+   Thanks to Stuart Cheshire for bringing up DNS-Based Service Discovery
+   (SD) and [RFC6281], which covers a DNS-based SD scenario and gives an
+   example of how the application is a means for a solution to address
+   dynamic DNS updates; in this case, Apple's BTMM can be achieved.
+
+   Many thanks to D. Wing, D. Thaler, and J. Abley for their comments.
+
+Contributors
+
+   The following individuals contributed text to the document:
+
+      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
+
+
+
+
+Deng, et al.                  Informational                    [Page 13]
+
+RFC 7393                    PCP DDNS Updates               November 2014
+
+
+Authors' Addresses
+
+   Xiaohong Deng
+
+   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
+   China
+
+   EMail: james.huang@huawei.com
+
+   Cathy Zhou
+   Huawei Technologies
+   China
+
+   EMail: cathy.zhou@huawei.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deng, et al.                  Informational                    [Page 14]
+