draft-ietf-6man-addr-select-sol-01.txt   draft-ietf-6man-addr-select-sol-02.txt 
IPv6 Maintenance Working Group A. Matsumoto IPv6 Maintenance Working Group A. Matsumoto
Internet-Draft T. Fujisaki Internet-Draft T. Fujisaki
Intended status: Informational NTT Intended status: Informational NTT
Expires: August 2, 2008 R. Hiromi Expires: January 3, 2010 R. Hiromi
K. Kanayama
Intec Netcore Intec Netcore
June 18, 2008 K. Kanayama
INTEC Systems
July 2, 2009
Solution approaches for address-selection problems Solution approaches for address-selection problems
draft-ietf-6man-addr-select-sol-01.txt draft-ietf-6man-addr-select-sol-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 2, 2008. This Internet-Draft will expire on January 3, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
Copyright (C) The IETF Trust (2008). This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
In response to address selection problem statement and requirement In response to address selection problem statement and requirement
documents, this document describes approaches to solutions and documents, this document describes approaches to solutions and
evaluates proposed solution mechanisms in line with requirements. It evaluates proposed solution mechanisms in line with requirements. It
also examines the applicability of each solution mechanism from the also examines the applicability of each solution mechanism from the
viewpoint of practical application. viewpoint of practical application.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Solution Design . . . . . . . . . . . . . . . . . . . . . . . 3 2. Solution Design . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Proactive approaches . . . . . . . . . . . . . . . . . . . 3 2.1. Proactive approaches . . . . . . . . . . . . . . . . . . . 4
2.2. Reactive approaches . . . . . . . . . . . . . . . . . . . 4 2.2. Reactive approaches . . . . . . . . . . . . . . . . . . . 5
3. Solution approaches . . . . . . . . . . . . . . . . . . . . . 4 3. Solution approaches . . . . . . . . . . . . . . . . . . . . . 5
3.1. Obtain all information prior to communication (Most 3.1. Obtain all information prior to communication (Most
Proactive) . . . . . . . . . . . . . . . . . . . . . . . . 4 Proactive) . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 4 3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Requirements correspondence analysis . . . . . . . . . 5 3.1.2. Requirements correspondence analysis . . . . . . . . . 6
3.1.3. Other issues . . . . . . . . . . . . . . . . . . . . . 6 3.1.3. Other issues . . . . . . . . . . . . . . . . . . . . . 7
3.2. Routing system assistance for address selection 3.2. Routing system assistance for address selection
(Proactive) . . . . . . . . . . . . . . . . . . . . . . . 6 (Proactive) . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 7
3.2.2. Requirements correspondence analysis . . . . . . . . . 6 3.2.2. Requirements correspondence analysis . . . . . . . . . 8
3.2.3. Other issues . . . . . . . . . . . . . . . . . . . . . 7 3.2.3. Other issues . . . . . . . . . . . . . . . . . . . . . 9
3.3. Trial-and-error approach (Reactive) . . . . . . . . . . . 7 3.3. Trial-and-error approach (Reactive) . . . . . . . . . . . 10
3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2. Requirement correspondence analysis . . . . . . . . . 8 3.3.2. Requirement correspondence analysis . . . . . . . . . 10
3.3.3. Other issues . . . . . . . . . . . . . . . . . . . . . 9 3.3.3. Other issues . . . . . . . . . . . . . . . . . . . . . 12
3.4. All-by-oneself approach (Most Reactive) . . . . . . . . . 9 3.4. All-by-oneself approach (Most Reactive) . . . . . . . . . 12
3.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 9 3.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 12
3.4.2. Requirement correspondence analysis . . . . . . . . . 9 3.4.2. Requirement correspondence analysis . . . . . . . . . 13
3.4.3. Other issues . . . . . . . . . . . . . . . . . . . . . 10 3.4.3. Other issues . . . . . . . . . . . . . . . . . . . . . 14
4. Applicability Comparison . . . . . . . . . . . . . . . . . . . 11 4. Applicability Comparison . . . . . . . . . . . . . . . . . . . 14
4.1. Dynamic-static and managed-unmanaged . . . . . . . . . . . 11 4.1. Dynamic-static and managed-unmanaged . . . . . . . . . . . 15
4.2. Deployment Difficulty . . . . . . . . . . . . . . . . . . 12 4.2. Deployment Difficulty . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. Appendix. Revision History . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
One physical network can have multiple logical networks. In that One physical network can have multiple logical networks. In that
case, an end-host has multiple IP addresses. (e.g, in the IPv4-IPv6 case, an end-host has multiple IP addresses. (e.g, in the IPv4-IPv6
dual-stack environment, in a site that uses both ULA [RFC4193] and dual-stack environment, in a site that uses both ULA [RFC4193] and
global scope addresses or in a site connected to multiple upstream global scope addresses or in a site connected to multiple upstream
IPv6 networks.) For such a host, RFC 3484 [RFC3484] defines default IPv6 networks.) For such a host, RFC 3484 [RFC3484] defines default
address-selection rules for the source and destination addresses. address-selection rules for the source and destination addresses.
Today, the RFC 3484 mechanism is widely implemented in major OSs. Today, the RFC 3484 mechanism is widely implemented in major OSs.
However, many people, including us, have found that in many sites the However, many people, including us, have found that in many sites the
default address-selection rules are not appropriate for the network default address-selection rules are not appropriate for the network
structure. PS [I-D.ietf-v6ops-addr-select-ps] lists problematic structure. RFC 5220 [RFC5220] lists problematic cases that resulted
cases that resulted from incorrect address selection. from incorrect address selection.
Though RFC 3484 made the address-selection behavior of a host Though RFC 3484 made the address-selection behavior of a host
configurable, typical users cannot make use of that because of the configurable, typical users cannot make use of that because of the
complexity of the mechanism and their lack of knowledge about their complexity of the mechanism and their lack of knowledge about their
network topologies. Therefore, an address-selection network topologies. Therefore, an address-selection
autoconfiguration mechanism is necessary, especially for the autoconfiguration mechanism is necessary, especially for the
unmanaged hosts of typical users. unmanaged hosts of typical users.
REQ [I-D.ietf-v6ops-addr-select-req] document enumerates requirements RFC 5221 [RFC5221] document enumerates requirements for address-
for address-selection mechanisms that enable hosts to perform selection mechanisms that enable hosts to perform appropriate address
appropriate address selection automatically. selection automatically.
In the IETF mailing lists and in the internet-draft archives, some In the IETF mailing lists and in the internet-draft archives, some
mechanisms for solving address-selection problems have already been mechanisms for solving address-selection problems have already been
proposed. This document describes possible design approaches for proposed. This document describes possible design approaches for
solving address selection problems. After that, we try to put solving address selection problems. After that, we try to put
together an overview as well as an analysis of how well the method together an overview as well as an analysis of how well the method
corresponds with the requirements. corresponds with the requirements.
2. Solution Design 2. Solution Design
skipping to change at page 5, line 5 skipping to change at page 6, line 5
information from a server beforehand. It then sets up communication information from a server beforehand. It then sets up communication
whenever it wants to. DHCPv6 and RA fall into this category as known whenever it wants to. DHCPv6 and RA fall into this category as known
protocols. There is a reference document protocols. There is a reference document
[I-D.fujisaki-dhc-addr-select-opt] in which DHCPv6 is used for this [I-D.fujisaki-dhc-addr-select-opt] in which DHCPv6 is used for this
purpose. purpose.
This approach can take advantage of the RFC 3484 Policy Table, which This approach can take advantage of the RFC 3484 Policy Table, which
is already widely deployed. By distributing policies for the Policy is already widely deployed. By distributing policies for the Policy
Table, you can auto-configure a host's address selection policy. Table, you can auto-configure a host's address selection policy.
Other than policy table based approach, Aleksi Suhonen proposed his
idea where a host has a separate routing table for each attached
address. He has not submitted any internet draft, but he posted it
to the mailing list and referred to it as draft-axu-addr-sel-pre00.
The documented idea was still incompleted, but basically it should
have characteristics in common with above mentioned policy table
based mechanism except the implementation characteristic.
3.1.2. Requirements correspondence analysis 3.1.2. Requirements correspondence analysis
1. Effectiveness: 3 1. Effectiveness: 3
It can support all cases by using the policy table. It can support all cases by using the policy table.
2. Timing: 3 2. Timing: 3
All information for communication is in a host in advance. All information for communication is in a host in advance.
Communication starts at once when it is necessary and the Communication starts at once when it is necessary and the
communication process refers to local policy information, so it communication process refers to local policy information, so it
exhibits good usability. Moreover, this leads to fewer overheads exhibits good usability. Moreover, this leads to fewer overheads
than per-connection mechanisms. than per-connection mechanisms.
3. Dynamic update: 3 3. Dynamic update: 3
Though it depends on what protocol is used to distribute the Though it depends on what protocol is used to distribute the
policies, some mechanisms support information updates from the policies, some mechanisms support information updates from the
server. Moreover, it is difficult to support dynamic network server. Moreover, it is difficult to support dynamic network
changes and real-time updates in some specific protocols. changes and real-time updates in some specific protocols.
4. Node-specific behavior: 3 4. Node-specific behavior: 3
For distribution to individual hosts in the same segment, DHCPv6 For distribution to individual hosts in the same segment, DHCPv6
can be used. can be used.
5. Application-specific behavior: 2 5. Application-specific behavior: 2
The policy table itself doesn't support application-specific The policy table itself doesn't support application-specific
address selection. It can be done using the address selection address selection. It can be done using the address selection
API. [RFC5014] API. [RFC5014]
6. Multiple interfaces: 2 6. Multiple interfaces: 2
If all interfaces belong to the same administration domain, it is If all interfaces belong to the same administration domain, it is
possible for the address-selection information to be controlled by possible for the address-selection information to be controlled by
administrators of that domain. However, if not, routing administrators of that domain. However, if not, routing
information and address selection policies are not always information and address selection policies are not always
equivalent between domains, and it is not possible to handle them. equivalent between domains, and it is not possible to handle them.
7. Central control: 3 7. Central control: 3
It can support central control. A site administrator or a service It can support central control. A site administrator or a service
provider can determine users' policy tables. provider can determine users' policy tables.
8. Route selection: 2 8. Route selection: 2
Current solutions, such as DHCPv6 and RA, do not have a mechanism Current solutions, such as DHCPv6 and RA, do not have a mechanism
for cooperation with routing protocols. This could be done with for cooperation with routing protocols. This could be done with
other techniques such as "source address based routing" or other techniques such as "source address based routing" or
"Default Router Preferences and More-Specific Routes" RFC4191. "Default Router Preferences and More-Specific Routes" RFC4191.
[RFC4191] [RFC4191]
9. Compatibility with RFC 3493: 3 9. Compatibility with RFC 3493: 3
This approach is able to coexist with any kind of applications This approach is able to coexist with any kind of applications
(socket API). In detail, any types of function such as (socket API). In detail, any types of function such as
getaddrinfo(), getsockname(), connect() or other typical system getaddrinfo(), getsockname(), connect() or other typical system
calls will work without alterations if this mechanism is applied calls will work without alterations if this mechanism is applied
to a host. to a host.
10. Compatibility and Interoperability with RFC 3484: 3 10. Compatibility and Interoperability with RFC 3484: 3
The basic idea of this approach has a compatibility with RFC3484. The basic idea of this approach has a compatibility with RFC3484.
This approach make RFC3484 policy table configurable to put some This approach make RFC3484 policy table configurable to put some
hints related with it's individual network case. hints related with it's individual network case.
11. Security: 2 11. Security: 2
This approach has a weakness on hijacking.
A combination of Layer 2 securing techniques and this mechanism This approach has a weakness on hijacking. A combination of Layer
will be able to be effective against security concerns. 2 securing techniques and this mechanism will be able to be
DHCP and RA protocol have own security measures and they also effective against security concerns. DHCP and RA protocol have
protect from them. own security measures and they also protect from them.
3.1.3. Other issues 3.1.3. Other issues
- The traffic volume will be equal to the number of policies. - The traffic volume will be equal to the number of policies.
- Hosts and servers need to support this function. - Hosts and servers need to support this function.
3.2. Routing system assistance for address selection (Proactive) 3.2. Routing system assistance for address selection (Proactive)
3.2.1. Overview 3.2.1. Overview
Fred Baker proposed this approach. A host asks the DMZ routers or Fred Baker proposed this approach. A host asks the DMZ routers or
the local router which is the best pair of source and destination the local router which is the best pair of source and destination
skipping to change at page 7, line 38 skipping to change at page 9, line 11
way. way.
6. Multiple Interfaces: 2 6. Multiple Interfaces: 2
If all interfaces belong to the same administration domain, it is If all interfaces belong to the same administration domain, it is
possible for the address-selection information to be controlled by possible for the address-selection information to be controlled by
administrators of that domain. However, if not, routing administrators of that domain. However, if not, routing
information and address selection policies are not always information and address selection policies are not always
equivalent between domains, and it is not possible to handle them. equivalent between domains, and it is not possible to handle them.
7. Central Control: 3 7. Central Control: 3
It is possible to provide address selection information from one It is possible to provide address selection information from one
source. However, because routing information changes dynamically, source. However, because routing information changes dynamically,
it is difficult to control it in the way that administrators want. it is difficult to control it in the way that administrators want.
8. Route Selection: 3 8. Route Selection: 3
It is possible to give next-hop selection advice to a host. As It is possible to give next-hop selection advice to a host. As
routers have routing information, it would seem to be easier for routers have routing information, it would seem to be easier for
routers to implement this function. routers to implement this function.
9. Compatibility with RFC 3493: 3 9. Compatibility with RFC 3493: 3
This approach is able to coexist with any kind of applications This approach is able to coexist with any kind of applications
(socket API). In detail, any types of function such as (socket API). In detail, any types of function such as
getaddrinfo(), getsockname(), connect() or other typical system getaddrinfo(), getsockname(), connect() or other typical system
calls will work without alterations if this mechanism is applied calls will work without alterations if this mechanism is applied
to a host. to a host. In the existing TCP/IP protocol stack implementation,
In the existing TCP/IP protocol stack implementation, destination destination address selection is mainly the role of the
address selection is mainly the role of the application and not application and not that of the kernel unlike source address
that of the kernel unlike source address selection. Therefore, selection. Therefore, implementing this model without affecting
implementing this model without affecting applications is not so applications is not so easy.
easy.
10. Compatibility and Interoperability with RFC 3484: 2 10. Compatibility and Interoperability with RFC 3484: 2
Currently it just proposed and there is no implementation. Currently it just proposed and there is no implementation.
Therefore, it depends on how to implement with this requirement Therefore, it depends on how to implement with this requirement
and it can be coexistence with RFC3484. and it can be coexistence with RFC3484.
11. Security: 2 11. Security: 2
This approach has a weakness on hijacking.
Currently it just proposed and there is no implementation. This approach has a weakness on hijacking. Currently it just
Therefore, it depends on how to define security protection proposed and there is no implementation. Therefore, it depends on
mechanism and how to implement it. how to define security protection mechanism and how to implement
it.
3.2.3. Other issues 3.2.3. Other issues
- A host must consult the routing system every time it starts a - A host must consult the routing system every time it starts a
connection if the host does not have address selection information connection if the host does not have address selection information
for the destination host or if the information lifetime has for the destination host or if the information lifetime has
expired. This could be a possible scalability problem. expired. This could be a possible scalability problem.
- The existing host/router OS implementation must be changed a lot. - The existing host/router OS implementation must be changed a lot.
In the existing TCP/IP protocol stack implementation, destination
address selection is mainly the role of the application and not
that of the kernel unlike source address selection. Therefore,
implementing this model without affecting applications is not so
easy.
3.3. Trial-and-error approach (Reactive) 3.3. Trial-and-error approach (Reactive)
3.3.1. Overview 3.3.1. Overview
M. Bagnulo proposed a new address selection method in his draft. M. Bagnulo presented a new address selection idea in his draft.
When the host notices that a network failure has occurred or packets Hirotaka Matsuoka extended and elaborated this approach in his draft.
have been dropped somewhere in the network by, for example, an [I-D.matsuoka-multihoming-try-and-error] When the host notices that a
ingress filter, the host changes the source address of the connection network failure has occurred or packets have been dropped somewhere
to another source address. in the network by, for example, an ingress filter, the host changes
the source address of the connection to another source address.
Hosts may use some kinds of error messages, e.g, ICMP error messages, Hosts may use some kinds of error messages, e.g, ICMP error messages,
from a network to detect that sent packets did not reach the from a network to detect that sent packets did not reach the
destination quickly. destination quickly.
The host stores a cache of address selection information so that the The host stores a cache of address selection information so that the
host can select an appropriate source address for new connections. host can select an appropriate source address for new connections.
For source address selection by the application that initiated a For source address selection by the application that initiated a
communication, this method provides an ordered list of source communication, this method provides an ordered list of source
skipping to change at page 8, line 48 skipping to change at page 10, line 41
The host stores a cache of address selection information so that the The host stores a cache of address selection information so that the
host can select an appropriate source address for new connections. host can select an appropriate source address for new connections.
For source address selection by the application that initiated a For source address selection by the application that initiated a
communication, this method provides an ordered list of source communication, this method provides an ordered list of source
addresses for the destination address to the application. addresses for the destination address to the application.
3.3.2. Requirement correspondence analysis 3.3.2. Requirement correspondence analysis
1. Effectiveness: 2 1. Effectiveness: 2
This solution is not effective for the problem about IPv4 or IPv6 This solution is not effective for the problem about IPv4 or IPv6
prioritization described in the problem statement document. prioritization described in the problem statement document.
2. Timing: 2 2. Timing: 2
Hosts should try to use all the available source addresses to the Hosts should try to use all the available source addresses to the
maximum to find an appropriate source address. If the host tries maximum to find an appropriate source address. If the host tries
the next source address after the previous trial using another the next source address after the previous trial using another
source address has failed, it may take a long time because this source address has failed, it may take a long time because this
trial-and-error process lasts until the connection succeeds. If trial-and-error process lasts until the connection succeeds. If
the host does not use an error message from a network to detect a the host does not use an error message from a network to detect a
connection error, it takes longer to wait for a time-out. connection error, it takes longer to wait for a time-out.
3. Dynamic update: 3 3. Dynamic update: 3
If hosts detect a connection failure using some reliable If hosts detect a connection failure using some reliable
mechanism, such like TCP or ICMP error messages, a connection mechanism, such like TCP or ICMP error messages, a connection
failure caused by some changes in the network will be detected failure caused by some changes in the network will be detected
immediately by the hosts. immediately by the hosts.
4. Node-specific behavior: 2 4. Node-specific behavior: 2
This solution does not have a function for node-specific behavior. This solution does not have a function for node-specific behavior.
However, it is not impossible to implement by setting a packet However, it is not impossible to implement by setting a packet
filter for each node at the gateways through which the packets filter for each node at the gateways through which the packets
from nodes pass. from nodes pass.
5. Application-specific behavior: 2 5. Application-specific behavior: 2
This solution does not have a function for application-specific This solution does not have a function for application-specific
behavior. However, the mechanism of this approach does not behavior. However, the mechanism of this approach does not
exclude address selection by each application. exclude address selection by each application.
6. Multiple interfaces: 3 6. Multiple interfaces: 3
If the protocol-stack or an application supports interface If the protocol-stack or an application supports interface
selection and it tries to establish a connection by changing selection and it tries to establish a connection by changing
addresses and also interfaces, it can find a working combination addresses and also interfaces, it can find a working combination
of addresses and interface. of addresses and interface.
7. Central control: 2 7. Central control: 2
The only way that a central administrator has to control the node The only way that a central administrator has to control the node
behavior is switching a filter on/off on the network. Therefore, behavior is switching a filter on/off on the network. Therefore,
advanced control such as traffic engineering and QoS is almost advanced control such as traffic engineering and QoS is almost
impossible. impossible.
8. Route Selection: 2 8. Route Selection: 2
This solution does not refer to next-hop selection for the This solution does not refer to next-hop selection for the
transmission of a packet. So, it should be used with some routing transmission of a packet. So, it should be used with some routing
function such as RFC 4191 on the nodes. function such as RFC 4191 on the nodes.
9. Compatibility with RFC 3493: 1 9. Compatibility with RFC 3493: 1
This approach has possibility to interfere with coexistence with This approach has possibility to interfere with coexistence with
applications(socket APIs). The returen value of functions would be applications(socket APIs). The returen value of functions would
changed for its meaning. A case is suspected that the return be changed for its meaning. A case is suspected that the return
value of connect() system call will change its state from "non- value of connect() system call will change its state from "non-
blocking" to "blocking" and this will bring alteration to the blocking" to "blocking" and this will bring alteration to the
application behaviours. Because of this suspicion, this approach application behaviours. Because of this suspicion, this approach
scores 1. scores 1.
10. Compatibility and Interoperability with RFC 3484: 2 10. Compatibility and Interoperability with RFC 3484: 2
It depends on how to implement with this requirement. But there It depends on how to implement with this requirement. But there
will be possible conflict which a result will be overwrite the will be possible conflict which a result will be overwrite the
3484 policy table without any permission of domain administrators. 3484 policy table without any permission of domain administrators.
11. Security: 2 11. Security: 2
This approach has a weakness on hijacking.
Currently it just proposed and there is no implementation. This approach has a weakness on hijacking. Currently it just
Therefore, it depends on how to define security protection proposed and there is no implementation. Therefore, it depends on
mechanism and how to implement it. how to define security protection mechanism and how to implement
it.
3.3.3. Other issues 3.3.3. Other issues
- A host must learn address selection information for each - A host must learn address selection information for each
destination host. Therefore, the number of cache entries could be destination host. Therefore, the number of cache entries could be
very large. very large.
- The existing host/router OS implementation must be changed a lot. - The existing host/router OS implementation must be changed a lot.
In particular, changing the source address of the existing In particular, changing the source address of the existing
connection is not so easy and has a big impact on the existing connection is not so easy and has a big impact on the existing
TCP/IP protocol stack implementation. TCP/IP protocol stack implementation.
3.4. All-by-oneself approach (Most Reactive) 3.4. All-by-oneself approach (Most Reactive)
skipping to change at page 10, line 39 skipping to change at page 12, line 40
- The existing host/router OS implementation must be changed a lot. - The existing host/router OS implementation must be changed a lot.
In particular, changing the source address of the existing In particular, changing the source address of the existing
connection is not so easy and has a big impact on the existing connection is not so easy and has a big impact on the existing
TCP/IP protocol stack implementation. TCP/IP protocol stack implementation.
3.4. All-by-oneself approach (Most Reactive) 3.4. All-by-oneself approach (Most Reactive)
3.4.1. Overview 3.4.1. Overview
shim6 was designed for site-multihoming. This mechanism introduces a shim6 [RFC5533] was designed for site-multihoming. This mechanism
new address selection method for session initiation and session introduces a new address selection method for session initiation and
survivability; it is documented in two drafts: session survivability; it is documented in RFC 5534. [RFC5534]
[I-D.ietf-shim6-locator-pair-selection] and
[I-D.ietf-shim6-failure-detection].
The shim6 host detects connection failures and changes the The shim6 host detects connection failures and changes the
destination and source addresses during the session. destination and source addresses during the session.
In this document, we focus on address selection issues in the In this document, we focus on address selection issues in the
connection initiation phase of shim6 and not on any other functions, connection initiation phase of shim6 and not on any other functions,
such as session survivability. such as session survivability.
3.4.2. Requirement correspondence analysis 3.4.2. Requirement correspondence analysis
skipping to change at page 11, line 51 skipping to change at page 14, line 9
behavior is switching a filter on/off on the network. Therefore, behavior is switching a filter on/off on the network. Therefore,
advanced control such as traffic engineering and QoS is almost advanced control such as traffic engineering and QoS is almost
impossible. impossible.
8. Route Selection: 2 8. Route Selection: 2
This solution does not refer to next-hop selection for the This solution does not refer to next-hop selection for the
transmission of a packet. Therefore, it should be used with some transmission of a packet. Therefore, it should be used with some
routing function such as RFC 4191 on the nodes. routing function such as RFC 4191 on the nodes.
9. Compatibility with RFC 3493: 3 9. Compatibility with RFC 3493: 3
This approach is able to coexist with any kind of applications This approach is able to coexist with any kind of applications
(socket API). In detail, any types of function such as (socket API). In detail, any types of function such as
getaddrinfo(), getsockname(), connect() or other typical system getaddrinfo(), getsockname(), connect() or other typical system
calls will work without alterations if this mechanism is applied calls will work without alterations if this mechanism is applied
to a host. to a host.
10. Compatibility and Interoperability with RFC 3484: 1 10. Compatibility and Interoperability with RFC 3484: 1
shim6 has different framework and coordination with RFC 3484.
The shim6 host performs address selection that reflects network shim6 has different framework and coordination with RFC 3484. The
failures that have occurred between the source and destination shim6 host performs address selection that reflects network host.
host. This may lead some interference with RFC3484 policy table. This may lead some interference with RFC3484 policy table.
11. Security: 1 11. Security: 1
This approach has a weakness on Denial of Service attack. It
will be concerned that the malicious users can abuse of This approach has a weakness on Denial of Service attack. It will
failure detection and make the network falling into critical be concerned that the malicious users can abuse of failure
condition. However, it depends on a situation how shim6 detection and make the network falling into critical condition.
operate with ICMPv6. However, it depends on a situation how shim6 operate with ICMPv6.
3.4.3. Other issues 3.4.3. Other issues
- The shim6 host performs address selection that reflects network
failures that have occurred between the source and destination
host.
- End hosts themselves can avoid network failure. There is no need - End hosts themselves can avoid network failure. There is no need
to modify or reconfigure routers in the path. to modify or reconfigure routers in the path.
- A host must learn address selection information for each - A host must learn address selection information for each
destination host. Therefore, the number of cache entries can be destination host. Therefore, the number of cache entries can be
very large. very large.
- The existing host OS implementation must be changed significantly. - The existing host OS implementation must be changed significantly.
4. Applicability Comparison 4. Applicability Comparison
skipping to change at page 14, line 12 skipping to change at page 16, line 33
- In a managed site, shim6 is not easy to manage in terms of node- - In a managed site, shim6 is not easy to manage in terms of node-
specific address selection control and central control. specific address selection control and central control.
4.2. Deployment Difficulty 4.2. Deployment Difficulty
less more less more
<-------------------------------------------> <------------------------------------------->
policy-dist 3484update shim6 Fred policy-dist 3484update shim6 Fred
PolicyDist: PolicyDist:
- What must be implemented is a distribution mechanism. The - What must be implemented is a distribution mechanism. The
existing protocols, such as RA and DHCP, can be used for this existing protocols, such as RA and DHCP, can be used for this
purpose. purpose.
3484update: 3484update:
- The protocol stack or applications on a host must be modified. - The protocol stack or applications on a host must be modified.
Routers in a site must be configured to return error messages to Routers in a site must be configured to return error messages to
the sender of inappropriately addressed packets. the sender of inappropriately addressed packets. In RFC3484,
- In RFC3484, precedences and labels are configurable, but not scopes. precedences and labels are configurable, but not scopes. Those of
Those of issues with ULA prefix or non routable global prefix still issues with ULA prefix or non routable global prefix still be left
be left behind even if this RFC would be updated. behind even if this RFC would be updated.
RouterAssist: RouterAssist:
- The protocol stack and applications on a host must be modified. - The protocol stack and applications on a host must be modified.
Furthermore, routers must be modified. Furthermore, routers must be modified.
shim6: shim6:
- The protocol stack must be modified. For this address selection - The protocol stack must be modified. For this address selection
purpose, corresponding nodes need not support shim6. Basically, purpose, corresponding nodes need not support shim6. Basically,
there is no need to change the router implementation or there is no need to change the router implementation or
configuration. configuration.
5. Security Considerations 5. Security Considerations
Incorrect address selection can lead to serious security problems, Incorrect address selection can lead to serious security problems,
such as session hijacking. However, we should note that address- such as session hijacking. However, we should note that address-
selection is ultimately decided by nodes and their users. There are selection is ultimately decided by nodes and their users. There are
skipping to change at page 15, line 17 skipping to change at page 17, line 40
In this document, we examined solutions to address selection problems In this document, we examined solutions to address selection problems
in the IPv6 multi-prefix environment. Although almost all solutions in the IPv6 multi-prefix environment. Although almost all solutions
examined in this document could be applied to any environment and examined in this document could be applied to any environment and
situation, a solution with a mechanism that is suitable for the situation, a solution with a mechanism that is suitable for the
situation should be selected. situation should be selected.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-v6ops-addr-select-ps]
Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Problem Statement of Default Address Selection in Multi-
prefix Environment: Operational Issues of RFC3484 Default
Rules", draft-ietf-v6ops-addr-select-ps-06 (work in
progress), May 2008.
[I-D.ietf-v6ops-addr-select-req]
Matsumoto, A., "Requirements for address selection
mechanisms", draft-ietf-v6ops-addr-select-req-07 (work in
progress), May 2008.
[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.
8.2. Informative References [RFC5220] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Problem Statement for Default Address Selection in Multi-
Prefix Environments: Operational Issues of RFC 3484
Default Rules", RFC 5220, July 2008.
[I-D.fujisaki-dhc-addr-select-opt] [RFC5221] Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
Fujisaki, T., "Distributing Address Selection Policy using "Requirements for Address Selection Mechanisms", RFC 5221,
DHCPv6", draft-fujisaki-dhc-addr-select-opt-06 (work in July 2008.
progress), June 2008.
[I-D.ietf-shim6-failure-detection] 8.2. Informative References
Arkko, J. and I. Beijnum, "Failure Detection and Locator
Pair Exploration Protocol for IPv6 Multihoming",
draft-ietf-shim6-failure-detection-10 (work in progress),
January 2008.
[I-D.ietf-shim6-locator-pair-selection] [I-D.fujisaki-dhc-addr-select-opt]
Bagnulo, M., "Default Locator-pair selection algorithm for Fujisaki, T., Matsumoto, A., Niinobe, S., Hiromi, R., and
the SHIM6 protocol", K. Kanayama, "Distributing Address Selection Policy using
draft-ietf-shim6-locator-pair-selection-02 (work in DHCPv6", draft-fujisaki-dhc-addr-select-opt-07 (work in
progress), July 2007. progress), March 2009.
[I-D.ietf-shim6-multihome-shim-api] [I-D.ietf-shim6-multihome-shim-api]
Komu, M., "Socket Application Program Interface (API) for Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto,
Multihoming Shim", draft-ietf-shim6-multihome-shim-api-03 "Socket Application Program Interface (API) for
(work in progress), July 2007. Multihoming Shim", draft-ietf-shim6-multihome-shim-api-08
(work in progress), May 2009.
[I-D.matsuoka-multihoming-try-and-error]
Matsuoka, H., "A Try and Error type approach for
multihoming", draft-matsuoka-multihoming-try-and-error-00
(work in progress), April 2009.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005. More-Specific Routes", RFC 4191, November 2005.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005. Addresses", RFC 4193, October 2005.
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6 [RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
Socket API for Source Address Selection", RFC 5014, Socket API for Source Address Selection", RFC 5014,
September 2007. September 2007.
[RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and
Locator Pair Exploration Protocol for IPv6 Multihoming",
RFC 5534, June 2009.
Appendix A. Appendix. Revision History
02:
Updated references for documents that were approved as RFCs.
Added reference to Hirotaka Matsuoka's try-and-error mechanism.
Added description about Aleksi Suhonen's routing table based
mechanism.
01:
Corresponding to the increase of RFC 5221 requirements,
considerations about requirement #9, #10, #11 are added for each
approach.
00:
Approved as a 6man working group item.
Authors' Addresses Authors' Addresses
Arifumi Matsumoto Arifumi Matsumoto
NTT PF Lab NTT PF 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: arifumi@nttv6.net
skipping to change at page 16, line 43 skipping to change at page 20, line 4
Email: fujisaki@syce.net Email: fujisaki@syce.net
Ruri Hiromi Ruri Hiromi
Intec Netcore, Inc. Intec Netcore, Inc.
Shinsuna 1-3-3 Shinsuna 1-3-3
Koto-ku, Tokyo 136-0075 Koto-ku, Tokyo 136-0075
Japan Japan
Phone: +81 3 5665 5069 Phone: +81 3 5665 5069
Email: hiromi@inetcore.com Email: hiromi@inetcore.com
Ken-ichi Kanayama Ken-ichi Kanayama
INTEC Systems Institute, Inc. INTEC Systems Institute, Inc.
Shimoshin-machi 5-33 Shimoshin-machi 5-33
Toyama-shi, Toyama 930-0804 Toyama-shi, Toyama 930-0804
Japan Japan
Phone: +81 76 444 8088 Phone: +81 76 444 8088
Email: kanayama_kenichi@intec-si.co.jp Email: kanayama_kenichi@intec-si.co.jp
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 64 change blocks. 
122 lines changed or deleted 199 lines changed or added

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