draft-ietf-6man-addr-select-considerations-00.txt   draft-ietf-6man-addr-select-considerations-01.txt 
IPv6 Operations T. Chown, Ed. IPv6 Maintenance T. Chown, Ed.
Internet-Draft University of Southampton Internet-Draft University of Southampton
Intended status: Informational October 19, 2009 Intended status: Informational July 11, 2010
Expires: April 22, 2010 Expires: January 12, 2011
Considerations for IPv6 Address Selection Policy Changes Considerations for IPv6 Address Selection Policy Changes
draft-ietf-6man-addr-select-considerations-00 draft-ietf-6man-addr-select-considerations-01
Abstract
Where the source and/or destination node of an IPv6 communication is
multi-addressed, a mechanism is required for the initiating node to
select the most appropriate address pair for the communication. RFC
3484 (IPv6 Default Address Selection) [RFC3484] defines such a
mechanism for nodes to perform source and destination address
selection. While RFC3484 recognised the need for implementations to
be able to change the policy table, it did not define how this could
be achieved. Requirements have now emerged for administrators to be
able to configure and potentially dynamically change RFC 3484 policy
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 RFC 3484, where default policies are currently defined.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
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 Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 12, 2011.
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 22, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Where the source and/or destination node of an IPv6 communication is This document may contain material from IETF Documents or IETF
multi-addressed, a mechanism is required for the initiating node to Contributions published or made publicly available before November
select the most appropriate address pair for the communication. RFC 10, 2008. The person(s) controlling the copyright in some of this
3484 (IPv6 Default Address Selection) [RFC3484] defines such a material may not have granted the IETF Trust the right to allow
mechanism for nodes to perform source and destination address modifications of such material outside the IETF Standards Process.
selection. While RFC3484 recognised the need for implementations to Without obtaining an adequate license from the person(s) controlling
be able to change the policy table, it did not define how this could the copyright in such materials, this document may not be modified
be achieved. Requirements have now emerged for administrators to be outside the IETF Standards Process, and derivative works of it may
able to dynamically change the RFC 3484 policy tables from a central not be created outside the IETF Standards Process, except to format
control point, and for nomadic hosts to be able to obtain the policy it for publication as an RFC or to translate it into languages other
for the network that they are currently attached to without manual than English.
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 RFC
3484, where default policies are currently defined.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Issues to Consider . . . . . . . . . . . . . . . . . . . . . . 4 2. Issues to Consider . . . . . . . . . . . . . . . . . . . . . . 4
3. Other Related Work . . . . . . . . . . . . . . . . . . . . . . 5 3. Other Related Work . . . . . . . . . . . . . . . . . . . . . . 5
4. Drivers for Policy Changes . . . . . . . . . . . . . . . . . . 5 4. Drivers for Policy Changes . . . . . . . . . . . . . . . . . . 5
4.1. Internal vs External Triggers . . . . . . . . . . . . . . 6 4.1. Internal vs External Triggers . . . . . . . . . . . . . . 6
4.2. Administratively Triggered Changes . . . . . . . . . . . . 7 4.2. Administratively Triggered Changes . . . . . . . . . . . . 7
4.3. Start-up vs Running Changes . . . . . . . . . . . . . . . 8 4.3. Start-up vs Running Changes . . . . . . . . . . . . . . . 8
4.4. Nomadic Nodes . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Nomadic Nodes . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Multiple Interface Nodes . . . . . . . . . . . . . . . . . 8 4.5. Multiple Interface Nodes . . . . . . . . . . . . . . . . . 8
5. How Dynamic? . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. How Dynamic? . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Considerations when Obtaining Policy . . . . . . . . . . . . . 10 6. Considerations when Obtaining Policy . . . . . . . . . . . . . 10
6.1. Changes in Available Address(es) . . . . . . . . . . . . . 10 6.1. Changes in Available Address(es) . . . . . . . . . . . . . 10
6.2. Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 10 6.2. Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Manual Configuration? . . . . . . . . . . . . . . . . . . 11 6.3. Manual Configuration? . . . . . . . . . . . . . . . . . . 11
6.4. Policy Conflicts . . . . . . . . . . . . . . . . . . . . . 11 6.4. Policy Conflicts . . . . . . . . . . . . . . . . . . . . . 11
7. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Is default policy used? . . . . . . . . . . . . . . . . . 12 7.1. Is default policy used? . . . . . . . . . . . . . . . . . 12
7.2. Pull model . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Pull model . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Push model . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. Push model . . . . . . . . . . . . . . . . . . . . . . . . 13
7.4. Routing Hints . . . . . . . . . . . . . . . . . . . . . . 13 7.4. Routing Hints . . . . . . . . . . . . . . . . . . . . . . 13
7.5. Conflicts/Merging Policies . . . . . . . . . . . . . . . . 13 7.5. Conflicts/Merging Policies . . . . . . . . . . . . . . . . 14
8. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . 14 8. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . 15
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
13. Informative References . . . . . . . . . . . . . . . . . . . . 16 13. Informative References . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
There have been various operational issues observed with Default There have been various operational issues observed with Default
Address Selection for IPv6 (RFC 3484) [RFC3484], as described in RFC Address Selection for IPv6 (RFC 3484) [RFC3484], as described in RFC
5220 [RFC5220]. As as a result, there has been some demand for hosts 5220 [RFC5220]. As as a result, there has been some demand for hosts
to be able to have their policy tables, and potentially the rules to be able to have their policy tables, and potentially the rules
described in RFC 3484, modified dynamically. Such changes may apply described in RFC 3484, modified dynamically. Such changes may apply
to 'static' hosts in a network where policies or topologies change, to 'static' hosts in a network where policies or topologies change,
or nomadic hosts within a network for which policies may vary or different default policy to that described in RFC 3484 is
depending on their location within the network. required, or for nomadic hosts within a network for which policies
may vary depending on their location within the network.
2. Issues to Consider 2. Issues to Consider
There are a number of aspects to consider in the context of such There are a number of aspects to consider in the context of such
address selection policy updates. address selection policy updates.
First is the frequency for which such updates are likely to be First is the frequency for which such updates are likely to be
required; this can be determined largely from identifying the required; this can be determined largely from identifying the
scenarios in which policy changes will be required. This may include scenarios in which policy changes will be required. This may include
overriding default operating system policies on startup, as well as overriding default operating system policies on startup, as well as
skipping to change at page 5, line 25 skipping to change at page 5, line 25
We note that there is some existing work in defining Requirements for We note that there is some existing work in defining Requirements for
Address Selection Mechanisms [RFC5221], and some initial work has Address Selection Mechanisms [RFC5221], and some initial work has
been done in the solution space (for a DHCP-based method) been done in the solution space (for a DHCP-based method)
[I-D.fujisaki-dhc-addr-select-opt], but these are not discussed here. [I-D.fujisaki-dhc-addr-select-opt], but these are not discussed here.
While RFC 5221 assumes that a dynamic policy update mechanism of some While RFC 5221 assumes that a dynamic policy update mechanism of some
form is available, this draft is primarily aimed at understanding the form is available, this draft is primarily aimed at understanding the
scenarios and triggers for policy changes, to better inform future scenarios and triggers for policy changes, to better inform future
detailed solution discussions. detailed solution discussions.
A draft discussing methods for multihoming without NAT66
[I-D.troan-multihoming-without-nat66] has been published recently.
This draft includes a requirement for a method to distribute address
selection policy to support IPv6 multihoming.
4. Drivers for Policy Changes 4. Drivers for Policy Changes
If we wish to determine how frequent address selection 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 are likely to be, we need to understand why such policies might need
to be changed, for particular sites or networks. to be changed, for particular sites or networks.
One reference text for potential drivers for policy change is RFC One reference text for potential drivers for policy change is RFC
5220, in which operational issues with the existing policies 5220, in which operational issues with the existing policies
described in RFC 3484 are listed. Each subsection of this document described in RFC 3484 are listed. Each subsection of this document
gives a reason why the existing rules or policy tables in RFC 3484 gives a reason why the existing rules or policy tables in RFC 3484
skipping to change at page 7, line 19 skipping to change at page 7, line 25
The other examples above are, in the general case, where the site The other examples above are, in the general case, where the site
administrator chooses to change a local policy and in doing so administrator chooses to change a local policy and in doing so
triggers the need for policy table updates. Some of these changes triggers the need for policy table updates. Some of these changes
one might assume to be set once, and to change rarely, for example: 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 IPv6 over IPv4 (or vice versa).
o Setting priority use of ULAs over globals (or vice versa). o Setting priority use of ULAs over globals (or vice versa).
o Setting priority of Teredo over native IPv4 (or vice versa).
o Setting priority use of privacy addresses over DNS-published o Setting priority use of privacy addresses over DNS-published
globals (or vice versa). globals (or vice versa).
o An internal network renumbering occurs, perhaps due to a site o An internal network renumbering occurs, perhaps due to a site
expanding. expanding.
o The nature of the external connectivity through multiple ISPs o The nature of the external connectivity through multiple ISPs
requires specific additional information (policy) to be delivered requires specific additional information (policy) to be delivered
to certain hosts (as discussed in 2.1.3 in RFC 5220). to certain hosts (as discussed in 2.1.3 in RFC 5220).
skipping to change at page 8, line 30 skipping to change at page 8, line 37
preferred policy change depending on the host's topological location preferred policy change depending on the host's topological location
within that site. Such a host should be capable of receiving policy within that site. Such a host should be capable of receiving policy
updates in a timely fashion as it migrates within the network. updates in a timely fashion as it migrates within the network.
While this may be one case of 'running changes' described above, the While this may be one case of 'running changes' described above, the
policy changes are required due to the host's new point of policy changes are required due to the host's new point of
attachment, not changes of policy to the current point of attachment. attachment, not changes of policy to the current point of attachment.
The frequency of updates are thus depend ant on the frequency of host The frequency of updates are thus depend ant on the frequency of host
mobility to parts of the network that have differing policies. mobility to parts of the network that have differing policies.
It is worth noting that the point at which a nomadic host configures
its network settings would be an appropriate time for it to also
receive any specific address selection policy for its point of
attachement.
4.5. Multiple Interface Nodes 4.5. Multiple Interface Nodes
In considering scenarios where hosts may be multi-addressed and In considering scenarios where hosts may be multi-addressed and
require policy to assist in address selection, the issue of hosts require policy to assist in address selection, the issue of hosts
with multiple interfaces arises. with multiple interfaces arises.
A host may have a variety of reasons to have multiple interfaces. It 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 may for example have WiFi and 3G interfaces, and be capable of
sending or receiving data over either interface. In some cases these sending or receiving data over either interface. In some cases these
interfaces may fall within the same administrative domain (ISP) and interfaces may fall within the same administrative domain (ISP) and
in some cases they may not. Another example would be the case of a in some cases they may not. Another example would be the case of a
host with a VPN connection established, where address selection may host with a VPN connection established, where address selection may
be affected by the choice of whether the VPN connection is used or be affected by the choice of whether the VPN connection is used or
not. not. In this case it is interesting to note the choice to use the
VPN tunnel for all, or just VPN home site traffic, is typically left
as a choice for the user via a tickbox selection.
This is clearly an important problem today, but we note that RFC 3484 Handling multiple interface nodes, and the possibility of conflicting
is currently defined as a per-node, not per-interface, mechanism. policy being retrieved via each, is clearly an important problem
However, for RFC 3484, and its potential update mechanisms, to be today, but we note that RFC 3484 is currently defined as a per-node,
applicable to typical 'real world' usage patterns, we should consider not per-interface, mechanism. However, for RFC 3484, and its
the multiple interface scenarios. potential update mechanisms, to be applicable to typical 'real world'
usage patterns, we should consider the multiple interface scenarios.
In the case where a host has multiple interfaces there are two likely In the case where a host has multiple interfaces there are two likely
scenarios: scenarios:
o Wired and wireless interfaces - in this case the operating system o Wired and wireless interfaces - in this case the operating system
just needs to pick one interface and use it. just needs to pick one interface and use it.
o Normal and VPN interfaces - here the default should be the normal o Normal and VPN interfaces - here the default should be the normal
interface; the VPN interface should only be used for destinations interface; the VPN interface should only be used for destinations
associated with the VPN. associated with the VPN.
skipping to change at page 11, line 37 skipping to change at page 12, line 5
that all nodes have common understanding of what the 'default' is (in that all nodes have common understanding of what the 'default' is (in
principle, that all nodes implement any future revised RFC 3484 principle, that all nodes implement any future revised RFC 3484
default policy table). default policy table).
6.4. Policy Conflicts 6.4. Policy Conflicts
In the case of a host operating in a single administrative domain, In the case of a host operating in a single administrative domain,
consistent policy should be available from whichever policy consistent policy should be available from whichever policy
distribution mechanism provides the information. However, in distribution mechanism provides the information. However, in
scenarios where a host is multi-addressed from multiple providers scenarios where a host is multi-addressed from multiple providers
(e.g. a SOHO network with differing DSL and cable providers) there is (e.g. a SOHO network with differing DSL and cable providers, or a
likely to be some conflicts in the received RFC 3484 policy user in a coffee shop initiating a VPN connection to their home
information. For the policy update mechanism to be applicable in the network) there is likely to be some conflicts in the received RFC
general case, we need to include potential policy conflicts from such 3484 policy information.
scenarios. An initial draft on handling such policy conflicts has
been released [I-D.arifumi-6man-addr-select-conflict]. The question then is whether the policy update mechanism itself needs
to handle such potential conflicts, choosing one or ther other or
merging by some set of heuristics, or whether the policy update
mechansism should be viewed independently of the conflict handling.
The view of the design team was that distributing policy is a network
problem, while handling conflicts is a host problem.
An initial draft on handling policy conflicts has been released
separately [I-D.arifumi-6man-addr-select-conflict] given the topic is
beyond the scope of this draft.
7. Solution Space 7. Solution Space
In this section we make some initial observations on the possible In this section we make some initial observations on the possible
solution space. solution space.
7.1. Is default policy used? 7.1. Is default policy used?
There could be some mechanism to indicate to a host that the local There could be some mechanism to indicate to a host that the local
network has a modified RFC 3484 policy in use, and thus that a network has a modified RFC 3484 policy in use, and thus that a
revised policy table is available (and should be used). revised policy table is available (and should be used).
Alternatively a host could simply attempt to obtain local RFC 3484 Alternatively a host could simply always attempt to obtain local RFC
policy on startup regardless. Regardless, it should also be possible 3484 policy on startup. Regardless, it should also be possible for a
for a host to detect that policy has changed (whether 'around' the host to detect that policy has changed (whether 'around' the host, or
host, or due to the host being nomadic). due to the host being nomadic). The method to convey this chnage to
a host would depend on whether a push or pull configuration method is
used.
It is assumed by 'default' policy here we refer to the revised/ It is assumed by 'default' policy here we refer to the revised/
updated RFC3484 specification, when that is produced. The question updated RFC3484 specification, when that is produced.
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 7.2. Pull model
One potential solution is that a host uses a similar mechanism for One potential solution is that a host uses a similar mechanism for
RFC 3484 policy updates as is used for obtaining other configuration RFC 3484 policy updates as is used for obtaining other configuration
data, for example DHCPv6 [RFC3315]. For hosts using stateless data, for example DHCPv6 [RFC3315]. For hosts using stateless
autoconfiguration, policy could be available via stateless DHCPv6 autoconfiguration, policy could be available via stateless DHCPv6
[RFC3736]. [RFC3736].
There are also already some initial proposals from the IETF mif WG on There are also already some initial proposals from the IETF mif WG on
skipping to change at page 13, line 44 skipping to change at page 14, line 15
currently valid. This application seems possible within the IPv6 currently valid. This application seems possible within the IPv6
Neighbour Discovery architecture, but does not appear to be clearly Neighbour Discovery architecture, but does not appear to be clearly
specified anywhere." specified anywhere."
The same thought seems relevant to address selection. There's no The same thought seems relevant to address selection. There's no
point selecting a source address whose prefix is not being advertised point selecting a source address whose prefix is not being advertised
in RAs. in RAs.
While routing and prefix hints may help a host make selection While routing and prefix hints may help a host make selection
decisions, we should consider to what extent we wish to 'burden' a decisions, we should consider to what extent we wish to 'burden' a
host with holding such information. host with holding such information. If a host is to determine and
cache routing hints, this may require an update of RFC 3484 policy
table syntax to support preference for address pairs.
7.5. Conflicts/Merging Policies 7.5. Conflicts/Merging Policies
As discussed above, the solution used to allow a host to determine
its address selection policy should be considered separately from the
heuristics a host may use to choose how to resolve any policy
conflicts where configurations are received from multiple sources.
We believe the conflict handling should be progressed in a separate
text, but have included some initial considerations here.
For whatever mechanism is used to distribute RFC 3484 policy, it is For whatever mechanism is used to distribute RFC 3484 policy, it is
not yet clear whether entire policy tables will be made available, or not yet clear whether entire policy tables will be made available, or
simply differences to the 'default', and thus whether policies may simply differences to the 'default', and thus whether policies may
need to be merged, or overridden. Some policy conflicts will be need to be merged, or overridden. Some policy conflicts will be
unresolvable, e.g. one prefers IPv4 over IPv6, the other vice-versa. unresolvable, e.g. one prefers IPv4 over IPv6, the other vice-versa.
It may be simpler, though less efficient, for whole policy tables to It may be simpler, though less efficient, for whole policy tables to
be distributed, to avoid the merger problem. be distributed, to avoid the merger problem.
One option may be to split the policy table into destination address One option may be to split the policy table into destination address
selection and source address selection tables, with the policy selection and source address selection tables, with the policy
skipping to change at page 15, line 28 skipping to change at page 16, line 11
preclude future flexibility. It seems clear that any RFC 3484 update preclude future flexibility. It seems clear that any RFC 3484 update
has two aspects: one that uses the existing policy table capability, has two aspects: one that uses the existing policy table capability,
and one that might change associated algorithms. and one that might change associated algorithms.
9. Conclusions 9. Conclusions
We believe the general scope of this text applies to site and We believe the general scope of this text applies to site and
enterprise networks, where an administrator may need to change enterprise networks, where an administrator may need to change
policies over time, but that it includes nomadic nodes within the policies over time, but that it includes nomadic nodes within the
site, which may migrate to different parts of the site where site, which may migrate to different parts of the site where
different policies are required. However, we do not preclude other different policies are required. We believe a key outcome of this
environments which might, in particular, introduce (partially or text should be progression of a solution to allow an enterprise
more) conflicting policies from different administrative domains, network manager to configure their hosts with address selection
e.g. in the SOHO space. We include multiple interface nodes in the policies that differ from the RFC 3484 default, across all or part of
discussion, and note there are two general cases, namely wired/air their network, and possibly changing polciy with time.
(or wlan/3G) interface, and normal/VPN interfaces, for which
different solutions are likely to apply. It is clear there may be environments which might introduce
conflicting policies from different administrative domains, e.g. a
SOHO network with two ISP links, or an enterprise node running a VPN
to a remote network. We conclude that the policy distribution
mechanism is a network task, while policy conflict handling is a host
task, and thus argue that we should progress the policy distribution
solution while analysing conflict handling (which is not unique to
this domain) in a separate text.
There is clearly a need to revise RFC 3484, to create a new default There is clearly a need to revise RFC 3484, to create a new default
policy table for address selection, and to improve non policy table policy table for address selection, and to improve non policy table
algorithms. This should be expedited. We also note that RFC 3484 is algorithms. This should be expedited. We also note that RFC 3484 is
currently defined on a per-node, not per-interface basis, which we currently defined on a per-node, not per-interface basis, which we
believe should remain the status quo for the scope of this work. The believe should remain the status quo for the scope of this work. The
node-wide problem is destination address selection. node-wide problem is destination address selection.
The scope of this text includes issues affecting the design of a The scope of this text includes issues affecting the design of a
protocol to allow a host's RFC 3484 policy table to be updated. From protocol to allow a host's RFC 3484 policy table to be updated. From
discussion of update triggers/scenarios, we believe rapid updates are discussion of update triggers/scenarios, we believe rapid updates are
unlikely unless a node is in a network which has (very) dynamic unlikely unless a node is in a network which has (very) dynamic
external traffic engineering, or many nodes are mobile between parts external traffic engineering, or many nodes are mobile between parts
of the network with differing policy. It's thus probably appropriate of the network with differing policy. It's thus probably appropriate
to use a similar method to obtain RFC 3484 policy as to obtain other to use a similar method to obtain RFC 3484 policy as to obtain other
configuration data. configuration data.
Hosts may receive conflicting policy updates in some cases,
particularly where they receive information from different
administrative domains; some initial work in analysing the conflict
scenarios is underway.
In terms of push or pull-based methods for policy distribution, our In terms of push or pull-based methods for policy distribution, our
discussions suggest that a push-based hint to hosts as to whether discussions suggest that a push-based hint to hosts as to whether
they are in a network where a (non default) local policy applies or they are in a network where a (non default) local policy applies or
not could be useful. This might be indicated via a RA option. In not could be useful. This might be indicated via a RA option. In
terms of obtaining policy, a pull-based solution, such as DHCPv6, may terms of obtaining policy, a pull-based solution, such as DHCPv6, may
be appropriate in managed environments (where managed non-default be appropriate in managed environments (where managed non-default
policies are most likely to be in effect). DHCPv6 is also preferable policies are most likely to be in effect). DHCPv6 is also preferable
if individual hosts on a subnet require different policies. if individual hosts on a subnet require different policies.
Further comments on this draft are welcomed. Further comments on this draft are welcomed.
skipping to change at page 17, line 22 skipping to change at page 18, line 4
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Problem Statement for Default Address Selection in Multi- "Problem Statement for Default Address Selection in Multi-
Prefix Environments: Operational Issues of RFC 3484 Prefix Environments: Operational Issues of RFC 3484
Default Rules", RFC 5220, July 2008. Default Rules", RFC 5220, July 2008.
[RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Requirements for Address Selection Mechanisms", RFC 5221, "Requirements for Address Selection Mechanisms", RFC 5221,
July 2008. July 2008.
[I-D.ietf-6man-addr-select-sol] [I-D.ietf-6man-addr-select-sol]
Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution
"Solution approaches for address-selection problems", approaches for address-selection problems",
draft-ietf-6man-addr-select-sol-02 (work in progress), draft-ietf-6man-addr-select-sol-03 (work in progress),
July 2009. March 2010.
[I-D.arifumi-6man-rfc3484-revise] [I-D.arifumi-6man-rfc3484-revise]
Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, Matsumoto, A., Fujisaki, T., and R. Hiromi, "Things To Be
"Things To Be Considered for RFC 3484 Revision", Considered for RFC 3484 Revision",
draft-arifumi-6man-rfc3484-revise-01 (work in progress), draft-arifumi-6man-rfc3484-revise-02 (work in progress),
March 2009. October 2009.
[I-D.fujisaki-dhc-addr-select-opt] [I-D.fujisaki-dhc-addr-select-opt]
Fujisaki, T., Matsumoto, A., and R. Hiromi, "Distributing Fujisaki, T., Matsumoto, A., and R. Hiromi, "Distributing
Address Selection Policy using DHCPv6", Address Selection Policy using DHCPv6",
draft-fujisaki-dhc-addr-select-opt-08 (work in progress), draft-fujisaki-dhc-addr-select-opt-09 (work in progress),
October 2009. March 2010.
[I-D.blanchet-mif-problem-statement] [I-D.blanchet-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces Problem Blanchet, M. and P. Seite, "Multiple Interfaces Problem
Statement", draft-blanchet-mif-problem-statement-01 (work Statement", draft-blanchet-mif-problem-statement-01 (work
in progress), June 2009. in progress), June 2009.
[I-D.dec-dhcpv6-route-option] [I-D.dec-dhcpv6-route-option]
Dec, W. and R. Johnson, "DHCPv6 Route Option", Dec, W. and R. Johnson, "DHCPv6 Route Option",
draft-dec-dhcpv6-route-option-01 (work in progress), draft-dec-dhcpv6-route-option-03 (work in progress),
March 2009. March 2010.
[I-D.sun-mif-address-policy-dhcp6] [I-D.sun-mif-address-policy-dhcp6]
Sun, T., Deng, H., and X. Duan, "Address Selection Policy Sun, T., Deng, H., and X. Duan, "Address Selection Policy
Configuration by DHCPv6 Option", Configuration by DHCPv6 Option",
draft-sun-mif-address-policy-dhcp6-01 (work in progress), draft-sun-mif-address-policy-dhcp6-01 (work in progress),
March 2009. March 2009.
[I-D.sarikaya-mif-dhcpv6solution] [I-D.sarikaya-mif-dhcpv6solution]
Sarikaya, B., Xia, F., and P. Seite, "DHCPv6 Extension for Sarikaya, B., Xia, F., and P. Seite, "DHCPv6 Extension for
Configuring Hosts with Multiple Interfaces", Configuring Hosts with Multiple Interfaces",
draft-sarikaya-mif-dhcpv6solution-02 (work in progress), draft-sarikaya-mif-dhcpv6solution-04 (work in progress),
September 2009. July 2010.
[I-D.sun-mif-route-config-dhcp6] [I-D.sun-mif-route-config-dhcp6]
Sun, T. and H. Deng, "Route Configuration by DHCPv6 Option Sun, T. and H. Deng, "Route Configuration by DHCPv6 Option
for Hosts with Multiple Interfaces", for Hosts with Multiple Interfaces",
draft-sun-mif-route-config-dhcp6-01 (work in progress), draft-sun-mif-route-config-dhcp6-01 (work in progress),
March 2009. March 2009.
[I-D.arifumi-6man-addr-select-conflict] [I-D.arifumi-6man-addr-select-conflict]
Matsumoto, A., Fujisaki, T., and R. Hiromi, Matsumoto, A., Fujisaki, T., and R. Hiromi,
"Considerations of address selection policy conflicts", "Considerations of address selection policy conflicts",
draft-arifumi-6man-addr-select-conflict-00 (work in draft-arifumi-6man-addr-select-conflict-02 (work in
progress), July 2009. progress), March 2010.
[I-D.denis-v6ops-nat-addrsel] [I-D.denis-v6ops-nat-addrsel]
Denis-Courmont, R., "Problems with IPv6 source address Denis-Courmont, R., "Problems with IPv6 source address
selection and IPv4 NATs", draft-denis-v6ops-nat-addrsel-00 selection and IPv4 NATs", draft-denis-v6ops-nat-addrsel-00
(work in progress), February 2009. (work in progress), February 2009.
[I-D.carpenter-renum-needs-work] [I-D.carpenter-renum-needs-work]
Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
still needs work", draft-carpenter-renum-needs-work-03 still needs work", draft-carpenter-renum-needs-work-05
(work in progress), May 2009. (work in progress), January 2010.
[I-D.troan-multihoming-without-nat66]
Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D.
Wing, "IPv6 Multihoming without Network Address
Translation", draft-troan-multihoming-without-nat66-00
(work in progress), May 2010.
Author's Address Author's Address
Tim Chown (editor) Tim Chown (editor)
University of Southampton University of Southampton
Southampton, Hampshire SO17 1BJ Southampton, Hampshire SO17 1BJ
United Kingdom United Kingdom
Email: tjc@ecs.soton.ac.uk Email: tjc@ecs.soton.ac.uk
 End of changes. 33 change blocks. 
116 lines changed or deleted 154 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/