idnits 2.17.1 draft-deng-pcp-ddns-05.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 seems to lack an Introduction section. ** There are 6 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 98: '...The DDNS service MUST be able to maint...' RFC 2119 keyword, line 102: '... sharing device MUST be supported....' RFC 2119 keyword, line 104: '... DDNS client MUST be triggered by ...' RFC 2119 keyword, line 106: '... the DDNS client MUST refresh the DNS ...' RFC 2119 keyword, line 189: '...irst of all, PCP MUST be used to insta...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 19, 2014) is 3690 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DNSOP Working Group X.Deng 2 Internet Draft M.Boucadair 3 Intended status: Informational France Telecom 4 Expires: September 20, 2014 Q.Zhao 5 BUPT 6 J.Huang 7 C.Zhou 8 Huawei 9 March 19, 2014 11 Using PCP to update dynamic DNS 12 draft-deng-pcp-ddns-05.txt 14 Abstract 16 This document focuses on the problems encountered when using dynamic 17 DNS in address sharing contexts (e.g., DS-Lite, NAT64) during IPv6 18 transition. Issues and possible solutions are documented in this memo. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 16, 2013. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Problem Statement ........................................... 2 55 2. Solution Space .............................................. 4 56 2.1. Locate a Service Port .................................. 4 57 2.2. Detect Changes ......................................... 4 58 3. Possible Solutions .......................................... 6 59 3.1. Topology ............................................... 6 60 3.2. For Web Service ........................................ 7 61 3.3. For Non-web Service .................................... 8 62 4. Security Considerations ..................................... 9 63 5. IANA Considerations ........................................ 10 64 6. Additional Authors' Addresses .............................. 10 65 7. Acknowledgments ............................................ 10 66 8. References ................................................. 10 67 8.1. Normative References................................... 10 68 8.2. Informative References ................................ 11 69 9. Authors' Addresses ......................................... 12 71 1. Problem Statement 73 Dynamic DNS (DDNS) is a widely deployed service to facilitate hosting 74 servers (e.g., to host webcam and http server) at premises. There are 75 a number of providers who offer a DDNS service, working in a client 76 and server mode, which mostly use a web-form based communication. 77 DDNS clients are generally implemented in the user's router or 78 computer, which once detects changes to its IP address it 79 automatically sends an update message to the DDNS server. The 80 communication between the client and the server is not standardized, 81 varying from one provider to another, although a few standard web- 82 based methods of updating emerged over time. 84 When the network architecture evolves towards an IPv4 sharing 85 architecture during IPv6 transition, the DDNS Client will have to not 86 only inform the IP address updates if any, but also to notify the 87 changes of external port on which the service is listening, because 88 well known port numbers, e.g. port 80 will no longer be available to 89 every web server. It will also require the ability to configure 90 corresponding port forwarding on CGN devices, so that incoming 91 communications initiated from outside can be routed to the 92 appropriate server behind the CGN. 94 This document focuses on the problems encountered when using dynamic 95 DNS in address sharing contexts (e.g., DS-Lite, NAT64). Below are 96 listed the main challenges: 98 (1) The DDNS service MUST be able to maintain an alternative port 99 number instead of the default port number. 101 (2) Appropriate means to instantiate port mapping in the address 102 sharing device MUST be supported. 104 (3) DDNS client MUST be triggered by the change of the external IP 105 address and the port number. Concretely, upon change of the external 106 IP address, the DDNS client MUST refresh the DNS records otherwise 107 the server won't be reachable from outside. This issue is exacerbated 108 in the DS-Lite context because no public IPv4 address is assigned to 109 the CPE. 111 This document describes solutions to resolve issues listed above in 112 the particular case of DS-Lite. 114 Note DDNS may be considered as an implementation of the Rendezvous 115 service mentioned in [RFC6887]. 117 After creating a mapping for incoming connections, it is necessary to 118 inform remote computers about the IP address, protocol, and port for 119 the incoming connection to reach the services hosted behind a DS-Lite 120 CGN. This is usually done in an application-specific manner. For 121 example, a computer game might use a rendezvous server specific to 122 that game (or specific to that game developer), a SIP phone would use 123 a SIP proxy, and a client using DNS-Based Service Discovery [RFC6763] 124 would use DNS Update [RFC2136][RFC3007]. PCP does not provide this 125 rendezvous function. RFC6281 shows an good example of how to use the 126 DNS-Based Service Discovery to make the service announcement 127 available, in an application manner. The rendezvous function may 128 support IPv4, IPv6, or both. Depending on that support and the 129 application's support of IPv4 or IPv6, the PCP client may need an 130 IPv4 mapping, an IPv6 mapping, or both. In the solution section, it 131 gives an example how the DDNS server may implement such a service 132 notification functionality if necessary. 134 This document requires no changes to PCP protocol or dynamic updates 135 in the standard domain name system [RFC2136], but is rather an 136 operational document to make the current DDNS service providers be 137 aware of the impacts and issues that the IPv6 transitioning and IPv4 138 address sharing will bring to them, and gives solutions address the 139 forthcoming issues. The current DDNS service providers usually 140 employs a web-based form to maintain DDNS service registration and 141 updates. For DNS-based Service Discovery, or DNS-SD and updates, 142 [RFC6763] intensively describes how to use DNS resource records and 143 standard DNS queries to facilitate service discovery, and [RFC6281] 144 elaborates an implementation of it with an Apple's Back to My Mac 145 (BTMM) Service. 147 2. Solution Space 149 2.1. Locate a Service Port 151 At least two solutions can be used to associate a port number with a 152 service identified: 154 (1) Use service URIs (e.g., FTP, SIP, HTTP) which embed an explicit 155 port number. Indeed, Uniform Resource Identifier (URI) defined in 156 [RFC3986] allows to carry port number in the syntax (e.g., 157 mydomain.example:15687) 159 (2) Use SRV records. Unfortunately, the majority of browsers do not 160 support this record type. 162 DDNS client and server are to be updated so that an alternative port 163 number is also signaled and stored by the server. Requesting remote 164 hosts will be then notified with the IP address and port number to 165 reach the server. 167 2.2. Detect Changes 168 +-----------------+ 169 | DDNS Server | 170 | | 171 +-----------------+ 172 ^ 173 | 174 |3. DDNS updates 175 | (if any) 176 | 177 +---------------+ +-----------------+ 178 |DDNS Client |1. PCP MAP request | CGN/PCP Server | 179 |PCP Client/IWF |------------------->| (PCP mapping for|80:8080+------+ 180 |ON CPE or |2. PCP MAP response | port forwarding)|<------|Client| 181 |the host itself|<-------------------| | | | 182 | |3. DDNS updates | | +------+ 183 | | (if any) | | 184 | |------------------->| | 185 +---------------+ +-----------------+ 187 Figure 1 : Flow Chart 189 First of all, PCP MUST be used to install the appropriate mapping in 190 the CGN so that incoming packets can be delivered to the appropriate 191 server. 193 In a network described in figure 1, DDNS Client/ PCP Client can 194 either be running on a Customer Premise Equipment (CPE) or be running 195 on the host that is hosting some services itself. There are several 196 possible ways to address the problems stated in section 1. 198 (1) If the DDNS client is enabled, the host issues periodically (e.g., 199 1h) PCP MAP requests (e.g., messages 1 and 2 in Figure 1) with short 200 lifetime (e.g., 30s) for the purpose of enquiring external IP address 201 and setting. If the purpose is to detect any change of external port, 202 the host must issues a PCP mapping to install a mapping for the 203 internal server. Upon change of the external IP address, the DDNS 204 client updates the records (e.g., message 3 in Figure 1). 206 (2) If the DDNS client is enabled, it checks the local mapping table 207 maintained by the PCP client. This process is repeated periodically 208 (e.g., 5mn, 30mn, 1h). If there is no PCP mapping created by PCP 209 client, it issues a PCP MAP request (e.g., messages 1 and 2 in Figure 210 1) for the purpose of enquiring external IP address and setting up 211 port forwarding mappings for incoming connections. Upon change of the 212 external IP address, the DDNS client updates the records in the DDNS 213 server, e.g., message 3 in Figure 1. 215 3. Possible Solutions 217 3.1. Topology 219 +--------------+ +--------+ +---------+ +--------+ +-------+ 220 | Service | | DDNS | | CGN& | | PCP | |Servers| 221 | User |---| Server|----| PCP |---| Client |---| | 222 | | | | | Server | | /DDNS | | | 223 | | | | | | | client | | | 224 +--------------+ +--------+ +---------+ +--------+ +-------+ 225 A user DDNS Server AFTR B4(CPE) A host 226 From Internet behind B4 228 Figure 2 : Implementation Topology 230 Servers: Servers that are deployed in the DS-Lite network, or more 231 generally, an IP address sharing environment. They are usually 232 running on a host that has been assigned with a private IPv4 address. 233 Having created a proper mapping via PCP in AFTR, these services have 234 been made available to the internet users. The services may provide 235 Web, FTP, SIP and other services though these ones may not be able to 236 been seen as using a well known port from the outside anymore, in the 237 IP address sharing context. 239 B4 (CPE): An endpoint of IPv4-in-v6 tunnel. A PCP client together 240 with a DDNS client are running on it. After PCP client establishes a 241 mapping on the AFTR, an end user may register its domain name and its 242 external IPv4 address plus port number to its DDNS service provider 243 (DDNS server), manually or automatically by DDNS client. Later, 244 likewise, end users may manually or let DDNS client on behalf of it, 245 to automatically announce IP and port changes to the DDNS server. 247 AFTR: Responsible for maintaining mappings between internal IPv4 248 Address plus port and external IPv4 address plus port. 250 DDNS server: Maintains a table linking a registered domain name and a 251 pair of registered host's external IPv4 address plus port number. 252 When being notified IP address and port number changes from DDNS 253 client, DDNS server then announces the updates to DNS servers on 254 behalf of end user. RFC 2136 and RFC 2137 may be used by DDNS server 255 to send updates to DNS servers. In many current practices, DDNS 256 server provider usually announce its own IP address as the registered 257 Domain names of end users. When Http requests reach the DDNS server, 258 they may employ URL Forwarding or HTTP 301 redirection to redirect 259 the request to a proper registered end user by looking up the 260 maintained link table. 262 Service users: Users who want to access services behind an IP address 263 sharing network. They send out standard DNS requests to locate the 264 services, which will lead them to a DDNS server, provided that the 265 requested services have been registered to a DDNS service provider. 266 Then the DDNS server will handle the rest in the way as described 267 before. 269 3.2. For Web Service 271 Current DDNS server implementations typically assume that the end 272 servers host web server on the default 80 port. In the DS-Lite 273 context, they will have to take into account that external port 274 assigned by AFTR may be any number other than 80, in order to 275 maintain proper mapping between domain names and external IP plus 276 port. By doing such changes to implementation, the HTTP request would 277 be redirected to the AFTR which servers the specific end host that 278 are running servers. The following chart shows how the messages reach 279 the right server. 281 Web Visitor DDNS server AFTR B4(CPE) Web Server 282 behind b4 283 | HTTP Get* | | | | 284 |---------------------->| | | | 285 | ip_DDNS_server |--------------->| | | 286 | | HTTP 301 | | | 287 | |<---------------| | | 288 | HTTP Get* ip_aftr:8001 | | | 289 |--------------------------------------->| | 290 | | HTTP Get* ip_websrv:8000 | 291 | |------------------------->| 292 | | | 293 | HTTP response | HTTP response | 294 |<---------------------------------------|--------------------------| 296 Figure 3 Http Service Messages 298 When a web user sends out a HTTP GET message to DDNS server after a 299 standard DNS query, DDNS server redirects the request to a registered 300 web server, in this case, by responding with a HTTP 301 message. Then 301 the HTTP GET message will be sent out to the AFTR, which will in turn 302 finds the proper hosts behind it. For simplicity, messages among AFTR, 303 B4 and web server behind b4 are not shown completely; for 304 communications among those nodes, please refer to [RFC6333]. 306 3.3. For Non-web Service 308 For non-web services, as mentioned in Section 2, other means will be 309 needed to inform the users about the service information. 311 [RFC6763] shows an good example of DNS based solution to do so, in 312 which case an application running in the end user's device will 313 retrieve service information via DNS SRV/TXT records, and list 314 available services. In a scenario where such application is not 315 applicable, following provides another means for a third party, e.g. 316 DDNS service provider, to disclose services to the Internet users. 318 A web portal can be used to list available services. DDNS server 319 maintains a web portal for each user FQDN, which provides a users 320 service links. In the figure below, it assumes websrv.myip.org is a 321 user's FQDN provided by a DDNS service provider. 323 +-------------+ +-------------+ +----------+ Internet +-------+ 324 |DDNS client /|----|DDNS server /|----|DNS server|----------|Visitor| 325 | Web Server | | web portal | | | | | 326 +-------------+ +-------------+ +----------+ +-------+ 327 | register | | | 328 |<------------------> | | | 329 | websrv.myip.org | update DNS | | 330 | 100.1.1.2:2000 | <-------------> | | 331 | | websrv.myip.org | | 332 | | portal's IP | | 333 | +-------------+ | | 334 | |update portal| | | 335 | +-------------+ | DNS resolve for | 336 | | | <----------------> | 337 | | | websrv.myip.org | 338 | | | get portal's IP | 339 | | | | 340 | | visit portal of websrv.myip.org | 341 | | <----------------------------------> | 342 | | | | 343 | visit http://100.1.1.2:2000 | 344 | <--------------------------------------------------------> | 346 Figure 4 Update Web Portal 348 The DDNS client registers the servers' information to the DDNS server, 349 including public IP address and port obtained via PCP, user's FQDN 350 and other necessary information. The DDNS server also works as portal 351 server, it registers its IP address and user's FQDN to the DNS system, 352 so that visitors can visit the web portal. 354 DDNS server also maintains a web portal for each user's FQDN, update 355 the portal according to registered information from DDNS client. When 356 a visitor visits websrv.myip.org, DNS query will resolve to portal 357 server's address, and the visitor will see the portal and the 358 available services. 360 +-------------------------------------------------------------+ 361 | | 362 | Portal of websrv.myip.org | 363 | | 364 | Service1: web server | 365 | Link: http://100.1.1.2:2000 | 366 | | 367 | Service2: video | 368 | Link: rtsp://100.1.1.2:8080/test.sdp | 369 | | 370 | ...... | 371 | | 372 +-------------------------------------------------------------+ 374 Figure 5 An Example of Web Portal 376 The web portal in the above figure shows service links that are 377 available to be accessed. Multiple services is accessible per user's 378 FQDN. Some applications which are not http based can also be 379 supported via this solution. When user click a link, the registered 380 application in the client OS will be invoked to handle the link. How 381 this can be achieved is out of the scope of this document. 383 4. Security Considerations 385 This memo does not introduce a new protocol, but makes use of 386 existing protocols, including PCP, DNS, HTTP redirect. The protocol 387 between the DDNS client and server is proprietary in most cases, some 388 extension may be necessary, which is up to DDNS operators. 390 5. IANA Considerations 392 This draft does not request any action from IANA. 394 6. Additional Authors' Addresses 396 This work is made available also from additional authors' 397 contribution and work. 399 Xiaohong Huang 401 Beijing University of Posts and Telecommunications, China 402 Email: huangxh@bupt.edu.cn 404 Yan Ma 406 Beijing University of Posts and Telecommunications, China 407 Email: mayan@bupt.edu.cn 409 7. Acknowledgments 411 Thanks to Stuart Cheshire for bringing up DNS-Based Service Discovery 412 and RFC6281 where covers DNS-based SD scenario and gives a good 413 example of how the application means of solution to address dynamic 414 DNS update, in this case, apple' BTMM, can be achieved. 416 8. References 418 8.1. Normative References 420 [RFC2136] 422 P. Vixie, et. al." Dynamic Updates in the Domain Name 423 System (DNS UPDATE)", April 1997. 425 [RFC3007] 427 B. Wellington, " Secure Domain Name System (DNS) Dynamic 428 Update", November 2000. 430 [RFC3986] 432 T. Berners-Lee, et. al. " Uniform Resource Identifier (URI): 433 Generic Syntax", January 2005. 435 [RFC6281] 437 S. Cheshire, et. Al. " Understanding Apple's Back to My Mac 438 (BTMM) Service", June 2011. 440 [RFC6333] 442 A. Durand, et. Al. " Dual-Stack Lite Broadband Deployments 443 Following IPv4 Exhaustion", August 2011. 445 8.2. Informative References 447 [RFC6887] 449 D. Wing, et. al. " Port Control Protocol (PCP)", April 2013. 451 [RFC6763] 453 S. Cheshire, et. al. " DNS-Based Service Discovery ", 454 February 2013 456 9. Authors' Addresses 458 Xiaohong Deng 459 France Telecom 460 Rennes,35000 France 461 Email: dxhbupt@gmail.com 463 Mohamed BOUCADAIR 464 France Telecom 465 Rennes,35000 France 467 Email: mohamed.boucadair@orange.com 469 Qin Zhao 470 Beijing University of Posts and Telecommunications, China 471 Email: zhaoqin.bupt@gmail.com 473 James Huang 474 Huawei Technologies 475 Email: james.huang@huawei.com 477 Cathy Zhou 478 Huawei Technologies 479 Email: cathy.zhou@huawei.com