IPv6 Operations T. Chown, Ed.
Internet-Draft University of Southampton
Intended status: Informational March 9, 2009
Expires: September 10, 2009
Considerations for IPv6 Address Selection Policy Changes
draft-chown-addr-select-considerations-02
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Chown Expires September 10, 2009 [Page 1]
Internet-Draft Address Selection Considerations March 2009
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract
RFC 3484 (IPv6 Default Address Selection) [RFC3484] defines
mechanisms for nodes to perform source and destination address
selection choices when faced with multiple addresses to choose
between when initiating a communication. While RFC3484 recognised
the need for implementations to be able to change the policy table, a
requirement has now also emerged for administrators to be able to
dynamically change the policy tables from a central control point,
and for nomadic hosts to be able to obtain the policy for the network
that they are currently attached to without manual user intervention.
This text discusses considerations for such policy changes, including
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 September 10, 2009 [Page 2]
Internet-Draft Address Selection Considerations March 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Issues to Consider . . . . . . . . . . . . . . . . . . . . . . 4
3. Other Related Work . . . . . . . . . . . . . . . . . . . . . . 5
4. Drivers for Policy Changes . . . . . . . . . . . . . . . . . . 5
4.1. Internal vs External Triggers . . . . . . . . . . . . . . 6
4.2. Administratively Triggered Changes . . . . . . . . . . . . 7
4.3. Start-up vs Running Changes . . . . . . . . . . . . . . . 7
4.4. Nomadic Nodes . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Multiple Interface Nodes . . . . . . . . . . . . . . . . . 8
5. How Dynamic? . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Considerations when Obtaining Policy . . . . . . . . . . . . . 9
6.1. Changes in Available Address(es) . . . . . . . . . . . . . 10
6.2. Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. Manual Configuration? . . . . . . . . . . . . . . . . . . 10
6.4. Policy Conflicts . . . . . . . . . . . . . . . . . . . . . 10
7. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. Is default policy used? . . . . . . . . . . . . . . . . . 11
7.2. Pull model . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. Push model . . . . . . . . . . . . . . . . . . . . . . . . 12
7.4. Routing Hints . . . . . . . . . . . . . . . . . . . . . . 12
7.5. Conflicts/Merging Policies . . . . . . . . . . . . . . . . 13
8. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . 13
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
13. Informative References . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Chown Expires September 10, 2009 [Page 3]
Internet-Draft Address Selection Considerations March 2009
1. Introduction
There have been various operational issues observed with Default
Address Selection for IPv6 (RFC3484) [RFC3484], as described in
RFC5220 [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.
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].
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
Chown Expires September 10, 2009 [Page 4]
Internet-Draft Address Selection Considerations March 2009
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], 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 [I-D.arifumi-6man-rfc3484-revise]).
3. Other Related Work
We note that there is some existing work in defining Requirements for
Address Selection Mechanisms [RFC5221], and some initial work has
been done in the solution space (for DHCP)
[I-D.fujisaki-dhc-addr-select-opt], 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 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:
o Multiple Routers on a Single Interface
o Ingress Filtering
o Problem Half-Closed Network Problem (*)
o Combined Use of Global and ULA (*)
Chown Expires September 10, 2009 [Page 5]
Internet-Draft Address Selection Considerations March 2009
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 (*)
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 Triggers
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.
Chown Expires September 10, 2009 [Page 6]
Internet-Draft Address Selection Considerations March 2009
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 DNS-published
globals (or vice versa).
o An internal network renumbering occurs, perhaps due to a site
expanding.
o 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).
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 administrator 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
Chown Expires September 10, 2009 [Page 7]
Internet-Draft Address Selection Considerations March 2009
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.
4.4. Nomadic Nodes
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.
4.5. Multiple Interface Nodes
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 [I-D.blanchet-mif-problem-statement],
and on a number of possible DHCPv6 extensions to inform hosts about
routing information to assist the selection process
[I-D.dec-dhcpv6-route-option], [I-D.sun-mif-address-policy-dhcp6],
[I-D.sarikaya-mif-dhcpv6solution]. Another new draft proposes a
DHCPv6 option to convey policy directly to a host
[I-D.sun-mif-route-config-dhcp6]. At this stage we can simply note
that the latter mechanisms (DHCPv6 extensions) may be of interest
Chown Expires September 10, 2009 [Page 8]
Internet-Draft Address Selection Considerations March 2009
when considering our solution space.
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.
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.
6. Considerations when Obtaining Policy
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.
Chown Expires September 10, 2009 [Page 9]
Internet-Draft Address Selection Considerations March 2009
6.1. Changes in Available Address(es)
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.
6.2. Timeliness
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) [RFC4242], which was originally introduced
to assist with network renumbering events.
6.3. Manual Configuration?
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.
6.4. Policy Conflicts
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
Chown Expires September 10, 2009 [Page 10]
Internet-Draft Address Selection Considerations March 2009
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.
7. Solution Space
In this section we make some initial observations on the possible
solution space.
7.1. Is default policy used?
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.
7.2. Pull model
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
[I-D.sun-mif-route-config-dhcp6]. There are also proposals to convey
routing information via DHCPv6 to a host, to facilitate better
selection decisions, e.g. [I-D.dec-dhcpv6-route-option],
[I-D.sun-mif-address-policy-dhcp6],
[I-D.sarikaya-mif-dhcpv6solution]. 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.
Chown Expires September 10, 2009 [Page 11]
Internet-Draft Address Selection Considerations March 2009
7.3. Push model
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.
7.4. Routing Hints
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 [I-D.carpenter-renum-needs-work] 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.
Chown Expires September 10, 2009 [Page 12]
Internet-Draft Address Selection Considerations March 2009
7.5. Conflicts/Merging Policies
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.
8. 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. 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 [RFC5220]).
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 [I-D.arifumi-6man-rfc3484-revise] mean that an update of
RFC3484 is required, if only because some of the issues (as
Chown Expires September 10, 2009 [Page 13]
Internet-Draft Address Selection Considerations March 2009
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.
9. Conclusions
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.
Chown Expires September 10, 2009 [Page 14]
Internet-Draft Address Selection Considerations March 2009
Further comments on this draft are welcomed.
10. Security Considerations
There are no extra Security consideration for this document.
11. IANA Considerations
There are no extra IANA consideration for this document.
12. 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.
We also acknowledge comments received from IETF WG mail lists,
including those by Brian Carpenter and Dave Thaler.
13. Informative References
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 4242, November 2005.
[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", RFC 5220, July 2008.
[RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Requirements for Address Selection Mechanisms", RFC 5221,
July 2008.
[I-D.ietf-6man-addr-select-sol]
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.
Chown Expires September 10, 2009 [Page 15]
Internet-Draft Address Selection Considerations March 2009
[I-D.arifumi-6man-rfc3484-revise]
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.
[I-D.fujisaki-dhc-addr-select-opt]
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.
[I-D.blanchet-mif-problem-statement]
Blanchet, M., "Multiple Interfaces Problem Statement",
draft-blanchet-mif-problem-statement-00 (work in
progress), December 2008.
[I-D.dec-dhcpv6-route-option]
Dec, W. and R. Johnson, "DHCPv6 Route Option",
draft-dec-dhcpv6-route-option-01 (work in progress),
March 2009.
[I-D.sun-mif-address-policy-dhcp6]
Sun, T., Deng, H., and X. Duan, "Address Selection Policy
Configuration by DHCPv6 Option",
draft-sun-mif-address-policy-dhcp6-00 (work in progress),
March 2009.
[I-D.sarikaya-mif-dhcpv6solution]
Sarikaya, B., Xia, F., and P. Seite, "DHCPv6 Extension for
Configuring Hosts with multiple Interfaces",
draft-sarikaya-mif-dhcpv6solution-01 (work in progress),
March 2009.
[I-D.sun-mif-route-config-dhcp6]
Sun, T. and H. Deng, "Route Configuration by DHCPv6 Option
for Hosts with Multiple Interfaces",
draft-sun-mif-route-config-dhcp6-00 (work in progress),
March 2009.
[I-D.carpenter-renum-needs-work]
Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
still needs work", draft-carpenter-renum-needs-work-02
(work in progress), February 2009.
Chown Expires September 10, 2009 [Page 16]
Internet-Draft Address Selection Considerations March 2009
Author's Address
Tim Chown (editor)
University of Southampton
Southampton, Hampshire SO17 1BJ
United Kingdom
Email: tjc@ecs.soton.ac.uk
Chown Expires September 10, 2009 [Page 17]