idnits 2.17.1 draft-iab-principles-02.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 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 a Security Considerations 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.) ** 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 (April 1996) is 10238 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 section? 'Clark' on line 327 looks like a reference -- Missing reference section? 'Saltzer' on line 331 looks like a reference 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 April 1996 5 Architectural Principles of the Internet 7 Abstract 9 draft-iab-principles-02.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................7 48 Acknowledgements................................................7 49 References......................................................8 50 Editor's Address................................................8 52 1. Constant Change 54 In searching for Internet architectural principles, we must remember 55 that technical change is continuous in the information technology 56 industry. The Internet reflects this. Over the 25 years since the 57 ARPANET started, various measures of the size of the Internet have 58 increased by factors between 1000 (backbone speed) and 1000000 59 (number of hosts). In this environment, some architectural principles 60 inevitably change. Principles that seemed inviolable a few years ago 61 are deprecated today. Principles that seem sacred today will be 62 deprecated tomorrow. The principle of constant change is perhaps the 63 only principle of the Internet that should survive indefinitely. 65 The purpose of this document is not, therefore, to lay down dogma 66 about how Internet protocols should be designed, or even about how 67 they should fit together. Rather, it is to convey various guidelines 68 that have been found useful in the past, and that may be useful to 69 those designing new protocols or evaluating such designs. 71 A good analogy for the development of the Internet is that of 72 constantly renewing the individual streets and buildings of a city, 73 rather than razing the city and rebuilding it. The architectural 74 principles therefore aim to provide a framework for creating 75 cooperation and standards, as a small "spanning set" of rules that 76 generates a large, varied and evolving space of technology. 78 Some current technical triggers for change include the limits to the 79 scaling of IPv4, the fact that gigabit/second networks and multimedia 80 present fundamentally new challenges, and the need for quality of 81 service and security guarantees in the commercial Internet. 83 As Lord Kelvin stated in 1895, "Heavier-than-air flying machines are 84 impossible." We would be foolish to imagine that the principles 85 listed below are more than a snapshot of our current understanding. 87 2. Is there an Internet Architecture? 89 2.1 Many members of the Internet community would argue that there is 90 no architecture, but only a tradition, which was not written down for 91 the first 25 years (or at least not by the IAB). However, in very 92 general terms, the community believes that the goal is connectivity, 93 the tool is the Internet Protocol, and the intelligence is end to end 94 rather than hidden in the network. 96 The current exponential growth of the network seems to show that 97 connectivity is its own reward, and is more valuable than any 98 individual application such as mail or the World-Wide Web. This 99 connectivity requires technical cooperation between service 100 providers, and flourishes in the increasingly liberal and competitive 101 commercial telecommunications environment. 103 The key to global connectivity is the inter-networking layer. The 104 key to exploiting this layer over diverse hardware providing global 105 connectivity is the "end to end argument". 107 2.2 It is generally felt that in an ideal situation there should be 108 one, and only one, protocol at the Internet level. This allows for 109 uniform and relatively seamless operations in a competitive, multi- 110 vendor, multi-provider public network. There can of course be 111 multiple protocols to satisfy different requirements at other levels, 112 and there are many successful examples of large private networks with 113 multiple network layer protocols in use. 115 In practice, there are at least two reasons why more than one network 116 layer protocol might be in use on the public Internet. Firstly, there 117 can be a need for gradual transition from one version of IP to 118 another. Secondly, fundamentally new requirements might lead to a 119 fundamentally new protocol. 121 The Internet level protocol must be independent of the hardware 122 medium and hardware addressing. This approach allows the Internet to 123 exploit any new digital transmission technology of any kind, and to 124 decouple its addressing mechanisms from the hardware. It allows the 125 Internet to be the easy way to interconect fundamentally different 126 transmission media, and to offer a single platform for a wide variety 127 of Information Infrastructure applications and services. There is a 128 good exposition of this model, and other important fundemental 129 issues, in [Clark]. 131 2.3 It is also generally felt that end-to-end functions can best be 132 realised by end-to-end protocols. 134 The end-to-end argument is discussed in depth in [Saltzer]. The 135 basic argument is that, as a first principle, certain required end- 136 to-end functions can only be performed correctly by the end-systems 137 themselves. A specific case is that any network, however carefully 138 designed, will be subject to failures of transmission at some 139 statistically determined rate. The best way to cope with this is to 140 accept it, and give responsibility for the integrity of communication 141 to the end systems. Another specific case is end-to-end security. 143 To quote from [Saltzer], "The function in question can completely and 144 correctly be implemented only with the knowledge and help of the 145 application standing at the endpoints of the communication system. 146 Therefore, providing that questioned function as a feature of the 147 communication system itself is not possible. (Sometimes an incomplete 148 version of the function provided by the communication system may be 149 useful as a performance enhancement.)" 151 This principle has important consequences if we require applications 152 to survive partial network failures. An end-to-end protocol design 153 should not rely on the maintenance of state (i.e. information about 154 the state of the end-to-end communication) inside the network. Such 155 state should be maintained only in the endpoints, in such a way that 156 the state can only be destroyed when the endpoint itself breaks 157 (known as fate-sharing). An immediate consequence of this is that 158 datagrams are better than classical virtual circuits. The network's 159 job is to route datagrams as efficiently and flexibly as possible. 161 Everything else should be done at the fringes. 163 To perform its services, the network maintains some state 164 information: routes, QoS guarantees that it makes, session 165 information where that is used in header compression, compression 166 histories for data compression, and the like. This state must be 167 self-healing; adaptive procedures or protocols must exist to derive 168 and maintain that state, and change it when the topology or activity 169 of the network changes. The volume of this state must be minimized, 170 and the loss of the state must not result in more than a temporary 171 denial of service given that connectivity exists. Manually 172 configured state must be kept to an absolute minimum. 174 2.4 Fortunately, nobody owns the Internet, there is no centralized 175 control, and nobody can turn it off. Its evolution depends on rough 176 consensus about technical proposals, and on running code. 177 Engineering feed-back from real implementations is more important 178 than any architectural principles. 180 3. General Design Issues 182 3.1 Heterogeneity is inevitable and must be supported by design. 183 Multiple types of hardware must be allowed for, e.g. transmission 184 speeds differing by at least 7 orders of magnitude, various computer 185 word lengths, and hosts ranging from memory-starved microprocessors 186 up to massively parallel supercomputers. Multiple types of 187 application protocol must be allowed for, ranging from the simplest 188 such as remote login up to the most complex such as distributed 189 databases. 191 3.2 If there are several ways of doing the same thing, choose one. 192 If a previous design, in the Internet context or elsewhere, has 193 successfully solved the same problem, choose the same solution unless 194 there is a good technical reason not to. Duplication of the same 195 protocol functionality should be avoided as far as possible, without 196 of course using this argument to reject improvements. 198 3.3 All designs must scale readily to very many nodes per site and to 199 many millions of sites. 201 3.4 Performance and cost must be considered as well as functionality. 203 3.5 Keep it simple. When in doubt during design, choose the simplest 204 solution. 206 3.6 Modularity is good. If you can keep things separate, do so. 208 3.7 In many cases it is better to adopt an almost complete solution 209 now, rather than to wait until a perfect solution can be found. 211 3.8 Avoid options and parameters whenever possible. Any options and 212 parameters should be configured or negotiated dynamically rather than 213 manually. 215 3.9 Be strict when sending and tolerant when receiving. 216 Implementations must follow specifications precisely when sending to 217 the network, and tolerate faulty input from the network. When in 218 doubt, discard faulty input silently, without returning an error 219 message unless this is required by the specification. 221 3.10 Be parsimonious with unsolicited packets, especially multicasts 222 and broadcasts. 224 3.11 Circular dependencies must be avoided. 226 For example, routing must not depend on look-ups in the 227 Domain Name System (DNS), since the updating of DNS servers 228 depends on successful routing. 230 3.12 Objects should be self decribing (include type and size), within 231 reasonable limits. Only type codes and other magic numbers assigned 232 by the Internet Assigned Numbers Authority (IANA) may be used. 234 3.13 All specifications should use the same terminology and notation, 235 and the same bit- and byte-order convention. 237 3.14 And perhaps most important: Nothing gets standardised until 238 there are multiple instances of running code. 240 4. Name and address issues 242 4.1 Avoid any design that requires addresses to be hard coded or 243 stored on non-volatile storage (except of course where this is an 244 essential requirement as in a name server or configuration server). 245 In general, user applications should use names rather than addresses. 247 4.2 A single naming structure should be used. 249 4.3 Public (i.e. widely visible) names should be in case-independent 250 ASCII. Specifically, this refers to DNS names, and to protocol 251 elements that are transmitted in text format. 253 4.4 Addresses must be unambiguous (unique within any scope where they 254 may appear). 256 4.5 Upper layer protocols must be able to identify end-points 257 unambiguously. In practice today, this means that addresses must be 258 the same at start and finish of transmission. 260 5. External Issues 262 5.1 Prefer unpatented technology, but if the best technology is 263 patented and is available to all at reasonable terms, then 264 incorporation of patented technology is acceptable. 266 5.2 The existence of export controls on some aspects of Internet 267 technology is only of secondary importance in choosing which 268 technology to adopt into the standards. All of the technology 269 required to implement Internet standards can be fabricated in each 270 country, so world wide deployment of Internet technology does not 271 depend on its exportability from any particular country or countries. 273 5.3 Any implementation which does not include all of the required 274 components cannot claim conformance with the standard. 276 5.4 Designs should be fully international, with support for 277 localisation (adaptation to local character sets). In particular, 278 there should be a uniform approach to character set tagging for 279 information content. 281 6. Related to Confidentiality and Authentication 283 6.1 All designs must fit into the IP security architecture. 285 6.2 It is highly desirable that Internet carriers protect the privacy 286 and authenticity of all traffic, but this is not a requirement of the 287 architecture. Confidentiality and authentication are the 288 responsibility of end users and must be implemented in the protocols 289 used by the end users. Endpoints should not depend on the 290 confidentiality or integrity of the carriers. Carriers may choose to 291 provide some level of protection, but this is secondary to the 292 primary responsibility of the end users to protect themselves. 294 6.3 Wherever a cryptographic algorithm is called for in a protocol, 295 the protocol should be designed to permit alternative algorithms to 296 be used and the specific algorithm employed in a particular 297 implementation should be explicitly labeled. Official labels for 298 algorithms are to be recorded by the IANA. 300 (It can be argued that this principle could be generalised beyond the 301 security area.) 303 6.4 In choosing algorithms, the algorithm should be one which is 304 widely regarded as strong enough to serve the purpose. Among 305 alternatives all of which are strong enough, preference should be 306 given to algorithms which have stood the test of time and which are 307 not unnecessarily inefficient. 309 6.5 To ensure interoperation between endpoints making use of security 310 services, one algorithm (or suite of algorithms) should be mandated 311 to ensure the ability to negotiate a secure context between 312 implementations. Without this, implementations might otherwise not 313 have an algorithm in common and not be able to communicate securely. 315 Acknowledgements 317 This document is a collective work of the Internet community, 318 published by the Internet Architecture Board. Special thanks to Fred 319 Baker, Noel Chiappa, Donald Eastlake, Frank Kastenholz, Neal 320 McBurnett, Masataka Ohta, Jeff Schiller and Lansing Sloan. 322 References 324 Note that the references have been deliberately limited to two 325 fundamental papers on the Internet architecture. 327 [Clark] The Design Philosophy of the DARPA Internet Protocols, 328 D.D.Clark, Proc SIGCOMM 88, ACM CCR Vol 18, Number 4, August 1988, 329 pages 106-114 (reprinted in ACM CCR Vol 25, 1995, pages 102-111). 331 [Saltzer] End-To-End Arguments in System Design, J.H. Saltzer, 332 D.P.Reed, D.D.Clark, ACM TOCS, Vol 2, Number 4, November 1984, pp 333 277-288. 335 Editor's Address 337 Brian E. Carpenter 338 Group Leader, Communications Systems Phone: +41 22 767-4967 339 Computing and Networks Division Fax: +41 22 767-7155 340 CERN 341 European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch 342 1211 Geneva 23, Switzerland