idnits 2.17.1 draft-iab-principles-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 Internet-Drafts being working documents. ** 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? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** 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 8 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 Introduction section. ** 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 3 instances of too long lines in the document, the longest one being 4 characters in excess of 72. 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 (January 1996) is 10322 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'Clark' -- Possible downref: Non-RFC (?) normative reference: ref. 'Saltzer' Summary: 11 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IAB B. Carpenter 2 Internet Draft (editor) 3 January 1996 5 Architectural Principles of the Internet 7 Abstract 9 draft-iab-principles-01.txt 11 The Internet and its architecture have grown in evolutionary fashion from 12 modest beginnings, rather than from a Grand Plan. While this process of 13 evolution is one of the main reasons for the technology's success, it 14 nevertheless seems useful to record a snapshot of the current 15 principles of the Internet architecture. This is intended for general 16 guidance and general interest, and is in no way intended to be a 17 formal or invariant reference model. 19 Discussion of this draft should take place on the ietf@ietf.org list 21 Status of this Memo 23 This document is an Internet-Draft. Internet-Drafts are working 24 documents of the Internet Engineering Task Force (IETF), its areas, 25 and its working groups. Note that other groups may also distribute 26 working documents as Internet-Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet- Drafts as reference 31 material or to cite them other than as ``work in progress.'' 33 To learn the current status of any Internet-Draft, please check the 34 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 35 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 36 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 37 Rim). 39 Table of Contents: 41 Status of this Memo.............................................1 42 1. Constant Change..............................................2 43 2. Is there an Internet Architecture?...........................2 44 3. General Design Issues........................................5 45 4. Name and address issues......................................6 46 5. External Issues..............................................6 47 6. Related to Confidentiality and Authentication................6 48 7. Security considerations......................................7 49 Acknowledgements................................................7 50 References......................................................8 51 Editor's Address................................................8 53 1. Constant Change 55 In searching for Internet architectural principles, we must remember 56 that technical change is continuous in the information technology 57 industry. The Internet reflects this. Over the 25 years since the 58 ARPANET started, various measures of the size of the Internet have 59 increased by factors between 1000 (backbone speed) and 1000000 60 (number of hosts). In this environment, some architectural principles 61 inevitably change. Principles that seemed inviolable a few years ago 62 are deprecated today. Principles that seem sacred today will be 63 deprecated tomorrow. The notion of a fixed Reference Model into which 64 all designs must fit is anathema to the Internet. The principle of 65 constant change is perhaps the only principle of the Internet that 66 should survive indefinitely. 68 A good analogy for the development of the Internet is that of 69 constantly renewing the individual streets and buildings of a city, 70 rather than razing the city and rebuilding it. The architectural 71 principles therefore aim to provide a framework for creating 72 cooperation and standards, as a small "spanning set" of rules that 73 generates a large, varied and evolving space of technology. 75 Some current technical triggers for change include the limits to the 76 scaling of IPv4, the fact that gigabit/second networks and multimedia 77 present fundamentally new challenges, and the need for quality of 78 service and security guarantees in the commercial Internet. 80 As Lord Kelvin stated in 1895, "Heavier-than-air flying machines are 81 impossible." We would be foolish to imagine that the principles 82 listed below are more than a snapshot of our current understanding. 84 2. Is there an Internet Architecture? 86 2.1 Many members of the Internet community would argue that there is 87 no architecture, but only a tradition, which was not written down for 88 the first 25 years (or at least not by the IAB). However, in very 89 general terms, the community believes that the goal is connectivity, 90 the tool is the Internet Protocol, and the intelligence is end to end 91 rather than hidden in the network. 93 The current exponential growth of the network seems to show that 94 connectivity is its own reward, and is more valuable than any 95 individual application such as mail or the World-Wide Web. This 96 connectivity requires technical cooperation between service 97 providers, and flourishes in the increasingly liberal and competitive 98 commercial telecommunications environment. 100 The key to global connectivity is a single protocol at the inter- 101 networking layer. The key to exploiting this single protocol over 102 diverse hardware providing global connectivity is the "end to end 103 argument". 105 2.2 It is generally felt that there should be one, and only one, 106 protocol at the Internet level (but perhaps two versions for an 107 extended period during transition). There can be many protocols at 108 other levels. 110 This single protocol must be independent of the hardware medium and 111 hardware addressing. This approach allows the Internet to exploit 112 any new digital transmission technology of any kind, and to decouple 113 its addressing mechanisms from the hardware. It allows the Internet 114 to be the easy way to interconect fundamentally different 115 transmission media, and to offer a single platform for a wide variety 116 of Information Infrastructure applications and services. There is a 117 good exposition of this model, and other important fundemental 118 issues, in [Clark]. 120 2.3 It is also generally felt that end-to-end functions can best be 121 realised by end-to-end protocols. 123 The end-to-end argument is discussed in depth in [Saltzer]. The 124 basic argument is that, as a first principle, certain required end- 125 to-end functions can only be performed correctly by the end-systems 126 themselves. A specific case is that any network, however carefully 127 designed, will be subject to failures of transmission at some 128 statistically determined rate. The best way to cope with this is to 129 accept it, and give responsibility for the integrity of communication 130 to the end systems. Another specific case is end-to-end security. 132 To quote from [Saltzer], "The function in question can completely and 133 correctly be implemented only with the knowledge and help of the 134 application standing at the endpoints of the communication system. 135 Therefore, providing that questioned function as a feature of the 136 communication system itself is not possible. (Sometimes an incomplete 137 version of the function provided by the communication system may be 138 useful as a performance enhancement.)" 140 This principle has important consequences if we require applications 141 to survive partial network failures. An end-to-end protocol design 142 should not rely on the maintenance of state (i.e. information about 143 the state of the end-to-end communication) inside the network. Such 144 state should be maintained only in the endpoints, in such a way that 145 the state can only be destroyed when the endpoint itself breaks 146 (known as fate-sharing). An immediate consequence of this is that 147 datagrams are better than classical virtual circuits. The network's 148 job is to route datagrams as efficiently and flexibly as possible. 149 Everything else should be done at the fringes. 151 To perform its services, the network maintains some state 152 information: routes, QoS guarantees that it makes, session 153 information where that is used in header compression, compression 154 histories for data compression, and the like. This state must be 155 self-healing; adaptive procedures or protocols must exist to derive 156 and maintain that state, and change it when the topology or activity 157 of the network changes. The volume of this state must be minimized, 158 and the loss of the state must not result in more than a temporary 159 denial of service given that connectivity exists. 161 2.4 Fortunately, nobody owns the Internet, there is no centralized 162 control, and nobody can turn it off. Its evolution depends on rough 163 consensus about technical proposals, and on running code. 164 Engineering feed-back from real implementations is more important 165 than any architectural principles 167 3. General Design Issues 169 3.1 Heterogeneity is inevitable and must be supported by design. 170 Multiple types of hardware must be allowed for, e.g. transmission 171 speeds differing by at least 7 orders of magnitude, various computer 172 word lengths, and hosts ranging from memory-starved microprocessors 173 up to massively parallel supercomputers. Multiple types of 174 application protocol must be allowed for, ranging from the simplest 175 such as remote login up to the most complex such as distributed 176 databases. 178 3.2 If there are several ways of doing the same thing, choose one. 179 If a previous Internet design has successfully solved the same 180 problem, choose the same solution unless there is a good technical 181 reason not to. Duplication of the same protocol functionality should 182 be avoided as far as possible, without of course using this argument 183 to reject improvements. 185 3.3 All designs must scale readily to very many nodes per site and to 186 many millions of sites. 188 3.4 Performance and cost must be considered as well as functionality. 190 3.5 Keep it simple. When in doubt during design, choose the simplest 191 solution. If you can keep things separate, do so. 193 3.6 In many cases it is better to adopt an almost complete solution 194 now, rather than to wait until a perfect solution can be found. 196 3.7 Avoid options and parameters whenever possible. Any options and 197 parameters should be configured or negotiated dynamically rather than 198 manually. 200 3.8 Be strict when sending and tolerant when receiving. 201 Implementations must follow specifications precisely when sending to 202 the network, and tolerate faulty input from the network. When in 203 doubt, discard faulty input silently, without returning an error 204 message unless this is required by the specification. 206 3.9 Be parsimonious with unsolicited packets, especially multicasts 207 and broadcasts. 209 3.10 Circular dependencies must be avoided. 211 For example, routing must not depend on look-ups in the 212 Domain Name System (DNS), since the updating of DNS servers 213 depends on successful routing. 215 3.11 Objects should be self decribing (include type and size), within 216 reasonable limits. Only type codes and other magic numbers assigned 217 by the Internet Assigned Numbers Authority (IANA) may be used. 219 3.12 All specifications should use the same terminology and notation, 220 and the same bit- and byte-order convention. 222 3.13 And perhaps most important: Nothing gets standardised until 223 there are multiple instances of running code. 225 4. Name and address issues 227 4.1 Avoid any design that requires addresses to be hard coded or 228 stored on non-volatile storage (except of course where this is an 229 essential requirement as in a name server or configuration server). 230 In general, user applications should use names rather than addresses. 232 4.2 A single naming structure should be used. 234 4.3 Public (i.e. widely visible) names should be in case-independent 235 ASCII. 237 4.4 Addresses must be unambiguous (unique within any scope where they 238 may appear). 240 4.5 Upper layer protocols must be able to identify end-points 241 unambiguously. In practice today, this means that addresses must be 242 the same at start and finish of transmission. 244 5. External Issues 246 5.1 Prefer unpatented technology, but if the best technology is 247 patented and is available to all at reasonable terms, then 248 incorporation of patented technology is acceptable. 250 5.2 The existence of export controls on some aspects of Internet 251 technology is only of secondary importance in choosing which 252 technology to adopt into the standards. All of the technology 253 required to implement Internet standards can be fabricated in each 254 country, so world wide deployment of Internet technology does not 255 depend on its exportability from any particular country or countries. 257 5.3 Any implementation which does not include all of the required 258 components cannot claim conformance with the standard. 260 5.4 Designs should be "internationally user-friendly". In particular, 261 there should be a uniform approach to character set support for 262 information content. 264 6. Related to Confidentiality and Authentication 266 6.1 All designs must fit into the IP security architecture. 268 6.2 Confidentiality and authentication are the responsibility of end 269 users and must be implemented in the protocols used by the end users. 270 Endpoints should not depend on the confidentiality or integrity of 271 the carriers, and in particular, it is not the responsibility of the 272 carriers to ensure confidentiality. Carriers may choose to provide 273 some level of protection, but this is secondary to the primary 274 responsibility of the end users to protect themselves. 276 6.3 Wherever a cryptographic algorithm is called for in a protocol, 277 the protocol should be designed to permit alternative algorithms to 278 be used and the specific algorithm employed in a particular 279 implementation should be explicitly labeled. Official labels for 280 algorithms are to be recorded by the IANA. 282 (It can be argued that this principle could be generalised beyond the 283 security area.) 285 6.4 In choosing algorithms, the algorithm should be one which is 286 widely regarded as strong enough to serve the purpose. Among 287 alternatives all of which are strong enough, preference should be 288 given to algorithms which have stood the test of time and which are 289 not unnecessarily inefficient. 291 7. Security considerations 293 We just did that. 295 Acknowledgements 297 This document is a collective work of the Internet community, 298 published by the Internet Architecture Board. Special thanks to Fred 299 Baker, Noel Chiappa, Donald Eastlake, Frank Kastenholz, and Neal 300 McBurnett. 302 References 304 Note that the references have been deliberately limited to two 305 fundamental papers on the Internet architecture. 307 [Clark] The Design Philosophy of the DARPA Internet Protocols, 308 D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988, 309 pages 106-114 (reprinted in ACM CCR Vol 25, 1995, pages 102-111). 311 [Saltzer] End-To-End Arguments in System Design, J.H. Saltzer, 312 D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp 313 277-288. 315 Editor's Address 317 Brian E. Carpenter 318 Group Leader, Communications Systems Phone: +41 22 767-4967 319 Computing and Networks Division Fax: +41 22 767-7155 320 CERN 321 European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch 322 1211 Geneva 23, Switzerland