idnits 2.17.1 draft-cao-homenet-mif-srvdis-00.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 : ---------------------------------------------------------------------------- ** There are 14 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2013) is 3840 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-11) exists of draft-ietf-mif-happy-eyeballs-extension-03 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-10 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Z. Cao 3 Internet-Draft China Mobile 4 Intended status: Informational A. Ding 5 Expires: April 24, 2014 Cambridge University / Helsinki University 6 October 21, 2013 8 Service Discovery in the Homenet Environment with Multiple Connections 9 draft-cao-homenet-mif-srvdis-00 11 Abstract 13 This document analyzes the problems of service discovery in a homenet 14 multiple connection environment. A multiple connection environment 15 consists of multiple-interfaced nodes connecting to multiple networks 16 or multiple provisioning domains. Given a type of service a 17 multiple-interfaced client is looking for, the discovery progress 18 ought to return a correct pointer to the service instance that the 19 client is able to access without trying every available channel. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 24, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Requirements and Terminology . . . . . . . . . . . . . . . . 3 57 2.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3.1. Mif Scenario . . . . . . . . . . . . . . . . . . . . . . 3 61 3.2. Homenet Scenario . . . . . . . . . . . . . . . . . . . . 5 62 4. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . 5 63 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 65 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. Normative References . . . . . . . . . . . . . . . . . . 9 67 7.2. Informative References . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 A multihomed host has multiple provisioning domains via physical and/ 73 or virtual interfaces. A multihomed host receives node configuration 74 information from each of its access networks, through various 75 mechanisms such as DHCP, PPP and IPv6 Router Advertisements. When 76 the received node-scoped configuration objects have different values 77 from each administration domains, such as different DNS servers IP 78 addresses, different default gateways or different address selection 79 policies, the node has to decide which it will use or how it will 80 merge them. 82 Issues regarding how the multi-homed host uses the configuration 83 objects have been addresses in [RFC6418]. Current practices of how 84 the various implementations handle these problems are introduced in 85 [RFC6419]. [RFC6731] extends DHCPv6 to inform the host which DNS 86 server it ought to select to send the query request, and DNS based 87 Service Discovery (DNS-SD) has been specified in [RFC6763]. 89 This document analyzes the problem of service discovery in a multiple 90 connection environment. A multiple connection environment consists 91 of multiple-interfaces nodes connecting to multiple networks or 92 multiple provisioning domains. Given a type of service a multiple- 93 interfaced client is looking for, the discovery progress ought to 94 return a correct pointer to the service instance that the a client is 95 able to access. 97 2. Requirements and Terminology 99 2.1. Requirements 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 2.2. Terminology 107 Service Domain 109 A set of services that can be accessed by users. Besides 110 providing services, a service domain is responsible for delivering 111 configuration and pointers that ensure a guaranteed service 112 access. 114 Service Discovery 116 Procedure to acquire information that is necessary to access 117 service. 119 Multiple Connection Environment 121 Consists of multiple-interfaced nodes that connect to multiple 122 networks or multiple provisioning domains. 124 3. Scenarios 126 We describe two scenarios in this section, one related to Multiple 127 Interfaces, and the other one related to Home Networks (homenet). 129 3.1. Mif Scenario 131 The service discovery process can be summarized as the following five 132 steps. 134 1. Service Discovery Preparation: the host determines which 135 interface it should send a query request based on the 136 configuration information. 138 2. Service Query Request: the host sends a query request to find a 139 service. The query should include a description of the service, 140 for example, a full-qualified domain name, a URI, or an 141 application-specific naming of the service. 143 3. Service Request Handling: any entity that receives the query 144 request should handle the request. The entity should understand 145 the meaning of the request, and check the semantics of the 146 request language before giving an answer back. 148 4. Service Query Response: the entity that receives the query 149 request should reply with an answer to the query. The answer 150 should include a pointer to the service. 152 5. Service Access: the host accesses the service via the pointer 153 provided in the query response. The host is supposed to be able 154 to get the service instance via the pointer under a successful 155 and efficient service discovery mechanism, unless the servers in 156 such service domain encounter problems e.g. a web server is down. 158 Figure 1 shows a typical scenario for service discovery in a multiple 159 connection environment. It is common in today's mobile Internet that 160 a host is equipped with multiple network interfaces. On the service 161 domain, different services are deployed and some services may not be 162 accessible to a certain interface on the host due to security concern 163 or access policy. The connectivity each interface provides may not 164 be restricted to Internet access. For instance, WLAN and bluetooth 165 can offer direct access to potential services e.g. printers via local 166 ad-hoc connectivity. In such multiple connection environment, the 167 service discovery process should return a correct point to the host 168 and ensure that the host can access the service via this pointer. 169 This situation makes the multiple interface service discovery 170 different from the typical one-interface Internet access scenario. 171 Furthermore, the growing usage of IPv6 in the homenet environment has 172 made service discovery more challenging that requires thorough 173 investigation. 175 +-------------------------------------------+ 176 | Host with multiple interfaces | 177 | | 178 | | 179 | +---+ +---+ +---+ ... +---+ | 180 | | | | | | | ... | | | 181 +-----+--------+--------+-------------+-----+ 182 | | | | 183 3G WLAN__ Bluetooth ... Wired 184 / \________ \__ \ 185 / \____ \ \ 186 ---------------------------------------------------------------------- 187 +-+-+-+-+-+-+-+-+- +-+-+-+-+-+-+-+-+ Service Domain 188 ( Service ) ( Service ) 189 \________________/ \_______________/ 191 Figure 1: Multiple Interface Host with Multiple Available Services 193 3.2. Homenet Scenario 195 We also describe the issues related to the homenet architecture 196 [I-D.ietf-homenet-arch], as depicted in Figure 2. 198 Suppose one MIF host is connected to three domains: homenet domain, 199 3gpp domain and a WiFi or enterprise domain. There is one service 200 that is named with the private domain name, say 'temperature.ietf', 201 which is only resolvable via the domain name service residing inside 202 the homenet and is supported by the multicast dns service [RFC6762]. 204 There are several problems in this scenario. First of all, since the 205 host has two unicast dns domains configured over the 3GPP and WiFi, 206 and as well as a multicast service discovery domain within the 207 homenet, the host does not know which domain it should send a dns 208 resolution request. Secondly, even if coupled with the split dns 209 solution [RFC6731], the configuration information obtained from DHCP 210 supports only those two unicast dns domains, but not the homenet 211 domain which is normally considered as 'zero-configuration'. Third, 212 the service discovery problem will become more complicated if the 213 host is connecting to more than one home networks, i.e., multiple 214 multicast dns domains. 216 +--------------+ 217 | 3GPP Domain | 218 +--------------+ 219 | 220 +--------------+ +------+ | 221 |Homenet Domain|------| Host |-------------+ 222 +--------------+ +------+ | 223 | 224 +--------------+ 225 | Wi-Fi | 226 | Domain | 227 +--------------+ 229 Figure 2: Homenet Scenario 231 4. Problem Analysis 233 The problems that a multiple-interfaced host may meet during the 234 service discovery include: 236 1. How the query requests are sent? Because there are multiple 237 interfaces available and multiple service rendezvous existing, 238 the host should decide which destination it ought to send the 239 query to. And if there is a round-robin mechanism, the host 240 should determine the order of the query request. 242 2. How to handle the query and reply? Some pointers to the service 243 are restricted to a local scope or a certain interface, e.g., an 244 office printer may not be accessible to the 3G-interface. The 245 service discovery process is supposed to return a pointer that is 246 accessible to the host. 248 3. How to access the service? Given the pointer to the service, the 249 host should be able to determine from which interface it can 250 access the service. 252 The existing work of [RFC6418] and [RFC6419] have covered the general 253 problems encountered by hosts accessing multiple provisioning 254 domains, but the focus is on connectivity and configuration. 255 Proposal of Happy Eyeball in [I-D.ietf-mif-happy-eyeballs-extension] 256 allows a host with multiple interfaces to pick a suitable one for 257 access and enables automatic fallback. In a DNS based service 258 discovery [RFC6763], the problem of domain split is analyzed in the 259 [RFC6731]. The document defines an extension to the DHCPv4 and 260 DHCPv6 to inform the MIF host which domain scope the Recursive DNS 261 Server(RDNSS) is serving for, so that the "service query request" can 262 be sent to the correct RDNSS to get an answer. 264 The existing proposals resolve the partial problem in the service 265 discovery process mentioned above. To highlight the missing blocks, 266 Figure 3 provides a 'gap' analysis. In the figure, we compare three 267 existing solutions on service discovery, DNS-SD[RFC6763], DNS-Server- 268 Selection [RFC6731], and MIF Happy Eyeball 269 [I-D.ietf-mif-happy-eyeballs-extension], from three aspects as 270 mentioned above. The DNS-Srv-Sel solution uses the defined DHCP 271 option for the MIF host to select the corresponding DNS Server, and 272 MIF-HE inherits this method in its most updated version. The MIF-HE 273 can help host failover to the workable interface during service 274 access while DNS-Srv-Sel does not handle this particular issue. The 275 DNS-SD is not designed for a multiple interfaces environment and DNS 276 server selection and request handling are based on standard DNS 277 behaviors. 279 +-------------+----------------+----------------+----------------+ 280 |Aspects \Sol | DNS-SD | DNS-Srv-Sel | MIF-HE | 281 +-------------+----------------+----------------+----------------+ 282 |How to | Std. DNS | DHCP Option | Same as | 283 |Send Query | behavior | informed | DNS-Srv-Sel | 284 +-------------+----------------+----------------+----------------+ 285 |How to Handle| Std. DNS server| selection based| Same as | 286 |Queries | behavior | on option | DNS-Srv-Sel | 287 +-------------+----------------+----------------+----------------+ 288 |How to Access|no guarantee | not possible if| Failover to the| 289 |service |of connectivity | ports rejected | Happiest one | 290 +-------------+----------------+----------------+----------------+ 292 Figure 3: Gap Analysis of Existing Service Discovery Methods 294 In a complicated network as shown in Figure 4 , the host connects to 295 the enterprise network via the wired interface, a WLAN network with 296 the 802.11 interface, and an operator's network via the cellular 297 interface. The three intranets have their own Firewall policies to 298 the global Internet. On the enterprise network, many outgoing ports 299 are restricted, and on the WLAN and operator's public network, there 300 is more freedom. If the MIF host makes a DNS-SRV query to a service 301 in a global domain, all the RDNS servers have the corresponding 302 records. But say the service port number has been blocked by the 303 enterprise network administrator, the DNS has no such information. 304 Even if the DNS returns a pointer to the MIF host, the MIF host 305 cannot access this service via the wired interface. 307 +---------------+ 308 | RDNSS with | | Enterprise 309 +------+ | public + |----| Intranet 310 | | | enterprise's | | 311 | |------Wired -----| private names | | 312 | | +---------------+ +----------+----+ 313 | | | FW | 314 | | +----+ 315 | MIF | +---------------+ +----+ | 316 | node |----- WLAN ------| RDNSS with |--| FW |-----| Public 317 | | | public names | +----+ | Internet 318 | | +---------------+ | 319 | | +----+ 320 | | | FW | 321 | | +---------------+ +----------+----+ 322 | |---- Cellular ---| RDNSS with | | 323 +------+ | public + | | Operator 324 | operator's |----| Intranet 325 | private names | | 326 +---------------+ 328 Figure 4: Scenario of Multiple Interface DNS Service Discovery 330 CoAP [I-D.ietf-core-coap] is an IETF designed RESTful protocol for 331 constrained environment. CoAP defines a link-format for service 332 discovery of the particular CoAP server, i.e., "/.well-known/core". 333 If the CoAP client has multiple access networks as shown in Figure 5, 334 the situation turns to be more complex. For instance, if the MIF 335 client wants to find a humidity sensing resource, but does not know 336 which domain contains the information, it basically needs to send 337 multiple CoAP GET requests with the well-known URL. Once it gets a 338 response for the required resource, it can send the corresponding 339 request to get the information. However this way is sub-optimal 340 especially for constrained devices. MIF service discovery SHOULD 341 consider the efficiency of the service discovery process. 343 +---------------+ +--------+ +----------+ 344 | Internal |________| MIF |__________| External | 345 | Domain | | Host | | Domain | 346 +---------------+ +--------+ +----------+ 347 | GET /.well-known/core | | 348 |<------------------------| GET /.well-known/core | 349 | |----------------------->| 350 | ACK CON | ACK CON | 351 |------------------------>|<-----------------------| 352 | | GET ~/hum | 353 | |----------------------->| 355 Figure 5: CoAP Service Discovery for a MIF Host 357 As a summary of the above analysis, the general problems and 358 requirements of service discovery in a MIF environment can be 359 summarized as follows: 361 Service Directory Service Configuration: Service directory is the 362 entity that stores or can get the stored relationship between 363 service names and service pointers. Different interfaces or 364 provisioning domains have their different service directories. 365 How to configure them on the MIF host and how the MIF host 366 utilizes the configured information are important for the service 367 discovery process to behave correctly. 369 Service Directory Selection: After the service directory 370 information is configured on the host, the host is able to select 371 the correct directory to send the query. The host can utilize 372 auxiliary information available or send the query to all the 373 directories that have been configured. The behavior of MIF host 374 to select a correct directory is also important for a stable 375 system. 377 Service Pointer/Address Resolution: The same service may have 378 different available addresses and pointers, and some service has 379 limited connectivity. So the resolution process should be able to 380 return to the MIF host a record that is accessible from at least 381 one of the interfaces. Efficiency SHOULD be taken into 382 consideration in this phase. 384 Service Route Selection: With the pointers returned, the host should 385 route the service level data to the service instance identified by 386 the returned pointers. 388 5. IANA Considerations 390 This document has no IANA requests. 392 6. Security Considerations 394 The query response exchanges should be protected by security 395 mechanisms. If the response contains invalid information, e.g. a 396 pointer to a worm website, it harms. As a consequence, the service 397 discovery should protect bogus information injected by attackers or 398 intruders. The security consideration ought to be made by the 399 underlining protocols, and it is out the scope of this problem 400 statement document. 402 7. References 404 7.1. Normative References 406 [I-D.ietf-mif-happy-eyeballs-extension] 407 Chen, G., Williams, C., Wing, D., and A. Yourtchenko, 408 "Happy Eyeballs Extension for Multiple Interfaces", draft- 409 ietf-mif-happy-eyeballs-extension-03 (work in progress), 410 August 2013. 412 [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved 413 Recursive DNS Server Selection for Multi-Interfaced 414 Nodes", RFC 6731, December 2012. 416 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 417 February 2013. 419 [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service 420 Discovery", RFC 6763, February 2013. 422 7.2. Informative References 424 [I-D.ietf-core-coap] 425 Shelby, Z., Hartke, K., and C. Bormann, "Constrained 426 Application Protocol (CoAP)", draft-ietf-core-coap-18 427 (work in progress), June 2013. 429 [I-D.ietf-homenet-arch] 430 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 431 "Home Networking Architecture for IPv6", draft-ietf- 432 homenet-arch-10 (work in progress), August 2013. 434 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 435 Requirement Levels", BCP 14, RFC 2119, March 1997. 437 [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and 438 Provisioning Domains Problem Statement", RFC 6418, 439 November 2011. 441 [RFC6419] Wasserman, M. and P. Seite, "Current Practices for 442 Multiple-Interface Hosts", RFC 6419, November 2011. 444 Authors' Addresses 446 Zhen Cao 447 China Mobile 448 Xuanwumenxi Ave. No. 32 449 Beijing 100871 450 China 452 Phone: +86-10-52686688 453 Email: zehn.cao@gmail.com, caozhen@chinamobile.com 455 Aaron Yi Ding 456 Cambridge University / Helsinki University 457 William Gates Building, 15 JJ Thomson Ave 458 CB3 0FD Cambridge 459 United Kingdom 461 Phone: +44-7934034801; +358-9-19151296 462 Email: Aaron.Ding@cl.cam.ac.uk