idnits 2.17.1 draft-ietf-6man-addr-select-considerations-04.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 abstract seems to contain references ([RFC3484]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 31, 2011) is 4561 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3736 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4242 (Obsoleted by RFC 8415) == Outdated reference: A later version (-05) exists of draft-ietf-6man-rfc3484-revise-04 == Outdated reference: A later version (-13) exists of draft-ietf-6man-addr-select-opt-01 == Outdated reference: A later version (-05) exists of draft-ietf-mif-dhcpv6-route-option-03 == Outdated reference: A later version (-12) exists of draft-ietf-mif-dns-server-selection-07 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance T. Chown, Ed. 3 Internet-Draft University of Southampton 4 Intended status: Informational A. Matsumoto, Ed. 5 Expires: May 3, 2012 NTT 6 October 31, 2011 8 Considerations for IPv6 Address Selection Policy Changes 9 draft-ietf-6man-addr-select-considerations-04 11 Abstract 13 Where the source and/or destination node of an IPv6 communication is 14 multi-addressed, a mechanism is required for the initiating node to 15 select the most appropriate address pair for the communication. RFC 16 3484 (IPv6 Default Address Selection) [RFC3484] defines such a 17 mechanism for nodes to perform source and destination address 18 selection. While RFC3484 recognised the need for implementations to 19 be able to change the policy table, it did not define how this could 20 be achieved. Requirements have now emerged for administrators to be 21 able to configure and potentially dynamically change RFC 3484 policy 22 from a central control point, and for (nomadic) hosts to be able to 23 obtain the policy for the network that they are currently attached to 24 without manual user intervention. This text discusses considerations 25 for such policy changes, including examples of cases where a change 26 of policy is required, and the likely frequency of such policy 27 changes. This text also includes some discussion on the need to also 28 update RFC 3484, where default policies are currently defined. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on May 3, 2012. 47 Copyright Notice 48 Copyright (c) 2011 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Issues to Consider . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Other Related Work . . . . . . . . . . . . . . . . . . . . . . 5 78 4. Drivers for Policy Changes . . . . . . . . . . . . . . . . . . 5 79 4.1. Internal vs External Triggers . . . . . . . . . . . . . . 6 80 4.2. Administratively Triggered Changes . . . . . . . . . . . . 7 81 4.3. Start-up vs Running Changes . . . . . . . . . . . . . . . 8 82 4.4. Nomadic Nodes . . . . . . . . . . . . . . . . . . . . . . 8 83 4.5. Multiple Interface Nodes . . . . . . . . . . . . . . . . . 8 84 5. How Dynamic? . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 6. Considerations when Obtaining Policy . . . . . . . . . . . . . 10 86 6.1. Changes in Available Address(es) . . . . . . . . . . . . . 11 87 6.2. Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 11 88 7. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 11 89 7.1. Is default policy used? . . . . . . . . . . . . . . . . . 11 90 7.2. Pull model . . . . . . . . . . . . . . . . . . . . . . . . 12 91 7.3. Push model . . . . . . . . . . . . . . . . . . . . . . . . 12 92 7.4. Routing Hints . . . . . . . . . . . . . . . . . . . . . . 12 93 7.5. Policy Conflicts . . . . . . . . . . . . . . . . . . . . . 13 94 7.6. Policy Merging . . . . . . . . . . . . . . . . . . . . . . 14 95 8. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . 14 96 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 97 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 98 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 99 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 100 13. Informative References . . . . . . . . . . . . . . . . . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 103 1. Introduction 105 There have been various operational issues observed with Default 106 Address Selection for IPv6 (RFC 3484) [RFC3484], as described in RFC 107 5220 [RFC5220]. As as a result, there has been some demand for hosts 108 to be able to have their policy tables, and potentially the rules 109 described in RFC 3484, modified dynamically. Such changes may apply 110 to 'static' hosts in a network where policies or topologies change, 111 or different default policy to that described in RFC 3484 is 112 required, or for nomadic hosts within a network for which policies 113 may vary depending on their location within the network. 115 2. Issues to Consider 117 There are a number of aspects to consider in the context of such 118 address selection policy updates. 120 First is the frequency for which such updates are likely to be 121 required; this can be determined largely from identifying the 122 scenarios in which policy changes will be required. This may include 123 overriding default operating system policies on startup, as well as 124 changes while a system is running. We discuss this topic in Section 125 4. 127 Second, by understanding how dynamic the policy update mechanism 128 needs to be we should be better placed to determine what types of 129 update approaches best meet those needs. There may be other 130 considerations of course, e.g. whether the systems are in managed or 131 unmanaged environments, and whether the solution should be proactive 132 or automated, as discussed in [I-D.ietf-6man-addr-select-sol]. 133 Section 5 covers these issues. 135 Third, if we assume some policy update mechanism is defined we should 136 consider how hosts and systems may become aware that a policy change 137 has happened, and how policy can be disseminated in a timely fashion. 138 Thus we need to understand what kind of triggers can be identified 139 that can be used for invoking the policy table update mechanism, e.g. 140 address re-obtainment, address lifetime expiration, or perhaps policy 141 lifetime expiration. We also need to consider what other factors may 142 come into play, e.g. potential policy conflicts. This is discussed 143 in Section 6. 145 After analysing these issues, we can make some initial comments 146 regarding the potential solution spaces, and what models may be well 147 suited, e.g. push vs pull models, and what other methods might assist 148 us, e.g. hints from local routing tables. This is covered in Section 149 7. 151 Finally, we should assess whether these update solutions require or 152 need RFC 3484 to be updated. In some instances, we might envision 153 solutions that simply use RFC 3484 as guidelines and provide 154 sufficient controls to address the current limitations in the RFC. 155 However, as noted in RFC 5220 [RFC5220], not all the operational 156 issues observed to date can be remedied by updating RFC 3484 alone. 157 There is already a good analysis of issues with RFC 3484 and how the 158 text could be revised [I-D.ietf-6man-rfc3484-revise]). 160 3. Other Related Work 162 We note that there is some existing work in defining Requirements for 163 Address Selection Mechanisms [RFC5221], and some initial work has 164 been done in the solution space (for a DHCP-based method) 165 [I-D.ietf-6man-addr-select-opt], but these are not discussed here. 166 While RFC 5221 assumes that a dynamic policy update mechanism of some 167 form is available, this draft is primarily aimed at understanding the 168 scenarios and triggers for policy changes, to better inform future 169 detailed solution discussions. 171 A draft discussing methods for multihoming without IPv6 NAT 172 [I-D.ietf-v6ops-multihoming-without-nat66] has been published 173 recently. This draft includes a requirement for a method to 174 distribute address selection policy to support IPv6 multihoming. 176 4. Drivers for Policy Changes 178 If we wish to determine how frequent address selection policy changes 179 are likely to be, we need to understand why such policies might need 180 to be changed, for particular sites or networks. 182 One reference text for potential drivers for policy change is RFC 183 5220, in which operational issues with the existing policies 184 described in RFC 3484 are listed. Each subsection of this document 185 gives a reason why the existing rules or policy tables in RFC 3484 186 may not be sufficient in certain cases. There have been some 187 significant changes to IPv6 since RFC 3484 was drafted which have 188 impacted the RFC, e.g. the introduction of Unique Local Addresses 189 (ULAs), and concerns about the impact of using longest prefix 190 matching on (DNS) round-robin load balancing. 192 In summary, the issues raised in RFC 5220 were: 194 o Multiple Routers on a Single Interface 195 o Ingress Filtering 197 o Half-Closed Network Problem (*) 199 o Combined Use of Global and ULA addresses (*) 201 o Site Renumbering (*) 203 o Multicast Source Address Selection (*) 205 o Temporary Address Selection 207 o IPv4 or IPv6 Prioritization (*) 209 o ULA and IPv4 Dual-Stack Environment (*) 211 o ULA or Global Prioritization (*) 213 The authors of RFC 5220 noted which of these issues can be solved 214 just by changes to the RFC 3484 policy table, marked (*) above, and 215 which cannot. It is interesting to note that issues largely related 216 to internal networking and (administrative) policy decisions can be 217 handled this way. However some issues need changes beyond just 218 policy table updates. 220 4.1. Internal vs External Triggers 222 When considering drivers or triggers that may lead to a requirement 223 for the policy to change, we can divide the problem space into those 224 drivers that are external to a site or network and those internal to 225 it. In the case of the first two examples above, a dynamic policy 226 table update may be required by externally driven routing changes, 227 assuming the site uses a dynamic routing protocol intra-site and the 228 routing protocol is configured to reflect changes of extra-site 229 routing topology. 231 If a site is multihomed using BGP and advertising a single prefix 232 upstream, then no policy table manipulation is required for global 233 address preferences. However where a site is multihomed by receiving 234 a prefix from each upstream provider, each host will have multiple 235 addresses and many need policy table manipulation. In such a case, 236 the policy table of hosts may need to be updated according to the 237 routing policy. 239 It should be noted that we have other mechanisms for dynamic routing 240 topology change, for example deprecating one of the advertised 241 prefixes, e.g. when one of the upstream links has a problem. But 242 such mechanisms may only help in some cases, and do not remove the 243 need for agility in the RFC 3484 policy. 245 Other examples of external factors include a new transition mechanism 246 being defined (e.g. as with the emergence of Teredo using 2001::/32 247 as assigned by IANA) and its inclusion being required in the policy 248 table (at the time of writing Teredo is not included in RFC 3484, 249 though some operating systems have added it), a new address block 250 being defined, or a site renumbering event that could be triggered by 251 an upstream provider's actions. 253 4.2. Administratively Triggered Changes 255 The other examples above are, in the general case, where the site 256 administrator chooses to change a local policy and in doing so 257 triggers the need for policy table updates. Some of these changes 258 one might assume to be set once, and to change rarely, for example: 260 o Setting priority use of IPv6 over IPv4 (or vice versa). 262 o Setting priority use of ULAs over globals (or vice versa). 264 o Setting priority of Teredo over native IPv4 (or vice versa). 266 o Setting priority use of privacy addresses over DNS-published 267 globals (or vice versa). 269 o An internal network renumbering occurs, perhaps due to a site 270 expanding. 272 o The nature of the external connectivity through multiple ISPs 273 requires specific additional information (policy) to be delivered 274 to certain hosts (as discussed in 2.1.3 in RFC 5220). 276 o Disabling longest-prefix match functions to facilitate round-robin 277 load balancing. 279 However it may be the case that different parts of a site have 280 different policies, or policies are changed in a rolling fashion 281 across a site over time as IPv6 and/or ULAs are introduced (for 282 example). This may happen where the administrator prefers a gradual 283 introduction of new policy in a phased operation across a site, 284 rather than changing policy across the whole site in one operation. 286 Other administrative changes may occur more frequently, e.g.: 288 o Routing tables and forwarding tables change dynamically. 290 o A different provider (link) is preferred for a given destination. 292 It's possible that provider links may vary on a daily basis, or by 293 time of day. The frequency of such policy changes will depend on the 294 frequency that the administrator wishes to change the implied traffic 295 engineering policies. 297 4.3. Start-up vs Running Changes 299 When a host starts up it may be configured with the default RFC 3484 300 policies. At this stage a number of addresses may be configured on a 301 number of interfaces on the host. At this time it may be desirable 302 for the host to be able to receive the site-specific policy updates 303 as a start-up override from the RFC 3484 defaults. 305 Other policy changes may later be required while the host is running. 306 Ideally the same protocol should be used for the start-up and running 307 state update mechanism. 309 4.4. Nomadic Nodes 311 A host may be nomadic within a site and as a result it may see the 312 preferred policy change depending on the host's topological location 313 within that site. Such a host should be capable of receiving policy 314 updates in a timely fashion as it migrates within the network. 316 While this may be one case of 'running changes' described above, the 317 policy changes are required due to the host's new point of 318 attachment, not changes of policy to the current point of attachment. 319 The frequency of updates are thus depend ant on the frequency of host 320 mobility to parts of the network that have differing policies. 322 It is worth noting that the point at which a nomadic host configures 323 its network settings would be an appropriate time for it to also 324 receive any specific address selection policy for its point of 325 attachement. 327 4.5. Multiple Interface Nodes 329 In considering scenarios where hosts may be multi-addressed and 330 require policy to assist in address selection, the issue of hosts 331 with multiple interfaces arises. 333 A host may have a variety of reasons to have multiple interfaces. It 334 may for example have WiFi and 3G interfaces, and be capable of 335 sending or receiving data over either interface. In some cases these 336 interfaces may fall within the same administrative domain (ISP) and 337 in some cases they may not. Another example would be the case of a 338 host with a VPN connection established, where address selection may 339 be affected by the choice of whether the VPN connection is used or 340 not. In this case it is interesting to note the choice to use the 341 VPN tunnel for all, or just VPN home site traffic, is often left as a 342 choice for the user via a tickbox selection. In addition, initiating 343 the VPN typically changes several related settings, which is 344 reasonable behaviour given the user chose to initiate the VPN 345 connection. 347 Handling multiple interface nodes, and the possibility of conflicting 348 policy being retrieved via each, is clearly an important problem 349 today, but we note that RFC 3484 is currently defined as a per-node, 350 not per-interface, mechanism (at least in the context of destination 351 address selection). However, for RFC 3484, and its potential update 352 mechanisms, to be applicable to typical 'real world' usage patterns, 353 we should consider the multiple interface scenarios. 355 In the case where a host has multiple interfaces there are two likely 356 scenarios: 358 o Wired and wireless interfaces - in this case the operating system 359 just needs to pick one interface and use it. 361 o Normal and VPN interfaces - here the default should be the normal 362 interface; the VPN interface should only be used for destinations 363 associated with the VPN. 365 It has been suggested that an RFC 3484 policy table is required on a 366 per-interface basis, though the choice of interface may itself be 367 determined by the (destination) address selection process. As stated 368 above, RFC 3484's policy table is currently defined to be node-wide. 369 The node-wide problem is destination address selection when the 370 source address is implied from a selected interface. 372 We note that there are some new, initial drafts published recently on 373 the multiple interface problem [I-D.ietf-mif-problem-statement], and 374 on a number of possible DHCPv6 extensions, e.g. to inform hosts about 375 routing information to assist the selection process. 376 [I-D.ietf-mif-dhcpv6-route-option], to inform hosts about DNS server 377 selection policy, [I-D.ietf-mif-dns-server-selection]. These drafts 378 fall within the remit of the new IETF mif WG. We note that the mif 379 WG may produce relevant work with respect to the analysis of RFC 3484 380 policy changes, but at this stage no such output exists for 381 inclusion. 383 5. How Dynamic? 385 The discussion above suggests that many of the potential triggers for 386 policy table changes are 'one-off' in nature, i.e. a site makes a 387 one-time policy change. It is thus unlikely that such administrative 388 changes will be frequent. 390 There are some cases where updates may be required to be more 391 frequent. In the example of a site which is implementing the gradual 392 introduction of new policy across its network, while the frequency of 393 changes may be relatively high, there is still probably only one or a 394 small number of changes per host. 396 There may be a higher rate of policy changes within a site if there 397 are nomadic hosts within the site, and these are roaming frequently 398 to parts of the network where differing policies are in effect. In 399 such cases it may be useful for a host to know whether or not the 400 default RFC 3484 (or soon to be 3484bis) policies are in effect or 401 not, and for there to be a 'cheap' way for the host to discover this. 403 Perhaps the biggest cause of policy change lies where the preferred 404 links or paths for certain destinations change frequently over time 405 as (typically) traffic engineering requirements change. In some 406 networks this may be a daily change, or change between states at 407 different times of day. It is not clear how common these cases are, 408 and thus further input is welcomed here. Our belief is that cases 409 where dynamic changes are used heavily are rare. 411 So, unless a site or network has rapidly changing traffic engineering 412 requirements, or includes a high number of mobile nodes where the 413 nodes are roaming to areas of the network with differing address 414 selection related policies, the frequency of updates is likely to be 415 relatively low. Most update requests will simply occur when a host 416 starts up, and such requests for policy will be little different in 417 frequency to other configuration requests. Other types of network 418 change that may require a host to change its RFC 3484 policy 419 behaviour are probably also likely to have associated changes with 420 other host configuration data. 422 6. Considerations when Obtaining Policy 424 When a policy change is made, or a host migrates to a part of the 425 network with different policies, that change of policy needs to be 426 conveyed to the host. It needs to be made available and applied 427 without restarting every affected host. 429 6.1. Changes in Available Address(es) 431 One might assume at first that when a host observes a change in its 432 addresses, it should re-obtain the selection policy, but this may not 433 always be the case. Not all policy changes are tied to a host 434 changing one or more addresses, though it may be acceptable to query 435 regardless for new policy (if a pull model is used) when address 436 information changes. 438 As described above, it may be sufficient for a host to know when a 439 policy is changed, or that perhaps the default policy is - or is not 440 - in effect in its current locale. 442 6.2. Timeliness 444 In many, but not all, cases a policy change will need to be 445 synchronised across a network. Thus there is a general issue of 446 timely and synchronised dissemination of new policy. If the policy 447 is distributed via the same mechanism that informs a host of a change 448 of address(es), the application of the policy should be synchronised 449 sufficiently with the address change. However, not all hosts may 450 receive the update information at the same time, e.g. where new 451 address assignments may be dependent on DHCP lease timers. 453 Where hosts use DHCPv6 for address information, in the absence of 454 some form of Reconfigure message, a host may see a delay in policy 455 changes being notified. One possible tool to help here is the DHCPv6 456 Lifetime Option (RFC4242) [RFC4242], which was originally introduced 457 to assist with network renumbering events. 459 7. Solution Space 461 In this section we make some initial observations on the possible 462 solution space. 464 7.1. Is default policy used? 466 There could be some mechanism to indicate to a host that the local 467 network has a modified RFC 3484 policy in use, and thus that a 468 revised policy table is available (and should be used). 469 Alternatively a host could simply always attempt to obtain local RFC 470 3484 policy on startup. Regardless, it should also be possible for a 471 host to detect that policy has changed (whether 'around' the host, or 472 due to the host being nomadic). The method to convey this chnage to 473 a host would depend on whether a push or pull configuration method is 474 used. 476 It is assumed by 'default' policy here we refer to the revised/ 477 updated RFC3484 specification, when that is produced. 479 7.2. Pull model 481 One potential solution is that a host uses a similar mechanism for 482 RFC 3484 policy updates as is used for obtaining other configuration 483 data, for example DHCPv6 [RFC3315]. For hosts using stateless 484 autoconfiguration, policy could be made available via stateless 485 DHCPv6 [RFC3736]. 487 There are also already some initial proposals from the IETF mif WG on 488 using DHCPv6 to deliver (mainly routing oriented) information to 489 hosts, e.g. [I-D.ietf-mif-dhcpv6-route-option] and 490 [I-D.ietf-mif-dns-server-selection]. These methods assume entities 491 that have timely knowledge of routing information can provide equally 492 timely hints to hosts on address selection, via DHCPv6. At this 493 stage we believe that distributing RFC 3484 policy, as configured by 494 an administrator, is a more practical use of DHCPv6. 496 The DHCP model allows individual nodes to potentially have differing 497 policy, even when on the same subnet. 499 7.3. Push model 501 For hosts only using stateless autoconfiguration, in environments 502 without stateless DHCPv6, it may be argued that since the network is 503 not managed, there is not likely to be any managed policy to push to 504 the hosts. In such environments hosts may perhaps more usefully use 505 techniques such as router hints to make informed selections, as 506 discussed later in this text. 508 It may of course be possible to piggy back policy information to a 509 host in a Router Advertisement message, though initial consensus 510 seems to be that this is a less attractive approach. 512 7.4. Routing Hints 514 As mentioned above, if a host has routing hints available, it may be 515 able to make more informed selections. For example, a protocol could 516 be specified for a node to query an on-link or remote (e.g. edge) 517 router for 'hints'. For example, a new ICMPv6 message could be 518 defined that queried a site edge router or route server for address 519 pairs to use for a given destination address. 521 However, having hosts themselves participate in routing is generally 522 not desirable. At this stage we can simply note that address 523 selection might be simplified when some hint based on routing state 524 is provided to the end system, but such mechanisms are out of scope 525 for this text. 527 It is noted in [RFC5887] that: 529 "In an environment where a site has more than one upstream link to 530 the outside world, the site might have more than one valid routing 531 prefix. In such cases, typically all valid routing prefixes within a 532 site will have the same prefix length. Also in such cases, it might 533 be desirable for hosts that obtain their addresses using DHCPv6 to 534 learn about the availability of upstream links dynamically, by 535 deducing from periodic IPv6 RA messages which routing prefixes are 536 currently valid. This application seems possible within the IPv6 537 Neighbour Discovery architecture, but does not appear to be clearly 538 specified anywhere." 540 The same thought seems relevant to address selection. There's no 541 point selecting a source address whose prefix is not being advertised 542 in RAs. 544 While routing and prefix hints may help a host make selection 545 decisions, we should consider to what extent we wish to 'burden' a 546 host with holding such information. If a host is to determine and 547 cache routing hints, this may require an update of RFC 3484 policy 548 table syntax to support preference for address pairs. 550 7.5. Policy Conflicts 552 In the case of a host operating in a single administrative domain, 553 consistent policy should be available from whichever policy 554 distribution mechanism provides the information. In such cases the 555 network should not distribute policy sets from multiple entities (or 556 by multiple mechanisms). However, in scenarios where a host is 557 multi-addressed from multiple providers (e.g. a SOHO network with 558 differing DSL and cable providers, or a user in a coffee shop 559 initiating a VPN connection to their home network), multiple RFC 3484 560 policies may be received and there is likely to be some conflicts in 561 the received policy information. 563 There are scenarios where a host may wish to ignore a conveyed 564 policy. For example, the manager of a mobile node may not want to 565 have its preferences changed by a visited network. In such a case 566 one might argue that the mobile node should use MIPv6 with whatever 567 its home network policies are. 569 The question then is whether the policy update mechanism itself needs 570 to handle such potential conflicts, choosing one or ther other or 571 merging by some set of heuristics, or whether the policy update 572 mechansism should be viewed independently of the conflict handling. 573 The view of the design team was that distributing policy is a network 574 problem, while handling conflicts is a host problem. 576 An initial draft on handling policy conflicts has been released 577 separately [I-D.arifumi-6man-addr-select-conflict] given the topic is 578 beyond the scope of this draft. 580 7.6. Policy Merging 582 For whatever mechanism is used to distribute RFC 3484 policy, it is 583 not yet clear whether entire policy tables will be made available, or 584 simply differences to the 'default', and thus whether policies may 585 need to be merged, or overridden. Some policy conflicts will be 586 unresolvable, e.g. one prefers IPv4 over IPv6, the other vice-versa. 587 It may be simpler, though less efficient, for whole policy tables to 588 be distributed, to avoid the merger problem. 590 One option may be to split the policy table into destination address 591 selection and source address selection tables, with the policy 592 distribution only updating the source address selection. Whether 593 this might make merging policies simpler or in fact more complex 594 would require further study. 596 It may also be possible to indicate some priority value for a policy, 597 e.g. the priority of the interface it is received on, or perhaps to 598 convey a unique identifier for the policy provider. Alternatibely, 599 if there are multiple policies in conflict, a host could simply 600 choose to fall back to use the default RFC 3484 policy. 602 A host also needs to know how to decide when to accept a policy. We 603 could simplify the discussion by assuming a host is located in and 604 only nomadic within a single site with one administrative controlling 605 entity. 607 8. On RFC3484 Default Policies 609 RFC 3484 includes text about mechanisms for changing policy, having 610 'policy hooks' and having a configurable policy table. The 611 implication is that defaults can be changed, and the text gives 612 examples of this in Section 10. However, issues with RFC 3484 are 613 broader that just policy table updates - it remains the case that 614 some operational issues with RFC 3484 are not just related to the 615 table, but on rules themselves, e.g. longest prefix match (affecting 616 DNS round robin as described in [RFC5220]). 618 While discussing default policy, we noted that the word 'default' has 619 to be carefully defined, and also what the scope of this 'default' 620 is. The default policy should be whatever RFC 3484, or its -bis 621 version, states. At present some operating systems have already 622 modified their default, based on operational feedback (e.g. on ULAs, 623 on Teredo prefixes, or on the DNS round-robin problem). Currently we 624 assume RFC3484 and changes to it will remain node-specific. 626 It certainly seems the case that the issues raised in RFC 5220, and 627 discussed in [I-D.ietf-6man-rfc3484-revise] mean that an update of 628 RFC 3484 is required, if only because some of the issues (as 629 highlighted earlier) cannot be addressed by updating the policy table 630 alone. An update would also give us some hope that all operating 631 systems might have a common 'default'. 633 We do not note any specific comments here on how RFC 3484 should be 634 updated. Other drafts have made suggestions. There are some 635 discussions on ideas however, e.g. on the semantics of labels, and in 636 adding ULAs explicitly to the default policy table. 638 There have also been new issues identified, e.g. on how one 639 differentiates between IPv4+NAT access or IPv6 transitional access 640 (e.g. via Teredo) to a dual-stack destination (the IPv4 private 641 address inside the NAT is implicitly global, although its explicit 642 scope is local) [I-D.denis-v6ops-nat-addrsel]. This illustrates that 643 new issues may continue to be identified through growing IPv6 644 operational experience. 646 It is hard to predict exactly what features people will want to add 647 to address selection algorithms in the future. Ideally we should not 648 preclude future flexibility. It seems clear that any RFC 3484 update 649 has two aspects: one that uses the existing policy table capability, 650 and one that might change associated algorithms. 652 9. Conclusions 654 We believe a key outcome of this text should be progression of a 655 solution to allow an enterprise network manager to configure their 656 hosts with address selection policies that may differ from the RFC 657 3484 default, across all or part of their network, and possibly 658 changing polciy with time. The general scope of this text applies to 659 site and enterprise networks, where an administrator may need to 660 change policies over time. It also includes nomadic nodes within the 661 site, which may migrate to different parts of the site where 662 different policies are required. 664 It is clear there may be environments which might introduce 665 conflicting policies from different administrative domains, e.g. a 666 SOHO network with two ISP links, or an enterprise node running a VPN 667 to a remote network. We conclude that the policy distribution 668 mechanism is a network task, while policy conflict handling is a host 669 task. Within this text, we do not present a solution for policy 670 conflict handling, because at this time there is no perfect or 671 practical solution. We thus recommend that we should progress the 672 policy distribution solution while analysing conflict handling (which 673 is not unique to this domain) in a separate text. 675 The scope of this text includes issues affecting the design of a 676 protocol to allow a host's RFC 3484 policy table to be updated. From 677 discussion of update triggers/scenarios, we believe rapid updates are 678 unlikely to be required unless a node is in a network which has 679 (very) dynamic external traffic engineering, or many nodes are mobile 680 between parts of the network with differing policy. It's thus 681 generally appropriate to use a similar method to obtain RFC 3484 682 policy as to obtain other configuration data. 684 In terms of obtaining policy, a pull-based solution, such as DHCPv6, 685 may be more appropriate in managed environments (where managed non- 686 default policies are most likely to be in effect), which would assure 687 that hosts only gain policy information from a single entity (the 688 DHCPv6 service). Use of DHCPv6 is also preferable if individual 689 hosts on a subnet require different policies. In unmanaged networks, 690 without stateless DHCPv6, use of routing hints may be an approach 691 worth exploring. 693 Finally, there is a clear need to revise RFC 3484, to create a new 694 default policy table for address selection, and to improve non policy 695 table algorithms. This should be expedited. 697 10. Security Considerations 699 There are no extra Security consideration for this document. 701 11. IANA Considerations 703 There are no extra IANA consideration for this document. 705 12. Acknowledgements 707 The design team working on this draft is: Marcelo Bagnulo Braun, Marc 708 Blanchet, Tim Chown, Francis Dupont, Tim Enos, TJ Evans, Brian 709 Haberman, Tony Hain, Ruri Hiromi, Suresh Krishnan, Arifumi Matsumoto, 710 Janos Mohacsi, Sebastien Roy, Teemu Savolainen, Fujisaki Tomohiro, 711 and John Zhao. 713 We also acknowledge comments received from IETF WG mail lists, 714 including those by Brian Carpenter and Dave Thaler. 716 13. Informative References 718 [RFC3484] Draves, R., "Default Address Selection for Internet 719 Protocol version 6 (IPv6)", RFC 3484, February 2003. 721 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 722 and M. Carney, "Dynamic Host Configuration Protocol for 723 IPv6 (DHCPv6)", RFC 3315, July 2003. 725 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 726 (DHCP) Service for IPv6", RFC 3736, April 2004. 728 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 729 Time Option for Dynamic Host Configuration Protocol for 730 IPv6 (DHCPv6)", RFC 4242, November 2005. 732 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 733 "Problem Statement for Default Address Selection in Multi- 734 Prefix Environments: Operational Issues of RFC 3484 735 Default Rules", RFC 5220, July 2008. 737 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 738 "Requirements for Address Selection Mechanisms", RFC 5221, 739 July 2008. 741 [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 742 Still Needs Work", RFC 5887, May 2010. 744 [I-D.ietf-6man-addr-select-sol] 745 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution 746 approaches for address-selection problems", 747 draft-ietf-6man-addr-select-sol-03 (work in progress), 748 March 2010. 750 [I-D.ietf-6man-rfc3484-revise] 751 Matsumoto, A., Kato, J., Fujisaki, T., and T. Chown, 752 "Update to RFC 3484 Default Address Selection for IPv6", 753 draft-ietf-6man-rfc3484-revise-04 (work in progress), 754 July 2011. 756 [I-D.ietf-6man-addr-select-opt] 757 Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, 758 "Distributing Address Selection Policy using DHCPv6", 759 draft-ietf-6man-addr-select-opt-01 (work in progress), 760 June 2011. 762 [I-D.ietf-mif-problem-statement] 763 Blanchet, M. and P. Seite, "Multiple Interfaces and 764 Provisioning Domains Problem Statement", 765 draft-ietf-mif-problem-statement-15 (work in progress), 766 May 2011. 768 [I-D.ietf-mif-dhcpv6-route-option] 769 Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6 770 Route Options", draft-ietf-mif-dhcpv6-route-option-03 771 (work in progress), September 2011. 773 [I-D.ietf-mif-dns-server-selection] 774 Savolainen, T., Kato, J., and T. Lemon, "Improved DNS 775 Server Selection for Multi-Interfaced Nodes", 776 draft-ietf-mif-dns-server-selection-07 (work in progress), 777 October 2011. 779 [I-D.arifumi-6man-addr-select-conflict] 780 Matsumoto, A., Fujisaki, T., and R. Hiromi, 781 "Considerations of address selection policy conflicts", 782 draft-arifumi-6man-addr-select-conflict-02 (work in 783 progress), March 2010. 785 [I-D.denis-v6ops-nat-addrsel] 786 Denis-Courmont, R., "Problems with IPv6 source address 787 selection and IPv4 NATs", draft-denis-v6ops-nat-addrsel-00 788 (work in progress), February 2009. 790 [I-D.ietf-v6ops-multihoming-without-nat66] 791 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 792 Wing, "IPv6 Multihoming without Network Address 793 Translation", 794 draft-ietf-v6ops-multihoming-without-nat66-00 (work in 795 progress), December 2010. 797 Authors' Addresses 799 Tim Chown (editor) 800 University of Southampton 801 Southampton, Hampshire SO17 1BJ 802 United Kingdom 804 Email: tjc@ecs.soton.ac.uk 806 Arifumi Matsumoto (editor) 807 NTT SI Lab 808 Midori-Cho 3-9-11 809 Musashino-shi, Tokyo 180-8585 810 Japan 812 Phone: +81 422 59 3334 813 Email: arifumi@nttv6.net