IPv6 Operations T. Chown, Ed.
Internet-Draft University of Southampton
Intended status: Informational November 3, 2008
Expires: May 7, 2009
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 7, 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 May 7, 2009 [Page 1]
Internet-Draft Address Selection Considerations November 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. How Dynamic? . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. On Address Changes and Obtaining Policy . . . . . . . . . . . 7
7. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . 8
8. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
12. Informative References . . . . . . . . . . . . . . . . . . . . 9
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Chown Expires May 7, 2009 [Page 2]
Internet-Draft Address Selection Considerations November 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. 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 [4]. 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 [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]). We talk about these issues in
Section 7.
Chown Expires May 7, 2009 [Page 3]
Internet-Draft Address Selection Considerations November 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 May 7, 2009 [Page 4]
Internet-Draft Address Selection Considerations November 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.
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:
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).
Chown Expires May 7, 2009 [Page 5]
Internet-Draft Address Selection Considerations November 2008
o An internal network renumbering occurs, perhaps due to a site
expanding.
o 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).
o 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.:
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. 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.
Chown Expires May 7, 2009 [Page 6]
Internet-Draft Address Selection Considerations November 2008
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.
Chown Expires May 7, 2009 [Page 7]
Internet-Draft Address Selection Considerations November 2008
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. 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.
Chown Expires May 7, 2009 [Page 8]
Internet-Draft Address Selection Considerations November 2008
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.
Author's Address
Tim Chown (editor)
University of Southampton
Southampton, Hampshire SO17 1BJ
United Kingdom
Email: tjc@ecs.soton.ac.uk
Chown Expires May 7, 2009 [Page 9]
Internet-Draft Address Selection Considerations November 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 May 7, 2009 [Page 10]