| TOC |
|
This document identifies basic issues in transport protocols which complicate the Internet routing process. It offers discussion and examples which elucidate the problems and offers suggestions to transport protocol architects and implementers for avoiding the complications.
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
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.
This Internet-Draft will expire on September 9, 2010.
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
1.
Introduction
2.
Terminology
3.
Finding the Destination
3.1.
Dyanmic Map
3.2.
Reference by IP address
3.3.
Address Array
3.4.
Re-finding the Destination
4.
Associating Packets with the Session
4.1.
Why every packet?
4.2.
Global Versus Local Identifier
4.3.
Negotiated Versus Composed Identifier
5.
Recognizing the Source
6.
Multipath issues
7.
Backward compatibility
8.
Forward compatibility
9.
IANA Considerations
10.
Security Considerations
11.
References
11.1.
Normative References
11.2.
Informative References
§
Author's Address
| TOC |
Efficient Internet routing is all about aggregation. Combine multiple downstream routes into a single CIDR prefix sent upstream and all is well in the world. Fail and the routing table grows, the cost of routers rises [BGPCOST] (Herrin, W., “What does a BGP Route cost?,” February 2008.) and the general stability of the Internet falls.
Because of how TCP and the various UDP-based transport protocols interact with the IP address, multihoming and mobility can defeat aggregation. These protocols require the IP address to remain the same throughout their operation. Any time a host changes its location within the network without also changing its IP address, knowledge about that address becomes disaggregate with its neighbors. The change must be propagated throughout the entire network.
Routing researchers believe that if the host could readily change its IP addresses to match its attachment to the network then the network wouldn't have to change its routing to match the host's movement. This would improve aggregation and reduce the frequency of routing updates needed to keep the network operating. They call this concept "locator/identifier separation."
Locator/identifier separation's premise is simple: don't use the IP address for both forwarding packets through the network and associating those packets with their respective endpoints. Instead, separate this overloaded functionality into distinct elements within each packet: locators used solely for forwarding packets and identifiers used to associate those packets with specific hosts, services and sessions.
Practically speaking, this means we can either treat the IP address as a host identifier and build an overlay to the routing system with a new locator field somewhere in the packet or we can treat the IP address as a locator and introduce new elements into the transport protocols to figure out which packets belong to who.
This document will focus on suggestions for how to achieve the latter version of the goal: improving TCP and other transport protocols with evolutionary changes which loosen or eliminate their operational dependence on the host's fixed IP address.
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].
| TOC |
Most if not all transport protocols have a communications initiator and a communications acceptor. The initiator sends the first packet. The acceptor responds. This acceptor is often but not always a server of some sort.
Today, the application supplies a single IP address to the transport initiator, telling it to establish a connection or just send a packet. The application might or might not have found the address in a naming service (e.g. DNS) first.
This presents a problem for the routing system. The applications, and thus the developers and operators tend to treat the IP address as a static object. Knowledge about that address' current location within the routing system ends up having to be propagated throughout the network.
Alleviating this problem suggests the following rules:
| TOC |
The transport protocol API SHOULD support the use of a dynamic endpoint to IP address map. In other words, the application should be able to hand the DNS domain name to the connect() call and not have to deal with the underlying IP address at all.
What happens when you require the application to handle finding IP addresses? You get very inconsistent results. Some developers pay attention to the DNS TTL. Most don't. Many don't even bother with a name; they store raw IP addresses in configuration files. At the end of the day the operator is stuck: he demands acrobatics from his routing system because too much of his software doesn't work right without it.
| TOC |
The transport protocol API SHOULD discourage applications from referencing a remote system by its IP addresses. From the application's perspective, the IP address should be just like the MAC address: a detail which it need not consider.
Where you do provide an API to controlling the IP address selection, try to require the application developer to deal with all the little details that your hostname-based API would ordinarily handle for him. Especially re-finding the remote endpoint.
| TOC |
Where a transport protocol accepts IP addresses from the application, it MUST accept an array of addresses containing all the addresses and address families via which the application intends to attempt communications with the remote system. Trying each candidate in sequence with retransmissions and timeouts will take to long to establish a transport session when one or several of the candidate IP addresses are unreachable. Consider parallelizing the connection establishment process and at the very least send the retransmission to the next candidate instead of camping on one of them.
If the overall process is perceived as slow, we're back to the operator requiring acrobatics from the routing system in order to speed it up.
| TOC |
Beware that there will be common corner cases where one or both endpoints lose contact and retain no valid IP addresses for the other. The transport protocol SHOULD be able to resolve such situations. This is especially likely with two mobile systems talking to each other where they're briefly in between addresses at about the same time.
How can you find the other side of the connection after losing track of him? How about the DNS? If your opposite endpoint has been dynamically updating the A and AAAA records in his DNS entry then they should contain some entries that are currently valid. If you paid attention to the authority name server list when you first queried the name then you might even bypass TTL delays at your local resolver.
| TOC |
Associating packets with a particular ongoing transport session is a simpler but in some ways more subtle issue. There are two hard and fast rules:
| TOC |
Suppose you don't follow these two rules. Suppose you build a multipath transport by establishing parallel TCP connections using different choices of source and destination IP address and plan on dropping or adding TCP connections as your IP addresses change. These individual connections use TCP's normal method of associating packets: the source/destination address and port pairs. What limits does that impose on the routing system?
One conceivable way to achieve multihoming without propagating a distinct route into the network is with stateless Network Address Translation (NAT). Your hosts use private IP addresses. Each private IP address maps to a specific public IP address from each of your ISPs aggregated address blocks.
Let's follow a packet through a round trip.
| Host | Internal IP | ISP1 IP | ISP2 IP |
|---|---|---|---|
| I | 1 | 2 | |
| A | 3 | 4 | 5 |
| Table 1: NAT multihoming IP addresses |
The initator (I) wants to send a packet to the acceptor (A). I knows that A's external IP addresses are 4 and 5. It decides to send this packet to 4. Here's how the packet flows through the network from I to A described as (source,destination) pairs at each step:
I->(1,4)->(2,4)->(2,3)->A
So far so good. Let's start working back the other way; we just reverse the source and destination IP addresses.
I->(1,4)->(2,4)->(2,3)->A->(3,2)->uh oh.
As the packet leaves A's network for the internet, the source address will be translated into either 4 or 5. Either one is valid. Let's pick 5.
I->(1,4)->(2,4)->(2,3)->A->(3,2)->(5,2)->(5,1)->I
"I" received a packet from IP address 5 in response to his packet to IP address 4. If he relies on the IP address, he has no idea what to do with that packet. But, if the packet contains an identifier token, he will recognize that the packet is a response to the one he sent.
The KEY POINT to take away from this is that in the future Internet, the IP addresses you see could change not just some number of minutes or seconds apart but literally from packet to packet. If your efforts improving transport protocols are to have the desired impact, you MUST take this in to account.
| TOC |
Whether the token used to associate packets with the transport session is globally unique or just unique between the two communicating machines does not appear to matter to the routing system.
| TOC |
Wether the identifier token is negotiated between the two hosts or a host-unique half-identifier is simply announced by each end does not appear to matter to the routing system.
| TOC |
Some protocols need the application to understand who a packet came from without starting up a session and perhaps with a packet flow in only one direction. Such protocols MUST NOT rely on the IP address to identify the packet's source. SNMP TRAP, for example, is bad mojo for the routing system.
| TOC |
A multipath transport protocol, briefly, is a protocol in which multiple IP addresses are available for the source and destination address and may be used interchangably. In a multipath scenario, the host is connected to two or more distinct ISPs using IP addresses assigned from each ISP and spreading the data traffic between them.
Some gotchas for multipath:
| TOC |
As you investigate upgrading existing protocols like TCP, you'll find that backward compatibility requires maintaining a certain degree of stickiness to the IP address selection. Even if both ends support your upgrade, the middleboxes like the NAT-performing "DSL router" might not.
Postel's robustness principle rules: construct your packets for maximum compatibility but make sure you can receive packets in all the myriad ways implied by this document.
| TOC |
IPv4 was not the first Internet protocol. IPv6 won't be the last. When designing your APIs, consider passing parameters that are protocol-family and address-family agnostic so that the applications developers don't need to know or care about the IP protocol in use. Practically speaking, this means: where you must pass an address back and forth with the application, pass a text representation rather than a binary value.
| TOC |
This memo includes no request to IANA.
| TOC |
Filtering by IP address never was a reliable way to secure your protocol. Come to find out it breaks routing too. Replacing IP address filtering in protocol designs will surely have major security considerations, but those issues are beyond the scope of this document.
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| TOC |
| [BGPCOST] | Herrin, W., “What does a BGP Route cost?,” February 2008. |
| TOC |
| William D. Herrin | |
| 3005 Crane Drive | |
| Falls Church, Virginia 22042 | |
| US | |
| Phone: | |
| Email: | bill@herrin.us |