idnits 2.17.1 draft-ietf-6man-addr-select-considerations-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 19, 2009) is 5302 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-ietf-6man-addr-select-sol-02 == Outdated reference: A later version (-03) exists of draft-arifumi-6man-rfc3484-revise-01 == Outdated reference: A later version (-09) exists of draft-fujisaki-dhc-addr-select-opt-08 == Outdated reference: A later version (-05) exists of draft-dec-dhcpv6-route-option-01 == Outdated reference: A later version (-04) exists of draft-sarikaya-mif-dhcpv6solution-02 == Outdated reference: A later version (-03) exists of draft-sun-mif-route-config-dhcp6-01 == Outdated reference: A later version (-02) exists of draft-arifumi-6man-addr-select-conflict-00 == Outdated reference: A later version (-05) exists of draft-carpenter-renum-needs-work-03 Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Operations T. Chown, Ed. 3 Internet-Draft University of Southampton 4 Intended status: Informational October 19, 2009 5 Expires: April 22, 2010 7 Considerations for IPv6 Address Selection Policy Changes 8 draft-ietf-6man-addr-select-considerations-00 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on April 22, 2010. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 Where the source and/or destination node of an IPv6 communication is 57 multi-addressed, a mechanism is required for the initiating node to 58 select the most appropriate address pair for the communication. RFC 59 3484 (IPv6 Default Address Selection) [RFC3484] defines such a 60 mechanism for nodes to perform source and destination address 61 selection. While RFC3484 recognised the need for implementations to 62 be able to change the policy table, it did not define how this could 63 be achieved. Requirements have now emerged for administrators to be 64 able to dynamically change the RFC 3484 policy tables from a central 65 control point, and for nomadic hosts to be able to obtain the policy 66 for the network that they are currently attached to without manual 67 user intervention. This text discusses considerations for such 68 policy changes, including examples of cases where a change of policy 69 is required, and the likely frequency of such policy changes. This 70 text also includes some discussion on the need to also update RFC 71 3484, where default policies are currently defined. 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 . . . . . . . . . . . . . . . . . . . . . . . . 10 88 6.3. Manual Configuration? . . . . . . . . . . . . . . . . . . 11 89 6.4. Policy Conflicts . . . . . . . . . . . . . . . . . . . . . 11 90 7. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 11 91 7.1. Is default policy used? . . . . . . . . . . . . . . . . . 12 92 7.2. Pull model . . . . . . . . . . . . . . . . . . . . . . . . 12 93 7.3. Push model . . . . . . . . . . . . . . . . . . . . . . . . 12 94 7.4. Routing Hints . . . . . . . . . . . . . . . . . . . . . . 13 95 7.5. Conflicts/Merging Policies . . . . . . . . . . . . . . . . 13 96 8. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . 14 97 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 99 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 100 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 101 13. Informative References . . . . . . . . . . . . . . . . . . . . 16 102 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 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 nomadic hosts within a network for which policies may vary 113 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.arifumi-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.fujisaki-dhc-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 4. Drivers for Policy Changes 173 If we wish to determine how frequent address selection policy changes 174 are likely to be, we need to understand why such policies might need 175 to be changed, for particular sites or networks. 177 One reference text for potential drivers for policy change is RFC 178 5220, in which operational issues with the existing policies 179 described in RFC 3484 are listed. Each subsection of this document 180 gives a reason why the existing rules or policy tables in RFC 3484 181 may not be sufficient in certain cases. There have been some 182 significant changes to IPv6 since RFC 3484 was drafted which have 183 impacted the RFC, e.g. the introduction of Unique Local Addresses 184 (ULAs), and concerns about the impact of using longest prefix 185 matching on (DNS) round-robin load balancing. 187 In summary, the issues raised in RFC 5220 were: 189 o Multiple Routers on a Single Interface 191 o Ingress Filtering 193 o Half-Closed Network Problem (*) 195 o Combined Use of Global and ULA addresses (*) 196 o Site Renumbering (*) 198 o Multicast Source Address Selection (*) 200 o Temporary Address Selection 202 o IPv4 or IPv6 Prioritization (*) 204 o ULA and IPv4 Dual-Stack Environment (*) 206 o ULA or Global Prioritization (*) 208 The authors of RFC 5220 noted which of these issues can be solved 209 just by changes to the RFC 3484 policy table, marked (*) above, and 210 which cannot. It is interesting to note that issues largely related 211 to internal networking and (administrative) policy decisions can be 212 handled this way. However some issues need changes beyond just 213 policy table updates. 215 4.1. Internal vs External Triggers 217 When considering drivers or triggers that may lead to a requirement 218 for the policy to change, we can divide the problem space into those 219 drivers that are external to a site or network and those internal to 220 it. In the case of the first two examples above, a dynamic policy 221 table update may be required by externally driven routing changes, 222 assuming the site uses a dynamic routing protocol intra-site and the 223 routing protocol is configured to reflect changes of extra-site 224 routing topology. 226 If a site is multihomed using BGP and advertising a single prefix 227 upstream, then no policy table manipulation is required for global 228 address preferences. However where a site is multihomed by receiving 229 a prefix from each upstream provider, each host will have multiple 230 addresses and many need policy table manipulation. In such a case, 231 the policy table of hosts may need to be updated according to the 232 routing policy. 234 It should be noted that we have other mechanisms for dynamic routing 235 topology change, for example deprecating one of the advertised 236 prefixes, e.g. when one of the upstream links has a problem. But 237 such mechanisms may only help in some cases, and do not remove the 238 need for agility in the RFC 3484 policy. 240 Other examples of external factors include a new transition mechanism 241 being defined (e.g. as with the emergence of Teredo using 2001::/32 242 as assigned by IANA) and its inclusion being required in the policy 243 table (at the time of writing Teredo is not included in RFC 3484, 244 though some operating systems have added it), a new address block 245 being defined, or a site renumbering event that could be triggered by 246 an upstream provider's actions. 248 4.2. Administratively Triggered Changes 250 The other examples above are, in the general case, where the site 251 administrator chooses to change a local policy and in doing so 252 triggers the need for policy table updates. Some of these changes 253 one might assume to be set once, and to change rarely, for example: 255 o Setting priority use of IPv6 over IPv4 (or vice versa). 257 o Setting priority use of ULAs over globals (or vice versa). 259 o Setting priority use of privacy addresses over DNS-published 260 globals (or vice versa). 262 o An internal network renumbering occurs, perhaps due to a site 263 expanding. 265 o The nature of the external connectivity through multiple ISPs 266 requires specific additional information (policy) to be delivered 267 to certain hosts (as discussed in 2.1.3 in RFC 5220). 269 o Disabling longest-prefix match functions to facilitate round-robin 270 load balancing. 272 However it may be the case that different parts of a site have 273 different policies, or policies are changed in a rolling fashion 274 across a site over time as IPv6 and/or ULAs are introduced (for 275 example). This may happen where the administrator prefers a gradual 276 introduction of new policy in a phased operation across a site, 277 rather than changing policy across the whole site in one operation. 279 Other administrative changes may occur more frequently, e.g.: 281 o Routing tables and forwarding tables change dynamically. 283 o A different provider (link) is preferred for a given destination. 285 It's possible that provider links may vary on a daily basis, or by 286 time of day. The frequency of such policy changes will depend on the 287 frequency that the administrator wishes to change the implied traffic 288 engineering policies. 290 4.3. Start-up vs Running Changes 292 When a host starts up it may be configured with the default RFC 3484 293 policies. At this stage a number of addresses may be configured on a 294 number of interfaces on the host. At this time it may be desirable 295 for the host to be able to receive the site-specific policy updates 296 as a start-up override from the RFC 3484 defaults. 298 Other policy changes may later be required while the host is running. 299 Ideally the same protocol should be used for the start-up and running 300 state update mechanism. 302 4.4. Nomadic Nodes 304 A host may be nomadic within a site and as a result it may see the 305 preferred policy change depending on the host's topological location 306 within that site. Such a host should be capable of receiving policy 307 updates in a timely fashion as it migrates within the network. 309 While this may be one case of 'running changes' described above, the 310 policy changes are required due to the host's new point of 311 attachment, not changes of policy to the current point of attachment. 312 The frequency of updates are thus depend ant on the frequency of host 313 mobility to parts of the network that have differing policies. 315 4.5. Multiple Interface Nodes 317 In considering scenarios where hosts may be multi-addressed and 318 require policy to assist in address selection, the issue of hosts 319 with multiple interfaces arises. 321 A host may have a variety of reasons to have multiple interfaces. It 322 may for example have WiFi and 3G interfaces, and be capable of 323 sending or receiving data over either interface. In some cases these 324 interfaces may fall within the same administrative domain (ISP) and 325 in some cases they may not. Another example would be the case of a 326 host with a VPN connection established, where address selection may 327 be affected by the choice of whether the VPN connection is used or 328 not. 330 This is clearly an important problem today, but we note that RFC 3484 331 is currently defined as a per-node, not per-interface, mechanism. 332 However, for RFC 3484, and its potential update mechanisms, to be 333 applicable to typical 'real world' usage patterns, we should consider 334 the multiple interface scenarios. 336 In the case where a host has multiple interfaces there are two likely 337 scenarios: 339 o Wired and wireless interfaces - in this case the operating system 340 just needs to pick one interface and use it. 342 o Normal and VPN interfaces - here the default should be the normal 343 interface; the VPN interface should only be used for destinations 344 associated with the VPN. 346 It has been suggested that an RFC 3484 policy table is required on a 347 per-interface basis, though the choice of interface may itself be 348 determined by the (destination) address selection process. As stated 349 above, RFC 3484's policy table is currently defined to be node-wide. 350 The node-wide problem is destination address selection when the 351 source address is implied from a selected interface. 353 We note that there are some new, initial drafts published recently on 354 the multiple interface problem [I-D.blanchet-mif-problem-statement], 355 and on a number of possible DHCPv6 extensions, e.g. to inform hosts 356 about routing information to assist the selection process 357 [I-D.dec-dhcpv6-route-option], [I-D.sun-mif-address-policy-dhcp6], 358 [I-D.sarikaya-mif-dhcpv6solution]. Another new draft proposes a 359 DHCPv6 option to convey policy directly to a host 360 [I-D.sun-mif-route-config-dhcp6]. These drafts fall within the remit 361 of the new IETF mif WG, which at the time of writing was only 362 recently formed. We note that the mif WG may produce relevant work 363 with respect to the analysis of RFC 3484 policy changes, but at this 364 stage no such output exists for inclusion. 366 5. How Dynamic? 368 The discussion above suggests that many of the potential triggers for 369 policy table changes are 'one-off' in nature, i.e. a site makes a 370 one-time policy change. It is thus unlikely that such administrative 371 changes will be frequent. 373 There are some cases where updates may be required to be more 374 frequent. In the example of a site which is implementing the gradual 375 introduction of new policy across its network, while the frequency of 376 changes may be relatively high, there is still probably only one or a 377 small number of changes per host. 379 There may be a higher rate of policy changes within a site if there 380 are nomadic hosts within the site, and these are roaming frequently 381 to parts of the network where differing policies are in effect. In 382 such cases it may be useful for a host to know whether or not the 383 default RFC 3484 (or soon to be 3484bis) policies are in effect or 384 not, and for there to be a 'cheap' way for the host to discover this. 386 Perhaps the biggest cause of policy change lies where the preferred 387 links or paths for certain destinations change frequently over time 388 as (typically) traffic engineering requirements change. In some 389 networks this may be a daily change, or change between states at 390 different times of day. It is not clear how common these cases are, 391 and thus further input is welcomed here. Our belief is that cases 392 where dynamic changes are used heavily are rare. 394 So, unless a site or network has rapidly changing traffic engineering 395 requirements, or includes a high number of mobile nodes where the 396 nodes are roaming to areas of the network with differing address 397 selection related policies, the frequency of updates is likely to be 398 relatively low. Most update requests will simply occur when a host 399 starts up, and such requests for policy will be little different in 400 frequency to other configuration requests. Other types of network 401 change that may require a host to change its RFC 3484 policy 402 behaviour are probably also likely to have associated changes with 403 other host configuration data. 405 6. Considerations when Obtaining Policy 407 When a policy change is made, or a host migrates to a part of the 408 network with different policies, that change of policy needs to be 409 conveyed to the host. It needs to be made available and applied 410 without restarting every affected host. 412 6.1. Changes in Available Address(es) 414 One might assume at first that when a host observes a change in its 415 addresses, it should re-obtain the selection policy, but this may not 416 always be the case. Not all policy changes are tied to a host 417 changing one or more addresses, though it may be acceptable to query 418 regardless for new policy (if a pull model is used) when address 419 information changes. 421 As described above, it may be sufficient for a host to know when a 422 policy is changed, or that perhaps the default policy is - or is not 423 - in effect in its current locale. 425 6.2. Timeliness 427 In many, but not all, cases a policy change will need to be 428 synchronised across a network. Thus there is a general issue of 429 timely and synchronised dissemination of new policy. If the policy 430 is distributed via the same mechanism that informs a host of a change 431 of address(es), the application of the policy should be synchronised 432 sufficiently with the address change. However, not all hosts may 433 receive the update information at the same time, e.g. where new 434 address assignments may be dependent on DHCP lease timers. 436 Where hosts use DHCPv6 for address information, in the absence of 437 some form of Reconfigure message, a host may see a delay in policy 438 changes being notified. One possible tool to help here is the DHCPv6 439 Lifetime Option (RFC4242) [RFC4242], which was originally introduced 440 to assist with network renumbering events. 442 6.3. Manual Configuration? 444 There are scenarios where a host may wish to ignore conveyed policy. 445 For example, the manager of a mobile node may not want to have its 446 preferences changed by a visited network. In such a case one might 447 argue that the mobile node should use MIPv6 with whatever its home 448 network policies are. 450 The implication again is that there could be value in having a flag 451 of some kind to inform a host whether network it is in uses the 452 default RFC 3484 policy, which would then allow each end system to 453 decide if it should get an (overriding) local policy or not. One 454 problem with this though is that some operating systems already 455 implement 'modified' RFC 3484 behaviour, so we would have to be sure 456 that all nodes have common understanding of what the 'default' is (in 457 principle, that all nodes implement any future revised RFC 3484 458 default policy table). 460 6.4. Policy Conflicts 462 In the case of a host operating in a single administrative domain, 463 consistent policy should be available from whichever policy 464 distribution mechanism provides the information. However, in 465 scenarios where a host is multi-addressed from multiple providers 466 (e.g. a SOHO network with differing DSL and cable providers) there is 467 likely to be some conflicts in the received RFC 3484 policy 468 information. For the policy update mechanism to be applicable in the 469 general case, we need to include potential policy conflicts from such 470 scenarios. An initial draft on handling such policy conflicts has 471 been released [I-D.arifumi-6man-addr-select-conflict]. 473 7. Solution Space 475 In this section we make some initial observations on the possible 476 solution space. 478 7.1. Is default policy used? 480 There could be some mechanism to indicate to a host that the local 481 network has a modified RFC 3484 policy in use, and thus that a 482 revised policy table is available (and should be used). 483 Alternatively a host could simply attempt to obtain local RFC 3484 484 policy on startup regardless. Regardless, it should also be possible 485 for a host to detect that policy has changed (whether 'around' the 486 host, or due to the host being nomadic). 488 It is assumed by 'default' policy here we refer to the revised/ 489 updated RFC3484 specification, when that is produced. The question 490 as to how a non-default policy is indicated may be steered by which 491 we believe to be the common case in the longer term - hosts that need 492 local policy changes, or hosts that do not. If an RA bit is used to 493 indicate whether a local policy is available, we avoid hosts 494 requesting potentially non-existent policy tables (or copies of 495 default tables they already have) forever. 497 7.2. Pull model 499 One potential solution is that a host uses a similar mechanism for 500 RFC 3484 policy updates as is used for obtaining other configuration 501 data, for example DHCPv6 [RFC3315]. For hosts using stateless 502 autoconfiguration, policy could be available via stateless DHCPv6 503 [RFC3736]. 505 There are also already some initial proposals from the IETF mif WG on 506 using DHCPv6 to deliver (mainly routing oriented) information to 507 hosts, e.g. [I-D.sun-mif-route-config-dhcp6], 508 [I-D.dec-dhcpv6-route-option], [I-D.sun-mif-address-policy-dhcp6] and 509 [I-D.sarikaya-mif-dhcpv6solution]. These methods assume entities 510 that have timely knowledge of routing information can provide equally 511 timely hints to hosts on address selection, via DHCPv6. At this 512 stage we believe that distributing RFC 3484 policy, as configured by 513 an administrator, is a more practical use of DHCPv6. If future 514 methods offer additional 'hints' based on routing information, this 515 becomes part of the 'policy conflict' problem to be solved. 517 The DHCP model allows individual nodes to potentially have differing 518 policy, even when on the same subnet. 520 7.3. Push model 522 For hosts only using stateless autoconfiguration, in environments 523 without DHCPv6, it can be argued that since the network is not 524 managed, there is not likely to be any 'managed' policy to push to 525 the hosts. In such environments hosts may perhaps more usefully use 526 techniques such as router hints to make informed selections, as 527 discussed later in this text. 529 It may of course be possible to piggy back policy information to a 530 host in a Router Advertisement message, though initial consensus 531 seems to be that this is a less attractive approach. However, we may 532 find that RAs may be a good place to indicate whether a default 533 policy is in place or not, to avoid hosts requesting non-existent 534 updates via DHCPv6. 536 7.4. Routing Hints 538 As mentioned above, if a host has routing hints available, it may be 539 able to make more informed selections. For example, a protocol could 540 be specified for a node to query an on-link or remote (e.g. edge) 541 router for 'hints'. Having hosts themselves participate in routing 542 is generally not desirable. At this stage we can simply note that 543 address selection might be simplified when some hint based on routing 544 state is provided to the end system, but such mechanisms are out of 545 scope for this text. 547 It is noted in [I-D.carpenter-renum-needs-work] that: 549 "In an environment where a site has more than one upstream link to 550 the outside world, the site might have more than one valid routing 551 prefix. In such cases, typically all valid routing prefixes within a 552 site will have the same prefix length. Also in such cases, it might 553 be desirable for hosts that obtain their addresses using DHCPv6 to 554 learn about the availability of upstream links dynamically, by 555 deducing from periodic IPv6 RA messages which routing prefixes are 556 currently valid. This application seems possible within the IPv6 557 Neighbour Discovery architecture, but does not appear to be clearly 558 specified anywhere." 560 The same thought seems relevant to address selection. There's no 561 point selecting a source address whose prefix is not being advertised 562 in RAs. 564 While routing and prefix hints may help a host make selection 565 decisions, we should consider to what extent we wish to 'burden' a 566 host with holding such information. 568 7.5. Conflicts/Merging Policies 570 For whatever mechanism is used to distribute RFC 3484 policy, it is 571 not yet clear whether entire policy tables will be made available, or 572 simply differences to the 'default', and thus whether policies may 573 need to be merged, or overridden. Some policy conflicts will be 574 unresolvable, e.g. one prefers IPv4 over IPv6, the other vice-versa. 575 It may be simpler, though less efficient, for whole policy tables to 576 be distributed, to avoid the merger problem. 578 One option may be to split the policy table into destination address 579 selection and source address selection tables, with the policy 580 distribution only updating the source address selection. Whether 581 this might make merging policies simpler or in fact more complex 582 would require further study. 584 It may also be possible to indicate some priority value for a policy, 585 e.g. the priority of the interface it is received on. Or if there 586 are multiple policies in conflict, a host could simply choose to fall 587 back to use the default RFC 3484 policy. 589 A host also needs to know how to decide when to accept a policy. We 590 could simplify the discussion by assuming a host is located in and 591 only nomadic within a single site with one administrative controlling 592 entity. 594 8. On RFC3484 Default Policies 596 RFC 3484 includes text about mechanisms for changing policy, having 597 'policy hooks' and having a configurable policy table. The 598 implication is that defaults can be changed, and the text gives 599 examples of this in Section 10. However, issues with RFC 3484 are 600 broader that just policy table updates - it remains the case that 601 some operational issues with RFC 3484 are not just related to the 602 table, but on rules themselves, e.g. longest prefix match (affecting 603 DNS round robin as described in [RFC5220]). 605 While discussing default policy, we noted that the word 'default' has 606 to be carefully defined, and also what the scope of this 'default' 607 is. The default policy should be whatever RFC 3484, or its -bis 608 version, states. At present some operating systems have already 609 modified their default, based on operational feedback (e.g. on ULAs, 610 on Teredo prefixes, or on the DNS round-robin problem). Currently we 611 assume RFC3484 and changes to it will remain node-specific. 613 It certainly seems the case that the issues raised in RFC 5220, and 614 discussed in [I-D.arifumi-6man-rfc3484-revise] mean that an update of 615 RFC 3484 is required, if only because some of the issues (as 616 highlighted earlier) cannot be addressed by updating the policy table 617 alone. An update would also give us some hope that all operating 618 systems might have a common 'default'. 620 We do not note any specific comments here on how RFC 3484 should be 621 updated. Other drafts have made suggestions. There are some 622 discussions on ideas however, e.g. on the semantics of labels, and in 623 adding ULAs explicitly to the default policy table. 625 There have also been new issues identified, e.g. on how one 626 differentiates between IPv4+NAT access or IPv6 transitional access 627 (e.g. via Teredo) to a dual-stack destination (the IPv4 private 628 address inside the NAT is implicitly global, although its explicit 629 scope is local) [I-D.denis-v6ops-nat-addrsel]. This illustrates that 630 new issues may continue to be identified through growing IPv6 631 operational experience. 633 It is hard to predict exactly what features people will want to add 634 to address selection algorithms in the future. Ideally we should not 635 preclude future flexibility. It seems clear that any RFC 3484 update 636 has two aspects: one that uses the existing policy table capability, 637 and one that might change associated algorithms. 639 9. Conclusions 641 We believe the general scope of this text applies to site and 642 enterprise networks, where an administrator may need to change 643 policies over time, but that it includes nomadic nodes within the 644 site, which may migrate to different parts of the site where 645 different policies are required. However, we do not preclude other 646 environments which might, in particular, introduce (partially or 647 more) conflicting policies from different administrative domains, 648 e.g. in the SOHO space. We include multiple interface nodes in the 649 discussion, and note there are two general cases, namely wired/air 650 (or wlan/3G) interface, and normal/VPN interfaces, for which 651 different solutions are likely to apply. 653 There is clearly a need to revise RFC 3484, to create a new default 654 policy table for address selection, and to improve non policy table 655 algorithms. This should be expedited. We also note that RFC 3484 is 656 currently defined on a per-node, not per-interface basis, which we 657 believe should remain the status quo for the scope of this work. The 658 node-wide problem is destination address selection. 660 The scope of this text includes issues affecting the design of a 661 protocol to allow a host's RFC 3484 policy table to be updated. From 662 discussion of update triggers/scenarios, we believe rapid updates are 663 unlikely unless a node is in a network which has (very) dynamic 664 external traffic engineering, or many nodes are mobile between parts 665 of the network with differing policy. It's thus probably appropriate 666 to use a similar method to obtain RFC 3484 policy as to obtain other 667 configuration data. 669 Hosts may receive conflicting policy updates in some cases, 670 particularly where they receive information from different 671 administrative domains; some initial work in analysing the conflict 672 scenarios is underway. 674 In terms of push or pull-based methods for policy distribution, our 675 discussions suggest that a push-based hint to hosts as to whether 676 they are in a network where a (non default) local policy applies or 677 not could be useful. This might be indicated via a RA option. In 678 terms of obtaining policy, a pull-based solution, such as DHCPv6, may 679 be appropriate in managed environments (where managed non-default 680 policies are most likely to be in effect). DHCPv6 is also preferable 681 if individual hosts on a subnet require different policies. 683 Further comments on this draft are welcomed. 685 10. Security Considerations 687 There are no extra Security consideration for this document. 689 11. IANA Considerations 691 There are no extra IANA consideration for this document. 693 12. Acknowledgements 695 The design team working on this draft is: Marcelo Bagnulo Braun, Marc 696 Blanchet, Tim Chown, Francis Dupont, Tim Enos, TJ Evans, Brian 697 Haberman, Tony Hain, Ruri Hiromi, Suresh Krishnan, Arifumi Matsumoto, 698 Janos Mohacsi, Sebastien Roy, Teemu Savolainen, Fujisaki Tomohiro, 699 and John Zhao. 701 We also acknowledge comments received from IETF WG mail lists, 702 including those by Brian Carpenter and Dave Thaler. 704 13. Informative References 706 [RFC3484] Draves, R., "Default Address Selection for Internet 707 Protocol version 6 (IPv6)", RFC 3484, February 2003. 709 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 710 and M. Carney, "Dynamic Host Configuration Protocol for 711 IPv6 (DHCPv6)", RFC 3315, July 2003. 713 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 714 (DHCP) Service for IPv6", RFC 3736, April 2004. 716 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 717 Time Option for Dynamic Host Configuration Protocol for 718 IPv6 (DHCPv6)", RFC 4242, November 2005. 720 [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 721 "Problem Statement for Default Address Selection in Multi- 722 Prefix Environments: Operational Issues of RFC 3484 723 Default Rules", RFC 5220, July 2008. 725 [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 726 "Requirements for Address Selection Mechanisms", RFC 5221, 727 July 2008. 729 [I-D.ietf-6man-addr-select-sol] 730 Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 731 "Solution approaches for address-selection problems", 732 draft-ietf-6man-addr-select-sol-02 (work in progress), 733 July 2009. 735 [I-D.arifumi-6man-rfc3484-revise] 736 Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, 737 "Things To Be Considered for RFC 3484 Revision", 738 draft-arifumi-6man-rfc3484-revise-01 (work in progress), 739 March 2009. 741 [I-D.fujisaki-dhc-addr-select-opt] 742 Fujisaki, T., Matsumoto, A., and R. Hiromi, "Distributing 743 Address Selection Policy using DHCPv6", 744 draft-fujisaki-dhc-addr-select-opt-08 (work in progress), 745 October 2009. 747 [I-D.blanchet-mif-problem-statement] 748 Blanchet, M. and P. Seite, "Multiple Interfaces Problem 749 Statement", draft-blanchet-mif-problem-statement-01 (work 750 in progress), June 2009. 752 [I-D.dec-dhcpv6-route-option] 753 Dec, W. and R. Johnson, "DHCPv6 Route Option", 754 draft-dec-dhcpv6-route-option-01 (work in progress), 755 March 2009. 757 [I-D.sun-mif-address-policy-dhcp6] 758 Sun, T., Deng, H., and X. Duan, "Address Selection Policy 759 Configuration by DHCPv6 Option", 760 draft-sun-mif-address-policy-dhcp6-01 (work in progress), 761 March 2009. 763 [I-D.sarikaya-mif-dhcpv6solution] 764 Sarikaya, B., Xia, F., and P. Seite, "DHCPv6 Extension for 765 Configuring Hosts with Multiple Interfaces", 766 draft-sarikaya-mif-dhcpv6solution-02 (work in progress), 767 September 2009. 769 [I-D.sun-mif-route-config-dhcp6] 770 Sun, T. and H. Deng, "Route Configuration by DHCPv6 Option 771 for Hosts with Multiple Interfaces", 772 draft-sun-mif-route-config-dhcp6-01 (work in progress), 773 March 2009. 775 [I-D.arifumi-6man-addr-select-conflict] 776 Matsumoto, A., Fujisaki, T., and R. Hiromi, 777 "Considerations of address selection policy conflicts", 778 draft-arifumi-6man-addr-select-conflict-00 (work in 779 progress), July 2009. 781 [I-D.denis-v6ops-nat-addrsel] 782 Denis-Courmont, R., "Problems with IPv6 source address 783 selection and IPv4 NATs", draft-denis-v6ops-nat-addrsel-00 784 (work in progress), February 2009. 786 [I-D.carpenter-renum-needs-work] 787 Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering 788 still needs work", draft-carpenter-renum-needs-work-03 789 (work in progress), May 2009. 791 Author's Address 793 Tim Chown (editor) 794 University of Southampton 795 Southampton, Hampshire SO17 1BJ 796 United Kingdom 798 Email: tjc@ecs.soton.ac.uk