rfc2735.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.


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: [phone]
   EMail: [e-mail]


   Bernhard Petri
   Siemens AG
   Hofmannstr. 51
   Munich, Germany, D-81359

   Phone: [phone]
   EMail: [e-mail]






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]