idnits 2.17.1 draft-iab-ip-model-evolution-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 280 has weird spacing: '...onse to data ...' == Line 597 has weird spacing: '...tion of physi...' -- 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 (October 25, 2010) is 4926 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) == Outdated reference: A later version (-12) exists of draft-iab-anycast-arch-implications-00 == Outdated reference: A later version (-05) exists of draft-ietf-intarea-shared-addressing-issues-02 -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- 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: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Thaler 3 Internet-Draft IAB 4 Intended status: Informational October 25, 2010 5 Expires: April 28, 2011 7 Evolution of the IP Model 8 draft-iab-ip-model-evolution-02.txt 10 Abstract 12 This draft attempts to document various aspects of the IP service 13 model and how it has evolved over time. In particular, it attempts 14 to document the properties of the IP layer as they are seen by upper- 15 layer protocols and applications, and especially properties which 16 were (and at times still are) incorrectly perceived to exist, as well 17 as properties that would cause problems if changed. Finally, it 18 provides some guidance to protocol designers and implementers. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 28, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2. The IP Service Model . . . . . . . . . . . . . . . . . . . . . 5 56 2.1. Links and Subnets . . . . . . . . . . . . . . . . . . . . 6 57 3. Common Application Assumptions . . . . . . . . . . . . . . . . 7 58 3.1. Assumptions about routing . . . . . . . . . . . . . . . . 7 59 3.1.1. Reachability is symmetric . . . . . . . . . . . . . . 7 60 3.1.2. Reachability is transitive . . . . . . . . . . . . . . 8 61 3.1.3. Error messages can be received in response to 62 data packets . . . . . . . . . . . . . . . . . . . . . 8 63 3.1.4. Multicast is supported within a link . . . . . . . . . 9 64 3.1.5. IPv4 broadcast is supported . . . . . . . . . . . . . 9 65 3.1.6. Multicast/broadcast is less expensive than 66 replicated unicast . . . . . . . . . . . . . . . . . . 10 67 3.1.7. The end-to-end latency of the first packet to a 68 destination is typical . . . . . . . . . . . . . . . . 10 69 3.1.8. Reordering is rare . . . . . . . . . . . . . . . . . . 10 70 3.1.9. Loss is rare and probabilistic, not deterministic . . 11 71 3.1.10. An end-to-end path exists at a single point in time . 11 72 3.1.11. Discussion . . . . . . . . . . . . . . . . . . . . . . 12 73 3.2. Assumptions about addressing . . . . . . . . . . . . . . . 13 74 3.2.1. Addresses are stable over long periods of time . . . . 13 75 3.2.2. A host has only one address on one interface . . . . . 13 76 3.2.3. A non-multicast/broadcast address identifies a 77 single host over a long period of time . . . . . . . . 14 78 3.2.4. An address can be used as an indication of 79 physical location . . . . . . . . . . . . . . . . . . 15 80 3.2.5. An address used by an application is the same as 81 the address used for routing . . . . . . . . . . . . . 15 82 3.2.6. A subnet is smaller than a link . . . . . . . . . . . 16 83 3.2.7. Selecting a local address selects the interface . . . 16 84 3.2.8. An address is part of an on-link subnet prefix . . . . 16 85 3.2.9. Discussion . . . . . . . . . . . . . . . . . . . . . . 17 86 3.3. Assumptions about upper-layer extensibility . . . . . . . 17 87 3.3.1. New transport-layer protocols can work across the 88 Internet . . . . . . . . . . . . . . . . . . . . . . . 17 89 3.3.2. If one stream between a pair of addresses can get 90 through, then so can another . . . . . . . . . . . . . 17 91 3.3.3. Discussion . . . . . . . . . . . . . . . . . . . . . . 18 92 3.4. Assumptions about security . . . . . . . . . . . . . . . . 18 93 3.4.1. Packets are unmodified in transit . . . . . . . . . . 18 94 3.4.2. Packets are private . . . . . . . . . . . . . . . . . 19 95 3.4.3. Source addresses are not forged . . . . . . . . . . . 19 96 3.4.4. Discussion . . . . . . . . . . . . . . . . . . . . . . 19 97 4. Security Considerations . . . . . . . . . . . . . . . . . . . 19 98 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 99 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 100 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 101 8. IAB Members at the time of this writing . . . . . . . . . . . 21 102 9. IAB Members at expected time of approval . . . . . . . . . . . 21 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 10.1. Normative References . . . . . . . . . . . . . . . . . . . 21 105 10.2. Informative References . . . . . . . . . . . . . . . . . . 22 106 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26 108 1. Introduction 110 Since the Internet Protocol was first published as [IEN028] in 1978, 111 IP has provided a network-layer connectivity service to upper-layer 112 protocols and applications. The basic IP service model was 113 documented in the original IEN's (and subsequently in the RFC's that 114 obsolete them). However, since the mantra has been "Everything Over 115 IP", the IP service model has evolved significantly over the past 30 116 years to enable new behaviors that the original definition did not 117 envision. For example, by 1989 there was already some confusion and 118 so [RFC1122] clarified many things and extended the model. In 2004, 119 [RFC3819] gave advice to link-layer protocol designers on a number of 120 issues that affect upper layers and is the closest in intent to this 121 document. Today's IP service model is not well documented in a 122 single place, but is either implicit or discussed piecemeal in many 123 different RFCs. As a result, today's IP service model is actually 124 not well known, or at least is often misunderstood. 126 In the early days of IP, changing or extending the basic IP service 127 model was easier since it was not as widely deployed and there were 128 fewer implementations. Today, the ossification of the Internet makes 129 evolving the IP model even more difficult. Thus it is important to 130 understand the evolution of the IP model for two reasons: 132 1. To make it clear what upper-layer protocols and applications can 133 and cannot depend on. There are many myths (or at least beliefs 134 that are no longer true) on which applications may be based, and 135 which are problematic. 136 2. To document lessons for future evolution to take into account. 137 It is important that the service model remain consistent, rather 138 than evolving in two opposing directions. It is sometimes the 139 case in IETF Working Groups today that directions are considered 140 or even taken which would change the IP service model. Doing 141 this without understanding the implications on applications can 142 be dangerous. 144 This draft attempts to document various aspects of the IP service 145 model and how it has evolved over time. In particular, it attempts 146 to document the properties of the IP layer, as seen by upper-layer 147 protocols and applications, especially properties that were (and at 148 times still are) incorrectly perceived to exist. It also highlights 149 properties which would cause problems if changed. 151 2. The IP Service Model 153 In this document, we use the term "IP Service Model" to refer to the 154 model exposed by IP to higher-layer protocols and applications. This 155 is depicted in Figure 1 by the horizontal line. 157 +-------------+ +-------------+ 158 | Application | | Application | 159 +------+------+ +------+------+ 160 | | 161 +------+------+ +------+------+ 162 | Upper-Layer | | Upper-Layer | 163 | Protocol | | Protocol | 164 +------+------+ +------+------+ 165 | | 166 ------------------------------------------------------------------ 167 | | 168 +--+--+ +-----+ +--+--+ 169 | IP | | IP | | IP | 170 +--+--+ +--+--+ +--+--+ 171 | | | 172 +-----+------+ +-----+------+ +-----+------+ 173 | Link Layer | | Link Layer | | Link Layer | 174 +-----+------+ +--+-----+---+ +-----+------+ 175 | | | | 176 +---------------------+ +--------------------+ 178 Source Destination 180 IP Service Model 182 Figure 1 184 The foundation of the IP service model today is documented in 185 [RFC0791] section 2.2. Generally speaking, IP provides a 186 connectionless delivery service for variable size packets, which does 187 not guarantee ordering, delivery, or lack of duplication, but is 188 merely best effort (although some packets may get better service than 189 others). Senders can send to a destination address without signaling 190 a priori, and receivers just listen on an already provisioned 191 address, without signaling a priori. 193 Architectural principles of the IP model are further discussed in 194 [RFC1958] and in [NEWARCH] sections 5 and 6. 196 2.1. Links and Subnets 198 Section 2.1 of [RFC4903] discusses the terms "link" and "subnet" with 199 respect to the IP model. 201 A "link" in the IP service model refers to the topological area 202 within which a packet with an IPv4 TTL or IPv6 Hop Limit of 1 can be 203 delivered. That is, where no IP-layer forwarding (which entails a 204 TTL/Hop Limit decrement) occurs between two nodes. 206 A "subnet" in the IP service model refers to the topological area 207 within which addresses from the same subnet prefix are assigned to 208 interfaces. 210 3. Common Application Assumptions 212 Below is a list of properties which are often assumed by applications 213 and upper-layer protocol, but which have become less true over time. 215 3.1. Assumptions about routing 217 3.1.1. Reachability is symmetric 219 Many applications assume that if a host A can contact a host B, then 220 the reverse is also true. Examples of this behavior include request- 221 response patterns, which require reverse reachability only after 222 forward reachability, as well as callbacks (e.g., as used by the File 223 Transfer Protocol (FTP) [RFC0959]). 225 Originally it was the case that reachability was symmetric (although 226 the path taken may not be), both within a link and across the 227 Internet. With the advent of technologies such as Network Address 228 Translators (NATs) and firewalls (as in the following example 229 figure), this can no longer be assumed. Today, host-to-host 230 connectivity is challenging if not impossible in general. It is 231 relatively easy to initiate communication from hosts (A-E in the 232 example diagram) to servers (S), but not vice versa, nor between 233 hosts A-E. For a longer discussion on peer-to-peer connectivity see 234 [RFC5694] Appendix A. 236 __________ ___ ___ 237 / \ ___ ___ / \ ____|FW |__A 238 / \ ___ / \ _____|NAT|__| | |___| 239 | |__|NAT|__| | |___| | |__B 240 | | |___| | |__C \___/ 241 | | \___/ ___ 242 S__| Internet | ___ ___ / \ 243 | | ___ / \ _____|NAT|__| |__D 244 | |__|FW |__| | |___| | | 245 | | |___| | |__E \___/ 246 \ / \___/ 247 \__________/ 249 Figure 2 251 However, it is still the case that if a request can be sent, then a 252 reply to that request can generally be received, but an unsolicited 253 request in the other direction may not be received. [RFC2993] 254 discusses this in more detail. 256 There are also links (e.g., satellite) that were defined as 257 unidirectional links and hence an address on such a link results in 258 asymmetric reachability. [RFC3077] explicitly addresses this problem 259 for multi-homed hosts by tunneling packets over another interface in 260 order to restore symmetric reachability. 262 Finally, even with common wireless networks such as 802.11, this 263 assumption may not be true, as discussed in [WIRELESS] section 5.5. 265 3.1.2. Reachability is transitive 267 Many applications assume that if a host A can contact host B, and B 268 can contact C, then host A can contact C. Examples of this behavior 269 include applications and protocols that use referrals. 271 Originally it was the case that reachability was transitive, both 272 within a link and across the Internet. With the advent of 273 technologies such as NATs and firewalls, this can no longer be 274 assumed across the Internet, but it is often still true within a 275 link. As a result, upper-layer protocols and applications may be 276 relying on transitivity within a link. However, some radio 277 technologies, such as 802.11 ad-hoc mode, violate this assumption 278 within a link. 280 3.1.3. Error messages can be received in response to data packets 282 Some upper-layer protocols and applications assume that ICMP error 283 messages will be received in response to packets sent that cannot be 284 delivered. Examples of this include the use of Path MTU Discovery 285 [RFC1191][RFC1981]) relying on messages indicating packets were too 286 big, and traceroute and the use of expanding ring search [RFC1812] 287 relying on messages indicating packets reached their maximum hop 288 count limit. 290 Originally this assumption largely held, but many ICMP senders then 291 chose to rate-limit responses, and many firewalls now block ICMP 292 messages. For a longer discussion, see [RFC2923] section 2.1. 294 This led to an alternate mechanism for Path MTU Discovery that does 295 not rely on this assumption being true [RFC4821], and guidance to 296 firewall administrators ([RFC2979] section 3.1.1 and [RFC4890]). 298 3.1.4. Multicast is supported within a link 300 [RFC1112] introduced multicast to the IP service model. In this 301 evolution, senders still just send to a destination address without 302 signaling a priori, but in contrast to the original IP model, 303 receivers must signal to the network before they can receive traffic 304 to a multicast address. 306 Today, many applications and protocols use multicast addresses, 307 including protocols for address configuration, service discovery, 308 etc. (See [MCAST4] and [MCAST6] for those that use well-known 309 addresses.) 311 Most of these only assume that multicast works within a link, and may 312 or may not function across a wider area. While network-layer 313 multicast works over most link types, there are Non-Broadcast Multi- 314 Access (NBMA) links over which multicast does not work (e.g., X.25, 315 ATM, frame relay, 6to4, ISATAP, Teredo) and this can interfere with 316 some protocols and applications. Similarly, there are links such as 317 802.11 ad-hoc mode where multicast packets may not get delivered to 318 all receivers on the link. [RFC2461] and its successor [RFC4861] 319 both state: 320 "Note that all link types (including NBMA) are expected to provide 321 multicast service for applications that need it (e.g., using 322 multicast servers)." 324 However, not all link types today meet this expectation. 326 3.1.5. IPv4 broadcast is supported 328 IPv4 broadcast support was originally defined on a link, across a 329 network, and for subnet directed broadcast, and is used by many 330 applications and protocols. For security reasons, however, [RFC2644] 331 deprecated forwarding of broadcast packets. Thus, since 1999, 332 broadcast can only be relied on within a link. Still, there exist 333 NBMA links over which broadcast does not work, and there exist some 334 "semi-broadcast" links (e.g., 802.11 ad-hoc mode) where broadcast 335 packets may not get delivered to all nodes on the link. Another case 336 where broadcast fails to work is when a /32 or /31 is assigned to a 337 point-to-point interface (e.g., [RFC3021]), leaving no broadcast 338 address available. 340 The addition of link-scoped multicast to the IP service model to a 341 large extent obsoleted the need for broadcast. It is also worth 342 noting that the broadcast API model used by most platforms allows 343 receivers to just listen on an already provisioned address, without 344 signaling a priori, but in contrast to the unicast API model, senders 345 must signal to the local IP stack (SO_BROADCAST) before they can send 346 traffic to a broadcast address. However, from the network's 347 perspective, the host still sends without signaling a priori. 349 3.1.6. Multicast/broadcast is less expensive than replicated unicast 351 Some applications and upper-layer protocols that use multicast or 352 broadcast do so not because they do not know the addresses of 353 receivers, but simply to avoid sending multiple copies of the same 354 packet over the same link. 356 In wired networks, sending a single multicast packet on a link is 357 generally less expensive than sending multiple unicast packets. This 358 may not be true for wireless networks, where implementations can only 359 send multicast at the basic rate, regardless of the negotiated rates 360 of potential receivers. As a result, replicated unicast may achieve 361 much higher throughput across such links than multicast/broadcast 362 traffic. 364 3.1.7. The end-to-end latency of the first packet to a destination is 365 typical 367 Many applications and protocols choose a destination address by 368 sending a message to each of a number of candidates, picking the 369 first one to respond, and then using that destination for subsequent 370 communication. If the end-to-end latency of the first packet to each 371 destination is atypical, this can result in a highly non-optimal 372 destination being chosen, with much longer paths (and hence higher 373 load on the Internet) and lower throughput. 375 Today, there are a number of reasons this is not true. First, when 376 sending to a new destination there may be some startup latency 377 resulting from the link-layer or network-layer mechanism in use, such 378 as ARP resolution for instance. In addition, the first packet may 379 follow a different path from subsequent packets. For example, 380 protocols such as Mobile IPv6 [RFC3775], Protocol Independent 381 Multicast - Sparse Mode (PIM-SM) [RFC4601], and the Multicast Source 382 Discovery Protocol (MSDP) [RFC3618] send packets on one path, and 383 then allow immediately switching to a shorter path, resulting in a 384 large latency difference. There are various proposals currently 385 being evaluated by the IETF Routing Research Group that result in 386 similar path switching. 388 3.1.8. Reordering is rare 390 As discussed in [REORDER], [RFC2991], and [RFC3819] section 15, there 391 are a number of effects of reordering. For example, reordering 392 increases buffering requirements (and jitter) in many applications, 393 and in devices that do packet reassembly. TCP [RFC0793] in 394 particular is adversely affected by reordering, since it enters fast- 395 retransmit when three packets are received before a late packet, 396 which drastically lowers throughput. Finally, some NATs and 397 firewalls assume that the initial fragment arrives first, resulting 398 in packet loss when this is not the case. 400 Today there are number of things that cause reordering. For example, 401 some routers do per-packet round-robin load balancing, which, 402 depending on the topology, can result in a great deal of reordering. 403 As another example, when a packet is fragmented at the sender, some 404 hosts send the last fragment first. Finally, as discussed in 405 Section 3.1.7, protocols that do path switching after the first 406 packet result in deterministic reordering within the first burst of 407 packets. 409 3.1.9. Loss is rare and probabilistic, not deterministic 411 In the original IP model, senders just send, without signaling the 412 network a priori. This works to a degree. In practice, the last hop 413 (and in rare cases, other hops) of the path needs to resolve next hop 414 information (e.g., the link-layer address of the destination) on 415 demand which results in queuing traffic, and if the queue fills up, 416 some traffic gets dropped. This means that bursty sources can be 417 problematic (and indeed a single large packet that gets fragmented 418 becomes such a burst). The problem is rarely observed in practice 419 today, either because the resolution within the last hop happens very 420 quickly, or because bursty applications are rarer. However, any 421 protocol that significantly increases such delays or adds new 422 resolutions would be a change to the classic IP model and may 423 adversely impact upper-layer protocols and applications that result 424 in bursts of packets. 426 In addition, mechanisms that simply drop the first packet, rather 427 than queuing it, also break this assumption. Similar to the result 428 of reordering, they can result in a highly non-optimal destination 429 being chosen by applications that use the first one to respond. Two 430 examples of mechanisms that appear to do this are network interface 431 cards that support a "Wake-on-LAN" capability where any packet that 432 matches a specified pattern will wake up a machine in a power- 433 conserving mode, but only after dropping the matching packet, and 434 MSDP, where encapsulating data packets is optional, but doing so 435 enables bursty sources to be accommodated while a multicast tree is 436 built back to the source's domain. 438 3.1.10. An end-to-end path exists at a single point in time 440 In classic IP, applications assume that either an end-to-end path 441 exists to a destination, or that the packet will be dropped. In 442 addition, IP today tends to assume that the packet delay is 443 relatively short (since the "Time"-to-live is just a hop count). In 444 IP's earlier history, the TTL field was expected to also be 445 decremented each second (not just each hop). 447 This assumption is still true in general today. However, the IRTF 448 Delay Tolerant Networking Research Group is investigating ways for 449 applications to use IP in networks where this assumption is not true, 450 such as store-and-forward networks (e.g., packets carried by vehicles 451 or animals). 453 3.1.11. Discussion 455 The reasons why assumptions listed above are increasingly less true 456 can be divided into two categories: effects caused by attributes of 457 link-layer technologies, and effects caused by network-layer 458 technologies. 460 RFC 3819 [RFC3819] gives advice to link-layer protocol designers to 461 minimize these effects. Generally the link-layer causes are not 462 intentionally trying to break IP, but rather adding IP over the 463 technology introduces the problem. Hence where the link-layer 464 protocol itself does not do so, when specifying how IP is defined 465 over such a link protocol, designers should compensate to the maximum 466 extent possible. As examples, [RFC3077] and [RFC2491] compensate for 467 lack of symmetric reachability and lack of link-layer multicast, 468 respectively. That is, when IP is defined over a link type, the 469 protocol designers should attempt to restore the assumptions listed 470 in this document. For example, since an implementation can 471 distinguish between 802.11 ad hoc mode vs. infrastructure mode, it 472 may be possible to define a mechanism below IP to compensate for the 473 lack of transitivity over such links. 475 At the network layer, as a general principle, we believe that 476 reachability is good. For security reasons ([RFC4948]), however, it 477 is desirable to restrict reachability by unauthorized parties; indeed 478 IPsec, an integral part of the IP model, provides one means to do so. 479 Where there are issues with asymmetry, non-transitivity, and so 480 forth, which are not direct results of restricting reachability to 481 only authorized parties (for some definition of authorized), the IETF 482 should attempt to avoid or solve such issues. Similar to the 483 principle outlined in [RFC1958] section 3.9, the general theme when 484 defining a protocol is to be liberal in what effects you accept, and 485 conservative in what effects you cause. 487 However, in being liberal in what effects you accept, it is also 488 important to remember that diagnostics are important, and being too 489 liberal can mask problems. Thus a tussle exists between the desire 490 to provide a better experience to one's own users or applications and 491 thus be more successful ([RFC5218]), vs. the desire to put pressure 492 on getting problems fixed. One solution is to provide a separate 493 "pedantic mode" that can be enabled to see the problems rather than 494 mask them. 496 3.2. Assumptions about addressing 498 3.2.1. Addresses are stable over long periods of time 500 Originally addresses were manually configured on fixed machines, and 501 hence addresses were very stable. With the advent of technologies 502 such as DHCP, roaming, and wireless, addresses can no longer be 503 assumed to be stable for long periods of time ([RFC3775] section 504 4.2). However, the APIs provided to applications today typically 505 still assume stable addresses (e.g., address lifetimes are not 506 exposed to applications that get addresses). This can cause problems 507 today when addresses become stale. 509 For example, many applications resolve names to addresses and then 510 cache them without any notion of lifetime. In fact, the classic name 511 resolution APIs do not even provide applications with the lifetime of 512 entries. 514 Proxy Mobile IPv6 [RFC5213] tries to restore this assumption to some 515 extent by preserving the same address while roaming around a local 516 area. The issue of roaming between different networks has been known 517 since at least 1980 when [IEN135] proposed a mobility solution that 518 attempted to restore this assumption by adding an additional address 519 that can be used by applications which is stable while roaming 520 anywhere with Internet connectivity. More recent protocols such as 521 Mobile IPv6 (MIP6) [RFC3775] and the Host Identity Protocol (HIP) 522 [RFC4423] follow in this same vein. 524 3.2.2. A host has only one address on one interface 526 Although many applications assume this (e.g., by calling a name 527 resolution function such as gethostbyname and then just using the 528 first address returned), it was never really true to begin with, even 529 if it was the common case. Even [RFC0791] states: 530 "provision must be made for a host to have several physical 531 interfaces to the network with each having several logical 532 internet addresses". 534 However today this assumption is increasingly less true, with the 535 advent of multiple interfaces (e.g., wired and wireless), dual-IPv4/ 536 IPv6 nodes, multiple IPv6 addresses on the same interface (e.g., 537 link-local and global), etc. Similarly, many protocol specifications 538 such as DHCP only describe operations for a single interface, whereas 539 obtaining host-wide configuration from multiple interfaces presents a 540 merging problem for nodes in practice. Too often this problem is 541 simply ignored by Working Groups, and applications and users suffer 542 as a result from poor merging algorithms. 544 One use of protocols such as MIP6 and HIP is to make this assumption 545 somewhat more true by adding an additional "address" that can be the 546 one used by such applications, and the protocol will deal with the 547 complexity of multiple physical interfaces and addresses. 549 3.2.3. A non-multicast/broadcast address identifies a single host over 550 a long period of time 552 Many applications and upper-layer protocols maintain a communication 553 session with a destination over some period of time. If that address 554 is reassigned to another host, or if that address is assigned to 555 multiple hosts and the host at which packets arrive changes, such 556 applications can have problems. 558 In addition, many security mechanisms and configurations assume that 559 one can block traffic by IP address, implying that a single attacker 560 can be identified by IP address. If that IP address can also 561 identify many legitimate hosts, apply such a block can result in 562 denial-of-service. 564 [RFC1546] introduced the notion of anycast to the IP service model. 565 It states: 566 Because anycasting is stateless and does not guarantee delivery of 567 multiple anycast datagrams to the same system, an application 568 cannot be sure that it is communicating with the same peer in two 569 successive UDP transmissions or in two successive TCP connections 570 to the same anycast address. 571 The obvious solutions to these issues are to require applications 572 which wish to maintain state to learn the unicast address of their 573 peer on the first exchange of UDP datagrams or during the first 574 TCP connection and use the unicast address in future 575 conversations. 577 The issues with anycast are further discussed in [RFC4786] and 578 [I-D.iab-anycast-arch-implications]. 580 Another mechanism by which multiple hosts use the same address is as 581 a result of scoped addresses, as defined for both IPv4 [RFC1918] 582 [RFC3927] and IPv6 [RFC4007]. Because such addresses can be reused 583 within multiple networks, hosts in different networks can use the 584 same address. As a result, a host that is multihomed to two such 585 networks cannot use the destination address to uniquely identify a 586 peer. For example, a host can no longer use a 5-tuple to uniquely 587 identify a TCP connection. This is why IPv6 added the concept of a 588 "zone index". 590 Yet another example is that, in some high-availability solutions, one 591 host takes over the IP address of another failed host. 593 See [RFC2101], [RFC2775], and 594 [I-D.ietf-intarea-shared-addressing-issues] for additional discussion 595 on address uniqueness. 597 3.2.4. An address can be used as an indication of physical location 599 Some applications attempt to use an address to infer some information 600 about the physical location of the host with that address. For 601 example, geo-location services are often used to provide targeted 602 content or ads. 604 Various forms of tunneling have made this assumption less true, and 605 this will become increasingly less true as the use of IPv4 NATs for 606 large networks continues to increase. See 607 [I-D.ietf-intarea-shared-addressing-issues] section 7 for a longer 608 discussion. 610 3.2.5. An address used by an application is the same as the address 611 used for routing 613 Some applications assume that the address the application uses is the 614 same as that used by routing. For example, some applications use raw 615 sockets to read/write packet headers, including the source and 616 destination addresses in the IP header. As another example, some 617 applications make assumptions about locality (e.g., whether the 618 destination is on the same subnet) by comparing addresses. 620 Protocols such as Mobile IPv6 and HIP specifically break this 621 assumption (in an attempt to restore other assumptions as discussed 622 above). Recently, the IRTF Routing Research Group has been 623 evaluating a number of possible mechanisms, some of which would also 624 break this assumption, while others preserve this assumption near the 625 edges of the network and only break it in the core of the Internet. 627 Breaking this assumption is sometimes referred to as an "identifier/ 628 locator" split. As originally defined in 1978 ([IEN019], [IEN023]), 629 however, an address was originally defined as only a locator, whereas 630 names were defined to be the identifiers. However, the TCP protocol 631 then used addresses as identifiers. 633 Finally, in a liberal sense, any tunneling mechanism might be said to 634 break this assumption, although in practice applications that make 635 this assumption will continue to work. Since the address of the 636 inside of the tunnel is still used for routing as expected. 638 3.2.6. A subnet is smaller than a link 640 In the classic IP model, a "subnet" is smaller than, or equal to, a 641 "link". Destinations with addresses in the same on-link subnet 642 prefix can be reached with TTL (or Hop Count) = 1. Link-scoped 643 multicast packets, and all-ones broadcast packets will be delivered 644 (in a best effort fashion) to all listening nodes on the link. 645 Subnet broadcast packets will be delivered (in a best effort fashion) 646 to all listening nodes in the subnet. There have been some efforts 647 in the past (e.g., [RFC0925], [RFC3069]) to allow multi-link subnets 648 and change the above service model, but the adverse impact on 649 applications that have such assumptions recommend against changing 650 this assumption. 652 [RFC4903] discusses this topic in more detail and surveys a number of 653 protocols and applications that depend on this assumption. 654 Specifically, some applications assume that, if a destination address 655 is in the same on-link subnet prefix as the local machine, then 656 therefore packets can be sent with TTL=1, or that packets can be 657 received with TTL=255, or link-scoped multicast or broadcast can be 658 used to reach the destination. 660 3.2.7. Selecting a local address selects the interface 662 Some applications assume that binding to a given local address 663 constrains traffic reception to the interface with that address, and 664 that traffic from that address will go out on that address's 665 interface. However, [RFC1122] section 3.3.4.2 defines two models: 666 the Strong End System (or Strong host) model where this is true, and 667 the Weak End System (or Weak host) model where this is not true. In 668 fact any router is inherently a weak host implementation, since 669 packets can be forwarded between interfaces. 671 3.2.8. An address is part of an on-link subnet prefix 673 To some extent, this was never true, in that there were cases in IPv4 674 where the "mask" was 255.255.255.255, such as on a point-to-point 675 link where the two endpoints had addresses out of unrelated address 676 spaces, and no on-link subnet prefix exists on the link. However, 677 this didn't stop many platforms and applications from assuming that 678 every address had a "mask" (or prefix) that was on-link. The 679 assumption of whether a subnet is on-link (in which case one can send 680 directly to the destination after using ARP/ND) or off-link (in which 681 case one just sends to a router) has evolved over the years, and it 682 can no longer be assumed that an address has an on-link prefix. In 683 1998, [RFC2461] introduced the distinction as part of the core IPv6 684 protocol suite. This topic is discussed further in 685 [I-D.wbeebee-on-link-and-off-link-determination], and [RFC4903] also 686 touches on this topic with respect to the service model seen by 687 applications. 689 3.2.9. Discussion 691 RFC 1958 [RFC1958] section 4.1 states: "In general, user applications 692 should use names rather than addresses." 694 We emphasize the above point, which is too often ignored. Many 695 commonly used APIs unnecessarily expose addresses to applications 696 that already use names. Similarly, some protocols are defined to 697 carry addresses, rather than carrying names (instead of or in 698 addition to addresses). Protocols and applications that are already 699 dependent on a naming system should be designed in such a way that 700 they avoid or minimize any dependence on the notion of addresses. 702 One challenge is that many hosts today do not have names that can be 703 resolved. For example, a host may not have a fully-qualfied domain 704 name (FQDN) or a Domain Name System (DNS) server that will host its 705 name. 707 3.3. Assumptions about upper-layer extensibility 709 3.3.1. New transport-layer protocols can work across the Internet 711 IP was originally designed to support the addition of new transport- 712 layer protocols, and [PROTOCOLS] lists many such protocols. 714 However, as discussed in [I-D.rosenberg-internet-waist-hourglass], 715 NATs and firewalls today break this assumption and often only allow 716 UDP and TCP (or even just HTTP). 718 3.3.2. If one stream between a pair of addresses can get through, then 719 so can another 721 Some applications and protocols use multiple upper-layer streams of 722 data between the same pair of addresses, and initiated by the same 723 party. Passive-mode FTP [RFC0959], and RTP [RFC3550], are two 724 examples of such protocols, which use separate streams for data vs. 725 control channels. 727 Today, there are many reasons this may not be true. Firewalls, for 728 example, may selectively allow/block specific protocol numbers and/or 729 values in upper-layer protocol fields (such as port numbers). 731 Similarly, middleboxes such as NATs that create per-stream state may 732 cause other streams to fail once they run out of space to store 733 additional stream state. 735 3.3.3. Discussion 737 [NEWARCH] section 5.1 discusses the primary requirements of the 738 original internet architecture, including Service Generality. It 739 states: 741 "This goal was to support the widest possible range of applications, 742 by supporting a variety of types of service at the transport level. 743 Services might be distinguished by speed, latency, or reliability, 744 for example. Service types might include virtual circuit service, 745 which provides reliable, full-duplex byte streams, and also datagram 746 service, which delivers individual packets with no guarantees of 747 reliability or ordering. The requirement for datagram service was 748 motivated by early ARPAnet experiments with packet speech (using IMP 749 Type 3 messages)." 751 The reasons the assumptions in this section are becoming less true 752 are due to network-layer (or higher-layer) techniques being 753 introduced that interfere with the original requirement. Generally 754 these are done either in the name of security, or as a side effect of 755 solving some other problem such as address shortage. Work is needed 756 to investigate ways to restore the original behavior while still 757 meeting today's security requriements. 759 3.4. Assumptions about security 761 3.4.1. Packets are unmodified in transit 763 Some applications and upper-layer protocols assume that a packet is 764 unmodified in transit, except for a few well-defined fields (e.g., 765 TTL). Examples of this behavior include protocols that define their 766 own integrity protection mechanism such as a checksum. 768 This assumption is broken by NATs as discussed in [RFC2993] and other 769 middleboxes that modify the contents of packets. There are many 770 tunneling technologies (e.g., [RFC4380]) that attempt to restore this 771 assumption to some extent. 773 The IPsec architecture [RFC4301] added security to the IP model, 774 providing a way to address this problem without changing 775 applications, although transport-mode IPsec is not currently widely 776 used over the Internet. 778 3.4.2. Packets are private 780 The assumption that data is private has never really been true. 781 However, many old applications and protocols (e.g., FTP) transmit 782 passwords or other sensitive data in the clear. 784 IPsec provides a way to address this problem without changing 785 applications, although it is not yet widely deployed, and doing 786 encryption/decryption for all packets can be computationally 787 expensive. 789 3.4.3. Source addresses are not forged 791 Most applications and protocols use the source address of some 792 incoming packet when generating a response, and hence assume that it 793 has not been forged (and as a result can often be vulnerable to 794 various types of attacks such as reflection attacks). 796 Various mechanisms that restore this assumption include, for example, 797 IPsec and Cryptographically Generated Addresses (CGAs) [RFC3972]. 799 3.4.4. Discussion 801 A good discussion of threat models and common tools can be found in 802 [RFC3552]. Protocol designers and applications developers are 803 encouraged to be familiar with that document. 805 4. Security Considerations 807 This document discusses assumptions about the IP service model made 808 by many applications and upper-layer protocols. Whenever these 809 assumptions are broken, if the application or upper-layer protocol 810 has some security-related behavior that is based on the assumption, 811 then security can be affected. 813 For example, if an application assumes that binding to the IP address 814 of a "trusted" interface means that it will never receive traffic 815 from an "untrusted" interface, and that assumption is broken (as 816 discussed in Section 3.2.7) then an attacker could get access to 817 private information. 819 As a result, great care should be taken when expanding the extent to 820 which an assumption is false. On the other hand, application and 821 upper-layer protocol developers should carefully consider the impact 822 of basing their security on any of the assumptions enumerated in this 823 document. 825 It is also worth noting that many of the changes that have occurred 826 over time (e.g., firewalls, dropping directed broadcasts, etc.) that 827 are discussed in this document were done in the interest of improving 828 security at the expense of breaking some applications. 830 5. IANA Considerations 832 This document has no IANA Actions. 834 6. Conclusion 836 Because a huge number of applications already exist that use TCP/IP 837 for business-critical operations, any changes to the service model 838 need to be done with extreme care. Extensions that merely add 839 additional optional functionality without impacting any existing 840 applications are much safer than extensions which change one or more 841 of the core assumptions discussed above. Any changes to the above 842 assumptions should only be done in accordance with some mechanism to 843 minimize or mitigate the risks of breaking mission-critical 844 applications. Historically, changes have been done without regard to 845 such considerations and as a result the situation for applications 846 today is already problematic. Key to maintaining an interoperable 847 Internet is documenting and maintaining invariants that higher layers 848 can depend on, and being very judicious with changes. 850 In general, lower-layer protocols should document the contract they 851 provide to higher layers; that is, what assumptions the upper layer 852 can rely on (sometimes this is done in the form of an applicability 853 statement). Conversely, higher-layer protocols should document the 854 assumptions they rely on from the lower layer (sometimes this is done 855 in the form of requirements). 857 We must also recognize that a successful architecture often evolves 858 as success brings growth and as technology moves forward. As a 859 result, the various assumptions made should be periodically reviewed 860 when updating protocols. 862 7. Acknowledgements 864 Chris Hopps, Dow Street, Phil Hallam-Baker, and others provided 865 helpful discussion on various points that led to this document. Iain 866 Calder, Brian Carpenter, Jonathan Rosenberg, Erik Nordmark, Alain 867 Durand, and Iljitsch van Beijnum also provided valuable feedback. 869 8. IAB Members at the time of this writing 871 Loa Andersson 872 Gonzalo Camarillo 873 Stuart Cheshire 874 Russ Housley 875 Olaf Kolkman 876 Gregory Lebovitz 877 Barry Leiba 878 Kurtis Lindqvist 879 Andrew Malis 880 Danny McPherson 881 David Oran 882 Dave Thaler 883 Lixia Zhang 885 9. IAB Members at expected time of approval 887 Bernard Aboba 888 Marcelo Bagnulo 889 Ross Callon 890 Spencer Dawkins 891 Vijay Gill 892 Russ Housley 893 John Klensin 894 Olaf Kolkman 895 Danny McPherson 896 Jon Peterson 897 Andrei Robachevsky 898 Dave Thaler 899 Hannes Tschofenig 901 10. References 903 10.1. Normative References 905 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 906 September 1981. 908 [RFC1112] Deering, S., "Host extensions for IP multicasting", STD 5, 909 RFC 1112, August 1989. 911 [RFC1122] Braden, R., "Requirements for Internet Hosts - 912 Communication Layers", STD 3, RFC 1122, October 1989. 914 [RFC1546] Partridge, C., Mendez, T., and W. Milliken, "Host 915 Anycasting Service", RFC 1546, November 1993. 917 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 918 Discovery for IP Version 6 (IPv6)", RFC 2461, 919 December 1998. 921 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 922 in Routers", BCP 34, RFC 2644, August 1999. 924 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 925 Internet Protocol", RFC 4301, December 2005. 927 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 928 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 929 September 2007. 931 10.2. Informative References 933 [I-D.iab-anycast-arch-implications] 934 McPherson, D. and D. Oran, "Architectural Considerations 935 of IP Anycast", draft-iab-anycast-arch-implications-00 936 (work in progress), February 2010. 938 [I-D.ietf-intarea-shared-addressing-issues] 939 Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 940 Roberts, "Issues with IP Address Sharing", 941 draft-ietf-intarea-shared-addressing-issues-02 (work in 942 progress), October 2010. 944 [I-D.rosenberg-internet-waist-hourglass] 945 Rosenberg, J., "UDP and TCP as the New Waist of the 946 Internet Hourglass", 947 draft-rosenberg-internet-waist-hourglass-00 (work in 948 progress), February 2008. 950 [I-D.wbeebee-on-link-and-off-link-determination] 951 Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 952 Model", 953 draft-wbeebee-on-link-and-off-link-determination-02 (work 954 in progress), February 2008. 956 [IEN019] Shoch, J., "A note on Inter-Network Naming, Addressing, 957 and Routing", IEN 19, January 1978, 958 . 960 [IEN023] Cohen, D., "On Names, Addresses and Routings", IEN 23, 961 January 1978, 962 . 964 [IEN028] Postel, J., "Draft Internetwork Protocol Specification", 965 IEN 28, February 1978, 966 . 968 [IEN135] Sunshine, C. and J. Postel, "Addressing Mobile Hosts in 969 the ARPA Internet Environment", IEN 135, March 1980, 970 . 972 [MCAST4] Internet Assigned Numbers Authority, "IPv4 Multicast 973 Addresses", 974 . 976 [MCAST6] Internet Assigned Numbers Authority, "INTERNET PROTOCOL 977 VERSION 6 MULTICAST ADDRESSES", 978 . 981 [NEWARCH] Clark, D., et al., "New Arch: Future Generation Internet 982 Architecture", Air Force Research Laboratory Technical 983 Report AFRL-IF-RS-TR-2004-235, August 2004, . 987 [PROTOCOLS] 988 Internet Assigned Numbers Authority, "Protocol Numbers", 989 . 991 [REORDER] Bennett, J., Partridge, C., and N. Shectman, "Packet 992 reordering is not pathological network behavior", IEEE/ACM 993 Transactions on Networking, Vol. 7, No. 6, December 1999. 995 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 996 RFC 793, September 1981. 998 [RFC0925] Postel, J., "Multi-LAN address resolution", RFC 925, 999 October 1984. 1001 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 1002 STD 9, RFC 959, October 1985. 1004 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1005 November 1990. 1007 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1008 RFC 1812, June 1995. 1010 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1011 E. Lear, "Address Allocation for Private Internets", 1012 BCP 5, RFC 1918, February 1996. 1014 [RFC1958] Carpenter, B., "Architectural Principles of the Internet", 1015 RFC 1958, June 1996. 1017 [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 1018 for IP version 6", RFC 1981, August 1996. 1020 [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 1021 Address Behaviour Today", RFC 2101, February 1997. 1023 [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 1024 over Non-Broadcast Multiple Access (NBMA) networks", 1025 RFC 2491, January 1999. 1027 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 1028 February 2000. 1030 [RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", 1031 RFC 2923, September 2000. 1033 [RFC2979] Freed, N., "Behavior of and Requirements for Internet 1034 Firewalls", RFC 2979, October 2000. 1036 [RFC2991] Thaler, D. and C. Hopps, "Multipath Issues in Unicast and 1037 Multicast Next-Hop Selection", RFC 2991, November 2000. 1039 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 1040 November 2000. 1042 [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, 1043 "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", 1044 RFC 3021, December 2000. 1046 [RFC3069] McPherson, D. and B. Dykes, "VLAN Aggregation for 1047 Efficient IP Address Allocation", RFC 3069, February 2001. 1049 [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. 1050 Zhang, "A Link-Layer Tunneling Mechanism for 1051 Unidirectional Links", RFC 3077, March 2001. 1053 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1054 Jacobson, "RTP: A Transport Protocol for Real-Time 1055 Applications", STD 64, RFC 3550, July 2003. 1057 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 1058 Text on Security Considerations", BCP 72, RFC 3552, 1059 July 2003. 1061 [RFC3618] Fenner, B. and D. Meyer, "Multicast Source Discovery 1062 Protocol (MSDP)", RFC 3618, October 2003. 1064 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1065 in IPv6", RFC 3775, June 2004. 1067 [RFC3819] Karn, P., Bormann, C., Fairhurst, G., Grossman, D., 1068 Ludwig, R., Mahdavi, J., Montenegro, G., Touch, J., and L. 1069 Wood, "Advice for Internet Subnetwork Designers", BCP 89, 1070 RFC 3819, July 2004. 1072 [RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic 1073 Configuration of IPv4 Link-Local Addresses", RFC 3927, 1074 May 2005. 1076 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1077 RFC 3972, March 2005. 1079 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 1080 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 1081 March 2005. 1083 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1084 Network Address Translations (NATs)", RFC 4380, 1085 February 2006. 1087 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1088 (HIP) Architecture", RFC 4423, May 2006. 1090 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1091 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1092 Protocol Specification (Revised)", RFC 4601, August 2006. 1094 [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast 1095 Services", BCP 126, RFC 4786, December 2006. 1097 [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU 1098 Discovery", RFC 4821, March 2007. 1100 [RFC4890] Davies, E. and J. Mohacsi, "Recommendations for Filtering 1101 ICMPv6 Messages in Firewalls", RFC 4890, May 2007. 1103 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, 1104 June 2007. 1106 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 1107 IAB workshop on Unwanted Traffic March 9-10, 2006", 1108 RFC 4948, August 2007. 1110 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1111 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1113 [RFC5218] Thaler, D. and B. Aboba, "What Makes For a Successful 1114 Protocol?", RFC 5218, July 2008. 1116 [RFC5694] Camarillo, G. and IAB, "Peer-to-Peer (P2P) Architecture: 1117 Definition, Taxonomies, Examples, and Applicability", 1118 RFC 5694, November 2009. 1120 [WIRELESS] 1121 Kotz, D., Newport, C., and C. Elliott, "The mistaken 1122 axioms of wireless-network research", Dartmouth College 1123 Computer Science Technical Report TR2003-467, July 2003, 1124 . 1126 Author's Address 1128 Dave Thaler 1129 IAB 1130 One Microsoft Way 1131 Redmond, WA 98052 1132 USA 1134 Phone: +1 425 703 8835 1135 Email: dthaler@microsoft.com