idnits 2.17.1 draft-deng-pcp-ddns-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 11, 2014) is 3578 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-boucadair-pcp-deployment-cases-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Deng 3 Internet-Draft 4 Intended status: Informational M. Boucadair 5 Expires: December 13, 2014 France Telecom 6 Q. Zhao 7 Beijing University of Posts and Telecommunications 8 J. Huang 9 C. Zhou 10 Huawei Technologies 11 June 11, 2014 13 Using Port Control Protocol (PCP) to update dynamic DNS 14 draft-deng-pcp-ddns-06 16 Abstract 18 This document focuses on the problems encountered when using dynamic 19 DNS in address sharing contexts (e.g., DS-Lite, NAT64) during IPv6 20 transition. Both issues and possible solutions are documented in 21 this memo. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on December 13, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . 2 59 1.2. Scope and Goals . . . . . . . . . . . . . . . . . . . . . 3 60 2. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Locate a Service Port . . . . . . . . . . . . . . . . . . 4 62 2.2. Create Explicit Mappings for Incoming Connections . . . . 5 63 2.3. Detect Changes . . . . . . . . . . . . . . . . . . . . . 5 64 3. Some Deployment Solutions . . . . . . . . . . . . . . . . . . 6 65 3.1. Reference Topology . . . . . . . . . . . . . . . . . . . 6 66 3.2. For Web Service . . . . . . . . . . . . . . . . . . . . . 7 67 3.3. For Non-web Service . . . . . . . . . . . . . . . . . . . 8 68 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 11 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 74 8.2. Informative References . . . . . . . . . . . . . . . . . 11 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 77 1. Introduction 79 1.1. Problem Statement 81 Dynamic DNS (DDNS) is a widely deployed service to facilitate hosting 82 servers (e.g., access to a webcam, HTTP server, FTP server, etc.) at 83 customers' premises. There are a number of providers which offer a 84 DDNS service, working in a client and server mode, which mostly use a 85 web-form based communication. DDNS clients are generally implemented 86 in the user's router or computer, which once detects changes to its 87 assigned IP address it automatically sends an update message to the 88 DDNS server. The communication between the DDNS client and the DDNS 89 server is not standardized, varying from one provider to another, 90 although a few standard web-based methods of updating emerged over 91 time. 93 When the network architecture evolves towards an IPv4 sharing 94 architecture during IPv6 transition, the DDNS client will have to not 95 only inform the IP address updates if any, but also to notify the 96 changes of external port on which the service is listening, because 97 well known port numbers, e.g., port 80 will no longer be available to 98 every web server. It will also require the ability to configure 99 corresponding port forwarding on CGN (Carrier Grade NAT, [RFC6888]) 100 devices, so that incoming communications initiated from Internet can 101 be routed to the appropriate server behind the CGN. 103 Issues encountered in address sharing are documented in [RFC6269]. 104 This document focuses on the problems encountered when using dynamic 105 DNS in address sharing contexts (e.g., DS-Lite [RFC6333], NAT64 106 [RFC6146]). Below are listed the main challenges: 108 Announce and Discover an alternate service port: The DDNS service 109 must be able to maintain an alternative port number instead of the 110 default port number. 112 Allow for incoming connections: Appropriate means to instantiate 113 port mappings in the address sharing device must be supported. 115 Detect changes and trigger DDNS updates: DDNS client must be 116 triggered by the change of the external IP address and the port 117 number. Concretely, upon change of the external IP address (and/ 118 or external port number), the DDNS client must refresh the DNS 119 records otherwise the server won't be reachable from outside. 120 This issue is exacerbated in the DS-Lite context because no public 121 IPv4 address is assigned to the CPE. 123 1.2. Scope and Goals 125 This document describes some candidate solutions to resolve the 126 aforementioned issues with a particular focus on DS-Lite. These 127 solutions may also be valid for other address sharing schemes. 129 This document sketches deployment considerations based on the PCP 130 (Port Control Protocol, [RFC6887]). Note DDNS may be considered as 131 an implementation of the Rendezvous service mentioned in [RFC6887]. 133 Indeed, after creating an explicit mapping for incoming connections 134 using PCP, it is necessary to inform remote hosts about the IP 135 address, protocol, and port number for the incoming connection to 136 reach the services hosted behind a DS-Lite CGN. This is usually done 137 in an application-specific manner. For example, a machine hosting a 138 game server might use a rendezvous server specific to that game (or 139 specific to that game developer), a SIP phone would use a SIP proxy, 140 and a client using DNS-Based Service Discovery [RFC6763] would use 141 DNS Update [RFC2136][RFC3007], etc. PCP does not provide this 142 rendezvous function. 144 The rendezvous function may support IPv4, IPv6, or both. Depending 145 on that support and the application's support of IPv4 or IPv6, the 146 PCP client may need an IPv4 mapping, an IPv6 mapping, or both. An 147 example illustrating how the DDNS server may implement such a service 148 notification functionality if necessary is provided in Section 3. 150 This document does not specify any protocol extension, but instead it 151 focuses on the elaboration of the problem space and illustrate how 152 existing tools can be re-used to solve the problem for some 153 deployment contexts. Particularly, this document requires no changes 154 to PCP or dynamic updates in the standard domain name system 155 [RFC2136], but is rather an operational document to make the current 156 DDNS service providers be aware of the impacts and issues that the 157 IPv6 transitioning and IPv4 address sharing will bring to them, and 158 gives solutions address the forthcoming issues. The current DDNS 159 service providers usually employs a web-based form to maintain DDNS 160 service registration and updates. 162 Generic deployment considerations for DS-Lite, including B4 remote 163 management and IPv4 connectivity check, can be found in [RFC6908]. 164 This document complements [RFC6908] with deployment considerations 165 related to Rendezvous service maintenance. Additional PCP-related 166 deployment considerations are available at 167 [I-D.boucadair-pcp-deployment-cases]. 169 Solutions relying on DNS-based Service Discovery [RFC6763] or Apple's 170 Back to My Mac (BTMM) Service [RFC6281] are not considered in this 171 document. Moreover, this document does not assume that DDNS service 172 relies on [RFC2136]. 174 IPv4 addresses used in the examples are derived from the IPv4 block 175 reserved for documentation in [RFC6890]. DNS name examples follow 176 [RFC2606]. 178 2. Solution Space 180 2.1. Locate a Service Port 182 As listed below, at least two solutions can be used to associate a 183 port number with a service: 185 1. Use service URIs (e.g., FTP, SIP, HTTP) which embed an explicit 186 port number. Indeed, Uniform Resource Identifier (URI) defined 187 in [RFC3986] allows to carry port number in the syntax (e.g., 188 mydomain.example:15687). 190 2. Use SRV records [RFC2782]. Unfortunately, the majority of 191 browsers do not support this record type. 193 DDNS client and DDNS server are to be updated so that an alternate 194 port number is signaled and stored by the DDNS server. Requesting 195 remote hosts will be then notified with the IP address and port 196 number to reach the server. 198 2.2. Create Explicit Mappings for Incoming Connections 200 PCP is used to install the appropriate mapping(s) in the CGN so that 201 incoming packets can be delivered to the appropriate server. 203 2.3. Detect Changes 205 In a network described in Figure 1, DDNS client/ PCP client can 206 either be running on a Customer Premise Equipment (CPE) or be running 207 on the host that is hosting some services itself. There are several 208 possible ways to address the problems stated in Section 1.1: 210 1. If the DDNS client is enabled, the host issues periodically 211 (e.g., 60 minutes) PCP MAP requests (e.g., messages 1 and 2 in 212 Figure 1) with short lifetime (e.g., 30s) for the purpose of 213 enquiring external IP address and setting. If the purpose is to 214 detect any change of external port, the host must issues a PCP 215 mapping to install a mapping for the internal server. Upon 216 change of the external IP address, the DDNS client updates the 217 records accordingly (e.g., message 3 in Figure 1). 219 2. If the DDNS client is enabled, it checks the local mapping table 220 maintained by the PCP client. This process is repeated 221 periodically (e.g., 5 minutes, 30 minutes, 60 minutes). If there 222 is no PCP mapping created by PCP client, it issues a PCP MAP 223 request (e.g., messages 1 and 2 in Figure 1) for the purpose of 224 enquiring external IP address and setting up port forwarding 225 mappings for incoming connections. Upon change of the external 226 IP address, the DDNS client updates the records in the DDNS 227 server, e.g., message 3 in Figure 1. 229 +-----------------+ 230 | DDNS Server | 231 +-----------------+ 232 ^ 233 | 234 |3. DDNS updates 235 | (if any) 236 | 237 +---------------+ +-----------------+ 238 |DDNS Client |1. PCP MAP request | CGN/PCP Server | 239 |PCP Client/IWF |------------------->| (PCP mapping for|80:8080+------+ 240 |on CPE or |2. PCP MAP response | port forwarding)|<------|Client| 241 |the host itself|<-------------------| | +------+ 242 | |3. DDNS updates | | 243 | | (if any) | | 244 | |------------------->| | 245 +---------------+ +-----------------+ 247 Figure 1: Flow Chart 249 3. Some Deployment Solutions 251 3.1. Reference Topology 253 Figure 2 illustrates the topology used for the deployment solutions 254 elaborated in the following sub-sections. 256 +--------------+ +--------+ +---------+ +--------+ +-------+ 257 | Service | | DDNS | | CGN& | | PCP | |Servers| 258 | User |---| Server|----| PCP |---| Client |---| | 259 | | | | | Server | | /DDNS | | | 260 | | | | | | | client | | | 261 +--------------+ +--------+ +---------+ +--------+ +-------+ 262 A user DDNS Server AFTR B4(CPE) A host 264 From Internet behind B4 266 Figure 2: Implementation Topology 268 Figure 2 involves of the following entities: 270 o Servers: refer to the servers that are deployed in the DS-Lite 271 network, or more generally, an IP address sharing environment. 272 They are usually running on a host that has been assigned with a 273 private IPv4 address. Having created a proper mapping via PCP in 274 AFTR, these services have been made available to the Internet 275 users. The services may provide Web, FTP, SIP and other services 276 though these ones may not be able to been seen as using a well 277 known port from the outside anymore, in the IP address sharing 278 context. 280 o B4 (CPE): An endpoint of IPv4-in-v6 tunnel [RFC6333]. A PCP 281 client together with a DDNS client are running on it. After PCP 282 client establishes a mapping on the AFTR, an end user may register 283 its domain name and its external IPv4 address plus port number to 284 its DDNS service provider (DDNS server), manually or automatically 285 by DDNS client. Later, likewise, end users may manually or let 286 DDNS client on behalf of it, to automatically announce IP address 287 and/or port changes to the DDNS server. 289 o AFTR: Responsible for maintaining mappings between internal IPv4 290 Address plus port and external IPv4 address plus port [RFC6333]. 292 o DDNS server: Maintains a table that associates a registered domain 293 name and a pair of registered host's external IPv4 address plus 294 port number. When being notified IP address and port number 295 changes from DDNS client, DDNS server announces the updates to DNS 296 servers on behalf of end user. [RFC2136] and [RFC3007] may be 297 used by DDNS server to send updates to DNS servers. In many 298 current practices, DDNS server provider usually announce its own 299 IP address as the registered domain names of end users. When HTTP 300 requests reach the DDNS server, they may employ URL Forwarding or 301 HTTP 301 redirection to redirect the request to a proper 302 registered end user by looking up the maintained link table. 304 o Service users: refers to users who want to access services behind 305 an IP address sharing network. They issue standard DNS requests 306 to locate the services, which will lead them to a DDNS server, 307 provided that the requested services have been registered to a 308 DDNS service provider. The DDNS server will then handle the rest 309 in the way as described before. 311 3.2. For Web Service 313 Current DDNS server implementations typically assume that the end 314 servers host web server on the default 80 port. In the DS-Lite 315 context, they will have to take into account that external port 316 assigned by AFTR may be any number other than 80, in order to 317 maintain proper mapping between domain names and external IP plus 318 port. By doing such changes, the HTTP request would be redirected to 319 the AFTR which servers the specific end host that are running 320 servers. 322 Figure 3 depicts how messages are handled in order to be delivered to 323 the right server. 325 Web Visitor DDNS server AFTR B4(CPE) Web Server 326 behind B4 327 | HTTP Get* | | | | 328 |---------------------->| | | | 329 | ip_DDNS_server |------------->| | | 330 | | HTTP 301 | | | 331 | |<-------------| | | 332 | HTTP Get* ip_aftr:8001 | | | 333 |------------------------------------->| | 334 | | HTTP Get* ip_websrv:8000 | 335 | |------------------------->| 336 | | | 337 | HTTP response | HTTP response | 338 |<-------------------------------------|--------------------------| 339 | | | 341 Figure 3: Http Service Messages 343 When a web user sends out a HTTP GET message to DDNS server after a 344 standard DNS query, DDNS server redirects the request to a registered 345 web server, in this case, by responding with a HTTP 301 message. 346 Then, the HTTP GET message will be sent out to the AFTR, which will 347 in turn finds the proper hosts behind it. For simplicity, messages 348 among AFTR, B4 and web server behind B4 are not shown completely; for 349 communications among those nodes, refer to [RFC6333]. 351 3.3. For Non-web Service 353 For non-web services, as mentioned in Section 2, other means will be 354 needed to inform the users about the service information. 356 [RFC6763] includes an example of DNS-based solution which allows an 357 application running in the end user's device to retrieve service- 358 related information via DNS SRV/TXT records, and list available 359 services. In a scenario where such application is not applicable, 360 following provides another solution for a third party, e.g., DDNS 361 service provider, to disclose services to the Internet users. 363 A web portal can be used to list available services. DDNS server 364 maintains a web portal for each user FQDN (Fully Qualified Domain 365 Name), which provides users service links. Figure 4 assumes 366 "websrv.example.com" is a user's FQDN provided by a DDNS service 367 provider. 369 +-------------+ +-------------+ +----------+ Internet +-------+ 370 |DDNS client /| |DDNS server /| |DNS server| |Visitor| 371 | Web Server | | web portal | | | | | 372 +-------------+ +-------------+ +----------+ +-------+ 373 | register | | | 374 |<------------------>| | | 375 | websrv.example.com | update DNS | | 376 | 192.0.2.1:2000 | <-------------> | | 377 | |websrv.example.com| | 378 | | portal's IP | | 379 | +-------------+ | | 380 | |update portal| | | 381 | +-------------+ | DNS resolve for | 382 | | | <----------------> | 383 | | | websrv.example.com | 384 | | | get portal's IP | 385 | | | | 386 | | visit portal of websrv.example.com | 387 | | <----------------------------------> | 388 | | | | 389 | visit http://192.0.2.1:2000 | 390 | <-------------------------------------------------------->| 391 | | | | 393 Figure 4: Update Web Portal 395 The DDNS client registers the servers' information to the DDNS 396 server, including public IP address and port obtained via PCP, user's 397 FQDN and other necessary information. The DDNS server also behaves 398 as portal server, it registers its IP address, port number, and 399 user's FQDN to the DNS system, so that visitors can access the web 400 portal. 402 DDNS server also maintains a web portal for each user's FQDN, update 403 the portal according to registered information from DDNS client. 404 When a visitor accesses "websrv.example.com", a DNS query will 405 resolve to portal server's address, port number, and the visitor will 406 see the portal and the available services. 408 +-------------------------------------------------------------+ 409 | | 410 | Portal: websrv.example.com | 411 | | 412 | Service1: web server | 413 | Link: http://192.0.2.1:2000 | 414 | | 415 | Service2: video | 416 | Link: rtsp://192.0.2.1:8080/test.sdp | 417 | | 418 | ...... | 419 | | 420 +-------------------------------------------------------------+ 422 Figure 5: An Example of Web Portal 424 As shown in Figure 5, the web portal shows the service URLs that are 425 available to be accessed. Multiple services are accessible per 426 user's FQDN. 428 Some applications which are not HTTP-based can also be delivered 429 using this solution. When a user clicks on a link, the registered 430 application in the client OS will be invoked to handle the link. How 431 this can be achieved is out of the scope of this document. 433 4. Security Considerations 435 This document does not introduce a new protocol nor specify protocol 436 extensions. Security-related considerations related to PCP [RFC6887] 437 and DS-Lite [RFC6333] should be taken into account. 439 The protocol between the DDNS client and DDNS server is proprietary 440 in most cases, some extensions may be necessary, which is up to DDNS 441 operators. These operators should enforce security-related policies 442 to avoid that illegitimate users alter records installed by 443 legitimate users or install fake records that would lead to attract 444 illegitimate traffic. Means to protect the DDNS server against DoS 445 (Denial of Service) should be enabled. Note these considerations are 446 not specific to address sharing contexts but are valid for DDNS 447 service in general. 449 5. IANA Considerations 451 This document does not require any action from IANA. 453 6. Contributors 455 The following individuals contributed text to the document: 457 Xiaohong Huang 459 Beijing University of Posts and Telecommunications, China 460 Email: huangxh@bupt.edu.cn 462 Yan Ma 464 Beijing University of Posts and Telecommunications, China 465 Email: mayan@bupt.edu.cn 467 7. Acknowledgements 469 Thanks to Stuart Cheshire for bringing up DNS-Based Service Discovery 470 and [RFC6281] where covers DNS-based SD scenario and gives an example 471 of how the application means of solution to address dynamic DNS 472 update, in this case, apple' BTMM, can be achieved. 474 Many thanks to D. Wing, D. Thaler, and J. Abley for their 475 comments. 477 8. References 479 8.1. Normative References 481 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 482 Resource Identifier (URI): Generic Syntax", STD 66, RFC 483 3986, January 2005. 485 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 486 Stack Lite Broadband Deployments Following IPv4 487 Exhaustion", RFC 6333, August 2011. 489 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 490 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 491 2013. 493 8.2. Informative References 495 [I-D.boucadair-pcp-deployment-cases] 496 Boucadair, M., "Port Control Protocol (PCP) Deployment 497 Models", draft-boucadair-pcp-deployment-cases-02 (work in 498 progress), April 2014. 500 [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, 501 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 502 RFC 2136, April 1997. 504 [RFC2606] Eastlake, D. and A. Panitz, "Reserved Top Level DNS 505 Names", BCP 32, RFC 2606, June 1999. 507 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 508 specifying the location of services (DNS SRV)", RFC 2782, 509 February 2000. 511 [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic 512 Update", RFC 3007, November 2000. 514 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 515 NAT64: Network Address and Protocol Translation from IPv6 516 Clients to IPv4 Servers", RFC 6146, April 2011. 518 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 519 Roberts, "Issues with IP Address Sharing", RFC 6269, June 520 2011. 522 [RFC6281] Cheshire, S., Zhu, Z., Wakikawa, R., and L. Zhang, 523 "Understanding Apple's Back to My Mac (BTMM) Service", RFC 524 6281, June 2011. 526 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 527 Discovery", RFC 6763, February 2013. 529 [RFC6888] Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 530 and H. Ashida, "Common Requirements for Carrier-Grade NATs 531 (CGNs)", BCP 127, RFC 6888, April 2013. 533 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 534 "Special-Purpose IP Address Registries", BCP 153, RFC 535 6890, April 2013. 537 [RFC6908] Lee, Y., Maglione, R., Williams, C., Jacquenet, C., and M. 538 Boucadair, "Deployment Considerations for Dual-Stack 539 Lite", RFC 6908, March 2013. 541 Authors' Addresses 543 Xiaohong Deng 545 Email: dxhbupt@gmail.com 546 Mohamed Boucadair 547 France Telecom 548 Rennes 35000 549 France 551 Email: mohamed.boucadair@orange.com 553 Qin Zhao 554 Beijing University of Posts and Telecommunications 555 China 557 Email: zhaoqin.bupt@gmail.com 559 James Huang 560 Huawei Technologies 561 China 563 Email: james.huang@huawei.com 565 Cathy Zhou 566 Huawei Technologies 567 China 569 Email: cathy.zhou@huawei.com