From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2735.txt | 675 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 675 insertions(+) create mode 100644 doc/rfc/rfc2735.txt (limited to 'doc/rfc/rfc2735.txt') diff --git a/doc/rfc/rfc2735.txt b/doc/rfc/rfc2735.txt new file mode 100644 index 0000000..b16a109 --- /dev/null +++ b/doc/rfc/rfc2735.txt @@ -0,0 +1,675 @@ + + + + + + +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 + used to denote a method to indicate the VPN-ID via control signalling + or similar ways in the control path. + +2.2 VPN Support Overview + + 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 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 4.1 below) 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 + +3.1 VPN-Aware NHRP Operation + + When a VPN-aware NHRP device forwards a packet pertaining to a + particular VPN, that device MUST be able to indicate the VPN either: + + a) explicitly through use of the VPN-specific LLC/SNAP header or + b) implictly through an indication via VPN signalling. + + This applies to NHC-NHS, NHS-NHS, and NHS-NHC control messages as + well as NHC-NHC shortcut traffic. + + For case a), the indication of the VPN-ID is via a VPN-specific + LLC/SNAP header specified in section 4.2 below. In the case of an + 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 VPN + signalling depends on the mechanisms available in the underlying + network and is outside the scope of this memo. A VPN-aware NHRP + entity using VPN signalling SHOULD NOT also indicate the VPN-ID + explicity for any PDU on the related path. + + 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. + + When a VPN capable NHRP entity receives an NHRP message from a VPN- + aware NHRP device without a VPN indication via VPN encapsulation or + VPN signalling, the message applies to the default routing instance + supported by the shared infrastructure. The public Internet or a + particular VPN routing realm may be configured as the default routing + instance. + +3.2 Interactions of VPN-aware and non-VPN-aware NHRP entities + + A VPN-aware NHRP entity MUST be able to indicate the VPN-ID in one of + the ways specified in section 3.1 above. It MAY participate in more + than one VPN. + + Because a non-VPN-aware NHRP device does not understand the concept + of VPNs, it only supports a single routing instance. Therefore, a + non-VPN-aware NHRP entity belongs to exactly one VPN without being + aware of it. All internetworking packets sent by that entity are + assumed to belong to that VPN (Note that if the current IPv4-based + Internet is regarded as just one big VPN, attached IPv4 hosts may + e.g. be regarded as being "contained" in that VPN). + + In order for a non-VPN-aware NHRP entity to interact with a VPN-aware + NHRP entity, the VPN-aware NHRP entity MUST be configured to + associate the correct VPN-ID with information received from the non- + VPN-aware entity. In other words, the VPN-aware NHRP entity acts as + in the case of option b) from section 3.1 where the VPN-ID was + indicated via VPN signalling. However, this association is + provisioned using administrative means that are beyond the scope of + this document instead of via VPN signalling. Further, it MUST be + ensured by administrative means that non-VPN-aware NHRP entities only + communicate either with other NHRP entities contained in the same + VPN, or with VPN-aware NHRP entities with pre- configured information + 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-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. + + In order to correctly transfer data packets, it is necessary for + VPN-aware ingress NHRP clients to know whether their partner is also + VPN-aware. If the egress is VPN-aware, the ingress NHC will also use + the means described in section 3.1 on an NBMA shortcut to that egress + NHC to specify the VPN to which the data packet belongs. + + For this purpose, a further NHRP extension (in addition to those + specified in section 5.3 of [1]) is specified which is called NHRP + Device Capabilities extension (see section 4.2 below). This extension + currently indicates the VPN capabilities of NHRP source and + destination entities, but may also be used in the future for further + additions to NHRP to indicate other capabilities as well. + +3.3 Handling of the NHRP Device Capabilities extension + + The NHRP Device Capabilities extension MUST be attached to all NHRP + Resolution Requests generated by a VPN-aware source NHRP entity. The + device SHOULD set the Source Capabilities field to indicate that it + supports VPNs. The compulsory bit MUST be set to zero, so that a + non-VPN-aware NHS may safely ignore the extension when forwarding the + request. In addition, the A-bit (see section 5.2.1 of [1]) SHOULD be + set to indicate that only authoritative next hop information is + desired to avoid non-authoritative replies from non-VPN-aware NHRP + servers. + + Since a non-VPN-aware NHS is not able to process the NHRP Device + Capability extension, Network Admistrators MUST avoid configurations + 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 NHRP + Device Capability Extension included, it returns an NHRP Resolution + Reply with an indication of whether the destination is VPN-aware by + correctly setting the target capabilities flag [see Section 4.2]. + + If an egress NHS receives an NHRP Resolution Request without an NHRP + Device Capability Extension included or with the source capabilities + flag indicating that the source NHRP device is non-VPN-aware, it MAY + 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 the + VPN-aware destination will be unable to determine the context + 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 the + request and return an NHRP Resolution Reply. By default, the + two non-VPN-aware NHRP clients will interact correctly. + + - It MAY offer itself as a destination and resolve the request + using its own NBMA address, if it has the related capabilities. + + - If the indicated VPN-ID identifies the default routing instance + of the destination, the NHS MAY accept the request and send a + corresponding NHRP Resolution Reply. + + The NHRP Device Capabilities extension SHOULD NOT be included in the + NHRP Register Request and Reply messages. + +3.4 Error handling procedures + + If an NHRP entity receives a PDU with a VPN-ID indicated via VPN + encapsulation which is in conflict to a VPN-ID earlier allocated to + that communication (e.g. via VPN signalling or administratively via + configuration), it SHOULD send back an NHRP error indication (see + 5.2.7 of [1]) to the sender indicating error code 16 (VPN mismatch). + However, in order to avoid certain security issues, an NHRP entity + MAY instead silently drop the packet. + + If a VPN-aware NHRP entity receives a packet for a VPN that it does + not support, it SHOULD send back an NHRP error indication to the + sender with an error code 17 (VPN not supported). However, in order + to avoid certain security issues, an NHRP entity MAY instead silently + drop the packet. + + If a VPN-aware NHS cannot find a route to forward a VPN-related NHRP + message, it SHOULD send back an NHRP error indication to the sender + with error code 6 (protocol address unreachable). However, in order + to avoid certain security issues, an NHRP entity MAY instead silently + 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 indication + SHALL be indicated via VPN encapsulation or VPN signalling, except + 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 Formats + +4.1 VPN encapsulation + + 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 receipt + - VPN related OUI (see [3]) + - VPN Index (see [3]). + + When this encapsulation header is used, the remainder of the PDU MUST + be structured according to the appropriate LLC/SNAP format (i.e. that + would have been used without the additional VPN encapsulation + header). Correspondingly, the following figure shows how NHRP + 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 VPN + 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 extension + + 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-aware + 0x1 - the source NHRP device is VPN-aware + + The unused bits MUST be set to zero on transmission + 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-aware + 0x1 - the destination NHRP device is VPN-aware + + The unused bits MUST be set to zero on transmission + and ignored on receipt. + +4.3 Error Codes + + 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 with a VPN-ID in the LLC/SNAP header different + from the VPN-ID which had been specified earlier via VPN + signalling. + + 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. + +5. Security Considerations + + For any VPN application, it is important that VPN-related information + is not misdirected to other VPNs and is not accessible when being + transferred across a public or shared infrastructure. It is therefore + RECOMMENDED to use the VPN support functions specified in this + document in combination with NHRP authentication as specified in + section 5.3.4 of [1]. Section 5.3.4.4 of [1] also provides further + information on general security considerations related to NHRP. + + In cases where the NHRP entity does not trust all of the NHRP + entities, or is uncertain about the availability of the end-to-end + 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 Considerations + + The LLC/SNAP protocol ID 0x00-08 for VPN encapsulation had already + been allocated by IANA in conjunction with [2]. This specification + does not require the allocation of any additional LLC/SNAP protocol + 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 VPN + indices to identify VPNs. The use of these particular VPN indices + within the context of this specification is reserved, and requires + allocation and approval by the IESG in accordance with RFC 2434. + +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 J. Heinanen, "Multiprotocol Encapsulation over + 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 Requirement + Levels", BCP 14, RFC 2119, March 1997. + +Authors' Addresses + + Barbara A. Fox + Equipe Communications + 100 Nagog Park + Acton, MA 01720 + + Phone: +1-978-795-2009 + EMail: bfox@equipecom.com + + + Bernhard Petri + Siemens AG + Hofmannstr. 51 + Munich, Germany, D-81359 + + Phone: +49 89 722-34578 + EMail: bernhard.petri@icn.siemens.de + + + + + + +Fox & Petri Standards Track [Page 11] + +RFC 2735 NHRP Support for Virtual Private Networks December 1999 + + +Full Copyright Statement + + Copyright (C) The Internet Society (1999). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING + TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING + BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION + HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF + MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Fox & Petri Standards Track [Page 12] + -- cgit v1.2.3