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