draft-ietf-6man-addr-select-considerations-04.txt   draft-ietf-6man-addr-select-considerations-05.txt 
IPv6 Maintenance T. Chown, Ed. IPv6 Maintenance T.J. Chown, Ed.
Internet-Draft University of Southampton Internet-Draft University of Southampton
Intended status: Informational A. Matsumoto, Ed. Intended status: Informational A.M. Matsumoto, Ed.
Expires: May 3, 2012 NTT Expires: October 03, 2013 NTT
October 31, 2011 April 01, 2013
Considerations for IPv6 Address Selection Policy Changes Considerations for IPv6 Address Selection Policy Changes
draft-ietf-6man-addr-select-considerations-04 draft-ietf-6man-addr-select-considerations-05
Abstract Abstract
Where the source and/or destination node of an IPv6 communication is This ducument is intended to capture the address selection design
multi-addressed, a mechanism is required for the initiating node to team's considerations about the address selection issues mainly
select the most appropriate address pair for the communication. RFC raised in [RFC5220]. This considerations led to the revision of RFC
3484 (IPv6 Default Address Selection) [RFC3484] defines such a 3484 [RFC6724], and Address Selection DHCP option. Although it does
mechanism for nodes to perform source and destination address not perfectly match the current state, this document captures the
selection. While RFC3484 recognised the need for implementations to past discussion and considerations for the historical record.
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 in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 May 3, 2012. This Internet-Draft will expire on October 03, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Copyright (c) 2013 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 7 skipping to change at page 2, line 21
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Issues to Consider . . . . . . . . . . . . . . . . . . . . . . 4 2. Issues to Consider . . . . . . . . . . . . . . . . . . . . . 3
3. Other Related Work . . . . . . . . . . . . . . . . . . . . . . 5 3. Other Related Work . . . . . . . . . . . . . . . . . . . . . 4
4. Drivers for Policy Changes . . . . . . . . . . . . . . . . . . 5 4. Drivers for Policy Changes . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . 6
4.3. Start-up vs Running Changes . . . . . . . . . . . . . . . 8 4.3. Start-up vs Running Changes . . . . . . . . . . . . . . . 7
4.4. Nomadic Nodes . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Nomadic Nodes . . . . . . . . . . . . . . . . . . . . . . 7
4.5. Multiple Interface Nodes . . . . . . . . . . . . . . . . . 8 4.5. Multiple Interface Nodes . . . . . . . . . . . . . . . . 8
5. How Dynamic? . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. How Dynamic? . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Considerations when Obtaining Policy . . . . . . . . . . . . . 10 6. Considerations when Obtaining Policy . . . . . . . . . . . . 10
6.1. Changes in Available Address(es) . . . . . . . . . . . . . 11 6.1. Changes in Available Address(es) . . . . . . . . . . . . 10
6.2. Timeliness . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. Timeliness . . . . . . . . . . . . . . . . . . . . . . . 10
7. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Solution Space . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Is default policy used? . . . . . . . . . . . . . . . . . 11 7.1. Is default policy used? . . . . . . . . . . . . . . . . . 11
7.2. Pull model . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. Pull model . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. Push model . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. Push model . . . . . . . . . . . . . . . . . . . . . . . 11
7.4. Routing Hints . . . . . . . . . . . . . . . . . . . . . . 12 7.4. Routing Hints . . . . . . . . . . . . . . . . . . . . . . 12
7.5. Policy Conflicts . . . . . . . . . . . . . . . . . . . . . 13 7.5. Policy Conflicts . . . . . . . . . . . . . . . . . . . . 12
7.6. Policy Merging . . . . . . . . . . . . . . . . . . . . . . 14 7.6. Policy Merging . . . . . . . . . . . . . . . . . . . . . 13
8. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . 14 8. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . 14
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
10. Security Considerations . . . . . . . . . . . . . . . . . . . 16 10. Security Considerations . . . . . . . . . . . . . . . . . . . 16
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
13. Informative References . . . . . . . . . . . . . . . . . . . . 17 13. Informative References . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
This ducument is intended to capture the past discussions and
considerations about the address selection issues mainly raised in
[RFC5220]. This considerations led to the revision of RFC 3484
[RFC6724], and Address Selection DHCP option
[I-D.ietf-6man-addr-select-opt]. Although it does not necessarily
match the current state, this document captures the past discussion
and considerations for the historical record.
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 RFC 3484 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.
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 different default policy to that described in RFC 3484 is or different default policy to that described in RFC 3484 is
required, or for nomadic hosts within a network for which policies required, or for nomadic hosts within a network for which policies
may vary depending on their location within the network. 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
changes while a system is running. We discuss this topic in Section changes while a system is running. We discuss this topic in
4. Section 4.
Second, by understanding how dynamic the policy update mechanism Second, by understanding how dynamic the policy update mechanism
needs to be we should be better placed to determine what types of needs to be we should be better placed to determine what types of
update approaches best meet those needs. There may be other update approaches best meet those needs. There may be other
considerations of course, e.g. whether the systems are in managed or considerations of course, e.g. whether the systems are in managed or
unmanaged environments, and whether the solution should be proactive unmanaged environments, and whether the solution should be proactive
or automated, as discussed in [I-D.ietf-6man-addr-select-sol]. or automated. Section 5 covers these issues.
Section 5 covers these issues.
Third, if we assume some policy update mechanism is defined we should Third, if we assume some policy update mechanism is defined we should
consider how hosts and systems may become aware that a policy change consider how hosts and systems may become aware that a policy change
has happened, and how policy can be disseminated in a timely fashion. has happened, and how policy can be disseminated in a timely fashion.
Thus we need to understand what kind of triggers can be identified Thus we need to understand what kind of triggers can be identified
that can be used for invoking the policy table update mechanism, e.g. that can be used for invoking the policy table update mechanism, e.g.
address re-obtainment, address lifetime expiration, or perhaps policy address re-obtainment, address lifetime expiration, or perhaps policy
lifetime expiration. We also need to consider what other factors may lifetime expiration. We also need to consider what other factors may
come into play, e.g. potential policy conflicts. This is discussed come into play, e.g. potential policy conflicts. This is discussed
in Section 6. in Section 6.
After analysing these issues, we can make some initial comments After analysing these issues, we can make some initial comments
regarding the potential solution spaces, and what models may be well regarding the potential solution spaces, and what models may be well
suited, e.g. push vs pull models, and what other methods might assist suited, e.g. push vs pull models, and what other methods might
us, e.g. hints from local routing tables. This is covered in Section assist us, e.g. hints from local routing tables. This is covered in
7. Section 7.
Finally, we should assess whether these update solutions require or Finally, we should assess whether these update solutions require or
need RFC 3484 to be updated. In some instances, we might envision need RFC 3484 to be updated. In some instances, we might envision
solutions that simply use RFC 3484 as guidelines and provide solutions that simply use RFC 3484 as guidelines and provide
sufficient controls to address the current limitations in the RFC. sufficient controls to address the current limitations in the RFC.
However, as noted in RFC 5220 [RFC5220], not all the operational However, as noted in RFC 5220 [RFC5220], not all the operational
issues observed to date can be remedied by updating RFC 3484 alone. issues observed to date can be remedied by updating RFC 3484 alone.
There is already a good analysis of issues with RFC 3484 and how the
text could be revised [I-D.ietf-6man-rfc3484-revise]).
3. Other Related Work 3. Other Related Work
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.ietf-6man-addr-select-opt], but these are not discussed here. [I-D.ietf-6man-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
skipping to change at page 5, line 42 skipping to change at page 5, line 14
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
may not be sufficient in certain cases. There have been some may not be sufficient in certain cases. There have been some
significant changes to IPv6 since RFC 3484 was drafted which have significant changes to IPv6 since RFC 3484 was drafted which have
impacted the RFC, e.g. the introduction of Unique Local Addresses impacted the RFC, e.g. the introduction of Unique Local Addresses
(ULAs), and concerns about the impact of using longest prefix (ULAs), and concerns about the impact of using longest prefix
matching on (DNS) round-robin load balancing. matching on (DNS) round-robin load balancing.
In summary, the issues raised in RFC 5220 were: In summary, the issues raised in RFC 5220 were:
o Multiple Routers on a Single Interface o Multiple Routers on a Single Interface
o Ingress Filtering o Ingress Filtering
o Half-Closed Network Problem (*) o Half-Closed Network Problem (*)
o Combined Use of Global and ULA addresses (*) o Combined Use of Global and ULA addresses (*)
o Site Renumbering (*) o Site Renumbering (*)
o Multicast Source Address Selection (*) o Multicast Source Address Selection (*)
skipping to change at page 6, line 50 skipping to change at page 6, line 26
If a site is multihomed using BGP and advertising a single prefix If a site is multihomed using BGP and advertising a single prefix
upstream, then no policy table manipulation is required for global upstream, then no policy table manipulation is required for global
address preferences. However where a site is multihomed by receiving address preferences. However where a site is multihomed by receiving
a prefix from each upstream provider, each host will have multiple a prefix from each upstream provider, each host will have multiple
addresses and many need policy table manipulation. In such a case, addresses and many need policy table manipulation. In such a case,
the policy table of hosts may need to be updated according to the the policy table of hosts may need to be updated according to the
routing policy. routing policy.
It should be noted that we have other mechanisms for dynamic routing It should be noted that we have other mechanisms for dynamic routing
topology change, for example deprecating one of the advertised topology change, for example deprecating one of the advertised
prefixes, e.g. when one of the upstream links has a problem. But prefixes, e.g. when one of the upstream links has a problem. But
such mechanisms may only help in some cases, and do not remove the such mechanisms may only help in some cases, and do not remove the
need for agility in the RFC 3484 policy. need for agility in the RFC 3484 policy.
Other examples of external factors include a new transition mechanism Other examples of external factors include a new transition mechanism
being defined (e.g. as with the emergence of Teredo using 2001::/32 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 as assigned by IANA) and its inclusion being required in the policy
table (at the time of writing Teredo is not included in RFC 3484, table (at the time of writing Teredo is not included in RFC 3484,
though some operating systems have added it), a new address block though some operating systems have added it), a new address block
being defined, or a site renumbering event that could be triggered by being defined, or a site renumbering event that could be triggered by
an upstream provider's actions. an upstream provider's actions.
4.2. Administratively Triggered Changes 4.2. Administratively Triggered Changes
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
skipping to change at page 9, line 39 skipping to change at page 9, line 13
associated with the VPN. associated with the VPN.
It has been suggested that an RFC 3484 policy table is required on a It has been suggested that an RFC 3484 policy table is required on a
per-interface basis, though the choice of interface may itself be per-interface basis, though the choice of interface may itself be
determined by the (destination) address selection process. As stated determined by the (destination) address selection process. As stated
above, RFC 3484's policy table is currently defined to be node-wide. above, RFC 3484's policy table is currently defined to be node-wide.
The node-wide problem is destination address selection when the The node-wide problem is destination address selection when the
source address is implied from a selected interface. source address is implied from a selected interface.
We note that there are some new, initial drafts published recently on We note that there are some new, initial drafts published recently on
the multiple interface problem [I-D.ietf-mif-problem-statement], and the multiple interface problem [RFC6418], and on a number of possible
on a number of possible DHCPv6 extensions, e.g. to inform hosts about DHCPv6 extensions, e.g. to inform hosts about routing information to
routing information to assist the selection process. assist the selection process., to inform hosts about DNS server
[I-D.ietf-mif-dhcpv6-route-option], to inform hosts about DNS server selection policy, [RFC6731]. These drafts fall within the remit of
selection policy, [I-D.ietf-mif-dns-server-selection]. These drafts the new IETF mif WG. We note that the mif WG may produce relevant
fall within the remit of the new IETF mif WG. We note that the mif work with respect to the analysis of RFC 3484 policy changes, but at
WG may produce relevant work with respect to the analysis of RFC 3484 this stage no such output exists for inclusion.
policy changes, but at this stage no such output exists for
inclusion.
5. How Dynamic? 5. How Dynamic?
The discussion above suggests that many of the potential triggers for 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 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 one-time policy change. It is thus unlikely that such administrative
changes will be frequent. changes will be frequent.
There are some cases where updates may be required to be more There are some cases where updates may be required to be more
frequent. In the example of a site which is implementing the gradual frequent. In the example of a site which is implementing the gradual
introduction of new policy across its network, while the frequency of introduction of new policy across its network, while the frequency of
changes may be relatively high, there is still probably only one or a changes may be relatively high, there is still probably only one or a
small number of changes per host. small number of changes per host.
There may be a higher rate of policy changes within a site if there There may be a higher rate of policy changes within a site if there
skipping to change at page 11, line 26 skipping to change at page 10, line 39
- in effect in its current locale. - in effect in its current locale.
6.2. Timeliness 6.2. Timeliness
In many, but not all, cases a policy change will need to be In many, but not all, cases a policy change will need to be
synchronised across a network. Thus there is a general issue of synchronised across a network. Thus there is a general issue of
timely and synchronised dissemination of new policy. If the policy timely and synchronised dissemination of new policy. If the policy
is distributed via the same mechanism that informs a host of a change is distributed via the same mechanism that informs a host of a change
of address(es), the application of the policy should be synchronised of address(es), the application of the policy should be synchronised
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.
7. Solution Space 7. Solution Space
skipping to change at page 12, line 18 skipping to change at page 11, line 30
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 made available via stateless autoconfiguration, policy could be made available via stateless
DHCPv6 [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.ietf-mif-dhcpv6-route-option] and hosts, e.g. DHCPv6 route option and [RFC6731]. These methods assume
[I-D.ietf-mif-dns-server-selection]. These methods assume entities entities that have timely knowledge of routing information can
that have timely knowledge of routing information can provide equally provide equally timely hints to hosts on address selection, via
timely hints to hosts on address selection, via DHCPv6. At this DHCPv6. At this stage we believe that distributing RFC 3484 policy,
stage we believe that distributing RFC 3484 policy, as configured by as configured by an administrator, is a more practical use of DHCPv6.
an administrator, is a more practical use of DHCPv6.
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 stateless DHCPv6, it may be argued that since the network is without stateless DHCPv6, it may be argued that since the network is
not 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
skipping to change at page 12, line 45 skipping to change at page 12, line 9
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. seems to be that this is a less attractive approach.
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'. For example, a new ICMPv6 message could be router for 'hints'. For example, a new ICMPv6 message could be
defined that queried a site edge router or route server for address defined that queried a site edge router or route server for address
pairs to use for a given destination address. pairs to use for a given destination address.
However, having hosts themselves participate in routing is generally However, having hosts themselves participate in routing is generally
not desirable. At this stage we can simply note that address not desirable. At this stage we can simply note that address
selection might be simplified when some hint based on routing state selection might be simplified when some hint based on routing state
is provided to the end system, but such mechanisms are out of scope is provided to the end system, but such mechanisms are out of scope
for this text. for this text.
skipping to change at page 13, line 37 skipping to change at page 12, line 50
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. Policy Conflicts 7.5. 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. In such cases the distribution mechanism provides the information. In such cases the
network should not distribute policy sets from multiple entities (or network should not distribute policy sets from multiple entities (or
by multiple mechanisms). However, in scenarios where a host is by multiple mechanisms). However, in scenarios where a host is
multi-addressed from multiple providers (e.g. a SOHO network with multi-addressed from multiple providers (e.g. a SOHO network with
differing DSL and cable providers, or a user in a coffee shop differing DSL and cable providers, or a user in a coffee shop
initiating a VPN connection to their home network), multiple RFC 3484 initiating a VPN connection to their home network), multiple RFC 3484
policies may be received and there is likely to be some conflicts in policies may be received and there is likely to be some conflicts in
the received policy information. the received policy information.
There are scenarios where a host may wish to ignore a conveyed 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 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 have its preferences changed by a visited network. In such a case
one might argue that the mobile node should use MIPv6 with whatever one might argue that the mobile node should use MIPv6 with whatever
its home network policies are. its home network policies are.
The question then is whether the policy update mechanism itself needs The question then is whether the policy update mechanism itself needs
to handle such potential conflicts, choosing one or ther other or to handle such potential conflicts, choosing one or ther other or
merging by some set of heuristics, or whether the policy update merging by some set of heuristics, or whether the policy update
mechansism should be viewed independently of the conflict handling. mechansism should be viewed independently of the conflict handling.
The view of the design team was that distributing policy is a network The view of the design team was that distributing policy is a network
problem, while handling conflicts is a host problem. 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 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 perhaps to e.g. the priority of the interface it is received on, or perhaps to
convey a unique identifier for the policy provider. Alternatibely, convey a unique identifier for the policy provider. Alternatibely,
if there are multiple policies in conflict, a host could simply if there are multiple policies in conflict, a host could simply
choose to fall back to use the default RFC 3484 policy. 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
implication is that defaults can be changed, and the text gives implication is that defaults can be changed, and the text gives
examples of this in Section 10. However, issues with RFC 3484 are examples of this in Section 10. However, issues with RFC 3484 are
broader that just policy table updates - it remains the case that broader that just policy table updates - it remains the case that
some operational issues with RFC 3484 are not just related to the some operational issues with RFC 3484 are not just related to the
table, but on rules themselves, e.g. longest prefix match (affecting table, but on rules themselves, e.g. longest prefix match (affecting
DNS round robin as described in [RFC5220]). DNS round robin as described in [RFC5220]).
While discussing default policy, we noted that the word 'default' has While discussing default policy, we noted that the word 'default' has
to be carefully defined, and also what the scope of this 'default' to be carefully defined, and also what the scope of this 'default'
is. The default policy should be whatever RFC 3484, or its -bis is. The default policy should be whatever RFC 3484, or its -bis
version, states. At present some operating systems have already version, states. At present some operating systems have already
modified their default, based on operational feedback (e.g. on ULAs, modified their default, based on operational feedback (e.g. on ULAs,
on Teredo prefixes, or on the DNS round-robin problem). Currently we on Teredo prefixes, or on the DNS round-robin problem). Currently we
assume RFC3484 and changes to it will remain node-specific. assume RFC3484 and changes to it will remain node-specific.
It certainly seems the case that the issues raised in RFC 5220, and It certainly seems the case that the issues raised in RFC 5220, and
discussed in [I-D.ietf-6man-rfc3484-revise] mean that an update of problems about RFC 3484 revision mean that an update of RFC 3484 is
RFC 3484 is required, if only because some of the issues (as required, if only because some of the issues (as highlighted earlier)
highlighted earlier) cannot be addressed by updating the policy table cannot be addressed by updating the policy table alone. An update
alone. An update would also give us some hope that all operating would also give us some hope that all operating systems might have a
systems might have a common 'default'. common 'default'.
We do not note any specific comments here on how RFC 3484 should be We do not note any specific comments here on how RFC 3484 should be
updated. Other drafts have made suggestions. There are some updated. Other drafts have made suggestions. There are some
discussions on ideas however, e.g. on the semantics of labels, and in discussions on ideas however, e.g. on the semantics of labels, and
adding ULAs explicitly to the default policy table. in adding ULAs explicitly to the default policy table.
There have also been new issues identified, e.g. on how one There have also been new issues identified, e.g. on how one
differentiates between IPv4+NAT access or IPv6 transitional access differentiates between IPv4+NAT access or IPv6 transitional access
(e.g. via Teredo) to a dual-stack destination (the IPv4 private (e.g. via Teredo) to a dual-stack destination (the IPv4 private
address inside the NAT is implicitly global, although its explicit address inside the NAT is implicitly global, although its explicit
scope is local) [I-D.denis-v6ops-nat-addrsel]. This illustrates that scope is local) [I-D.denis-v6ops-nat-addrsel]. This illustrates that
new issues may continue to be identified through growing IPv6 new issues may continue to be identified through growing IPv6
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.
skipping to change at page 15, line 50 skipping to change at page 15, line 15
solution to allow an enterprise network manager to configure their solution to allow an enterprise network manager to configure their
hosts with address selection policies that may differ from the RFC hosts with address selection policies that may differ from the RFC
3484 default, across all or part of their network, and possibly 3484 default, across all or part of their network, and possibly
changing polciy with time. The general scope of this text applies to changing polciy with time. The general scope of this text applies to
site and enterprise networks, where an administrator may need to site and enterprise networks, where an administrator may need to
change policies over time. It also includes nomadic nodes within the 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. different policies are required.
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. Within this text, we do not present a solution for policy task. Within this text, we do not present a solution for policy
conflict handling, because at this time there is no perfect or conflict handling, because at this time there is no perfect or
practical solution. We thus recommend that we should progress the practical solution. We thus recommend that we should progress the
policy distribution solution while analysing conflict handling (which policy distribution solution while analysing conflict handling (which
is not unique to this domain) in a separate text. is not unique to this domain) in a separate text.
The scope of this text includes issues affecting the design of a The scope of this text includes issues affecting the design of a
skipping to change at page 17, line 14 skipping to change at page 16, line 29
and John Zhao. and John Zhao.
We also acknowledge comments received from IETF WG mail lists, We also acknowledge comments received from IETF WG mail lists,
including those by Brian Carpenter and Dave Thaler. including those by Brian Carpenter and Dave Thaler.
13. Informative References 13. Informative References
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol
(DHCP) Service for IPv6", RFC 3736, April 2004. (DHCP) Service for IPv6", RFC 3736, April 2004.
[RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh
Time Option for Dynamic Host Configuration Protocol for Time Option for Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 4242, November 2005. IPv6 (DHCPv6)", RFC 4242, November 2005.
skipping to change at page 17, line 37 skipping to change at page 17, line 8
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.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering [RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
Still Needs Work", RFC 5887, May 2010. Still Needs Work", RFC 5887, May 2010.
[I-D.ietf-6man-addr-select-sol] [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Matsumoto, A., Fujisaki, T., and R. Hiromi, "Solution Provisioning Domains Problem Statement", RFC 6418,
approaches for address-selection problems", November 2011.
draft-ietf-6man-addr-select-sol-03 (work in progress),
March 2010.
[I-D.ietf-6man-rfc3484-revise] [RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved
Matsumoto, A., Kato, J., Fujisaki, T., and T. Chown, Recursive DNS Server Selection for Multi-Interfaced
"Update to RFC 3484 Default Address Selection for IPv6", Nodes", RFC 6731, December 2012.
draft-ietf-6man-rfc3484-revise-04 (work in progress),
July 2011.
[I-D.ietf-6man-addr-select-opt] [I-D.ietf-6man-addr-select-opt]
Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown, Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing
"Distributing Address Selection Policy using DHCPv6", Address Selection Policy using DHCPv6", draft-ietf-6man-
draft-ietf-6man-addr-select-opt-01 (work in progress), addr-select-opt-08 (work in progress), January 2013.
June 2011.
[I-D.ietf-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement",
draft-ietf-mif-problem-statement-15 (work in progress),
May 2011.
[I-D.ietf-mif-dhcpv6-route-option] [I-D.ietf-mif-dhcpv6-route-option]
Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6 Dec, W., Mrugalski, T., Sun, T., Sarikaya, B., and A.
Route Options", draft-ietf-mif-dhcpv6-route-option-03 Matsumoto, "DHCPv6 Route Options", draft-ietf-mif-dhcpv6
(work in progress), September 2011. -route-option-05 (work in progress), August 2012.
[I-D.ietf-mif-dns-server-selection]
Savolainen, T., Kato, J., and T. Lemon, "Improved DNS
Server Selection for Multi-Interfaced Nodes",
draft-ietf-mif-dns-server-selection-07 (work in progress),
October 2011.
[I-D.arifumi-6man-addr-select-conflict]
Matsumoto, A., Fujisaki, T., and R. Hiromi,
"Considerations of address selection policy conflicts",
draft-arifumi-6man-addr-select-conflict-02 (work in
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.ietf-v6ops-multihoming-without-nat66] [I-D.ietf-v6ops-multihoming-without-nat66]
Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D.
Wing, "IPv6 Multihoming without Network Address Wing, "IPv6 Multihoming without Network Address
Translation", Translation", draft-ietf-v6ops-multihoming-without-
draft-ietf-v6ops-multihoming-without-nat66-00 (work in nat66-00 (work in progress), December 2010.
progress), December 2010.
Authors' Addresses Authors' Addresses
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
Arifumi Matsumoto (editor) Arifumi Matsumoto (editor)
NTT SI Lab NTT NT Lab
Midori-Cho 3-9-11 Midori-Cho 3-9-11
Musashino-shi, Tokyo 180-8585 Musashino-shi, Tokyo 180-8585
Japan Japan
Phone: +81 422 59 3334 Phone: +81 422 59 3334
Email: arifumi@nttv6.net Email: matsumoto.arifumi@lab.ntt.co.jp
 End of changes. 45 change blocks. 
143 lines changed or deleted 128 lines changed or added

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