doc: Add RFC documents

1 files changed, 1403 insertions, 0 deletions

diff --git a/doc/rfc/rfc6250.txt b/doc/rfc/rfc6250.txt
new file mode 100644
index 0000000..5cbb82e
--- /dev/null
+++ b/doc/rfc/rfc6250.txt
@@ -0,0 +1,1403 @@
+
+
+
+
+
+
+Internet Architecture Board (IAB)                              D. Thaler
+Request for Comments: 6250                                      May 2011
+Category: Informational
+ISSN: 2070-1721
+
+
+                       Evolution of the IP Model
+
+Abstract
+
+   This RFC attempts to document various aspects of the IP service model
+   and how it has evolved over time.  In particular, it attempts to
+   document the properties of the IP layer as they are seen by upper-
+   layer protocols and applications, especially properties that were
+   (and, at times, still are) incorrectly perceived to exist as well as
+   properties that would cause problems if changed.  The discussion of
+   these properties is organized around evaluating a set of claims, or
+   misconceptions.  Finally, this document provides some guidance to
+   protocol designers and implementers.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Architecture Board (IAB)
+   and represents information that the IAB has deemed valuable to
+   provide for permanent record.  Documents approved for publication by
+   the IAB are not a candidate for any level of Internet Standard; see
+   Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6250.
+
+Copyright Notice
+
+   Copyright (c) 2011 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
+   (http://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.
+
+
+
+
+
+Thaler & IAB                  Informational                     [Page 1]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. The IP Service Model ............................................4
+      2.1. Links and Subnets ..........................................5
+   3. Common Application Misconceptions ...............................5
+      3.1. Misconceptions about Routing ...............................5
+           3.1.1. Claim: Reachability is symmetric ....................5
+           3.1.2. Claim: Reachability is transitive ...................6
+           3.1.3. Claim: Error messages can be received in
+                  response to data packets ............................7
+           3.1.4. Claim: Multicast is supported within a link .........7
+           3.1.5. Claim: IPv4 broadcast is supported ..................8
+           3.1.6. Claim: Multicast/broadcast is less expensive
+                  than replicated unicast .............................8
+           3.1.7. Claim: The end-to-end latency of the first
+                  packet to a destination is typical ..................8
+           3.1.8. Claim: Reordering is rare ...........................9
+           3.1.9. Claim: Loss is rare and probabilistic, not
+                  deterministic .......................................9
+           3.1.10. Claim: An end-to-end path exists at a
+                   single point in time ..............................10
+           3.1.11. Discussion ........................................10
+      3.2. Misconceptions about Addressing ...........................11
+           3.2.1. Claim: Addresses are stable over long
+                  periods of time ....................................11
+           3.2.2. Claim: An address is four bytes long ...............12
+           3.2.3. Claim: A host has only one address on one interface 12
+           3.2.4. Claim: A non-multicast/broadcast address
+                  identifies a single host over a long period of time 13
+           3.2.5. Claim: An address can be used as an
+                  indication of physical location ....................14
+           3.2.6. Claim: An address used by an application is
+                  the same as the address used for routing ...........14
+           3.2.7. Claim: A subnet is smaller than a link .............14
+           3.2.8. Claim: Selecting a local address selects
+                  the interface ......................................15
+           3.2.9. Claim: An address is part of an on-link
+                  subnet prefix ......................................15
+           3.2.10. Discussion ........................................15
+      3.3. Misconceptions about Upper-Layer Extensibility ............16
+           3.3.1. Claim: New transport-layer protocols can
+                  work across the Internet ...........................16
+           3.3.2. Claim: If one stream between a pair of
+                  addresses can get through, then so can another .....17
+           3.3.3. Discussion .........................................17
+      3.4. Misconceptions about Security .............................17
+           3.4.1. Claim: Packets are unmodified in transit ...........17
+
+
+
+Thaler & IAB                  Informational                     [Page 2]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+           3.4.2. Claim: Packets are private .........................18
+           3.4.3. Claim: Source addresses are not forged .............18
+           3.4.4. Discussion .........................................18
+   4. Security Considerations ........................................18
+   5. Conclusion .....................................................19
+   6. Acknowledgements ...............................................20
+   7. IAB Members at the Time of This Writing ........................20
+   8. IAB Members at the Time of Approval ............................20
+   9. References .....................................................20
+      9.1. Normative References ......................................20
+      9.2. Informative References ....................................21
+
+1.  Introduction
+
+   Since the Internet Protocol was first published as [IEN028] 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 IENs (and subsequently in the RFCs 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.  For example, by 1989 there was already some confusion and
+   so [RFC1122] clarified many things and extended the model.  In 2004,
+   [RFC3819] advised link-layer protocol designers on a number of issues
+   that affect upper layers and is the closest in intent to this
+   document.  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 clarify what properties can and cannot be depended upon by
+       upper-layer protocols and applications.  There are many
+       misconceptions on which applications may be based and 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 that would change the IP service model.  Doing this
+       without understanding the implications on applications can be
+       dangerous.
+
+
+
+Thaler & IAB                  Informational                     [Page 3]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   This RFC attempts to document various aspects of the IP service model
+   and how it has evolved over time.  In particular, it attempts to
+   document the properties of the IP layer, as seen by upper-layer
+   protocols and applications, especially properties that were (and at
+   times still are) incorrectly perceived to exist.  It also highlights
+   properties that would cause problems if changed.
+
+2.  The IP Service Model
+
+   In this document, we use the term "IP service model" to refer to the
+   model exposed by IP to higher-layer protocols and applications.  This
+   is depicted in Figure 1 by the horizontal line.
+
+    +-------------+                                  +-------------+
+    | Application |                                  | Application |
+    +------+------+                                  +------+------+
+           |                                                |
+    +------+------+                                  +------+------+
+    | Upper-Layer |                                  | Upper-Layer |
+    |  Protocol   |                                  |  Protocol   |
+    +------+------+                                  +------+------+
+           |                                                |
+   ------------------------------------------------------------------
+           |                                                |
+        +--+--+                  +-----+                 +--+--+
+        | IP  |                  | IP  |                 | IP  |
+        +--+--+                  +--+--+                 +--+--+
+           |                        |                       |
+     +-----+------+           +-----+------+          +-----+------+
+     | Link Layer |           | Link Layer |          | Link Layer |
+     +-----+------+           +--+-----+---+          +-----+------+
+           |                     |     |                    |
+           +---------------------+     +--------------------+
+
+         Source                                        Destination
+
+                             IP Service Model
+
+                                 Figure 1
+
+   The foundation of the IP service model today is documented in Section
+   2.2 of [RFC0791].  Generally speaking, IP provides a connectionless
+   delivery service for variable size packets, which does not guarantee
+   ordering, delivery, or lack of duplication, but is merely best effort
+   (although some packets may get better service than others).  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 & IAB                  Informational                     [Page 4]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   Architectural principles of the IP model are further discussed in
+   [RFC1958] and in Sections 5 and 6 of [NEWARCH].
+
+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 an IPv4 Time to Live (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.
+
+3.  Common Application Misconceptions
+
+   Below is a list of properties that are often assumed by applications
+   and upper-layer protocols, but which have become less true over time.
+
+3.1.  Misconceptions about Routing
+
+3.1.1.  Claim: Reachability is symmetric
+
+   Many applications assume that if a host A can contact a host B, then
+   the reverse is also true.  Examples of this behavior include request-
+   response patterns, which require reverse reachability only after
+   forward reachability, as well as callbacks (e.g., as used by the File
+   Transfer Protocol (FTP) [RFC0959]).
+
+   Originally, it was the case that reachability was symmetric (although
+   the path taken may not be), both within a link and across the
+   Internet.  With the advent of technologies such as Network Address
+   Translators (NATs) and firewalls (as in the following example
+   figure), this can no longer be assumed.  Today, host-to-host
+   connectivity is challenging if not impossible in general.  It is
+   relatively easy to initiate communication from hosts (A-E in the
+   example diagram) to servers (S), but not vice versa, nor between
+   hosts A-E.  For a longer discussion on peer-to-peer connectivity, see
+   Appendix A of [RFC5694].
+
+
+
+
+
+
+
+
+
+Thaler & IAB                  Informational                     [Page 5]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+           __________                                 ___       ___
+          /          \             ___        ___    /   \ ____|FW |__A
+         /            \    ___    /   \ _____|NAT|__|     |    |___|
+        |              |__|NAT|__|     |     |___|  |     |__B
+        |              |  |___|  |     |__C          \___/
+        |              |          \___/               ___
+     S__|   Internet   |           ___        ___    /   \
+        |              |   ___    /   \ _____|NAT|__|     |__D
+        |              |__|FW |__|     |     |___|  |     |
+        |              |  |___|  |     |__E          \___/
+         \            /           \___/
+          \__________/
+
+                                 Figure 2
+
+   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.  [RFC2993]
+   discusses this in more detail.
+
+   There are also links (e.g., satellite) that were defined as
+   unidirectional links and hence an address on such a link results in
+   asymmetric reachability.  [RFC3077] explicitly addresses this problem
+   for multihomed hosts by tunneling packets over another interface in
+   order to restore symmetric reachability.
+
+   Finally, even with common wireless networks such as 802.11, this
+   assumption may not be true, as discussed in Section 5.5 of
+   [WIRELESS].
+
+3.1.2.  Claim: Reachability is transitive
+
+   Many applications assume that if a host A can contact host B, and B
+   can contact C, then host A can contact C.  Examples of this behavior
+   include applications and protocols that use referrals.
+
+   Originally, it was the case that reachability was transitive, both
+   within a link and across the Internet.  With the advent of
+   technologies such as NATs and firewalls and various routing policies,
+   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,
+   some radio technologies, such as 802.11 ad hoc mode, violate this
+   assumption within a link.
+
+
+
+
+
+
+
+Thaler & IAB                  Informational                     [Page 6]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+3.1.3.  Claim: Error messages can be received in response to data
+        packets
+
+   Some upper-layer protocols and applications assume that ICMP error
+   messages will be received in response to packets sent that cannot be
+   delivered.  Examples of this include the use of Path MTU Discovery
+   [RFC1191] [RFC1981] relying on messages indicating packets were too
+   big, and traceroute and the use of expanding ring search [RFC1812]
+   relying on messages indicating packets reached their TTL/Hop Limit.
+
+   Originally, this assumption largely held, but many ICMP senders then
+   chose to rate-limit responses in order to mitigate denial-of-service
+   attacks, and many firewalls now block ICMP messages entirely.  For a
+   longer discussion, see Section 2.1 of [RFC2923].
+
+   This led to an alternate mechanism for Path MTU Discovery that does
+   not rely on this assumption being true [RFC4821] and guidance to
+   firewall administrators ([RFC4890] and Section 3.1.1 of [RFC2979]).
+
+3.1.4.  Claim: Multicast is supported within a link
+
+   [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, many applications and protocols use multicast addresses,
+   including protocols for address configuration, service discovery,
+   etc.  (See [MCAST4] and [MCAST6] for those that use well-known
+   addresses.)
+
+   Most of these only assume that multicast works within a link and 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, Intra-Site Automatic Tunnel Addressing
+   Protocol (ISATAP), Teredo) and this can interfere with some protocols
+   and applications.  Similarly, there are links such as 802.11 ad hoc
+   mode where multicast packets may not get delivered to all receivers
+   on the link.  [RFC4861] states:
+
+      Note that all link types (including NBMA) are expected to provide
+      multicast service for applications that need it (e.g., using
+      multicast servers).
+
+   and its predecessor [RFC2461] contained similar wording.
+
+
+
+
+Thaler & IAB                  Informational                     [Page 7]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   However, not all link types today meet this expectation.
+
+3.1.5.  Claim: IPv4 broadcast is supported
+
+   IPv4 broadcast support was originally defined on a link, across a
+   network, and for subnet-directed broadcast, and it is used by many
+   applications and protocols.  For security reasons, however, [RFC2644]
+   deprecated the forwarding of broadcast packets.  Thus, since 1999,
+   broadcast can only be relied on within a link.  Still, there exist
+   NBMA links over which broadcast does not work, and there exist some
+   "semi-broadcast" links (e.g., 802.11 ad hoc mode) where broadcast
+   packets may not get delivered to all nodes on the link.  Another case
+   where broadcast fails to work is when a /32 or /31 is assigned to a
+   point-to-point interface (e.g., [RFC3021]), leaving no broadcast
+   address available.
+
+   To a large extent, the addition of link-scoped multicast to the IP
+   service model 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 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.
+
+3.1.6.  Claim: Multicast/broadcast is less expensive than replicated
+        unicast
+
+   Some applications and upper-layer protocols that use multicast or
+   broadcast do so not because they do not know the addresses of
+   receivers, but simply to avoid sending multiple copies of the same
+   packet over 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 only
+   send multicast at the basic rate, regardless of the negotiated rates
+   of potential receivers.  As a result, replicated unicast may achieve
+   much higher throughput across such links than multicast/broadcast
+   traffic.
+
+3.1.7.  Claim: The end-to-end latency of the first packet to a
+        destination is typical
+
+   Many applications and protocols choose a destination address by
+   sending a message to each of a number of candidates, picking the
+   first one to respond, and then using that destination for subsequent
+   communication.  If the end-to-end latency of the first packet to each
+
+
+
+Thaler & IAB                  Informational                     [Page 8]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   destination is atypical, this can result in a highly non-optimal
+   destination being chosen, with much longer paths (and hence higher
+   load on the Internet) and lower throughput.
+
+   Today, there are a number of reasons this is not true.  First, when
+   sending to a new destination there may be some startup latency
+   resulting from the link-layer or network-layer mechanism in use, such
+   as the Address Resolution Protocol (ARP), for instance.  In addition,
+   the first packet may follow a different path from subsequent packets.
+   For example, protocols such as Mobile IPv6 [RFC3775], Protocol
+   Independent Multicast - Sparse Mode (PIM-SM) [RFC4601], and the
+   Multicast Source Discovery Protocol (MSDP) [RFC3618] send packets on
+   one path, and then allow immediately switching to a shorter path,
+   resulting in a large latency difference.  There are various proposals
+   currently being evaluated by the IETF Routing Research Group that
+   result in similar path switching.
+
+3.1.8.  Claim: Reordering is rare
+
+   As discussed in [REORDER], [RFC2991], and Section 15 of [RFC3819],
+   there are a number of effects of reordering.  For example, reordering
+   increases buffering requirements (and jitter) in many applications
+   and in devices that do packet reassembly.  In particular, TCP
+   [RFC0793] is adversely affected by reordering since it enters fast-
+   retransmit when three packets are received before a late packet,
+   which drastically lowers throughput.  Finally, some NATs and
+   firewalls assume that the initial fragment arrives first, resulting
+   in packet loss when this is not the case.
+
+   Today, there are a number of things that cause reordering.  For
+   example, some routers do per-packet, round-robin load balancing,
+   which, depending on the topology, can result in a great deal of
+   reordering.  As another example, when a packet is fragmented at the
+   sender, some hosts send the last fragment first.  Finally, as
+   discussed in Section 3.1.7, protocols that do path switching after
+   the first packet result in deterministic reordering within the first
+   burst of packets.
+
+3.1.9.  Claim: Loss is rare and probabilistic, not deterministic
+
+   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).  The problem is rarely observed in practice
+
+
+
+Thaler & IAB                  Informational                     [Page 9]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   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.
+
+   In addition, mechanisms that simply drop the first packet, rather
+   than queuing it, also break this assumption.  Similar to the result
+   of reordering, they can result in a highly non-optimal destination
+   being chosen by applications that use the first one to respond.  Two
+   examples of mechanisms that appear to do this are network interface
+   cards that support a "Wake-on-LAN" capability where any packet that
+   matches a specified pattern will wake up a machine in a power-
+   conserving mode, but only after dropping the matching packet, and
+   MSDP, where encapsulating data packets is optional, but doing so
+   enables bursty sources to be accommodated while a multicast tree is
+   built back to the source's domain.
+
+3.1.10.  Claim: An end-to-end path exists at a single point in time
+
+   In classic IP, applications assume that either an end-to-end path
+   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).  In
+   IP's earlier history, the TTL field was expected to also be
+   decremented each second (not just each hop).
+
+   In general, this assumption is still true today.  However, the IRTF
+   Delay Tolerant Networking Research Group is investigating ways for
+   applications to use IP in networks where this assumption is not true,
+   such as store-and-forward networks (e.g., packets carried by vehicles
+   or animals).
+
+3.1.11.  Discussion
+
+   The reasons why the assumptions listed above are increasingly less
+   true can be divided into two categories: effects caused by attributes
+   of link-layer technologies and effects caused by network-layer
+   technologies.
+
+   RFC 3819 [RFC3819] advises link-layer protocol designers to minimize
+   these effects.  Generally, the link-layer causes are not
+   intentionally trying to break IP, but rather adding IP over the
+   technology introduces the problem.  Hence, where the link-layer
+   protocol itself does not do so, when specifying how IP is defined
+   over such a link protocol, designers should compensate to the maximum
+   extent possible.  As examples, [RFC3077] and [RFC2491] compensate for
+
+
+
+Thaler & IAB                  Informational                    [Page 10]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   the lack of symmetric reachability and the lack of link-layer
+   multicast, respectively.  That is, when IP is defined over a link
+   type, the protocol designers should attempt to restore the
+   assumptions listed in this document.  For example, since an
+   implementation can distinguish between 802.11 ad hoc mode versus
+   infrastructure mode, it may be possible to define a mechanism below
+   IP to compensate for the lack of transitivity over such links.
+
+   At the network layer, as a general principle, we believe that
+   reachability is good.  For security reasons ([RFC4948]), however, it
+   is desirable to restrict reachability by unauthorized parties; indeed
+   IPsec, an integral part of the IP model, provides one means to do so.
+   Where there are issues with asymmetry, non-transitivity, and so
+   forth, which are not direct results of restricting reachability to
+   only authorized parties (for some definition of authorized), the IETF
+   should attempt to avoid or solve such issues.  Similar to the
+   principle outlined in Section 3.9 of [RFC1958], the general theme
+   when defining a protocol is to be liberal in what effects you accept,
+   and conservative in what effects you cause.
+
+   However, in being liberal in what effects you accept, it is also
+   important to remember that diagnostics are important, and being too
+   liberal can mask problems.  Thus, a tussle exists between the desire
+   to provide a better experience to one's own users or applications and
+   thus be more successful ([RFC5218]), versus the desire to put
+   pressure on getting problems fixed.  One solution is to provide a
+   separate "pedantic mode" that can be enabled to see the problems
+   rather than mask them.
+
+3.2.  Misconceptions about Addressing
+
+3.2.1.  Claim: Addresses are stable over long periods of time
+
+   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 when addresses become
+   stale.
+
+   For example, many applications resolve names to addresses and then
+   cache them without any notion of lifetime.  In fact, the classic name
+   resolution APIs do not even provide applications with the lifetime of
+   entries.
+
+
+
+
+
+Thaler & IAB                  Informational                    [Page 11]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   Proxy Mobile IPv6 [RFC5213] tries to restore this assumption to some
+   extent by preserving the same address while roaming around a local
+   area.  The issue of roaming between different networks has been known
+   since at least 1980 when [IEN135] proposed a mobility solution that
+   attempted to restore this assumption by adding an additional address
+   that can be used by applications, which is stable while roaming
+   anywhere with Internet connectivity.  More recent protocols such as
+   Mobile IPv6 (MIP6) [RFC3775] and the Host Identity Protocol (HIP)
+   [RFC4423] follow in this same vein.
+
+3.2.2.  Claim: An address is four bytes long
+
+   Many applications and protocols were designed to only support
+   addresses that are four bytes long.  Although this was sufficient for
+   IPv4, the advent of IPv6 made this assumption invalid and with the
+   exhaustion of IPv4 address space this assumption will become
+   increasingly less true.  There have been some attempts to try to
+   mitigate this problem with limited degrees of success in constrained
+   cases.  For example, "Bump-In-the-Stack" [RFC2767] and "Bump-in-the-
+   API" [RFC3338] attempt to provide four-byte "IPv4" addresses for IPv6
+   destinations, but have many limitations including (among a number of
+   others) all the problems of NATs.
+
+3.2.3.  Claim: 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, this assumption is increasingly less true today, 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.
+
+   One use of protocols such as MIP6 and HIP is to make this assumption
+   somewhat more true by adding an additional "address" that can be the
+   one used by such applications, and the protocol will deal with the
+   complexity of multiple physical interfaces and addresses.
+
+
+
+Thaler & IAB                  Informational                    [Page 12]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+3.2.4.  Claim: A non-multicast/broadcast address identifies a single
+        host over a long period of time
+
+   Many applications and upper-layer protocols maintain a communication
+   session with a destination over some period of time.  If that address
+   is reassigned to another host, or if that address is assigned to
+   multiple hosts and the host at which packets arrive changes, such
+   applications can have problems.
+
+   In addition, many security mechanisms and configurations assume that
+   one can block traffic by IP address, implying that a single attacker
+   can be identified by IP address.  If that IP address can also
+   identify many legitimate hosts, applying such a block can result in
+   denial of service.
+
+   [RFC1546] introduced the notion of anycast to the IP service model.
+   It states:
+
+      Because anycasting is stateless and does not guarantee delivery of
+      multiple anycast datagrams to the same system, an application
+      cannot be sure that it is communicating with the same peer in two
+      successive UDP transmissions or in two successive TCP connections
+      to the same anycast address.
+
+      The obvious solutions to these issues are to require applications
+      which wish to maintain state to learn the unicast address of their
+      peer on the first exchange of UDP datagrams or during the first
+      TCP connection and use the unicast address in future
+      conversations.
+
+   The issues with anycast are further discussed in [RFC4786] and
+   [ANYCAST].
+
+   Another mechanism by which multiple hosts use the same address is as
+   a result of scoped addresses, as defined for both IPv4 [RFC1918]
+   [RFC3927] and IPv6 [RFC4007].  Because such addresses can be reused
+   within multiple networks, hosts in different networks can use the
+   same address.  As a result, a host that is multihomed to two such
+   networks cannot use the destination address to uniquely identify a
+   peer.  For example, a host can no longer use a 5-tuple to uniquely
+   identify a TCP connection.  This is why IPv6 added the concept of a
+   "zone index".
+
+   Yet another example is that, in some high-availability solutions, one
+   host takes over the IP address of another failed host.
+
+   See [RFC2101], [RFC2775], and [SHARED-ADDRESSING] for additional
+   discussion on address uniqueness.
+
+
+
+Thaler & IAB                  Informational                    [Page 13]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+3.2.5.  Claim: An address can be used as an indication of physical
+        location
+
+   Some applications attempt to use an address to infer some information
+   about the physical location of the host with that address.  For
+   example, geo-location services are often used to provide targeted
+   content or ads.
+
+   Various forms of tunneling have made this assumption less true, and
+   this will become increasingly less true as the use of IPv4 NATs for
+   large networks continues to increase.  See Section 7 of
+   [SHARED-ADDRESSING] for a longer discussion.
+
+3.2.6.  Claim: An address used by an application is the same as the
+        address used for routing
+
+   Some applications assume that the address the application uses is the
+   same as that used by routing.  For example, some applications use raw
+   sockets to read/write packet headers, including the source and
+   destination addresses in the IP header.  As another example, some
+   applications make assumptions about locality (e.g., whether the
+   destination is on the same subnet) by comparing addresses.
+
+   Protocols such as Mobile IPv6 and HIP specifically break this
+   assumption (in an attempt to restore other assumptions as discussed
+   above).  Recently, the IRTF Routing Research Group has been
+   evaluating a number of possible mechanisms, some of which would also
+   break this assumption, while others preserve this assumption near the
+   edges of the network and only break it in the core of the Internet.
+
+   Breaking this assumption is sometimes referred to as an "identifier/
+   locator" split.  However, as originally defined in 1978 ([IEN019],
+   [IEN023]), an address was originally defined as only a locator,
+   whereas names were defined to be the identifiers.  However, the TCP
+   protocol then used addresses as identifiers.
+
+   Finally, in a liberal sense, any tunneling mechanism might be said to
+   break this assumption, although, in practice, applications that make
+   this assumption will continue to work, since the address of the
+   inside of the tunnel is still used for routing as expected.
+
+3.2.7.  Claim: 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 on-link subnet
+   prefix 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.
+
+
+
+Thaler & IAB                  Informational                    [Page 14]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   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 (e.g., [RFC0925], [RFC3069]) 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 and surveys a number of
+   protocols and applications that depend on this assumption.
+   Specifically, some applications assume that, if a destination address
+   is in the same on-link subnet prefix as the local machine, then
+   therefore packets can be sent with TTL=1, or that packets can be
+   received with TTL=255, or link-scoped multicast or broadcast can be
+   used to reach the destination.
+
+3.2.8.  Claim: 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, Section 3.3.4.2 of [RFC1122] 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.
+
+3.2.9.  Claim: An address is part of an on-link subnet prefix
+
+   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, and no on-link subnet prefix existed on the link.  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.  In
+   1998, [RFC2461] introduced the distinction as part of the core IPv6
+   protocol suite.  This topic is discussed further in [ON-OFF-LINK],
+   and [RFC4903] also touches on this topic with respect to the service
+   model seen by applications.
+
+3.2.10.  Discussion
+
+   Section 4.1 of RFC 1958 [RFC1958] states: "In general, user
+   applications should use names rather than addresses".
+
+
+
+
+Thaler & IAB                  Informational                    [Page 15]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   We emphasize the above point, which is too often ignored.  Many
+   commonly used APIs unnecessarily expose addresses to applications
+   that already use names.  Similarly, some protocols are defined to
+   carry addresses, rather than carrying names (instead of or in
+   addition to addresses).  Protocols and applications that are already
+   dependent on a naming system should be designed in such a way that
+   they avoid or minimize any dependence on the notion of addresses.
+
+   One challenge is that many hosts today do not have names that can be
+   resolved.  For example, a host may not have a fully qualified domain
+   name (FQDN) or a Domain Name System (DNS) server that will host its
+   name.
+
+   Applications that, for whatever reason, cannot use names should be
+   IP-version agnostic.
+
+3.3.  Misconceptions about Upper-Layer Extensibility
+
+3.3.1.  Claim: New transport-layer protocols can work across the
+        Internet
+
+   IP was originally designed to support the addition of new transport-
+   layer protocols, and [PROTOCOLS] lists many such protocols.
+
+   However, as discussed in [WAIST-HOURGLASS], NATs and firewalls today
+   break this assumption and often only allow UDP and TCP (or even just
+   HTTP).
+
+   Hence, while new protocols may work from some places, they will not
+   necessarily work from everywhere, such as from behind such NATs and
+   firewalls.
+
+   Since even UDP and TCP may not work from everywhere, it may be
+   necessary for applications to support "HTTP failover" modes.  The use
+   of HTTP as a "transport of last resort" has become common (e.g.,
+   [BOSH] among others) even in situations where it is sub-optimal, such
+   as in real-time communications or where bidirectional communication
+   is required.  Also, the IETF HyBi Working Group is now in the process
+   of designing a standards-based solution for layering other protocols
+   on top of HTTP.  As a result of having to support HTTP failover,
+   applications may have to be engineered to sustain higher latency.
+
+
+
+
+
+
+
+
+
+
+Thaler & IAB                  Informational                    [Page 16]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+3.3.2.  Claim: If one stream between a pair of addresses can get
+        through, then so can another
+
+   Some applications and protocols use multiple upper-layer streams of
+   data between the same pair of addresses and initiated by the same
+   party.  Passive-mode FTP [RFC0959], and RTP [RFC3550], are two
+   examples of such protocols, which use separate streams for data
+   versus control channels.
+
+   Today, there are many reasons why this may not be true.  Firewalls,
+   for example, may selectively allow/block specific protocol numbers
+   and/or values in upper-layer protocol fields (such as port numbers).
+   Similarly, middleboxes such as NATs that create per-stream state may
+   cause other streams to fail once they run out of space to store
+   additional stream state.
+
+3.3.3.  Discussion
+
+   Section 5.1 of [NEWARCH] discusses the primary requirements of the
+   original Internet architecture, including Service Generality.  It
+   states:
+
+      This goal was to support the widest possible range of
+      applications, by supporting a variety of types of service at the
+      transport level.  Services might be distinguished by speed,
+      latency, or reliability, for example.  Service types might include
+      virtual circuit service, which provides reliable, full-duplex byte
+      streams, and also datagram service, which delivers individual
+      packets with no guarantees of reliability or ordering.  The
+      requirement for datagram service was motivated by early ARPAnet
+      experiments with packet speech (using IMP Type 3 messages).
+
+   The reasons that the assumptions in this section are becoming less
+   true are due to network-layer (or higher-layer) techniques being
+   introduced that interfere with the original requirement.  Generally,
+   these are done either in the name of security or as a side effect of
+   solving some other problem such as address shortage.  Work is needed
+   to investigate ways to restore the original behavior while still
+   meeting today's security requirements.
+
+3.4.  Misconceptions about Security
+
+3.4.1.  Claim: Packets are unmodified in transit
+
+   Some applications and upper-layer protocols assume that a packet is
+   unmodified in transit, except for a few well-defined fields (e.g.,
+   TTL).  Examples of this behavior include protocols that define their
+   own integrity-protection mechanism such as a checksum.
+
+
+
+Thaler & IAB                  Informational                    [Page 17]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   This assumption is broken by NATs as discussed in [RFC2993] and other
+   middleboxes that modify the contents of packets.  There are many
+   tunneling technologies (e.g., [RFC4380]) that attempt to restore this
+   assumption to some extent.
+
+   The IPsec architecture [RFC4301] added security to the IP model,
+   providing a way to address this problem without changing
+   applications, although transport-mode IPsec is not currently widely
+   used over the Internet.
+
+3.4.2.  Claim: Packets are private
+
+   The assumption that data is private has never really been true.
+   However, many old applications and protocols (e.g., FTP) transmit
+   passwords or other sensitive data in the clear.
+
+   IPsec provides a way to address this problem without changing
+   applications, although it is not yet widely deployed, and doing
+   encryption/decryption for all packets can be computationally
+   expensive.
+
+3.4.3.  Claim: Source addresses are not forged
+
+   Most applications and protocols use the source address of some
+   incoming packet when generating a response, and hence assume that it
+   has not been forged (and as a result can often be vulnerable to
+   various types of attacks such as reflection attacks).
+
+   Various mechanisms that restore this assumption include, for example,
+   IPsec and Cryptographically Generated Addresses (CGAs) [RFC3972].
+
+3.4.4.  Discussion
+
+   A good discussion of threat models and common tools can be found in
+   [RFC3552].  Protocol designers and applications developers are
+   encouraged to be familiar with that document.
+
+4.  Security Considerations
+
+   This document discusses assumptions about the IP service model made
+   by many applications and upper-layer protocols.  Whenever these
+   assumptions are broken, if the application or upper-layer protocol
+   has some security-related behavior that is based on the assumption,
+   then security can be affected.
+
+
+
+
+
+
+
+Thaler & IAB                  Informational                    [Page 18]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   For example, if an application assumes that binding to the IP address
+   of a "trusted" interface means that it will never receive traffic
+   from an "untrusted" interface, and that assumption is broken (as
+   discussed in Section 3.2.8), then an attacker could get access to
+   private information.
+
+   As a result, great care should be taken when expanding the extent to
+   which an assumption is false.  On the other hand, application and
+   upper-layer protocol developers should carefully consider the impact
+   of basing their security on any of the assumptions enumerated in this
+   document.
+
+   It is also worth noting that many of the changes that have occurred
+   over time (e.g., firewalls, dropping directed broadcasts, etc.) that
+   are discussed in this document were done in the interest of improving
+   security at the expense of breaking some applications.
+
+5.  Conclusion
+
+   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 without impacting any existing
+   applications are much safer than extensions that 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.  The key to maintaining an
+   interoperable Internet is documenting and maintaining invariants that
+   higher layers can depend on, and being very judicious with changes.
+
+   In general, lower-layer protocols should document the contract they
+   provide to higher layers; that is, what assumptions the upper layer
+   can rely on (sometimes this is done in the form of an applicability
+   statement).  Conversely, higher-layer protocols should document the
+   assumptions they rely on from the lower layer (sometimes this is done
+   in the form of requirements).
+
+   We must also recognize that a successful architecture often evolves
+   as success brings growth and as technology moves forward.  As a
+   result, the various assumptions made should be periodically reviewed
+   when updating protocols.
+
+
+
+
+
+
+
+Thaler & IAB                  Informational                    [Page 19]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+6.  Acknowledgements
+
+   Chris Hopps, Dow Street, Phil Hallam-Baker, and others provided
+   helpful discussion on various points that led to this document.  Iain
+   Calder, Brian Carpenter, Jonathan Rosenberg, Erik Nordmark, Alain
+   Durand, and Iljitsch van Beijnum also provided valuable feedback.
+
+7.  IAB Members at the Time of This Writing
+
+   Loa Andersson
+   Gonzalo Camarillo
+   Stuart Cheshire
+   Russ Housley
+   Olaf Kolkman
+   Gregory Lebovitz
+   Barry Leiba
+   Kurtis Lindqvist
+   Andrew Malis
+   Danny McPherson
+   David Oran
+   Dave Thaler
+   Lixia Zhang
+
+8.  IAB Members at the Time of Approval
+
+   Bernard Aboba
+   Marcelo Bagnulo
+   Ross Callon
+   Spencer Dawkins
+   Russ Housley
+   John Klensin
+   Olaf Kolkman
+   Danny McPherson
+   Jon Peterson
+   Andrei Robachevsky
+   Dave Thaler
+   Hannes Tschofenig
+
+
+9.  References
+
+9.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.
+
+
+
+Thaler & IAB                  Informational                    [Page 20]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   [RFC1122]  Braden, R., "Requirements for Internet Hosts -
+              Communication Layers", STD 3, RFC 1122, October 1989.
+
+   [RFC1546]  Partridge, C., Mendez, T., and W. Milliken, "Host
+              Anycasting Service", RFC 1546, November 1993.
+
+   [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.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 2005.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              September 2007.
+
+9.2.  Informative References
+
+   [ANYCAST]  McPherson, D. and D. Oran, "Architectural Considerations
+              of IP Anycast", Work in Progress, February 2010.
+
+   [BOSH]     Paterson, I., Smith, D., Saint-Andre, P., and J. Moffitt,
+              "Bidirectional-streams Over Synchronous HTTP (BOSH)",
+              XEP 0124, 2010,
+              <http://xmpp.org/extensions/xep-0124.html>.
+
+   [IEN019]   Shoch, J., "A note on Inter-Network Naming, Addressing,
+              and Routing", IEN 19, January 1978,
+              <http://www.rfc-editor.org/ien/ien19.txt>.
+
+   [IEN023]   Cohen, D., "On Names, Addresses and Routings", IEN 23,
+              January 1978, <http://www.rfc-editor.org/ien/ien23.txt>.
+
+   [IEN028]   Postel, J., "Draft Internetwork Protocol Specification",
+              IEN 28, February 1978,
+              <http://www.rfc-editor.org/ien/ien28.pdf>.
+
+   [IEN135]   Sunshine, C. and J. Postel, "Addressing Mobile Hosts in
+              the ARPA Internet Environment", IEN 135, March 1980,
+              <http://www.rfc-editor.org/ien/ien135.txt>.
+
+   [MCAST4]   Internet Assigned Numbers Authority, "IPv4 Multicast
+              Addresses",
+              <http://www.iana.org/assignments/multicast-addresses>.
+
+
+
+Thaler & IAB                  Informational                    [Page 21]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   [MCAST6]   Internet Assigned Numbers Authority, "INTERNET PROTOCOL
+              VERSION 6 MULTICAST ADDRESSES",
+              <http://www.iana.org/assignments/
+              ipv6-multicast-addresses>.
+
+   [NEWARCH]  Clark, D., et al., "New Arch: Future Generation Internet
+              Architecture", Air Force Research Laboratory Technical
+              Report AFRL-IF-RS-TR-2004-235, August 2004, <http://
+              www.dtic.mil/cgi-bin/
+              GetTRDoc?AD=ADA426770&Location=U2&doc=GetTRDoc.pdf>.
+
+   [ON-OFF-LINK]
+              Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet
+              Model", Work in Progress, February 2008.
+
+   [PROTOCOLS]
+              Internet Assigned Numbers Authority, "Protocol Numbers",
+              <http://www.iana.org/assignments/protocol-numbers>.
+
+   [REORDER]  Bennett, J., Partridge, C., and N. Shectman, "Packet
+              reordering is not pathological network behavior", IEEE/ACM
+              Transactions on Networking, Vol. 7, No. 6, December 1999.
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, September 1981.
+
+   [RFC0925]  Postel, J., "Multi-LAN address resolution", RFC 925,
+              October 1984.
+
+   [RFC0959]  Postel, J. and J. Reynolds, "File Transfer Protocol",
+              STD 9, RFC 959, October 1985.
+
+   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
+              November 1990.
+
+   [RFC1812]  Baker, F., "Requirements for IP Version 4 Routers",
+              RFC 1812, June 1995.
+
+   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
+              E. Lear, "Address Allocation for Private Internets",
+              BCP 5, RFC 1918, February 1996.
+
+   [RFC1958]  Carpenter, B., "Architectural Principles of the Internet",
+              RFC 1958, June 1996.
+
+   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
+              for IP version 6", RFC 1981, August 1996.
+
+
+
+
+Thaler & IAB                  Informational                    [Page 22]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   [RFC2101]  Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4
+              Address Behaviour Today", RFC 2101, February 1997.
+
+   [RFC2491]  Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6
+              over Non-Broadcast Multiple Access (NBMA) networks",
+              RFC 2491, January 1999.
+
+   [RFC2767]  Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack
+              Hosts using the "Bump-In-the-Stack" Technique (BIS)",
+              RFC 2767, February 2000.
+
+   [RFC2775]  Carpenter, B., "Internet Transparency", RFC 2775,
+              February 2000.
+
+   [RFC2923]  Lahey, K., "TCP Problems with Path MTU Discovery",
+              RFC 2923, September 2000.
+
+   [RFC2979]  Freed, N., "Behavior of and Requirements for Internet
+              Firewalls", RFC 2979, October 2000.
+
+   [RFC2991]  Thaler, D. and C. Hopps, "Multipath Issues in Unicast and
+              Multicast Next-Hop Selection", RFC 2991, November 2000.
+
+   [RFC2993]  Hain, T., "Architectural Implications of NAT", RFC 2993,
+              November 2000.
+
+   [RFC3021]  Retana, A., White, R., Fuller, V., and D. McPherson,
+              "Using 31-Bit Prefixes on IPv4 Point-to-Point Links",
+              RFC 3021, December 2000.
+
+   [RFC3069]  McPherson, D. and B. Dykes, "VLAN Aggregation for
+              Efficient IP Address Allocation", RFC 3069, February 2001.
+
+   [RFC3077]  Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y.
+              Zhang, "A Link-Layer Tunneling Mechanism for
+              Unidirectional Links", RFC 3077, March 2001.
+
+   [RFC3338]  Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A.
+              Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)",
+              RFC 3338, October 2002.
+
+   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
+              Jacobson, "RTP: A Transport Protocol for Real-Time
+              Applications", STD 64, RFC 3550, July 2003.
+
+   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
+              Text on Security Considerations", BCP 72, RFC 3552,
+              July 2003.
+
+
+
+Thaler & IAB                  Informational                    [Page 23]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   [RFC3618]  Fenner, B. and D. Meyer, "Multicast Source Discovery
+              Protocol (MSDP)", RFC 3618, October 2003.
+
+   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
+              in IPv6", RFC 3775, June 2004.
+
+   [RFC3819]  Karn, P., Bormann, C., Fairhurst, G., Grossman, D.,
+              Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L.
+              Wood, "Advice for Internet Subnetwork Designers", BCP 89,
+              RFC 3819, July 2004.
+
+   [RFC3927]  Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
+              Configuration of IPv4 Link-Local Addresses", RFC 3927,
+              May 2005.
+
+   [RFC3972]  Aura, T., "Cryptographically Generated Addresses (CGA)",
+              RFC 3972, March 2005.
+
+   [RFC4007]  Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and
+              B. Zill, "IPv6 Scoped Address Architecture", RFC 4007,
+              March 2005.
+
+   [RFC4380]  Huitema, C., "Teredo: Tunneling IPv6 over UDP through
+              Network Address Translations (NATs)", RFC 4380,
+              February 2006.
+
+   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
+              (HIP) Architecture", RFC 4423, May 2006.
+
+   [RFC4601]  Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
+              "Protocol Independent Multicast - Sparse Mode (PIM-SM):
+              Protocol Specification (Revised)", RFC 4601, August 2006.
+
+   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
+              Services", BCP 126, RFC 4786, December 2006.
+
+   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
+              Discovery", RFC 4821, March 2007.
+
+   [RFC4890]  Davies, E. and J. Mohacsi, "Recommendations for Filtering
+              ICMPv6 Messages in Firewalls", RFC 4890, May 2007.
+
+   [RFC4903]  Thaler, D., "Multi-Link Subnet Issues", RFC 4903,
+              June 2007.
+
+   [RFC4948]  Andersson, L., Davies, E., and L. Zhang, "Report from the
+              IAB workshop on Unwanted Traffic March 9-10, 2006",
+              RFC 4948, August 2007.
+
+
+
+Thaler & IAB                  Informational                    [Page 24]
+
+RFC 6250                Evolution of the IP Model               May 2011
+
+
+   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
+              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
+
+   [RFC5218]  Thaler, D. and B. Aboba, "What Makes For a Successful
+              Protocol?", RFC 5218, July 2008.
+
+   [RFC5694]  Camarillo, G. and IAB, "Peer-to-Peer (P2P) Architecture:
+              Definition, Taxonomies, Examples, and Applicability",
+              RFC 5694, November 2009.
+
+   [SHARED-ADDRESSING]
+              Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
+              Roberts, "Issues with IP Address Sharing", Work
+              in Progress, March 2011.
+
+   [WAIST-HOURGLASS]
+              Rosenberg, J., "UDP and TCP as the New Waist of the
+              Internet Hourglass", Work in Progress, February 2008.
+
+   [WIRELESS]
+              Kotz, D., Newport, C., and C. Elliott, "The mistaken
+              axioms of wireless-network research", Dartmouth College
+              Computer Science Technical Report TR2003-467, July 2003, <
+              http://www.cs.dartmouth.edu/cms_file/SYS_techReport/337/
+              TR2003-467.pdf>.
+
+Authors' Addresses
+
+   Dave Thaler
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+
+   Phone: +1 425 703 8835
+   EMail: dthaler@microsoft.com
+
+
+   Internet Architecture Board
+
+   EMail: iab@iab.org
+
+
+
+
+
+
+
+
+
+
+
+Thaler & IAB                  Informational                    [Page 25]
+