As per Relevance of the word indicate, we have this rfc below:
Network Working Group B.
Request for Comments: 2735 Equipe
Category: Standards Track B.
Siemens
December 1999
NHRP Support for Virtual Private
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
The NBMA Next Hop Resolution Protocol (NHRP) is used to determine
NBMA subnetwork addresses of the "NBMA next hop" towards a
internetworking layer address (see [1]). This document describes
enhancements necessary to enable NHRP to perform the same
for private internetworking layer addresses available within
framework of a Virtual Private Network (VPN) service on a shared
network
1.
NHRP is a public internetworking layer based resolution protocol
There is an implicit understanding in [1] that a control
applies to the public address space
Service Providers of Virtual Private Network (VPN) services
offer VPN participants specific service level agreements (SLA)
may include, for example, dedicated routing functions and/or
QoS levels. A particularly important feature of a VPN service is
ability to use a private address space which may overlap with
address space of another VPN or the Public Internet. Therefore,
an internetworking layer address only has meaning within the VPN
which it exists. For this reason, it is necessary to identify
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
a private VPN address to a shared NBMA network address. In order
properly resolve a private VPN address, it is necessary for the
device to be able to identify the VPN in which the address
meaning and determine resolution information based on that "scope".
As VPN services are added to an NBMA network using NHRP devices,
may be necessary to support the service with legacy NHRP devices
do not have VPN knowledge and so do not explicitly support VPNs
This document describes requirements for "VPN-aware" NHRP entities
support VPN services while communicating with both "VPN-aware"
"non-VPN-aware" NHRP entities
2. Overview of NHRP VPN
2.1
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in RFC 2119 [4].
In addition to the terminology specified in section 2.1 of [1],
following definitions and acronyms are used
Default Routing Instance -- In the presence of VPNs, all packets
processed (e.g., routed) within the context of a specific VPN. In
case where no VPN is indicated, a packet is processed according to
default VPN, i.e., a Default Routing Instance. This routing
may be the Public Internet, a particular VPN, etc. The term only
meaning for "VPN-aware" NHRP entities
Virtual Private Network (VPN) -- in the context of
specification, this term is used as described in [3].
VPN-aware -- a "VPN-aware" NHRP entity is an NHRP entity
implements the NHRP enhancements for VPNs as defined in
document
Non-VPN-aware -- a "non-VPN-aware" NHRP entity is an NHRP
which is deployed as part of a single VPN, but is not VPN-aware
Restrictions applying to non-VPN-aware NHRP entities are
below. NHRP devices as specified in [1] are examples of non-VPN
aware entities
VPN encapsulation -- An LLC/SNAP encapsulation of a PDU with
indication of the VPN to which the PDU belongs. In the case that
underlying NBMA network is an ATM network, VPN encapsulation
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,
term is used as specified in [3].
VPN signalling -- in the context of this specification, this term
used to denote a method to indicate the VPN-ID via control
or similar ways in the control path
2.2 VPN Support
When supporting NHRP for a VPN, it is necessary to specify to
VPN the NHRP message applies in order to comply with the VPN
level agreement applicable to that VPN
On some NBMA networks, it is possible to establish a VPN-
control path between NHRP devices. This is sufficient to
the NHRP control packets as belonging to the "inherited" VPN
However, when that alternative is not used, the NHRP device
specify the VPN to which an NHRP packet applies in the PDU
It is not useful to add a VPN extension to NHRP control
because transit NHRP Servers are not required to process
extensions to an NHRP control message (see 5.3 in [1]). NHRP
already deployed might resolve the control packet within the scope
the public internetworking layer address space instead of the
address space causing problems in routing
Instead, an LLC/SNAP header with a VPN indication (as specified
Section 4.1 below) will be prepended to the NHRP control message
This solution allows the same VPN-specific LLC/SNAP header to
prepended to PDUs in both the control and data paths
3. NHRP VPN
3.1 VPN-Aware NHRP
When a VPN-aware NHRP device forwards a packet pertaining to
particular VPN, that device MUST be able to indicate the VPN either
a) explicitly through use of the VPN-specific LLC/SNAP header
b) implictly through an indication via VPN signalling
This applies to NHC-NHS, NHS-NHS, and NHS-NHC control messages
well as NHC-NHC shortcut traffic
For case a), the indication of the VPN-ID is via a VPN-
LLC/SNAP header specified in section 4.2 below. In the case of
underlying ATM network, see also section 8 of [2].
Fox & Petri Standards Track [Page 3]
RFC 2735 NHRP Support for Virtual Private Networks December 1999
For case b), the method used to indicate the VPN-ID via
signalling depends on the mechanisms available in the
network and is outside the scope of this memo. A VPN-aware
entity using VPN signalling SHOULD NOT also indicate the VPN-
explicity for any PDU on the related path
In transiting an NHRP Server, the VPN identification MAY be
in a different format than was received, however, the same VPN-
MUST be indicated for the message. For example, a PDU received
an LLC/SNAP header containing a VPN identifier may be forwarded on
control path which was established with an indication of the same
without the VPN-specific LLC/SNAP header
When a VPN capable NHRP entity receives an NHRP message from a VPN
aware NHRP device without a VPN indication via VPN encapsulation
VPN signalling, the message applies to the default routing
supported by the shared infrastructure. The public Internet or
particular VPN routing realm may be configured as the default
instance
3.2 Interactions of VPN-aware and non-VPN-aware NHRP
A VPN-aware NHRP entity MUST be able to indicate the VPN-ID in one
the ways specified in section 3.1 above. It MAY participate in
than one VPN
Because a non-VPN-aware NHRP device does not understand the
of VPNs, it only supports a single routing instance. Therefore,
non-VPN-aware NHRP entity belongs to exactly one VPN without
aware of it. All internetworking packets sent by that entity
assumed to belong to that VPN (Note that if the current IPv4-
Internet is regarded as just one big VPN, attached IPv4 hosts
e.g. be regarded as being "contained" in that VPN).
In order for a non-VPN-aware NHRP entity to interact with a VPN-
NHRP entity, the VPN-aware NHRP entity MUST be configured
associate the correct VPN-ID with information received from the non
VPN-aware entity. In other words, the VPN-aware NHRP entity acts
in the case of option b) from section 3.1 where the VPN-ID
indicated via VPN signalling. However, this association
provisioned using administrative means that are beyond the scope
this document instead of via VPN signalling. Further, it MUST
ensured by administrative means that non-VPN-aware NHRP entities
communicate either with other NHRP entities contained in the
VPN, or with VPN-aware NHRP entities with pre- configured
about the related VPN-ID of those non-VPN-aware entities
Fox & Petri Standards Track [Page 4]
RFC 2735 NHRP Support for Virtual Private Networks December 1999
VPN-aware NHRP entities SHALL only send information to non-VPN-
NHRP entities if that information belongs to the VPN in which
non-VPN-aware entity is contained. Information sent to a non-VPN
aware NHRP entity MUST not include any indication of the VPN-ID
In order to correctly transfer data packets, it is necessary
VPN-aware ingress NHRP clients to know whether their partner is
VPN-aware. If the egress is VPN-aware, the ingress NHC will also
the means described in section 3.1 on an NBMA shortcut to that
NHC to specify the VPN to which the data packet belongs
For this purpose, a further NHRP extension (in addition to
specified in section 5.3 of [1]) is specified which is called
Device Capabilities extension (see section 4.2 below). This
currently indicates the VPN capabilities of NHRP source
destination entities, but may also be used in the future for
additions to NHRP to indicate other capabilities as well
3.3 Handling of the NHRP Device Capabilities
The NHRP Device Capabilities extension MUST be attached to all
Resolution Requests generated by a VPN-aware source NHRP entity.
device SHOULD set the Source Capabilities field to indicate that
supports VPNs. The compulsory bit MUST be set to zero, so that
non-VPN-aware NHS may safely ignore the extension when forwarding
request. In addition, the A-bit (see section 5.2.1 of [1]) SHOULD
set to indicate that only authoritative next hop information
desired to avoid non-authoritative replies from non-VPN-aware
servers
Since a non-VPN-aware NHS is not able to process the NHRP
Capability extension, Network Admistrators MUST avoid
in which a VPN-aware NHRP Client is authoritatively served by a non
VPN-aware NHRP Server
If an egress NHS receives an NHRP Resolution Request with an
Device Capability Extension included, it returns an NHRP
Reply with an indication of whether the destination is VPN-aware
correctly setting the target capabilities flag [see Section 4.2].
If an egress NHS receives an NHRP Resolution Request without an
Device Capability Extension included or with the source
flag indicating that the source NHRP device is non-VPN-aware, it
act in one of the following ways
Fox & Petri Standards Track [Page 5]
RFC 2735 NHRP Support for Virtual Private Networks December 1999
- It MAY reject the NHRP Resolution Request; this is because
VPN-aware destination will be unable to determine the
of information received on an NBMA shortcut from a non-VPN
aware NHRP source. This is the default case
- If the destination is also non-VPN-aware, it MAY accept
request and return an NHRP Resolution Reply. By default,
two non-VPN-aware NHRP clients will interact correctly
- It MAY offer itself as a destination and resolve the
using its own NBMA address, if it has the related capabilities
- If the indicated VPN-ID identifies the default routing
of the destination, the NHS MAY accept the request and send
corresponding NHRP Resolution Reply
The NHRP Device Capabilities extension SHOULD NOT be included in
NHRP Register Request and Reply messages
3.4 Error handling
If an NHRP entity receives a PDU with a VPN-ID indicated via
encapsulation which is in conflict to a VPN-ID earlier allocated
that communication (e.g. via VPN signalling or administratively
configuration), it SHOULD send back an NHRP error indication (
5.2.7 of [1]) to the sender indicating error code 16 (VPN mismatch).
However, in order to avoid certain security issues, an NHRP
MAY instead silently drop the packet
If a VPN-aware NHRP entity receives a packet for a VPN that it
not support, it SHOULD send back an NHRP error indication to
sender with an error code 17 (VPN not supported). However, in
to avoid certain security issues, an NHRP entity MAY instead
drop the packet
If a VPN-aware NHS cannot find a route to forward a VPN-related
message, it SHOULD send back an NHRP error indication to the
with error code 6 (protocol address unreachable). However, in
to avoid certain security issues, an NHRP entity MAY instead
drop the packet
In all cases, where an NHRP error indication is returned by a VPN
aware NHRP entity, the incorrect VPN-ID related to this
SHALL be indicated via VPN encapsulation or VPN signalling,
when sending it to a non-VPN-aware NHRP device (see 3.1 / 3.2 above).
Fox & Petri Standards Track [Page 6]
RFC 2735 NHRP Support for Virtual Private Networks December 1999
4. NHRP Packet
4.1 VPN
The format of the VPN encapsulation header is as follows
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x5E | 0x00 | 0x08 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAD | OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC encapsulated PDU (up to 2^16 - 16 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
It consists of the following parts
- LLC/SNAP indication (0xAA-AA-03)
- OUI (of IANA) (0x00-00-5E
- PID allocated by IANA for VPN encapsulation (0x00-08)
- PAD field (inserted for 32-bit alignment
this field is coded as 0x00, and is ignored on
- VPN related OUI (see [3])
- VPN Index (see [3]).
When this encapsulation header is used, the remainder of the PDU
be structured according to the appropriate LLC/SNAP format (i.e.
would have been used without the additional VPN
header). Correspondingly, the following figure shows how
messages are transferred using VPN encapsulation
Fox & Petri Standards Track [Page 7]
RFC 2735 NHRP Support for Virtual Private Networks December 1999
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x5E | 0x00 | 0x08 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAD | OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x5E | 0x00 | 0x03 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NHRP message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following example shows how IP packets are transferred by
encapsulation
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x5E | 0x00 | 0x08 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PAD | OUI |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPN Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0xAA | 0xAA | 0x03 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x00 | 0x00 | 0x08 | 0x00 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP PDU (up to 2^16 - 24 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fox & Petri Standards Track [Page 8]
RFC 2735 NHRP Support for Virtual Private Networks December 1999
4.2 NHRP device capabilities
The format of the NHRP device capabilities extension is as follows
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C|u| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Target Capabilities |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
C: Compulsory = 0 (not a compulsory extension
u: Unused and MUST be set to zero
Type = 0x0009
Length = 0x0008
Source Capabilities field
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused |V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V bit
0x0 - the source NHRP device is non-VPN-
0x1 - the source NHRP device is VPN-
The unused bits MUST be set to zero on
and ignored on receipt
Fox & Petri Standards Track [Page 9]
RFC 2735 NHRP Support for Virtual Private Networks December 1999
Target Capabilities field
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| unused |V
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
V bit
0x0 - the destination NHRP device is non-VPN-
0x1 - the destination NHRP device is VPN-
The unused bits MUST be set to zero on
and ignored on receipt
4.3 Error
The following further Error Codes are defined in addition to
specified in section 5.2.7 of [1]):
16 - VPN
This error code is returned by a VPN-capable NHRP device, if
receives a PDU with a VPN-ID in the LLC/SNAP header
from the VPN-ID which had been specified earlier via
signalling
17 - VPN not
This error code is returned by a VPN-capable NHRP device, if
receives an NHRP message for a VPN that it does not support
5. Security
For any VPN application, it is important that VPN-related
is not misdirected to other VPNs and is not accessible when
transferred across a public or shared infrastructure. It is
RECOMMENDED to use the VPN support functions specified in
document in combination with NHRP authentication as specified
section 5.3.4 of [1]. Section 5.3.4.4 of [1] also provides
information on general security considerations related to NHRP
In cases where the NHRP entity does not trust all of the
entities, or is uncertain about the availability of the end-to-
NHRP authentication chain, it may use IPsec for confidentiality
integrity, etc
Fox & Petri Standards Track [Page 10]
RFC 2735 NHRP Support for Virtual Private Networks December 1999
6. IANA
The LLC/SNAP protocol ID 0x00-08 for VPN encapsulation had
been allocated by IANA in conjunction with [2]. This
does not require the allocation of any additional LLC/SNAP
IDs beyond that
It should be noted that IANA - as the owner of the VPN-related OUI
0x00-00-5E - is itself also a VPN authority which may allocate
indices to identify VPNs. The use of these particular VPN
within the context of this specification is reserved, and
allocation and approval by the IESG in accordance with RFC 2434.
[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 J. Heinanen, "Multiprotocol Encapsulation
ATM Adaptation Layer 5", RFC 2684, September 1999.
[3] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier",
RFC 2685, September 1999.
[4] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
Authors'
Barbara A.
Equipe
100 Nagog
Acton, MA 01720
Phone: +1-978-795-2009
EMail: bfox@equipecom.
Bernhard
Siemens
Hofmannstr. 51
Munich, Germany, D-81359
Phone: +49 89 722-34578
EMail: bernhard.petri@icn.siemens.
Fox & Petri Standards Track [Page 11]
RFC 2735 NHRP Support for Virtual Private Networks December 1999
Full Copyright
Copyright (C) The Internet Society (1999). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Fox & Petri Standards Track [Page 12]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
