idnits 2.17.1 draft-iab-principles-00.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-26) 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 6 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 (October 1995) is 10421 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. 'NREN' -- 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 October 1995 5 Architectural Principles of the Internet 7 Abstract 9 draft-iab-principles-00.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 Status of this Memo 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as ``work in progress.'' 31 To learn the current status of any Internet-Draft, please check the 32 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 33 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 34 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 35 Rim). 37 Table of Contents: 39 Status of this Memo.............................................1 40 1. Constant Change..............................................2 41 2. Is there an Internet Architecture?...........................2 42 3. General Design Issues........................................4 43 4. Name and address issues......................................5 44 5. External Issues..............................................5 45 6. Related to Confidentiality and Authentication................5 46 7. Security considerations......................................6 47 Acknowledgements................................................6 48 References......................................................6 49 Editor's Address................................................6 51 1. Constant Change 53 In searching for Internet architectural principles, we must remember 54 that technical change is continuous in the information technology 55 industry. The Internet reflects this. Over the 25 years since the 56 ARPANET started, various measures of the size of the Internet have 57 increased by factors between 1000 (backbone speed) and 1000000 58 (number of hosts). In this environment, some architectural principles 59 inevitably change. Principles that seemed inviolable a few years ago 60 are deprecated today. Principles that seem sacred today will be 61 deprecated tomorrow. The notion of a fixed Reference Model into which 62 all designs must fit is anathema to the Internet. The principle of 63 constant change is perhaps the only principle of the Internet that 64 should survive indefinitely. 66 A good analogy for the development of the Internet is that of 67 constantly renewing the individual streets and buildings of a city, 68 rather than razing the city and rebuilding it. The architectural 69 principles therefore aim to provide a framework for creating 70 cooperation and standards, as a small "spanning set" of rules that 71 generates a large, varied and evolving space of technology. 73 Some current technical triggers for change include the limits to the 74 scaling of IPv4, the fact that gigabit/second networks and multimedia 75 present fundamentally new challenges, and the need for quality of 76 service and security guarantees in the commercial Internet. 78 As Lord Kelvin stated in 1895, "Heavier-than-air flying machines are 79 impossible." We would be foolish to imagine that the principles 80 listed below are more than a snapshot of our current understanding. 82 2. Is there an Internet Architecture? 84 2.1 Many members of the Internet community would argue that there is 85 no architecture, but only a tradition, which was not written down for 86 the first 25 years (or at least not by the IAB). However, in very 87 general terms, the community believes that the goal is connectivity, 88 the tool is the Internet Protocol, and the intelligence is end to end 89 rather than hidden in the network. 91 The current exponential growth of the network seems to show that 92 connectivity is its own reward, and is more valuable than any 93 individual application such as mail or the World-Wide Web. This 94 connectivity requires technical cooperation between service 95 providers, and flourishes in the increasingly liberal and competitive 96 commercial telecommunications environment. 98 The key to global connectivity is a single protocol at the inter- 99 networking layer. The key to exploiting this single protocol over 100 diverse hardware providing global connectivity is the "end to end 101 argument". 103 2.2 It is generally felt that there should be one, and only one, 104 protocol at the Internet level (but perhaps two versions for an 105 extended period during transition). There can be many protocols at 106 other levels. 108 This single protocol must be independent of the hardware medium and 109 hardware addressing. This approach allows the Internet to exploit 110 any new digital transmission technology of any kind, and to decouple 111 its addressing mechanisms from the hardware. It allows the Internet 112 to be the easy way to interconect fundamentally different 113 transmission media, and to offer a single platform for a wide variety 114 of Information Infrastructure applications and services. There is a 115 good exposition of this model, known as the "hourglass" model, in 116 [NREN]. 118 2.3 It is also generally felt that end-to-end functions can best be 119 realised by end-to-end protocols. 121 The end-to-end argument is discussed in depth in [Saltzer]. The 122 basic argument is that any network, however carefully designed, will 123 be subject to failures of transmission at some statistically 124 determined rate. The best way to cope with this is to accept it, and 125 give responsibility for the integrity of communication to the end 126 systems. 128 To quote from [Saltzer], "The function in question can completely and 129 correctly be implemented only with the knowledge and help of the 130 application standing at the endpoints of the communication system. 131 Therefore, providing that questioned function as a feature of the 132 communication system itself is not possible. (Sometimes an incomplete 133 version of the function provided by the communication system may be 134 useful as a performance enhancement.)" 136 This principle has important consequences. It shows that an end-to- 137 end protocol design should not rely on the maintenance of state (i.e. 138 information about the state of the end-to-end communication) inside 139 the network. Such state should be maintained only in the endpoints, 140 in such a way that the state can only be destroyed when the endpoint 141 itself breaks (known as fate-sharing). An immediate consequence of 142 this is that datagrams are better than virtual circuits. The 143 network's job is to route datagrams as efficiently and flexibly as 144 possible. Everything else should be done at the fringes. 146 It will be noted that this principle does not forbid "soft state", 147 i.e. state created adaptively to enhance quality of service, as long 148 as the accidental loss of soft state does not destroy the end-to-end 149 communication. 151 2.4 Fortunately, nobody owns the Internet, there is no centralized 152 control, and nobody can turn it off. Its evolution depends on rough 153 consensus about technical proposals, and on running code. 154 Engineering feed-back from real implementations is more important 155 than any architectural principles 157 3. General Design Issues 159 3.1 Heterogeneity is inevitable and must be supported by design. 160 Multiple types of hardware must be allowed for, e.g. transmission 161 speeds differing by at least 7 orders of magnitude, various computer 162 word lengths, and hosts ranging from memory-starved microprocessors 163 up to massively parallel supercomputers. Multiple types of 164 application protocol must be allowed for, ranging from the simplest 165 such as remote login up to the most complex such as distributed 166 databases. 168 3.2 If there are several ways of doing the same thing, choose one. 169 If a previous Internet design has successfully solved the same 170 problem, choose the same solution unless there is a good technical 171 reason not to. Duplication of the same protocol functionality should 172 be avoided as far as possible, without of course using this argument 173 to reject improvements. 175 3.3 All designs must scale readily to very many nodes per site and to 176 many millions of sites. 178 3.4 Performance and cost must be considered as well as functionality. 180 3.5 Keep it simple. When in doubt during design, choose the simplest 181 solution. If you can keep things separate, do so. 183 3.6 Avoid options and parameters whenever possible. Any options and 184 parameters should be configured or negotiated dynamically rather than 185 manually. 187 3.7 Be strict when sending and tolerant when receiving. 188 Implementations must follow specifications precisely when sending to 189 the network, and tolerate faulty input from the network. When in 190 doubt, discard faulty input silently, without returning an error 191 message unless this is required by the specification. 193 3.8 Be parsimonious with unsolicited packets, especially multicasts 194 and broadcasts. 196 3.9 Circular dependencies must be avoided. 198 For example, routing must not depend on look-ups in the 199 Domain Name System (DNS), since the updating of DNS servers 200 depends on successful routing. 202 3.10 Objects should be self decribing (include type and size). Only 203 type codes and other magic numbers assigned by the Internet Assigned 204 Numbers Authority (IANA) may be used. 206 3.11 All specifications should use the same terminology and notation, 207 and the same bit- and byte-order convention. 209 3.12 And perhaps most important: Nothing gets standardised until 210 there are multiple instances of running code. 212 4. Name and address issues 214 4.1 Avoid any design that requires addresses to be hard coded or 215 stored on non-volatile storage (except of course where this is an 216 essential requirement as in a name server or configuration server). 217 In general, user applications should use names rather than addresses. 219 4.1 A single naming structure should be used. 221 4.2 Public (i.e. widely visible) names should be case-independent. 223 4.3 Addresses must be unambiguous (unique within any scope where they 224 may appear). 226 4.4 Upper layer protocols must be able to identify end-points 227 unambiguously. In practice today, this means that addresses must be 228 the same at start and finish of transmission. 230 5. External Issues 232 5.1 Prefer unpatented technology, but if the best technology is 233 patented and is available to all at reasonable terms, then 234 incorporation of patented technology is acceptable. 236 5.2 The existence of export controls on some aspects of Internet 237 technology is only of secondary importance in choosing which 238 technology to adopt into the standards. All of the technology 239 required to implement Internet standards can be fabricated in each 240 country, so world wide deployment of Internet technology does not 241 depend on its exportability from any particular country or countries. 243 5.3 Any implementation which does not include all of the required 244 components cannot claim conformance with the standard. 246 5.4 Designs should be "internationally user-friendly". In particular, 247 there should be a uniform approach to character set support. 249 6. Related to Confidentiality and Authentication 251 6.1 All designs must fit into the Internet security architecture. 253 6.2 Confidentiality and authentication are the responsibility of end 254 users and must be implemented in the protocols used by the end users. 255 Endpoints should not depend on the confidentiality or integrity of 256 the carriers, and in particular, it is not the responsibility of the 257 carriers to ensure confidentiality. Carriers may choose to provide 258 some level of protection, but this is secondary to the primary 259 responsibility of the end users to protect themselves. 261 6.3 Wherever a cryptographic algorithm is called for in a protocol, 262 the protocol should be designed to permit alternative algorithms to 263 be used and the specific algorithm employed in a particular 264 implementation should be explicitly labeled. Official labels for 265 algorithms are to be recorded by the IANA. 267 6.4 In choosing algorithms, the algorithm should be one which is 268 widely regarded as strong enough to serve the purpose. Among 269 alternatives all of which are strong enough, preference should be 270 given to algorithms which have stood the test of time and which are 271 not unnecessarily inefficient. 273 7. Security considerations 275 We just did that. 277 Acknowledgements 279 This document is a collective work of the Internet community, 280 published by the Internet Architecture Board. 282 References 284 Note that the references have been deliberately limited to two 285 fundamental aspects of the Internet architecture. 287 [NREN] Realizing the Information Future: The Internet and Beyond, 288 National Research Council, National Academy Press, Washington, D.C., 289 1994 (Chapter 2, especially Figure 2.1). Available from the World- 290 Wide Web URL xerxes.nas.edu:70/1/nap/online/rtif. 292 [Saltzer] End-To-End Arguments in System Design, J.H. Saltzer, 293 D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp 294 277-288. 296 Editor's Address 298 Brian E. Carpenter 299 Group Leader, Communications Systems Phone: +41 22 767-4967 300 Computing and Networks Division Fax: +41 22 767-7155 301 CERN 302 European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch 303 1211 Geneva 23, Switzerland