[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                                          S. Pegrum
Internet Draft                                               D. Jamieson
Expiration Date: February 1999                                   M. Yuen
                                                                A. Celer
                                          Nortel (Northern Telecom) Ltd.
                                                             August 1998

          VPN Point to Multipoint Tunnel Protocol (VPMT)

Status of this Memo
   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as ``work in progress''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast)

   This draft obsoletes draft-pegrum-vmmt-00.txt


   For many carrier's, the implementation of Virtual Private Network
   (VPN) services using current IP Tunneling technology is problematic
   because of onerous configuration requirements. The VPMT is an
   protocol for the dynammic distribution of VPN information throughout
   a shared network, which in turn allows the automatic formation of
   point to multi-point tunnels between VPN routers.

   The method described in this internet draft  is intended for single
   AS where the AS administrator is a trusted third party.  Traffic
   seperation is maintained between VPNs.

Table of Contents

   1       Introduction ............................................   2
   1.1     Terminology .............................................   2
   2       Address Assignment ......................................   2
   3       Routing Updates .........................................   3
   4       VPN Peer Discovery.......................................
   4.1     VPN Peer Discovery Algorithm.............................

Pegrum, et. al.              Internet Draft                     [Page 1]

RFC NNNN                     VPMT Protocol                   August 1998

   4.2     Multicast Enabled Shared Networks........................
   4.3     Non-Multicast Enabled Shared Networks....................
   5       Peer Connectivity........................................
   6       Peer Discovery Using ICMP Messages.......................
   6.1     Message Formats .........................................   4
   6.2     IPv6 Compliance..........................................   6
   7       Summary .................................................
   8       Security Considerations .................................
   9       References ..............................................
   10      Author's Address ........................................

1. Introduction

   For the purposes of this document, a VPN shall be considered to
   consist of a grouping of private routers that use a shared tunneled
   backbone. It is assumed that multiple VPNs use the shared backbone.

   Private routers that are members of the same VPN form a peer group.
   The members of the peer group communicate with each other over a
   logical shared broadcast medium which is actually the tunnelled
   backbone simulating a shared broadcast medium for each VPN peer

   In common tunnel implementations, tunnels are point to point
   connections where the endpoints are statically configured by the
   network operator.  The VPMT protocol dynamically distributes
   connection information (tunnel endpoints) between VPN peers
   throughout a shared network, to allow dynamic establishment of a
   point to multi-point tunnels.  The VPN connection information could
   include multi-cast information allowing the establishment of
   multi-point to multi-point tunnels.

   Each VPN is identified by a 32 bit VPN identifier (VPNID) that is
   unique in the shared network, but common to all the routers which
   belong to the same VPN.  Suggested format of the VPNID is 16 bits of
   AS number and 16 bits VPN number.  It is assumed that VPN does not
   cross boundaries of the AS.

   Each VPN peer (router) belonging to a VPN is identified by a 32 bit
   peer VPN identifier (PEERID) that is unique in the private network,
   but does not have to be unique in the shared network.  This
   information is not propagated in the network.

   The VPN peer connectivity is achieved in two steps:
     * discovering the peers in the shared network
     * establishment of communication channels between peers

Pegrum, et. al.              Internet Draft                     [Page 2]

RFC NNNN                     VPMT Protocol                   August 1998

   This protocol deals with the dynamic VPN peer discovery in shared
   network. Suggestions on how to establish the communication channels
   between peers are given in Section 5.

1.1 Terminology

  There is no new terminology introduced by this draft.

2. Address Assignment

   Each VPN peer would have assigned a number of addresses as following:

     * IP address in shared network -
                   In case of non-multicast enabled shared network
                this address is to be used as a source or destination
                address in all VPN peer discovery messages.
                   In case of the multicast enabled network
                it is the group multicast address to which the VPN
                peer belongs.
                   This address can also be used to establish VPN
                peer to peer communication channels, if it is
                not-multicast address.

     * IP address in shared network - (optional)
                   This address is being used to establish communication
                channels between VPN peers, if the VPMT messaging is
                isolated from the VPN data traffic.

     * multiple private IP addresses -
                   These addresses are used to establish configuration
                of the private address space (network).
                   The tunnel is not established between two end-points
                if advertised private interfaces do not belong to the
                same sub-net.
                   There has to be at least one private address assigned
                to the VPN peer.

3. Routing Updates

   No routing information is exchanged between the shared and private
   networks.  Routing updates from the shared network are blocked and
   not transmitted into the private networks. Conversely, private
   network updates, even though they are tunnelled across the shared
   network, are not transmitted into the shared network routing domain.

Pegrum, et. al.              Internet Draft                     [Page 3]

RFC NNNN                     VPMT Protocol                   August 1998

   The VPN peer processes only routing information received from the
   peer which belong to the same VPNID.

4. VPN Peer Discovery

   The VPMT protocol allows VPN peer discovery to run in multicast
   and non-multicast enabled networks.

   New VPN peers joining the VPN immediately issues a VPN Peer
   Solicitation message to trigger advertisements from other routers
   on the VPN.  In addition, each VPN router periodically issues a
   VPN Advertisement Message to ensure that VPN integrity is maintained
   Advertisements are not meant to provide blackhole detection.
   The Layer 2 tunnel protocol and the VPN routing protocol provide
   blackhole detection.

   After discovering VPN peers connectivity between them is established.
   The VPN peer configuration information is used by the implemented
   Layer 2 Tunneling protocol to establish connectivity between VPN
   peers.  The Layer 2 tunneling protocol carries full responsiblity of
   management of setting-up and tearing down peer connectivity.

   ARP entries on VPN peers are refreshed when processing the VPN
   Advertisement messages received from VPN peers.

   4.1 VPN Peer Discovery Algorithm

   The algorithm for discovering peers in the shared network for both
   multicast and non-multicast enabled networks is the same.

   Step 1.
     Provision set of addresses specified in Section 2 for the VPN peer,
     and unique VPNID for the VPN .

     Provision the following:
       1)  for multicast enabled networks - multicast address where
           solicitation and advertisement message are sent
       2)  for non-multicast enabled networks - provision set of known
           addresses where the solicitation  and advertisement message
           are sent.

     This draft does not deal with the automatic discovery of carrier
     network configuration for non-multicast enabled networks.

Pegrum, et. al.              Internet Draft                     [Page 4]

RFC NNNN                     VPMT Protocol                   August 1998

   Step 2.
     When VPN peer joins the shared network it issues the VPN
     Solicitation Message which includes the full information about the
     peer.  This message is sent to known address(es).
     The acknowledgement to that message comes in the form of a VPN
     Advertisement Message which contains remote VPN peer configuration

   Step 3.
     On receiving of the VPN Advertisement Message, the following checks
     are performed:
       1)  VPNID is checked;  in case that the VPNID of the remote peer
           does not match VPNID of the receiver, the message is not
       2)  each private (address, mask) pair is compared with own
           private (address, mask) pair; for private interfaces
           that belong to the same sub-net, the connectivity
           can be eastablished .  The method of setting up-the
           connectivity depends on the Layer 2 tunneling implementation
       3)  in case that the peer connectivity is to be established,
           the shared address of the peer is stored

           It is an implementation detail if the shared address of the
           peer should be stored in case that the private interfaces
           do not belong to the same sub-net.

   Step 4.
     If the VPN peer does not receive any responses for its VPN
     Solicitation Message, the message is periodically re-sent.
     The value of the period is provisionable and set by the network

     If peer connectivity is established, the VPN Solicitation message
     will not be resent.

   Step 5.
     VPN Advertisement message is sent in two scenarios:
       1)  as a reply to the peer VPN Solicitation Message
       2)  periodically sent to known multicast address or set of
           known destinations

     An algorithm to change the advertisement frequency can be
     implemented in order to lower the requirements on the bandwidth
     for the messages in stable carier network. The frequency of updates
     is indicated in the advertisement message generated by the VPN

Pegrum, et. al.              Internet Draft                     [Page 5]

RFC NNNN                     VPMT Protocol                   August 1998

    Step 6.
      If the VPN peer disconnects from the network, no action
      is performed.  It is up to Layer 2 tunneling protocol to tear
      down the connection.

   4.2 Multicast Enabled Shared Networks

   In multicast enabled shared networks, each VPN peer is required to
   join the multicast group that is provisioned for its associated VPN.

   After joining the multicast group, the VPN peer executes a VPN Peer
   Router Discovery protocol described in Section 4.1 on that multicast

   The messages are a combination of VPN discovery and address
   resolution.  The VPN discovery is meant to be a security measure to
   ensure that all routers that belong to this multi-cast group belong
   to the same VPN (have the same VPNID).  This is intended to guard
   against configuration errors only.  It is assumed that the shared
   network is secure.

   After discovering a VPN peer, the connectivity between them is
   established by the layer 2 tunneling protocol.

   4.3 Non-Multicast Enabled Shared Networks

   In non-multicast enabled shared networks, the VPN peer discovery
   algorithm descibed in Section 4.1 is used.
   The destination address to send the VPN Solicitation and
   Advertisement Message can be one of the following:
     * broadcast address instead of a multicast group address
     * set of known unicast addresses

   If the broadcast address is being used, the limit on the number of
   broadcast addresses in the network may impose additional VPN peer
   discovery message processing in order to separate peer configuration
   data.  In this case it is advisable to use separate IP address to
   establish communication channels between VPN peers.

   If the set of unicast addresses is being used, the originating
   VPN peer would push VPN Solicitation and Advertisement messages to
   all known destinations.  The further refinement of the protocol is an
   implementation concern.

   To propagate peer discovery information in the network the following
   methods can be used:
     1. ICMP messages

Pegrum, et. al.              Internet Draft                     [Page 6]

RFC NNNN                     VPMT Protocol                   August 1998

     2. OPAQUE LSAs
     3. TCP connection established between known destinations
     4. use of multicast addresses in the network

   In Section 6, an example using the ICMP message implementation is

5. Peer Conectivity

   Peer connectivity phase is responsible for the following:
     1)  in case that connectivity between peers can be established
         (same VPNID and interface(s) belong to the same sub-net(s), it
         handles all actions necessary to create tunnel via carrier
         backbone (network)
     2)  in case that connectivity between peers cannot exist anymore,
         it carries all actions necessary to remove the tunnel via
         carrier backbone (network)
     3)  based on the layer 2 media used to esatblish peer connectivity,
         there can be periodical verification of the tunnel state.  This
         functionality is separate from VPN Peer Discovery phase.

   The communication of data between VPN peers througout carrier network
   can be carried using separate layer 2 media.  The following methods
   of encapsulating VPN data can be used:
     1. IP in IP tunnel
     2. MPLS
     4. IPSec
     5. Frame Relay SVCs

   This draft does not discuss the options of the peer connectivity
   establishement and maintenance.

6. Peer Discovery Using ICMP Messages

   In this section, the example is given on the use of the ICMP Peer
   Discovery message to identify VPN peers in order to set-up the
   connections between them.  A new message type is being proposed,
   which includes all necessary data to identify the peer and set-up the

   6.1 Message Formats

   The message formats follow standard ICMP type messages.  The IP
   Header is not shown in the diagrams below.

   The VPMT protocol proposes to define new ICMP message type VPN Peer

Pegrum, et. al.              Internet Draft                     [Page 7]

RFC NNNN                     VPMT Protocol                   August 1998

   Discovery for messages to dynamically discover VPN peers.
   For the VPN ICPM Peer Discovery message the following codes are
     * 1 - VPN solicitation message; this message will invoke the
               VPN Adverisement message to be sent by the receiving
     * 2 - VPN advertisement message; this message is not acknowledged
               in any way by the receiving router

   The VPN ICMP Peer Discovery message format includes VPN configuration

   The diagram below illustrates the message format for IPv4 only

   VPN ICMP Peer Discovery Message

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    |     Type      |     Code      |           Checksum            |
    |S|P|    Num Interfaces         | Addr Entry Size               |
    |                           VPN Identifier                      |
    |           Refresh Time        |        Reserved               |
    |                           Shared  Address                     |
    |                           Private  Address                    |
    |                         Private  Address Mask                 |
    +                                                               +

   IP Header Addresses:
     Destination Address:  Shared Network IP Address of the VPN peer;
                           in case of the multicast enabled network
                           it is the group multicast address to which
                           the VPN peer belongs
     Source Address:       Shared Network IP Address of the VPN peer

   ICMP Fields:
     Type:                 VPN ICMP Peer Discovery
     Code:                 value {1, 2}; where:
                             1 - VPN Solicitation Message

Pegrum, et. al.              Internet Draft                     [Page 8]

RFC NNNN                     VPMT Protocol                   August 1998

                             2 - VPN Advertisement Message
     Checksum:             16 bit one's complement of entire message
     S (shared)            1 bit format of the shared address:
                             0 - complies with IPv4
                             1 - complies with IPv6
     P (private)           1 bit format of the private (address,mask)
                             0 - complies with IPv4
                             1 - complies with IPv6
     Num Interfaces:       14 bit containing number of VPN private
                           interfaces included in this message;
                           interface is desfined by (address, mask)

     Addr Entry:           Size of (address,mask) pair in 32 bit words
     VPN Identifier:       32 bits containing VPNID shared between
                           VPN peers
     Refresh Time:         2 bytes of refresh time interval in seconds
     Reserved:             2 bytes
     Shared address:       VPN peer address in the shared network
                           this address may differ from the source
                           address in IP header.  This address specifies
                           communication channel end-point on the source
                           VPN peer.
     Private Address:      IP address of the interface to the private
     Private Address Mask: mask associated with the IP address of the
                           interface to the private network

   6.2 IPv6 Compliance

   The VPMT protocol can be used in IPv6 .  The message format remains
   the same with respect to fields, however the size of the following
   fields will, optionally, expand from 32 bits to 128 bits:
     * Shared address
     * Private address
     * Prefix length for the private address mask

   The following fields in the ICMP Peer Discovery message will be used
   to specify the format of the address and appropriate mask:
     * shared :
         0 - IPv4 format
         1 - IPv6 format
     * private :
         0 - IPv4 format
         1 - IPv6 format

   The behaviour of the protocol remains unchanged.

Pegrum, et. al.              Internet Draft                     [Page 9]

RFC NNNN                     VPMT Protocol                   August 1998

7. Summary

   VPMT addresses several problems:
     - Dynamic VPN endpoint configuration
     - Support of Multi-point to Multi-point tunnels
     - Security against network operator misconfiguration
     - Ensures private network isolation

     The VPMT protocol allows for scalable VPN solutions using a common
     shared infrastructure.

8. Security Considerations

   This protocol requires the shared network to be secure and trusted.

   The method is intended for a single AS where the AS administrator
   is a trusted third party.

9. References
     [1] S. Deering, Editor, "ICMP Router Discovery Messages", RFC 1256,
     Xerox PARC, September 1991 [2] S. Hanks et al., "Generic Router
     Encapsulation", RFC 1701, NetSmiths Ltd & Cisco Systems, October

9. Author's Address

     Scott Pegrum
     Nortel (Northern Telecom), Ltd.
     PO Box 3511 Station C
     Ottawa ON K1Y 4H7

     EMail: spegrum@Nortel.ca

     Dwieght Jamieson
     Nortel (Northern Telecom), Ltd.
     PO Box 3511 Station C
     Ottawa ON K1Y 4H7

     EMail: djamies@Nortel.ca

Pegrum, et. al.              Internet Draft                    [Page 10]

RFC NNNN                     VPMT Protocol                   August 1998

     Matthew Yuen
     Nortel (Northern Telecom), Ltd.
     PO Box 3511 Station C
     Ottawa ON K1Y 4H7

     EMail: myuen@Nortel.ca

     Alicja B. Celer
     Nortel (Northern Telecom), Ltd.
     PO Box 3511 Station C
     Ottawa ON K1Y 4H7

     EMail: aceler@nortel.ca

Pegrum, et. al.              Internet Draft                    [Page 11]