idnits 2.17.1 draft-ietf-6man-addr-select-considerations-01.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 (July 11, 2010) is 5036 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 (-03) exists of draft-arifumi-6man-rfc3484-revise-02 == Outdated reference: A later version (-05) exists of draft-dec-dhcpv6-route-option-03 == Outdated reference: A later version (-03) exists of draft-sun-mif-route-config-dhcp6-01 == Outdated reference: A later version (-01) exists of draft-troan-multihoming-without-nat66-00 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 July 11, 2010 5 Expires: January 12, 2011 7 Considerations for IPv6 Address Selection Policy Changes 8 draft-ietf-6man-addr-select-considerations-01 10 Abstract 12 Where the source and/or destination node of an IPv6 communication is 13 multi-addressed, a mechanism is required for the initiating node to 14 select the most appropriate address pair for the communication. RFC 15 3484 (IPv6 Default Address Selection) [RFC3484] defines such a 16 mechanism for nodes to perform source and destination address 17 selection. While RFC3484 recognised the need for implementations to 18 be able to change the policy table, it did not define how this could 19 be achieved. Requirements have now emerged for administrators to be 20 able to configure and potentially dynamically change RFC 3484 policy 21 from a central control point, and for (nomadic) hosts to be able to 22 obtain the policy for the network that they are currently attached to 23 without manual user intervention. This text discusses considerations 24 for such policy changes, including examples of cases where a change 25 of policy is required, and the likely frequency of such policy 26 changes. This text also includes some discussion on the need to also 27 update RFC 3484, where default policies are currently defined. 29 Status of this Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on January 12, 2011. 46 Copyright Notice 48 Copyright (c) 2010 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? . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 6. Considerations when Obtaining Policy . . . . . . . . . . . . . 10 86 6.1. Changes in Available Address(es) . . . . . . . . . . . . . 10 87 6.2. Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 11 88 6.3. Manual Configuration? . . . . . . . . . . . . . . . . . . 11 89 6.4. Policy Conflicts . . . . . . . . . . . . . . . . . . . . . 11 90 7. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 12 91 7.1. Is default policy used? . . . . . . . . . . . . . . . . . 12 92 7.2. Pull model . . . . . . . . . . . . . . . . . . . . . . . . 12 93 7.3. Push model . . . . . . . . . . . . . . . . . . . . . . . . 13 94 7.4. Routing Hints . . . . . . . . . . . . . . . . . . . . . . 13 95 7.5. Conflicts/Merging Policies . . . . . . . . . . . . . . . . 14 96 8. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . 15 97 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 99 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 100 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 101 13. Informative References . . . . . . . . . . . . . . . . . . . . 17 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 104 1. Introduction 106 There have been various operational issues observed with Default 107 Address Selection for IPv6 (RFC 3484) [RFC3484], as described in RFC 108 5220 [RFC5220]. As as a result, there has been some demand for hosts 109 to be able to have their policy tables, and potentially the rules 110 described in RFC 3484, modified dynamically. Such changes may apply 111 to 'static' hosts in a network where policies or topologies change, 112 or different default policy to that described in RFC 3484 is 113 required, or for nomadic hosts within a network for which policies 114 may vary depending on their location within the network. 116 2. Issues to Consider 118 There are a number of aspects to consider in the context of such 119 address selection policy updates. 121 First is the frequency for which such updates are likely to be 122 required; this can be determined largely from identifying the 123 scenarios in which policy changes will be required. This may include 124 overriding default operating system policies on startup, as well as 125 changes while a system is running. We discuss this topic in Section 126 4. 128 Second, by understanding how dynamic the policy update mechanism 129 needs to be we should be better placed to determine what types of 130 update approaches best meet those needs. There may be other 131 considerations of course, e.g. whether the systems are in managed or 132 unmanaged environments, and whether the solution should be proactive 133 or automated, as discussed in [I-D.ietf-6man-addr-select-sol]. 134 Section 5 covers these issues. 136 Third, if we assume some policy update mechanism is defined we should 137 consider how hosts and systems may become aware that a policy change 138 has happened, and how policy can be disseminated in a timely fashion. 139 Thus we need to understand what kind of triggers can be identified 140 that can be used for invoking the policy table update mechanism, e.g. 141 address re-obtainment, address lifetime expiration, or perhaps policy 142 lifetime expiration. We also need to consider what other factors may 143 come into play, e.g. potential policy conflicts. This is discussed 144 in Section 6. 146 After analysing these issues, we can make some initial comments 147 regarding the potential solution spaces, and what models may be well 148 suited, e.g. push vs pull models, and what other methods might assist 149 us, e.g. hints from local routing tables. This is covered in Section 150 7. 152 Finally, we should assess whether these update solutions require or 153 need RFC 3484 to be updated. In some instances, we might envision 154 solutions that simply use RFC 3484 as guidelines and provide 155 sufficient controls to address the current limitations in the RFC. 156 However, as noted in RFC 5220 [RFC5220], not all the operational 157 issues observed to date can be remedied by updating RFC 3484 alone. 158 There is already a good analysis of issues with RFC 3484 and how the 159 text could be revised [I-D.arifumi-6man-rfc3484-revise]). 161 3. Other Related Work 163 We note that there is some existing work in defining Requirements for 164 Address Selection Mechanisms [RFC5221], and some initial work has 165 been done in the solution space (for a DHCP-based method) 166 [I-D.fujisaki-dhc-addr-select-opt], but these are not discussed here. 167 While RFC 5221 assumes that a dynamic policy update mechanism of some 168 form is available, this draft is primarily aimed at understanding the 169 scenarios and triggers for policy changes, to better inform future 170 detailed solution discussions. 172 A draft discussing methods for multihoming without NAT66 173 [I-D.troan-multihoming-without-nat66] has been published recently. 174 This draft includes a requirement for a method to distribute address 175 selection policy to support IPv6 multihoming. 177 4. Drivers for Policy Changes 179 If we wish to determine how frequent address selection policy changes 180 are likely to be, we need to understand why such policies might need 181 to be changed, for particular sites or networks. 183 One reference text for potential drivers for policy change is RFC 184 5220, in which operational issues with the existing policies 185 described in RFC 3484 are listed. Each subsection of this document 186 gives a reason why the existing rules or policy tables in RFC 3484 187 may not be sufficient in certain cases. There have been some 188 significant changes to IPv6 since RFC 3484 was drafted which have 189 impacted the RFC, e.g. the introduction of Unique Local Addresses 190 (ULAs), and concerns about the impact of using longest prefix 191 matching on (DNS) round-robin load balancing. 193 In summary, the issues raised in RFC 5220 were: 195 o Multiple Routers on a Single Interface 196 o Ingress Filtering 198 o Half-Closed Network Problem (*) 200 o Combined Use of Global and ULA addresses (*) 202 o Site Renumbering (*) 204 o Multicast Source Address Selection (*) 206 o Temporary Address Selection 208 o IPv4 or IPv6 Prioritization (*) 210 o ULA and IPv4 Dual-Stack Environment (*) 212 o ULA or Global Prioritization (*) 214 The authors of RFC 5220 noted which of these issues can be solved 215 just by changes to the RFC 3484 policy table, marked (*) above, and 216 which cannot. It is interesting to note that issues largely related 217 to internal networking and (administrative) policy decisions can be 218 handled this way. However some issues need changes beyond just 219 policy table updates. 221 4.1. Internal vs External Triggers 223 When considering drivers or triggers that may lead to a requirement 224 for the policy to change, we can divide the problem space into those 225 drivers that are external to a site or network and those internal to 226 it. In the case of the first two examples above, a dynamic policy 227 table update may be required by externally driven routing changes, 228 assuming the site uses a dynamic routing protocol intra-site and the 229 routing protocol is configured to reflect changes of extra-site 230 routing topology. 232 If a site is multihomed using BGP and advertising a single prefix 233 upstream, then no policy table manipulation is required for global 234 address preferences. However where a site is multihomed by receiving 235 a prefix from each upstream provider, each host will have multiple 236 addresses and many need policy table manipulation. In such a case, 237 the policy table of hosts may need to be updated according to the 238 routing policy. 240 It should be noted that we have other mechanisms for dynamic routing 241 topology change, for example deprecating one of the advertised 242 prefixes, e.g. when one of the upstream links has a problem. But 243 such mechanisms may only help in some cases, and do not remove the 244 need for agility in the RFC 3484 policy. 246 Other examples of external factors include a new transition mechanism 247 being defined (e.g. as with the emergence of Teredo using 2001::/32 248 as assigned by IANA) and its inclusion being required in the policy 249 table (at the time of writing Teredo is not included in RFC 3484, 250 though some operating systems have added it), a new address block 251 being defined, or a site renumbering event that could be triggered by 252 an upstream provider's actions. 254 4.2. Administratively Triggered Changes 256 The other examples above are, in the general case, where the site 257 administrator chooses to change a local policy and in doing so 258 triggers the need for policy table updates. Some of these changes 259 one might assume to be set once, and to change rarely, for example: 261 o Setting priority use of IPv6 over IPv4 (or vice versa). 263 o Setting priority use of ULAs over globals (or vice versa). 265 o Setting priority of Teredo over native IPv4 (or vice versa). 267 o Setting priority use of privacy addresses over DNS-published 268 globals (or vice versa). 270 o An internal network renumbering occurs, perhaps due to a site 271 expanding. 273 o The nature of the external connectivity through multiple ISPs 274 requires specific additional information (policy) to be delivered 275 to certain hosts (as discussed in 2.1.3 in RFC 5220). 277 o Disabling longest-prefix match functions to facilitate round-robin 278 load balancing. 280 However it may be the case that different parts of a site have 281 different policies, or policies are changed in a rolling fashion 282 across a site over time as IPv6 and/or ULAs are introduced (for 283 example). This may happen where the administrator prefers a gradual 284 introduction of new policy in a phased operation across a site, 285 rather than changing policy across the whole site in one operation. 287 Other administrative changes may occur more frequently, e.g.: 289 o Routing tables and forwarding tables change dynamically. 291 o A different provider (link) is preferred for a given destination. 293 It's possible that provider links may vary on a daily basis, or by 294 time of day. The frequency of such policy changes will depend on the 295 frequency that the administrator wishes to change the implied traffic 296 engineering policies. 298 4.3. Start-up vs Running Changes 300 When a host starts up it may be configured with the default RFC 3484 301 policies. At this stage a number of addresses may be configured on a 302 number of interfaces on the host. At this time it may be desirable 303 for the host to be able to receive the site-specific policy updates 304 as a start-up override from the RFC 3484 defaults. 306 Other policy changes may later be required while the host is running. 307 Ideally the same protocol should be used for the start-up and running 308 state update mechanism. 310 4.4. Nomadic Nodes 312 A host may be nomadic within a site and as a result it may see the 313 preferred policy change depending on the host's topological location 314 within that site. Such a host should be capable of receiving policy 315 updates in a timely fashion as it migrates within the network. 317 While this may be one case of 'running changes' described above, the 318 policy changes are required due to the host's new point of 319 attachment, not changes of policy to the current point of attachment. 320 The frequency of updates are thus depend ant on the frequency of host 321 mobility to parts of the network that have differing policies. 323 It is worth noting that the point at which a nomadic host configures 324 its network settings would be an appropriate time for it to also 325 receive any specific address selection policy for its point of 326 attachement. 328 4.5. Multiple Interface Nodes 330 In considering scenarios where hosts may be multi-addressed and 331 require policy to assist in address selection, the issue of hosts 332 with multiple interfaces arises. 334 A host may have a variety of reasons to have multiple interfaces. It 335 may for example have WiFi and 3G interfaces, and be capable of 336 sending or receiving data over either interface. In some cases these 337 interfaces may fall within the same administrative domain (ISP) and 338 in some cases they may not. Another example would be the case of a 339 host with a VPN connection established, where address selection may 340 be affected by the choice of whether the VPN connection is used or 341 not. In this case it is interesting to note the choice to use the 342 VPN tunnel for all, or just VPN home site traffic, is typically left 343 as a choice for the user via a tickbox selection. 345 Handling multiple interface nodes, and the possibility of conflicting 346 policy being retrieved via each, is clearly an important problem 347 today, but we note that RFC 3484 is currently defined as a per-node, 348 not per-interface, mechanism. However, for RFC 3484, and its 349 potential update mechanisms, to be applicable to typical 'real world' 350 usage patterns, we should consider the multiple interface scenarios. 352 In the case where a host has multiple interfaces there are two likely 353 scenarios: 355 o Wired and wireless interfaces - in this case the operating system 356 just needs to pick one interface and use it. 358 o Normal and VPN interfaces - here the default should be the normal 359 interface; the VPN interface should only be used for destinations 360 associated with the VPN. 362 It has been suggested that an RFC 3484 policy table is required on a 363 per-interface basis, though the choice of interface may itself be 364 determined by the (destination) address selection process. As stated 365 above, RFC 3484's policy table is currently defined to be node-wide. 366 The node-wide problem is destination address selection when the 367 source address is implied from a selected interface. 369 We note that there are some new, initial drafts published recently on 370 the multiple interface problem [I-D.blanchet-mif-problem-statement], 371 and on a number of possible DHCPv6 extensions, e.g. to inform hosts 372 about routing information to assist the selection process 373 [I-D.dec-dhcpv6-route-option], [I-D.sun-mif-address-policy-dhcp6], 374 [I-D.sarikaya-mif-dhcpv6solution]. Another new draft proposes a 375 DHCPv6 option to convey policy directly to a host 376 [I-D.sun-mif-route-config-dhcp6]. These drafts fall within the remit 377 of the new IETF mif WG, which at the time of writing was only 378 recently formed. We note that the mif WG may produce relevant work 379 with respect to the analysis of RFC 3484 policy changes, but at this 380 stage no such output exists for inclusion. 382 5. How Dynamic? 384 The discussion above suggests that many of the potential triggers for 385 policy table changes are 'one-off' in nature, i.e. a site makes a 386 one-time policy change. It is thus unlikely that such administrative 387 changes will be frequent. 389 There are some cases where updates may be required to be more 390 frequent. In the example of a site which is implementing the gradual 391 introduction of new policy across its network, while the frequency of 392 changes may be relatively high, there is still probably only one or a 393 small number of changes per host. 395 There may be a higher rate of policy changes within a site if there 396 are nomadic hosts within the site, and these are roaming frequently 397 to parts of the network where differing policies are in effect. In 398 such cases it may be useful for a host to know whether or not the 399 default RFC 3484 (or soon to be 3484bis) policies are in effect or 400 not, and for there to be a 'cheap' way for the host to discover this. 402 Perhaps the biggest cause of policy change lies where the preferred 403 links or paths for certain destinations change frequently over time 404 as (typically) traffic engineering requirements change. In some 405 networks this may be a daily change, or change between states at 406 different times of day. It is not clear how common these cases are, 407 and thus further input is welcomed here. Our belief is that cases 408 where dynamic changes are used heavily are rare. 410 So, unless a site or network has rapidly changing traffic engineering 411 requirements, or includes a high number of mobile nodes where the 412 nodes are roaming to areas of the network with differing address 413 selection related policies, the frequency of updates is likely to be 414 relatively low. Most update requests will simply occur when a host 415 starts up, and such requests for policy will be little different in 416 frequency to other configuration requests. Other types of network 417 change that may require a host to change its RFC 3484 policy 418 behaviour are probably also likely to have associated changes with 419 other host configuration data. 421 6. Considerations when Obtaining Policy 423 When a policy change is made, or a host migrates to a part of the 424 network with different policies, that change of policy needs to be 425 conveyed to the host. It needs to be made available and applied 426 without restarting every affected host. 428 6.1. Changes in Available Address(es) 430 One might assume at first that when a host observes a change in its 431 addresses, it should re-obtain the selection policy, but this may not 432 always be the case. Not all policy changes are tied to a host 433 changing one or more addresses, though it may be acceptable to query 434 regardless for new policy (if a pull model is used) when address 435 information changes. 437 As described above, it may be sufficient for a host to know when a 438 policy is changed, or that perhaps the default policy is - or is not 439 - in effect in its current locale. 441 6.2. Timeliness 443 In many, but not all, cases a policy change will need to be 444 synchronised across a network. Thus there is a general issue of 445 timely and synchronised dissemination of new policy. If the policy 446 is distributed via the same mechanism that informs a host of a change 447 of address(es), the application of the policy should be synchronised 448 sufficiently with the address change. However, not all hosts may 449 receive the update information at the same time, e.g. where new 450 address assignments may be dependent on DHCP lease timers. 452 Where hosts use DHCPv6 for address information, in the absence of 453 some form of Reconfigure message, a host may see a delay in policy 454 changes being notified. One possible tool to help here is the DHCPv6 455 Lifetime Option (RFC4242) [RFC4242], which was originally introduced 456 to assist with network renumbering events. 458 6.3. Manual Configuration? 460 There are scenarios where a host may wish to ignore conveyed policy. 461 For example, the manager of a mobile node may not want to have its 462 preferences changed by a visited network. In such a case one might 463 argue that the mobile node should use MIPv6 with whatever its home 464 network policies are. 466 The implication again is that there could be value in having a flag 467 of some kind to inform a host whether network it is in uses the 468 default RFC 3484 policy, which would then allow each end system to 469 decide if it should get an (overriding) local policy or not. One 470 problem with this though is that some operating systems already 471 implement 'modified' RFC 3484 behaviour, so we would have to be sure 472 that all nodes have common understanding of what the 'default' is (in 473 principle, that all nodes implement any future revised RFC 3484 474 default policy table). 476 6.4. Policy Conflicts 478 In the case of a host operating in a single administrative domain, 479 consistent policy should be available from whichever policy 480 distribution mechanism provides the information. However, in 481 scenarios where a host is multi-addressed from multiple providers 482 (e.g. a SOHO network with differing DSL and cable providers, or a 483 user in a coffee shop initiating a VPN connection to their home 484 network) there is likely to be some conflicts in the received RFC 485 3484 policy information. 487 The question then is whether the policy update mechanism itself needs 488 to handle such potential conflicts, choosing one or ther other or 489 merging by some set of heuristics, or whether the policy update 490 mechansism should be viewed independently of the conflict handling. 491 The view of the design team was that distributing policy is a network 492 problem, while handling conflicts is a host problem. 494 An initial draft on handling policy conflicts has been released 495 separately [I-D.arifumi-6man-addr-select-conflict] given the topic is 496 beyond the scope of this draft. 498 7. Solution Space 500 In this section we make some initial observations on the possible 501 solution space. 503 7.1. Is default policy used? 505 There could be some mechanism to indicate to a host that the local 506 network has a modified RFC 3484 policy in use, and thus that a 507 revised policy table is available (and should be used). 508 Alternatively a host could simply always attempt to obtain local RFC 509 3484 policy on startup. Regardless, it should also be possible for a 510 host to detect that policy has changed (whether 'around' the host, or 511 due to the host being nomadic). The method to convey this chnage to 512 a host would depend on whether a push or pull configuration method is 513 used. 515 It is assumed by 'default' policy here we refer to the revised/ 516 updated RFC3484 specification, when that is produced. 518 7.2. Pull model 520 One potential solution is that a host uses a similar mechanism for 521 RFC 3484 policy updates as is used for obtaining other configuration 522 data, for example DHCPv6 [RFC3315]. For hosts using stateless 523 autoconfiguration, policy could be available via stateless DHCPv6 524 [RFC3736]. 526 There are also already some initial proposals from the IETF mif WG on 527 using DHCPv6 to deliver (mainly routing oriented) information to 528 hosts, e.g. [I-D.sun-mif-route-config-dhcp6], 529 [I-D.dec-dhcpv6-route-option], [I-D.sun-mif-address-policy-dhcp6] and 530 [I-D.sarikaya-mif-dhcpv6solution]. These methods assume entities 531 that have timely knowledge of routing information can provide equally 532 timely hints to hosts on address selection, via DHCPv6. At this 533 stage we believe that distributing RFC 3484 policy, as configured by 534 an administrator, is a more practical use of DHCPv6. If future 535 methods offer additional 'hints' based on routing information, this 536 becomes part of the 'policy conflict' problem to be solved. 538 The DHCP model allows individual nodes to potentially have differing 539 policy, even when on the same subnet. 541 7.3. Push model 543 For hosts only using stateless autoconfiguration, in environments 544 without DHCPv6, it can be argued that since the network is not 545 managed, there is not likely to be any 'managed' policy to push to 546 the hosts. In such environments hosts may perhaps more usefully use 547 techniques such as router hints to make informed selections, as 548 discussed later in this text. 550 It may of course be possible to piggy back policy information to a 551 host in a Router Advertisement message, though initial consensus 552 seems to be that this is a less attractive approach. However, we may 553 find that RAs may be a good place to indicate whether a default 554 policy is in place or not, to avoid hosts requesting non-existent 555 updates via DHCPv6. 557 7.4. Routing Hints 559 As mentioned above, if a host has routing hints available, it may be 560 able to make more informed selections. For example, a protocol could 561 be specified for a node to query an on-link or remote (e.g. edge) 562 router for 'hints'. Having hosts themselves participate in routing 563 is generally not desirable. At this stage we can simply note that 564 address selection might be simplified when some hint based on routing 565 state is provided to the end system, but such mechanisms are out of 566 scope for this text. 568 It is noted in [I-D.carpenter-renum-needs-work] that: 570 "In an environment where a site has more than one upstream link to 571 the outside world, the site might have more than one valid routing 572 prefix. In such cases, typically all valid routing prefixes within a 573 site will have the same prefix length. Also in such cases, it might 574 be desirable for hosts that obtain their addresses using DHCPv6 to 575 learn about the availability of upstream links dynamically, by 576 deducing from periodic IPv6 RA messages which routing prefixes are 577 currently valid. This application seems possible within the IPv6 578 Neighbour Discovery architecture, but does not appear to be clearly 579 specified anywhere." 581 The same thought seems relevant to address selection. There's no 582 point selecting a source address whose prefix is not being advertised 583 in RAs. 585 While routing and prefix hints may help a host make selection 586 decisions, we should consider to what extent we wish to 'burden' a 587 host with holding such information. If a host is to determine and 588 cache routing hints, this may require an update of RFC 3484 policy 589 table syntax to support preference for address pairs. 591 7.5. Conflicts/Merging Policies 593 As discussed above, the solution used to allow a host to determine 594 its address selection policy should be considered separately from the 595 heuristics a host may use to choose how to resolve any policy 596 conflicts where configurations are received from multiple sources. 597 We believe the conflict handling should be progressed in a separate 598 text, but have included some initial considerations here. 600 For whatever mechanism is used to distribute RFC 3484 policy, it is 601 not yet clear whether entire policy tables will be made available, or 602 simply differences to the 'default', and thus whether policies may 603 need to be merged, or overridden. Some policy conflicts will be 604 unresolvable, e.g. one prefers IPv4 over IPv6, the other vice-versa. 605 It may be simpler, though less efficient, for whole policy tables to 606 be distributed, to avoid the merger problem. 608 One option may be to split the policy table into destination address 609 selection and source address selection tables, with the policy 610 distribution only updating the source address selection. Whether 611 this might make merging policies simpler or in fact more complex 612 would require further study. 614 It may also be possible to indicate some priority value for a policy, 615 e.g. the priority of the interface it is received on. Or if there 616 are multiple policies in conflict, a host could simply choose to fall 617 back to use the default RFC 3484 policy. 619 A host also needs to know how to decide when to accept a policy. We 620 could simplify the discussion by assuming a host is located in and 621 only nomadic within a single site with one administrative controlling 622 entity. 624 8. On RFC3484 Default Policies 626 RFC 3484 includes text about mechanisms for changing policy, having 627 'policy hooks' and having a configurable policy table. The 628 implication is that defaults can be changed, and the text gives 629 examples of this in Section 10. However, issues with RFC 3484 are 630 broader that just policy table updates - it remains the case that 631 some operational issues with RFC 3484 are not just related to the 632 table, but on rules themselves, e.g. longest prefix match (affecting 633 DNS round robin as described in [RFC5220]). 635 While discussing default policy, we noted that the word 'default' has 636 to be carefully defined, and also what the scope of this 'default' 637 is. The default policy should be whatever RFC 3484, or its -bis 638 version, states. At present some operating systems have already 639 modified their default, based on operational feedback (e.g. on ULAs, 640 on Teredo prefixes, or on the DNS round-robin problem). Currently we 641 assume RFC3484 and changes to it will remain node-specific. 643 It certainly seems the case that the issues raised in RFC 5220, and 644 discussed in [I-D.arifumi-6man-rfc3484-revise] mean that an update of 645 RFC 3484 is required, if only because some of the issues (as 646 highlighted earlier) cannot be addressed by updating the policy table 647 alone. An update would also give us some hope that all operating 648 systems might have a common 'default'. 650 We do not note any specific comments here on how RFC 3484 should be 651 updated. Other drafts have made suggestions. There are some 652 discussions on ideas however, e.g. on the semantics of labels, and in 653 adding ULAs explicitly to the default policy table. 655 There have also been new issues identified, e.g. on how one 656 differentiates between IPv4+NAT access or IPv6 transitional access 657 (e.g. via Teredo) to a dual-stack destination (the IPv4 private 658 address inside the NAT is implicitly global, although its explicit 659 scope is local) [I-D.denis-v6ops-nat-addrsel]. This illustrates that 660 new issues may continue to be identified through growing IPv6 661 operational experience. 663 It is hard to predict exactly what features people will want to add 664 to address selection algorithms in the future. Ideally we should not 665 preclude future flexibility. It seems clear that any RFC 3484 update 666 has two aspects: one that uses the existing policy table capability, 667 and one that might change associated algorithms. 669 9. Conclusions 671 We believe the general scope of this text applies to site and 672 enterprise networks, where an administrator may need to change 673 policies over time, but that it includes nomadic nodes within the 674 site, which may migrate to different parts of the site where 675 different policies are required. We believe a key outcome of this 676 text should be progression of a solution to allow an enterprise 677 network manager to configure their hosts with address selection 678 policies that differ from the RFC 3484 default, across all or part of 679 their network, and possibly changing polciy with time. 681 It is clear there may be environments which might introduce 682 conflicting policies from different administrative domains, e.g. a 683 SOHO network with two ISP links, or an enterprise node running a VPN 684 to a remote network. We conclude that the policy distribution 685 mechanism is a network task, while policy conflict handling is a host 686 task, and thus argue that we should progress the policy distribution 687 solution while analysing conflict handling (which is not unique to 688 this domain) in a separate text. 690 There is clearly a need to revise RFC 3484, to create a new default 691 policy table for address selection, and to improve non policy table 692 algorithms. This should be expedited. We also note that RFC 3484 is 693 currently defined on a per-node, not per-interface basis, which we 694 believe should remain the status quo for the scope of this work. The 695 node-wide problem is destination address selection. 697 The scope of this text includes issues affecting the design of a 698 protocol to allow a host's RFC 3484 policy table to be updated. From 699 discussion of update triggers/scenarios, we believe rapid updates are 700 unlikely unless a node is in a network which has (very) dynamic 701 external traffic engineering, or many nodes are mobile between parts 702 of the network with differing policy. It's thus probably appropriate 703 to use a similar method to obtain RFC 3484 policy as to obtain other 704 configuration data. 706 In terms of push or pull-based methods for policy distribution, our 707 discussions suggest that a push-based hint to hosts as to whether 708 they are in a network where a (non default) local policy applies or 709 not could be useful. This might be indicated via a RA option. In 710 terms of obtaining policy, a pull-based solution, such as DHCPv6, may 711 be appropriate in managed environments (where managed non-default 712 policies are most likely to be in effect). DHCPv6 is also preferable 713 if individual hosts on a subnet require different policies. 715 Further comments on this draft are welcomed. 717 10. Security Considerations 719 There are no extra Security consideration for this document. 721 11. IANA Considerations 723 There are no extra IANA consideration for this document. 725 12. Acknowledgements 727 The design team working on this draft is: Marcelo Bagnulo Braun, Marc 728 Blanchet, Tim Chown, Francis Dupont, Tim Enos, TJ Evans, Brian 729 Haberman, Tony Hain, Ruri Hiromi, Suresh Krishnan, Arifumi Matsumoto, 730 Janos Mohacsi, Sebastien Roy, Teemu Savolainen, Fujisaki Tomohiro, 731 and John Zhao. 733 We also acknowledge comments received from IETF WG mail lists, 734 including those by Brian Carpenter and Dave Thaler. 736 13. Informative References 738 [RFC3484] Draves, R., "Default Address Selection for Internet 739 Protocol version 6 (IPv6)", RFC 3484, February 2003. 741 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 742 and M. Carney, "Dynamic Host Configuration Protocol for 743 IPv6 (DHCPv6)", RFC 3315, July 2003. 745 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 746 (DHCP) Service for IPv6", RFC 3736, April 2004. 748 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 749 Time Option for Dynamic Host Configuration Protocol for 750 IPv6 (DHCPv6)", RFC 4242, November 2005. 752 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 753 "Problem Statement for Default Address Selection in Multi- 754 Prefix Environments: Operational Issues of RFC 3484 755 Default Rules", RFC 5220, July 2008. 757 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 758 "Requirements for Address Selection Mechanisms", RFC 5221, 759 July 2008. 761 [I-D.ietf-6man-addr-select-sol] 762 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution 763 approaches for address-selection problems", 764 draft-ietf-6man-addr-select-sol-03 (work in progress), 765 March 2010. 767 [I-D.arifumi-6man-rfc3484-revise] 768 Matsumoto, A., Fujisaki, T., and R. Hiromi, "Things To Be 769 Considered for RFC 3484 Revision", 770 draft-arifumi-6man-rfc3484-revise-02 (work in progress), 771 October 2009. 773 [I-D.fujisaki-dhc-addr-select-opt] 774 Fujisaki, T., Matsumoto, A., and R. Hiromi, "Distributing 775 Address Selection Policy using DHCPv6", 776 draft-fujisaki-dhc-addr-select-opt-09 (work in progress), 777 March 2010. 779 [I-D.blanchet-mif-problem-statement] 780 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 781 Statement", draft-blanchet-mif-problem-statement-01 (work 782 in progress), June 2009. 784 [I-D.dec-dhcpv6-route-option] 785 Dec, W. and R. Johnson, "DHCPv6 Route Option", 786 draft-dec-dhcpv6-route-option-03 (work in progress), 787 March 2010. 789 [I-D.sun-mif-address-policy-dhcp6] 790 Sun, T., Deng, H., and X. Duan, "Address Selection Policy 791 Configuration by DHCPv6 Option", 792 draft-sun-mif-address-policy-dhcp6-01 (work in progress), 793 March 2009. 795 [I-D.sarikaya-mif-dhcpv6solution] 796 Sarikaya, B., Xia, F., and P. Seite, "DHCPv6 Extension for 797 Configuring Hosts with Multiple Interfaces", 798 draft-sarikaya-mif-dhcpv6solution-04 (work in progress), 799 July 2010. 801 [I-D.sun-mif-route-config-dhcp6] 802 Sun, T. and H. Deng, "Route Configuration by DHCPv6 Option 803 for Hosts with Multiple Interfaces", 804 draft-sun-mif-route-config-dhcp6-01 (work in progress), 805 March 2009. 807 [I-D.arifumi-6man-addr-select-conflict] 808 Matsumoto, A., Fujisaki, T., and R. Hiromi, 809 "Considerations of address selection policy conflicts", 810 draft-arifumi-6man-addr-select-conflict-02 (work in 811 progress), March 2010. 813 [I-D.denis-v6ops-nat-addrsel] 814 Denis-Courmont, R., "Problems with IPv6 source address 815 selection and IPv4 NATs", draft-denis-v6ops-nat-addrsel-00 816 (work in progress), February 2009. 818 [I-D.carpenter-renum-needs-work] 819 Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 820 still needs work", draft-carpenter-renum-needs-work-05 821 (work in progress), January 2010. 823 [I-D.troan-multihoming-without-nat66] 824 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 825 Wing, "IPv6 Multihoming without Network Address 826 Translation", draft-troan-multihoming-without-nat66-00 827 (work in progress), May 2010. 829 Author's Address 831 Tim Chown (editor) 832 University of Southampton 833 Southampton, Hampshire SO17 1BJ 834 United Kingdom 836 Email: tjc@ecs.soton.ac.uk