draft-ietf-6man-addr-select-considerations-02.txt   draft-ietf-6man-addr-select-considerations-03.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 12, 2010 Intended status: Informational March 14, 2011
Expires: January 13, 2011 Expires: September 15, 2011
Considerations for IPv6 Address Selection Policy Changes Considerations for IPv6 Address Selection Policy Changes
draft-ietf-6man-addr-select-considerations-02 draft-ietf-6man-addr-select-considerations-03
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 13, 2011. This Internet-Draft will expire on September 15, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 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
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 5, line 12 skipping to change at page 5, line 12
us, e.g. hints from local routing tables. This is covered in Section us, e.g. hints from local routing tables. This is covered in Section
7. 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 There is already a good analysis of issues with RFC 3484 and how the
text could be revised [I-D.arifumi-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-dhc-addr-select-opt], but these are not discussed here. [I-D.fujisaki-6man-addr-select-opt], but these are not discussed
While RFC 5221 assumes that a dynamic policy update mechanism of some here. While RFC 5221 assumes that a dynamic policy update mechanism
form is available, this draft is primarily aimed at understanding the of some form is available, this draft is primarily aimed at
scenarios and triggers for policy changes, to better inform future understanding the scenarios and triggers for policy changes, to
detailed solution discussions. better inform future detailed solution discussions.
A draft discussing methods for multihoming without NAT66 A draft discussing methods for multihoming without NAT66
[I-D.troan-multihoming-without-nat66] has been published recently. [I-D.troan-multihoming-without-nat66] has been published recently.
This draft includes a requirement for a method to distribute address This draft includes a requirement for a method to distribute address
selection policy to support IPv6 multihoming. 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
skipping to change at page 9, line 39 skipping to change at page 9, line 39
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.blanchet-mif-problem-statement], the multiple interface problem [I-D.ietf-mif-problem-statement], and
and on a number of possible DHCPv6 extensions, e.g. to inform hosts on a number of possible DHCPv6 extensions, e.g. to inform hosts about
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.dec-dhcpv6-route-option], [I-D.sun-mif-address-policy-dhcp6],
[I-D.sarikaya-mif-dhcpv6solution]. Another new draft proposes a [I-D.sarikaya-mif-dhcpv6solution]. Another new draft proposes a
DHCPv6 option to convey policy directly to a host DHCPv6 option to convey policy directly to a host
[I-D.sun-mif-route-config-dhcp6]. These drafts fall within the remit [I-D.sun-mif-route-config-dhcp6]. These drafts fall within the remit
of the new IETF mif WG, which at the time of writing was only of the new IETF mif WG, which at the time of writing was only
recently formed. We note that the mif WG may produce relevant work recently formed. We note that the mif WG may produce relevant work
with respect to the analysis of RFC 3484 policy changes, but at this with respect to the analysis of RFC 3484 policy changes, but at this
stage no such output exists for inclusion. stage no such output exists for inclusion.
5. How Dynamic? 5. How Dynamic?
skipping to change at page 13, line 8 skipping to change at page 13, line 8
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.
It is noted in [I-D.carpenter-renum-needs-work] that: It is noted in [RFC5887] 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
currently valid. This application seems possible within the IPv6 currently valid. This application seems possible within the IPv6
Neighbour Discovery architecture, but does not appear to be clearly Neighbour Discovery architecture, but does not appear to be clearly
skipping to change at page 15, line 14 skipping to change at page 15, line 14
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.arifumi-6man-rfc3484-revise] mean that an update of discussed in [I-D.ietf-6man-rfc3484-revise] mean that an update of
RFC 3484 is required, if only because some of the issues (as RFC 3484 is required, if only because some of the issues (as
highlighted earlier) cannot be addressed by updating the policy table highlighted earlier) cannot be addressed by updating the policy table
alone. An update would also give us some hope that all operating alone. An update would also give us some hope that all operating
systems might have a common 'default'. systems might have a 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 in
adding ULAs explicitly to the default policy table. adding ULAs explicitly to the default policy table.
skipping to change at page 17, line 35 skipping to change at page 17, line 35
[RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Problem Statement for Default Address Selection in Multi- "Problem Statement for Default Address Selection in Multi-
Prefix Environments: Operational Issues of RFC 3484 Prefix Environments: Operational Issues of RFC 3484
Default Rules", RFC 5220, July 2008. Default Rules", RFC 5220, July 2008.
[RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Requirements for Address Selection Mechanisms", RFC 5221, "Requirements for Address Selection Mechanisms", RFC 5221,
July 2008. July 2008.
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
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.arifumi-6man-rfc3484-revise] [I-D.ietf-6man-rfc3484-revise]
Matsumoto, A., Fujisaki, T., and R. Hiromi, "Things To Be Matsumoto, A., Kato, J., and T. Fujisaki, "Update to RFC
Considered for RFC 3484 Revision", 3484 Default Address Selection for IPv6",
draft-arifumi-6man-rfc3484-revise-03 (work in progress), draft-ietf-6man-rfc3484-revise-02 (work in progress),
July 2010. March 2011.
[I-D.fujisaki-dhc-addr-select-opt] [I-D.fujisaki-6man-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-6man-addr-select-opt-00 (work in progress),
March 2010. July 2010.
[I-D.blanchet-mif-problem-statement] [I-D.ietf-mif-problem-statement]
Blanchet, M. and P. Seite, "Multiple Interfaces Problem Blanchet, M. and P. Seite, "Multiple Interfaces and
Statement", draft-blanchet-mif-problem-statement-01 (work Provisioning Domains Problem Statement",
in progress), June 2009. draft-ietf-mif-problem-statement-10 (work in progress),
March 2011.
[I-D.dec-dhcpv6-route-option] [I-D.dec-dhcpv6-route-option]
Dec, W., Johnson, R., Mrugalski, T., and A. Matsumoto, Dec, W., Mrugalski, T., Sun, T., and B. Sarikaya, "DHCPv6
"DHCPv6 Route Options", draft-dec-dhcpv6-route-option-04 Route Option", draft-dec-dhcpv6-route-option-05 (work in
(work in progress), July 2010. progress), September 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., Deng, H., and D. Liu, "Route Configuration by Sun, T., Deng, H., and D. Liu, "Route Configuration by
DHCPv6 Option for Hosts with Multiple Interfaces", DHCPv6 Option for Hosts with Multiple Interfaces",
draft-sun-mif-route-config-dhcp6-02 (work in progress), draft-sun-mif-route-config-dhcp6-03 (work in progress),
July 2010. 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
(work in progress), February 2009. (work in progress), February 2009.
[I-D.carpenter-renum-needs-work]
Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering
still needs work", draft-carpenter-renum-needs-work-05
(work in progress), January 2010.
[I-D.troan-multihoming-without-nat66] [I-D.troan-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-00 Translation", draft-troan-multihoming-without-nat66-01
(work in progress), May 2010. (work in progress), July 2010.
Author's Address Author's Address
Tim Chown (editor) Tim Chown (editor)
University of Southampton University of Southampton
Southampton, Hampshire SO17 1BJ Southampton, Hampshire SO17 1BJ
United Kingdom United Kingdom
Email: tjc@ecs.soton.ac.uk Email: tjc@ecs.soton.ac.uk
 End of changes. 19 change blocks. 
40 lines changed or deleted 38 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/