draft-ietf-6man-addr-select-considerations-03.txt   draft-ietf-6man-addr-select-considerations-04.txt 
IPv6 Maintenance T. Chown, Ed. IPv6 Maintenance T. Chown, Ed.
Internet-Draft University of Southampton Internet-Draft University of Southampton
Intended status: Informational March 14, 2011 Intended status: Informational A. Matsumoto, Ed.
Expires: September 15, 2011 Expires: May 3, 2012 NTT
October 31, 2011
Considerations for IPv6 Address Selection Policy Changes Considerations for IPv6 Address Selection Policy Changes
draft-ietf-6man-addr-select-considerations-03 draft-ietf-6man-addr-select-considerations-04
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 46
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 September 15, 2011. This Internet-Draft will expire on May 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
skipping to change at page 3, line 33 skipping to change at page 3, line 33
7.3. Push model . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. Push model . . . . . . . . . . . . . . . . . . . . . . . . 12
7.4. Routing Hints . . . . . . . . . . . . . . . . . . . . . . 12 7.4. Routing Hints . . . . . . . . . . . . . . . . . . . . . . 12
7.5. Policy Conflicts . . . . . . . . . . . . . . . . . . . . . 13 7.5. Policy Conflicts . . . . . . . . . . . . . . . . . . . . . 13
7.6. Policy Merging . . . . . . . . . . . . . . . . . . . . . . 14 7.6. Policy Merging . . . . . . . . . . . . . . . . . . . . . . 14
8. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . 14 8. On RFC3484 Default Policies . . . . . . . . . . . . . . . . . 14
9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
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 different default policy to that described in RFC 3484 is or different default policy to that described in RFC 3484 is
skipping to change at page 5, line 19 skipping to change at page 5, line 19
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 There is already a good analysis of issues with RFC 3484 and how the
text could be revised [I-D.ietf-6man-rfc3484-revise]). 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.fujisaki-6man-addr-select-opt], but these are not discussed [I-D.ietf-6man-addr-select-opt], but these are not discussed here.
here. While RFC 5221 assumes that a dynamic policy update mechanism While RFC 5221 assumes that a dynamic policy update mechanism of some
of some form is available, this draft is primarily aimed at form is available, this draft is primarily aimed at understanding the
understanding the scenarios and triggers for policy changes, to scenarios and triggers for policy changes, to better inform future
better inform future detailed solution discussions. detailed solution discussions.
A draft discussing methods for multihoming without NAT66 A draft discussing methods for multihoming without IPv6 NAT
[I-D.troan-multihoming-without-nat66] has been published recently. [I-D.ietf-v6ops-multihoming-without-nat66] has been published
This draft includes a requirement for a method to distribute address recently. This draft includes a requirement for a method to
selection policy to support IPv6 multihoming. 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
skipping to change at page 9, line 41 skipping to change at page 9, line 41
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 [I-D.ietf-mif-problem-statement], and
on a number of possible DHCPv6 extensions, e.g. to inform hosts about on a number of possible DHCPv6 extensions, e.g. to inform hosts about
routing information to assist the selection process routing information to assist the selection process.
[I-D.dec-dhcpv6-route-option], [I-D.sun-mif-address-policy-dhcp6], [I-D.ietf-mif-dhcpv6-route-option], to inform hosts about DNS server
[I-D.sarikaya-mif-dhcpv6solution]. Another new draft proposes a selection policy, [I-D.ietf-mif-dns-server-selection]. These drafts
DHCPv6 option to convey policy directly to a host fall within the remit of the new IETF mif WG. We note that the mif
[I-D.sun-mif-route-config-dhcp6]. These drafts fall within the remit WG may produce relevant work with respect to the analysis of RFC 3484
of the new IETF mif WG, which at the time of writing was only policy changes, but at this stage no such output exists for
recently formed. We note that the mif WG may produce relevant work inclusion.
with respect to the analysis of RFC 3484 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
skipping to change at page 12, line 18 skipping to change at page 12, line 18
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.sun-mif-route-config-dhcp6], hosts, e.g. [I-D.ietf-mif-dhcpv6-route-option] and
[I-D.dec-dhcpv6-route-option], [I-D.sun-mif-address-policy-dhcp6] and [I-D.ietf-mif-dns-server-selection]. 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. 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
skipping to change at page 17, line 45 skipping to change at page 17, line 44
[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] [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.ietf-6man-rfc3484-revise] [I-D.ietf-6man-rfc3484-revise]
Matsumoto, A., Kato, J., and T. Fujisaki, "Update to RFC Matsumoto, A., Kato, J., Fujisaki, T., and T. Chown,
3484 Default Address Selection for IPv6", "Update to RFC 3484 Default Address Selection for IPv6",
draft-ietf-6man-rfc3484-revise-02 (work in progress), draft-ietf-6man-rfc3484-revise-04 (work in progress),
March 2011. July 2011.
[I-D.fujisaki-6man-addr-select-opt] [I-D.ietf-6man-addr-select-opt]
Fujisaki, T., Matsumoto, A., and R. Hiromi, "Distributing Matsumoto, A., Fujisaki, T., Kato, J., and T. Chown,
Address Selection Policy using DHCPv6", "Distributing Address Selection Policy using DHCPv6",
draft-fujisaki-6man-addr-select-opt-00 (work in progress), draft-ietf-6man-addr-select-opt-01 (work in progress),
July 2010. June 2011.
[I-D.ietf-mif-problem-statement] [I-D.ietf-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces and Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", Provisioning Domains Problem Statement",
draft-ietf-mif-problem-statement-10 (work in progress), draft-ietf-mif-problem-statement-15 (work in progress),
March 2011. May 2011.
[I-D.dec-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., and B. Sarikaya, "DHCPv6
Route Option", draft-dec-dhcpv6-route-option-05 (work in Route Options", draft-ietf-mif-dhcpv6-route-option-03
progress), September 2010. (work in progress), September 2011.
[I-D.sun-mif-address-policy-dhcp6]
Sun, T., Deng, H., and X. Duan, "Address Selection Policy
Configuration by DHCPv6 Option",
draft-sun-mif-address-policy-dhcp6-01 (work in progress),
March 2009.
[I-D.sarikaya-mif-dhcpv6solution]
Sarikaya, B., Xia, F., and P. Seite, "DHCPv6 Extension for
Configuring Hosts with Multiple Interfaces",
draft-sarikaya-mif-dhcpv6solution-04 (work in progress),
July 2010.
[I-D.sun-mif-route-config-dhcp6] [I-D.ietf-mif-dns-server-selection]
Sun, T., Deng, H., and D. Liu, "Route Configuration by Savolainen, T., Kato, J., and T. Lemon, "Improved DNS
DHCPv6 Option for Hosts with Multiple Interfaces", Server Selection for Multi-Interfaced Nodes",
draft-sun-mif-route-config-dhcp6-03 (work in progress), draft-ietf-mif-dns-server-selection-07 (work in progress),
July 2010. October 2011.
[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
(work in progress), February 2009. (work in progress), February 2009.
[I-D.troan-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", draft-troan-multihoming-without-nat66-01 Translation",
(work in progress), July 2010. draft-ietf-v6ops-multihoming-without-nat66-00 (work in
progress), December 2010.
Author's Address 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)
NTT SI Lab
Midori-Cho 3-9-11
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 3334
Email: arifumi@nttv6.net
 End of changes. 19 change blocks. 
62 lines changed or deleted 48 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/