idnits 2.17.1 draft-ietf-ion-nhrp-vpn-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 6) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. Information sent to a non-VPN-aware NHRP entity MUST not include any indication of the VPN-ID. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Barbara A. Fox 2 INTERNET-DRAFT Equipe Communications 3 Bernhard Petri 4 Expires April, 2000 Siemens AG 6 NHRP Support for Virtual Private Networks 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet- Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The NBMA Next Hop Resolution Protocol (NHRP) is used to determine the 32 NBMA subnetwork addresses of the "NBMA next hop" towards a public 33 internetworking layer address (see [1]). This document describes the 34 enhancements necessary to enable NHRP to perform the same function 35 for private internetworking layer addresses available within the 36 framework of a Virtual Private Network (VPN) service on a shared NBMA 37 network. 39 1. Introduction 41 NHRP is a public internetworking layer based resolution protocol. 42 There is an implicit understanding in [1] that a control message 43 applies to the public address space. 45 Service Providers of Virtual Private Network (VPN) services will 46 offer VPN participants specific service level agreements (SLA) which 47 may include, for example, dedicated routing functions and/or specific 48 QoS levels. A particularly important feature of a VPN service is the 49 ability to use a private address space which may overlap with the 50 address space of another VPN or the Public Internet. Therefore, such 51 an internetworking layer address only has meaning within the VPN in 52 which it exists. For this reason, it is necessary to identify the 53 VPN in which a particular internetworking layer address has meaning, 54 the "scope" of the internetworking layer address. 56 As VPNs are deployed on shared networks, NHRP may be used to resolve 57 a private VPN address to a shared NBMA network address. In order to 58 properly resolve a private VPN address, it is necessary for the NHRP 59 device to be able to identify the VPN in which the address has 60 meaning and determine resolution information based on that "scope". 62 As VPN services are added to an NBMA network using NHRP devices, it 63 may be necessary to support the service with legacy NHRP devices that 64 do not have VPN knowledge and so do not explicitly support VPNs. 65 This document describes requirements for "VPN-aware" NHRP entities to 66 support VPN services while communicating with both "VPN-aware" and 67 "non-VPN-aware" NHRP entities. 69 2. Overview of NHRP VPN Support 71 2.1 Terminology 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119. 77 In addition to the terminology specified in section 2.1 of [1], the 78 following definitions and acronyms are used: 80 Default Routing Instance -- In the presence of VPNs, all packets are 81 processed (e.g., routed) within the context of a specific VPN. In the 82 case where no VPN is indicated, a packet is processed according to a 83 default VPN, i.e., a Default Routing Instance. This routing instance 84 may be the Public Internet, a particular VPN, etc. The term only has 85 meaning for "VPN-aware" NHRP entities. 87 Virtual Private Network (VPN) -- in the context of this 88 specification, this term is used as described in [3]. 90 VPN-aware -- a "VPN-aware" NHRP entity is an NHRP entity that 91 implements the NHRP enhancements for VPNs as defined in this 92 document. 94 Non-VPN-aware -- a "non-VPN-aware" NHRP entity is an NHRP entity 95 which is deployed as part of a single VPN, but is not VPN-aware. 96 Restrictions applying to non-VPN-aware NHRP entities are outlined 97 below. NHRP devices as specified in [1] are examples of non-VPN- 98 aware entities. 100 VPN encapsulation -- An LLC/SNAP encapsulation of a PDU with an 101 indication of the VPN to which the PDU belongs. In the case that the 102 underlying NBMA network is an ATM network, VPN encapsulation is 103 specified in section 8 of [2]. 105 VPN identifier (VPN-ID) -- in the context of this specification, this 106 term is used as specified in [3]. 108 VPN signalling -- in the context of this specification, this term is 109 used to denote a method to indicate the VPN-ID via control signalling 110 or similar ways in the control path. 112 2.2 VPN Support Overview 114 When supporting NHRP for a VPN, it is necessary to specify to which 115 VPN the NHRP message applies in order to comply with the VPN service 116 level agreement applicable to that VPN. 118 On some NBMA networks, it is possible to establish a VPN-specific 119 control path between NHRP devices. This is sufficient to identify 120 the NHRP control packets as belonging to the "inherited" VPN. 121 However, when that alternative is not used, the NHRP device must 122 specify the VPN to which an NHRP packet applies in the PDU. 124 It is not useful to add a VPN extension to NHRP control messages 125 because transit NHRP Servers are not required to process the 126 extensions to an NHRP control message (see 5.3 in [1]). NHRP Servers 127 already deployed might resolve the control packet within the scope of 128 the public internetworking layer address space instead of the private 129 address space causing problems in routing. 131 Instead, an LLC/SNAP header with a VPN indication (as specified in 132 Section 4.1 below) will be prepended to the NHRP control message. 133 This solution allows the same VPN-specific LLC/SNAP header to be 134 prepended to PDUs in both the control and data paths. 136 3. NHRP VPN Operation 138 3.1 VPN-Aware NHRP Operation 140 When a VPN-aware NHRP device forwards a packet pertaining to a 141 particular VPN, that device MUST be able to indicate the VPN either: 143 a) explicitly through use of the VPN-specific LLC/SNAP header or 144 b) implictly through an indication via VPN signalling. 146 This applies to NHC-NHS, NHS-NHS, and NHS-NHC control messages as 147 well as NHC-NHC shortcut traffic. 149 For case a), the indication of the VPN-ID is via a VPN-specific 150 LLC/SNAP header specified in section 4.2 below. In the case of an 151 underlying ATM network, see also section 8 of [2]. 153 For case b), the method used to indicate the VPN-ID via VPN 154 signalling depends on the mechanisms available in the underlying 155 network and is outside the scope of this draft. A VPN-aware NHRP 156 entity using VPN signalling SHOULD NOT also indicate the VPN-ID 157 explicity for any PDU on the related path. 159 In transiting an NHRP Server, the VPN identification MAY be forwarded 160 in a different format than was received, however, the same VPN-ID 161 MUST be indicated for the message. For example, a PDU received with 162 an LLC/SNAP header containing a VPN identifier may be forwarded on a 163 control path which was established with an indication of the same VPN 164 without the VPN-specific LLC/SNAP header. 166 When a VPN capable NHRP entity receives an NHRP message from a VPN- 167 aware NHRP device without a VPN indication via VPN encapsulation or 168 VPN signalling, the message applies to the default routing instance 169 supported by the shared infrastructure. The public Internet or a 170 particular VPN routing realm may be configured as the default routing 171 instance. 173 3.2 Interactions of VPN-aware and non-VPN-aware NHRP entities 175 A VPN-aware NHRP entity MUST be able to indicate the VPN-ID in one of 176 the ways specified in section 3.1 above. It MAY participate in more 177 than one VPN. 179 Because a non-VPN-aware NHRP device does not understand the concept 180 of VPNs, it only supports a single routing instance. Therefore, a 181 non-VPN-aware NHRP entity belongs to exactly one VPN without being 182 aware of it. All internetworking packets sent by that entity are 183 assumed to belong to that VPN (Note that if the current IPv4-based 184 Internet is regarded as just one big VPN, attached IPv4 hosts may 185 e.g. be regarded as being "contained" in that VPN). 187 In order for a non-VPN-aware NHRP entity to interact with a VPN-aware 188 NHRP entity, the VPN-aware NHRP entity MUST be configured to 189 associate the correct VPN-ID with information received from the non- 190 VPN-aware entity. In other words, the VPN-aware NHRP entity acts as 191 in the case of option b) from section 3.1 where the VPN-ID was 192 indicated via VPN signalling. However, this association is 193 provisioned using administrative means that are beyond the scope of 194 this document instead of via VPN signalling. Further, it MUST be 195 ensured by administrative means that non-VPN-aware NHRP entities only 196 communicate either with other NHRP entities contained in the same 197 VPN, or with VPN-aware NHRP entities with pre- configured information 198 about the related VPN-ID of those non-VPN-aware entities. 200 VPN-aware NHRP entities SHALL only send information to non-VPN-aware 201 NHRP entities if that information belongs to the VPN in which the 202 non-VPN-aware entity is contained. Information sent to a non-VPN- 203 aware NHRP entity MUST not include any indication of the VPN-ID. 205 In order to correctly transfer data packets, it is necessary for 206 VPN-aware ingress NHRP clients to know whether their partner is also 207 VPN-aware. If the egress is VPN-aware, the ingress NHC will also use 208 the means described in section 3.1 on an NBMA shortcut to that egress 209 NHC to specify the VPN to which the data packet belongs. 211 For this purpose, a further NHRP extension (in addition to those 212 specified in section 5.3 of [1]) is specified which is called NHRP 213 Device Capabilities extension (see section 4.2 below). This extension 214 currently indicates the VPN capabilities of NHRP source and 215 destination entities, but may also be used in the future for further 216 additions to NHRP to indicate other capabilities as well. 218 3.3 Handling of the NHRP Device Capabilities extension 220 The NHRP Device Capabilities extension MUST be attached to all NHRP 221 Resolution Requests generated by a VPN-aware source NHRP entity. The 222 device SHOULD set the Source Capabilities field to indicate that it 223 supports VPNs. The compulsory bit MUST be set to zero, so that a 224 non-VPN-aware NHS may safely ignore the extension when forwarding the 225 request. In addition, the A-bit (see section 5.2.1 of [1]) SHOULD be 226 set to indicate that only authoritative next hop information is 227 desired to avoid non-authoritative replies from non-VPN-aware NHRP 228 servers. 230 NTERNET-DRAFT NHRP VPN Expires April 2000 232 Since a non-VPN-aware NHS is not able to process the NHRP Device 233 Capability extension, Network Admistrators MUST avoid configurations 234 in which a VPN-aware NHRP Client is authoritatively served by a non- 235 VPN-aware NHRP Server. 237 If an egress NHS receives an NHRP Resolution Request with an NHRP 238 Device Capability Extension included, it returns an NHRP Resolution 239 Reply with an indication of whether the destination is VPN-aware by 240 correctly setting the target capabilities flag [see Section 4.2]. 242 If an egress NHS receives an NHRP Resolution Request without an NHRP 243 Device Capability Extension included or with the source capabilities 244 flag indicating that the source NHRP device is non-VPN-aware, it MAY 245 act in one of the following ways: 247 - It MAY reject the NHRP Resolution Request; this is because the 248 VPN-aware destination will be unable to determine the context of 249 information received on an NBMA shortcut from a non-VPN-aware NHRP 250 source. This is the default case. 252 - If the destination is also non-VPN-aware, it MAY accept the 253 request and return an NHRP Resolution Reply. By default, the two 254 non-VPN-aware NHRP clients will interact correctly. 256 - It MAY offer itself as a destination and resolve the request 257 using its own NBMA address, if it has the related capabilities. 259 - If the indicated VPN-ID identifies the default routing instance 260 of the destination, the NHS MAY accept the request and send a 261 corresponding NHRP Resolution Reply. 263 The NHRP Device Capabilities extension SHOULD NOT be included in the 264 NHRP Register Request and Reply messages. 266 3.4 Error handling procedures 268 If an NHRP entity receives a PDU with a VPN-ID indicated via VPN 269 encapsulation which is in conflict to a VPN-ID earlier allocated to 270 that communication (e.g. via VPN signalling or administratively via 271 configuration), it SHOULD send back an NHRP error indication (see 272 5.2.7 of [1]) to the sender indicating error code 16 (VPN mismatch). 273 However, in order to avoid certain security issues, an NHRP entity 274 MAY instead silently drop the packet. 276 If a VPN-aware NHRP entity receives a packet for a VPN that it does 277 not support, it SHOULD send back an NHRP error indication to the 278 sender with an error code 17 (VPN not supported). However, in order 279 to avoid certain security issues, an NHRP entity MAY instead silently 280 drop the packet. 282 If a VPN-aware NHS cannot find a route to forward a VPN-related NHRP 283 message, it SHOULD send back an NHRP error indication to the sender 284 with error code 6 (protocol address unreachable). However, in order 285 to avoid certain security issues, an NHRP entity MAY instead silently 286 drop the packet. 288 In all cases, where an NHRP error indication is returned by a VPN- 289 aware NHRP entity, the incorrect VPN-ID related to this indication 290 SHALL be indicated via VPN encapsulation or VPN signalling, except 291 when sending it to a non-VPN-aware NHRP device (see 3.1 / 3.2 above). 293 4. NHRP Packet Formats 295 4.1 VPN encapsulation 297 The format of the VPN encapsulation header is as follows: 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | 0xAA | 0xAA | 0x03 | 0x00 | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | 0x00 | 0x5E | 0x00 | 0x08 | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | PAD | OUI | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | VPN Index | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | LLC encapsulated PDU (up to 2^16 - 16 octets) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 It consists of the following parts: 315 - LLC/SNAP indication (0xAA-AA-03) 316 - OUI (of IANA) (0x00-00-5E) 317 - PID allocated by IANA for VPN encapsulation (0x00-08) 318 - PAD field (inserted for 32-bit alignment) 319 this field is coded as 0x00, and is ignored on receipt 320 - VPN related OUI (see [3]) 321 - VPN Index (see [3]). 323 When this encapsulation header is used, the remainder of the PDU MUST 324 be structured according to the appropriate LLC/SNAP format (i.e. that 325 would have been used without the additional VPN encapsulation 326 header). Correspondingly, the following figure shows how NHRP 327 messages are transferred using VPN encapsulation: 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | 0xAA | 0xAA | 0x03 | 0x00 | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | 0x00 | 0x5E | 0x00 | 0x08 | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | PAD | OUI | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | VPN Index | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | 0xAA | 0xAA | 0x03 | 0x00 | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | 0x00 | 0x5E | 0x00 | 0x03 | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 | NHRP message | 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 The following example shows how IP packets are transferred by VPN 348 encapsulation: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | 0xAA | 0xAA | 0x03 | 0x00 | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | 0x00 | 0x5E | 0x00 | 0x08 | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | PAD | OUI | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | VPN Index | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | 0xAA | 0xAA | 0x03 | 0x00 | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | 0x00 | 0x00 | 0x08 | 0x00 | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | IP PDU (up to 2^16 - 24 octets) | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 4.2 NHRP device capabilities extension 369 The format of the NHRP device capabilities extension is as follows: 371 0 1 2 3 372 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 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 |C|u| Type | Length | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Source Capabilities | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Target Capabilities | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 C: Compulsory = 0 (not a compulsory extension) 382 u: Unused and MUST be set to zero. 383 Type = 0x0009 384 Length = 0x0008 386 Source Capabilities field: 388 0 1 2 3 389 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 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | unused |V| 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 V bit: 396 0x0 - the source NHRP device is non-VPN-aware 397 0x1 - the source NHRP device is VPN-aware 399 The unused bits MUST be set to zero on transmission 400 and ignored on receipt. 402 Target Capabilities field: 404 0 1 2 3 405 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 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | unused |V| 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 V bit: 411 0x0 - the destination NHRP device is non-VPN-aware 412 0x1 - the destination NHRP device is VPN-aware 414 The unused bits MUST be set to zero on transmission 415 and ignored on receipt. 417 4.3 Error Codes 419 The following further Error Codes are defined in addition to those 420 specified in section 5.2.7 of [1]): 422 16 - VPN mismatch 424 This error code is returned by a VPN-capable NHRP device, if it 425 receives a PDU with a VPN-ID in the LLC/SNAP header different 426 from the VPN-ID which had been specified earlier via VPN 427 signalling. 429 17 - VPN not supported 431 This error code is returned by a VPN-capable NHRP device, if it 432 receives an NHRP message for a VPN that it does not support. 434 5. Security considerations 436 For any VPN application, it is important that VPN-related information 437 is not misdirected to other VPNs and is not accessible when being 438 transferred across a public or shared infrastructure. It is therefore 439 RECOMMENDED to use the VPN support functions specified in this 440 document in combination with NHRP authentication as specified in 441 section 5.3.4 of [1]. Section 5.3.4.4 of [1] also provides further 442 information on general security considerations related to NHRP. 444 In cases where the NHRP entity does not trust all of the NHRP 445 entities, or is uncertain about the availability of the end-to-end 446 NHRP authentication chain, it may use IPsec for confidentiality, 447 integrity, etc. 449 6. IANA considerations 451 The LLC/SNAP protocol ID 0x00-08 for VPN encapsulation had already 452 been allocated by IANA in conjunction with [2]. This specification 453 does not require the allocation of any additional LLC/SNAP protocol 454 IDs beyond that. 456 It should be noted that IANA - as the owner of the VPN-related OUI: 457 0x00-00-5E - is itself also a VPN authority which may allocate VPN 458 indices to identify VPNs. The use of these particular VPN indices 459 within the context of this specification is reserved, and requires 460 allocation and approval by the IESG in accordance with RFC 2434. 462 References 464 [1] Luciani, J., Katz, D., Piscitello, D., Cole, B., and 465 N. Doraswamy, "NMBA Next Hop Resolution Protocol (NHRP)", RFC 466 2332, April 1998. 468 [2] Grossman, D. and Heinanen, J. "Multiprotocol Encapsulation over ATM 469 Adaptation Layer 5", RFC 2684, September 1999. 471 [3] Fox, B., Gleeson, B., "Virtual Private Networks Identifier", RFC 2685, 472 September 1999. 474 Author Information 476 Barbara A. Fox 477 Equipe Communications 478 101 Nagog Park 479 Acton, MA 01720 480 phone: +1-978-635-1999 x2009 481 email: bfox@equipecom.com 483 Bernhard Petri 484 Siemens AG 485 Hofmannstr. 51 486 Munich, Germany, D-81359 487 phone: +49 89 722-34578 488 email: bernhard.petri@icn.siemens.de