idnits 2.17.1 draft-iab-arch-changes-00.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 9 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.) ** There are 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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. -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC 2277' is defined on line 313, but no explicit reference was found in the text == Unused Reference: 'RFC 2775' is defined on line 319, but no explicit reference was found in the text == Unused Reference: 'RFC 3022' is defined on line 332, but no explicit reference was found in the text == Unused Reference: 'RFC 3027' is defined on line 335, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2543 (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) Summary: 6 errors (**), 0 flaws (~~), 8 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IAB B. Carpenter 2 Internet Draft R. Austein 3 February 2002 (editors) 5 Recent Changes in the Architectural Principles of the Internet 7 Copyright Notice 9 If published as an RFC this document will become 10 Copyright (C) The Internet Society (2002). All Rights Reserved. 12 Abstract 14 draft-iab-arch-changes-00.txt 16 In 1996, the IAB published RFC 1958, entitled "Architectural 17 Principles of the Internet." The Internet has grown and evolved 18 since then, and this document records the impact of this evolution on 19 the principles laid down previously. This first draft is issued for 20 discussion by the IETF community. 22 Status of this Memo 24 This document is an Internet-Draft and is subject to all provisions 25 of Section 10 of RFC2026. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 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 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/1id-abstracts.html 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html 42 Table of Contents: 44 Status of this Memo.............................................1 45 1. Introduction.................................................3 46 2. The End-to-End Argument and Middleboxes......................3 47 2.1. NATs as a Special Case of Middleboxes......................4 48 3. Internationalisation.........................................5 49 4. Overextension................................................6 50 5. A New External Issue.........................................7 51 6. Security Considerations......................................7 52 Non-normative References........................................7 53 Acknowledgements................................................8 54 Editors' Addresses..............................................9 55 Full Copyright Statement........................................9 57 1. Introduction 59 In 1996, the IAB published RFC 1958, entitled "Architectural 60 Principles of the Internet" [RFC 1958]. The Internet has grown 61 dramatically and evolved substantially since then, and this document 62 attempts to record the impact of this evolution on the principles 63 laid down previously. 65 Indeed, the very first section of [RFC 1958] is entitled "Constant 66 Change" and it was expected that the document would require 67 revisiting. Although the principles are still fundamentally sound, 68 some of them need additional explanation and refinement to match 69 current realities. Three main areas are of concern. Also, one new 70 principle has arisen. 72 From here on, it is assumed that the reader is familiar with [RFC 73 1958]. Principles that are not mentioned in the present document are 74 still regarded as fully valid. 76 2. The End-to-End Argument and Middleboxes 78 The description of the end-to-end argument in [RFC 1958] does not 79 take into account the concerns about transparency [RFC 2775, RFC 80 2956] and the related issues surrounding NATs [RFC 2993, RFC 3022, 81 RFC 3027] and intermediaries or middleboxes [RFC 3234, RFC 3040]. 82 These topics have stimulated much activity in the IETF in recent 83 years, and this work has attracted some attention in other forums 84 [Clark]. 86 We can state that the traditional end-to-end argument still applies, 87 both as an abstract design principle, and concretely to all cases 88 where a single transport connection (unicast or multicast) is 89 considered. However, in cases where an application data flow passes 90 through multiple transport connections and may even be modified en 91 route by middleboxes, the argument applies in a more subtle way. In 92 the presence of middleboxes, it is no longer possible to assume that 93 because TCP is reliable, the end-to-end path is reliable. Also, state 94 in the middleboxes may be lost during failures. To obtain reliability 95 and robustness, more sophisticated techniques than those employed by 96 TCP are needed, possibly approaching the complexity of transactional 97 two-phase commit. Similarly, IP or Transport Level security no longer 98 guarantees end-to-end security. Security mechanisms above the 99 network itself are needed in addition. 101 One way to look at the problem is that users do still care very much 102 about the end-to-end principle, but only at layers where they 103 understand how preservation of semantics matters to them. For 104 example: loss of TCP's end-to-end data integrity would matter a great 105 deal to most users, but loss of an ability they've never used (such 106 as a new, genuine peer-to-peer application that requires full 107 transparency) would be invisible. So the end-to-end principle is 108 still valid, but its realisation cannot be limited to the transport 109 layer. 111 More concretely, in the presence of middleboxes, applications are 112 often forced to use application-layer handshakes to ensure 113 reliability and robustness. See SMTP delivery confirmation and 114 stateful SIP proxies [RFC 2543] as examples. This is the end-to-end 115 principle, recursed further to the "real" ends to cover cases where 116 it no longer applies to an end-to-end IP path. In some cases even 117 application state may be temporarily stored in the middle of the 118 network. The duration of this state varies widely: for example, RSVP 119 soft state lasts for the duration of the reservation, while SIP state 120 only lasts for one transaction, not for the duration of the session. 121 If an RSVP soft state box dies in mid-flow, the flow is perturbed 122 until the soft state is reconstructed, which is not true for SIP and 123 SMTP. 125 The idea of fate-sharing survives this recursion, but requires that 126 all application state created in middleboxes must be capable of re- 127 creation after failure. Additionally, to support this requirement, 128 where a function cannot be fulfilled completely, reliably and 129 securely by two endpoints of a conversation, the necessary 130 middleboxes to fulfil the function should be explicit partners in 131 explicit communication with at least one endpoint (or, by recursion 132 of the same principle, with an intermediate middlebox). In other 133 words, middleboxes should not be invisible, because their failures 134 need to be detected and dealt with by their communication partners. 136 A--------M1-------------M2-------------Z 137 \ / 138 \ / 139 M3----------------------/ 141 In this example, suppose a conversation between A and Z requires 142 intervention by middleboxes M1, M2 and M3, with the creation of soft 143 state in those boxes. To create this state, explicit communication 144 about the A-Z conversation may be required between each of the 145 following pairs: (A, M1), (M1, M2), (M2, Z), (M1, M3), and (M3,Z). 146 This will allow for recreation of soft state in M1, M2 and M3 (or 147 their backups) in all failure cases except total failure of A or Z; 148 thus the fate-sharing principle is preserved. 150 Subtle effects can occur when the middlebox actually modifies the 151 application data stream in some way, i.e. becomes an active agent in 152 destroying data path integrity. Specific concerns of this kind are 153 discussed in [RFC 3238]. 155 2.1. NATs as a Special Case of Middleboxes 157 The specific case of NAT middleboxes has led to much anguish, due to 158 the number of instances (notoriously TCP and IPSEC) in which end-to- 159 end integrity depends on the value of IP addresses. In other cases 160 (such as H.323) the protocol itself assumes address transparency. 161 NATs specifically cause breaches of one of the principles in [RFC 162 1958]: 163 "Addresses must be unambiguous (unique within any scope where they 164 may appear)." 165 [RFC 2993] goes into detail, and makes a strong case for address 166 translation being a dead end in the architecture. Unfortunately, 167 while we remain convinced that it is a dead end, it is crowded with 168 users, and workarounds are being sought, especially by the MIDCOM WG. 169 These workarounds may produce their own architectural issues [unsaf]. 170 It remains a fact that today, NAT inhibits progress beyond the simple 171 Web client/server model, and that the only well understood solution 172 that definitively fixes this problem is general adoption of a larger 173 address space. 175 [RFC 1958] also states that: 176 "Upper layer protocols must be able to identify end-points 177 unambiguously. In practice today, this means that addresses must be 178 the same at start and finish of transmission." 179 Again, NATs can cause violations of this principle. However, the new 180 SCTP transport protocol [RFC 2960] may provide a partial solution by 181 handling multiple addresses for a single connection. There have also 182 been proposals to allow TCP connections to update their endpoint 183 addresses [Snoeren]. 185 One well-established aspect of IP addresses that has become more 186 troublesome recently [RFC 2956] is that they combine two functions: 187 that of an "endpoint identifier" and a "locator". Such functional 188 overloading could be considered a violation of an important design 189 principle (see Section 4 below). Of course there were (and are) good 190 pragmatic engineering reasons for this choice. Nevertheless, if it 191 was possible to split endpoint identifiers from locators, many of the 192 problems currently associated with NATs, route aggregation, 193 multihoming, and renumbering would be fundamentally reformulated. 194 Despite recent research activity in this area, it remains uncertain 195 whether this would in fact simplify the problems just cited, or 196 merely move them to a different part of the Internet architecture. 198 The issue identified here has a parallel closer to the applications 199 layer. We have several efforts, in one form or another, to assign 200 URI types to all protocols and then permit naming URIs (e.g., a NAPTR 201 record ultimately maps a name into a URI). But, historically, our 202 names and addresses bind to to a network object, such as a host, and 203 we use port numbers to identify protocols and protocol listeners. 204 But URIs aren't like that -- they typically bind to a (host, 205 protocol) pair or something equivalent to it. And, through that 206 evolution, we are in danger of losing the host:port model That has 207 its own set of implications, some of which may even be good ones, but 208 it is another evolving architectural change whose implications are 209 not completely understood. 211 3. Internationalisation 213 [RFC 1958] states that: 215 "Public (i.e. widely visible) names should be in case-independent 216 ASCII. Specifically, this refers to DNS names, and to protocol 217 elements that are transmitted in text format." 219 This was not intended to diminish the importance of multiple 220 character sets for users of the Internet. It was a simple statement 221 of the need for a lingua franca (indeed, ASCII is very close to being 222 the character set of the original lingua franca). Since 1996, the 223 IETF has studied character set issues in general [RFC 2130] and made 224 specific recommendations for the use of a standardised approach [RFC 225 2277]. In fact, the situation is complicated by the fact that some 226 uses of text are hidden entirely in protocol elements and need only 227 be read by machines, while other uses are intended entirely for human 228 consumption. Many uses lie between these two extremes, which leads to 229 conflicting implementation requirements. 231 For the specific case of DNS, a working group on internationalisation 232 is in progress. A fundamental requirement in this work is to not 233 disturb the current use and operation of the domain name system, and 234 for the DNS to continue to allow any system anywhere to resolve any 235 domain name. This leads to some very strong requirements for 236 backwards compatibility with the existing ASCII-only DNS. Yet since 237 the DNS has come to be used as if it was a directory service, domain 238 names are also expected to be presented to users in local character 239 sets. Furthermore, users want them in forms that can be interpreted 240 locally as words. Satisfying this requirement simultaneously with 241 those for backwards compatibility and universal name resolution is 242 not easy. 244 This document is not intended to resolve these complex and difficult 245 issues. But the principle that names encoded in a text format within 246 protocol elements must be universally decodable (i.e. encoded in a 247 globally standard format with no intrinsic ambiguity) will not 248 change. At some point, it is possible that this format will no longer 249 be case-independent ASCII. 251 4. Overextension 253 There has been a strong tendency in the last few years to overload 254 some designs with functionality that was not originally anticipated, 255 with resulting operational complexities. One can argue that [RFC 256 1958] covers this point by stating "Keep it simple." However, it 257 should be stated explicitly that protocols and systems should not be 258 stretched beyond their reasonable design parameters until scaling, 259 reliability and security isssues have been resolved beyond doubt. 261 A nuance is that two different interpretations are possible: 263 1) Functional overloading considered harmful. 265 2) Extensible protocols have limits. 267 Both of these interpretations are true in various cases. Examples 268 where one or the other might apply include DNS [dnsrole], MPLS, and 269 BGP. It is hard to give precise criteria for the safe limits to 270 overloading or extension. In some cases, overloading or extending a 271 protocol may reduce total complexity by avoiding the creation of a 272 new protocol; in other cases a new ad hoc protocol might be the 273 simpler solution. 275 There is a subtle line between overloading and re-use. We have a 276 number of re-useable technologies, including component technologies 277 specifically designed for re-use. Examples include SASL, BEEP and 278 APEX. On the other hand, re-use should not go so far as to turn a 279 protocol into a Trojan Horse, as has happened with HTTP [RFC 3205]. 281 5. A New External Issue 283 Section 5 of [RFC 1958], "External Issues", deals with a number of 284 principles where the IETF's work touches on non-technical issues. 286 The IETF Policy on Wiretapping [RFC 2804] adds such a principle that 287 is not included in [RFC 1958]: the IETF has decided not to consider 288 legal requirements for wiretapping in certain jurisdictions as part 289 of the process for creating and maintaining IETF standards. That RFC 290 sets out the reasons for the new principle, e.g. that adding a 291 requirement for wiretapping will make affected protocol designs 292 considerably more complex. 294 As with all principles of the architecture, this one will no doubt 295 require review in the future. 297 6. Security Considerations 299 This document does not discuss issues directly affecting the security 300 of the Internet. However, it is worth noting that since [RFC 1958] 301 was published, the requirement for all Internet protocols to have an 302 adequate security solution has become more important than ever. 304 Non-normative References 306 [RFC 1958] Architectural Principles of the Internet. B. Carpenter, 307 Ed.. June 1996. 309 [RFC 2130] The Report of the IAB Character Set Workshop held 29 310 February - 1 March, 1996. C. Weider, C. Preston, K. Simonsen, H. 311 Alvestrand, R. Atkinson, M. Crispin, P. Svanberg. April 1997. 313 [RFC 2277] IETF Policy on Character Sets and Languages. H. 314 Alvestrand. January 1998. 316 [RFC 2543] SIP: Session Initiation Protocol. M. Handley, H. 317 Schulzrinne, E. Schooler, J. Rosenberg. March 1999. 319 [RFC 2775] Internet Transparency. B. Carpenter. February 2000. 321 [RFC 2804] IETF Policy on Wiretapping. IAB, IESG. May 2000. 323 [RFC 2956] Overview of 1999 IAB Network Layer Workshop. M. Kaat. 324 October 2000. 326 [RFC 2960] Stream Control Transmission Protocol. R. Stewart, Q. Xie, 327 K. Morneault, C. Sharp, H. Schwarzbauer, T. Taylor, I. Rytina, M. 328 Kalla, L. Zhang, V. Paxson. October 2000. 330 [RFC 2993] Architectural Implications of NAT. T. Hain. November 2000. 332 [RFC 3022] Traditional IP Network Address Translator (Traditional 333 NAT). P. Srisuresh, K. Egevang. January 2001. 335 [RFC 3027] Protocol Complications with the IP Network Address 336 Translator. M. Holdrege, P. Srisuresh. January 2001. 338 [RFC 3040] Internet Web Replication and Caching Taxonomy. I. Cooper, 339 I. Melve, G. Tomlinson. January 2001. 341 [RFC 3205] On the use of HTTP as a Substrate. K. Moore. February 342 2002. 344 [RFC 3234] Middleboxes: taxonomy and issues. B. Carpenter, S. Brim. 345 February 2002. 347 [RFC 3238] IAB Architectural and Policy Considerations for Open 348 Pluggable Edge Services. S. Floyd, L. Daigle. January 2002. 350 [dnsrole] Role of the Domain Name System. J. Klensin. Work in 351 progress, 2001 (draft-klensin-dns-role-01.txt) 353 [unsaf] IAB Considerations for UNilateral Self-Address Fixing 354 (UNSAF). IAB. Work in progress, 2002 (draft-iab-unsaf- 355 considerations-01.txt) 357 [Clark] D. Clark, M. Blumenthal, "Rethinking the Design of the 358 Internet: The End-to-end Arguments vs. the Brave New World", 359 Telecommunications Policy Research Conference, September 2000, 360 available via http://www.tprc.org/ 362 [Snoeren] Alex C. Snoeren, David G. Andersen and Hari Balakrishnan, 363 "Fine-Grained Failover Using Connection Migration," USENIX (San 364 Francisco), March 2001. 366 Acknowledgements 368 This document is a collective work of the Internet community, 369 published by the Internet Architecture Board. Special thanks to . 372 Editors' Addresses 374 Brian E. Carpenter 375 IBM Zurich Research Laboratory 376 Saeumerstrasse 4 377 8803 Rueschlikon 378 Switzerland 380 Email: brian@hursley.ibm.com 382 Rob Austein 383 InterNetShare, Incorporated 384 325M Sharon Park Drive, Suite 308 385 Menlo Park, CA 94025 386 USA 388 Email: sra@hactrn.net 390 Full Copyright Statement 392 PLACEHOLDER for full ISOC Copyright Statement