summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7393.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7393.txt')
-rw-r--r--doc/rfc/rfc7393.txt787
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]
+