Internet Engineering Task Force Barbara A. Fox INTERNET-DRAFT Lucent Technologies <draft-ietf-ion-nhrp-vpn-00.txt> Bernhard Petri Expires September, 1999 Siemens AG NHRP Support for Virtual Private Networks Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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 Fox, Petri [Page 1]
INTERNET-DRAFT NHRP VPN Expires September 1999 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. 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". 2. Overview of NHRP VPN Indication When supporting NHRP for a VPN, it is necessary to specify to which VPN the NHRP message applies in order to comply with the VPN service level agreement applicable to that VPN. On some NBMA networks, it is possible to establish a VPN-specific control path between NHRP devices. This is sufficient to identify the NHRP control packets as belonging to the "inherited" VPN. However, when that alternative is not used, the NHRP device must specify the VPN to which an NHRP control packet applies in the PDU. It is not useful to add a VPN extension to NHRP control messages because transit NHRP Servers are not required to process the extensions to an NHRP control message (see 5.3 in [1]). NHRP Servers already deployed might resolve the control packet within the scope of the public internetworking layer address space instead of the private address space causing problems in routing. Instead, an LLC/SNAP header with a VPN indication (as specified in Section 8 of [2]) will be prepended to the NHRP control message. This solution allows the same VPN-specific LLC/SNAP header to be prepended to PDUs in both the control and data paths. 3. NHRP VPN Operation When an NHRP device forwards an NHRP control packet pertaining to a particular VPN, that VPN must be indicated either: Fox, Petri [Page 2]
INTERNET-DRAFT NHRP VPN Expires September 1999 a) explicitly through use of the VPN-specific LLC/SNAP header or b) implictly through an indication in control path establishment. This applies to NHC-NHS, NHS-NHS, and NHS-NHC messages. For case a), the indication of the VPN-ID via a VPN-specific LLC/SNAP header is specified in [2]. For case b), the method used to indicate the VPN-ID within control path establishment depends on the mechanisms available in the underlying network and is outside the scope of this draft. In transiting an NHRP Server, the VPN identification may be forwarded in a different format than was received, however, the same VPN ID must be indicated for the message. For example, a PDU received with an LLC/SNAP header containing a VPN identifier MAY be forwarded on a control path which was established with an indication of the same VPN without the VPN-specific LLC/SNAP header. If a PDU with a VPN-specific LLC/SNAP header is received on a control path that was established with a VPN indication, the PDU may be dropped as specified in Section 8.3 of [2]. If it is not dropped, the VPN identifiers MUST match. If the processed PDU indicates a different VPN, an NHRP Error Indication (see 5.2.7 of [1]) shall be returned to the sender with an Error Code 16 (VPN mismatch). When a VPN capable device receives an NHRP message without a VPN indication, the message applies to the public address space. If a VPN capable device receives an NHRP message for a VPN that it does not support, that message MAY be silently discarded or an NHRP Error Indication (see 5.2.7 of [1]) MAY be returned to the sender with an Error Code 17 (VPN not supported). 4. NHRP Packet Formats VPN-specific NHRP control messages forwarded on a non VPN-specific control path MUST be prepended with the VPN-specific LLC-SNAP header as defined in Section 8 of [2]. The following further Error Codes are defined in addition to those specified in section 5.2.7 of [1]): 16 - VPN mismatch This error code is returned by a VPN-capable NHRP device, if it receives a PDU on the control path with a VPN-ID in the LLC/SNAP header different from the VPN-ID which had been specified for that control path at its establishment. Fox, Petri [Page 3]
INTERNET-DRAFT NHRP VPN Expires September 1999 17 - VPN not supported This error code is returned by a VPN-capable NHRP device, if it receives an NHRP message for a VPN that it does not support. References [1] Luciani, J., Katz, D., Piscitello, D., Cole, B., and N. Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC 2332, April 1998. [2] Grossman, D. and Heinanen, J. "Multiprotocol Encapsulation over ATM Adaptation Layer 5", work in progress. Author Information Barbara A. Fox Lucent Technologies 300 Baker Ave, Suite 100 Concord, MA 01742-2168 phone: +1-978-287-2843 email: barbarafox@lucent.com Bernhard Petri Siemens AG Hofmannstr. 51 Munich, Germany, D-81359 phone: +49 89 722-34578 email: bernhard.petri@icn.siemens.de Fox, Petri [Page 4]
