idnits 2.17.1 draft-carpenter-transparency-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 17 longer pages, the longest (page 1) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 13 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (December 1999) is 8889 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 1323' is mentioned on line 174, but not defined ** Obsolete undefined reference: RFC 1323 (Obsoleted by RFC 7323) == Missing Reference: 'IEN 48' is mentioned on line 670, but not defined == Unused Reference: 'RFC 1633' is defined on line 686, but no explicit reference was found in the text == Unused Reference: 'RFC 1928' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'RFC 1958' is defined on line 699, but no explicit reference was found in the text == Unused Reference: 'RFC 2052' is defined on line 705, but no explicit reference was found in the text == Unused Reference: 'RFC 2210' is defined on line 711, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellovin' -- Possible downref: Non-RFC (?) normative reference: ref. 'Berners-Lee' -- Possible downref: Non-RFC (?) normative reference: ref. 'Saltzer' -- Possible downref: Non-RFC (?) normative reference: ref. 'CATENET' ** Obsolete normative reference: RFC 793 (ref. 'STD 7') (Obsoleted by RFC 9293) ** Downref: Normative reference to an Informational RFC: RFC 1546 ** Obsolete normative reference: RFC 1597 (Obsoleted by RFC 1918) ** Downref: Normative reference to an Informational RFC: RFC 1633 ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) ** Downref: Normative reference to an Informational RFC: RFC 1958 ** Obsolete normative reference: RFC 2052 (Obsoleted by RFC 2782) ** Downref: Normative reference to an Informational RFC: RFC 2101 ** Obsolete normative reference: RFC 2309 (Obsoleted by RFC 7567) ** Obsolete normative reference: RFC 2326 (Obsoleted by RFC 7826) ** Obsolete normative reference: RFC 2401 (Obsoleted by RFC 4301) ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) == Outdated reference: A later version (-09) exists of draft-iab-nat-implications-04 ** Downref: Normative reference to an Informational draft: draft-iab-nat-implications (ref. 'NAT-ARCH') == Outdated reference: A later version (-05) exists of draft-ietf-nat-protocol-complications-01 ** Downref: Normative reference to an Informational draft: draft-ietf-nat-protocol-complications (ref. 'NAT-PROT') == Outdated reference: A later version (-03) exists of draft-iab-secmech-01 ** Downref: Normative reference to an Informational draft: draft-iab-secmech (ref. 'SECMECH') == Outdated reference: A later version (-05) exists of draft-ietf-nat-rsip-framework-01 ** Downref: Normative reference to an Experimental draft: draft-ietf-nat-rsip-framework (ref. 'RSIP') == Outdated reference: A later version (-09) exists of draft-moskowitz-hip-00 -- Possible downref: Normative reference to a draft: ref. 'HIP' Summary: 25 errors (**), 0 flaws (~~), 16 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IETF B. Carpenter 2 Internet Draft 3 December 1999 5 Internet Transparency 7 Copyright Notice 9 Placeholder for ISOC copyright. 11 Abstract 13 draft-carpenter-transparency-05.txt 15 This document describes the current state of the Internet 16 from the architectural viewpoint, concentrating on issues 17 of end-to-end connectivity and transparency. It concludes with a 18 summary of some major architectural alternatives facing the Internet 19 network layer. 21 This document was used as input to the IAB workshop on the future of 22 the network layer held in July 1999. For this reason, it does not 23 claim to be complete and definitive, and it refrains from making 24 recommendations. 26 Status of this Memo 28 This document is an Internet-Draft and is in full conformance with 29 all provisions of Section 10 of RFC2026. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet- Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 Table of Contents: 49 Status of this Memo.............................................1 50 1. Introduction.................................................3 51 2. Aspects of end-to-end connectivity...........................3 52 2.1 The end-to-end argument.....................................3 53 2.2 End-to-end performance......................................4 54 2.3 End-to-end address transparency.............................5 55 3. Multiple causes of loss of transparency......................6 56 3.1 The Intranet model..........................................6 57 3.2 Dynamic address allocation..................................6 58 3.2.1 SLIP and PPP..............................................6 59 3.2.2 DHCP......................................................7 60 3.3 Firewalls...................................................7 61 3.3.1 Basic firewalls...........................................7 62 3.3.2 SOCKS.....................................................7 63 3.4 Private addresses...........................................7 64 3.5 Network address translators.................................8 65 3.6 Application level gateways, relays, proxies, and caches.....8 66 3.7 Voluntary isolation and peer networks.......................9 67 3.8 Split DNS...................................................9 68 3.9 Various load-sharing tricks.................................9 69 4. Summary of current status and impact.........................9 70 5. Possible future directions..................................11 71 5.1 Successful migration to IPv6...............................11 72 5.2 Complete failure of IPv6...................................12 73 5.2.1 Re-allocating the IPv4 address space.....................12 74 5.2.2 Exhaustion...............................................13 75 5.3 Partial deployment of IPv6.................................13 76 6. Conclusion..................................................13 77 7. Security considerations.....................................13 78 Acknowledgements...............................................14 79 References.....................................................15 80 Author's Address...............................................16 81 Full Copyright Statement.......................................17 83 1. Introduction 85 "There's a freedom about the Internet: As long as we accept the 86 rules of sending packets around, we can send packets containing 87 anything to anywhere." [Berners-Lee] 89 The Internet is experiencing growing pains which are often referred 90 to as "the end-to-end problem". This document attempts to analyse 91 those growing pains by reviewing the current state of the network 92 layer, especially its progressive loss of transparency. For the 93 purposes of this document, "transparency" refers to the original 94 Internet concept of a single universal logical addressing scheme, and 95 the mechanisms by which packets may flow from source to destination 96 essentially unaltered. 98 The causes of this loss of transparency are partly artefacts of 99 parsimonious allocation of the limited address space available to 100 IPv4, and partly the result of broader issues resulting from the 101 widespread use of TCP/IP technology by businesses and consumers. For 102 example, network address translation is an artefact, but Intranets 103 are not. 105 Thus the way forward must recognise the fundamental changes in the 106 usage of TCP/IP that are driving current Internet growth. In one 107 scenario, a complete migration to IPv6 potentially allows the 108 restoration of global address transparency, but without removing 109 firewalls and proxies from the picture. At the other extreme, a total 110 failure of IPv6 leads to complete fragmentation of the network layer, 111 with global connectivity depending on endless patchwork. 113 This document does not discuss the routing implications of address 114 space, nor the implications of quality of service management on 115 router state, although both these matters interact with transparency 116 to some extent. It also does not substantively discuss namespace 117 issues. 119 2. Aspects of end-to-end connectivity 121 The phrase "end to end", often abbreviated as "e2e", is widely used 122 in architectural discussions of the Internet. For the purposes of 123 this paper, we first present three distinct aspects of end-to- 124 endness. 126 2.1 The end-to-end argument 128 This is an argument first described in [Saltzer] and reviewed in [RFC 129 1958], from which an extended quotation follows: 131 "The 132 basic argument is that, as a first principle, certain required end- 133 to-end functions can only be performed correctly by the end-systems 134 themselves. A specific case is that any network, however carefully 135 designed, will be subject to failures of transmission at some 136 statistically determined rate. The best way to cope with this is to 137 accept it, and give responsibility for the integrity of communication 138 to the end systems. Another specific case is end-to-end security. 140 "To quote from [Saltzer], 'The function in question can completely and 141 correctly be implemented only with the knowledge and help of the 142 application standing at the endpoints of the communication system. 143 Therefore, providing that questioned function as a feature of the 144 communication system itself is not possible. (Sometimes an incomplete 145 version of the function provided by the communication system may be 146 useful as a performance enhancement.)' 148 "This principle has important consequences if we require applications 149 to survive partial network failures. An end-to-end protocol design 150 should not rely on the maintenance of state (i.e. information about 151 the state of the end-to-end communication) inside the network. Such 152 state should be maintained only in the endpoints, in such a way that 153 the state can only be destroyed when the endpoint itself breaks 154 (known as fate-sharing). An immediate consequence of this is that 155 datagrams are better than classical virtual circuits. The network's 156 job is to transmit datagrams as efficiently and flexibly as possible. 157 Everything else should be done at the fringes." 159 Thus this first aspect of end-to-endness limits what the network is 160 expected to do, and clarifies what the end-system is expected to do. 161 The end-to-end argument underlies the rest of this document. 163 2.2 End-to-end performance 165 Another aspect, in which the behaviour of the network and that of the 166 end-systems interact in a complex way, is performance, in a 167 generalised sense. This is not a primary focus of the present 168 document, but it is mentioned briefly since it is often referred to 169 when discussing end-to-end issues. 171 Much work has been done over many years to improve and optimise the 172 performance of TCP. Interestingly, this has led to comparatively 173 minor changes to TCP itself; [STD 7] is still valid apart from minor 174 additions [RFC 1323, RFC 2581, RFC 2018]. However a great deal of 175 knowledge about good practice in TCP implementations has built up, 176 and the queuing and discard mechanisms in routers have been fine- 177 tuned to improve system performance in congested conditions. 179 Unfortunately all this experience in TCP performance does not help 180 with transport protocols that do not exhibit TCP-like response to 181 congestion [RFC 2309]. Also, the requirement for specified quality of 182 service for different applications and/or customers has led to much 183 new development, especially the Integrated Services [RFC 1633, RFC 184 2210] and Differentiated Services [RFC 2475] models. At the same time 185 new transport-related protocols have appeared [RFC 1889, RFC 2326] or 186 are in discussion in the IETF. It should also be noted that since the 187 speed of light is not set by an IETF standard, our current notions of 188 end-to-end performance will be largely irrelevant to interplanetary 189 networking. 191 Thus, despite the fact that performance and congestion issues for TCP 192 are now quite well understood, the arrival of QOS mechanisms and of 193 new transport protocols raise new questions about end-to-end 194 performance, but these are not further discussed here. 196 2.3 End-to-end address transparency 198 When the catenet concept (a network of networks) was first described 199 by Cerf in 1978 [IEN 48] following an earlier suggestion by Pouzin in 200 1974 [CATENET], a clear assumption was that a single logical address 201 space would cover the whole catenet (or Internet as we now know it). 202 This applied not only to the early TCP/IP Internet, but also to the 203 Xerox PUP design, the OSI connectionless network design, XNS, and 204 numerous other proprietary network architectures. 206 This concept had two clear consequences - packets could flow 207 essentially unaltered throughout the network, and their source and 208 destination addresses could be used as unique labels for the end 209 systems. 211 The first of these consequences is not absolute. In practice changes 212 can be made to packets in transit. Some of these are reversible at 213 the destination (such as fragmentation and compression). Others may 214 be irreversible (such as changing type of service bits or 215 decrementing a hop limit), but do not seriously obstruct the end-to- 216 end principle of Section 2.1. However, any change made to a packet in 217 transit that requires per-flow state information to be kept at an 218 intermediate point would violate the fate-sharing aspect of the end- 219 to-end principle. 221 The second consequence, using addresses as unique labels, was in a 222 sense a side-effect of the catenet concept. However, it was a side- 223 effect that came to be highly significant. The uniqueness and 224 durability of addresses have been exploited in many ways, in 225 particular by incorporating them in transport identifiers. Thus they 226 have been built into transport checksums, cryptographic signatures, 227 Web documents, and proprietary software licence servers. [RFC 2101] 228 explores this topic in some detail. Its main conclusion is that IPv4 229 addresses can no longer be assumed to be either globally unique or 230 invariant, and any protocol or applications design that assumes these 231 properties will fail unpredictably. Work in the IAB and the NAT 232 working group [NAT-ARCH] has analysed the impact of one specific 233 cause of non-uniqueness and non-invariance, i.e., network address 234 translators. Again the conclusion is that many applications will 235 fail, unless they are specifically adapted to avoid the assumption of 236 address transparency. One form of adaptation is the insertion of some 237 form of application level gateway, and another form is for the NAT to 238 modify payloads on the fly, but in either case the adaptation is 239 application-specific. 241 Non-transparency of addresses is part of a more general phenomenon. 242 We have to recognise that the Internet has lost end-to-end 243 transparency, and this requires further analysis. 245 3. Multiple causes of loss of transparency 247 This section describes various recent inventions that have led to the 248 loss of end-to-end transparency in the Internet. 250 3.1 The Intranet model 252 Underlying a number of the specific developments mentioned below is 253 the concept of an "Intranet", loosely defined as a private corporate 254 network using TCP/IP technology, and connected to the Internet at 255 large in a carefully controlled manner. The Intranet is presumed to 256 be used by corporate employees for business purposes, and to 257 interconnect hosts that carry sensitive or confidential information. 258 It is also held to a higher standard of operational availability than 259 the Internet at large. Its usage can be monitored and controlled, and 260 its resources can be better planned and tuned than those of the 261 public network. These arguments of security and resource management 262 have ensured the dominance of the Intranet model in most corporations 263 and campuses. 265 The emergence of the Intranet model has had a profound effect on the 266 notion of application transparency. Many corporate network managers 267 feel it is for them alone to determine which applications can 268 traverse the Internet/Intranet boundary. In this world view, address 269 transparency may seem to be an unimportant consideration. 271 3.2 Dynamic address allocation 273 3.2.1 SLIP and PPP 275 It is to be noted that with the advent of vast numbers of dial-up 276 Internet users, whose addresses are allocated at dial-up time, and 277 whose traffic may be tunelled back to their home ISP, the actual IP 278 addresses of such users are purely transient. During their period of 279 validity they can be relied on end-to-end, but they must be forgotten 280 at the end of every session. In particular they can have no permanent 281 association with the domain name of the host borrowing them. 283 3.2.2 DHCP 285 Similarly, LAN-based users of the Internet today frequently use DHCP 286 to acquire a new address at system restart, so here again the actual 287 value of the address is potentially transient and must not be stored 288 between sessions. 290 3.3 Firewalls 292 3.3.1 Basic firewalls 294 Intranet managers have a major concern about security: unauthorised 295 traffic must be kept out of the Intranet at all costs. This concern 296 led directly to the firewall concept (a system that intercepts all 297 traffic between the Internet and the Intranet, and only lets through 298 selected traffic, usually belonging to a very limited set of 299 applications). Firewalls, by their nature, fundamentally limit 300 transparency. 302 3.3.2 SOCKS 304 A footnote to the effect of firewalls is the SOCKS mechanism [RFC 305 1928] by which untrusted applications such as telnet and ftp can 306 punch through a firewall. SOCKS requires a shim library in the 307 Intranet client, and a server in the firewall which is essentially an 308 application level relay. As a result, the remote server does not see 309 the real client; it believes that the firewall is the client. 311 3.4 Private addresses 313 When the threat of IPv4 address exhaustion first arose, and in some 314 cases user sites were known to be "pirating" addresses for private 315 use, a set of official private addresses were hurriedly allocated 316 [RFC 1597] and later more carefully defined [BCP 5]. The legitimate 317 existence of such an address allocation proved to very appealling, so 318 Intranets with large numbers of non-global addresses came into 319 existence. Unfortunately, such addresses by their nature cannot be 320 used for communication across the public Internet; without special 321 measures, hosts using private addresses are cut off from the world. 323 Note that private address space is sometimes asserted to be a 324 security feature, based on the notion that outside knowledge of 325 internal addresses might help intruders. This is a false argument, 326 since it is trivial to hide addresses by suitable access control 327 lists, even if they are globally unique - indeed that is a basic 328 feature of a filtering router, the simplest form of firewall. A 329 system with a hidden address is just as private as a system with a 330 private addresss. There is of course no possible point in hiding the 331 addresses of servers to which outside access is required. 333 It is also worth noting that the IPv6 equivalent of private 334 addresses, i.e. site-local addresses, have similar characteristics to 335 BCP 5 addresses, but their use will not be forced by a lack of 336 globally unique IPv6 addresses. 338 3.5 Network address translators 340 Network address translators (NATs) are an almost inevitable 341 consequence of the existence of Intranets using private addresses yet 342 needing to communicate with the Internet at large. Their 343 architectural implications are discussed at length in [NAT-ARCH], the 344 fundamental point being that address translation on the fly destroys 345 end-to-end address transparency and breaks any middleware or 346 applications that depend on it. Numerous protocols, for example 347 H.323, carry IP addresses at application level and fail to traverse a 348 simple NAT box correctly. If the full range of Internet applications 349 is to be used, NATs have to be coupled with application level 350 gateways (ALGs) or proxies. Furthermore, the ALG or proxy must be 351 updated whenever a new address-dependent application comes along. In 352 practice, NAT functionality is built into many firewall products, and 353 all useful NATs have associated ALGs, so it is difficult to 354 disentangle their various impacts. 356 3.6 Application level gateways, relays, proxies, and caches 358 It is reasonable to position application level gateways, relays, 359 proxies, and caches at certain critical topological points, 360 especially the Intranet/Internet boundary. For example, if an 361 Intranet does not use SMTP as its mail protocol, an SMTP gateway is 362 needed. Even in the normal case, an SMTP relay is common, and can 363 perform useful mail routing functions, spam filtering, etc. (It may 364 be observed that spam filtering is in some ways a firewall function, 365 but the store-and-forward nature of electronic mail and the 366 availability of MX records allow it to be a distinct and separate 367 function.) 369 Similarly, for a protocol such as HTTP with a well-defined voluntary 370 proxy mechanism, application proxies also serving as caches are very 371 useful. Although these devices interfere with transparency, they do 372 so in a precise way, correctly terminating network, transport and 373 application protcols on both sides. They can however exhibit some 374 shortfalls in ease of configuration and failover. 376 However, there appear to be cases of "involuntary" applications level 377 devices such as proxies that grab and modify HTTP traffic without 378 using the appropriate mechanisms, sometimes known as "transparent 379 caches", or mail relays that purport to remove undesirable words. 380 These devices are by definition not transparent, and may have totally 381 unforeseeable side effects. (A possible conclusion is that even for 382 non-store-and-forward protocols, a generic diversion mechanism 383 analagous to the MX record would be of benefit. The SRV record [RFC 384 2052] is a step in this direction.) 386 3.7 Voluntary isolation and peer networks 388 There are communities that think of themselves as being so different 389 that they require isolation via an explicit proxy, and even by using 390 proprietary protocols and addressing schemes within their network. An 391 example is the WAP Forum which targets very small phone-like devices 392 with some capabilities for Internet connectivity. However, it's not 393 the Internet they're connecting directly to. They have to go through 394 a proxy. This could potentially mean that millions of devices will 395 never know the benefits of end-to-end connectivity to the Internet. 397 A similar effect arises when applications such as telephony span both 398 an IP network and a peer network layer using a different technology. 399 Although the application may work end-to-end, there is no possibility 400 of end-to-end packet transmission. 402 3.8 Split DNS 404 Another consequence of the Intranet/Internet split is "split DNS" or 405 "two faced DNS", where a corporate network serves up partly or 406 completely different DNS inside and outside its firewall. There are 407 many possible variants on this; the basic point is that the 408 correspondence between a given FQDN (fully qualified domain name) and 409 a given IPv4 address is no longer universal and stable over long 410 periods. 412 3.9 Various load-sharing tricks 414 IPv4 was not designed to support anycast [RFC 1546], so there is no 415 natural approach to load-sharing when one server cannot do the job. 416 Various tricks have been used to resolve this (multicast to find a 417 free server, the DNS returns different addresses for the same FQDN in 418 a round-robin, a router actually routes packets sent to the same 419 address automatically to different servers, etc.). While these tricks 420 are not particularly harmful in the overall picture, they can be 421 implemented in such a way as to interfere with name or address 422 transparency. 424 4. Summary of current status and impact 426 It is impossible to estimate with any numerical reliability how 427 widely the above inventions have been deployed. Since many of them 428 preserve the illusion of transparency while actually interfering with 429 it, they are extremely difficult to measure. 431 However it is certain that all the mechanisms just described are in 432 very widespread use; they are not a marginal phenomenon. In corporate 433 networks, many of them are the norm. Some of them (firewalls, relays, 434 proxies and caches) clearly have intrinsic value given the Intranet 435 concept. The others are largely artefacts and pragmatic responses to 436 various pressures in the operational Internet, and they must be 437 costing the industry very dearly in constant administration and 438 complex fault diagnosis. 440 In particular, the decline of transparency is having a severe effect 441 on deployment of end-to-end IP security. The Internet security model 442 [SECMECH] calls for security at several levels (roughly, network, 443 applications, and object levels). The current network level security 444 model [RFC 2401] was constructed prior to the recognition that end- 445 to-end address transparency was under severe threat. Although 446 alternative proposals have begun to emerge [HIP] the current reality 447 is that IPSEC cannot be deployed end-to-end in the general case. 448 Tunnel-mode IPSEC can be deployed between corporate gateways or 449 firewalls. Transport-mode IPSEC can be deployed within a corporate 450 network in some cases, but it cannot span from Intranet to Internet 451 and back to another Intranet if there is any chance of a NAT along 452 the way. 454 Indeed, NAT breaks other security mechanisms as well, such as DNSSEC 455 and Kerberos, since they rely on address values. 457 The loss of transparency brought about by private addresses and NATs 458 affects many applications protocols to a greater or lesser extent. 459 This is explored in detail in [NAT-PROT]. A more subtle effect is 460 that the prevalence of dynamic addresses (from DHCP, SLIP and PPP) 461 has fed upon the trend towards client/server computing. Today it is 462 largely true that servers have fixed addresses, clients have dynamic 463 addresses, and servers can in no way assume that a client's IP 464 address identifies the client. On the other hand, clients rely on 465 servers having stable addresses since a DNS lookup is the only 466 generally deployed mechanism by which a client can find a server and 467 solicit service. In this environment, there is little scope for true 468 peer-to-peer applications protocols, and no easy solution for mobile 469 servers. Indeed, the very limited demand for Mobile IP might be 470 partly attributed to the market dominance of client/server 471 applications in which the client's address is of transient 472 significance. We also see a trend towards single points of failure 473 such as media gateways, again resulting from the difficulty of 474 implementing peer-to-peer solutions directly between clients with no 475 fixed address. 477 The notion that servers can use precious globally unique addresses 478 from a small pool, because there will always be fewer servers than 479 clients, may become anachronistic when most electrical devices become 480 network-manageable and thus become servers for a management protocol. 481 Similarly, if every PC becomes a telephone (or the converse), capable 482 of receiving unsolicited incoming calls, the lack of stable IP 483 addresses for PCs will be an issue. Another impending paradigm shift 484 is when domestic and small-office subscribers move from dial-up to 485 always-on Internet connectivity, at which point transient address 486 assignment from a pool becomes much less appropriate. 488 Many of the inventions described in the previous section lead to the 489 datagram traffic between two hosts being directly or indirectly 490 mediated by at least one other host. For example a client may depend 491 on a DHCP server, a server may depend on a NAT, and any host may 492 depend on a firewall. This violates the fate-sharing principle of 493 [Saltzer] and introduces single points of failure. Worse, most of 494 these points of failure require configuration data, yet another 495 source of operational risk. The original notion that datagrams would 496 find their way around failures, especially around failed routers, has 497 been lost; indeed the overloading of border routers with additional 498 functions has turned them into critical rather than redundant 499 components, even for multihomed sites. 501 The loss of address transparency has other negative effects. For 502 example, large scale servers may use heuristics or even formal 503 policies that assign different priorities to service for different 504 clients, based on their addresses. As addresses lose their global 505 meaning, this mechanism will fail. Similarly, any anti-spam or anti- 506 spoofing techniques that rely on reverse DNS lookup of address values 507 can be confused by translated addresses. (Uncoordinated renumbering 508 can have similar disadvantages.) 510 The above issues are not academic. They add up to complexity in 511 applications design, complexity in network configuration, complexity 512 in security mechanisms, and complexity in network management. 513 Specifically, they make fault diagnosis much harder, and by 514 introducing more single points of failure, they make faults more 515 likely to occur. 517 5. Possible future directions 519 5.1 Successful migration to IPv6 521 In this scenario, IPv6 becomes fully implemented on all hosts and 522 routers, including the adaptation of middleware, applications, and 523 management systems. Since the address space then becomes big enough 524 for all conceivable needs, address transparency can be restored. 525 Transport-mode IPSEC can in principle deploy, given adequate security 526 policy tools and a key infrastructure. However, it is widely 527 believed that the Intranet/firewall model will certainly persist. 529 Note that it is a basic assumption of IPv6 that no artificial 530 constraints will be placed on the supply of addresses, given that 531 there are so many of them. Current practices by which some ISPs 532 strongly limit the number of IPv4 addresses per client will have no 533 reason to exist for IPv6. (However, addresses will still be assigned 534 prudently, according to guidelines designed to favour hierarchical 535 routing.) 537 Clearly this is in any case a very long term scenario, since it 538 assumes that IPv4 has declined to the point where IPv6 is required 539 for universal connectivity. Thus, a viable version of Scenario 5.3 is 540 a prerequisite for Scenario 5.1. 542 5.2 Complete failure of IPv6 544 In this scenario, IPv6 fails to reach any significant level of 545 operational deployment, IPv4 addressing is the only available 546 mechanism, and address transparency cannot be restored. IPSEC cannot 547 be deployed globally in its current form. In the very long term, the 548 pool of globally unique IPv4 addresses will be nearly totally 549 allocated, and new addresses will generally not be available for any 550 purpose. 552 It is unclear exactly what is likely to happen if the Internet 553 continues to rely exclusively on IPv4, because in that eventuality a 554 variety of schemes are likely to promulgated, with a view toward 555 providing an acceptable evolutionary path for the network. However, 556 we can examine two of the more simplistic sub-scenarios which are 557 possible, while realising that the future would be unlikely to match 558 either one exactly: 560 5.2.1 Re-allocating the IPv4 address space 562 Suppose that a mechanism is created to continuously recover and re- 563 allocate IPv4 addresses. A single global address space is maintained, 564 with all sites progressively moving to an Intranet private address 565 model, with global addresses being assigned temporarily from a pool 566 of several billion. 568 5.2.1.1 A sub-sub-scenario of this is generalised use of NAT and NAPT 569 (NAT with port number translation). This has the disadvantage that 570 the host is unaware of the unique address being used for its traffic, 571 being aware only of its ambiguous private address, with all the 572 problems that this generates. See [NAT-ARCH]. 574 5.2.1.2 Another sub-sub-scenario is the use of realm-specific IP 575 addressing implemented at the host rather than by a NAT box. See 576 [RSIP]. In this case the host is aware of its unique address, 577 allowing for substantial restoration of the end-to-end usefulness of 578 addresses, e.g. for TCP or cryptographic checksums. 580 5.2.1.3 A final sub-sub-scenario is the "map and encapsulate" model 581 in which address translation is replaced by systematic encapsulation 582 of all packets for wide-area transport. This model has never been 583 fully developed, although it is completely compatible with end-to-end 584 addressing. 586 5.2.2 Exhaustion 588 Suppose that no mechanism is created to recover addresses (except 589 perhaps black or open market trading). Sites with large address 590 blocks keep them. All the scenarios of 5.2.1 appear but are 591 insufficient. Eventually the global address space is no longer 592 adequate. This is a nightmare scenario - NATs appear within the 593 "global" address space, for example at ISP-ISP boundaries. It is 594 unclear how a global routing system and a global DNS system can be 595 maintained; the Internet is permanently fragmented. 597 5.3 Partial deployment of IPv6 599 In this scenario, IPv6 is completely implemented but only deploys in 600 certain segments of the network (e.g. in certain countries, or in 601 certain areas of application such as mobile hand-held devices). 602 Instead of being transitional in nature, some of the IPv6 transition 603 techniques become permanent features of the landscape. Sometimes 604 addresses are 32 bits, sometimes they are 128 bits. DNS lookups may 605 return either or both. In the 32 bit world, the scenarios 5.2.1 and 606 5.2.2 may occur. IPSEC can only deploy partially. 608 6. Conclusion 610 None of the above scenarios is clean, simple and straightforward. 611 Although the pure IPv6 scenario is the cleanest and simplest, it is 612 not straightforward to reach it. The various scenarios without use of 613 IPv6 are all messy and ultimately seem to lead to dead ends of one 614 kind or another. Partial deployment of IPv6, which is a required step 615 on the road to full deployment, is also messy but avoids the dead 616 ends. 618 7. Security considerations 620 The loss of transparency is both a bug and a feature from the 621 security viewpoint. To the extent that it prevents the end-to-end 622 deployment of IPSEC, it damages security and creates vulnerabilities. 623 For example, if a standard NAT box is in the path, then the best that 624 can be done is to decrypt and re-encrypt IP traffic in the NAT. The 625 traffic will therefore be momentarily in clear text and potentially 626 vulnerable. Furthermore, the NAT will possess many keys and will be a 627 prime target of attack. In environments where this is unacceptable, 628 encryption must be applied above the network layer instead, of course 629 with no usage whatever of IP addresses in data that is 630 cryptographically protected. See section 4 for further discussion. 632 In certain scenarios, i.e. 5.1 (full IPv6) and 5.2.1.2 (RSIP), end- 633 to-end IPSEC would become possible, especially using the "distributed 634 firewalls" model advocated in [Bellovin]. 636 The loss of transparency at the Intranet/Internet boundary may be 637 considered a security feature, since it provides a well defined point 638 at which to apply restrictions. This form of security is subject to 639 the "crunchy outside, soft inside" risk, whereby any successful 640 penetration of the boundary exposes the entire Intranet to trivial 641 attack. The lack of end-to-end security applied within the Intranet 642 also ignores insider threats. 644 It should be noted that security applied above the transport level, 645 such as SSL, SSH, PGP or S/MIME, is not affected by network layer 646 transparency issues. 648 Acknowledgements 650 This document and the related issues have been discussed extensively 651 by the IAB. Special thanks to Steve Deering for a detailed review and 652 to Noel Chiappa. Useful comments or ideas were also received from Rob 653 Austein, John Bartas, Jim Bound, Scott Bradner, Vint Cerf, Spencer 654 Dawkins, Anoop Ghanwani, Erik Guttmann, Eric A. Hall, Graham Klyne, 655 Dan Kohn, Gabriel Montenegro, Thomas Narten, Erik Nordmark, Vern 656 Paxson, Michael Quinlan, Eric Rosen, Daniel Senie, Henning 657 Schulzrinne, Bill Sommerfeld, and George Tsirtsis. 659 References 661 [Bellovin] Distributed Firewalls, S. Bellovin, available at 662 http://www.research.att.com/~smb/papers/distfw.pdf or 663 http://www.research.att.com/~smb/papers/distfw.ps (work in progress). 665 [Berners-Lee] Weaving the Web, T. Berners-Lee, M. Fischetti, 666 HarperCollins, 1999, p 208. 668 [Saltzer] End-To-End Arguments in System Design, J.H. Saltzer, 669 D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp 670 277-288. [IEN 48] Cerf, V., "The Catenet Model for Internetworking," 671 Information Processing Techniques Office, Defense Advanced Research 672 Projects Agency, IEN 48, July 1978. 674 [CATENET] Pouzin, L., "A Proposal for Interconnecting Packet 675 Switching Networks," Proceedings of EUROCOMP, Brunel University, May 676 1974, pp. 1023-36. 678 [STD 7] Transmission Control Protocol, J. Postel, RFC 793, 1981. 680 [RFC 1546] Host Anycasting Service, C. Partridge, T. Mendez, W. 681 Milliken, RFC 1546, 1993. 683 [RFC 1597] Address Allocation for Private Internets. Y. Rekhter, B. 684 Moskowitz, D. Karrenberg, G. de Groot, RFC 1597, 1994. 686 [RFC 1633] Integrated Services in the Internet Architecture: an 687 Overview, R. Braden, D. Clark, S. Shenker, RCC 1633, 1994. 689 [RFC 1889] RTP: A Transport Protocol for Real-Time Applications - 690 Audio-Video Transport Working Group, H. Schulzrinne, S. Casner, R. 691 Frederick, V. Jacobson, RFC 1889, 1996. 693 [BCP 5] Address Allocation for Private Internets. Y. Rekhter, B. 694 Moskowitz, D. Karrenberg, G. J. de Groot & E. Lear, RFC 1918, 1996. 696 [RFC 1928] SOCKS Protocol Version 5, M. Leech, M. Ganis, Y. Lee, R. 697 Kuris, D. Koblas & L. Jones, RFC 1928, 1996. 699 [RFC 1958] Architectural Principles of the Internet, B. Carpenter 700 (ed.), RFC 1958, 1996. 702 [RFC 2018] TCP Selective Acknowledgement Options. M. Mathis, J. 703 Mahdavi, S. Floyd, A. Romanow, RFC 2018, 1996. 705 [RFC 2052] A DNS RR for specifying the location of services (DNS 706 SRV), A. Gulbrandsen, P. Vixie, RFC 2052, 1996. 708 [RFC 2101] IPv4 Address Behaviour Today. B. Carpenter, J. Crowcroft, 709 Y. Rekhter, RFC 2101, 1997. 711 [RFC 2210] The Use of RSVP with IETF Integrated Services, J. 712 Wroclawski, RFC 2210, 1997. 714 [RFC 2309] Recommendations on Queue Management and Congestion 715 Avoidance in the Internet, B. Braden, D. Clark, J. Crowcroft, B. 716 Davie, S. Deering, D. Estrin, S. Floyd, V. Jacobson, G. Minshall, C. 717 Partridge, L. Peterson, K. Ramakrishnan, S. Shenker, J. Wroclawski, 718 L. Zhang, RFC 2309, 1998. 720 [RFC 2326] Real Time Streaming Protocol (RTSP), H. Schulzrinne, A. 721 Rao, R. Lanphier, RFC 2326, 1998 723 [RFC 2401] Security Architecture for the Internet Protocol, S. Kent, 724 R. Atkinson, RFC 2401, 1998. 726 [RFC 2475] An Architecture for Differentiated Service, S. Blake, D. 727 Black, M. Carlson, E. Davies, Z. Wang, W. Weiss, RFC 2475, 1998. 729 [RFC 2581] TCP Congestion Control, M. Allman, V. Paxson, W. Stevens, 730 RFC 2581, 1999. 732 [NAT-ARCH] Architectural Implications of NAT, T. Hain, draft-iab- 733 nat-implications-04.txt (work in progress). 735 [NAT-PROT] Protocol Complications with the IP Network Address 736 Translator (NAT), M. Holdrege, P. Srisuresh, draft-ietf-nat- 737 protocol-complications-01.txt (work in progress). 739 [SECMECH] Security Mechanisms for the Internet, S. Bellovin, draft- 740 iab-secmech-01.txt (work in progress). 742 [RSIP] Realm Specific IP: A Framework, J. Lo, M. Borella, D. 743 Grabelsky draft-ietf-nat-rsip-framework-01.txt (work in progress). 745 [HIP] The Host Identity Payload, R. Moskowitz, draft-moskowitz-hip- 746 00.txt (work in progress). 748 Author's Address 750 Brian E. Carpenter 751 IBM 752 c/o iCAIR 753 Suite 150 754 1890 Maple Avenue 755 Evanston, IL 60201 756 USA 758 Email: brian@icair.org 760 Full Copyright Statement 762 PLACEHOLDER for full ISOC copyright Statement