NHRP Support for Virtual Private Networks
Extracted elements (21)
A VPN extension was not added to NHRP control messages because transit NHRP Servers are not required to process extensions, and already-deployed servers might resolve control packets within the public address space instead of the private VPN address space. Instead, a VPN-specific LLC/SNAP header is prepended to NHRP control messages, allowing the same header to be used for both control and data paths.
The compulsory bit of the NHRP Device Capabilities extension is set to zero so that non-VPN-aware NHS devices may safely ignore it when forwarding resolution requests, enabling backward compatibility with legacy NHRP infrastructure.
A non-VPN-aware NHRP entity belongs to exactly one VPN without being aware of it; to interoperate with VPN-aware entities, the VPN-aware entity must be administratively pre-configured to associate the correct VPN-ID with traffic from the non-VPN-aware entity.
When a VPN-capable NHRP entity receives an NHRP message from a VPN-aware device without any VPN indication (neither VPN encapsulation nor VPN signalling), the message is treated as applying to the default routing instance, which may be the public Internet or a configured default VPN.
A VPN-aware NHRP entity MUST be configured to associate the correct VPN-ID with information received from non-VPN-aware entities, and it MUST be ensured by administrative means that non-VPN-aware NHRP entities only communicate with entities in the same VPN or with VPN-aware entities pre-configured with their VPN-ID.
A VPN-aware NHRP entity using VPN signalling SHOULD NOT also indicate the VPN-ID explicitly for any PDU on the related path, to avoid redundant or conflicting VPN identification.
If a VPN-aware NHRP entity receives a packet for a VPN it does not support, it SHOULD send back an NHRP error indication with error code 17 (VPN not supported), but MAY silently drop the packet to avoid certain security issues.
If an NHRP entity receives a PDU with a VPN-ID indicated via VPN encapsulation that conflicts with a previously allocated VPN-ID, it SHOULD send back an NHRP error indication with error code 16 (VPN mismatch), but MAY instead silently drop the packet to avoid security issues.
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.
Network Administrators MUST avoid configurations in which a VPN-aware NHRP Client is authoritatively served by a non-VPN-aware NHRP Server, since a non-VPN-aware NHS cannot process the NHRP Device Capability extension.
The NHRP Device Capabilities extension MUST be attached to all NHRP Resolution Requests generated by a VPN-aware source NHRP entity, with the compulsory bit set to zero so non-VPN-aware NHS may safely ignore it.
The NHRP Device Capabilities extension SHOULD NOT be included in NHRP Register Request and Reply messages.
VPN-aware NHRP entities SHALL only send information to non-VPN-aware NHRP entities if that information belongs to the VPN in which the non-VPN-aware entity is contained, and information sent to a non-VPN-aware NHRP entity MUST NOT include any indication of the VPN-ID.
When a VPN-aware NHRP device forwards a packet pertaining to a particular VPN, that device MUST be able to indicate the VPN either explicitly through use of the VPN-specific LLC/SNAP header or implicitly through an indication via VPN signalling.
When an NHRP error indication is returned by a VPN-aware NHRP entity, the incorrect VPN-ID SHALL be indicated via VPN encapsulation or VPN signalling, except when sending to a non-VPN-aware NHRP device.
The NHRP Device Capabilities extension (Type 0x0009) is a new NHRP extension that indicates VPN capabilities of source and destination NHRP entities, enabling VPN-aware ingress NHCs to determine whether egress NHCs are also VPN-aware before establishing shortcuts.
Two new NHRP error codes are defined: error code 16 (VPN mismatch) returned when a PDU contains a VPN-ID in the LLC/SNAP header that differs from the previously signalled VPN-ID, and error code 17 (VPN not supported) returned when a message arrives for an unsupported VPN.
The LLC/SNAP protocol ID 0x00-08 for VPN encapsulation was previously allocated by IANA in conjunction with RFC 2684; this document requires no additional LLC/SNAP protocol ID allocations. VPN indices under the IANA OUI (0x00-00-5E) are reserved and require IESG allocation and approval per RFC 2434.
It is RECOMMENDED to use VPN support functions in combination with NHRP authentication (section 5.3.4 of RFC 2332) to prevent VPN-related information from being misdirected to other VPNs or accessed across shared infrastructure. Where full trust in the NHRP authentication chain cannot be established, IPsec SHOULD be used for confidentiality and integrity.
The NHRP Device Capabilities extension has Type=0x0009, Length=0x0008, compulsory bit C=0, and two 32-bit capability fields (Source Capabilities and Target Capabilities), each with a single V-bit (LSB) indicating VPN-awareness (0=non-VPN-aware, 1=VPN-aware).
The VPN encapsulation header consists of: LLC/SNAP indicator (0xAA-AA-03), IANA OUI (0x00-00-5E), PID for VPN encapsulation (0x00-08), a PAD byte for 32-bit alignment (coded 0x00), a VPN-related OUI (3 bytes), and a VPN Index (4 bytes), followed by the LLC-encapsulated PDU.