draft-ietf-6man-addr-select-considerations-01.txt   draft-ietf-6man-addr-select-considerations-02.txt 
IPv6 Maintenance T. Chown, Ed. IPv6 Maintenance T. Chown, Ed.
Internet-Draft University of Southampton Internet-Draft University of Southampton
Intended status: Informational July 11, 2010 Intended status: Informational July 12, 2010
Expires: January 12, 2011 Expires: January 13, 2011
Considerations for IPv6 Address Selection Policy Changes Considerations for IPv6 Address Selection Policy Changes
draft-ietf-6man-addr-select-considerations-01 draft-ietf-6man-addr-select-considerations-02
Abstract Abstract
Where the source and/or destination node of an IPv6 communication is Where the source and/or destination node of an IPv6 communication is
multi-addressed, a mechanism is required for the initiating node to multi-addressed, a mechanism is required for the initiating node to
select the most appropriate address pair for the communication. RFC select the most appropriate address pair for the communication. RFC
3484 (IPv6 Default Address Selection) [RFC3484] defines such a 3484 (IPv6 Default Address Selection) [RFC3484] defines such a
mechanism for nodes to perform source and destination address mechanism for nodes to perform source and destination address
selection. While RFC3484 recognised the need for implementations to selection. While RFC3484 recognised the need for implementations to
be able to change the policy table, it did not define how this could be able to change the policy table, it did not define how this could
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. 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."
This Internet-Draft will expire on January 12, 2011. This Internet-Draft will expire on January 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 16 skipping to change at page 3, line 16
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? . . . . . . . . . . . . . . . . . . . . . . . . . 10
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) . . . . . . . . . . . . . 11
6.2. Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 11
6.3. Manual Configuration? . . . . . . . . . . . . . . . . . . 11 7. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 11
6.4. Policy Conflicts . . . . . . . . . . . . . . . . . . . . . 11 7.1. Is default policy used? . . . . . . . . . . . . . . . . . 11
7. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Is default policy used? . . . . . . . . . . . . . . . . . 12
7.2. Pull model . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Pull model . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3. Push model . . . . . . . . . . . . . . . . . . . . . . . . 13 7.3. Push model . . . . . . . . . . . . . . . . . . . . . . . . 12
7.4. Routing Hints . . . . . . . . . . . . . . . . . . . . . . 13 7.4. Routing Hints . . . . . . . . . . . . . . . . . . . . . . 12
7.5. Conflicts/Merging Policies . . . . . . . . . . . . . . . . 14 7.5. Policy Conflicts . . . . . . . . . . . . . . . . . . . . . 13
8. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . 15 7.6. Policy Merging . . . . . . . . . . . . . . . . . . . . . . 14
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
13. Informative References . . . . . . . . . . . . . . . . . . . . 17 13. Informative References . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 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
skipping to change at page 9, line 7 skipping to change at page 9, line 7
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. In this case it is interesting to note the choice to use the 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 VPN tunnel for all, or just VPN home site traffic, is often left as a
as a choice for the user via a tickbox selection. choice for the user via a tickbox selection. In addition, initiating
the VPN typically changes several related settings, which is
reasonable behaviour given the user chose to initiate the VPN
connection.
Handling multiple interface nodes, and the possibility of conflicting Handling multiple interface nodes, and the possibility of conflicting
policy being retrieved via each, is clearly an important problem policy being retrieved via each, is clearly an important problem
today, but we note that RFC 3484 is currently defined as a per-node, today, but we note that RFC 3484 is currently defined as a per-node,
not per-interface, mechanism. However, for RFC 3484, and its not per-interface, mechanism (at least in the context of destination
potential update mechanisms, to be applicable to typical 'real world' address selection). However, for RFC 3484, and its potential update
usage patterns, we should consider the multiple interface scenarios. 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 29 skipping to change at page 11, line 35
sufficiently with the address change. However, not all hosts may sufficiently with the address change. However, not all hosts may
receive the update information at the same time, e.g. where new receive the update information at the same time, e.g. where new
address assignments may be dependent on DHCP lease timers. address assignments may be dependent on DHCP lease timers.
Where hosts use DHCPv6 for address information, in the absence of Where hosts use DHCPv6 for address information, in the absence of
some form of Reconfigure message, a host may see a delay in policy 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 changes being notified. One possible tool to help here is the DHCPv6
Lifetime Option (RFC4242) [RFC4242], which was originally introduced Lifetime Option (RFC4242) [RFC4242], which was originally introduced
to assist with network renumbering events. 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 there could be value in having a flag
of some kind to inform a host whether network it is in uses the
default RFC 3484 policy, which would then allow each end system to
decide if it should get an (overriding) local policy or not. One
problem with this though is that some operating systems already
implement 'modified' RFC 3484 behaviour, so we would have to be sure
that all nodes have common understanding of what the 'default' is (in
principle, that all nodes implement any future revised RFC 3484
default policy table).
6.4. Policy Conflicts
In the case of a host operating in a single administrative domain,
consistent policy should be available from whichever policy
distribution mechanism provides the information. However, in
scenarios where a host is multi-addressed from multiple providers
(e.g. a SOHO network with differing DSL and cable providers, or a
user in a coffee shop initiating a VPN connection to their home
network) there is likely to be some conflicts in the received RFC
3484 policy information.
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).
skipping to change at page 12, line 46 skipping to change at page 12, line 13
used. 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. updated RFC3484 specification, when that is produced.
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 made available via stateless
[RFC3736]. DHCPv6 [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
using DHCPv6 to deliver (mainly routing oriented) information to using DHCPv6 to deliver (mainly routing oriented) information to
hosts, e.g. [I-D.sun-mif-route-config-dhcp6], hosts, e.g. [I-D.sun-mif-route-config-dhcp6],
[I-D.dec-dhcpv6-route-option], [I-D.sun-mif-address-policy-dhcp6] and [I-D.dec-dhcpv6-route-option], [I-D.sun-mif-address-policy-dhcp6] and
[I-D.sarikaya-mif-dhcpv6solution]. These methods assume entities [I-D.sarikaya-mif-dhcpv6solution]. These methods assume entities
that have timely knowledge of routing information can provide equally that have timely knowledge of routing information can provide equally
timely hints to hosts on address selection, via DHCPv6. At this timely hints to hosts on address selection, via DHCPv6. At this
stage we believe that distributing RFC 3484 policy, as configured by stage we believe that distributing RFC 3484 policy, as configured by
an administrator, is a more practical use of DHCPv6. If future an administrator, is a more practical use of DHCPv6.
methods offer additional 'hints' based on routing information, this
becomes part of the 'policy conflict' problem to be solved.
The DHCP model allows individual nodes to potentially have differing The DHCP model allows individual nodes to potentially have differing
policy, even when on the same subnet. policy, even when on the same subnet.
7.3. Push model 7.3. Push model
For hosts only using stateless autoconfiguration, in environments For hosts only using stateless autoconfiguration, in environments
without DHCPv6, it can be argued that since the network is not without stateless DHCPv6, it may be argued that since the network is
managed, there is not likely to be any 'managed' policy to push to not managed, there is not likely to be any managed policy to push to
the hosts. In such environments hosts may perhaps more usefully use the hosts. In such environments hosts may perhaps more usefully use
techniques such as router hints to make informed selections, as techniques such as router hints to make informed selections, as
discussed later in this text. discussed later in this text.
It may of course be possible to piggy back policy information to a It may of course be possible to piggy back policy information to a
host in a Router Advertisement message, though initial consensus host in a Router Advertisement message, though initial consensus
seems to be that this is a less attractive approach. However, we may seems to be that this is a less attractive approach.
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 7.4. Routing Hints
As mentioned above, if a host has routing hints available, it may be As mentioned above, if a host has routing hints available, it may be
able to make more informed selections. For example, a protocol could able to make more informed selections. For example, a protocol could
be specified for a node to query an on-link or remote (e.g. edge) be specified for a node to query an on-link or remote (e.g. edge)
router for 'hints'. Having hosts themselves participate in routing router for 'hints'. For example, a new ICMPv6 message could be
is generally not desirable. At this stage we can simply note that defined that queried a site edge router or route server for address
address selection might be simplified when some hint based on routing pairs to use for a given destination address.
state is provided to the end system, but such mechanisms are out of
scope for this text. However, having hosts themselves participate in routing is generally
not desirable. At this stage we can simply note that address
selection might be simplified when some hint based on routing state
is provided to the end system, but such mechanisms are out of scope
for this text.
It is noted in [I-D.carpenter-renum-needs-work] that: It is noted in [I-D.carpenter-renum-needs-work] that:
"In an environment where a site has more than one upstream link to "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 the outside world, the site might have more than one valid routing
prefix. In such cases, typically all valid routing prefixes within a prefix. In such cases, typically all valid routing prefixes within a
site will have the same prefix length. Also in such cases, it might site will have the same prefix length. Also in such cases, it might
be desirable for hosts that obtain their addresses using DHCPv6 to be desirable for hosts that obtain their addresses using DHCPv6 to
learn about the availability of upstream links dynamically, by learn about the availability of upstream links dynamically, by
deducing from periodic IPv6 RA messages which routing prefixes are deducing from periodic IPv6 RA messages which routing prefixes are
skipping to change at page 14, line 19 skipping to change at page 13, line 31
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. If a host is to determine and host with holding such information. If a host is to determine and
cache routing hints, this may require an update of RFC 3484 policy cache routing hints, this may require an update of RFC 3484 policy
table syntax to support preference for address pairs. table syntax to support preference for address pairs.
7.5. Conflicts/Merging Policies 7.5. Policy Conflicts
As discussed above, the solution used to allow a host to determine In the case of a host operating in a single administrative domain,
its address selection policy should be considered separately from the consistent policy should be available from whichever policy
heuristics a host may use to choose how to resolve any policy distribution mechanism provides the information. In such cases the
conflicts where configurations are received from multiple sources. network should not distribute policy sets from multiple entities (or
We believe the conflict handling should be progressed in a separate by multiple mechanisms). However, in scenarios where a host is
text, but have included some initial considerations here. multi-addressed from multiple providers (e.g. a SOHO network with
differing DSL and cable providers, or a user in a coffee shop
initiating a VPN connection to their home network), multiple RFC 3484
policies may be received and there is likely to be some conflicts in
the received policy information.
There are scenarios where a host may wish to ignore a 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 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.6. Policy Merging
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
distribution only updating the source address selection. Whether distribution only updating the source address selection. Whether
this might make merging policies simpler or in fact more complex this might make merging policies simpler or in fact more complex
would require further study. would require further study.
It may also be possible to indicate some priority value for a policy, 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 e.g. the priority of the interface it is received on, or perhaps to
are multiple policies in conflict, a host could simply choose to fall convey a unique identifier for the policy provider. Alternatibely,
back to use the default RFC 3484 policy. if there are multiple policies in conflict, a host could simply
choose to fall back to use the default RFC 3484 policy.
A host also needs to know how to decide when to accept a policy. We 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 could simplify the discussion by assuming a host is located in and
only nomadic within a single site with one administrative controlling only nomadic within a single site with one administrative controlling
entity. entity.
8. On RFC3484 Default Policies 8. On RFC3484 Default Policies
RFC 3484 includes text about mechanisms for changing policy, having RFC 3484 includes text about mechanisms for changing policy, having
'policy hooks' and having a configurable policy table. The 'policy hooks' and having a configurable policy table. The
skipping to change at page 16, line 7 skipping to change at page 15, line 41
operational experience. operational experience.
It is hard to predict exactly what features people will want to add It is hard to predict exactly what features people will want to add
to address selection algorithms in the future. Ideally we should not to address selection algorithms in the future. Ideally we should not
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 a key outcome of this text should be progression of a
enterprise networks, where an administrator may need to change solution to allow an enterprise network manager to configure their
policies over time, but that it includes nomadic nodes within the hosts with address selection policies that may differ from the RFC
3484 default, across all or part of their network, and possibly
changing polciy with time. The general scope of this text applies to
site and enterprise networks, where an administrator may need to
change policies over time. It also 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. We believe a key outcome of this different policies are required.
text should be progression of a solution to allow an enterprise
network manager to configure their hosts with address selection
policies that differ from the RFC 3484 default, across all or part of
their network, and possibly changing polciy with time.
It is clear there may be environments which might introduce It is clear there may be environments which might introduce
conflicting policies from different administrative domains, e.g. a conflicting policies from different administrative domains, e.g. a
SOHO network with two ISP links, or an enterprise node running a VPN SOHO network with two ISP links, or an enterprise node running a VPN
to a remote network. We conclude that the policy distribution to a remote network. We conclude that the policy distribution
mechanism is a network task, while policy conflict handling is a host mechanism is a network task, while policy conflict handling is a host
task, and thus argue that we should progress the policy distribution task. Within this text, we do not present a solution for policy
solution while analysing conflict handling (which is not unique to conflict handling, because at this time there is no perfect or
this domain) in a separate text. practical solution. We thus recommend that we should progress the
policy distribution solution while analysing conflict handling (which
There is clearly a need to revise RFC 3484, to create a new default is not unique to this domain) in a separate text.
policy table for address selection, and to improve non policy table
algorithms. This should be expedited. We also note that RFC 3484 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. The
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 to be required unless a node is in a network which has
external traffic engineering, or many nodes are mobile between parts (very) dynamic external traffic engineering, or many nodes are mobile
of the network with differing policy. It's thus probably appropriate between parts of the network with differing policy. It's thus
to use a similar method to obtain RFC 3484 policy as to obtain other generally appropriate to use a similar method to obtain RFC 3484
configuration data. policy as to obtain other configuration data.
In terms of push or pull-based methods for policy distribution, our In terms of obtaining policy, a pull-based solution, such as DHCPv6,
discussions suggest that a push-based hint to hosts as to whether may be more appropriate in managed environments (where managed non-
they are in a network where a (non default) local policy applies or default policies are most likely to be in effect), which would assure
not could be useful. This might be indicated via a RA option. In that hosts only gain policy information from a single entity (the
terms of obtaining policy, a pull-based solution, such as DHCPv6, may DHCPv6 service). Use of DHCPv6 is also preferable if individual
be appropriate in managed environments (where managed non-default hosts on a subnet require different policies. In unmanaged networks,
policies are most likely to be in effect). DHCPv6 is also preferable without stateless DHCPv6, use of routing hints may be an approach
if individual hosts on a subnet require different policies. worth exploring.
Further comments on this draft are welcomed. Finally, there is a clear need to revise RFC 3484, to create a new
default policy table for address selection, and to improve non policy
table algorithms. This should be expedited.
10. Security Considerations 10. Security Considerations
There are no extra Security consideration for this document. There are no extra Security consideration for this document.
11. IANA Considerations 11. IANA Considerations
There are no extra IANA consideration for this document. There are no extra IANA consideration for this document.
12. Acknowledgements 12. Acknowledgements
skipping to change at page 18, line 12 skipping to change at page 17, line 44
[I-D.ietf-6man-addr-select-sol] [I-D.ietf-6man-addr-select-sol]
Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution
approaches for address-selection problems", approaches for address-selection problems",
draft-ietf-6man-addr-select-sol-03 (work in progress), draft-ietf-6man-addr-select-sol-03 (work in progress),
March 2010. March 2010.
[I-D.arifumi-6man-rfc3484-revise] [I-D.arifumi-6man-rfc3484-revise]
Matsumoto, A., Fujisaki, T., and R. Hiromi, "Things To Be Matsumoto, A., Fujisaki, T., and R. Hiromi, "Things To Be
Considered for RFC 3484 Revision", Considered for RFC 3484 Revision",
draft-arifumi-6man-rfc3484-revise-02 (work in progress), draft-arifumi-6man-rfc3484-revise-03 (work in progress),
October 2009. July 2010.
[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-09 (work in progress), draft-fujisaki-dhc-addr-select-opt-09 (work in progress),
March 2010. 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., Johnson, R., Mrugalski, T., and A. Matsumoto,
draft-dec-dhcpv6-route-option-03 (work in progress), "DHCPv6 Route Options", draft-dec-dhcpv6-route-option-04
March 2010. (work in progress), July 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-04 (work in progress), draft-sarikaya-mif-dhcpv6solution-04 (work in progress),
July 2010. 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., Deng, H., and D. Liu, "Route Configuration by
for Hosts with Multiple Interfaces", DHCPv6 Option for Hosts with Multiple Interfaces",
draft-sun-mif-route-config-dhcp6-01 (work in progress), draft-sun-mif-route-config-dhcp6-02 (work in progress),
March 2009. July 2010.
[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-02 (work in draft-arifumi-6man-addr-select-conflict-02 (work in
progress), March 2010. 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
 End of changes. 27 change blocks. 
130 lines changed or deleted 113 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/