From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7393.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 787 insertions(+) create mode 100644 doc/rfc/rfc7393.txt (limited to 'doc/rfc/rfc7393.txt') 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, + . + + [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- + Stack Lite Broadband Deployments Following IPv4 + Exhaustion", RFC 6333, August 2011, + . + + [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. + Selkirk, "Port Control Protocol (PCP)", RFC 6887, April + 2013, . + +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, + . + + [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS + Names", BCP 32, RFC 2606, June 1999, + . + + [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + specifying the location of services (DNS SRV)", RFC 2782, + February 2000, . + + [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic + Update", RFC 3007, November 2000, + . + + [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, + . + + + + + +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, . + + [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, + "Understanding Apple's Back to My Mac (BTMM) Service", RFC + 6281, June 2011, . + + [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", RFC 6763, February 2013, + . + + [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, + . + + [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, + "Special-Purpose IP Address Registries", BCP 153, RFC + 6890, April 2013, + . + + [RFC6908] Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M. + Boucadair, "Deployment Considerations for Dual-Stack + Lite", RFC 6908, March 2013, + . + +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] + -- cgit v1.2.3