rfc1454.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 843 行 · 第 1/3 页

Dixon                                                           [Page 5]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


2.7 The End of Lifetime as We Know It

   The old IPv4 "Time to Live" field has been recast in every case as a
   simple hop count, largely on grounds of implementation convenience.
   Although the old TTL was largely implemented in this fashion anyway,
   it did serve an architectural purpose in putting an upper bound on
   the lifetime of a packet in the network. If this field is recast as a
   hop-count, there must be some other specification of the maximum
   lifetime of a packet in the network so that a source host can ensure
   that network-layer fragment ids and transport-layer sequence numbers
   are never in danger of re-use whilst there is a danger of confusion.
   There are, in fact, three separate issues here:

      1. Terminating routing loops (solved by hop count).

      2. Bounding lifetime of network-layer packets (a necessity,
         unspecified so far) to support assumptions by the transport
         layer.

      3. Permitting the source to place further restrictions on packet
         lifetime (for example so that "old" real-time traffic can be
         discarded in favour of new traffic in the case of congestion
         (an optional feature, unspecified so far).

3. WHAT THE PROPOSALS ONLY HINT AT

3.1 Resource Reservation

   Increasingly, applications require a certain bandwidth or transit
   delay if they are to be at all useful (for example, real-time video
   and audio transport). Such applications need procedures to indicate
   their requirements to the network and to have the required resources
   reserved.  This process is in some ways analogous to the selection of
   a source route:

      a.  The specification by the source of its requirements.

      b.  The confirmation that the requirements can be met.

      c.  Marking traffic with the requirement.

      d.  Routing marked traffic accordingly.

   Traffic which is routed according to the same set of resource
   requirements is sometimes called a "flow". The identification of
   flows requires a setup process, and it is tempting to suppose that
   the same process might also be used to set up source routes, however,
   there are a number of differences:



Dixon                                                           [Page 6]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


      - All the routers on a path must participate in resource
        reservation and agree to it.

      - Consequently, it is relatively straightforward to maintain
        context in each router and the identification for flows can be
        short.

      - The network can choose to reroute on failure.

   By various means, each proposal could carry flow-identification,
   though this is very much "for future study" at present. No setup
   mechansisms are defined. The process for actually reserving the
   resources is a higher-order problem. The interaction between source-
   routing and resource reservation needs further investigation:
   although the two are distinct and have different implementation
   constraints, the consequence of having two different mechanisms could
   be that it becomes difficult to select routes which meet both policy
   and performance goals.

3.2 Address-Assignment Policies

   In IPv4, addresses were bound to systems on a long-term basis and in
   many cases could be used interchangeably with DNS names. It is
   tacitly accepted that the association of an address with a particular
   system may be more volatile in IPng. Indeed, one of the proposals,
   PIP, makes a distinction between the identification of a system (a
   fixed quantity) and its address, and permits the binding to be
   altered on the fly. None of the proposals defines bounds for the
   lifetime of addresses, and the manner in which addresses are assigned
   is not necessarily bound to a particular proposal. For example,
   within the larger address space to be provided by IPng, there is a
   choice to be made of assigning the "higher order" part of the
   hierarchical address in a geographically-related fashion or by
   reference to service provider. Geographically-based addresses can be
   constant and easy to assign, but represent a renewed danger of
   degeneration to "flat" addresses within the region of assignment,
   unless certain topological restrictions are assumed.  Provider-based
   address assignment results in a change of address (if providers are
   changed) or multiple addresses (if multiple providers are used).
   Mobile hosts (depending on the underlying technology) can present
   problems in both geographic and provider-based schemes.

   Without firm proposals for address-assignment schemes and the
   consequences for likely address lifetimes, it is impossible to assume
   that the existing DNS model by which name-to-address bindings can be
   discovered remains valid.





Dixon                                                           [Page 7]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


   Note that there is an interaction between the mechanism for
   assignment of addresses and way in which automatic configuration may
   be deployed.

3.3 Automatic Configuration

   Amongst the biggest (user) bugbears of current IP services is the
   administrative effort of maintaining basic configuration information,
   such as assigning names and addresses to hosts, ensuring these are
   refelected in the DNS, and keeping this information correct. Part of
   this results from poor implementation (or the blind belief that vi
   and awk are network management tools). However, a lot of the problems
   could be alleviated by making this process more automatic. Some of
   the possibilities (some mutually-exlusive) are:

      - Assigning host addresses from some (relative) invariant, such
        as a LAN address.

      - Defining a protocol for dynamic assignment of addresses within a
        subnetwork.

      - Defining "generic addresses" by which hosts can without
        preconfiguration reach necessary local servers (DNS, route
        servers, etc.).

      - Have hosts determine their name by DNS lookup.

      - Have hosts update their name/address bindings when their
        configuration changes.

   Whilst a number of the proposals make mention of some of these
   possibilities, the choice of appropriate solutions depends to some
   extent on address-assignment policies. Also, dynamic configuration
   results in some difficult philosopical and practical issues (what
   exactly is the role of an address?, In what sense is a host "the same
   host" when its address changes?, How do you handle dynamic changes to
   DNS mappings and how do you authenticate them?).

   The groups involved in the proposals would, I think, see most of
   these questions outside their scope. It would seem to be a failure in
   the process of defining and selecting candidates for IPng that
   "systemness" issues like these will probably not be much discussed.
   This is recognised by the participants, and it is likely that, even
   when a decision is made, some of these ideas will be revisited by a
   wider audience.

   It is, however, unlikely that IP will make an impact on proprietary
   networking systems for the non-technical environment (e.g., Netware,



Dixon                                                           [Page 8]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


   Appletalk), without automatic configuration being taken seriously
   either in the architecture, or by suppliers. I believe that there are
   ideas on people's heads of how to address these issues - they simply
   have not made it onto paper yet.

3.4 Application Interface/Application Protocol Changes

   A number of common application protocols (FTP, RPC, etc.) have been
   identified which specifically transfer 32-bit IPv4 addresses, and
   there are doubtless others, both standard and proprietary. There are
   also many applications which treat IPv4 addresses as simple 32-bit
   integers. Even applications which use BSD sockets and try to handle
   addresses opaquely will not understand how to parse or print longer
   addresses (even if the socket structure is big enough to accommodate
   them).

   Each proposal, therefore, needs to specify mechanisms to permit
   existing applications and interfaces to operate in the new
   environment whilst conversion takes place. It would be useful also,
   to have (one) specification of a reference programming interface for
   (TCP and) IPng (which would also operate on IPv4), to allow
   developers to begin changing applications now. All the proposals
   specify transition mechansisms from which existing application-
   compatibility can be inferred. There is no sign yet of a new
   interface specification independent of chosen protocol.

3.5 DNS Changes

   It is obvious that there has to be a name to address mapping service
   which supports the new, longer, addresses. All the proposals assume
   that this service will be provided by DNS, with some suitably-defined
   new resource record. There is some discussion ongoing about the
   appropriateness of returning this information along with "A" record
   information in response to certain enquiries, and which information
   should be requested first. There is a potential tradeoff between the
   number of queries needed to establish the correct address to use and
   the potential for breaking existing implementations by returning
   information that they do not expect.

   There has been heat, but not light, generated by discussion of  the
   use of DNS for auto-configuration and the scaling (or otherwise) of
   reverse translations for certain addressing schemes.









Dixon                                                           [Page 9]

RFC 1454        Comparison of Next Version IP Proposals         May 1993


4. WHAT THE PROPOSALS DON'T REALLY MENTION

4.1 Congestion Avoidance

   IPv4 offers "Source Quench" control messages which may be used by
   routers to indicate to a source that it is congested and has or may
   shortly drop packets. TUBA/PIP have a "congestion encountered" bit
   which provides similar information to the destination. None of these
   specifications offers detailed instructions on how to use these
   facilities. However, there has been a substantial body of analysis
   over recent years that suggests that such facilities can be used (by
   providing information to the transport protocol) not only to signal
   congestion, but also to minimise delay through the network layer.
   Each proposal can offer some form of congestion  signalling, but none
   specifies a mechanism for its use (or an analysis of whether the
   mechanism is in fact useful).

   As a user of a network service which currently has a discard rate of
   around 30% and a round-trip-time of up to 2 seconds for a distance of
   only 500 miles I would be most interested in some proposals for a
   more graceful degradation of the network service under excess load.

4.2 Mobile Hosts

   A characteristic of mobile hosts is that they (relatively) rapidly
   move their physical location and point of attachment to the network
   topology.  This obviously has signficance for addressing (whether
   geographical or topological) and routing. There seems to be an
   understanding of the problem, but so far no detailed specification of
   a solution.

4.3 Accounting

   The IESG selection criteria require only that proposals do not have
   the effect of preventing the collection of information that may be of
   interest for audit or billing purposes. Consequently, none of the
   proposals  consider potential accounting mechanisms.

4.4 Security

   "Network Layer Security Issues are For Further Study". Or secret.

   However, it would be useful to have it demonstrated that each
   candidate could be extended to provide a level of security, for
   example against address-spoofing. This will be particularly
   important if resource-allocation features will permit certain hosts
   to claim large chunks of available bandwidth for specialised
   applications.



Dixon                                                          [Page 10]