Considerations for IPv6 Address Selection Policy Changes

There have been various operational issues observed with Default Address Selection for IPv6 (RFC3484) , as described in RFC5220 . As as a result, there has been some demand for hosts to be able to have their policy tables, and potentially the rules described in RFC3484, modified dynamically. Such changes may apply to 'static' hosts in a network where policies or topologies change, or nomadic hosts within a network for which policies may vary depending on their location within the network.

There are a number of aspects to consider in the context of such address selection policy updates. First is the frequency for which such updates are likely to be required; this will be determined largely from identifying the scenarios in which policy changes will be required. This may include overriding default system policies on startup, as well as changes while a system is running. We discuss this topic in Section 4. Second, by understanding how dynamic the policy update mechanism needs to be we should be better placed to determine what types of update approaches best meet those needs. There may be other considerations of course, e.g. whether the systems are in managed or unmanaged environments, and whether the solution should be proactive or automated, as discussed in . Section 5 covers these issues. Third, if we assume some policy update mechanism is defined we should consider how hosts and systems may become aware that a policy change has happened, and how policy can be disseminated in a timely fashion. Thus we need to understand what kind of technical/concrete event(s) can be used for triggering the policy table update mechanism, e.g. address re-obtainment, address lifetime expiration, or perhaps policy lifetime expiration. We also need to consider what other factors may come into play, e.g. potential policy conflicts. This is discussed in Section 6. After analysing these issues, we can make some initial comments regarding the potential solution spaces, and what models may be well suited, e.g. push vs pull models, and what other methods might assist us, e.g. hints from local routing tables. This is covered in Section 7. Finally, we should assess whether these update solutions require or need 3484 to be updated. In some instances, we might envision solutions that simply use RFC3484 as guidelines and provide sufficient controls to address the current limitations in the RFC. However, as noted in RFC5220 , not all the operational issues observed to date can be remedied by updating RFC3484 alone. There is already a good analysis of issues with RFC3484 and how the text could be revised ).

We note that there is some existing work in defining Requirements for Address Selection Mechanisms , and some initial work has been done in the solution space (for DHCP) , but these are not discussed here. While RFC5221 does assume that a dynamic policy update mechanism of some form is available, this draft is currently aimed at understanding the scenarios and triggers for policy changes, to better inform future solution discussions.

If we wish to determine how frequent address selection policy changes are likely to be, we need to understand why such policies might need to be changed, for particular sites or networks. One reference text for potential drivers for policy change is RFC5220, in which operational issues with the existing policies described in RFC3484 are listed. Each subsection of this document gives a reason why the existing rules or policy tables in RFC3484 may not be sufficient in certain cases. There have been some significant changes to IPv6 since RFC3484 was drafted which have impacted the RFC, e.g. the introduction of Unique Local Addresses (ULAs), and concerns about longest prefix matching affecting (DNS) round robin load balancing. In summary, the issues raised in RFC5220 were: Multiple Routers on a Single Interface Ingress Filtering Problem Half-Closed Network Problem (*) Combined Use of Global and ULA (*) Site Renumbering (*) Multicast Source Address Selection (*) Temporary Address Selection IPv4 or IPv6 Prioritization (*) ULA and IPv4 Dual-Stack Environment (*) ULA or Global Prioritization (*) The authors of RFC5220 noted which of these issues can be solved by changes to the RFC3484 policy table, marked (*) above, and which cannot. It is interesting to note that issues largely related to internal networking and (administrative) policy decisions can be handled this way.

When considering drivers or triggers that may lead to a requirement for the policy to change, we can divide the problem space into those external to a site or network and those internal to it. In the case of the first two examples above, a dynamic policy table update may be required by externally driven routing changes, assuming the site uses a dynamic routing protocol intra-site and the routing protocol is configured to reflect changes of extra-site routing topology. If a site is multihomed using BGP and advertising a single prefix upstream, then no policy table manipulation is required for global address preferences. However where a site is multihomed by receiving a prefix from each upstream provider, each host will have multiple addresses and many need policy table manipulation. In such a case, the policy table of hosts may thus need to be updated according to the routing policy. It should be noted that we have other mechanisms for dynamic routing topology change, for example deprecating one of the advertised prefixes, perhaps when one of the upstream links has a problems. Other examples of external factors include a new transition mechanism being defined (e.g. as with the emergence of Teredo using 2001::/32 as assigned by IANA) and its inclusion being required in the policy table, a new address block being defined, or a site renumbering event that could be triggered by an upstream provider's actions.

The other examples above are, in the general case, where the site administrator chooses to change a local policy and in doing so triggers the need for policy table updates. Some of these changes one might assume to be set once, and to change rarely, for example: Setting priority use of IPv6 over IPv4 (or vice versa). Setting priority use of ULAs over globals (or vice versa). Setting priority use of privacy addresses over DNS-published globals (or vice versa). An internal network renumbering occurs, perhaps due to a site expanding. The nature of the external connectivity through multiple ISPs requires specific additional information (policy) to be delivered to certain hosts (as discussed in 2.1.3 in RFC5220). Disabling longest-prefix match functions to facilitate round-robin load balancing. However it may be the case that different parts of a site have different policies, or policies are changed in a rolling fashion across a site over time as IPv6 or ULAs are introduced (for example). This may happen where the administrator prefers a gradual introduction of new policy in a phased operation across a site, rather than changing policy across the whole site in one operation. Other administrative changes may occur more frequently, e.g.: Routing tables and forwarding tables change dynamically. A different provider (link) is preferred for a given destination. It's possible that provider links may vary on a daily basis, or by time of day. The frequency of such policy changes will depend on the frequency that the administrator wishes to change the traffic engineering policies.

When a host starts up it may be configured with the default RFC3484 policies. At this stage a number of addresses may be configured on a number of interfaces on the host. At this time it may be desirable for the host to be able to receive the site-specific policy updates as a start-up override from the RFC3484 defaults. Other policy changes may later be required while the host is running. Ideally the same protocol should be used for the start-up and running state updates.

A host may be nomadic within a site and as a result it may see the preferred policy change depending on the host's topological location within that site. Such a host should be capable of receiving policy updates in a timely fashion as it migrates within the network. While this may be one case of 'running changes' described above, the policy changes are required due to the host's new point of attachment, not changes of policy to the current point of attachment.

In considering scenarios where hosts may be multi-addressed and require policy to assist in address selection, the issue of hosts with multiple interfaces arose. A host may have a variety of reasons to have multiple interfaces. It may for example have WiFi and 3G interfaces, and be capable of sending or receiving data over either interface. In some cases these interfaces may fall within the same administrative domain (ISP) and in some cases they may not. Another example would be the case of a host with a VPN connection established, where address selection may be affected by the choice of whether the VPN connection is used or not. This is clearly an important problem today, but we note that RFC3484 is currently defined as a per-node, not per-interface, mechanism. While the multiple interface problem is interesting, we feel it is out of scope of this draft. This draft is only focused on handling multiple policies into one interface and conveying them into the hosts' RFC3484 policy table. We note that there are some new, initial drafts published recently on the multiple interface problem , and on a number of possible DHCPv6 extensions to inform hosts about routing information to assist the selection process , , . Another new draft proposes a DHCPv6 option to convey policy directly to a host . At this stage we can simply note that the latter mechanisms (DHCPv6 extensions) may be of interest when considering our solution space.

The discussion above suggests that many of the potential triggers for policy table changes are 'one-off' in nature, i.e. a site makes a one-time policy change. It is thus unlikely that such administrative changes will be frequent. There are some cases where updates may be required to be more frequent. In the example of a site which is implementing the gradual introduction of new policy across its network, while the frequency of changes may be relatively high, there is still probably only one or a small number of changes per host. There may be a higher rate of policy changes within a site if there are nomadic hosts within the site, and these are roaming frequently to parts of the network where differing policies are in effect. In such cases it may be useful for a host to know whether or not the default RFC3484 (or soon to be 3484bis) policies are in effect or not, and for there to be a 'cheap' way for the host to discover this. Perhaps the biggest cause of policy change lies where the preferred links or paths for certain destinations change frequently over time as traffic engineering requirements change. In some networks this may be a daily change, or change between states at different times of day. It is not clear how common these cases are, and thus further input is welcomed here. In terms of the impact of frequency of policy changes on solutions, we first need to ensure there is some consensus on the drivers for policy change and thus the frequency of changes. At this stage we note that the analysis is simplified if we assume that only administrative changes are considered, and that it would be highly preferable if the start-up and running state solutions used the same protocol.

When a policy change is made, or a host migrates to a part of the network with different policies, that change of policy needs to be conveyed to the host. It needs to be made available and applied without restarting every affected host.

One might assume at first that when a host observes a change in its addresses, it should re-obtain the selection policy, but this may not always be the case. It should be noted that not all policy changes are tied to a host changing one or more addresses, though it may be acceptable to query regardless for new policy (if a pull model is used) when address information changes. As described above, it may be sufficient for a host to know when a policy is changed, or that perhaps the default policy is - or is not - in effect in its current locale.

In many, but not all, cases a policy change will need to be synchronised across a network. Thus there is a general issue of timely and synchronised dissemination of new policy. If the policy is distributed via the same mechanism that informs a host of a change of address(es), the application of the policy should be synchronised sufficiently with the address change. However, not all hosts may receive the update information at the same time, e.g. where new address assignments may be dependent on DHCP lease timers. Where hosts use DHCPv6 for address information, in the absence of some form of Reconfigure message, a host may see a delay in policy changes being notified. One possible tool to help here is the DHCPv6 Lifetime Option (RFC4242) , which was originally introduced to assist with network renumbering events.

There are scenarios where a host may wish to ignore conveyed policy. For example, the manager of a mobile node may not want to have its preferences changed by a visited network. In such a case one might argue that the mobile node should use MIPv6 with whatever its home network policies are. The implication again is that we need a flag of some kind to inform a host whether network it is in uses the default RFC3484 policy, which would then allow each end system to decide if it should get an (overriding) local policy or not.

As the above suggests, it is possible that conflicting policies may be available to a host, regardless of whether a push or pull model is used to distribute policy. For example, where a host is on a subnet with two or more routers under different administrative control, the policies may differ. The question then is how such conflicts can be resolved. If there are mergers of policies, the rules for such mergers need careful consideration. Otherwise the host may have to simply choose one policy by some method. Ideally we would limit the scope of this problem to scenarios where hosts are operating under a single administrative entity, which should ensure policies are consistent.

In this section we make some initial observations on the possible solution space.

There should be some mechanism to indicate to a host that the local network does not use the default RFC3484 policy, and that a revised policy table is available (and should be used). However it should also be possible for a host to detect that policy has changed (whether 'around' the host, or due to the host being nomadic). It is assumed by 'default' policy here we refer to the revised/updated RFC3484 specification, when that is produced. The question as to how a non-default policy is indicated may be steered by which we believe to be the common case in the longer term - hosts that need local policy changes, or hosts that do not. If an RA bit is used to indicate whether a local policy is available, we avoid hosts requesting potentially non-existent policy tables (or copies of default tables they already have) forever.

One approach would be to define appropriate extensions to DHCPv6 to allow policy table updates to be applied to a host. There are some recent initial proposals in this area, in particular . There are also proposals to convey routing information via DHCPv6 to a host, to facilitate better selection decisions, e.g. , , . Whether these may be applicable in the context of this discussion remains to be determined. The DHCP model allows individual nodes to potentially have differing policy, even when on the same subnet.

A push model could also be possible. There may be some options to piggyback clues to the host into a Router Advertisement message, though initial consensus seems to be that this is a less attractive approach. However, we may find that RAs may be a good place to indicate whether a default policy is in place or not, to avoid hosts requesting non-existent updates via DHCPv6.

If a host has routing hints available, it may be able to make more informed selections. It may be that the most appropriate way to pass routing state is with a routing protocol from an active router. For example, a RIP listener could help to resolve the routing policy part of this problem space, but that would take us back to the issue of address selection in the cases where multiple default routes were advertised. At this stage we can simply note that address selection is simplified when routing state is provided to the end system. How routing state is passed is for future discussion; it may for example be via the DHCPv6 extensions described above. It is noted in that: "In an environment where a site has more than one upstream link to the outside world, the site might have more than one valid routing prefix. In such cases, typically all valid routing prefixes within a site will have the same prefix length. Also in such cases, it might be desirable for hosts that obtain their addresses using DHCPv6 to learn about the availability of upstream links dynamically, by deducing from periodic IPv6 RA messages which routing prefixes are currently valid. This application seems possible within the IPv6 Neighbour Discovery architecture, but does not appear to be clearly specified anywhere." The same thought seems relevant to address selection. There's no point selecting a source address whose prefix is not being advertised in RAs. While routing and prefix hints may help a host make selection decisions, we should consider to what extent we wish to 'burden' a host with holding such information.

It is not yet clear whether entire policy tables will be made available, or simply differences to the 'default', and thus whether policies may need to be merged, or overridden. Some policy conflicts will be unresolvable, e.g. one prefers IPv4 over IPv6, the other vice-versa. It may be simpler, though arguably less efficient, for whole policy tables to be distributed, to avoid the merger problem. One option may be to split the policy table into destination address selection and source address selection tables, with the policy distribution only updating the source address selection. Whether this might make merging policies simpler or in fact more complex would require further study. It may also be possible to indicate some priority value for a policy, e.g. the priority of the interface it is received on. Or if there are multiple policies in conflict, a host could simply choose to fall back to use the default RFC3484 policy. A host also needs to know how to decide when to accept a policy. We could simplify the discussion by assuming a host is located in and only nomadic within a single site with one administrative controlling entity.

RFC3484 includes text about mechanisms for changing policy, having 'policy hooks' and having a configurable policy table. The implication is that defaults can be changed, and the text gives examples of this in Section 10. However, issues with RFC3484 are broader that just policy table updates - it remains the case that some operational issues with RFC3484 are not just related to the table, but on rules themselves, e.g. longest prefix match (affecting DNS round robin as described in ). While discussing default policy, we noted that the word 'default' has to be defined here, i.e. what is the scope of this 'default'. It seems it is 'system wide' but first it just moves the issue to the 'system' definition and second larger or smaller granularities make sense (for instance 'link wide' and 'user wide'). Whether and how this can be considered in an open question. Currently we assume RFC3484 and changes to it will remain node-specific. It certainly seems the case that the issues raised in RFC5220, and discussed in mean that an update of RFC3484 is required, if only because some of the issues (as highlighted earlier) cannot be addressed by updating the policy table alone. We do not note any specific comments here on how RFC3484 should be updated. Other drafts have made suggestions. There are some discussions on ideas however, e.g. on the semantics of labels, and in adding ULAs explicitly to the default policy table.

We believe the scope of this text should apply to site and enterprise networks, where an administrator may need to change policies over time, but that it includes nomadic nodes within the site, which may migrate to different parts of the site where different policies are required. This is the focus of our analysis. We note there is potentially complementary work within the multiple interface (mif) community on handling address selection issues for mobile nodes with multiple interfaces, and that outputs from that community may be applicable to our problem space. There is clearly a need to revise RFC3484, to create a new default policy for address selection. This should be expedited. We also note that RFC3484 is currently defined on a per-node, not per-interface basis, which we believe should remain the status quo for the scope of this work. It is not clear how or if the mif work will affect this assumption. The scope of this text includes issues affecting the design of a protocol to allow a host's RFC3484 policy table to be updated. It has been suggested that hosts may receive conflicting policy table updates in some scenarios. However, heuristics for policy table mergers may prove problematic to devise, so the problem space for policy distribution and updates could be simplified if we can assume hosts are operating in a network under one administrative entity. It is simplified further if we only consider policy changes triggered for administrative reasons. In terms of push or pull-based methods for policy distribution, early analysis suggests that a push-based hint to hosts as to whether they are in a network where the default policy applies or not would be useful. This might be indicated via an RA flag, perhaps. In terms of obtaining policy, a pull-based solution, such as DHCPv6, may be preferable if inidividual hosts on a subnet require differing policies. Also, the same protocol for policy updates should probably be used whether a host is starting up, or if updates are required while the node is running. Further comments on this draft are welcomed.

There are no extra Security consideration for this document.

There are no extra IANA consideration for this document.

The design team working on this draft is: Marcelo Bagnulo Braun, Marc Blanchet, Tim Chown, Francis Dupont, Tim Enos, TJ Evans, Brian Haberman, Tony Hain, Ruri Hiromi, Suresh Krishnan, Arifumi Matsumoto, Janos Mohacsi, Sebastien Roy, Teemu Savolainen, Fujisaki Tomohiro, and John Zhao. We also acknowledge comments received from IETF WG mail lists, including those by Brian Carpenter and Dave Thaler.