idnits 2.17.1 draft-huitema-multi-homed-01.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Missing revision: the document name given in the document, 'draft-huitema-multi-homed-0', does not give the document revision number ~~ Missing draftname component: the document name given in the document, 'draft-huitema-multi-homed-0', does not seem to contain all the document name components required ('draft' prefix, document source, document name, and revision) -- see https://www.ietf.org/id-info/guidelines#naming for more information. == Mismatching filename: the document gives the document name as 'draft-huitema-multi-homed-0', but the file name used is 'draft-huitema-multi-homed-01' ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 1119 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 12 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (May 1995) is 10568 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 12 errors (**), 1 flaw (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group C. Huitema 3 Internet Draft INRIA 5 Expiration Date: November 1995 May 1995 7 Multi-homed TCP 9 C. Huitema 11 Christian.Huitema@sophia.inria.fr 13 draft-huitema-multi-homed-0.txt 15 1. Status of this Memo 17 This document is an Internet-Draft. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, and 21 its working groups. Note that other groups may also distribute working 23 documents as Internet- Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet- Drafts as reference material 31 or to cite them other than as ``work in progress.'' 33 To learn the current status of any Internet-Draft, please check the 35 ``1id-abstracts.txt'' listing contained in the Internet- Drafts Shadow 37 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 39 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 41 ftp.isi.edu (US West Coast). 43 2. Abstract 45 Current TCP connections are identified by pairs of host addresses and 47 port numbers. This introduces a "fate sharing" dependency between the 49 connection and these values, and specially with the time to live of the 51 host addresses. There are at least three cases where this dependency is 53 unduly harmful: 55 (1) when the host moves to a new location and is assigned a 57 new address, 59 (2) when the interface used by a multi-homed host to initiate 61 the connection is temporarily disconnected, 63 (3) when the host's network is renumbered, e.g. after 65 changing provider. 67 We propose to remove this fate sharing effect by allowing the set of 69 addresses used by a TCP connection to change over time. We modify TCP 71 defining a new type of parameter, PCB-ID, to be used during the initial 73 synchronisation. This parameter identifies the "Protocol Control Block" 75 associated to the TCP connection. When initiating a connection, the host 77 attach to the SYN packet the identifier of the local PCB. If both hosts 79 have identified their local PCB, they can now exchange "Extented TCP" 81 packets, where the pair of 16-bit port numbers has been replaced by the 83 32-bit PCB-ID at the destination. This way, PCB location becomes 85 independent of the IP addresses. The addresses in use can be stored in 87 this PCB, so that we can change these in the course of the connection. 89 In fact, we can use several addresses in parallel for the same 91 connection, which is why our proposal is called "multi-homed TCP". 93 3. Proposed extensions to TCP 95 Our proposal requires two extensions to TCP: the definition of a context 97 parameter during the synchronization exchange and the carrying of this 99 parameter in the data packets. 101 3.1. The context identification parameter 103 When a TCP entity initiates a new connection, it can announce its 105 willingness to receive data from alternate addresses by including a "PCB 107 identification" parameter in the initial "synchronization" packet. This 109 parameter has the following format: 111 +----------+----------+-----------+----------+-----------+----------+ 113 |Kind=PCBID| Length=6 | 32-bit Protocol Control Block Identifier | 115 +----------+----------+-----------+----------+-----------+----------+ 117 This option is a unilateral offer, not subject to negotiation. It allows 119 the partner to send data from an alternate source address, if indeed the 121 "local contex id" is somehow repeated in the new packets. The context-id 123 is normally the identification of a "protocol control block"; however, 125 the precise format and bits carried in this parameter are entirely a 127 local matter. The only condition is one on reuse: in order to avoid 129 protocol errors due to old packets popping out of the network, the 131 context-id used by one connection cannot be reused immediately. One must 133 wait for the end of the "TIME- WAIT" state. 135 The parameter kind PCBID is to be allocated by the IANA. 137 This parameter can only be present in TCP packets where the SYN bit is 139 set. 141 3.2. Incoming data 143 An entity that has learned the PCB identification of its partner can 145 elect to send "Extended TCP" packets. The difference between extended 147 TCP and regular TCP packets are that: 149 - the IP protocol type is (a value to be defined by IANA), not 7 (TCP). 151 - the IP source and destination addresses may be different from the ones 153 use in the SYN packet. 155 - the first 32 bits of the ETCP header carry a protocol control block 157 identification, not a pair of ports. 159 The extended TCP packets have a format identical to normal TCP packets, 161 except for the replacement of the port pair by a context identification: 163 0 1 2 3 165 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | protocol control block identification | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Sequence Number | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Acknowledgment Number | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Data | |U|A|P|R|S|F| | 183 | Offset| Reserved |R|C|S|S|Y|I| Window | 185 | | |G|K|H|T|N|N| | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Checksum | Urgent Pointer | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Options | Padding | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | data | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 0 1 2 3 203 ETCP Header Format 205 ETCP packets are delivered to an ETCP incoming process, which merely 207 looks at the context identification and finds the corresponding PCB. All 209 packets arriving on the PCB identified by the context XB are treated 211 exactly as if they had been sent by host A to host B, using the TCP 213 ports "a" and "b", i.e. the ports present in the TCP packet. 215 3.3. Extended checksum rules 217 The checksum of ETCP packets is computed over the pseudo-header and the 219 packet itself. The pseudo header is composed of the IP addresses 221 actually present in the packet. 223 3.4. PCB extension 225 The protocol control block of TCB is extended to include a list of 227 partners addresses. This list is initialized with the partner address 229 expressed in the connection request. It is populated with the source 231 addresses from which ETCP packets bound to that PCB are received. Two 233 dates are associated to each address, "first seen" and "last seen", i.e. 235 the date at which a packet was received from this address the first 237 time, and then the last time. 239 The list is sorted by reverse order of "last seen" packets, i.e. most 241 recently seen first. TCP entities should normally send their packets to 243 the most recently seen address. They may elect to spread them over all 245 of the "currently active" addresses, i.e. all addresses whose "last 247 seen" date is larger than the "first seen" date of the most recently 249 seen address. 251 4. Finding addresses 253 The TCP "protocol control block" will be extended to contain a list of 255 IP addresses of the source entity. These addresses are obtained by 257 monitoring the IP source addresses of the ETCP packets. 259 In this section, we will see the address reassignent at use in four 261 cases, deprecation, anycasting, multi-homing and mobility. 263 4.1. Deprecation 265 The address autoconfiguration and neighbor discovery procedures of IPv6 267 allows hosts to renumber their interface. This is supposed to occur in 269 three phases: 271 1) Initially, the interface of host A is numbered with the address A1, 273 2) After reception of a router advertisement message, the host A decide 275 that the preferred address of the interface is now A2. Packets sent to 277 the deprecated address A1 can still be received for some period. 279 3) At the end of that period, the address A1 is invalidated. Packets 281 sent to it are discarded by the network. 283 Let's discuss first the behaviour of the host A, which is engaged in a 285 TCP connection with the host B, using ports a and b and PCB identifiers 287 xa and xb, respectively. Initially, packets will be exchanged using the 289 addresses A1 and B1. 291 (A1, B1, tcp) (a, b, SYN, PCBID=xa) ===========> 293 <============ (B1, A1, etcp) (xa, SYN, ACK, PCBID=xb) 295 (A1, B1, etcp) (xb, ACK, DATA) ===========> 297 <============ (B1, A1, etcp) (xa, ACK) 299 As soon as the address A1 becomes deprecated, A will stop using it. The 301 next data or acknowledgement packets will be sent from the preferred 303 source address A2: 305 (A2, B1, etcp) (xb, DATA) ===========> 307 <============ (B1, A1, etcp) (xa, DATA) 309 (A2, B1, etcp) (xb, ACK, DATA) ===========> 311 <============ (B1, A2, etcp) (xa, ACK) 313 The address change is noted by B because upon reception in context "xb" 315 of a packet from the new address A2. At this stage, B switches to the 317 new address. Due to the propagation delay, some packets sent to the old 319 address may still be in transit at this point. This will last for at 321 most twice the maximum propagation delay. We may then ensure that no 323 packets will be lost if the old address remains valid for at least twice 325 that delay, e.g. more than four minutes. 327 4.2. Anycasting 329 In order to use IPv6's anycasting facility, we should be able to send 331 the initial SYN packet to an anycast address. Such connection requests 333 are doomed in today's TCP, because anycast addresses cannot be used as 335 source addresses. ETCP solves the problem rather elegantly. Suppose that 337 the packet sent by the host A to the anycast address X is actually 339 routed to the nearest server for that anycast address, B, through its 341 interface B1. 343 (A1, X, tcp) (a, b, SYN, PCBID=xa) ===========> 345 <============ (B1, A1, etcp) (xa, SYN, ACK, PCBID=xb) 347 (A1, B1, etcp) (xb, ACK, DATA) ===========> 349 <============ (B1, A1, etcp) (xa, ACK) 351 Because B knows the PCB identifier "xa", it can sent an ETCP packet back 353 towards A, using the regular address B1 as source address, advertizing 355 its own PCB identifier. A notes the source address B1 in its PCB, and 357 the following packets are happily exchanged between A1 and B1. 359 The solution can in fact be extended to other variations of anycasting, 361 e.g. when the initial packet is sent to a multicast group. The only 363 difference here is that several response will come, e.g. from B and C, 365 two members of the group which both decided to reply to A. 367 (A1, G, tcp) (a, b, SYN, PCBID=xa) ===========> 369 <============ (B1, A1, etcp) (xa, SYN, ACK, PCBID=xb) 371 (A1, B1, etcp) (xb, ACK, DATA) ===========> 373 <============ (C1, A1, etcp) (xa, SYN, ACK, 375 PCBID=xc) 377 (A1, C1, etcp) (xc, RST) ===========> 379 (A1, B1, etcp) (xb, DATA) ===========> 381 Upon reception of the synchronisation packet from C, A realizes that 383 this packet is a duplicate SYN, that the PCB identifier is different 385 from the one advertized by B. It will refuse to consider the packet's 387 informations, and immediately send a "reset" to C, clearing the 389 additional connection. 391 In the rare case where the binary values of xb and xc would be 393 identical, A should simply discard the additional asynchronisation 395 packet. It must not add the corresponding source address to its PCB. 397 4.3. Multi-homing 399 Suppose that the host A is equipped with two interfaces, A1 and A2. It 401 may decide to spread the traffic over these two interfaces, sending 403 packets alternatively from sources A1 and A2. B, in turn, will send 405 packets alternatively towards each of these addresses: 407 (A1, B1, tcp) (a, b, SYN, PCBID=xa) ===========> 409 <============ (B1, A1, etcp) (xa, SYN, ACK, PCBID=xb) 411 (A1, B1, etcp) (xb, ACK, DATA) ===========> 413 <============ (B1, A1, etcp) (xa, ACK) 415 (A2, B1, etcp) (xb, ACK, DATA) ===========> 417 <============ (B1, A2, etcp) (xa, DATA) 419 (A1, B1, etcp) (xb, ACK, DATA) ===========> 421 <============ (B1, A1, etcp) (xa, ACK) 423 This is possible because B keeps in the PCB identified by "xb" a list of 425 partners addresses. Both addresses will in turn be the "most recently 427 seen" address. 429 4.4. Mobility 431 Mobility is treated by exactly the same mechanisms as those of 433 "renumbering" which we expressed in 4.1. There are however two problems, 435 fast movements and double jumps. There are few good solutions to the 437 "fast movement" problems. If a host gets a new address each fraction of 439 a second, there is just no way that a mechanism that exchange 441 information with communicating hosts through the whole internet will 443 keep pace. Proposed solutions involve home base and tunnelling. They 445 amount to saying that the mobile host is dual homed. It has a "mobile 447 address", which changes when the host roams, and a "home address", which 449 remains relatively static. When the host moves very fast, it should only 451 use its home address. When the host moves slowly, it can start using the 453 "mobile address" for more efficiency. 455 The double jump problem occurs when two mobile hosts change cells 457 simultaneously. In this case, we are in a situation were neither of the 459 previous addresses is usable. A cannot tell B that its address changed 461 from A1 to A2, because the packets bound to B1 don't make it to B, and 463 vice versa. 465 The only solution here is to request that mobile host maintain a stable 467 home address, e.g. A0 for A and B0 for B. They will "refresh" the 469 address list of their partners by regularly sending messages from these 471 addresses. In the double jump situations, the deadlock will be broken if 473 either A or B manages to get a packet to the home addresses A0 or B0. 475 5. Security considerations 477 The procedure that we propose introduces a significant security hole. If 479 a third party can obtain the "context-id" used by the TCP connection, 481 then it can send TCP packets using a bogus source address and trick the 483 TCP entity into believing that this is the new address of its partner: 485 it can, in short, "grab the connection". In the current Internet, such 487 connection grabbings require that one somehow subvert the routing 489 protocol, which is more difficult than simply listening to traffic and 491 forging packets. This threat is in fact inherent to the mobility 493 environment which we are willing to accomodate: we have the choice of 495 accepting this mode of operation or implementing a secure version of 497 TCP. 499 Implementing a secure version of TCP may be a good idea in any case, as 501 TCP is currently vulnerable to several forms of attacks: as long as the 503 origin of the packet is not securely authenticated, it is easy for 505 intruders to send forged TCP messages and distort the state of an 507 existing connection. We may be willing to use "IP security" to that 509 effect, wrapping the TCP packets inside an "IP secure" payload: 511 +-----------+-------------------------------+ 513 | | IP +-------------------+| 515 | IP header | security | TCP header + data || 517 | | header +-------------------+| 519 +-----------+-------------------------------+ 521 The IP security header identifies a "security context", to which a key 523 is attached, as well as the type of protection. Once a security context 525 has been established, we obtain a proof of the source Internet address, 527 as well as in some cases an integrity check, an confidentiality, i.e. 529 protection against eavesdropping. How secure IP contexts are established 531 is outside the scope of these memo. 533 If such protections are available, then our procedure becomes entirely 535 acceptable. In fact, we can define three mode of operations: 537 (1) Secure mode, into which only those packets which were 539 transmitted securely can be considered by TCP, 541 (2) Protected mode, into which packets are requested to come 543 either from a well identified address or through a secure channel, 545 (3) Unprotected mode, for users who are willing to take chances. 547 The second mode of operation protects us against the specific threats 549 brought in by mobility, without imposing the performance penalties of 551 cryptography on each and every packet. 553 We should note that it is theoretically feasible to associate security 555 parameters to the TCP connection, in much the same way that they are 557 associated to a pair of IP hosts. This would solve the TCP problem 559 entirely, making our connection very secure. But this is clearly a point 561 of debate. 563 8. Acknowledgements and related works 565 Many of the features of this proposal were discussed privately with 567 Lixia Zhang, John Wroclavski, Van Jacobson and Greg Minshall. I received 569 comments from Allison Mankin on a previous version of this proposal. The 571 support of multiple addresses bears some similarities with the 573 "transport context names" proposal of Dave Crocker. 575 Various authors, notably Steve Deering, have proposed an alternative 577 "context identification" mechanism based on "volatile port numbers": a 579 specific port is assigned to each connexion within the SYN exchange, 581 which is essentially equivalent to our 'context identifier". The scheme 583 that we propose here has the advantage of using larger identifiers: 16 585 bits does not necessarily allow enough contexts. It also has the 587 advantage of being entirely backward compatible (an additional TCP 589 parameter can be ignored) and of being explicit: alternative addresses 591 can only be used if the peer provided a context identifier. 593 Appendix A. Relation with other proposals. 595 Letting TCP connections survive a change of addresses is not a new 597 problem. 599 Partial solutions have been proposed, which essentially insert a 601 "permanent identifier" layer between the transport control and the 603 routing process. Instead of identifying the transport contexts by a pair 605 of source and destination addresses, one would use this "more permanent" 607 identifiers, often called "end point identifiers" or EID. The addresses 609 may change but the EID will remain constant. In the "classic" version of 611 the EID proposal, these identifiers will be present in each and every 613 packet, in addition to the addresses. Several implementations have been 615 proposed, e.g. as innovative IPng formats. Including EIDs in the IP or 617 IPng header itself has been ruled out during the debates, but one could 619 design an intermediate layer between IP and TCP that would carry those 621 headers. The proposal, however, suffers from three drawbacks: 623 (1) As EID are likely to have the same size than the IPng 625 addresses, we are considering a sizeable overhead. 627 (2) EID don't exist yet. Creating yet another address space 629 would implies significant administration efforts. 631 (3) Disconnecting identification and routing removes whatever 633 security there is in the current IP protocol. 635 The early SIP and SIPP proposals included a scheme that would alleviate 637 the first concern and eliminate the second one. Instead of creating a 639 new numbering space for EIDs, one would simply specialize one address, 641 e.g. the one that was used for sending the initial synchronization 643 packet of TCP. Most connections will simply go on using that address for 645 their whole duration. If the host moves, or if a new provider is 647 selected, the old address will be still be used as nominal source or 649 destination address, but the packet would be explicitly source routed 651 through the new address. This solution however suffers from the same 653 security problems as the generic EID proposal, and does not entirely 655 cure the "change of provider" problem. If the local network is 657 renumbered, the old addresses ceases to be valid. 659 In fact, that argument applies to all approaches based on "permanent 661 identifiers": we are exchanging a dependency on the IP address for a 663 dependency on these new identifiers. Proponents of the EID approaches 665 are ready to swear on their most sacred books, or on the head of their 667 favorite dog, that these new numbers will remain valid, unique and 669 stable for eternity. We may note however that there is not a single 671 human construct that ever met this requirement. The case is even more 673 obvious if we focus on network history, where exceptions to the unicity 675 and stability rules have been found for all proposed "unique numbers" 677 that were considered, be they IP addresses, which get renumbered, domain 679 names, which change from time to time, or IEEE-802 "MAC addresses", 681 which can easily be misconfigured. 683 Rather than yet another gigantic administrative effort, our solution 685 involves only locally asserted numbers, the PCB identifiers. 687 3. Why TCP 689 Our solution focuses on TCP. One may well object that TCP is not the 691 only protocol used over the Internet, that the fate- sharing also occurs 693 with other transport protocols, notably over UDP. However, a quick 695 analysis shows that "user 697 controlled" applications, that use the user datagram protocol, are much 699 less sensitive than those application which relie on the services of a 701 transport layer. This is notably the case of "client server" and "real 703 time" application; this is also the case of "secure" applications. 705 The most popular building block for "client server" applications is the 707 "stateless RPC". In this model, a client simply sends a request to the 709 server, generally a single UDP datagram. Upon reception of this request, 711 the server executes the required actions and sends back a reply, in most 713 cases a single UDP datagram. No "context" is kept by the server, and the 715 time-span of the transaction is generally quite short, which minimizes 717 the risk of observing a move in the middle of a transaction. At worst, 719 if such a transistion occurs, the client may repeat its request. Indeed, 721 if the server moves, the client will have to find its new location, its 723 new address. But that has to be solved by updating the routing process 725 or the name service; it is not a "transport control" problem. It is true 727 that client-server applications may have to maintain long term 729 associations. But they generally do so by identifying "application level 731 contexts", which are identified by the users and servers names: 733 authentication and access controls ought to be based on user names, not 735 on hardware addresses. 737 Real time applications also use UDP, generally in conjunction with 739 "multicast transmission". The practical experience have shown however 741 that the multicast transmission is very often achieved through a cascade 743 of relais, and that the source address received in the packets is not 745 always that of the actual source. The "real time transport protocol" 747 includes an identification mechanism by which stations are assigned 749 numbers within multicast groups. Real time applications go to great 751 length to reduce their packet size, using computation intensive 753 compression techniques; an additional header in each and every packet 755 would be entirely unwelcomed. 757 In fact, one may draw the general conclusion that applications which are 759 using datagram services have to incorporate their own control functions. 761 Identification of the partner, as well as general security measures, are 763 an integral part of these applications. Providing them with a "one size 765 fits all" intermediate layer would probably not help. 767 Then, one may also observe that even if one were to implement a 769 "transparent" solution, e.g. using some form of stable identifiers, the 771 TCP code would still need to be updated. The error and throughput 773 characteristics of mobile networks are different from those of fixed 775 networks; controlling parallel transmission over multiple paths is not 777 quite the same as controlling a single path. Key points of the 779 implementation, such as the retransmission strategy or the congestion 781 control algorithm would have to be revised in any case. 783 Appendix B. Managing a set of addresses 785 We have mentioned the need to maintain a "working set" of partner 787 addresses, and to "grade" each address in that working set. However, the 789 procedure described in the previous section only allows for addition of 791 addresses to the connection, not for their removal. This is because we 793 expect that the working set of addresses will simply be a cache of the 795 "most recently used" address of our partners. TCP entities may use 797 whatever strategy you want to maintain the set of addresses within 799 reasonable limits, e.g. LRU replacement. We will describe here some 801 possible manners of grading the addresses. 803 The first seen and last seen monitoring will produce a first selection 805 of selectable addresses within the working set. However, all the 807 selected addresses should not necessarily be used. Even if several of 809 them should be used, they need not be all used at the same rate. 811 Suppose that we have sent different packets to different addresses. If 813 one of these addresses has becomed invalid, packet sent to it will be 815 lost. Indeed, packets sent to valid addresses may also be lost, e.g. if 817 a cosmic ray hits a photodiode at the wrong moment. It is however quite 819 reasonable to relate the selection of addresses with the error control: 821 if a packet sent to one particular address failed, further packets 823 should preferably be sent another acceptable address. 825 Current TCP implementations try to characterize the network they are 827 using by computing round-trip time estimates and congestion windows. 829 When several addresses are in use, one may well believe that each 831 address will be reached by a different path, and that each of these 833 paths will have different characteristics. 835 In fact, due to the sequential nature of the acknowledgment process, it 837 would be very difficult to maintain more than one round-trip estimate 839 for the connection. However, it is entirely conceivable to maintain a 841 separate congestion avoidance window for each address in the working 843 set, and to mainatin these windows by running parallel versions of the 845 "slow start" algorithm. The window will be initialised when a new 847 address is added to the working set; it will be increased when a packet 849 sent to that address is acknowledged, it will shrink when a packet sent 851 to that address is lost. 853 Maintaining a congestion window per active address provides for a 855 rationale way of spreading the traffic over the various addresses. It is 857 clearly not the only way. In fact, this may well open the path for very 859 fruitful researches.