Multipath TCP

Propose a connection ID and offer to start Mutlipath TCP.

Proposed connection ID is a random number which is not already in use by the initiating host.

Must only be sent by the connection's initiator and must only be sent once per connection, but may be sent in any TCP packet for which the initiator expects an ACK.

My and Your IP address match the packet's source and destination IP address respectively. If the receiver gets a Multipath TCP proposal whose IP addresses don't match the addresses in the IP header, it must reject Multipath TCP since the packet has transited a NAT device which does not support Multipath TCP. If the packet transits a NAT device which supports multipath TCP, the NAT device must alter the option IP addresses in the same manner that it alters addresses in the IP header.

The host supports mutlipath TCP but the proposed connection ID is not available for use. Propose an alternate connection ID. Packets proposing an alternate connection ID will go back and forth between the initiator and acceptor until one or the other accepts or rejects the proposed connection ID. A host must remember all connection IDs it has proposed. A previously proposed connection ID is considered accepted upon receipt of any packet with the established bit set that contains a connection ID it proposed.

May only be sent in a packet for which the local host expects an ACK from the remote host.

Reject the attempt to initiate Multipath TCP and send no more Multipath TCP options. Regular TCP continues in which the source/destination IP address and the source/destination port form the connection ID.

Multipath TCP must be rejected if the IP addresses in the TCP option do not match the IP addresses in the IP header.

Multipath TCP must be rejected if the host can not remember additional connection ID proposals.

Should be sent in exactly those packets which ACK a packet containing a Multipath TCP proposal after the host decides to abandon the attempt to start Multipath TCP.

The established session ID of this TCP connection. Once the first packet with the TCP session option is received, no further packets without the TCP session option will be accepted for this connection.

All hosts and intermediate NAT devices MUST disregard the source IP address and ports assigned to a packet which contains an established connection ID.

A host MUST confirm that the destination address is one of it's own and MUST discard the packet if it is not. However, once the packet has been accepted, the host MUST use only the connection ID to associate accepted packets with the connection.

A host MUST NOT discard packets solely because they originate from a source address other than one the remote host has already announced.

Only one Multipath TCP option with the established bit set should appear in any packet. If an add or delete option appears, the session ID should be taken from that option.

Add an IP address or change the weight of an IP address via which the remote host may attempt to send packets to the local host for this connection.

The weight means: everything else being equal, send me [weight] packets via this address for every SUM(weights) packets you send.

A weight of zero means: do not attempt to send packets via this IP address unless you have determine that you can no longer reach me via any non-zero weighted addresses.

The host MUST respect the meaning of the zero weight. It SHOULD use any other weight hints to scale its own decision about which source/destination addresses to use for a given packet.

By default, the address used to start the multipath TCP connection is weighted 128.

A host MUST be able to remember 16 addresses offered by the remote. A host MUST NOT offer more than 16 addresses until it has deleted one and received an ack for the packet which contained the deletion.

The initiating host MUST NOT offer an RFC1918 address in a Multipath TCP option unless the original connection was established with an RFC1918 destination. The accepting host MUST NOT offer an RFC1918 address unless the original connection was established from an RFC1918 source.

Note that congestion control must be performed on a per source/destination pair basis instead of a per-connection basis. Reduce the window in response to the average loss across all paths rather than the absolute loss and allow the remote end to shift traffic away from those paths which experience loss towards those which don't instead.

Advise the remote host that no further communication attempts should be made to the given IP address.

IPv6 versions:

A dual stacked host may offer both IPv4 and IPv6 addresses for a particular connection ID. If both hosts are dual-stacked, they may send packets for the connection via both protocols, however only paths composed of only IPv6 addresses or only IPv4 addresses should be considered.

Hostname option for Multipath TCP

The Hostname option performs two functions:

1. Validation of the packets' source IP address
2. Rediscovery of IP addresses at which the remote host can be reached should all known paths be disrupted.

All network stacks which support Multipath TCP MUST be able to parse the Hostname TCP option. In particular, they must be able to recognize that the data portion of a packet containing a Hostname option should not be passed to the user as if it were regular data in the stream.

A host MUST NOT send a Hostname option until Multipath TCP has been established.

A host MUST NOT accept packets with a hostname option which contain a different hostname than previously present. Any such option received should be treated as if the host received an RST packet from the given source for the given connection ID. However, the host MUST accept and process additional hostname options which contain the same hostname first offered.

Once a host accepts the hostname, it will determine the source's IP addresses by performing a DNS lookup for A and AAAA records for the given hostname.

Only packets which originate from one of the IP addresses listed in the DNS lookup will be accepted for the connection. Others will be dropped and will cause the host to re-query the DNS hostname with a rate limit of once per 10 seconds.

Receipt of any valid Hostname packet will cause the host to re-lookup the DNS entry.

Any IP addresses in the lookup which have not already been added via the MultipathTCP option will be added with a weight of 0. IP addresses not present in the lookup will be removed from the list as if a MultipathTCP Delete option had been received.

Where a host is unable to communicate on any known source/destination pairs, it SHOULD re-perform the DNS lookup to determine if any more IP addresses are available for the remote host.

Note that the hostname presented in the Hostname option is not necessarily the same host name used to first establish the connection. A quesry for www.example.com may offer addresses for two physical machines, each of which maintains a distinct hostname for the purposes of maintaining Multipath TCP.

The host does not implement or declines to process hostname lookups for the purpose of validating source addresses.