idnits 2.17.1 draft-thaler-ip-model-evolution-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 788. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 799. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 806. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 812. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2008) is 5738 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 1546 ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft Microsoft 4 Expires: January 14, 2009 July 13, 2008 6 Evolution of the IP Model 7 draft-thaler-ip-model-evolution-01.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 14, 2009. 34 Abstract 36 This draft attempts to document various aspects of the IP service 37 model and how it has evolved over time. In particular, it attempts 38 to document the properties of the IP layer as they are seen by upper- 39 layer protocols and applications, and especially properties which 40 were (and at times still are) incorrectly perceived to exist, as well 41 as properties that changing would cause problems. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. The IP Service Model . . . . . . . . . . . . . . . . . . . . . 3 47 2.1. Links and Subnets . . . . . . . . . . . . . . . . . . . . 4 48 3. Common Application Assumptions . . . . . . . . . . . . . . . . 5 49 3.1. Assumptions about routing . . . . . . . . . . . . . . . . 5 50 3.1.1. Connectivity is symmetric . . . . . . . . . . . . . . 5 51 3.1.2. Connectivity is transitive . . . . . . . . . . . . . . 5 52 3.1.3. Multicast is supported within a link . . . . . . . . . 6 53 3.1.4. IPv4 broadcast is supported . . . . . . . . . . . . . 6 54 3.1.5. Multicast/broadcast is less expensive than 55 replicated unicast . . . . . . . . . . . . . . . . . . 7 56 3.1.6. Reordering is rare . . . . . . . . . . . . . . . . . . 7 57 3.1.7. Loss is rare and probabilistic, not deterministic . . 8 58 3.1.8. An end-to-end path exists at a single point in time . 8 59 3.2. Assumptions about addressing . . . . . . . . . . . . . . . 8 60 3.2.1. Addresses are stable over long periods of time . . . . 8 61 3.2.2. A non-multicast/broadcast address identifies a 62 single host over a long period of time . . . . . . . . 9 63 3.2.3. A host has only one address on one interface . . . . . 9 64 3.3. Assumptions about the relationship between routing and 65 addressing . . . . . . . . . . . . . . . . . . . . . . . . 10 66 3.3.1. An address used by an application is the same as 67 the address used for routing . . . . . . . . . . . . . 10 68 3.3.2. A subnet is smaller than a link . . . . . . . . . . . 11 69 3.3.3. Selecting a local address selects the interface . . . 11 70 3.3.4. An address is part of an on-link subnet . . . . . . . 11 71 3.4. Assumptions about upper-layer extensibility . . . . . . . 11 72 3.4.1. New transport-layer protocols can work across the 73 Internet . . . . . . . . . . . . . . . . . . . . . . . 12 74 3.5. Assumptions about security . . . . . . . . . . . . . . . . 12 75 3.5.1. Packets are unmodified in transit . . . . . . . . . . 12 76 3.5.2. Packets are private . . . . . . . . . . . . . . . . . 12 77 3.5.3. Source addresses are not spoofed . . . . . . . . . . . 12 78 4. Impact . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 81 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 82 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 84 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 85 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 86 Intellectual Property and Copyright Statements . . . . . . . . . . 18 88 1. Introduction 90 Since the Internet Protocol was first published as [IEN028] in 1978, 91 IP has provided a network-layer connectivity service to upper-layer 92 protocols and applications. The basic IP service model was 93 documented in the original IEN's (and subsequently the RFC's that 94 obsolete them). However, since the mantra has been "Everything Over 95 IP", the IP service model has evolved significantly over the past 30 96 years to enable new behaviors that the original definition did not 97 envision. For example, by 1989 there was already some confusion and 98 so [RFC1122] clarified many things and extended the model. In 2004, 99 [RFC3819] gave advice to link-layer protocol designers on a number of 100 things that affect upper layers and is the closest in intent to the 101 subject of this document. Today's IP service model is not well 102 documented in a single place, but is either implicit or discussed 103 piecemeal in many different RFCs. As a result, today's IP service 104 model is actually not well known, or at least is often misunderstood. 106 In the early days of IP, changing or extending the basic IP service 107 model was easier since it was not as widely deployed and there were 108 fewer implementations. Today, the ossification of the Internet makes 109 evolving the IP model even more difficult. Thus it is important to 110 understand the evolution of the IP model for two reasons: 111 1. To make it clear what upper-layer protocols and applications can 112 and cannot depend on. There are many myths (or at least beliefs 113 which are no longer true) applications may be based on which are 114 problematic. 115 2. To document lessons for future evolution to take into account. 116 It is important that the service model remain consistent, rather 117 than evolving in two opposing directions. It is sometimes the 118 case in IETF Working Groups today that directions are considered 119 or even taken which would change the IP service model. Doing 120 this without understanding the implications on applications can 121 be dangerous. 123 This draft attempts to document various aspects of the IP service 124 model and how it has evolved over time. In particular, it attempts 125 to document the properties of the IP layer as they are seen by upper- 126 layer protocols and applications, and especially properties which 127 were (and at times still are) incorrectly perceived to exist, as well 128 as properties that changing would cause problems. 130 2. The IP Service Model 132 In this document, we use the term "IP Service Model" to refer to the 133 model exposed by IP to higher-layer protocols and applications. This 134 is depicted in Figure 1 by the horizontal line. 136 +-------------+ +-------------+ 137 | Application | | Application | 138 +------+------+ +------+------+ 139 | | 140 +------+------+ +------+------+ 141 | Upper-Layer | | Upper-Layer | 142 | Protocol | | Protocol | 143 +------+------+ +------+------+ 144 | | 145 ------------------------------------------------------------------ 146 | | 147 +--+--+ +-----+ +--+--+ 148 | IP | | IP | | IP | 149 +--+--+ +--+--+ +--+--+ 150 | | | 151 +-----+------+ +-----+------+ +-----+------+ 152 | Link Layer | | Link Layer | | Link Layer | 153 +-----+------+ +--+-----+---+ +-----+------+ 154 | | | | 155 +---------------------+ +--------------------+ 157 Source Destination 159 IP Service Model 161 Figure 1 163 The foundation of the IP service model today is documented in 164 [RFC0791] section 2.2. Generally speaking, IP provides a 165 connectionless delivery service for variable size packets, which does 166 not guarantee ordering, delivery, or lack of duplication, but is 167 merely best effort. Senders can send to a destination address 168 without signaling a priori, and receivers just listen on an already 169 provisioned address, without signaling a priori. 171 2.1. Links and Subnets 173 Section 2.1 of [RFC4903] discusses the terms "link" and "subnet" with 174 respect to the IP model. 176 A "link" in the IP service model refers to the topological area 177 within which a packet with IPv4 TTL or IPv6 Hop Limit of 1 can be 178 delivered. That is, where no IP-layer forwarding (which entails a 179 TTL/Hop Limit decrement) occurs between two nodes. 181 A "subnet" in the IP service model refers to the topological area 182 within which addresses from the same subnet prefix are assigned to 183 interfaces. 185 3. Common Application Assumptions 187 Below is a list of properties which are often assumed by applications 188 and upper-layer protocol, but which have become less true over time. 190 3.1. Assumptions about routing 192 3.1.1. Connectivity is symmetric 194 Many applications assume that if a host A can contact a host B, then 195 the reverse is also true. Examples of this behavior include request- 196 response patterns, which only requires that reverse connectivity 197 exists after forward connectivity, and callbacks (e.g., as used by 198 the File Transfer Protocol (FTP) [RFC0959]). 200 Originally it was the case that connectivity was symmetric (although 201 the path taken may not be), both within a link and across the 202 Internet. With the advent of technologies such as NATs and 203 firewalls, this can no longer be assumed. However, it is still the 204 case that if a request can be sent, then a reply to that request can 205 generally be received, but an unsolicited request in the other 206 direction may not be received. [RFC2993] discusses this in more 207 detail. 209 There are also links (e.g., satellite) which were defined as 210 unidirectional links and hence an address on such a link results in 211 asymmetric connectivity. [RFC3077] explicitly addresses this problem 212 for multi-homed hosts by tunneling packets over another interface in 213 order to restore symmetric connectivity. 215 Finally, even with common wireless networks such as 802.11, this 216 assumption may not be true, as discussed in [WIRELESS] section 5.5. 218 3.1.2. Connectivity is transitive 220 Many applications assume that if a host A can contact host B, and B 221 can contact C, then host A can contact C. An example of this behavior 222 is applications and protocols that use referrals. 224 Originally it was the case that connectivity was transitive, both 225 within a link and across the Internet. With the advent of 226 technologies such as NATs, and firewalls, this can no longer be 227 assumed across the Internet, but it is often still true within a 228 link. As a result, upper-layer protocols and applications may be 229 relying on transitivity within a link. However, radio technologies 230 such as 802.11 ad-hoc mode violate this assumption. 232 3.1.3. Multicast is supported within a link 234 [RFC1112] introduced multicast to the IP service model. In this 235 evolution, senders still just send to a destination address without 236 signaling a priori, but in contrast to the original IP model, 237 receivers must signal to the network before they can receive traffic 238 to a multicast address. 240 Today, many applications and protocols are defined to use multicast 241 addresses, including protocols for address configuration, service 242 discovery, etc. (See [MCAST4] and [MCAST6] for those that use well- 243 known addresses.) 245 Most of these assume that multicast works within a link, but may or 246 may not function across a wider area. While network-layer multicast 247 works over most link types, there are Non-Broadcast Multi-Access 248 (NBMA) links over which multicast does not work (e.g., X.25, ATM, 249 frame relay, 6to4, ISATAP, Teredo) and this can interfere with some 250 protocols and applications. Similarly, there are links such as 251 802.11 ad-hoc mode where multicast packets may not get delivered to 252 all receivers on the link. [RFC2461] and its successor [RFC4861] 253 both state: 254 "Note that all link types (including NBMA) are expected to provide 255 multicast service for applications that need it (e.g., using 256 multicast servers)." 258 However, not all link types today do meet this expectation. 260 3.1.4. IPv4 broadcast is supported 262 IPv4 broadcast support was originally defined on a link, across a 263 network, and for subnet directed broadcast, and is used by many 264 applications and protocols. For security reasons, however, [RFC2644] 265 deprecated forwarding of broadcast packets, and hence since 1999 266 broadcast can only be relied on within a link. Still, there exist 267 NBMA links over which broadcast does not work, and there exist some 268 "semi-broadcast" links (e.g., 802.11 ad-hoc mode) where broadcast 269 packets may not get delivered to all nodes on the link. Another case 270 where broadcast fails to work is when a /32 or /31 is assigned to a 271 point-to-point interface (e.g., [RFC3021]), leaving no broadcast 272 address available. 274 In addition, the addition of link-scoped multicast to the IP service 275 model to a large extent obsoleted the need for broadcast. It is also 276 worth noting that the broadcast API model used by most platforms 277 allows receivers to just listen on an already provisioned address, 278 without signaling a priori, but in contrast to the unicast API model, 279 senders must signal to the local IP stack (SO_BROADCAST) before they 280 can send traffic to a broadcast address. However, from the network's 281 perspective, the host still sends without signaling a priori. 283 3.1.5. Multicast/broadcast is less expensive than replicated unicast 285 Some applications and upper-layer protocols use multicast or 286 broadcast do so not because they do not know the addresses of 287 receivers, but simply to avoid sending multiple copies of the same 288 packet over the same link. 290 In wired networks, sending a single multicast packet on a link is 291 generally less expensive than sending multiple unicast packets. This 292 may not be true for wireless networks, where implementations can only 293 send multicast at the basic rate, regardless of the negotiated rates 294 of potential receivers. As a result, replicated unicast may achieve 295 much higher throughput across such links than multicast/broadcast 296 traffic. 298 3.1.6. Reordering is rare 300 As discussed in [REORDER], [RFC2991], and [RFC3819] section 15, there 301 are a number of effects of reordering. For example, reordering 302 increases buffering requirements (and jitter) in many applications, 303 and in devices that do packet reassembly. TCP [RFC0793] in 304 particular is adversely affected by reordering since it enters fast- 305 retransmit when three packets are received before a late packet, 306 which drastically lowers throughput. 308 Today there are number of things that cause reordering. First, some 309 routers do per-packet round-robin load balancing, which, depending on 310 the topology, can result in a great deal of reordering. Second, 311 protocols such as Protocol Independent Multicast - Sparse Mode 312 (PIM-SM) [RFC4601], the Multicast Source Discovery Protocol (MSDP) 313 [RFC3618], and Mobile IPv6 [RFC3775] send packets on one path, and 314 then allow immediately switching to a shorter path, resulting in 315 deterministic reordering within the first burst of packets. There 316 are various proposals currently being evaluated by the IETF Routing 317 Research Group that result in similar reordering. 319 An undesirable effect of reordering among initial packets is that 320 some applications choose a destination address by sending a message 321 to each of a number of candidates, picking the first one to respond, 322 and then using that destination for subsequent communication. A high 323 degree of reordering can result in a highly non-optimal destination 324 being chosen, with much longer paths (and hence load on the Internet) 325 and lower throughput. 327 3.1.7. Loss is rare and probabilistic, not deterministic 329 In the original IP model, senders just send, without signaling the 330 network a priori. This works to a degree. In practice, the last hop 331 (and in rare cases, other hops) of the path needs to resolve next hop 332 information (e.g., the link-layer address of the destination) on 333 demand which results in queuing traffic, and if the queue fills up, 334 some traffic gets dropped. This means that bursty sources can be 335 problematic (and indeed a single large packet that gets fragmented 336 becomes such a burst at the last hop). The problem is rarely 337 observed in practice today, either because the resolution within the 338 last hop happens very quickly, or because bursty applications are 339 rarer. However, any protocol that significantly increases such 340 delays or adds new resolutions would be a change to the classic IP 341 model and may adversely impact upper-layer protocols and applications 342 that result in bursts of packets. 344 In addition, mechanisms that simply drop the first packet, rather 345 than queuing it, also break this assumption. Similar to the result 346 of reordering, they can result in a highly non-optional destination 347 being chosen by applications that use the first one to respond. Two 348 examples of mechanisms that appear to do this are network interface 349 cards that support a "Wake-on-LAN" capability where any packet that 350 matches a specified pattern will wake up a machine in a power- 351 conserving mode, but only after dropping the matching packet, and 352 MSDP (since encapsulating data packets is optional). 354 3.1.8. An end-to-end path exists at a single point in time 356 In classic IP, applications assume that an end-to-end path either 357 exists to a destination, or that the packet will be dropped. In 358 addition, IP today tends to assume that the packet delay is 359 relatively short (since the "Time"-to-live is just a hop count, since 360 each hop is assumed to be less than a second), whereas earlier the 361 TTL field was expected to be decremented each second (not just each 362 hop). The IRTF Delay Tolerant Networking Research Group 363 investigating changing this assumption. 365 3.2. Assumptions about addressing 367 3.2.1. Addresses are stable over long periods of time 369 Originally addresses were manually configured on fixed machines, and 370 hence addresses were very stable. With the advent of technologies 371 such as DHCP, roaming, and wireless, addresses can no longer be 372 assumed to be stable for long periods of time. However, the APIs 373 provided to applications today typically still assume stable 374 addresses (e.g., address lifetimes are not exposed to applications 375 that get addresses). This can cause problems today when addresses 376 become stale. 378 For example, many applications resolve names to addresses and then 379 cache them without any notion of lifetime. In fact, the classic name 380 resolution APIs do not even provide applications with the lifetime of 381 entries. 383 Proxy Mobile IPv6 [I-D.ietf-netlmm-proxymip6] tries to restore this 384 assumption to some extent by preserving the same address while 385 roaming around a local area. The issue of roaming between different 386 networks has been known since at least 1980 when [IEN135] proposed a 387 mobility solution that attempted to restore this assumption by adding 388 an additional address that can be used by applications which is 389 stable while roaming anywhere with Internet connectivity. More 390 recent protocols such as Mobile IPv6 (MIP6) [RFC3775] and the Host 391 Identity Protocol (HIP) [RFC4423] follow in this same vein. 393 3.2.2. A non-multicast/broadcast address identifies a single host over 394 a long period of time 396 Many applications and upper-layer protocols maintain a communication 397 session with a destination over some period of time. If that address 398 is reassigned to another host, or if that address is assigned to 399 multiple hosts and the host at which packets arrive changes, such 400 applications can have problems. 402 [RFC1546] introduced the notion of anycast to the IP service model. 403 It states: 404 Because anycasting is stateless and does not guarantee delivery of 405 multiple anycast datagrams to the same system, an application 406 cannot be sure that it is communicating with the same peer in two 407 successive UDP transmissions or in two successive TCP connections 408 to the same anycast address. 409 The obvious solutions to these issues are to require applications 410 which wish to maintain state to learn the unicast address of their 411 peer on the first exchange of UDP datagrams or during the first 412 TCP connection and use the unicast address in future 413 conversations. 415 The issues with anycast are further discussed in [RFC4786]. 417 3.2.3. A host has only one address on one interface 419 Although many applications assume this (e.g., by calling a name 420 resolution function such as gethostbyname and then just using the 421 first address returned), it was never really true to begin with, even 422 if it was the common case. Even [RFC0791] states: 424 "provision must be made for a host to have several physical 425 interfaces to the network with each having several logical 426 internet addresses". 428 However today this assumption is increasingly less true, with the 429 advent of multiple interfaces (e.g., wired and wireless), dual-IPv4/ 430 IPv6 nodes, multiple IPv6 addresses on the same interface (e.g., 431 link-local and global), etc. Similarly, many protocol specifications 432 such as DHCP only describe operations for a single interface, whereas 433 obtaining host-wide configuration from multiple interfaces presents a 434 merging problem for nodes in practice. Too often this problem is 435 simply ignored by Working Groups, and applications and users suffer 436 as a result from poor merging algorithms. 438 One use of protocols such as MIP6 and HIP is to make this assumption 439 somewhat more true by adding an additional "address" that can be the 440 one used by such applications, and the protocol will deal with the 441 complexity of multiple physical interfaces and addresses. 443 3.3. Assumptions about the relationship between routing and addressing 445 3.3.1. An address used by an application is the same as the address 446 used for routing 448 Some applications assume that the address the application uses is the 449 same as that used by routing. For example, some applications use raw 450 sockets to read/write packet headers, including the source and 451 destination addresses in the IP header. As another example, some 452 applications make assumptions about locality (e.g., whether the 453 destination is on the same subnet) by comparing addresses. 455 Protocols such as Mobile IPv6 and HIP specifically break this 456 assumption (in an attempt to restore other assumptions as discussed 457 above). Recently, the IRTF Routing Research Group has been 458 evaluating a number of possible mechanisms, some of which would also 459 break this assumption, while others preserve this assumption near the 460 edges of the network and only break it in the core of the Internet. 462 Breaking this assumption is sometimes referred to as an "identifier/ 463 locator" split. As originally defined in 1978 ([IEN019], [IEN023]), 464 however, an address was originally defined as only a locator, whereas 465 names were defined to be the identifiers. However, the TCP protocol 466 then used addresses as identifiers. 468 Finally, in a liberal sense, any tunneling mechanism might be said to 469 break this assumption, although in practice applications that make 470 this assumption will continue to work. Since the address of the 471 inside of the tunnel is still used for routing as expected. 473 3.3.2. A subnet is smaller than a link 475 In the classic IP model, a "subnet" is smaller than, or equal to, a 476 "link". Destinations with addresses in the same subnet can be 477 reached with TTL (or Hop Count) = 1. Link-scoped multicast packets, 478 and all-ones broadcast packets will be delivered (in a best effort 479 fashion) to all listening nodes on the link. Subnet broadcast 480 packets will be delivered (in a best effort fashion) to all listening 481 nodes in the subnet. There have been some efforts in the past (e.g., 482 [RFC0925], [RFC3069]) to allow multi-link subnets and change the 483 above service model, but the adverse impact on applications that have 484 such assumptions recommend against changing this assumption. 485 [RFC4903] discusses this topic in more detail and surveys a number of 486 protocols and applications that depend on this assumption. 488 3.3.3. Selecting a local address selects the interface 490 Some applications assume that binding to a given local address 491 constrains traffic reception to the interface with that address, and 492 that traffic from that address will go out on that address's 493 interface. However, [RFC1122] section 3.3.4.2 defines two models: 494 the Strong End System (or Strong host) model where this is true, and 495 the Weak End System (or Weak host) model where this is not true. In 496 fact any router is inherently a weak host implementation, since 497 packets can be forwarded between interfaces. 499 3.3.4. An address is part of an on-link subnet 501 To some extent, this was never true, in that there were cases in IPv4 502 where the "mask" was 255.255.255.255, such as on a point-to-point 503 link where the two endpoints had addresses out of unrelated address 504 spaces. However, this didn't stop many platforms and applications 505 from assuming that every address had a "mask" (or prefix) that was 506 on-link. The assumption of whether a subnet is on-link (in which 507 case one can send directly to the destination after using ARP/ND) or 508 off-link (in which case one just sends to a router) has evolved over 509 the years, and it can no longer be assumed that an address has an on- 510 link prefix. In 1998, [RFC2461] introduced the distinction as part 511 of the core IPv6 protocol suite. This topic is discussed further in 512 [I-D.wbeebee-on-link-and-off-link-determination], and [RFC4903] also 513 touches on this topic with respect to the service model seen by 514 applications. 516 3.4. Assumptions about upper-layer extensibility 517 3.4.1. New transport-layer protocols can work across the Internet 519 IP was originally designed to support the addition of new transport- 520 layer protocols, and [PROTOCOLS] lists many such protocols. 522 However, as discussed in [I-D.rosenberg-internet-waist-hourglass], 523 NATs and firewalls today break this assumption and often only allow 524 UDP and TCP (or even just HTTP). 526 3.5. Assumptions about security 528 3.5.1. Packets are unmodified in transit 530 Some applications and upper-layer protocols assume that a packet is 531 unmodified in transit, except for a few well-defined fields (e.g., 532 TTL). Examples of this behavior include protocols that define their 533 own integrity protection mechanism such as a checksum. 535 This assumption is broken by NATs as discussed in [RFC2993] and other 536 middleboxes that modify the contents of packets. There are many 537 tunneling technologies (e.g., [RFC4380]) that attempt to restore this 538 assumption to some extent. 540 The IPsec architecture [RFC4301] added security to the IP model, 541 providing a way to address this problem without changing 542 applications, although it is not currently widely used over the 543 Internet. 545 3.5.2. Packets are private 547 The assumption that data is private has never really been true. 548 However, many old applications and protocols (e.g., FTP) transmit 549 passwords or other sensitive data in the clear. 551 IPsec provides a way to address this problem without changing 552 applications, although it is not yet widely deployed, and doing 553 encryption/decryption for all packets can be computationally 554 expensive. 556 3.5.3. Source addresses are not spoofed 558 Most applications and protocols use the source address of some 559 incoming packet when generating a response, and hence assume that it 560 has not been spoofed (and as a result can often be vulnerable to 561 reflection attachs). 563 Various mechanisms that restore this assumption include, for example, 564 IPsec and Cryptographically Generated Addresses (CGAs) [RFC3972]. 566 4. Impact 568 Because a huge number of applications already exist that use TCP/IP 569 for business-critical operations, any changes to the service model 570 need to be done with extreme care. Extensions that merely add 571 additional optional functionality without impacting any existing 572 applications are much safer than extensions which change one or more 573 of the core assumptions discussed above. Any changes to the above 574 assumptions should only be done in accordance with some mechanism to 575 minimize or mitigate the risks of breaking mission-critical 576 applications. Historically, changes have been done without regard to 577 such considerations and as a result the situation for applications 578 today is already problematic. Key to maintaining an interoperable 579 Internet is documenting and maintaining invariants that higher layers 580 can depend on, and being very judicious with changes. 582 5. Security Considerations 584 This document discusses assumptions about the IP service model made 585 by many applications and upper-layer protocols. Whenever these 586 assumptions are broken, if the application or upper-layer protocol 587 has some security-related behavior that is based on the assumption, 588 then security can be affected. 590 For example, if an application assumes that binding to the IP address 591 of a "trusted" interface means that it will never receive traffic 592 from an "untrusted" interface, and that assumption is broken (as 593 discussed in Section 3.3.3) then an attacker could get access to 594 private information. 596 As a result, great care should be taken when expanding the extent to 597 which an assumption is false. On the other hand, application and 598 upper-layer protocol developers should carefully consider the impact 599 of basing their security on any of the assumptions enumerated in this 600 document. 602 It is also worth noting that many of the changes that have occurred 603 over time (e.g., firewalls, dropping directed broadcasts, etc.) that 604 are discussed in this document were done in the interest of improving 605 security at the expense of breaking some applications. 607 6. IANA Considerations 609 This document has no IANA Actions. 611 7. Acknowledgements 613 Bernard Aboba, Chris Hopps, Kurtis Lindqvist, Danny McPherson, Dow 614 Street, and others provided helpful discussion on various points that 615 led to this document. 617 8. References 619 8.1. Normative References 621 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 622 September 1981. 624 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 625 RFC 1112, August 1989. 627 [RFC1122] Braden, R., "Requirements for Internet Hosts - 628 Communication Layers", STD 3, RFC 1122, October 1989. 630 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 631 Anycasting Service", RFC 1546, November 1993. 633 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 634 Discovery for IP Version 6 (IPv6)", RFC 2461, 635 December 1998. 637 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 638 in Routers", BCP 34, RFC 2644, August 1999. 640 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 641 Internet Protocol", RFC 4301, December 2005. 643 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 644 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 645 September 2007. 647 8.2. Informative References 649 [I-D.ietf-netlmm-proxymip6] 650 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 651 and B. Patil, "Proxy Mobile IPv6", 652 draft-ietf-netlmm-proxymip6-18 (work in progress), 653 May 2008. 655 [I-D.rosenberg-internet-waist-hourglass] 656 Rosenberg, J., "UDP and TCP as the New Waist of the 657 Internet Hourglass", 658 draft-rosenberg-internet-waist-hourglass-00 (work in 659 progress), February 2008. 661 [I-D.wbeebee-on-link-and-off-link-determination] 662 Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 663 Model", 664 draft-wbeebee-on-link-and-off-link-determination-02 (work 665 in progress), February 2008. 667 [IEN019] Shoch, J., "A note on Inter-Network Naming, Addressing, 668 and Routing", IEN 19, January 1978, 669 . 671 [IEN023] Cohen, D., "On Names, Addresses and Routings", IEN 23, 672 January 1978, 673 . 675 [IEN028] Postel, J., "Draft Internetwork Protocol Specification", 676 IEN 28, February 1978, 677 . 679 [IEN135] Sunshine, C. and J. Postel, "Addressing Mobile Hosts in 680 the ARPA Internet Environment", IEN 135, March 1980, 681 . 683 [MCAST4] Internet Assigned Numbers Authority, "IPv4 Multicast 684 Addresses", 685 . 687 [MCAST6] Internet Assigned Numbers Authority, "INTERNET PROTOCOL 688 VERSION 6 MULTICAST ADDRESSES", 689 . 692 [PROTOCOLS] 693 Internet Assigned Numbers Authority, "Protocol Numbers", 694 . 696 [REORDER] Bennett, J., Partridge, C., and N. Shectman, "Packet 697 reordering is not pathological network behavior", IEEE/ACM 698 Transactions on Networking, Vol. 7, No. 6, December 1999. 700 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 701 RFC 793, September 1981. 703 [RFC0925] Postel, J., "Multi-LAN address resolution", RFC 925, 704 October 1984. 706 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 707 STD 9, RFC 959, October 1985. 709 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 710 Multicast Next-Hop Selection", RFC 2991, November 2000. 712 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 713 November 2000. 715 [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, 716 "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", 717 RFC 3021, December 2000. 719 [RFC3069] McPherson, D. and B. Dykes, "VLAN Aggregation for 720 Efficient IP Address Allocation", RFC 3069, February 2001. 722 [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. 723 Zhang, "A Link-Layer Tunneling Mechanism for 724 Unidirectional Links", RFC 3077, March 2001. 726 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 727 Protocol (MSDP)", RFC 3618, October 2003. 729 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 730 in IPv6", RFC 3775, June 2004. 732 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 733 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 734 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 735 RFC 3819, July 2004. 737 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 738 RFC 3972, March 2005. 740 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 741 Network Address Translations (NATs)", RFC 4380, 742 February 2006. 744 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 745 (HIP) Architecture", RFC 4423, May 2006. 747 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 748 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 749 Protocol Specification (Revised)", RFC 4601, August 2006. 751 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 752 Services", BCP 126, RFC 4786, December 2006. 754 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 755 June 2007. 757 [WIRELESS] 758 Kotz, D., Newport, C., and C. Elliott, "The mistaken 759 axioms of wireless-network research", Dartmouth College 760 Computer Science Technical Report TR2003-467, July 2003, 761 . 763 Author's Address 765 Dave Thaler 766 Microsoft Corporation 767 One Microsoft Way 768 Redmond, WA 98052 769 USA 771 Phone: +1 425 703 8835 772 Email: dthaler@microsoft.com 774 Full Copyright Statement 776 Copyright (C) The IETF Trust (2008). 778 This document is subject to the rights, licenses and restrictions 779 contained in BCP 78, and except as set forth therein, the authors 780 retain all their rights. 782 This document and the information contained herein are provided on an 783 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 784 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 785 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 786 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 787 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 788 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 790 Intellectual Property 792 The IETF takes no position regarding the validity or scope of any 793 Intellectual Property Rights or other rights that might be claimed to 794 pertain to the implementation or use of the technology described in 795 this document or the extent to which any license under such rights 796 might or might not be available; nor does it represent that it has 797 made any independent effort to identify any such rights. Information 798 on the procedures with respect to rights in RFC documents can be 799 found in BCP 78 and BCP 79. 801 Copies of IPR disclosures made to the IETF Secretariat and any 802 assurances of licenses to be made available, or the result of an 803 attempt made to obtain a general license or permission for the use of 804 such proprietary rights by implementers or users of this 805 specification can be obtained from the IETF on-line IPR repository at 806 http://www.ietf.org/ipr. 808 The IETF invites any interested party to bring to its attention any 809 copyrights, patents or patent applications, or other proprietary 810 rights that may cover technology that may be required to implement 811 this standard. Please address the information to the IETF at 812 ietf-ipr@ietf.org.