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]