NHRP Support for Virtual Private Networks
RFC 2735

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 03

Network Working Group                                             B. Fox
Request for Comments: 2735                         Equipe Communications
Category: Standards Track                                       B. Petri
                                                              Siemens AG
                                                           December 1999

               NHRP Support for Virtual Private Networks

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   The NBMA Next Hop Resolution Protocol (NHRP) is used to determine the
   NBMA subnetwork addresses of the "NBMA next hop" towards a public
   internetworking layer address (see [1]).  This document describes the
   enhancements necessary to enable NHRP to perform the same function
   for private internetworking layer addresses available within the
   framework of a Virtual Private Network (VPN) service on a shared NBMA
   network.

1. Introduction

   NHRP is a public internetworking layer based resolution protocol.
   There is an implicit understanding in [1] that a control message
   applies to the public address space.

   Service Providers of Virtual Private Network (VPN) services will
   offer VPN participants specific service level agreements (SLA) which
   may include, for example, dedicated routing functions and/or specific
   QoS levels.  A particularly important feature of a VPN service is the
   ability to use a private address space which may overlap with the
   address space of another VPN or the Public Internet.  Therefore, such
   an internetworking layer address only has meaning within the VPN in
   which it exists.  For this reason, it is necessary to identify the
   VPN in which a particular internetworking layer address has meaning,
   the "scope" of the internetworking layer address.

Fox & Petri                 Standards Track                     [Page 1]
RFC 2735       NHRP Support for Virtual Private Networks   December 1999

   As VPNs are deployed on shared networks, NHRP may be used to resolve
   a private VPN address to a shared NBMA network address.  In order to
   properly resolve a private VPN address, it is necessary for the NHRP
   device to be able to identify the VPN in which the address has
   meaning and determine resolution information based on that "scope".

   As VPN services are added to an NBMA network using NHRP devices, it
   may be necessary to support the service with legacy NHRP devices that
   do not have VPN knowledge and so do not explicitly support VPNs.
   This document describes requirements for "VPN-aware" NHRP entities to
   support VPN services while communicating with both "VPN-aware" and
   "non-VPN-aware" NHRP entities.

2. Overview of NHRP VPN Support

2.1 Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [4].

   In addition to the terminology specified in section 2.1 of [1], the
   following definitions and acronyms are used:

   Default Routing Instance -- In the presence of VPNs, all packets are
   processed (e.g., routed) within the context of a specific VPN. In the
   case where no VPN is indicated, a packet is processed according to a
   default VPN, i.e., a Default Routing Instance.  This routing instance
   may be the Public Internet, a particular VPN, etc.  The term only has
   meaning for "VPN-aware" NHRP entities.

   Virtual Private Network (VPN) -- in the context of this
   specification, this term is used as described in [3].

   VPN-aware -- a "VPN-aware" NHRP entity is an NHRP entity that
   implements the NHRP enhancements for VPNs as defined in this
   document.

   Non-VPN-aware -- a "non-VPN-aware" NHRP entity is an NHRP entity
   which is deployed as part of a single VPN, but is not VPN-aware.
   Restrictions applying to non-VPN-aware NHRP entities are outlined
   below.  NHRP devices as specified in [1] are examples of non-VPN-
   aware entities.

   VPN encapsulation -- An LLC/SNAP encapsulation of a PDU with an
   indication of the VPN to which the PDU belongs. In the case that the
   underlying NBMA network is an ATM network, VPN encapsulation is
   specified in section 8 of [2].

Fox & Petri                 Standards Track                     [Page 2]
RFC 2735       NHRP Support for Virtual Private Networks   December 1999

   VPN identifier (VPN-ID) -- in the context of this specification, this
   term is used as specified in [3].

   VPN signalling -- in the context of this specification, this term is