Network Working Group D. Thaler Internet-Draft Microsoft Expires: January 8, 2009 July 7, 2008 Evolution of the IP Model draft-thaler-ip-model-evolution-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 January 8, 2009. Abstract This draft attempts to document various aspects of the IP service model and how it has evolved over time. In particular, to document the properties of the IP layer as they are seen by upper layer protocols and applications, and especially on properties which were (and at times still are) incorrectly perceived to exist, as well as properties that changing would cause problems. Thaler Expires January 8, 2009 [Page 1] Internet-Draft Evolution of the IP Model July 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The IP Service Model . . . . . . . . . . . . . . . . . . . . . 3 2.1. Links and Subnets . . . . . . . . . . . . . . . . . . . . . 4 2.2. Common Application Assumptions . . . . . . . . . . . . . . 4 3. Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . . 8 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Intellectual Property and Copyright Statements . . . . . . . . . . 9 Thaler Expires January 8, 2009 [Page 2] Internet-Draft Evolution of the IP Model July 2008 1. Introduction Since the Internet Protocol was first published as an IEN in 1978, IP has provided a network-layer connectivity service to upper layer protocols and applications. The basic IP service model was documented in the original IEN's (and subsequently the RFC's that obsolete them). However, since the mantra has been "Everything Over IP", the IP service model has evolved significantly over the past 30 years to enable new behaviors that the original definition did not envision. Today's IP service model is not well documented in a single place, but is either implicit or discussed piecemeal in many different RFCs. As a result, today's IP service model is actually not well known, or at least is often misunderstood. In the early days of IP, changing or extending the basic IP service model was easier since it was not as widely deployed and there were fewer implementations. Today, the ossification of the Internet makes evolving the IP model even more difficult. Thus it is important to understand the evolution of the IP model for two reasons: 1. To make it clear what upper layer protocols and applications can and cannot depend on. There are many myths (or at least beliefs which are no longer true) applications may be based on which are problematic. 2. To document lessons for future evolution to take into account. It is important that the service model remain consistent, rather than evolving in two opposing directions. It is sometimes the case in IETF Working Groups today that directions are considered or even taken which would change the IP service model. Doing this without understanding the implications on applications can be dangerous. This draft attempts to document various aspects of the IP service model and how it has evolved over time. In particular, to document the properties of the IP layer as they are seen by upper layer protocols and applications, and especially on properties which were (and at times still are) incorrectly perceived to exist, as well as properties that changing would cause problems. 2. The IP Service Model The foundation of the IP service model today is documented in [RFC0791] section 2.2. Generally speaking, IP provides a connectionless delivery service, which does not guarantee ordering, delivery, or lack of duplication, but is merely best effort. Senders can send to a destination address without signaling a priori, and receivers just listen on an already provisioned address, without signaling a priori. Thaler Expires January 8, 2009 [Page 3] Internet-Draft Evolution of the IP Model July 2008 2.1. Links and Subnets Section 2.1 of [RFC4903] discusses the terms "link" and "subnet" with respect to the IP model. A "link" in the IP service model refers to the topological area within which a packet with IPv4 TTL or IPv6 Hop Limit of 1 can be delivered. That is, where no IP-layer forwarding (which entails a TTL/Hop Limit decrement) occurs between two nodes. A "subnet" in the IP service model refers to the topological area within which addresses from the same subnet prefix are assigned to interfaces. 2.2. Common Application Assumptions Below is a list of properties which are sometimes assumed by applications, but which have become less true over time. o Selecting a local address selects the interface: Some applications assume that binding to a given local address constrains traffic reception to the interface with that address, and that traffic from that address will go out on that address's interface. However, [RFC1122] section 3.3.4.2 defines two models: the Strong End System (or Strong host) model where this is true, and the Weak End System (or Weak host) model where this is not true. In fact any router is inherently a weak host implementation, since packets can be forwarded between interfaces. o Multicast is supported: [RFC1112] introduced multicast to the IP service model. In this evolution, senders still just send to a destination address without signaling a priori, but in contrast to the original IP model, receivers must signal to the network before they can receive traffic to a multicast address. Today it is often assumed that multicast works within a link, but may or may not function across a wider area. While network-layer multicast works over most link types, there are Non-Broadcast Multi-Access (NBMA) links over which multicast does not work (e.g., X.25, ATM, frame relay, 6to4, ISATAP, Teredo) and this can interfere with some protocols and applications. o Broadcast is supported: IPv4 broadcast support was originally defined on a link, across a network, and for subnet directed broadcast. Since [RFC2644], broadcast can only be relied on within a link. Still, there exist NBMA links over which broadcast does not work. In addition, the addition of link-scoped multicast to the IP service model to a large extent obsoleted the need for broadcast. It is also worth noting that the broadcast API model used by most platforms allows receivers to just listen on an already provisioned address, without signaling a priori, but in contrast to the unicast API model, senders must signal to the Thaler Expires January 8, 2009 [Page 4] Internet-Draft Evolution of the IP Model July 2008 local IP stack (SO_BROADCAST) before they can send traffic to a broadcast address. However, from the network's perspective, the host still sends without signaling a priori. o Multicast/broadcast is less expensive than unicast to reach multiple receivers on the same link: In wired networks, sending a single multicast packet on a link is generally less expensive than sending multiple unicast packets. This may not be true for wireless networks, where implementations can send multicast at the basic rate, regardless of the negotiated rates of potential receivers. o Bursty sources work: In the original IP model, senders just send, without signaling the network a priori. This works to a degree. In practice, the last hop (and in rare cases, other hops) of the path needs to resolve next hop information (e.g., the link-layer address of the destination) on demand which results in queuing traffic, and if the queue fills up, some traffic gets dropped. This means that bursty sources can be problematic (and indeed a single large packet that gets fragmented becomes such a burst at the last hop). The problem is rarely observed in practice today, either because the resolution within the last hop happens very quickly, or because bursty applications are rarer. However, any protocol that significantly increases such delays or adds new resolutions would be a change to the classic IP model and may adversely impact upper layer protocols and applications that result in bursts of packets. o Connectivity is Transitive: Originally it was the case that connectivity was transitive, both within a link and across the Internet. With the advent of technologies such as NATs, and firewalls, this can no longer be assumed across the Internet, but it is often still true within a link. As a result, upper layer protocols and applications may be relying on transitivity within a link. However, radio technologies such as 802.11 ad-hoc mode violate this assumption. o Connectivity is Symmetric: Originally it was the case that connectivity was symmetric (although the path taken may not be), both within a link and across the Internet. With the advent of technologies such as NATs and firewalls, this can no longer be assumed. However, it is still the case that if a request can be sent, then a reply to that request can generally be received, but an unsolicited request in the other direction may not be received. o Addresses are Stable: Originally addresses were manually configured on fixed machines, and hence addresses were very stable. With the advent of technologies such as DHCP, roaming, and wireless, addresses can no longer be assumed to be stable for long periods of time. However, the APIs provided to applications today typically still assume stable addresses (e.g., address lifetimes are not exposed to applications that get addresses). This can cause problems today when addresses become stale. Thaler Expires January 8, 2009 [Page 5] Internet-Draft Evolution of the IP Model July 2008 o A host has only one address on one interface: Although many applications assume this (e.g., by calling a name resolution function such as gethostbyname and then just using the first address returned), it was never really true to begin with, even if it was the common case. Even [RFC0791] states, "provision must be made for a host to have several physical interfaces to the network with each having several logical internet addresses". However today this assumption is increasingly less true, with the advent of multiple interfaces (e.g., wired and wireless), dual-IPv4/IPv6 nodes, multiple IPv6 addresses on the same interface (e.g., link- local and global), etc. Similarly, many protocol specifications such as DHCP only describe operations for a single interface, whereas obtaining host-wide configuration from multiple interfaces presents a merging problem for nodes in practice. Too often this problem is simply ignored by Working Groups, and applications and users suffer as a result from poor merging algorithms. o Traffic to a normal (non-broadcast/multicast) IP address is delivered to only one interface: (to be filled in) o Traffic to a normal (non-broadcast/multicast) IP address is delivered to the same interface over time: (to be filled in) o A "subnet" is smaller than a "link": In the classic IP model, a "subnet" is smaller than, or equal to, a "link". Destinations with addresses in the same subnet can be reached with TTL (or Hop Count) = 1. Link-scoped multicast packets, and all-ones broadcast packets will be delivered (in a best effort fashion) to all listening nodes on the link. Subnet broadcast packets will be delivered (in a best effort fashion) to all listening nodes in the subnet. There have been some efforts in the past to allow multi- link subnets and change the above service model, but the adverse impact on applications that have such assumptions recommend against changing this assumption. [RFC4903] discusses this topic in more detail. o An address is part of an on-link subnet: To some extent, this was never true, in that there were cases in IPv4 where the "mask" was 255.255.255.255, such as on a point-to-point link where the two endpoints had addresses out of unrelated address spaces. However, this didn't stop many platforms and applications from assuming that every address had a "mask" (or prefix) that was on-link. The assumption of whether a subnet is on-link (in which case one can send directly to the destination after using ARP/ND) or off-link (in which case one just sends to a router) has evolved over the years, and it can no longer be assumed that an address has an on- link prefix. [RFC2461] introduced the distinction as part of the core IPv6 protocol suite. [RFC4903] also touches on this topic with respect to the service model seen by applications. o Reordering is rare: (to be filled in) Thaler Expires January 8, 2009 [Page 6] Internet-Draft Evolution of the IP Model July 2008 o An "address" used by an application is the same as the "address" used for routing: (to be filled in) o An end-to-end path exists at a single point in time: In classic IP, applications assume that an end-to-end path either exists to a destination, or that the packet will be dropped. In addition, IP today tends to assume that the packet delay is relatively short (since the "Time"-to-live is just a hop count, since each hop is assumed to be less than a second), whereas earlier the TTL field was expected to be decremented each second (not just each hop). The DTN Research Group trying to change this assumption. o IP payload sent == IP payload received at other en: (to be filled in) o Unsolicited, unauthenticated inbound connectivity works: (to be filled in) 3. Impact Because a huge number of applications already exist that use TCP/IP for business-critical operations, any changes to the service model need to be done with extreme care. Extensions that merely add additional optional functionality with impacting any existing applications are much safer than extensions which change one or more of the core assumptions discussed above. Any changes to the above assumptions should only be done in accordance with some mechanism to minimize or mitigate the risks of breaking mission-critical applications. Historically, changes have been done without regard to such considerations and as a result the situation for applications today is already problematic. Key to maintaining an interoperable Internet is documenting and maintaining invariants that higher layers can depend on, and being very judicious with changes. 4. Security Considerations TBD. 5. IANA Considerations This document has no IANA Actions. 6. Acknowledgements Bernard Aboba, Chris Hopps, Dow Street, and others provided helpful discussion on various points that led to this document. Thaler Expires January 8, 2009 [Page 7] Internet-Draft Evolution of the IP Model July 2008 7. References 7.1. Normative References [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989. [RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999. 7.2. Informative References [IEN28] Postel, J., "Draft Internetwork Protocol Specification", February 1978. [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007. Author's Address Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA Phone: +1 425 703 8835 Email: dthaler@microsoft.com Thaler Expires January 8, 2009 [Page 8] Internet-Draft Evolution of the IP Model July 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Thaler Expires January 8, 2009 [Page 9]