Internet Engineering Task Force Arifumi Matsumoto
INTERNET DRAFT Kenji Fujikawa
Yasuo Okabe
Masahiro Kozuka
Kyoto University
Youichi Koyama
Trans New Technology
31 Jan 2004
TLC-FM : Transport Layer Common Framework for Multihoming
<draft-arifumi-multi6-tlc-fm-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- Drafts.
Internet-Drafts are draft documents, valid for a maximum of six
months, and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-
Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The existing transport protocols aren't designed to work well on
multi-homed and multi-addressed hosts. TLC-FM is a transport layer
common framework, which stores multihoming related information and
provides common functions and multihoming functions for all the
transport protocols.
In this framework, address information for each remote host and some
routing information for each next-hop is stored and shared by each
transport protocol. Also in this framework, incoming packet's
address fields are re-written from the on-wire address to the
original one that is expected by transport protocols. This is true
for outgoing packets as well.
Arifumi Expires 31 July 2004 [Page 1]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
Address and next-hop evaluation mechanism is included in this
framework, which is mainly dependent on notifications from transport
and even application layers. These are used for switching path
selection and even for next-hop and, thus, source address selection
in connection establishment phase. TLC framework is an enhanced form
of 4.3BSD's pcb(internet protocol control block), and can be easily
implemented without changing each transport layer protocol.
1. Introduction
Multihoming nodes that connected to the global network through
multiple up-stream access-lines are expected to have multiple
addresses given by each ISP. The existing transport
protocols[TCPIP1][TCPIP2], however, is not designed to manipulate
multiple addresses in one connection. When a network outage occurs
and the access-line associated with the local and remote addresses is
down, the connection itself gets lost.
We've worked on an enhanced TCP, we call this TCP-MH[TCPMH], and
we've almost finished on it. It was a TCP specific solution and in
this document we propose more than that. This proposal includes
multihoming support for other transport protocols as well as TCP and
this never involves changes of each transport protocol itself. Note
that this proposal doesn't require any kind of identifiers or any
agent hosts.
This design model is much like MAST[MAST], SIM[SIM] or ODT[ODT] layer
model in that multiple foreign and local address pairs are associated
with one transport session and these addresses are rewritten and then
presented to a transport layer. Moreover this proposal seems to have
a lot in common with SLAP[SLAP] presented by D. Crocker. This
proposal, however, is totally different from these in-between layer
approaches in the way that ours is quite a bit integrated into the
transport layer. In other words, common multihoming features for
transport layer protocols are abstracted into a transport layer
common framework, which we call Transport Layer Common Framework for
Multihoming(TLC-FM), named after TLC's FanMail ;-) Though each
transport session acts independently of other transport sessions,
useful information that can be shared by other transport sessions,
are stored in this common framework.
By taking advantages of enhancing transport layer, we've also
introduced new routing mechanism mainly for multihomed hosts with
multi-link.
2. Proposal Overview
2.1 Protocol Stack and Functionalities
Arifumi Expires 31 July 2004 [Page 2]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
TLC-FM(Transport Layer Common Framework for Multihoming), in short
TLC, is a transport common framework and abstracts multihoming
features for transport protocols. TLC is almost perfectly included
in transport layer and doesn't demand any changes to upper or lower
layer's interface(API). Thus, any existing applications and network
layer protocols can co-exist with TLC.
Though TLC is not much targeted a mobility solution, we believe that
mobility should be gained by using network layer mobile protocol such
as MIP[MIP], MIP6[MIP6] and LIN6[LIN6]. For example, when a host
uses MIP or MIP6 for network mobility and the host also wants to get
multihoming benefits, layer 4 multihoming protocol should exchange
both Home Address(HAddr) and Care of Address(CoA) with its
corresponding nodes. Or it may be useful to have multiple Home
Addresses.
The protocol stack architecture is described in the figure below.
+---------------------------------------+
| Application |
+---------------------------------------+
+-----------+ +-----------+ +-----------+
| TCP | | UDP | | RAW |
| +---------+-+-----------+-+---------+ |
| | TLC-FM | |
| +---------+-+-----------+-+---------+ |
+-----------+ +-----------+ +-----------+
+-------+ +--------+ +-------+ +--------+
| IPv4 | | IPv6 | | MIP(6)| | LIN6 |
+-------+ +--------+ +-------+ +--------+
fig.1 architecture model
The followings are multihoming features included in TLC.
1) Multiple Path Support for One Session
When processing a incoming packet, this resolves mapping from
on-wire local and remote address pair, ``path'' in short, to
local and remote host identifiers, which are held internally and
ephemerally. Multiple addresses can be associated with one
internal identifier. After looking up appropriate transport
session for the packet, address fields are re-written to the
original address and the packet is passed to the transport
control routine.
Sending a packet is simpler, as each transport session holds the
outgoing path and, thus, no looking up for on-wire addresses is
Arifumi Expires 31 July 2004 [Page 3]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
necessary.
Path information is shared by all the transport sessions those
are connecting to the same host.
2) Path Switching
Each transport session can select its own outgoing path without
any dependency on other sessions' path selection as far as the
path still exists. Path switching occurs when more than one
paths for its target host are stored in TLC and when TLC is
ordered to do so from transport or upper layer protocols. These
switchings are expected to cross over any lower layer protocols,
such as IPv4 and IPv6.
3) Selection and Evaluation of Addresses and Next-hops
Precisely speaking, we define ``path'' as a tuple of remote
address , local address and next-hop address. It isn't such
rare situation that more than one next-hops exist that can
deliver packets to a remote address, which is called
``multipath'' in [2991]. This is often the case when you have
two network interfaces for a host.
On a host in which [2991] is implemented there can be multiple
next-hops for one destination address. The moment the next-hop
is determined for a outgoing packet, the outgoing network
interface is also determined at the same time. The source
address for the packet should be one of the addresses that
network interface has considering that ingress filtering[2267]
at the ISP is such probable.
When selecting alternate path for a transport session, it is
such important to select a better path among expectedly a lot of
path candidates in order to circumvent network outages ASAP. We
believe that a statistical manner should be taken to evaluate a
path quality. In compliance with feedbacks from transport and
upper layer protocols, the corresponding path, a tuple of three
elements, gets/loses quality score.
4) Address Domain Functionality
Each host can have multiple address domains, namely multiple
host identifiers. For every host identifier at least one IPv4
or IPv6 address must be assigned. Note that an address must not
be overlapped.
It is a very common operational policy to let an application to
Arifumi Expires 31 July 2004 [Page 4]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
bind not all the local addresses but one or a few addresses for
security reasons or so. By setting up an address domain, you
can realize almost the same operations. You, however, cannot
set an address domain for each application, but you just can
have a domain for all the applications on that host.
2.2 Control Channel
The other part we need is a control channel for end-to-end
negotiation of address information. This information is injected to
TLC via a special socket or by a new system call.
Our control channel's protocol itself is nothing new. We follow
those manners adopted in MAST or SIM proposal. There may be,
however, a little difference from those in that TLC doesn't have any
global unique identifier and just a set of addresses plays a role of
an identifier.
The control channel can be based on any transport protocol. This,
however, should take advantage of TLC and, thus, TCP or UDP seems to
be appropriate for it.
As for when to start control channel, it should be invoked for
relatively long-lived sessions.
Validity check for each informed address should be performed in some
ways. One of the simplest ways might be to depend upon DNS, that is,
to see whether the reverse lookup of a newly notified address and
that of the address used for connection establishment are the same or
not. Or, to depend on a method like return-routablity check in
MobileIPv6[MIP6].
3. TLC Internal
The internal structure of TLC looks like the figure below. In the
upper half of this figure, you see a list of transport sessions'
control blocks. And the lower half is simplified form of TLC.
In this example, a host has three TCP sessions and one connected UDP
session. One of the three TCP session's remote host and one UDP
session's one is the same, which is allocated host id ``100''
internally. The 3rd TCP session is not established and in TCP_LISTEN
state. Here, ``---'' means ``any address'', which is often called
``ADDR_ANY''. Each connected session has its own path which is used
for sending packets.
This host is connected to two routers and ,thus , has two next-hop
gateways for default routes. On the network interface that is
Arifumi Expires 31 July 2004 [Page 5]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
directly connected to gateway gw1, this host has one address: laddr1.
On the other interface, laddr2 and laddr3 are assigned.
+--TCPBLK---+ +--TCPBLK---+ +---TCPBLK--+ +--UDPBLK---+
| TCP #1 | |TCP #2 | |TCP #3 | | UDP #1 |
| ... | | ... | | ... | | ... |
| fhid: 100 | | fhid: 101 | | fhid: --- | | fhid: 100 |
| lhid: 001 | | lhid: 002 | | lhid: 001 | | lhid: 001 |
| path: 2 | | path: 1 | | path: - | | path: 4 |
+-----------+ +-----------+ +-----------+ +-----------+
+---------------------TLC-FM----------------------+
| +-------TLCBLK--------+ +-------TLCBLK--------+ |
| | HostID: 100-001 | | HostID: 101-002 | |
| | 1:faddr1-gw1-laddr1 | | 1:faddr3-gw2-laddr3 | |
| | 2:faddr1-gw2-laddr2 | | 2:faddr4-gw2-laddr3 | |
| | 3:faddr2-gw1-laddr1 | +---------------------+ |
| | 4:faddr2-gw2-laddr2 | |
| +---------------------+ |
+-------------------------------------------------+
fig.2 TLC internal structure
Note that this host is configured to split three local addresses into
two domains. While laddr1 and laddr2 are in the same domain that is
assigned ``001'' as the local host id, laddr3 is in its own domain
and has ``002'' for local host id. So, you can tell TCP #3 is bound
to one of the addresses of address domain ``001'' and waiting for
connections destined for these addresses.
Then, all the possible paths are listed up in figure 2.
As for non-connected transport sessions, like non-connected UDP
socket, there is no big difference with connected ones except that
the fhid(foreign host id) field is kept to be ``---'', ADDR_ANY.
About the lifetime of each TLC control block, called TLCBLK in fig.
2, it can be deleted when it is no longer referred to by any
transport control block, TCPBLK or UDPBLK in fig. 2. Namely it can
be cleaned when no transport session to a target host exists, it may
be useful to keep every TLC control block as long as possible though.
4. Path Selection and Evaluation
4.1 Path Listing
As we've stated above, it is really common for a host to have
multiple network interfaces and, thus, have multiple next-hop
gateways available. The existing transport layer, however, doesn't
Arifumi Expires 31 July 2004 [Page 6]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
assume these situations and cannot manipulate multiple next-hops.
Note that, in most of the operating systems, it is a role of the
transport layer to look-up routing table and, moreover, in many cases
store caches of them, which is called ``routing cache'' or ``route
cache''. This is because routing table has a lot of useful
information that a transport layer protocol wants to know, such as
MTU of a network interface, and caches of them make packet processing
faster.
To fully get benefit from multi-link situation, first of all the
routing table has to be able to store multiple next-hops for one
destination. You'll see KAME[KAME] already has implementation of
parts of the system stated in [2991] and [2992], and that is for both
IPv4 and IPv6 routing system. Next, the transport layer, that
utilizes those routing system, has to support this new routing table
scheme. Especially when thinking about end-to-end multihoming system
and its path switching mechanism, it seems to be such beneficial to
treat a ``path'' not as just a pair of foreign and local addresses
but as a tuple of foreign and local addresses and a next-hop gateway.
Below is an example of listing all the possible paths between two
hosts.
foreign addr#1 -+-> gateway#1 -+-> local addr#1 : path#1
| +-> local addr#2 : path#2
+-> gateway#2 -+-> local addr#3 : path#3
+-> local addr#4 : path#4
+-> local addr#5 : path#5
foreign addr#2 ---> gateway#2 -+-> local addr#3 : path#6
+-> local addr#4 : path#7
+-> local addr#5 : path#8
fig.3 path list based on multipath routing table
In this example, the remote host has two addresses, foreign addr#1
and #2, and this host is directly connected to two routers, gateway#1
and #2. On the interface connected to gateway#1, this host is
assigned local addr#1 and #2. On the interface connected to
gateway#2, this host is assigned local addr#3, #4 and #5.
After the address information exchange through a control channel with
a corresponding host, routing cache for all the addresses should be
calculated. When there is no route to some of addresses notified by
the other node, the address should be dismissed and the host should
send non-acceptable message to the other end. Those routing cache
are stored in TLC control block. Then, path list should be
Arifumi Expires 31 July 2004 [Page 7]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
calculated like the figure above.
4.2 Path Evaluation
Path quality information is as much important thing as address
information that should be shared by every transport session.
Keeping quality information for each foreign address, gateway and
local address seems to be invaluable as well as information for each
tuple of these, on the point that the former information is more
reusable and easy to be shared by other transport sessions.
As for now, we are thinking of a very simple quality evaluation
mechanism. There are two methods for evaluation, that is, good or
bad. These evaluation is based on feedbacks from transport and upper
layer protocols, which is stated in the next section. For a feedback
telling that the path being used right now by a session seems to be
not good, the path's quality point and also each element of the path
is degraded and vice versa for a good feedback. If a bad message is
received, the path for that transport session is switched to the next
best path.
Here are two more likely rules for evaluation mechanism. Newer
feedback should have more points than the older one. And, each
transport session should have same amount of points per a certain
time period or per a path.
5 Interaction with Transport and Upper Layer
As stated in the previous section, we've defined two types of
feedbacks, that is ``good'' and ``bad''. TLC receives feedbacks from
all the connected transport sessions. These arrows in the figure
below stands for feedbacks from upper layer.
+---------------------------------------+
| Application |
+--------------|------------------------+
+-----------+ +|----------+ +-----------+
| TCP | |V UDP | | RAW |
| +-------|-+-+|--------|-+-+--|------+ |
| | V V TLC-FM V V | |
| +---------+-+-----------+-+---------+ |
+-----------+ +-----------+ +-----------+
+-------+ +--------+ +-------+ +--------+
| IPv4 | | IPv6 | | MIP(6)| | LIN6 |
+-------+ +--------+ +-------+ +--------+
fig.4 feedbacks from transport and upper layer
Arifumi Expires 31 July 2004 [Page 8]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
On what condition should each transport layer send a feedback is
protocol dependent. Next comes brief notes on when to send feedbacks
for each protocols.
5.1 TCP
As for TCP's network failure detection, we can follow the manner
adopted in TCP-MH[TCPMH]. That is, several times of
RTOs(retransmission time-out) trigger a path switching. In the same
way, path availability is easily detected in TCP, such as a series of
successful packet reception.
It is, of course, an important feature of multihoming to detect
network failure and to circumvent it by path switching and to revive
existing sessions. However, what's perhaps more important is a
multihoming support for connection establishment. That is to
establish a connection trying as many paths as possible. Though not
so many paths are expected to be available in the connection
establishment phase, it seems to be indispensable to try all the
next-hops and local addresses especially for multi-linked and
multihomed hosts.
Therefore, a path-switch trigger should be implemented also in
retransmission procedure of TCP SYN_SENT state and TCP initial SYN
packets are should be retransmitted on as many paths as possible.
5.2 UDP
UDP itself isn't a reliable data transfer protocol and, thus, its
really difficult to detect network failures in this part of the
protocol stack. About a non-connected UDP session, it doesn't have
any concept of a connection or a path. A connected UDP session is
different from non-connected one in that the foreign address of the
session is specified by connect() system call and it has a concept of
a path.
Then, what can we use as a path-switch trigger for a connected UDP
session ? Although there might be no standard way of doing this, we
propose likely candidates for UDP session failure detection methods
in the list below.
1) ICMP Destination Unreachable Message[792][2463]
There are some types in ICMP Destination Unreachable Message.
Among those, ICMP Port Unreachable message is usually generated by
the destination host of a UDP session, or by a filtering router.
If a host doesn't have any UDP sockets waiting packets for that
UDP port, the host usually sends back ICMP Port Unreachable
Arifumi Expires 31 July 2004 [Page 9]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
Message destined for the source address of the incoming packet.
These behaviors are specified in [1812] for IPv4, and in
[2460][2463] for IPv6.
ICMP Host Unreachable and ICMP Network Unreachable are generated
by routers that don't have a route for the destination address of
a incoming packet. What is important here is that this situation
is often caused by a link outage between intermediate routers.
Though it is a bit hard to imagine an ICMP Port Unreachable
message is generated because of intermediate network failure, it
is very likely to happen especially for the first several packets
after a path switching. When an address notified by a
corresponding node is not correct or it is an IPv4 private address
or IPv6 not global address, a packet on a new path will be perhaps
delivered not to intended host.
We have to note that these ICMP error messages have special
meanings for some applications, such as ``end of a session'', and
we have to keep delivering these messages to application layer.
Anyway, we can probably utilize these messages as path-switching
triggers.
2) ICMP Time Exceeded Message[792][2463]
This kind of message is usually generated by routers when it finds
the time to live field of processing datagram is zero. The
datagram is discarded and ICMP Time Exceeded message is sent back
to the sender of the datagram.
This situation is also often caused when a network outage is
occurred at a intermediate router and the router lost a relevant
route for the destination. This error message seems to be a good
trigger for path switching.
As you see in RFCs, these error messages are not specific for UDP
datagrams, so of course we can use these failure detection methods
for TCP sessions as well.
Listed above are for ``bad'' evaluation. As for ``good'' evaluation,
receiving some amounts of packets on a connected UDP session simply
seems to serve it.
Though these methods seem to be effective for UDP connections, unlike
TCP, all the UDP connection failures cannot be detected by these
means. There are many cases that none of these ICMP error messages
are sent back because of filtering at routers or so. The most
Arifumi Expires 31 July 2004 [Page 10]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
effective way of making UDP connection successful could be to select
the most appropriate path for the initial packet. Or to leave the
role of trigger to applications, which is mentioned in the next sub-
section.
5.3 RAW
Even a raw socket, only if it is connected, can get benefit from
multihoming. Just as well as UDP, ICMP Protocol Unreachable message
is expected to be returned when there is a network outage. When it
comes to relatively long-lived raw session, you can give a few
examples such as PPTP(GRE).
5.4 Application
As stated in the previous sub-section, UDP connection failures cannot
always be detected in the layer of UDP alone. The best place to
detect them is an application layer. For an application to send
feedbacks to lower layers, a new API is necessary.
We don't need such a functional API set as [MHAPI], but just two
functions for ``good evaluation'' and ``bad evaluation'' will
suffice. These can be easily implemented by adding some options to
the existing function for setting socket option, such as setsockopt()
on 4.4BSD.
6. Implementation Notes
For 4.X BSD based operating system, TLC can be relatively easily
implemented as an enhancement for Internet Protocol Control Block,
INPCB for short. INPCB should be regarded as a transport layer
common framework, and by adding or changing some features of it, we
can have almost everything that we want for TLC.
7. Discussion about Architecture
First of all, the definition of a layer in OSI reference model is,
"a Layer (N) entity provides services to higher Layer (N+1)
entities and relies on the services provided by the Layer (N-1)
and below entities supporting it.
A Layer (N) entity requests services of a local Layer (N-1) entity
via primitives directed at a Layer (N-1) service access point
(SAP).
If the primitives are explicitly implemented, they can be thought
of as function calls."
For example, TCP layer calls network layer's API(primitives), such as
Arifumi Expires 31 July 2004 [Page 11]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
ip_output() when using the data transfer service of network layer,
and never calls data-Link Layer or physical layer's API, such as
ether_output(). So, it is clear that TCP layer is on network layer.
When it comes to TLC, it modifies a transport layer's function which
is used to associate a datagram with a corresponding transport
session. Address field re-write function is called from transport
layer. Path evaluation function is called from transport layer. And
it doesn't have any direct interaction with IP or other layer.
Therefore, we can define TLC is a internal framework of transport
layer.
If you say "Layer 3.5", it calls network and transport layer's API,
provides API for them and never has direct interactions with network
or transport layer's internal functions. So, it just intercepts
primitives between these layers, and relays datagrams like this,
input: ip_input() -> mh_input() -> tcp_input()
output: ip_output() <- mh_output() <- tcp_output()
and does some processing like address re-writing, multiple on-wire
addressed to one address that transport layer holds, in these
functions. However, to which address should a datagram be re-written
? These mapping information are essentially stored in transport
layer, and, thus, these information have to be kept *also* in this
in-between layer. Resolving association of a datagram with a
transport session *twice* is really inefficient. (If you have a
global unique identifier in an address like LIN6, the middle layer
doesn't have difficulty in this association, though.)
What is worse is that transport specific fields, such as TCP/UDP
checksum, has to be taken care in this place when you re-write
address fields.
Below is a summary of these basic features of L4 and L3.5 solutions.
Layer 3.5 Solution
o No global unique host identifier is necessary.
o There is almost no need to modify L3 and L4 protocols and
implementations by converting on-wire addresses into some kind of
host identifier.
o It is necessary to modify DNS resolver library and API to lookup
local addresses.
When an application does bind() one of local host address or does
connect() to a remote address, the address has to be the one that
Arifumi Expires 31 July 2004 [Page 12]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
is converted to L3.5 internal address in order not to make an
inconsistency between L3.5 and L4 address and port bindings.
o Overhead of processing headers. A datagram to a transport
session mapping happens twice for each packet.
For each incoming packet, L3.5 needs to resolve datagram to
session mapping so that on-wire addresses can be re-written to
internal id, which also happens in transport layer after that.
o Besides address fields, transport specific fields, like a
checksum, has to be re-calculated in L3.5.
o There is no good way of knowing when to erase mapping information
for each remote host.
Layer 4 Solution
o No global unique host identifier is necessary.
o Needs to modify L4 implementations but does not need to modify L3
at all, L4 protocol itself or DNS resolver library.
o Minimum overhead of processing headers.
o No special attention is necessary for checksum processing and no
overhead involved.
o Can get benefit of failure detections at L4. And by making each
transport entity "path aware", it will be more secure and robust
in that each transport session can have its own path
independently.
o Can store path quality information because of feedback
information directly given by each transport entity.
o Can interact with multipath routing smoothly. This is because,
basically, it is a role of L4 to make use of routing information.
As stated above, L4 based solution has a lot of benefits over L3.5
based one. L4 based one has more flexibility and expandability. To
gain these functionalities, new interaction methods with L4 will be
necessary. If you modify transport layer, it is rather easy to have
these integrated, as the core feature of the middle layer is already
there. This is what TLC-FM is based on in its design.
Arifumi Expires 31 July 2004 [Page 13]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
8. Security Considerations
A lot of the issues we have to consider should be dependent on what
kind of control channel is adopted. A redirection attack and a
session hijack are mainly matters of address information exchange
methods.
One thing that is essential to TLC is transport protocols' checksum
calculation. However, this is not an issue for TLC at all, mainly
owing to its integration with the transport layer. As for a incoming
packet, each transport protocol validates checksum of the packet, and
then associates the packet with a corresponding transport session.
So, all we have to do is to put the address conversion routine just
before the association lookup. Sending a packet is just in reverse
order, that is, addresses on a datagram should be re-written just
before the checksum calculation.
As another threat essential to this proposal, we should think about
ICMP Error Message attack. If those methods described in section 5.2
are adopted, the third person will be able to force a transport
session to trigger path switching. However, an attacker has to know
the source and destination addresses and port numbers of a session.
As a MITM can abort any existing transport sessions even today and
this path switching mechanism itself doesn't solicit session hijack,
this kind of attack seems not to have serious impacts so far.
APPENDIX A. Considerations on RFC 3582
In this section, assessment how much this protocol meets the
requirements described in RFC 3582[3582].
3. Multihoming Goals
3.1 Capabilities of IPv4 multihoming
3.1.1 Redundancy
For a reliable data transport protocol like TCP, path switching is
always invoked when necessary and , thus, redundancy is assured.
However, path redundancy is not always available for UDP sessions.
For UDP sessions, application layer support for path switching is
necessary to achieve more redundancy.
3.1.2 Load Sharing
Each session on a host can select outgoing and incoming routes.
So, session based load sharing support is available.
Arifumi Expires 31 July 2004 [Page 14]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
3.1.3 Performance
When there is a bottle neck at one of the up-stream ISPs, less and
less transport sessions will select to use the ISP automatically
owing to network failure detections.
3.1.4 Policy
Path selection policy can be implemented at each host. However,
it is difficult for a site manager to impose a port-based policy,
such as NNTP service should use ISP A, to all the hosts within the
site at one time. All you can have is host-based policy, such as
host A can use ISP A or so.
3.1.5 Simplicity
There is no complexity for site management.
3.1.6 Transport-Layer Survivability
Same as Redundancy section.
3.1.7 Impact on DNS
No impact.
3.1.8 Packet Filtering
No impact.
3.2. Additional requirements
3.2.1 Scalability
This proposal makes the burden on routers decentralized to each
end node, so it is really scalable.
3.2.2 Impact on Routers
Basically no impacts. However, routers are expected to generate
ICMP error messages proposed in RFCs[1812][2463] when they
encounter network outages. These help each transport protocol to
detect failures.
3.2.3 Impact on Hosts
Though every host should implement this proposal for benefit of
multihomed hosts, it is still possible for new hosts to
Arifumi Expires 31 July 2004 [Page 15]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
communicate with legacy hosts.
3.2.4 Interaction between Hosts and the Routing System
No need for new interaction mechanism.
3.2.5 Operations and Management
No impact.
3.2.6 Cooperation between Transit Providers
No need for cooperation.
3.2.7 Multiple Solutions
As this proposal is basically a modification of transport layer,
it can co-exist with any other solutions based on other part of
layers.
APPENDIX B. References
[TCPIP1] W. Stevens, ``TCP/IP Illustrated, volume 1,'' 1994.
[TCPIP2] G. Wright and W. Stevens, ``TCP/IP Illustrated, volume 2,''
March 1996. [793] J. Postel, ``Transmission Control
Protocol,'' RFC 793, IETF Sep 1981.
[TCPMH] A. Matsumoto, M. Kozuka, K. Fujikawa, Y. Okabe, ``TCP Multi-
Home Options,'' Internet-draft (work in progress), Oct 2003,
draft-arifumi-tcp-mh-00.txt.
[MAST] D. Crocker, ``Multiple Address Service For Transport (MAST):
An Extended Proposal,'' Internet-draft (work in progress),
Sep 2003, draft-crocker-mast-proposal-01.txt.
[SIM] Erik Nordmark, ``Strong Identity Multihoming using 128 bit
Identifiers (SIM/CBID128),'' Internet-draft (work in
progress), Oct 2003, draft-nordmark-multi6-sim-01.txt.
[ODT] I. van Beijnum, ``On Demand Tunneling For Multihoming,''
Internet-draft (work in progress), Jan 2004, draft-van-
beijnum-multi6-odt-00.txt.
[SLAP] D. Crocker, ``Shared Locator Address Pool (SLAP) protocol,''
IETF Multi6 WG Mailing List Archive,
http://ops.ietf.org/lists/multi6/multi6.2003/msg02028.html
Arifumi Expires 31 July 2004 [Page 16]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
[2991] D. Thaler, C. Hopps, ``Multipath Issues in Unicast and
Multicast Next-Hop Selection,'' RFC 2991, Nov 2000
[2992] C. Hopps, ``Analysis of an Equal-Cost Multi-Path Algorithm,''
RFC 2992, Nov 2000
[2267] P. Ferguson, D. Senie, ``Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing,'' RFC 2267, Jan 1998
[MIP] C. Perkins, ``IP Mobility Support,'' RFC 2002, Oct 1996
[MIP6] D. Johnson, C. Perkins, J. Arkko, ``Mobility Support in
IPv6,'' Jun 2003, draft-ietf-mobileip-ipv6-24.txt.
[LIN6] F. Teraoka, M. Ishiyama, M. Kunishi, ``LIN6: A Solution to
Mobility and Multi-Homing in IPv6,'' Internet-draft (work in
progress), Jun 2003 draft-teraoka-ipng-lin6-02.txt.
[KAME] KAME Project is a joint effort to create single solid
software set, especially targeted at IPv6/IPsec.
http://www.kame.net/
[1812] F. Baker, ``Requirements for IP Version 4 Routers,'' RFC
1812, Jun 1995.
[2460] S. Deering, R. Hinden, ``Internet Protocol, Version 6 (IPv6)
Specification,'' RFC 2460, Dec 1998.
[792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, Sep 1981.
[2463] A. Conta, S. Deering, ``Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6)
Specification,'' RFC 2463, Dec 1998.
[MHAPI] A. Matsumoto, K. Fujikawa, Y. Okabe, ``Basic Socket API
Extensions for LIN6 End-to-End Multihoming,'' Internet-draft
(work in progress), Jun 2003 draft-arifumi-lin6-multihome-
api-00.txt.
[OSI] Mark Taylor, William Waung, Mohsen Banan, ``Internetwork
Mobility: The CDPD Approach Published September,''
Preliminaries Section, 1996 Prentice Hall Professional
Technical Reference ISBN 0-13-209693-5
[3582] J. Abley, B. Black, V. Gill, ``Goals for IPv6 Site-
Multihoming Architectures,'' RFC 3582, Aug 2003.
Arifumi Expires 31 July 2004 [Page 17]
draft-arifumi-multi6-tlc-fm-00.txt 30 Jan 2004
APPENDIX C. Authors' Addresses
Arifumi Matsumoto
Graduate School of Informatics
Kyoto University
Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN
Tel: +81 75-753-7468
Fax: +81 75-753-7472
Email: a@arifumi.net
Kenji Fujikawa
Graduate School of Informatics
Kyoto University
Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN
Tel: +81 75-753-5387
Fax: +81 75-753-4961
Email: fujikawa@real-internet.org
Yasuo Okabe
Academic Center for Computing and Media Studies
Kyoto University
Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN
Tel: +81 75-753-7458
Fax: +81 75-751-0482
Email: okabe@i.kyoto-u.ac.jp
Masahiro Kozuka
Faculty of Law, Kyoto University
Yoshida-Honmachi, Sakyo-ku, Kyoto 606-8501 JAPAN
Tel: +81 75-753-7468
Fax: +81 75-753-7472
Email: ma-kun@kozuka.jp
Youichi Koyama
Trans New Technology, Inc.
Inohara BLDG. 2F, 72 Tanaka Monzencho, Sakyo,
Kyoto 606-8225 JAPAN
Tel: +81-75-706-9800
Fax: +81-75-706-9801
Email: koyama-y@trans-nt.com
Arifumi Expires 31 July 2004 [Page 18]