NHRP Support for Virtual Private Networks
RFC 2735
|
Document |
Type |
|
RFC - Proposed Standard
(December 1999; No errata)
|
|
Authors |
|
Bernhard Petri
,
Barbara Fox
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 2735 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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
Show full document text