One document matched: draft-ietf-6man-addr-select-sol-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2461 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2461.xml'>
<!ENTITY rfc3315 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3315.xml'>
<!ENTITY rfc3484 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3484.xml'>
<!ENTITY rfc3633 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3633.xml'>
<!ENTITY rfc2991 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2991.xml'>
<!ENTITY rfc2992 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2992.xml'>
<!ENTITY rfc4191 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4191.xml'>
<!ENTITY rfc4193 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4193.xml'>
<!ENTITY UPDATE3484 PUBLIC 'UPDATE3484'
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.bagnulo-rfc3484-update.xml'>
<!ENTITY ADDRSELPS PUBLIC 'ADDRSELPS'
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-addr-select-ps.xml'>
<!ENTITY ADDRSELREQ PUBLIC 'ADDRSELPS'
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-v6ops-addr-select-req.xml'>
<!-- <!ENTITY POLICYDIST PUBLIC 'POLICYDIST'
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.arifumi-ipv6-policy-dist.xml'> -->
<!ENTITY ADDRSELOPT PUBLIC 'ADDRSELOPT'
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.fujisaki-dhc-addr-select-opt.xml'>
<!ENTITY rfc5014 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5014.xml'>
<!-- <!ENTITY ADDRSELAPI PUBLIC 'ADDRSELAPI'
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.chakrabarti-ipv6-addrselect-api.xml'> -->
<!ENTITY LOCPAIRSEL PUBLIC 'LOCPAIRSEL'
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-shim6-locator-pair-selection.xml'>
<!ENTITY FAILDETECT PUBLIC 'FAILDETECT'
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-shim6-failure-detection.xml'>
<!ENTITY SHIMAPI PUBLIC 'SHIMAPI'
'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-shim6-multihome-shim-api.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc autobreaks="yes" ?>
<?rfc toc="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc symrefs="yes" ?>
<?rfc compact="yes" ?>
<rfc category="info" ipr="full3978" docName="draft-ietf-6man-addr-select-sol-00.txt">
<front>
<title abbrev='Address-Selection Solutions'>
Solution approaches for address-selection problems
</title>
<author initials='A.M.' surname="Matsumoto" fullname='Arifumi Matsumoto'>
<organization abbrev='NTT'>NTT PF Lab</organization>
<address>
<postal>
<street>Midori-Cho 3-9-11</street>
<city>Musashino-shi</city>
<region>Tokyo</region>
<code>180-8585</code>
<country>Japan</country>
</postal>
<phone>+81 422 59 3334</phone>
<email>arifumi@nttv6.net</email>
</address>
</author>
<author initials='T.F.' surname="Fujisaki" fullname='Tomohiro Fujisaki'>
<organization abbrev='NTT'>NTT PF Lab</organization>
<address>
<postal>
<street>Midori-Cho 3-9-11</street>
<city>Musashino-shi</city>
<region>Tokyo</region>
<code>180-8585</code>
<country>Japan</country>
</postal>
<phone>+81 422 59 7351</phone>
<email>fujisaki@syce.net</email>
</address>
</author>
<author initials='R.H.' surname="Hiromi" fullname='Ruri Hiromi'>
<organization abbrev='Intec Netcore'>Intec Netcore, Inc.</organization>
<address>
<postal>
<street>Shinsuna 1-3-3</street>
<city>Koto-ku</city>
<region>Tokyo</region>
<code>136-0075</code>
<country>Japan</country>
</postal>
<phone>+81 3 5665 5069</phone>
<email>hiromi@inetcore.com</email>
</address>
</author>
<author initials='K.K.' surname="Kanayama" fullname='Ken-ichi Kanayama'>
<organization abbrev='Intec Netcore'>Intec Netcore, Inc.</organization>
<address>
<postal>
<street>Shinsuna 1-3-3</street>
<city>Koto-ku</city>
<region>Tokyo</region>
<code>136-0075</code>
<country>Japan</country>
</postal>
<phone>+81 3 5665 5069</phone>
<email>kanayama@inetcore.com</email>
</address>
</author>
<date month="January" year="2008"/>
<area>Internet</area>
<workgroup>IPv6 Maintenance Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract>
<t>
In response to address selection problem statement and
requirement documents, this document describes approaches to solutions and
evaluates proposed solution mechanisms in line with requirements.
It also examines the applicability of each solution mechanism
from the viewpoint of practical application.
</t>
</abstract>
</front>
<middle>
<section title="Introduction"> <!-- 1 -->
<t>
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
<xref target="RFC4193">ULA</xref> and
global scope addresses or in a site connected to multiple upstream
IPv6 networks.) For such a host, <xref target="RFC3484">RFC 3484</xref>
defines default
address-selection rules for the source and destination addresses.
</t>
<t>
Today, the RFC 3484 mechanism is widely implemented in major OSs.
However, many people, including us, have found that in many sites
the default address-selection rules are not appropriate for the network
structure.
<xref target="I-D.ietf-v6ops-addr-select-ps">PS</xref> lists problematic
cases that resulted from incorrect address selection.
</t>
<t>
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.
</t>
<t>
<xref target="I-D.ietf-v6ops-addr-select-req">REQ</xref> document
enumerates requirements for address-selection mechanisms
that enable hosts to perform appropriate address selection
automatically.
</t>
<t>
In the IETF mailing lists and in the internet-draft archives,
some mechanisms for solving address-selection problems
have already been proposed.
This document describes possible design approaches
for solving address selection problems.
After that, we try to put together an overview as well as
an analysis of how well the method corresponds with the requirements.
</t>
</section>
<section title="Solution Design"> <!-- 2 -->
<t>
There are two types of approaches that can control the behavior of
hosts in terms of the selection of destination address and source address.
The first type is proactive, where the host is given the
necessary information to decide the destination and source
addresses before the beginning of transmission. The other type is
reactive, where the host decides appropriate destination
address and source addresses through trial and error.
</t>
<section title="Proactive approaches"> <!-- 2.1 -->
<t>
There can be two types of proactive approaches.
One gives hosts all the information for selecting destination
and address and source addresses beforehand. Under some circumstances,
a lot of information could be stored in hosts.
</t>
<t>
The other type informs hosts about which prefixes should be
used in the source address for the different destinations every time
before starting each connection.
</t>
</section>
<section title="Reactive approaches"> <!-- 2.2 -->
<t>
In these approaches, the host does not have initial information for
address selection. It will try using different pairs of destination
and source addresses until the connection is established.
When an outage occurs, the host must detect it and
try again with a new pair of destination address and
source address. Some reactive solutions may use some
kind of control message that enables the gateway to indicate the outage.
</t>
</section>
</section>
<section title="Solution approaches"> <!-- 3 -->
<t>
This section describes the evaluation of the four approaches to
finding solutions. The evaluation value has a 3-point scale for each
of 8 requirements in the requirement document.
The meaning of the points is as follows.
</t>
<figure>
<artwork>
1 : bad
2 : fair
3 : good
</artwork>
</figure>
<t>
About "Effectiveness", the score is 1 if the approach solves no
problematic cases described in the problem statement document,
2 if it can handle at least one,
and 3 if it solves every case.
</t>
<section title="Obtain all information prior to communication (Most Proactive)"> <!-- 3.1 -->
<section title="Overview">
<t>
In this approach, a host obtains everything needed to select
addresses at once prior to communication. A host receives all
policy information from a server beforehand. It then sets up
communication whenever it wants to.
DHCPv6 and RA fall into this category as known protocols.
There is a reference <xref target="I-D.fujisaki-dhc-addr-select-opt">document</xref> in which DHCPv6 is used for this purpose.
</t>
<t>
This approach can take advantage of the RFC 3484 Policy Table,
which is already widely deployed. By distributing policies for
the Policy Table, you can auto-configure a host's address selection policy.
</t>
</section>
<section title="Requirements correspondence analysis">
<t>1. Effectiveness: 3</t>
<list style="hanging">
<t hangText=" ">
It can support all cases by using the policy table.
</t>
</list>
<t>2. Timing: 3</t>
<list style="hanging">
<t hangText=" ">
All information for communication is in a host in advance.
Communication starts at once when it is necessary and the
communication process refers to local policy information,
so it exhibits good usability. Moreover, this leads to
fewer overheads than per-connection mechanisms.
</t>
</list>
<t>3. Dynamic update: 3</t>
<list style="hanging">
<t hangText=" ">
Though it depends on what protocol is used to
distribute the policies, some mechanisms support information
updates from the server.
Moreover, it is difficult to support dynamic network changes
and real-time updates in some specific protocols.
</t>
</list>
<t>4. Node-specific behavior: 3</t>
<list style="hanging">
<t hangText=" ">
For distribution to individual hosts in the same segment,
DHCPv6 can be used.
</t>
</list>
<t>5. Application-specific behavior: 2</t>
<list style="hanging">
<t hangText=" ">
The policy table itself doesn't support application-specific
address selection. It can be done using the
address selection <xref target="RFC5014">API.</xref>
</t>
</list>
<t>6. Multiple interfaces: 2</t>
<list style="hanging">
<t hangText=" ">
If all interfaces belong to the same administration domain,
it is 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.
</t>
</list>
<t>7. Central control: 3</t>
<list style="hanging">
<t hangText=" ">
It can support central control. A site administrator or a
service provider can determine users' policy tables.
</t>
</list>
<t>8. Route selection: 2</t>
<list style="hanging">
<t hangText=" ">
Current solutions, such as DHCPv6 and RA, do not have
a mechanism for cooperation with routing protocols.
This could be done with other techniques such as
"source address based routing" or
"Default Router Preferences and More-Specific Routes"
<xref target="RFC4191">RFC4191.</xref>
</t>
</list>
</section>
<section title="Other issues">
<list style="hanging">
<t hangText="-">
The traffic volume will be equal to the number of policies.
</t>
<t></t>
<t hangText="-">
Hosts and servers need to support this function.
</t>
</list>
</section>
</section>
<section title="Routing system assistance for address selection (Proactive)"> <!-- 3.2 -->
<section title="Overview">
<t>
Fred Baker proposed this approach. A host asks the DMZ
routers or 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 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 response. He also proposed a mechanism that utilizes
the ICMP error 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.
</t>
</section>
<section title="Requirements correspondence analysis">
<t>1. Effectiveness: 3</t>
<list style="hanging">
<t hangText=" ">
A routing system knows about information about paths toward the
destination and information about which of their
prefixes should be used. Therefore, it is possible to select
an appropriate pair of source and destination addresses.
</t>
</list>
<t>2. Timing: 3</t>
<list style="hanging">
<t hangText=" ">
A routing system always has up-to-date routing information, so it will
be possible to provide suitable information whenever requests
come. However, the amount of information that the system must
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.
</t>
<t>
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.
</t>
</list>
<t>3. Dynamic update: 3</t>
<list style="hanging">
<t hangText=" ">
A routing system always has up-to-date routing information, and it
will be possible to provide suitable information whenever requests
come.
</t>
</list>
<t>4. Node-pecific behavior: 3</t>
<list style="hanging">
<t hangText=" ">
Node-specific information can be provided if a server recognizes
individual nodes.
</t>
</list>
<t>5. Application-specific behavior: 2</t>
<list style="hanging">
<t hangText=" ">
A routing system does not care about applications. Using address
selection API allows nodes to behave in an application-specific way.
</t>
</list>
<t>6. Multiple Interfaces: 2</t>
<list style="hanging">
<t hangText=" ">
If all interfaces belong to the same administration domain,
it is 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.
</t>
</list>
<t>7. Central Control: 3</t>
<list style="hanging">
<t hangText=" ">
It is possible to provide address selection information
from one source. However, because routing information changes
dynamically, it is difficult to control it in the way that
administrators want.
</t>
</list>
<t>8. Route Selection: 3</t>
<list style="hanging">
<t hangText=" ">
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 to implement this function.
</t>
</list>
</section>
<section title="Other issues">
<list style="hanging">
<t hangText="-">
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.
</t>
<t></t>
<t hangText="-">
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.
</t>
</list>
</section>
</section>
<section title="Trial-and-error approach (Reactive)"> <!-- 3.3 -->
<section title="Overview">
<t>
M. Bagnulo proposed a new address selection method in his draft.
When the host notices that a network failure has occurred or
packets have been dropped somewhere in the network by,
for example, an ingress filter, the host changes the source
address of the connection to another source address.
</t>
<t>
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 destination quickly.
</t>
<t>
The host stores a cache of address selection information so that
the host can select an appropriate source address for new connections.
</t>
<t>
For source address selection by the application that initiated a
communication, this method provides an ordered list of source
addresses for the destination address to the application.
</t>
</section>
<section title="Requirement correspondence analysis">
<t>1. Effectiveness: 2</t>
<list style="hanging">
<t hangText=" ">
This solution is not effective for the problem about IPv4 or IPv6
prioritization described in the problem statement document.
</t>
</list>
<t>2. Timing: 2</t>
<list style="hanging">
<t hangText=" ">
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 an error message from a network to detect a
connection error, it takes longer to wait for a time-out.
</t>
</list>
<t>3. Dynamic update: 3</t>
<list style="hanging">
<t hangText=" ">
If hosts detect a connection failure using some reliable
mechanism, such like TCP or ICMP error messages, a connection
failure caused by some changes in the network will be detected
immediately by the hosts.
</t>
</list>
<t>4. Node-specific behavior: 2</t>
<list style="hanging">
<t hangText=" ">
This solution does not have a function for node-specific behavior.
However, it is not impossible to implement by setting
a packet filter for each node at the gateways through which
the packets from nodes pass.
</t>
</list>
<t>5. Application-specific behavior: 2</t>
<list style="hanging">
<t hangText=" ">
This solution does not have a function for application-specific
behavior. However, the mechanism of this approach does not exclude
address selection by each application.
</t>
</list>
<t>6. Multiple interfaces: 3</t>
<list style="hanging">
<t hangText=" ">
If the protocol-stack or an application supports interface selection
and it tries to establish a connection by changing addresses and also
interfaces, it can find a working combination of addresses and interface.
</t>
</list>
<t>7. Central control: 2</t>
<list style="hanging">
<t hangText=" ">
The only way that a central administrator has
to control the node behavior is switching a filter on/off
on the network. Therefore, advanced control such as traffic
engineering and QoS is almost impossible.
</t>
</list>
<t>8. Route Selection: 2</t>
<list style="hanging">
<t hangText=" ">
This solution does not refer to next-hop selection for the
transmission of a packet. So, it should be used with some
routing function such as RFC 4191 on the nodes.
</t>
</list>
</section>
<section title="Other issues">
<list style="hanging">
<t hangText="-">
A host must learn address selection information for each
destination host. Therefore, the number of cache entries could
be very large.
</t>
<t></t>
<t hangText="-">
The existing host/router OS implementation must be changed a
lot. In particular, changing the source address of the existing
connection is not so easy and has a big impact on the existing
TCP/IP protocol stack implementation.
</t>
</list>
</section>
</section>
<section title="All-by-oneself approach (Most Reactive)"> <!-- 3.4 -->
<section title="Overview">
<t>
shim6 was designed for site-multihoming. This mechanism
introduces a new address selection method for session
initiation and session survivability; it is documented
in two drafts:<xref target="I-D.ietf-shim6-locator-pair-selection"></xref> and <xref target="I-D.ietf-shim6-failure-detection"></xref>.
</t>
<t>
The shim6 host detects connection failures and changes the
destination and source addresses during the session.
</t>
<t>
In this document, we focus on address selection issues in the connection
initiation phase of shim6 and not on any other functions,
such as session survivability.
</t>
</section>
<section title="Requirement correspondence analysis">
<t>1. Effectiveness: 2</t>
<list style="hanging">
<t hangText=" ">
This solution is not effective for the problem about IPv4 or IPv6
prioritization described in the problem statement document.
</t>
</list>
<t>2. Timing: 2</t>
<list style="hanging">
<t hangText=" ">
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.
</t>
</list>
<t>3. Dynamic update: 3</t>
<list style="hanging">
<t hangText=" ">
It can reflect dynamically changing network, as far as
it always tries all possible addresses and next-hops.
</t>
</list>
<t>4. Node-specific behavior: 2</t>
<list style="hanging">
<t hangText=" ">
This solution does not have a function for node-specific behavior.
However, it is not impossible to implement by setting a packet
filter for each node on the gateways through which the packets
from nodes pass.
</t>
</list>
<t>5. Application-specific behavior: 2</t>
<list style="hanging">
<t hangText=" ">
The use of shim6 <xref target="I-D.ietf-shim6-multihome-shim-api">API</xref> allows applications to override
address selection behavior.
</t>
</list>
<t>6. Multiple interfaces: 3</t>
<list style="hanging">
<t hangText=" ">
If the protocol-stack supports interface selection
and it tries to establish a connection by changing addresses and also
interfaces, it can find a working combination of addresses and interface.
</t>
</list>
<t>7. Central control: 2</t>
<list style="hanging">
<t hangText=" ">
The only way that a central administrator has
to control the node behavior is switching a filter on/off
on the network. Therefore, advanced control such as traffic
engineering and QoS is almost impossible.
</t>
</list>
<t>8. Route Selection: 2</t>
<list style="hanging">
<t hangText=" ">
This solution does not refer to next-hop selection for
the transmission of a packet. Therefore, it should be used
with some routing function such as RFC 4191 on the nodes.
</t>
</list>
</section>
<section title="Other issues">
<list style="hanging">
<t hangText="-">
The shim6 host performs address selection that reflects network
failures that have occurred between the source and destination host.
</t>
<t></t>
<t hangText="-">
End hosts themselves can avoid network failure.
There is no need to modify or reconfigure routers in the path.
</t>
<t></t>
<t hangText="-">
A host must learn address selection information for each destination
host. Therefore, the number of cache entries can be very large.
</t>
<t></t>
<t hangText="-">
The existing host OS implementation must be changed
significantly.
</t>
</list>
</section>
</section>
</section>
<section title="Applicability Comparison"> <!-- 4 -->
<t>
In the previous section, every approach scored "fair" or
better for every requirement. This means that every approach
can meet the demands of address selection. However, if you
actually want to choose one mechanism to solve your address
selection problem, it is 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.
</t>
<section title="Dynamic-static and managed-unmanaged">
<t>
First, we use two axes to evaluate the applicability of the
four approaches. One axis shows whether or not the network
structure changes dynamically and the other axis shows whether
the site is managed or unmanaged. In a managed network,
by our definition, a network administrator manages his or
her network, routers, and hosts. For example, an enterprise
network is managed, whereas a home network and a SOHO network
are unmanaged.
</t>
<figure>
<artwork>
static dynamic
<-------------------------------------------->
unmanaged ^ +----------+ +---------------------------+
| | | +-+--------------+ shim6 |
| | | | | | |
| | +--+-+-+------------+ | |
| | | | | | | | |
| | | | | | | | |
| | | | | +------------+-+------------+
| | | | | 3484update| |
| | +--+-+--------------+ |
| | | | |
| | | | |
| | Policy | | RouterAssist |
| | Dist | | |
| | | | |
| +----------+ +----------------+
managed v
</artwork>
</figure>
<t>PolicyDist:</t>
<list style="hanging">
<t hangText="-">
In a dynamic site, the policy table must be updated accordingly
and traffic for policy table distribution increases.
</t>
</list>
<t>3484update:</t>
<list style="hanging">
<t hangText="-">
This is a slightly manageable than shim6 in that 3484update does not
change the paths of established connections dynamically.
</t>
<t></t>
<t hangText="-">
In a very dynamic site, the use of an address selection information
cache does not have a good effect. This results in connection
failure and may degrade usability badly.
</t>
<t></t>
<t hangText="-">
Even in a very static site, a host may try inappropriate addresses or
next-hops and experience connection failures.
</t>
</list>
<t>RouterAssist:</t>
<list style="hanging">
<t hangText="-">
A host must send at least as many queries as the number
destination hosts. Therefore, in a static site, this method is
not optimal.
</t>
<t></t>
<t hangText="-">
In a very dynamic site, address selection information cache is no
help. If the cache function is not used, then connection
failures do not occur.
</t>
</list>
<t>shim6:</t>
<list style="hanging">
<t hangText="-">
In a static site, shim6 is not desirable because of its
connection sequence overhead and timeout-wait for path exploration.
</t>
<t></t>
<t hangText="-">
In a managed site, shim6 is not easy to manage in terms of
node-specific address selection control and central control.
</t>
</list>
</section>
<section title="Deployment Difficulty"> <!-- 4.2 -->
<figure>
<artwork>
less more
<------------------------------------------->
policy-dist 3484update shim6 Fred
</artwork>
</figure>
<t>PolicyDist:</t>
<list style="hanging">
<t hangText="-">
What must be implemented is a distribution mechanism.
The existing protocols, such as RA and DHCP, can be used
for this purpose.
</t>
</list>
<t>3484update:</t>
<list style="hanging">
<t hangText="-">
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.
</t>
</list>
<t>RouterAssist:</t>
<list style="hanging">
<t hangText="-">
The protocol stack and applications on a host must be
modified. Furthermore, routers must be modified.
</t>
</list>
<t>shim6:</t>
<list style="hanging">
<t hangText="-">
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.
</t>
</list>
</section>
</section>
<section title="Security Considerations"> <!-- 5 -->
<t>
Incorrect address selection can lead to serious security
problems, such as session hijacking. However, we should note
that address-selection is ultimately decided by nodes and
their users.
There are no means to enforce a specific address-selection
behavior upon every end-host from outside the host.
Therefore, a network administrator must take countermeasures
against unexpected address selection.
</t>
</section>
<section title="IANA Considerations"> <!-- 6 -->
<t>
This document has no actions for IANA.
</t>
</section>
<section title="Conclusions"> <!-- 7 -->
<t>
In this document, we examined solutions to address selection problems
in the IPv6 multi-prefix environment. Although almost all solutions
examined in this document could be applied to any environment and
situation, a solution with a mechanism that is suitable for the
situation should be selected.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc3484;
&ADDRSELPS;
&ADDRSELREQ;
</references>
<references title="Informative References">
&rfc4291;
&rfc4191;
&rfc4192;
&rfc4193;
&rfc3041;
&ADDRSELOPT;
&rfc5014;
&LOCPAIRSEL;
&FAILDETECT;
&SHIMAPI;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:41:52 |