rfc1726.txt

中、英文RFC文档大全打包下载完全版 .

      selection of which first-hop router to send any given packet to.
      IPng must not mandate that users or administrators manually
      configure first-hop routers into hosts.

      Also, a strength of IPv4 has been its ability to be used on
      isolated subnets.  IPng hosts must be able to work on networks
      without routers present.

      Additional elements of this criterion are:

      * Ease of address allocation.
      * Ease of changing the topology of the network within a particular
        routing domain.
      * Ease of changing network provider.
      * Ease of (re)configuring host/endpoint parameters such as
        addressing and identification.
      * Ease of (re)configuring router parameters such as addressing and
        identification.



Partridge and Kastenholz                                       [Page 16]

RFC 1726                IPng Technical Criteria            December 1994


      * Address allocation and assignment authority must be delegated as
        far 'down' the administrative hierarchy as possible.

      The requirements of this section apply only to IPng and its
      supporting protocols (such as for routing, address resolution, and
      network-layer control).  Specifically, as far as IPng is
      concerned, we are concerned only with how routers and hosts get
      their configuration information.

      We note that in general, automatic configuration of hosts is a
      large and complex problem and getting the configuration
      information into hosts and routers is only one, small, piece of
      the problem.  A large amount of additional, non-Internet-layer
      work is needed in order to be able to do "plug-and-play"
      networking.  Other aspects of "plug-and-play" networking include
      things like: Autoregistration of new nodes with DNS, configuring
      security service systems (e.g., Kerberos), setting up email relays
      and mail servers, locating network resources, adding entries to
      NFS export files, and so on.  To a large degree, these
      capabilities do not have any dependence on the IPng protocol
      (other than, perhaps, the format of addresses).

      We require that any IPng proposal not impede or prevent, in any
      way, the development of "plug-and-play" network configuration
      technologies.

      Automatic configuration of network nodes must not prevent users or
      administrators from also being able to manually configure their
      systems.

   Time Frame
      A method for plug and play on small subnets is immediately
      required.

      We believe that this is an extremely critical area for any IPng as
      a major complaint of the IP community as a whole is the difficulty
      in administering large IP networks.  Furthermore, ease of
      installation is likely to speed the deployment of IPng.

5.9 Secure Operation

   CRITERION
      IPng must provide a secure network layer.

   DISCUSSION
      We need to be sure that we have not created a network that is a
      cracker's playground.




Partridge and Kastenholz                                       [Page 17]

RFC 1726                IPng Technical Criteria            December 1994


      In order to meet the Robustness criterion, some elements of what
      is commonly shrugged off as "security" are needed; e.g., to prevent
      a villain from injecting bogus routing packets, and destroying the
      routing system within the network.  This criterion covers those
      aspects of security that are not needed to provide the Robustness
      criterion.

      Another aspect of security is non-repudiation of origin.  In order
      to adequately support the expected need for simple accounting, we
      believe that this is a necessary feature.

      In order to safely support requirements of the commercial world,
      IPng-level security must have capabilities to prevent
      eavesdroppers from monitoring traffic and deducing traffic
      patterns.  This is particularly important in multi-access networks
      such as cable TV networks [5].

      Aspects of security at the IP level to be considered include:

      * Denial of service protections [6],
      * Continuity of operations [6],
      * Precedence and preemption [6],
      * Ability to allow rule-based access control technologies [6]
      * Protection of routing and control-protocol operations [9],
      * Authentication of routing information exchanges, packets, data,
        and sources (e.g., make sure that the routing packet came from a
        router) [9],
      * QOS security (i.e., protection against improper use of network-
        layer resources, functions, and capabilities),
      * Auto-configuration protocol operations in that the host must be
        assured that it is getting its information from proper sources,
      * Traffic pattern confidentiality is strongly desired by several
        communities [9] and [5].

   Time Frame
      Security should be an integral component of any IPng from the
      beginning.

5.10 Unique Naming

   CRITERION
      IPng must assign all IP-Layer objects in the global, ubiquitous,
      Internet unique names.  These names may or may not have any
      location, topology, or routing significance.

   DISCUSSION
      We use the term "Name" in this criterion synonymously with the
      term "End Point Identifier" as used in the NIMROD proposal, or as



Partridge and Kastenholz                                       [Page 18]

RFC 1726                IPng Technical Criteria            December 1994


      IP Addresses uniquely identify interfaces/hosts in IPv4.  These
      names may or may not carry any routing or topology information.
      See [11] for more discussion on this topic.

      IPng must provide identifiers which are suitable for use as
      globally unique, unambiguous, and ubiquitous names for endpoints,
      nodes, interfaces, and the like.  Every datagram must carry the
      identifier of both its source and its destination (or some method
      must be available to determine these identifiers, given a
      datagram).  We believe that this is required in order to support
      certain accounting functions.

      Other functions and uses of unique names are:

      * To uniquely identify endpoints (thus if the unique name and
        address are not the same, the TCP pseudo-header should include
        the unique name rather than the address)
      * To allow endpoints to change topological location on the network
        (e.g., migrate) without changing their unique names.
      * To give one or more unique names to a node on the network (i.e.,
        one node may have multiple unique names)

      An identifier must refer to one and only one object while that
      object is in existence.  Furthermore, after an object ceases to
      exist, the identifier should be kept unused long enough to ensure
      that any packets containing the identifier have drained out of the
      Internet system, and that other references to the identifier have
      probably been lost.  We note that the term "existence" is as much
      an administrative issue as a technical one.  For example, if a
      workstation is reassigned, given a new IP address and node name,
      and attached to a new subnetwork, is it the same object or not.
      This does argue for a namespace that is relatively large and
      relatively stable.

   Time Frame
      We see this as a fundamental element of the IP layer and it should
      be in the protocol from the beginning.

5.11 Access

   CRITERION
      The protocols that define IPng, its associated protocols (similar
      to ARP and ICMP in IPv4) and the routing protocols (as in OSPF,
      BGP, and RIP for IPv4) must be published as standards track RFCs
      and must satisfy the requirements specified in RFC1310.  These
      documents should be as freely available and redistributable as the
      IPv4 and related RFCs.  There must be no specification-related
      licensing fees for implementing or selling IPng software.



Partridge and Kastenholz                                       [Page 19]

RFC 1726                IPng Technical Criteria            December 1994


   DISCUSSION
      An essential aspect of the development of the Internet and its
      protocols has been the fact that the protocol specifications are
      freely available to anyone who wishes a copy.  Beyond simply
      minimizing the cost of learning about the technology, the free
      access to specifications has made it easy for researchers and
      developers to easily incorporate portions of old protocol
      specifications in the revised specifications.  This type of easy
      access to the standards documents is required for IPng.

   Time Frame
      An IPng and its related protocols must meet these standards for
      openness before an IPng can be approved.

5.12 Multicast

   CRITERION
      The protocol must support both unicast and multicast packet
      transmission.  Part of the multicast capability is a requirement
      to be able to send to "all IP hosts on a given subnetwork".
      Dynamic and automatic routing of multicasts is also required.

   DISCUSSION
      IPv4 has made heavy use of the ability to multicast requests to
      all IPv4 hosts on a subnet, especially for autoconfiguration.
      This ability must be retained in IPng.

      Unfortunately, IPv4 currently uses the local media broadcast
      address to multicast to all IP hosts.  This behavior is anti-
      social in mixed-protocol networks and should be fixed in IPng.
      There's no good reason for IPng to send to all hosts on a subnet
      when it only wishes to send to all IPng hosts.  The protocol must
      make allowances for media that do not support true multicasting.

      In the past few years, we have begun to deploy support for wide-
      area multicast addressing in the Internet, and it has proved
      valuable.  This capability must not be lost in the transition to
      IPng.

      The ability to restrict the range of a multicast to specific
      networks is also important.  Furthermore, it must be possible to
      "selectively" multicast packets. That is, it must be possible to
      send a multicast to a remote, specific portion or area of the
      Internet (such as a specific network or subnetwork) and then have
      that multicast limited to just that specific area.  Furthermore,
      any given network or subnetwork should be capable of supporting
      2**16 "local" multicast groups, i.e., groups that are not
      propagated to other networks.  See [8].



Partridge and Kastenholz                                       [Page 20]

RFC 1726                IPng Technical Criteria            December 1994


      It should be noted that addressing -- specifically the syntax and
      semantics of addresses -- has a great impact on the scalability of
      the architecture.

      Currently, large-scale multicasts are routed manually through the
      Internet.  While this is fine for experiments, a "production"
      system requires that multicast-routing be dynamic and automatic.
      Multicast groups must be able to be created and destroyed, hosts
      must be able to join and leave multicast groups and the network
      routing infrastructure must be able to locate new multicast groups
      and destinations and route traffic to those destinations all
      without manual intervention.

      Large, topologically dispersed, multicast groups (with up to 10**6
      participants) must be supported.  Some applications are given in
      [8].

   Time Frame
      Obviously, address formats, algorithms for processing and
      interpreting the multicast addresses must be immediately available
      in IPng.  Broadcast and Multicast transmission/reception of
      packets are required immediately.  Dynamic routing of multicast
      packets must be available within 18 months.

      We believe that Multicast Addressing is vital to support future
      applications such as remote conferencing.  It is also used quite
      heavily in the current Internet for things like service location
      and routing.

5.13 Extensibility

   CRITERION
      The protocol must be extensible; it must be able to evolve to meet
      the future service needs of the Internet. This evolution must be
      achievable without requiring network-wide software upgrades.  IPng
      is expected to evolve over time. As it evolves, it must be able to
      allow different versions to coexist on the same network.

   DISCUSSION
      We do not today know all of the things that we will want the
      Internet to be able to do 10 years from now.  At the same time, it
      is not reasonable to ask users to transition to a new protocol