home *** CD-ROM | disk | FTP | other *** search
/ Handbook of Infosec Terms 2.0 / Handbook_of_Infosec_Terms_Version_2.0_ISSO.iso / text / rfcs / rfc1958.txt < prev    next >
Text File  |  1996-08-08  |  18KB  |  452 lines

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