rfc2764.txt

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

   It is possible to extend the IPSec protocol suite to allow for the
   transport of multiprotocol packets.  This can be achieved, for
   example, by extending the signalling component of IPSec - IKE, to
   indicate the protocol type of the traffic being tunneled, or to carry
   a packet multiplexing header (e.g., an LLC/SNAP header or GRE header)
   with each tunneled packet.  This approach is similar to that used for
   the same purpose in ATM networks, where signalling is used to
   indicate the encapsulation used on the VCC, and where packets sent on
   the VCC can use either an LLC/SNAP header or be placed directly into
   the AAL5 payload, the latter being known as VC-multiplexing (see
   [25]).

3.1.5  Frame Sequencing

   One quality of service attribute required by customers of a VPN may
   be frame sequencing, matching the equivalent characteristic of
   physical leased lines or dedicated connections.  Sequencing may be



Gleeson, et al.              Informational                     [Page 14]

RFC 2764           IP Based Virtual Private Networks       February 2000


   required for the efficient operation of particular end to end
   protocols or applications.  In order to implement frame sequencing,
   the tunneling mechanism must support a sequencing field.  Both L2TP
   and GRE have such a field.  IPSec has a sequence number field, but it
   is used by a receiver to perform an anti-replay check, not to
   guarantee in-order delivery of packets.

   It is possible to extend IPSec to allow the use of the existing
   sequence field to guarantee in-order delivery of packets.  This can
   be achieved, for example, by using IKE to negotiate whether or not
   sequencing is to be used, and to define an end point behaviour which
   preserves packet sequencing.

3.1.6  Tunnel Maintenance

   The VPN end points must monitor the operation of the VPN tunnels to
   ensure that connectivity has not been lost, and to take appropriate
   action (such as route recalculation) if there has been a failure.

   There are two approaches possible.  One is for the tunneling protocol
   itself to periodically check in-band for loss of connectivity, and to
   provide an explicit indication of failure.  For example L2TP has an
   optional keep-alive mechanism to detect non-operational tunnels.

   The other approach does not require the tunneling protocol itself to
   perform this function, but relies on the operation of some out-of-
   band mechanism to determine loss of connectivity.  For example if a
   routing protocol such as Routing Information Protocol (RIP) [26] or
   Open Shortest Path First (OSPF) [27] is run over a tunnel mesh, a
   failure to hear from a neighbor within a certain period of time will
   result in the routing protocol declaring the tunnel to be down.
   Another out-of-band approach is to perform regular ICMP pings with a
   peer.  This is generally sufficient assurance that the tunnel is
   operational, due to the fact the tunnel also runs across the same IP
   backbone.

   When tunnels are established dynamically a distinction needs to be
   drawn between the static and dynamic tunnel information needed.
   Before a tunnel can be established some static information is needed
   by a node, such as the identify of the remote end point and the
   attributes of the tunnel to propose and accept.  This is typically
   put in place as a result of a configuration operation.  As a result
   of the signalling exchange to establish a tunnel, some dynamic state
   is established in each end point, such as the value of the
   multiplexing field or keys to be used.  For example with IPSec, the
   establishment of a Security Association (SA) puts in place the keys
   to be used for the lifetime of that SA.




Gleeson, et al.              Informational                     [Page 15]

RFC 2764           IP Based Virtual Private Networks       February 2000


   Different policies may be used as to when to trigger the
   establishment of a dynamic tunnel.  One approach is to use a data-
   driven approach and to trigger tunnel establishment whenever there is
   data to be transferred, and to timeout the tunnel due to inactivity.
   This approach is particularly useful if resources for the tunnel are
   being allocated in the network for QoS purposes.  Another approach is
   to trigger tunnel establishment whenever the static tunnel
   configuration information is installed, and to attempt to keep the
   tunnel up all the time.

3.1.7  Large MTUs

   An IP tunnel has an associated Maximum Transmission Unit (MTU), just
   like a regular link. It is conceivable that this MTU may be larger
   than the MTU of one or more individual hops along the path between
   tunnel endpoints. If so, some form of frame fragmentation will be
   required within the tunnel.

   If the frame to be transferred is mapped into one IP datagram, normal
   IP fragmentation will occur when the IP datagram reaches a hop with
   an MTU smaller than the IP tunnel's MTU. This can have undesirable
   performance implications at the router performing such mid-tunnel
   fragmentation.

   An alternative approach is for the tunneling protocol itself to
   incorporate a segmentation and reassembly capability that operates at
   the tunnel level, perhaps using the tunnel sequence number and an
   end-of-message marker of some sort.  (Note that multilink PPP uses a
   mechanism similar to this to fragment packets).  This avoids IP level
   fragmentation within the tunnel itself. None of the existing
   tunneling protocols support such a mechanism.

3.1.8  Minimization of Tunnel Overhead

   There is clearly benefit in minimizing the overhead of any tunneling
   mechanisms.  This is particularly important for the transport of
   jitter and latency sensitive traffic such as packetized voice and
   video.  On the other hand, the use of security mechanisms, such as
   IPSec, do impose their own overhead, hence the objective should be to
   minimize overhead over and above that needed for security, and to not
   burden those tunnels in which security is not mandatory with
   unnecessary overhead.

   One area where the amount of overhead may be significant is when
   voluntary tunneling is used for dial-up remote clients connecting to
   a VPN, due to the typically low bandwidth of dial-up links.  This is
   discussed further in section 6.3.




Gleeson, et al.              Informational                     [Page 16]

RFC 2764           IP Based Virtual Private Networks       February 2000


3.1.9  Flow and congestion control

   During the development of the L2TP protocol procedures were developed
   for flow and congestion control.  These were necessitated primarily
   because of the need to provide adequate performance over lossy
   networks when PPP compression is used, which, unlike IP Payload
   Compression Protocol (IPComp) [28], is stateful across packets.
   Another motivation was to accommodate devices with very little
   buffering, used for example to terminate low speed dial-up lines.
   However the flow and congestion control mechanisms defined in the
   final version of the L2TP specification are used only for the control
   channels, and not for data traffic.

   In general the interactions between multiple layers of flow and
   congestion control schemes can be very complex.  Given the
   predominance of TCP traffic in today's networks and the fact that TCP
   has its own end-to-end flow and congestion control mechanisms, it is
   not clear that there is much benefit to implementing similar
   mechanisms within tunneling protocols.  Good flow and congestion
   control schemes, that can adapt to a wide variety of network
   conditions and deployment scenarios are complex to develop and test,
   both in themselves and in understanding the interaction with other
   schemes that may be running in parallel.  There may be some benefit,
   however, in having the capability whereby a sender can shape traffic
   to the capacity of a receiver in some manner, and in providing the
   protocol mechanisms to allow a receiver to signal its capabilities to
   a sender.  This is an area that may benefit from further study.

   Note also the work of the Performance Implications of Link
   Characteristics (PILC) working group of the IETF, which is examining
   how the properties of different network links can have an impact on
   the performance of Internet protocols operating over those links.

3.1.10  QoS / Traffic Management

   As noted above, customers may require that VPNs yield similar
   behaviour to physical leased lines or dedicated connections with
   respect to such QoS parameters as loss rates, jitter, latency and
   bandwidth guarantees.  How such guarantees could be delivered will,
   in general, be a function of the traffic management characteristics
   of the VPN nodes themselves, and the access and backbone networks
   across which they are connected.

   A full discussion of QoS and VPNs is outside the scope of this
   document, however by modeling a VPN tunnel as just another type of
   link layer, many of the existing mechanisms developed for ensuring
   QoS over physical links can also be applied.  For example at a VPN
   node, the mechanisms of policing, marking, queuing, shaping and



Gleeson, et al.              Informational                     [Page 17]

RFC 2764           IP Based Virtual Private Networks       February 2000


   scheduling can all be applied to VPN traffic with VPN-specific
   parameters, queues and interfaces, just as for non-VPN traffic.  The
   techniques developed for Diffserv, Intserv and for traffic
   engineering in MPLS are also applicable.  See also [29] for a
   discussion of QoS and VPNs.

   It should be noted, however, that this model of tunnel operation is
   not necessarily consistent with the way in which specific tunneling
   protocols are currently modeled.  While a model is an aid to
   comprehension, and not part of a protocol specification, having
   differing models can complicate discussions, particularly if a model
   is misinterpreted as being part of a protocol specification or as
   constraining choice of implementation method.  For example, IPSec
   tunnel processing can be modeled both as an interface and as an
   attribute of a particular packet flow.

3.2  Recommendations

   IPSec is needed whenever there is a requirement for strong encryption
   or strong authentication.  It also supports multiplexing and a
   signalling protocol - IKE.  However extending the IPSec protocol
   suite to also cover the following areas would be beneficial, in order
   to better support the tunneling requirements of a VPN environment.

   -  the transport of a VPN-ID when establishing an SA (3.1.2)

   -  a null encryption and null authentication option (3.1.3)

   -  multiprotocol operation (3.1.4)

   -  frame sequencing (3.1.5)

   L2TP provides no data security by itself, and any PPP security
   mechanisms used do not apply to the L2TP protocol itself, so that in
   order for strong security to be provided L2TP must run over IPSec.
   Defining specific modes of operation for IPSec when it is used to
   support L2TP traffic will aid interoperability.  This is currently a
   work item for the proposed L2TP working group.

4.0  VPN Types:  Virtual Leased Lines

   The simplest form of a VPN is a 'Virtual Leased Line' (VLL) service.
   In this case a point-to-point link is provided to a customer,
   connecting two CPE devices, as illustrated below.  The link layer
   type used to connect the CPE devices to the ISP nodes can be any link
   layer type, for example an ATM VCC or a Frame Relay circuit.  The CPE
   devices can be either routers bridges or hosts.




Gleeson, et al.              Informational                     [Page 18]

RFC 2764           IP Based Virtual Private Networks       February 2000


   The two ISP nodes are both connected to an IP network, and an IP
   tunnel is set up between them.  Each ISP node is configured to bind
   the stub link and the IP tunnel together at layer 2 (e.g., an ATM VCC
   and the IP tunnel).  Frames are relayed between the two links.  For
   example the ATM Adaptation Layer 5 (AAL5) payload is taken and
   encapsulated in an IPSec tunnel, and vice versa.  The contents of the