IPv6 Operations T. Chown, Ed.
Internet-Draft University of Southampton
Intended status: Informational October 27, 2008
Expires: April 30, 2009
Considerations for IPv6 Address Selection Policy Changes
draft-chown-addr-select-considerations-00
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 April 30, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
Through operational experience of IPv6 Default Address Selection
(RFC3484) [1] 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.
Chown Expires April 30, 2009 [Page 1]
Internet-Draft Address Selection Considerations October 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Issues to Consider . . . . . . . . . . . . . . . . . . . . . . 3
3. Other Related Work . . . . . . . . . . . . . . . . . . . . . . 4
4. Drivers for Policy Changes . . . . . . . . . . . . . . . . . . 4
4.1. Internal vs External Tiggers . . . . . . . . . . . . . . . 5
4.2. Administratively Triggered Changes . . . . . . . . . . . . 5
4.3. Start-up vs Running Changes . . . . . . . . . . . . . . . 6
5. On Address Changes and Obtaining Policy . . . . . . . . . . . 6
6. How Dynamic? . . . . . . . . . . . . . . . . . . . . . . . . . 7
7. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . 7
8. Considerations for Solutions . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
12. Informative References . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Chown Expires April 30, 2009 [Page 2]
Internet-Draft Address Selection Considerations October 2008
1. Introduction
There have been various operational issues observed (RFC5220) [2]
with Default Address Selection for IPv6 (RFC3484) [1]. 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.
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 [4].
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.
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 [2], 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 [6]).
Chown Expires April 30, 2009 [Page 3]
Internet-Draft Address Selection Considerations October 2008
3. Other Related Work
We note that there is some existing work in defining Requirements for
Address Selection Machanisms [3], and some initial work has been done
in the solution space (for DHCP) [5], 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:
o Multiple Routers on a Single Interface
o Ingress Filtering
o Problem Half-Closed Network Problem (*)
o Combined Use of Global and ULA (*)
o Site Renumbering (*)
o Multicast Source Address Selection (*)
o Temporary Address Selection
o IPv4 or IPv6 Prioritization (*)
o ULA and IPv4 Dual-Stack Environment (*)
o ULA or Global Prioritization (*)
Chown Expires April 30, 2009 [Page 4]
Internet-Draft Address Selection Considerations October 2008
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. In such a case, the policy
table of hosts may needs 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, 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, e.g.:
o Setting priority use of IPv6 over IPv4 (or vice versa).
o Setting priority use of ULAs over globals (or vice versa).
o Setting priority use of privacy addresses over globals (or vice
versa).
o An internal network renumbering occurs, perhaps due to a site
expanding.
o Disabling longest-prefix match functions to facilitate round-robin
load balancing.
Chown Expires April 30, 2009 [Page 5]
Internet-Draft Address Selection Considerations October 2008
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).
Other administrative changes may occur more frequently, e.g.:
o Routing tables and forwarding tables change dynamically.
o 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.
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. 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 changes an address, 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. 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. It should also be noted of course that not
all policy changes are tied to a host changing one or more addresses.
One possible tool to help here is the DHCPv6 Lifetime Option
(RFC4242), which was originally introduced to assist with network
renumbering events.
Thus there is a general issue of timely and synchronised
dissemination of new policy.
Chown Expires April 30, 2009 [Page 6]
Internet-Draft Address Selection Considerations October 2008
6. 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.
However, there are also some cases where updates may be required to
be more frequent, e.g. the gradual introduction of new policy across
a large site, and cases where preferred links for certain
destinations change frequently over time (possibly daily). It is not
clear how common these cases are, and thus further input is welcomed
here.
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 [2]).
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 [6] 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. Considerations for Solutions
In this first draft we avoid any discussion of impact on or
implications for solutions. Except that it would be highly
preferable if the start-up and running state solutions used the same
protocol.
9. Security Considerations
There are no extra Security consideration for this document.
Chown Expires April 30, 2009 [Page 7]
Internet-Draft Address Selection Considerations October 2008
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
[1] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[2] 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",
RFC 5220, July 2008.
[3] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Requirements for Address Selection Mechanisms", RFC 5221,
July 2008.
[4] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Solution approaches for address-selection problems",
draft-ietf-6man-addr-select-sol-01 (work in progress),
June 2008.
[5] Fujisaki, T., Matsumoto, A., Niinobe, S., Hiromi, R., and K.
Kanayama, "Distributing Address Selection Policy using DHCPv6",
draft-fujisaki-dhc-addr-select-opt-06 (work in progress),
June 2008.
[6] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Things To Be Considered for RFC 3484 Revision",
draft-arifumi-6man-rfc3484-revise-00 (work in progress),
June 2008.
Chown Expires April 30, 2009 [Page 8]
Internet-Draft Address Selection Considerations October 2008
Author's Address
Tim Chown (editor)
University of Southampton
Southampton, Hampshire SO17 1BJ
United Kingdom
Email: tjc@ecs.soton.ac.uk
Chown Expires April 30, 2009 [Page 9]
Internet-Draft Address Selection Considerations October 2008
Full Copyright Statement
Copyright (C) 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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Chown Expires April 30, 2009 [Page 10]