rfc2956.txt

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

Network Working Group                                            M. Kaat
Request for Comments: 2956                   SURFnet ExpertiseCentrum bv
Category: Informational                                     October 2000


              Overview of 1999 IAB Network Layer Workshop

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

Abstract

   This document is an overview of a workshop held by the Internet
   Architecture Board (IAB) on the Internet Network Layer architecture
   hosted by SURFnet in Utrecht, the Netherlands on 7-9 July 1999.  The
   goal of the workshop was to understand the state of the network layer
   and its impact on continued growth and usage of the Internet.
   Different technical scenarios for the (foreseeable) future and the
   impact of external influences were studied.  This report lists the
   conclusions and recommendations to the Internet Engineering Task
   Force (IETF) community.

Table of Contents

   1. Introduction . . . . . . . . . . . . . . . . . . . . . . .  2
   2. Conclusions and Observations . . . . . . . . . . . . . . .  3
    2.1  Transparency. . . . . . . . . . . . . . . . . . . . . .  3
    2.2  NAT, Application Level Gateways & Firewalls . . . . . .  4
    2.3  Identification and Addressing . . . . . . . . . . . . .  4
    2.4  Observations on Address Space . . . . . . . . . . . . .  5
    2.5  Routing Issues. . . . . . . . . . . . . . . . . . . . .  5
    2.6  Observations on Mobility. . . . . . . . . . . . . . . .  6
    2.7  DNS Issues. . . . . . . . . . . . . . . . . . . . . . .  7
    2.8  NAT and RSIP. . . . . . . . . . . . . . . . . . . . . .  7
    2.9  NAT, RSIP and IPv6. . . . . . . . . . . . . . . . . . .  8
    2.10 Observations on IPv6. . . . . . . . . . . . . . . . . .  9
   3. Recommendations. . . . . . . . . . . . . . . . . . . . . . 10
    3.1 Recommendations on Namespace . . . . . . . . . . . . . . 10
    3.2 Recommendations on RSIP. . . . . . . . . . . . . . . . . 10
    3.3 Recommendations on IPv6. . . . . . . . . . . . . . . . . 10
    3.4 Recommendations on IPsec . . . . . . . . . . . . . . . . 11



Kaat                         Informational                      [Page 1]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


    3.5 Recommendations on DNS . . . . . . . . . . . . . . . . . 11
    3.6 Recommendations on Routing . . . . . . . . . . . . . . . 12
    3.7 Recommendations on Application Layer and APIs. . . . . . 12
   4. Security Considerations. . . . . . . . . . . . . . . . . . 12
   References. . . . . . . . . . . . . . . . . . . . . . . . . . 13
   Appendix A. Participants. . . . . . . . . . . . . . . . . . . 15
   Author's Address. . . . . . . . . . . . . . . . . . . . . . . 15
   Full Copyright Statement  . . . . . . . . . . . . . . . . . . 16

1. Introduction

   From July 7 to July 9, 1999 the Internet Architecture Board (IAB)
   held a workshop on the architecture of the Internet Network Layer.
   The Network Layer is usually referred to as the IP layer.  The goal
   of the workshop was to discuss the current state of the Network Layer
   and the impact various currently deployed or future mechanisms and
   technologies might have on the continued growth and usage of the
   Internet.

   The most important issues to be discussed were:

   o  Status of IPv6 deployment and transition issues
   o  Alternative technical strategies in case IPv6 is not adopted
   o  Globally unique addresses and 32 bit address depletion
   o  Global connectivity and reachability
   o  Fragmentation of the Internet
   o  End to end transparency and the progressive loss thereof
   o  End to end security
   o  Complications of address sharing mechanisms (NAT, RSIP)
   o  Separation of identification and location in addressing
   o  Architecture and scaling of the current routing system

   The participants looked into several technical scenarios and
   discussed the feasibility and probability of the deployment of each
   scenario.  Among the scenarios were for example full migration to
   IPv6, IPv6 deployment only in certain segments of the network, no
   significant deployment of IPv6 and increased segmentation of the IPv4
   address space due to the use of NAT devices.

   Based on the discussion of these scenarios several trends and
   external influences were identified which could have a large impact
   on the status of the network layer, such as the deployment of
   wireless network technologies, mobile networked devices and special
   purpose IP devices.







Kaat                         Informational                      [Page 2]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


   The following technical issues were identified to be important goals:

   o  Deployment of end to end security
   o  Deployment of end to end transport
   o  Global connectivity and reachability should be maintained
   o  It should be easy to deploy new applications
   o  It should be easy to connect new hosts and networks to the
      Internet ("plug and ping")

   By the notion "deployment of end to end transport" it is meant that
   it is a goal to be able to deploy new applications that span from any
   host to any other host without intermediaries, and this requires
   transport protocols with similar span (see also [1]).

   This document summarizes the conclusions and recommendations made by
   the workshop.  It should be noted that not all participants agreed
   with all of the statements, and it was not clear whether anyone
   agreed with all of them.  The recommendations made however are based
   on strong consensus among the participants.

2. Conclusions and Observations

   The participants came to a number of conclusions and observations on
   several of the issues mentioned in section 1.  In the following
   sections 2.1-2.10 these conclusions will be described.

2.1 Transparency

   In the discussions transparency was referred to as the original
   Internet concept of a single universal logical addressing scheme and
   the mechanisms by which packets may flow from source to destination
   essentially unaltered [1].  This traditional end to end transparency
   has been lost in the current Internet, specifically the assumption
   that IPv4 addresses are globally unique or invariant is no longer
   true.

   There are multiple causes for the loss of transparency, for example
   the deployment of network address translation devices, the use of
   private addresses, firewalls and application level gateways, proxies
   and caches.  These mechanisms increase fragmentation of the network
   layer, which causes problems for many applications on the Internet.
   It adds up to complexity in applications design and inhibits the
   deployment of new applications.  In particular, it has a severe
   effect on the deployment of end to end IP security.







Kaat                         Informational                      [Page 3]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


   Another consequence of fragmentation is the deployment of "split DNS"
   or "two faced DNS", which means that the correspondence between a
   given FQDN and an IPv4 address is no longer universal and stable over
   long periods (see section 2.7).

   End to end transparency will probably not be restored due to the fact
   that some of the mechanisms have an intrinsic value (e.g. firewalls,
   caches and proxies) and the loss of transparency may be considered by
   some as a security feature.  It was however concluded that end to end
   transparency is desirable and an important issue to pursue.
   Transparency is further explored in [1].

2.2 NAT, Application Level Gateways & Firewalls

   The previous section indicated that the deployment of NAT (Network
   Address Translation), Application Level Gateways and firewalls causes
   loss of network transparency.  Each of them is incompatible with
   certain applications because they interfere with the assumption of
   end to end transparency.  NAT especially complicates setting up
   servers, peer to peer communications and "always-on" hosts as the
   endpoint identifiers, i.e. IP addresses, used to set up connections
   are globally ambiguous and not stable (see [2]).

   NAT, application level gateways and firewalls however are being
   increasingly widely deployed as there are also advantages to each,
   either real or perceived.  Increased deployment causes a further
   decline of network transparency and this inhibits the deployment of
   new applications.  Many new applications will require specialized
   Application Level Gateways (ALGs) to be added to NAT devices, before
   those applications will work correctly when running through a NAT
   device.  However, some applications cannot operate effectively with
   NAT even with an ALG.

2.3 Identification and Addressing

   In the original IPv4 network architecture hosts are globally,
   permanently and uniquely identified by an IPv4 address.  Such an IP
   address is used for identification of the node as well as for
   locating the node on the network.  IPv4 in fact mingles the semantics
   of node identity with the mechanism used to deliver packets to the
   node.  The deployment of mechanisms that separate the network into
   multiple address spaces breaks the assumption that a host can be
   uniquely identified by a single IP address.  Besides that, hosts may
   wish to move to a different location in the network but keep their
   identity the same.  The lack of differentiation between the identity
   and the location of a host leads to a number of problems in the
   current architecture.




Kaat                         Informational                      [Page 4]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


   Several technologies at this moment use tunneling techniques to
   overcome the problem or cannot be deployed in the case of separate
   address spaces.  If a node could have some sort of a unique
   identifier or endpoint name this would help in solving a number of
   problems.

   It was concluded that it may be desirable on theoretical grounds to
   separate the node identity from the node locator.  This is especially
   true for IPsec, since IP addresses are used (in transport mode) as
   identifiers which are cryptographically protected and hence MUST
   remain unchanged during transport.  However, such a separation of
   identity and location will not be available as a near-term solution,
   and will probably require changes to transport level protocols.
   However, the current specification of IPsec does allow to use some
   other identifier than an IP address.

2.4 Observations on Address Space

   There is a significant risk that a single 32 bit global address space
   is insufficient for foreseeable needs or desires.  The participants'
   opinions about the time scale over which new IPv4 addresses will
   still be available for assignment ranged from 2 to 20 years.
   However, there is no doubt that at the present time, users cannot
   obtain as much IPv4 address space as they desire.  This is partly a
   result of the current stewardship policies of the Regional Internet
   Registries (RIRs).

   It was concluded that it ought to be possible for anybody to have
   global addresses when required or desired.  The absence of this
   inhibits the deployment of some types of applications.  It should
   however be noted that there will always be administrative boundaries,
   firewalls and intranets, because of the need for security and the
   implementation of policies.  NAT is seen as a significant
   complication on these boundaries.  It is often perceived as a
   security feature because people are confusing NATs with firewalls.

2.5 Routing Issues

   A number of concerns were raised regarding the scaling of the current
   routing system.  With current technology, the number of prefixes that
   can be used is limited by the time taken for the routing algorithm to
   converge, rather than by memory size, lookup time, or some other
   factor.  The limit is unknown, but there is some speculation, of
   extremely unclear validity, that it is on the order of a few hundred
   thousand prefixes.  Besides the computational load of calculating
   routing tables, the time it takes to distribute routing updates
   across the network, the robustness and security of the current
   routing system are also important issues.  The only known addressing



Kaat                         Informational                      [Page 5]

RFC 2956            1999 IAB Network Layer Workshop         October 2000


   scheme which produces scalable routing mechanisms depends on
   topologically aggregated addresses, which requires that sites
   renumber when their position in the global topology changes.
   Renumbering remains operationally difficult and expensive ([3], [4]).
   It is not clear whether the deployment of IPv6 would solve the
   current routing problems, but it should do so if it makes renumbering
   easier.

   At least one backbone operator has concerns about the convergence
   time of internetwork-wide routing during a failover.  This operator
   believes that current convergence times are on the order of half a
   minute, and possibly getting worse.  Others in the routing community
   did not believe that the convergence times are a current issue. Some,
   who believe that real-time applications (e.g. telephony) require