Internet DRAFT - draft-arifumi-multi6-tlc-fm


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


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  The list of Internet-
   Draft Shadow Directories can be accessed at


   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

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

   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


        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

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 |
          +-----------+ +-----------+ +-----------+ +-----------+
            | +-------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

   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

         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

   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-

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
      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

   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

     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

   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

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,

   [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-

   [SLAP]  D. Crocker, ``Shared Locator Address Pool (SLAP) protocol,''
           IETF Multi6 WG Mailing List Archive,

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.

   [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-

   [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

   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

   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

   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

   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

Arifumi                   Expires 31 July 2004                 [Page 18]