Network Working Group
Independent Submission                                           X. Deng
Internet-Draft
Intended status:
Request for Comments: 7393
Category: Informational                                     M. Boucadair
Expires: December 13, 2014
ISSN: 2070-1721                                           France Telecom
                                                                 Q. Zhao
                      Beijing University of Posts and Telecommunications
                                                                J. Huang
                                                                 C. Zhou
                                                     Huawei Technologies
                                                           June 11,
                                                            October 2014

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

Abstract

   This document focuses on the problems encountered when using dynamic
   DNS in address sharing address-sharing contexts (e.g., DS-Lite, NAT64) 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 Internet-Draft document is submitted in full conformance with not an Internet Standards Track specification; it is
   published for informational purposes.

   This is a contribution to the
   provisions RFC Series, independently of BCP 78 any other
   RFC stream.  The RFC Editor has chosen to publish this document at
   its discretion and BCP 79.

   Internet-Drafts makes no statement about its value for
   implementation or deployment.  Documents approved for publication by
   the RFC Editor are working documents not a candidate for any level of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list
   Standard; see Section 2 of RFC 5741.

   Information about the current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum status of six months this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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.
   http://www.rfc-editor.org/info/rfc7393.

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

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 that offer a
   DDNS service, working in a client and server mode, which mostly use a
   web-form based
   web-form-based communication.  DDNS clients are generally implemented
   in the user's router or computer, which computer; once detects changes are detected to its
   assigned IP address it automatically sends 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.

   When the network architecture evolves towards an IPv4 sharing
   architecture during IPv6 transition,

   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 not
   only inform register the IP address updates if any, but also to notify and/or the
   changes of external port
   port(s) on which the service is listening, because
   well known port numbers, e.g., port 80 will no longer be available listening.  Also, the DDNS client has
   to
   every web server. 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 CGN (Carrier Grade NAT, [RFC6888])
   devices, 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 address-sharing contexts (e.g., DS-Lite [RFC6333], [RFC6333] and NAT64
   [RFC6146]).  Below  The main challenges are listed the main challenges: below:

   Announce and Discover 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 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
      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. Customer Premises Equipment (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 address-sharing schemes.

   This document sketches deployment considerations based on the PCP
   (Port Port
   Control Protocol, [RFC6887]). Protocol (PCP) [RFC6887].  Note that DDNS may be considered
   as an implementation of the Rendezvous 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, extension but instead it
   focuses on the elaboration of the problem space and illustrate illustrates how
   existing tools can be re-used 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], but [RFC2136]; rather,
   it 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 it gives solutions to
   address the forthcoming issues.  The current DDNS service providers
   usually employs employ a web-based form to maintain DDNS service registration
   and updates.

   Generic deployment considerations for DS-Lite, including B4 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 rendezvous
   service maintenance.  Additional PCP-related deployment
   considerations are available at
   [I-D.boucadair-pcp-deployment-cases]. [PCP-DEPLOYMENT].

   Solutions relying on DNS-based 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 that embed an explicit
       port number.  Indeed, the Uniform Resource Identifier (URI)
       defined in [RFC3986] allows to carry 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/PCP client can
   either
   be running on either a Customer Premise Equipment (CPE) 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 issues
       (e.g., 60 minutes) PCP MAP requests (e.g., messages 1 and 2 in
       Figure 1) with short lifetime lifetimes (e.g., 30s) for the purpose of
       enquiring
       inquiring an external IP address and setting.  If the purpose is
       to detect any change of to the external port, the host must issues issue 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 the PCP client, it issues a PCP MAP
       request (e.g., messages 1 and 2 in Figure 1) for the purpose of
       enquiring
       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

3.  Some Deployment Solutions

3.1.  Reference Topology

   Figure 2 illustrates the topology used for the deployment solutions
   elaborated in the following sub-sections. subsections.

   +--------------+   +--------+    +---------+   +--------+   +-------+
   | Service      |   |  DDNS  |    |  CGN&  CGN/   |   | PCP    |   |Servers|
   | User         |---|  Server|----|  PCP    |---| Client |---|       |
   |              |   |        |    |  Server |   | /DDNS  |   |       |
   |              |   |        |    |         |   | client Client |   |       |
   +--------------+   +--------+    +---------+   +--------+   +-------+
       A user         DDNS Server       AFTR        B4(CPE)      A host

   From
    from Internet                                  behind B4

                     Figure 2: Implementation Topology

   Figure 2 involves of the following entities:

   o  Servers: refer Refers to the servers that are deployed in the DS-Lite
      network, or more generally, an IP address sharing 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,
      the Address Family Transition Router (AFTR), these services have
      been made available to the Internet users.  The services may provide Web,
      web, FTP, SIP SIP, and other services though these ones may not be able to been
      be seen as using a well
      known well-known port from the outside anymore, in
      the IP address sharing address-sharing context.

   o  B4 (CPE):  B4(CPE): An endpoint of IPv4-in-v6 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 on behalf of it, to 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 address plus port internal port, and the
      external IPv4 address plus port [RFC6333].

   o  DDNS server: Maintains a table that associates a registered domain
      name and a pair of registered host's external IPv4 address plus
      port number. 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
      used by DDNS server servers to send updates to DNS servers.  In many
      current practices, a DDNS server service provider usually announce 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 Refers to users who want to access services behind
      an IP address sharing 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 server servers on the default 80 port.  In the DS-Lite
   context, they will have to take into account that external port 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.  By doing such changes,  If a proper mapping is maintained, the HTTP request would be
   redirected to the AFTR AFTR, which servers serves the specific end host that are is
   running the servers.

   Figure 3 depicts how messages are handled in order to be delivered to
   the right server.

   Web Visitor        DDNS server Server       AFTR      B4(CPE)     Web Server
                                                               behind B4
   | HTTP Get* GET*             |              |          |               |
   |---------------------->|              |          |               |
   | ip_DDNS_server        |------------->|          |               |
   |                       | HTTP 301     |          |               |
   |                       |<-------------|          |               |
   | HTTP Get* GET* ip_aftr:8001               |          |               |
   |------------------------------------->|                          |
   |                                      | HTTP Get* GET* ip_websrv:8000 |
   |                                      |------------------------->|
   |                                      |                          |
   |                       HTTP response  | HTTP response            |
   |<-------------------------------------|--------------------------|
   |                                      |                          |

                      Figure 3: Http HTTP Service Messages

   When a web user sends out a 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 a an HTTP 301
   message.  Then, the HTTP GET message will be sent out to the AFTR,
   which will in turn finds find the proper hosts behind it.  For simplicity,
   messages among AFTR, B4 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 which that allows an
   application running in the end user's device to retrieve service-
   related information via DNS SRV/TXT records, 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 the Internet users.

   A web portal can be used to list available services.  A DDNS server
   maintains a web portal for each user FQDN (Fully user's Fully Qualified Domain
   Name), Name
   (FQDN), which provides users service links. links to users.  Figure 4 assumes
   "websrv.example.com" is a user's FQDN provided by a DDNS service
   provider.

   +-------------+    +-------------+    +----------+ Internet +-------+
   |DDNS client Client /|    |DDNS server Server /|    |DNS server| Server|          |Visitor|
   |  Web Server |    | web portal 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 servers' server's information to the DDNS
   server, including the public IP address and port obtained via PCP,
   the user's
   FQDN FQDN, and other necessary information.  The DDNS server
   also behaves as a portal server, server; it registers its IP address, port
   number, and the user's FQDN to the DNS system, system so that visitors can
   access the web portal.

   A DDNS server also maintains a web portal for each user's FQDN, update 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 to the portal server's address, address and port number, and the
   visitor will see the portal and the available services.

     +-------------------------------------------------------------+
     |                                                             |
     |              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 which that are not HTTP-based 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 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, cases; some extensions may be necessary, which is up to the
   DDNS operators.  These operators should enforce security-related
   policies in order to avoid that keep illegitimate users alter from altering records
   installed by legitimate users or install installing fake records that would lead to
   attract illegitimate traffic.  Means to protect the DDNS server
   against DoS
   (Denial Denial of Service) Service (DoS) should be enabled.  Note that these
   considerations are not specific to address sharing address-sharing contexts but are
   valid for DDNS
   service services in general.

5.  IANA Considerations

   This document does not require any action from IANA.

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

7.  Acknowledgements

   Thanks to Stuart Cheshire for bringing up DNS-Based Service Discovery
   and [RFC6281] where covers DNS-based SD scenario and gives an example
   of how the application means of solution to address dynamic DNS
   update, in this case, apple' BTMM, can be achieved.

   Many thanks to D.  Wing, D.  Thaler, and J.  Abley for their
   comments.

8.  References

8.1.

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

8.2.
              2013, <http://www.rfc-editor.org/info/rfc6887>.

5.2.  Informative References

   [I-D.boucadair-pcp-deployment-cases]

   [PCP-DEPLOYMENT]
              Boucadair, M., "Port Control Protocol (PCP) Deployment
              Models", draft-boucadair-pcp-deployment-cases-02 (work Work in
              progress), April 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. 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. 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. 2000, <http://www.rfc-editor.org/info/rfc2782>.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, November 2000. 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. 2011,
              <http://www.rfc-editor.org/info/rfc6146>.

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269, June
              2011.
              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. 2011, <http://www.rfc-editor.org/info/rfc6281>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, February 2013. 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. 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. 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. 2013,
              <http://www.rfc-editor.org/info/rfc6908>.

Appendix A.  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.

Appendix B.  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

Authors' Addresses

   Xiaohong Deng

   Email:

   EMail: dxhbupt@gmail.com

   Mohamed Boucadair
   France Telecom
   Rennes  35000
   France

   Email:

   EMail: mohamed.boucadair@orange.com

   Qin Zhao
   Beijing University of Posts and Telecommunications
   China

   Email:

   EMail: zhaoqin.bupt@gmail.com

   James Huang
   Huawei Technologies
   China

   Email:

   EMail: james.huang@huawei.com
   Cathy Zhou
   Huawei Technologies
   China

   Email:

   EMail: cathy.zhou@huawei.com