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