Considerations for IPv6 Address Selection Policy Changes
draft-chown-addr-select-considerations-01

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on May 8, 2009.

Abstract

Through operational experience of IPv6 Default Address Selection (RFC3484) [RFC3484] (Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6),” February 2003.) implementations, it appears that a requirement has arisen for hosts and networks to be able to have their policies for address selection updated. This text discusses considerations for such policy changes, e.g. examples of cases where a change of policy is required, and the likely frequency of such policy changes. This text also includes some discussion on the need to also update RFC3484, where default policies are currently defined.

Table of Contents

1.  Introduction
2.  Issues to Consider
3.  Other Related Work
4.  Drivers for Policy Changes
    4.1.  Internal vs External Tiggers
    4.2.  Administratively Triggered Changes
    4.3.  Start-up vs Running Changes
5.  How Dynamic?
6.  On Address Changes and Obtaining Policy
7.  On RFC3484 Default Policies
8.  Conclusions
9.  Security Considerations
10.  IANA Considerations
11.  Acknowledgements
12.  Informative References
§  Author's Address
§  Intellectual Property and Copyright Statements

1.  Introduction

There have been various operational issues observed (RFC5220) [RFC5220] (Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, “Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules,” July 2008.) with Default Address Selection for IPv6 (RFC3484) [RFC3484] (Draves, R., “Default Address Selection for Internet Protocol version 6 (IPv6),” February 2003.). As as a result, there has been some demand for the capability for systems and networks to be able to have their policy tables, and potentially the rules described in RFC3484, modified.

2.  Issues to Consider

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 [I‑D.ietf‑6man‑addr‑select‑sol] (Matsumoto, A., Fujisaki, T., and R. Hiromi, “Solution approaches for address-selection problems,” March 2010.). 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. This is discussed in Section 6.

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 [RFC5220] (Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, “Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules,” July 2008.), not all the operational issues observed to date can be remedied by updating RFC3484 alone. Thus there may be further work required elsewhere, which may of course still include an RFC3484 update, to address all the issues detailed in RFC5220, as described in [I‑D.arifumi‑6man‑rfc3484‑revise] (Matsumoto, A., Fujisaki, T., and R. Hiromi, “Things To Be Considered for RFC 3484 Revision,” October 2009.)). We talk about these issues in Section 7.

3.  Other Related Work

We note that there is some existing work in defining Requirements for Address Selection Machanisms [RFC5221] (Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, “Requirements for Address Selection Mechanisms,” July 2008.), and some initial work has been done in the solution space (for DHCP) [I‑D.fujisaki‑dhc‑addr‑select‑opt] (Fujisaki, T., Matsumoto, A., and R. Hiromi, “Distributing Address Selection Policy using DHCPv6,” March 2010.), 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.

4.  Drivers for Policy Changes

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 obvious source of 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.

4.1.  Internal vs External Tiggers

When considering drivers or triggers that may lead to a requirement for the policy to change, we can consider those external to a site or network and those internal. 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 mechanims 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.

4.2.  Administratively Triggered Changes

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 globals (or vice versa).
• An internal network renumbering occurs, perhaps due to a site expanding.
• The nature of the external connectivity through mutiple 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 adinistrator wishes to change the traffic engineering policies.

4.3.  Start-up vs Running Changes

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.

5.  How Dynamic?

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.

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. We thus don't (yet) make comments on solutions, except that it would be highly preferable if the start-up and running state solutions used the same protocol.

6.  On Address Changes and Obtaining Policy

When a policy table change is made, the change of policy needs to be propogated to the hosts in a network.

From the host perspective, one could assume that when a host observes a change in its addresses, it should re-obtain the selection 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.

It should also be noted of course that not all policy changes are tied to a host changing one or more addresses. The question is then whether application of the new policy needs to be synchronised across the network or not. Thus there may be a general issue of timely and synchronised dissemination of new policy.

7.  On RFC3484 Default Policies

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. That said, 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 [RFC5220] (Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, “Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules,” July 2008.)).

We should note though 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.

It certainly seems the case that the issues raised in RFC5220, and discussed in [I‑D.arifumi‑6man‑rfc3484‑revise] (Matsumoto, A., Fujisaki, T., and R. Hiromi, “Things To Be Considered for RFC 3484 Revision,” October 2009.) 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.

8.  Conclusions

This first draft aims to provoke discussion and at this time has no firm conclusions.

9.  Security Considerations

There are no extra Security consideration for this document.

10.  IANA Considerations

There are no extra IANA consideration for this document.

11.  Acknowledgements

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.

12. Informative References

Author's Address

Full Copyright Statement

Copyright © The IETF Trust (2008).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.