draft-ietf-6man-addr-select-sol-02.txt   draft-ietf-6man-addr-select-sol-03.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: January 3, 2010 R. Hiromi Expires: September 9, 2010 R. Hiromi
Intec Netcore Intec Netcore
K. Kanayama March 8, 2010
INTEC Systems
July 2, 2009
Solution approaches for address-selection problems Solution approaches for address-selection problems
draft-ietf-6man-addr-select-sol-02.txt draft-ietf-6man-addr-select-sol-03.txt
Abstract
In response to address selection problem statement and requirement
documents, this document describes solution approaches and evaluates
proposed solution mechanisms in line with requirements. It also
examines the applicability for each solution mechanism, and concludes
that no single solution solves the problems and the combination of
the solutions should be the way forward.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79.
from IETF Documents or IETF Contributions published or made publicly
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 January 3, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
In response to address selection problem statement and requirement This document may contain material from IETF Documents or IETF
documents, this document describes approaches to solutions and Contributions published or made publicly available before November
evaluates proposed solution mechanisms in line with requirements. It 10, 2008. The person(s) controlling the copyright in some of this
also examines the applicability of each solution mechanism from the material may not have granted the IETF Trust the right to allow
viewpoint of practical application. 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.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Solution Design . . . . . . . . . . . . . . . . . . . . . . . 4 2. Solution Approaches . . . . . . . . . . . . . . . . . . . . . 4
2.1. Proactive approaches . . . . . . . . . . . . . . . . . . . 4 2.1. Proactive approach . . . . . . . . . . . . . . . . . . . . 4
2.2. Reactive approaches . . . . . . . . . . . . . . . . . . . 5 2.2. Reactive approach . . . . . . . . . . . . . . . . . . . . 4
3. Solution approaches . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Mechanisms . . . . . . . . . . . . . . . . . . . . . 4
3.1. Obtain all information prior to communication (Most 3.1. Policy Distribution (Proactive Approach) . . . . . . . . . 5
Proactive) . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.1. Requirements correspondence analysis . . . . . . . . . 5
3.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2. Other issues . . . . . . . . . . . . . . . . . . . . . 6
3.1.2. Requirements correspondence analysis . . . . . . . . . 6 3.2. Routing system assistance (Proactive Approach) . . . . . . 6
3.1.3. Other issues . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Requirements correspondence analysis . . . . . . . . . 7
3.2. Routing system assistance for address selection 3.2.2. Other issues . . . . . . . . . . . . . . . . . . . . . 8
(Proactive) . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Trial-and-error based (Reactive Approach) . . . . . . . . 8
3.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 7 3.3.1. Requirement correspondence analysis . . . . . . . . . 8
3.2.2. Requirements correspondence analysis . . . . . . . . . 8 3.3.2. Other issues . . . . . . . . . . . . . . . . . . . . . 10
3.2.3. Other issues . . . . . . . . . . . . . . . . . . . . . 9 3.4. All at once (Reactive Approach) . . . . . . . . . . . . . 10
3.3. Trial-and-error approach (Reactive) . . . . . . . . . . . 10 3.4.1. Requirement correspondence analysis . . . . . . . . . 10
3.3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 10 3.4.2. Other issues . . . . . . . . . . . . . . . . . . . . . 12
3.3.2. Requirement correspondence analysis . . . . . . . . . 10 4. Applicability Comparison . . . . . . . . . . . . . . . . . . . 12
3.3.3. Other issues . . . . . . . . . . . . . . . . . . . . . 12 4.1. Dynamic-static and managed-unmanaged . . . . . . . . . . . 12
3.4. All-by-oneself approach (Most Reactive) . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
3.4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
3.4.2. Requirement correspondence analysis . . . . . . . . . 13 7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.3. Other issues . . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4. Applicability Comparison . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
4.1. Dynamic-static and managed-unmanaged . . . . . . . . . . . 15 8.2. Informative References . . . . . . . . . . . . . . . . . . 15
4.2. Deployment Difficulty . . . . . . . . . . . . . . . . . . 16 Appendix A. Other Solutions . . . . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 Appendix B. Revision History . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Appendix. Revision History . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
One physical network can have multiple logical networks. In that
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
global scope addresses or in a site connected to multiple upstream
IPv6 networks.) For such a host, RFC 3484 [RFC3484] defines default
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 do not work perfectly. RFC 5220
structure. RFC 5220 [RFC5220] lists problematic cases that resulted [RFC5220] lists problematic cases that resulted from incorrect
from incorrect address selection. address selection. RFC 5221 [RFC5221] enumerates requirements for
address-selection mechanisms.
Though RFC 3484 made the address-selection behavior of a host
configurable, typical users cannot make use of that because of the
complexity of the mechanism and their lack of knowledge about their
network topologies. Therefore, an address-selection
autoconfiguration mechanism is necessary, especially for the
unmanaged hosts of typical users.
RFC 5221 [RFC5221] document enumerates requirements for address-
selection mechanisms that enable hosts to perform appropriate address
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 were proposed.
proposed. This document describes possible design approaches for This document describes possible design approaches for solving
solving address selection problems. After that, we try to put address selection problems. After summarizing each existing proposal
together an overview as well as an analysis of how well the method mechanism and analyzing how well the method corresponds with the
corresponds with the requirements. requirements, applicability domain for each mechanism are evaluated.
2. Solution Design 2. Solution Approaches
There are two types of approaches that can control the behavior of There are two types of approaches that can control the behavior of
hosts in terms of the selection of destination address and source hosts in terms of the selection of destination address and source
address. The first type is proactive, where the host is given the address. The first type is proactive, where the host is given the
necessary information to decide the destination and source addresses necessary information to decide the destination and source addresses
before the beginning of transmission. The other type is reactive, before the beginning of data transmission. The other type is
where the host decides appropriate destination address and source reactive, where the host decides appropriate destination address and
addresses through trial and error. source addresses through trial and error.
2.1. Proactive approaches
There can be two types of proactive approaches. One gives hosts all 2.1. Proactive approach
the information for selecting destination and address and source
addresses beforehand. Under some circumstances, a lot of information
could be stored in hosts.
The other type informs hosts about which prefixes should be used in In this approach, hosts should have all or a part of the information
the source address for the different destinations every time before for selecting appropriate address pair before the actual data
starting each connection. transmission.
2.2. Reactive approaches 2.2. Reactive approach
In these approaches, the host does not have initial information for In this approach, the host does not have initial information for
address selection. It will try using different pairs of destination address selection. It will try using different pairs of destination
and source addresses until the connection is established. When an and source addresses until the connection is established. It can
outage occurs, the host must detect it and try again with a new pair take advantage of error messages, and can make use of it to prune
of destination address and source address. Some reactive solutions unworkable pair of addresses.
may use some kind of control message that enables the gateway to
indicate the outage.
3. Solution approaches 3. Solution Mechanisms
This section describes the evaluation of the four approaches to This section describes the evaluation of the four mechanisms. The
finding solutions. The evaluation value has a 3-point scale for each evaluation value has a 3-point scale for each of 8 requirements in
of 8 requirements in the requirement document. The meaning of the the requirement document. The meanings of the points are as follows.
points is as follows.
1 : bad 1 : bad
2 : fair 2 : fair
3 : good 3 : good
About "Effectiveness", the score is 1 if the approach solves no About "Effectiveness", the score is 1 if the approach solves no
problematic cases described in the problem statement document, 2 if problematic cases described in the problem statement document, 2 if
it can handle at least one, and 3 if it solves every case. it can handle at least one, and 3 if it solves every case.
3.1. Obtain all information prior to communication (Most Proactive) 3.1. Policy Distribution (Proactive Approach)
3.1.1. Overview
In this approach, a host obtains everything needed to select In this approach, a host obtains everything, usually policies, needed
addresses at once prior to communication. A host receives all policy to select addresses prior to communication. The address selection
information from a server beforehand. It then sets up communication design team is working on this approach.
whenever it wants to. DHCPv6 and RA fall into this category as known [I-D.ietf-6man-addr-select-considerations] DHCPv6 and RA are possible
protocols. There is a reference document transport protocols. There is a proposal 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 behavior.
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.1. 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, which
exhibits good usability. Moreover, this leads to fewer overheads does not cause any delay or incorrect address selection.
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, such as RA and DHCPv6 RECONFIGURE.
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. and unicast based RA 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. For such cases, the algorithm for
merging policies have to be considered, which is documented in
this document. [I-D.arifumi-6man-addr-select-conflict]
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" RFC 4191. "Default Router Preferences and More-Specific Routes" RFC 4191.
[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
By injecting address selection policy, a session hijacking can be
possible in this mechanism. A combination of Layer 2 securing
techniques and this mechanism will be able to be effective against
security concerns. DHCP and RA protocol have own security
measures and they also protect from them.
This approach has a weakness on hijacking. A combination of Layer 3.1.2. Other issues
2 securing techniques and this mechanism will be able to be
effective against security concerns. DHCP and RA protocol have
own security measures and they also protect from them.
3.1.3. Other issues
- The traffic volume will be equal to the number of policies.
- Hosts and servers need to support this function.
3.2. Routing system assistance for address selection (Proactive) None.
3.2.1. Overview 3.2. Routing system assistance (Proactive Approach)
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
addresses when the host has a set of addresses A and the destination addresses when the host has a set of addresses A and the destination
host has a set of addresses B. Then, the host uses the policy host has a set of addresses B. Then, the host uses the policy
provided by the server/routing system as a guide in applying the provided by the server/routing system as a guide in applying the
response. He also proposed a mechanism that utilizes the ICMP error response.
message to change the source address of the existing session. This
point resembles Section 3.3 3484update mechanism, so the following
evaluation is based on only the first part of his proposal.
3.2.2. Requirements correspondence analysis 3.2.1. Requirements correspondence analysis
1. Effectiveness: 3 1. Effectiveness: 3
A routing system knows about information about paths toward the A routing system knows about information about paths toward the
destination and information about which of their prefixes should destination and information about which of their prefixes should
be used. Therefore, it is possible to select an appropriate pair be used. Therefore, it is possible to select an appropriate pair
of source and destination addresses. of source and destination addresses.
2. Timing: 3 2. Timing: 3
A routing system always has up-to-date routing information, so it A routing system always has up-to-date routing information, so it
will be possible to provide suitable information whenever requests will be possible to provide suitable information whenever requests
come. However, the amount of information that the system must come.
handle is huge, so there will be cases where it takes time to
answer the request because appropriate information must be
retrieved from a huge database.
If any server or routing trouble occurs, the requester cannot get
the answer, and address selection will fail. This point is the
same in all systems that depend on other servers.
3. Dynamic update: 3 3. Dynamic update: 3
A routing system always has up-to-date routing information, and it A routing system always has up-to-date routing information, and it
will be possible to provide suitable information whenever requests will be possible to provide suitable information whenever requests
come. come.
4. Node-specific behavior: 3 4. Node-specific behavior: 3
Node-specific information can be provided if a server recognizes Node-specific information can be provided if a server recognizes
individual nodes. individual nodes.
5. Application-specific behavior: 2 5. Application-specific behavior: 2
A routing system does not care about applications. Using address A routing system does not care about applications. Using address
selection API allows nodes to behave in an application-specific selection API allows nodes to behave in an application-specific
way. way.
6. Multiple Interfaces: 2 6. Multiple Interfaces: 2
If all interfaces belong to the same administration domain, it is The same as the policy based mechanism.
possible for the address-selection information to be controlled by
administrators of that domain. However, if not, routing
information and address selection policies are not always
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.
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: 1
In the existing TCP/IP protocol stack implementation, destination
This approach is able to coexist with any kind of applications address selection is mainly the role of the application and not
(socket API). In detail, any types of function such as that of the kernel unlike source address selection. Therefore,
getaddrinfo(), getsockname(), connect() or other typical system implementing this model without affecting applications is not
calls will work without alterations if this mechanism is applied feasible.
to a host. 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.
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. but it can be coexist with RFC3484.
11. Security: 2 11. Security: 2
This approach has a weakness on hijacking. Currently it just This approach has a weakness on hijacking just like the previous
proposed and there is no implementation. Therefore, it depends on mechanism.
how to define security protection mechanism and how to implement
it.
3.2.3. Other issues 3.2.2. Other issues
- A host must consult the routing system every time it starts a
connection if the host does not have address selection information
for the destination host or if the information lifetime has
expired. This could be a possible scalability problem.
- The existing host/router OS implementation must be changed a lot. - It has a possible scalability problem. A host must consult the
In the existing TCP/IP protocol stack implementation, destination routing system every time it starts a connection if the host does
address selection is mainly the role of the application and not not have address selection information for the destination host or
that of the kernel unlike source address selection. Therefore, if the information lifetime has expired.
implementing this model without affecting applications is not so
easy.
3.3. Trial-and-error approach (Reactive) - The existing host/router OS implementation must be changed a lot.
This can be problematic in some cases.
3.3.1. Overview 3.3. Trial-and-error based (Reactive Approach)
M. Bagnulo presented a new address selection idea in his draft. M. Bagnulo presented a new address selection idea in his draft.
Hirotaka Matsuoka extended and elaborated this approach in his draft. Hirotaka Matsuoka extended and elaborated this approach in his draft.
[I-D.matsuoka-multihoming-try-and-error] When the host notices that a [I-D.matsuoka-multihoming-try-and-error] When the host notices that a
network failure has occurred or packets have been dropped somewhere network failure has occurred or packets have been dropped somewhere
in the network by, for example, an ingress filter, the host changes in the network by, for example, an ingress filter, the host stores a
the source address of the connection to another source address. negative cache of address selection.
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 3.3.1. Requirement correspondence analysis
communication, this method provides an ordered list of source
addresses for the destination address to the application.
3.3.2. Requirement correspondence analysis
1. Effectiveness: 2 1. Effectiveness: 2
This solution is not effective for the destination address
This solution is not effective for the problem about IPv4 or IPv6 selection cases, such as a problem about IPv4 or IPv6
prioritization described in the problem statement document. prioritization described in the problem statement document.
2. Timing: 2 2. Timing: 1
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. This
issue largely depends on the cacue functionality, but there is no
established algorithm for this.
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 deploying a packet
filter for each node at the gateways through which the packets filter configured for each node at the gateways through which the
from nodes pass. packets 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 applications(socket APIs). The returen value of functions would
be 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
skipping to change at page 12, line 13 skipping to change at page 10, line 13
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 applications(socket APIs). The returen value of functions would
be 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: 1
This approach has a weakness on hijacking. Moreover, it may
This approach has a weakness on hijacking. Currently it just expose the privacy of the user host by showing all or a part of
proposed and there is no implementation. Therefore, it depends on the addresses of the host to the destination host.
how to define security protection mechanism and how to implement
it.
3.3.3. Other issues 3.3.2. 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 at once (Reactive Approach)
3.4.1. Overview
shim6 [RFC5533] was designed for site-multihoming. This mechanism
introduces a new address selection method for session initiation and
session survivability; it is documented in RFC 5534. [RFC5534]
The shim6 host detects connection failures and changes the This is another proposal by Fred Baker at 6man ML. By trying all the
destination and source addresses during the session. pairs of source and destination addresses at once, or in a very shord
period of time, a connection can be established as far as there is at
least one working pair of addresses.
In this document, we focus on address selection issues in the This mechiansm can easily combined with the error message retrieval
connection initiation phase of shim6 and not on any other functions, and cache function discussed in Section 3.3 to prune the unnecessary
such as session survivability. connection trials.
3.4.2. Requirement correspondence analysis 3.4.1. Requirement correspondence analysis
1. Effectiveness: 2 1. Effectiveness: 2
This solution is not effective for the destination address
This solution is not effective for the problem about IPv4 or IPv6 selection cases, such as a problem about IPv4 or IPv6
prioritization described in the problem statement document. prioritization described in the problem statement document.
2. Timing: 2 2. Timing: 3
The user does not have to wait for extra period of time.
Hosts should try to use all the available source addresses to the
maximum to find an appropriate source address. If the host tries
the next source address after the previous trial using another
source address has failed, it may take a long time because this
trial-and-error process lasts until the connection succeeds. If
the host does not use error messages from a network to detect a
connection error, it takes longer to wait for a time-out.
3. Dynamic update: 3 3. Dynamic update: 3
It can reflect dynamically changing network, as far as it always It can reflect dynamically changing network, as far as it always
tries all possible addresses and next-hops. tries all possible addresses and next-hops.
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 on the gateways through which the packets filter for each node on 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
The use of shim6 API [I-D.ietf-shim6-multihome-shim-api] allows behavior. However, the mechanism of this approach does not
applications to override address selection behavior. exclude address selection by each application.
6. Multiple interfaces: 3 6. Multiple interfaces: 3
If the protocol-stack supports interface selection and it tries to If the protocol-stack supports interface selection and it tries to
establish a connection by changing addresses and also interfaces, establish a connection by changing addresses and also interfaces,
it can find a working combination of addresses and interface. it can find a working combination of addresses and interface.
But, in such a environment, a host has to try all the combinations
of source address, destination address, and next-hop addresses,
which can be huge amount of connection establishment trial.
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. 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.
skipping to change at page 14, line 8 skipping to change at page 11, line 40
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. 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: 1
For non-connected transport protocols, there is no universal nor
This approach is able to coexist with any kind of applications established way of telling a connection is successful or failure
(socket API). In detail, any types of function such as from the viewpoint of anything other than the application. In
getaddrinfo(), getsockname(), connect() or other typical system this sense, it does not work for non-connected transport
calls will work without alterations if this mechanism is applied protocols.
to a host.
10. Compatibility and Interoperability with RFC 3484: 1 10. Compatibility and Interoperability with RFC 3484: 1
This mechanism uses every possible addresses for its rather
shim6 has different framework and coordination with RFC 3484. The initial connection setup. In that sense, it does not follow the
shim6 host performs address selection that reflects network host. address selection rules of RFC 3484.
This may lead some interference with RFC3484 policy table.
11. Security: 1 11. Security: 1
This approach has a weakness on hijacking. Moreover, it may
expose the privacy of the user host by showing all or a part of
the addresses of the host to the destination host.
This approach has a weakness on Denial of Service attack. It will 3.4.2. Other issues
be concerned that the malicious users can abuse of failure
detection and make the network falling into critical condition.
However, it depends on a situation how shim6 operate with ICMPv6.
3.4.3. Other issues
- The shim6 host performs address selection that reflects network - It brings unnecessary traffic to network, host, routers, and
failures that have occurred between the source and destination destinations.
host.
- End hosts themselves can avoid network failure. There is no need - It breaks DNS round robin based load balancing.
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
In the previous section, every approach scored "fair" or better for If you actually want to choose one mechanism to solve your address
every requirement. This means that every approach can meet the selection problem, it is important to figure out which approach is
demands of address selection. However, if you actually want to best suited to your situation. This section tries to evaluate the
choose one mechanism to solve your address selection problem, it is applicability of each approach from several aspects.
important to figure out which approach is best suited to your
situation. This section tries to evaluate the applicability of each
approach from several aspects.
4.1. Dynamic-static and managed-unmanaged 4.1. Dynamic-static and managed-unmanaged
First, we use two axes to evaluate the applicability of the four We use two axes to evaluate the applicability of the four approaches.
approaches. One axis shows whether or not the network structure One axis shows whether or not the network structure changes
changes dynamically and the other axis shows whether the site is dynamically and the other axis shows whether the site is managed or
managed or unmanaged. In a managed network, by our definition, a unmanaged. In a managed network, by our definition, a network
network administrator manages his or her network, routers, and hosts. administrator manages his or her network, routers, and hosts. For
For example, an enterprise network is managed, whereas a home network example, an enterprise network is managed, whereas a home network and
and a SOHO network are unmanaged. a SOHO network are unmanaged.
static dynamic static dynamic
<--------------------------------------------> <-------------------------------------------->
unmanaged ^ +----------+ +---------------------------+ unmanaged ^ +----------+ +---------------------------+
| | | +-+--------------+ shim6 | | | | +-+--------------+ all-at-once|
| | | | | | | | | | | | | |
| | +--+-+-+------------+ | | | | +--+-+-+------------+ | |
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | |
| | | | | +------------+-+------------+ | | | | | +------------+-+------------+
| | | | | 3484update| | | | | | | try-error| |
| | +--+-+--------------+ | | | +--+-+--------------+ |
| | | | | | | | | |
| | | | | | | | | |
| | Policy | | RouterAssist | | | Policy | | RouterAssist |
| | Dist | | | | | Dist | | |
| | | | | | | | | |
| +----------+ +----------------+ | +----------+ +----------------+
managed v managed v
PolicyDist: PolicyDist:
- In a dynamic site, the policy table must be updated accordingly - In a dynamic site, the policy table must be updated accordingly
and traffic for policy table distribution increases. and traffic for policy table distribution increases.
3484update: try-and-error:
- This is a slightly manageable than shim6 in that 3484update does - This is a slightly manageable than all-at-once in that it does not
not change the paths of established connections dynamically. change the paths of established connections dynamically.
- In a very dynamic site, the use of an address selection - In a very dynamic site, the use of an address selection
information cache does not have a good effect. This results in information cache does not have a good effect. This results in
connection failure and may degrade usability badly. connection failure and may degrade usability badly.
- Even in a very static site, a host may try inappropriate addresses - Even in a very static site, a host may try inappropriate addresses
or next-hops and experience connection failures. or next-hops and experience connection failures.
RouterAssist: RouterAssist:
- A host must send at least as many queries as the number - A host must send at least as many queries as the number
destination hosts. Therefore, in a static site, this method is destination hosts. Therefore, in a static site, this method is
not optimal. not optimal.
- In a very dynamic site, address selection information cache is no - In a very dynamic site, address selection information cache is no
help. If the cache function is not used, then connection failures help. If the cache function is not used, then connection failures
do not occur. do not occur.
shim6: all-at-once:
- In a static site, shim6 is not desirable because of its connection - In a static site, all-at-once is not desirable because of its
sequence overhead and timeout-wait for path exploration. connection sequence overhead and timeout-wait for path
exploration.
- In a managed site, shim6 is not easy to manage in terms of node- - In a managed site, it 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
less more
<------------------------------------------->
policy-dist 3484update shim6 Fred
PolicyDist:
- What must be implemented is a distribution mechanism. The
existing protocols, such as RA and DHCP, can be used for this
purpose.
3484update:
- The protocol stack or applications on a host must be modified.
Routers in a site must be configured to return error messages to
the sender of inappropriately addressed packets. In RFC3484,
precedences and labels are configurable, but not scopes. Those of
issues with ULA prefix or non routable global prefix still be left
behind even if this RFC would be updated.
RouterAssist:
- The protocol stack and applications on a host must be modified.
Furthermore, routers must be modified.
shim6:
- The protocol stack must be modified. For this address selection
purpose, corresponding nodes need not support shim6. Basically,
there is no need to change the router implementation or
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
no means to enforce a specific address-selection behavior upon every no means to enforce a specific address-selection behavior upon every
end-host from outside the host. Therefore, a network administrator end-host from outside the host. Therefore, a network administrator
must take countermeasures against unexpected address selection. must take countermeasures against unexpected address selection.
6. IANA Considerations 6. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
7. Conclusions 7. Conclusions
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. From the requirement analysis
examined in this document could be applied to any environment and and applicability evaluation, it can be concluded that there is no
situation, a solution with a mechanism that is suitable for the one perfect solution for this series of problems.
situation should be selected.
Hence, we have to combine two or more solutions together. The design
team proposal and all-at-once proposal are extreme opposite, and
combining these two seems to make the coverage biggest problem
spaces.
8. References 8. References
8.1. Normative References 8.1. Normative 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.
[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.
8.2. Informative References 8.2. Informative References
[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-01 (work in
progress), October 2009.
[I-D.axu-addr-sel]
Suhonen, A., "Address Selection Using Source Address
Specific Routing Tables", draft-axu-addr-sel-00 (work in
progress), July 2009.
[I-D.fujisaki-dhc-addr-select-opt] [I-D.fujisaki-dhc-addr-select-opt]
Fujisaki, T., Matsumoto, A., Niinobe, S., Hiromi, R., and Fujisaki, T., Matsumoto, A., and R. Hiromi, "Distributing
K. Kanayama, "Distributing Address Selection Policy using Address Selection Policy using DHCPv6",
DHCPv6", draft-fujisaki-dhc-addr-select-opt-07 (work in draft-fujisaki-dhc-addr-select-opt-09 (work in progress),
progress), March 2009. March 2010.
[I-D.ietf-6man-addr-select-considerations]
Chown, T., "Considerations for IPv6 Address Selection
Policy Changes",
draft-ietf-6man-addr-select-considerations-00 (work in
progress), October 2009.
[I-D.ietf-shim6-multihome-shim-api] [I-D.ietf-shim6-multihome-shim-api]
Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto, Komu, M., Bagnulo, M., Slavov, K., and S. Sugimoto,
"Socket Application Program Interface (API) for "Socket Application Program Interface (API) for
Multihoming Shim", draft-ietf-shim6-multihome-shim-api-08 Multihoming Shim", draft-ietf-shim6-multihome-shim-api-13
(work in progress), May 2009. (work in progress), February 2010.
[I-D.matsuoka-multihoming-try-and-error] [I-D.matsuoka-multihoming-try-and-error]
Matsuoka, H., "A Try and Error type approach for Matsuoka, H., "A Try and Error type approach for
multihoming", draft-matsuoka-multihoming-try-and-error-00 multihoming", draft-matsuoka-multihoming-try-and-error-00
(work in progress), April 2009. (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
skipping to change at page 18, line 43 skipping to change at page 16, line 13
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 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
Shim Protocol for IPv6", RFC 5533, June 2009. Shim Protocol for IPv6", RFC 5533, June 2009.
[RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and [RFC5534] Arkko, J. and I. van Beijnum, "Failure Detection and
Locator Pair Exploration Protocol for IPv6 Multihoming", Locator Pair Exploration Protocol for IPv6 Multihoming",
RFC 5534, June 2009. RFC 5534, June 2009.
Appendix A. Appendix. Revision History Appendix A. Other Solutions
Other than policy table distribution based approach, Aleksi Suhonen
proposed his idea [I-D.axu-addr-sel], where a host has a separate
routing table for each attached address. The document is still
incompleted, but basically it should have characteristics in common
with above mentioned policy table based mechanism except for the
implementation characteristics.
shim6 [RFC5533] was designed for site-multihoming. This mechanism
introduces a new sub-layer in IP layer, and new address selection
method for session initiation and session survivability. it is
documented in RFC 5534. [RFC5534] shim6 should fall into try-and-
error based category, in that it establishes a connection by trying
pairs of addresses.
Appendix B. Revision History
03:
Combined shim6 and try-and-error mechanisms into one section 3.3.
Removed deployment analysis in Section 4.
Made the introduction short and brief.
Added a reference to Design Team's work.
Added a reference to address selection conflict draft.
Created Appendix A. to mention about other solution proposals.
Conclusion and abstract was modified to reflect the discussion at
6man ML.
02: 02:
Updated references for documents that were approved as RFCs. Updated references for documents that were approved as RFCs.
Added reference to Hirotaka Matsuoka's try-and-error mechanism. Added reference to Hirotaka Matsuoka's try-and-error mechanism.
Added description about Aleksi Suhonen's routing table based Added description about Aleksi Suhonen's routing table based
mechanism. mechanism.
01: 01:
Corresponding to the increase of RFC 5221 requirements, Corresponding to the increase of RFC 5221 requirements,
considerations about requirement #9, #10, #11 are added for each considerations about requirement #9, #10, #11 are added for each
approach. approach.
00: 00:
Approved as a 6man working group item. Approved as a 6man working group item.
Authors' Addresses Authors' Addresses
Arifumi Matsumoto Arifumi Matsumoto
skipping to change at page 20, line 4 skipping to change at line 733
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
INTEC Systems Institute, Inc.
Shimoshin-machi 5-33
Toyama-shi, Toyama 930-0804
Japan
Phone: +81 76 444 8088
Email: kanayama_kenichi@intec-si.co.jp
 End of changes. 114 change blocks. 
368 lines changed or deleted 267 lines changed or added

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