idnits 2.17.1 draft-savolainen-6man-fqdn-based-if-selection-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 530. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 537. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 543. 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 document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 258 has weird spacing: '...terface cell...' == Line 314 has weird spacing: '...terface cell...' == Line 371 has weird spacing: '...terface cell...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2008) is 5665 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-03) exists of draft-ietf-6man-addr-select-sol-01 == Outdated reference: A later version (-09) exists of draft-fujisaki-dhc-addr-select-opt-06 -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Individual Submission T. Savolainen 2 Internet Draft Nokia 3 Intended status: Experimental October 23, 2008 4 Expires: April 2009 6 Domain name based network interface selection 7 draft-savolainen-6man-fqdn-based-if-selection-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that 12 any applicable patent or other IPR claims of which he or she is 13 aware have been or will be disclosed, and any of which he or she 14 becomes aware will be disclosed, in accordance with Section 6 of 15 BCP 79. 17 This document may not be modified, and derivative works of it may not 18 be created, except to publish it as an RFC and to translate it into 19 languages other than English. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html 37 This Internet-Draft will expire on April 23, 2009. 39 Abstract 41 A multi-homed host with multiple physical and/or virtual network 42 interfaces has to select which one of the network interfaces to use 43 for a new outgoing IPv4 or IPv6 connection. This document describes a 44 method to select an interface by using destination's fully qualified 45 domain name and DNS suffix information received dynamically for each 46 network interface. The method is useful, for example, in split 47 horizon DNS and walled garden scenarios, where right network 48 interface has to be selected even before DNS resolution is conducted. 50 Table of Contents 52 1. Introduction...................................................3 53 2. Conventions used in this document..............................3 54 3. Problem descriptions...........................................4 55 3.1. Split horizon DNS.........................................4 56 3.2. Firewalled walled gardens.................................5 57 3.3. Seemingly equal interfaces................................5 58 4. DNS suffix based interface selection...........................6 59 4.1. Learning of the DNS suffixes..............................6 60 4.2. Changes to DNS resolution procedures......................8 61 4.3. Changes to host's address selection procedures............9 62 5. Network operator considerations...............................10 63 6. Further considerations........................................10 64 7. Security Considerations.......................................10 65 8. IANA Considerations...........................................11 66 9. Acknowledgments...............................................11 67 10. References...................................................11 68 10.1. Normative References....................................11 69 10.2. Informative References..................................12 70 Author's Address.................................................12 72 1. Introduction 74 A host initiating an IP connection commonly uses destination's fully 75 qualified domain name (FQDN). The FQDN has to be first resolved into 76 an IP address with help of DNS, and afterwards the connection is 77 created to one of the resolved IP addresses. The source and 78 destination IP addresses that are used for the connection are 79 determined by host's address selection algorithms, like the one 80 defined for IPv6 in [RFC3484]. 82 A multi-homed host may do network interface selection as part of 83 host's source address selection algorithm. A host may also be 84 configured to use only single network interface at any given time or 85 for a given application. 87 This document identifies three problematic scenarios a multi-homed 88 host may encounter and for which solutions are needed. The problems 89 are listed below and described in detail in chapter 3: 91 1. Split horizon DNS 93 2. Firewalled walled gardens 95 3. Seemingly equal interfaces 97 An example of an application facing these problems is a web browser, 98 which in multi-homed environments may need to dynamically access 99 content over different network interfaces. 101 As a possible solution for these problems a method is described in 102 chapter 4 that uses DNS suffixes for determining the best network 103 interface for DNS resolution and for connecting to a given FQDN. 105 The solution presented in this memo is intended to be fully backwards 106 compatible and one that can be fully ignored by hosts and networks 107 that are not experiencing the described problem scenarios. 109 2. Conventions used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC-2119 [RFC2119]. 115 3. Problem descriptions 117 This chapter describes three multi-homing related problem scenarios 118 for which the DNS suffix based network interface selection solution 119 described in chapter 4 is targeted at. The scenarios are not 120 excluding each other, but shown separately for sake of simplicity. 122 3.1. Split horizon DNS 124 A multi-homed host may be connecting to one or more networks that are 125 using private fully qualified domain names. For example, the host may 126 have simultaneously open a wireless LAN (WLAN) connection to open 127 Internet, cellular (3GPP) connection to an operator network, and 128 virtual private network (VPN) connection to a corporate network. When 129 an application initiates connection to a FQDN, the host needs to be 130 able to choose the right network interface for making successful DNS 131 query. This is illustrated in figure 1. If the FQDN is for a public 132 name, in figure 1 scenario it could be resolved with any DNS server 133 in any network interface, but if the FQDN would be corporation's or 134 operator's service's private name, the host would need to be able to 135 correctly select the right network interface for DNS procedures, i.e. 136 already before destination's IP address is known. 138 +---------------+ | 139 | DNS server w/ | | Corporate 140 +---------+ | public + |----| Intranet 141 | | | corporation's | | 142 | |===== VPN =======| private names | | 143 | | +---------------+ +---+ 144 |A multi- | |FW | 145 | homed | +---+ 146 | host | +---------------| | 147 | |----- WLAN ------| DNS server w/ |----| Public 148 | | | public names | | Internet 149 | | +---------------+ +---+ 150 | | |FW | 151 | | +---------------+ +---+ 152 | |----- 3GPP ------| DNS server w/ | | 153 +---------+ | public + | | Operator 154 | operator's |----| Intranet 155 | private names | | 156 +---------------+ | 158 Figure 1 Split horizon DNS and firewalled walled 159 gardens scenarios illustrated 161 3.2. Firewalled walled gardens 163 The firewalled walled gardens scenario is similar to what was 164 described in 3.1 and figure 1, except that all DNS resolutions could 165 be conducted with any DNS server over any network interface. However, 166 for the actual IP connection creation to succeed right interface must 167 be chosen, as otherwise firewalls at the edge of walled garden would 168 block the incoming connection request. For example, a name of a 169 server in operator's private network could be resolved to an IP 170 address with any DNS server, but it could be contacted only over 171 direct access to operator's network. 173 3.3. Seemingly equal interfaces 175 In third problematic scenario there are no firewalls and all DNS 176 servers have all information, but traffic for certain destinations 177 are preferred to be transmitted over certain network interface rather 178 than others. The reasons can be, for example, route optimization or 179 quality of service related. For example, if a host has two seemingly 180 equal network interfaces from its point of view, the network 181 operator(s) of both or one of the network(s) may be interested to 182 guide a host to make better network interface selection decisions. 184 Figure 2 illustrates an example case where a multi-homed host should 185 choose network interface A for contacting server 1 but interface B 186 for contacting server 2, in order to select shortest path. This can 187 be important e.g. if the two paths have significant geographical 188 distance differences and thus different cost incurred for the network 189 operator(s). A host sticking to using only interface A would be able 190 to access both servers 1 and 2, but it would be suboptimal 191 performance and network load/cost-wise. 193 ----+------Internet--------+---- 194 | | 195 "costly hop"->| |<- "costly hop" 196 | | 197 +----------+ | | +----------+ 198 | Server 1 +----+-- --+------+ Server 2 | 199 +----------+ | | +----------+ 200 -+---+-- --+---+-- 201 (A)| +------+ |(B) 202 +---+ host +---+ 203 +------+ 205 Figure 2 A multi-homed host with two seemingly equal 206 network interfaces (from IP point of view) 208 Figure 3 illustrates case where a multi-homed host should choose 209 network interface A for contacting real-time service 1 but interface 210 B for non-real-time service 2. A host could contact service 1 via 211 either interface, but using interface A provides better experience 212 for real-time services (e.g. low latency) while interface B provides 213 better experience for non-real-time services (e.g. high bandwidth). 215 Real-time service 1 Non-real-time service 2 216 | | 217 ---+----+-------Internet-------+------+--- 218 | | 219 low latency (A) | +------+ | (B) high latency 220 low bandwidth +-------+ host +-------+ high bandwidth 221 higher cost/bit +------+ lower cost/bit 223 Figure 3 A multi-homed host with two network interfaces 224 having different characteristics 226 It is worth noting that in IPv4 domain both A and B network 227 interfaces, of figures 2 and 3, may be using private IPv4 [RFC1918] 228 addresses, which makes IPv4 address based interface selection 229 difficult. In IPv6 domain source address selection mechanisms such as 230 defined in [RFC3484] and worked on e.g. in [MATS2008] and [FUJI2008] 231 can be used to tackle seemingly equal interfaces problem. 233 4. DNS suffix based interface selection 235 This chapter contains a solution approach and a solution for the 236 problems described in chapter 3. 238 A host SHOULD learn which DNS suffixes in particular are resolvable, 239 and accessible, via each network interface. By default a host MUST 240 assume all FQDNs can be resolved and accessed via any network 241 interface. When a connection is to be created to a FQDN, a host 242 SHOULD prioritize available network interfaces for DNS resolution and 243 address selection purposes based on possibly matching DNS suffix 244 information. 246 This document describes how existing DHCP(v6) DNS search list options 247 can be used for this purpose. 249 4.1. Learning of the DNS suffixes 251 A host can learn the DNS suffixes of attached network interfaces from 252 DHCP search list options; DHCPv4 Domain Search Option number 119 253 [RFC3397] and DHCPv6 Domain Search List Option number 24 [RFC3646]. 255 This is illustrated in example message flow 1 below. 257 Application Host DHCP server of DHCP server of 258 WLAN interface cellular interface 259 | | | 260 | +-----------+ | 261 (1) | | open | | 262 | | interface | | 263 | +-----------+ | 264 | | | 265 (2) | |---option REQ-->| 266 | |<--option RESP--| 267 | | | 268 | +-----------+ | 269 (3) | | store | | 270 | | suffixes | | 271 | +-----------+ | 272 | | | 273 | +-----------+ | 274 (4) | | open | | 275 | | interface | | 276 | +-----------+ | 277 | | | | 278 (5) | |---option REQ------------------->| 279 | |<--option RESP-------------------| 280 | | | | 281 | +----------+ | | 282 (6) | | store | | | 283 | | suffixes | | | 284 | +----------+ | | 285 | | | | 287 Message flow 1: Learning DNS suffixes 289 Flow explanations: 291 (1) A host opens its first network interface, say WLAN 293 (2) The host obtains DNS suffix information for the new WLAN 294 interface from DHCP server 296 (3) The host stores the learned DNS suffixes for later use 298 (4) The host opens its seconds network interface, say cellular 299 (5) The host obtains DNS suffix, say "operator.com" information for 300 the new cellular interface from DHCP server 302 (6) The host stores the learned DNS suffixes for later use 304 4.2. Changes to DNS resolution procedures 306 When a DNS resolver in a host is requested by an application to do 307 DNS resolution for a FQDN to an IP address, the host SHOULD look if 308 any of the available network interfaces is known to advertise DNS 309 suffix matching to the FQDN. If there is a matching DNS suffix, then 310 that particular interface should be used for name resolution 311 procedures. This is illustrated in example message flow 2 below. 313 Application Host DHCP server of DHCP server of 314 WLAN interface cellular interface 315 | | | | 316 (1) |--Name REQ-->| | | 317 | | | | 318 | +-----------+ | | 319 (2) | | Choose | | | 320 | | interface | | | 321 | +-----------+ | | 322 | | | | 323 (3) | |------------DNS resolution------>| 324 | |<--------------------------------| 325 | | | | 326 (4) |<--Name resp-| | | 327 | | | | 329 Message flow 2: Choosing interface based on DNS suffix 331 Flow explanations: 333 (1) An application makes a request for resolving a FQDN, e.g. 334 "private.operator.com" 336 (2) A host looks at stored DNS suffix information and chooses 337 interface to use for DNS resolution 339 (3) The host has chosen cellular interface, as from DHCP it was 340 learned that the cellular interface has DNS suffix 341 "operator.com", and resolves the requested name using cellular 342 interface's DNS server to IP 192.0.2.1 344 (4) The host replies to application with resolved address 192.0.2.1 346 4.3. Changes to host's address selection procedures 348 To avoid problems described in chapter 3, in addition to logic for 349 conducting successful DNS query, the host's source IP address 350 selection algorithms must be able to choose the IP address of the 351 right network interface when application is providing only a 352 destination IP address to connect to. 354 The source address selection algorithm SHOULD do either or both of 355 the following procedures: 357 A) The algorithm to make reverse DNS lookup for the destination IP 358 address on host's own DNS cache, which should contain 359 corresponding record if the IP address was earlier resolved 360 from a FQDN. From this record FQDN matching the IP address is 361 learned, and based on that FQDN network interface with 362 corresponding DNS suffix can be chosen. 364 B) The algorithm to consult host's address selection policy table, 365 which may have been dynamically received as described in 366 [MATS2008] and [FUJI2008]. 368 This is illustrated in example message flow 3 below. 370 Application Host DHCP server of DHCP server of 371 WLAN interface cellular interface 372 | | | | 373 (1) |--Connect--->| | | 374 | | | | 375 | +-----------+ | | 376 (2) | | Choose | | | 377 | | interface | | | 378 | +-----------+ | | 379 | | | | 380 (3) | |------------Connect------------->| 381 | |<--------------------------------| 382 | | | | 383 (4) |<--Con resp--| | | 384 | | | | 386 Message flow 3: Choosing interface for outgoing connection 388 Flow explanations: 390 (1) An application initiates new connection to an IP address, e.g. 391 192.0.2.1 393 (2) The host either: 395 a. Consults host's internal DNS cache with reverse DNS lookup 396 query and learns that FQDN "private.operator.com" is matching 397 IP 192.0.2.1 and therefore cellular network interface with 398 matching DNS suffix "operator.com" shall be selected 400 b. Consults dynamically received address selection policy table 401 and learns that for destination IP 192.0.2.1 cellular 402 interface should be used 404 (3)and (4) Connection is established over selected network interface 406 5. Network operator considerations 408 An operator of a network can continue to use DHCP DNS search list 409 options as before, but the operator should take into account that 410 multi-homed hosts may use the DNS suffix information also for 411 interface selection purposes. 413 An operator wishing to assist hosts in network interface selection 414 should configure DHCP servers with proper DNS suffix information, 415 which hosts then can use as hints for improved operation. 416 Furthermore, the operator should configure DHCP servers with IP 417 address selection policies ([MATS2008], [FUJI2008]) that are 418 corresponding to the configured DNS suffix information. 420 6. Further considerations 422 Overloading of existing DNS search list options is not without 423 problems, though: hosts would obviously use the DNS suffixes learned 424 from search lists also for name resolution purposes. This may not be 425 a problem in deployment cases where DNS search list options already 426 contain few DNS suffixes like "intranet.corporation.com", but can 427 become a problem in other deployment scenarios. 429 An obvious alternative would be to define new DHCP options for 430 distributing DNS suffix information designed only for network 431 interface selection purposes. 433 7. Security Considerations 435 An attacker may try to lure traffic from multi-homed host to his 436 network by advertising DNS suffixes attacker wishes to intercept or 437 deny service. The host's security should not be based on correct 438 functionality of source/destination address selection, but risks of 439 this attack can be mitigated by properly prioritizing network 440 interfaces with conflicting DNS suffix advertisements. The 441 prioritization can be based on trust level of a network interface 442 over which DNS suffix was learned from: 444 o VPN interfaces being most trustworthy 446 o Managed networks being on the middle 448 o Unmanaged networks having lowest priority 450 Now, for example, if all of the three abovementioned networks would 451 indicate access for "corporation.com", the host would choose to use 452 the VPN for connections destined to "corporation.com" domain. 454 8. IANA Considerations 456 No considerations identified at this point. TBD: if new DHCP options 457 are defined instead, situation changes. 459 9. Acknowledgments 461 This document was prepared using 2-Word-v2.0.template.dot. 463 10. References 465 10.1. Normative References 467 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 468 Requirement Levels", BCP 14, RFC 2119, March 1997. 470 [RFC3397] Aboba, B., Cheshire, S., "Dynamic Host Configuration 471 Protocol (DHCP) Domain Search Option", RFC 3397, November 472 2002 474 [RFC3646] Ed., Droms, R., "DNS Configuration options for Dynamic 475 Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 476 December 2003 478 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., J. de Groot, 479 G., Lear, E., "Address Allocation for Private Internets", 480 RFC1918, February 1996 482 [MATS2008] Matsumoto, A., Fujisaki, T., Hiromi, R., Kanayama, K., 483 "Solution approaches for address-selection problems", June 484 2008, draft-ietf-6man-addr-select-sol-01.txt 486 [FUJI2008] Fujisaki, T., Niinobe, S., Hiromi, R., Kanayama, K., " 487 Distributing Address Selection Policy using DHCPv6", June 488 2008, draft-fujisaki-dhc-addr-select-opt-06.txt 490 10.2. Informative References 492 [RFC3484] Draves, R., "Default Address Selection for Internet 493 Protocol version 6 (IPv6)", RFC 3484, February 2003 495 Author's Address 497 Teemu Savolainen 498 Nokia 499 Hermiankatu 12 D 500 FI-33720 TAMPERE 501 FINLAND 503 Email: teemu.savolainen@nokia.com 505 Full Copyright Statement 507 Copyright (C) The IETF Trust (2008). 509 This document is subject to the rights, licenses and restrictions 510 contained in BCP 78, and except as set forth therein, the authors 511 retain all their rights. 513 This document and the information contained herein are provided on an 514 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 515 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 516 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 517 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 518 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 519 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 521 Intellectual Property Statement 523 The IETF takes no position regarding the validity or scope of any 524 Intellectual Property Rights or other rights that might be claimed to 525 pertain to the implementation or use of the technology described in 526 this document or the extent to which any license under such rights 527 might or might not be available; nor does it represent that it has 528 made any independent effort to identify any such rights. Information 529 on the procedures with respect to rights in RFC documents can be 530 found in BCP 78 and BCP 79. 532 Copies of IPR disclosures made to the IETF Secretariat and any 533 assurances of licenses to be made available, or the result of an 534 attempt made to obtain a general license or permission for the use of 535 such proprietary rights by implementers or users of this 536 specification can be obtained from the IETF on-line IPR repository at 537 http://www.ietf.org/ipr. 539 The IETF invites any interested party to bring to its attention any 540 copyrights, patents or patent applications, or other proprietary 541 rights that may cover technology that may be required to implement 542 this standard. Please address the information to the IETF at 543 ietf-ipr@ietf.org.