Movatterモバイル変換

Network Working Group                                         J. CarlsonRequest for Comments: 3772                              Sun MicrosystemsCategory: Standards Track                                     R. Winslow                                                      L-3 Communications                                                                May 2004Point-to-Point Protocol (PPP) Vendor ProtocolStatus 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 (2004).  All Rights Reserved.Abstract   The Point-to-Point Protocol (PPP) defines a Link Control Protocol   (LCP) and a method for negotiating the use of multi-protocol traffic   over point-to-point links.  The PPP Vendor Extensions document adds   vendor-specific general-purpose Configuration Option and Code   numbers.  This document extends these features to cover vendor-   specific Network, Authentication, and Control Protocols.1.  Introduction   PPP's [1] Vendor Extensions [3] defines a general-purpose mechanism   for the negotiation of various vendor-proprietary options and   extensions to the kinds of control messages that may be sent via the   Code field.   Some implementors may want to define proprietary network and control   protocols in addition to the already-described features.  While it   would be possible for such an implementor to use the existing LCP   Vendor-Specific Option to enable the use of the proprietary protocol,   this staged negotiation (enable via LCP, then negotiate via some   locally-assigned protocol number) suffers from at least three   problems:Carlson & Winslow           Standards Track                     [Page 1]

RFC 3772                  PPP Vendor Protocol                   May 2004   First, because it would be in LCP, the negotiation of the use of the   protocol would begin before identification and authentication of the   peer had been done.  This complicates the security analysis of the   feature and constrains the way in which the protocol might be   deployed.   Second, where compulsory tunneling is in use, the system performing   the initial LCP negotiation may be unrelated to the system that uses   the proprietary protocol.  In such a scenario, enabling the protocol   at LCP time would require either LCP renegotiation or support of the   proprietary protocol in the initial negotiator, both of which raise   deployment problems.   Third, the fact that any protocol negotiated via such a mechanism   would necessarily use a protocol number that is not assigned by IANA   complicates matters for diagnostic tools used to monitor the   datastream.  Having a fixed number allows these tools to display such   protocols in a reasonable, albeit limited, format.   A cleaner solution is thus to define a set of vendor-specific   protocols, one in each of the four protocol number ranges defined by   [1].  This specification reserves the following values:   Value (in hex)  Protocol Name   005b            Vendor-Specific Network Protocol (VSNP)   405b            Vendor-Specific Protocol (VSP)   805b            Vendor-Specific Network Control Protocol (VSNCP)   c05b            Vendor-Specific Authentication Protocol (VSAP)   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 inBCP 14,RFC 2119 [2].2.  PPP Vendor-Specific Network Control Protocol (VSNCP)   The Vendor-Specific Network Control Protocol (VSNCP) is responsible   for negotiating the use of the Vendor-Specific Network Protocol   (VSNP).  VSNCP uses the same packet exchange and option negotiation   mechanism as LCP, but with a different set of options.   VSNCP packets MUST NOT be exchanged until PPP has reached the   Network-Layer Protocol phase.  Any VSNCP packets received when not in   that phase MUST be silently ignored.  If a VSNCP packet with an   unrecognized OUI is received, an LCP Protocol-Reject SHOULD be sent   in response.Carlson & Winslow           Standards Track                     [Page 2]

RFC 3772                  PPP Vendor Protocol                   May 2004   The network layer data, carried in VSNP packets, MUST NOT be sent   unless VSNCP is in Opened state.  If a VSNP packet is received when   VSNCP is not in Opened state and LCP is Opened, the implementation   MAY respond using LCP Protocol-Reject.2.1.  VSNCP Packet Format   Exactly one VSNCP packet is carried in the PPP Information field,   with the PPP Protocol field set to hex 805b (VSNCP).  A summary of   the VSNCP packet format is shown below.  The fields are transmitted   from left to right.    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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Code      |  Identifier   |            Length             |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                    OUI                        |    Data ...   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Code      Only LCP Code values 1 through 7 (Configure-Request, Configure-      Ack, Configure-Nak, Configure-Reject, Terminate-Request,      Terminate-Ack, and Code-Reject) are used.  All other codes SHOULD      result in a VSNCP Code-Reject reply.   Identifier and Length      These are as documented for LCP.   OUI      This three-octet field contains the vendor's Organizationally      Unique Identifier.  The bits within the octet are in canonical      order, and the most significant octet is transmitted first.  SeeSection 5 below for more information on OUI values.   Data      This field contains data in the same format as for the      corresponding LCP Code numbers.Carlson & Winslow           Standards Track                     [Page 3]

RFC 3772                  PPP Vendor Protocol                   May 20042.2.  VSNP Packet Format   When VSNCP is in Opened state, VSNP packets may be sent by setting   the PPP Protocol field to hex 005b (VSNP) and placing the vendor-   specific data in the PPP Information field.  No restrictions are   placed on this data.3.  PPP Vendor-Specific Protocol (VSP)   The Vendor-Specific Protocol (VSP) is intended for use in situations   where the implementation of a complete Network Layer Protocol is   unnecessary, or where per-link signaling is required (seeSection 7   below).   VSP packets MUST NOT be sent until PPP has reached either Network-   Layer Protocol or Authentication phase.  VSP packets received before   those phases MUST be silently ignored.  Once the proper phase has   been reached, a VSP packet containing an unrecognized OUI value   SHOULD be returned using LCP Protocol-Reject.   Exactly one VSP packet is carried in the PPP Information field, with   the PPP Protocol field set to 405b (VSP).  A summary of the VSP   packet format is shown below.  The fields are transmitted from left   to right.    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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                       Magic-Number                            |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                    OUI                        |   Reserved    |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |    Data ...   +-+-+-+   Magic-Number      The four-octet Magic-Number field is used to detect looped-back      links.  If the Magic-Number Option was not negotiated by LCP, then      this field MUST be set to 0.  Implementation of the LCP Magic-      Number Option is RECOMMENDED.   OUI      This three-octet field contains the vendor's Organizationally      Unique Identifier.  The bits within the octet are in canonical      order, and the most significant octet is transmitted first.  SeeSection 5 below for more information on OUI values.Carlson & Winslow           Standards Track                     [Page 4]

RFC 3772                  PPP Vendor Protocol                   May 2004   Reserved      Reserved for future definition.  Must be zero on transmit and      ignored on reception.   Data      Vendor-specific data.4.  PPP Vendor-Specific Authentication Protocol (VSAP)   The Vendor-Specific Authentication Protocol (VSAP) is used in two   ways.  First, it is used with the LCP Authentication Option in order   to negotiate the use of a vendor-specific authentication protocol to   be used during the PPP Authentication phase.  Second, it is used in   the PPP Protocol field to carry those proprietary authentication   messages during the PPP Authentication phase.4.1.  VSAP Authentication Option Format   This option is used in LCP Configure-Request, -Ack, -Nak, and -Reject   messages.    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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Type      |    Length     |    Authentication-Protocol    |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |                    OUI                        |    Data ...   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   Type      3   Length      >=7   Authentication-Protocol      The hex value c05b, in Network Byte Order.Carlson & Winslow           Standards Track                     [Page 5]

RFC 3772                  PPP Vendor Protocol                   May 2004   OUI      This three-octet field contains the vendor's Organizationally      Unique Identifier.  The bits within the octet are in canonical      order, and the most significant octet is transmitted first.  SeeSection 5 below for more information on OUI values.   Data      This optional field contains options or other information specific      to the operation of the vendor-specific authentication protocol.4.2.  VSAP Authentication Data Format    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   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |     Code      |  Identifier   |            Length             |   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   |    Data ...   +-+-+-+-+   The Identifier and Length fields are as for LCP.  The Code and Data   fields and the processing of the messages are defined by the vendor-   specific protocol.   However, it is RECOMMENDED that vendor-specific protocols use Code 3   for "Success" and Code 4 for "Failure," as with [4] and [5], in order   to simplify the design of network monitoring equipment.5.  Organizationally Unique Identifiers   The three-octet Organizationally Unique Identifier (OUI) used in the   messages described in this document identifies an organization   ("vendor") that defines the meaning of the message.  This OUI is   based on IEEE 802 vendor assignments.   Vendors that desire to use their IEEE 802 OUI for a PPP Vendor   Protocol SHOULD also register the assigned OUI with IANA for the   benefit of the community.   A vendor that does not otherwise need an IEEE-assigned OUI can   request a PPP-specific OUI from the IANA.  This OUI shall be assigned   from the CF0000 series.  This procedure is defined for vendors that   are not able to use IEEE assignments, such as software-only vendors.Carlson & Winslow           Standards Track                     [Page 6]

RFC 3772                  PPP Vendor Protocol                   May 20046.  Multiple Vendor-Specific Protocols   Vendors are encouraged to define their protocols to allow for future   expansion, where necessary.  For example, it may be appropriate for a   VSNP to include a locally-defined selector field to distinguish among   multiple proprietary protocols carried via this mechanism, and   appropriate Configuration Options in VSNCP to enable and disable   these sub-protocols.  Because the requirements of such a selector are   known only to the vendor defining such protocols, they are not   described further in this document.   An implementation MAY also support more than one vendor-specific   protocol, distinguished by OUI.  In this case, the implementation   MUST also treat LCP Protocol-Reject specially by examining the OUI   field in the rejected message and disabling only the protocol to   which it refers, rather than all use of the vendor-specific protocol   number.  Note that such an implementation is compatible with a simple   implementation that supports only one OUI: that implementation will   respond with LCP Protocol-Reject for unrecognized OUIs and otherwise   leave the negotiation state unmodified.   An OUI-distinguished mechanism is expected to be used only in the   case of cooperating vendors.  Vendors are encouraged to use just a   single OUI for all protocols defined by that vendor, if possible.7.  Multilink, Compression, and Encryption Considerations   The Vendor-Specific Network Protocol (VSNP) is defined to operate at   the bundle level if Multilink PPP [6] is in use, and also above any   Compression Protocols [7] and Encryption Protocols [8] in use.   The Vendor-Specific Protocol (VSP) is defined to operate at the per-   link level if Multilink PPP is in use, and MUST NOT be subjected to   data compression.  If a per-link encryption protocol is in use, then   VSP packets MUST be encrypted.   Note that because VSP is defined at the per-link level, bundle level   encryption does not affect VSP.8.  Security Considerations   The security of any vendor-specific authentication protocol is   subject to the provisions of that proprietary mechanism.   Implementations that wish to avoid security problems associated with   such protocols SHOULD send LCP Configure-Nak in response to an LCP   Configure-Request specifying VSAP, or MAY terminate operation.Carlson & Winslow           Standards Track                     [Page 7]

RFC 3772                  PPP Vendor Protocol                   May 2004   When operating with PPP encryption, but without Multilink PPP, VSP   packets are sent in the clear.  Implementations that require PPP   encryption as part of a security mechanism should consider whether to   employ per-link encryption or forego use of VSP in favor of VSNP.   The security of vendor-specific networking protocols is likewise   subject to the security mechanisms defined by those protocols.   Independent analysis of the security of any such protocol is   RECOMMENDED.9.  IANA Considerations   IANA has assigned four similarly-numbered PPP Protocol field values,   005b, 405b, 805b, and c05b, as described inSection 1 of this   document.   As described inSection 5 above and in [3], the IANA also maintains a   CF0000 series block of non-IEEE OUIs that may be allocated for   vendors that do not otherwise need an IEEE-assigned OUI.10.  References10.1.  Normative References   [1]  Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51,RFC 1661, July 1994.   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement        Levels",BCP 14,RFC 2119, March 1997.10.2.  Informative References   [3]  Simpson, W., "PPP Vendor Extensions",RFC 2153, May 1997.   [4]  Simpson, W., "PPP Challenge Handshake Authentication Protocol        (CHAP)",RFC 1994, August 1996.   [5]  Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication        Protocol (EAP)",RFC 2284, March 1998.   [6]  Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,        "The PPP Multilink Protocol (MP)",RFC 1990, August 1996.   [7]  Rand, D., "The PPP Compression Control Protocol (CCP)",RFC1962, June 1996.   [8]  Meyer, G., "The PPP Encryption Control Protocol (ECP)",RFC1968, June 1996.Carlson & Winslow           Standards Track                     [Page 8]

RFC 3772                  PPP Vendor Protocol                   May 200411.  Acknowledgments   The authors thank Karl Fox and Thomas Narten for their comments and   help in preparing this document.   Some of the language and phrasing has been borrowed fromRFC 1332,   written by Glenn McGregor, andRFC 2153, written by William Allen   Simpson.12.  Authors   Questions about this document should be addressed to the IETF pppext   working group or the authors listed below.   James Carlson   Sun Microsystems   1 Network Drive MS UBUR02-212   Burlington MA  01803-2757   Phone:  +1 781 442 2084   Fax:    +1 781 442 1677   EMail:  james.d.carlson@sun.com   Richard Winslow   L-3 Communications Systems - East   1 Federal Street A&E-2NE   Camden, NJ 08102   EMail: richard.winslow@l-3com.comCarlson & Winslow           Standards Track                     [Page 9]

RFC 3772                  PPP Vendor Protocol                   May 200413.  Full Copyright Statement   Copyright (C) The Internet Society (2004).  This document is subject   to the rights, licenses and restrictions contained inBCP 78, and   except as set forth therein, the authors retain all their rights.   This document and the information contained herein are provided on an   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET   ENGINEERING TASK FORCE DISCLAIM 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.Intellectual Property   The IETF takes no position regarding the validity or scope of any   Intellectual Property Rights or other rights that might be claimed to   pertain to the implementation or use of the technology described in   this document or the extent to which any license under such rights   might or might not be available; nor does it represent that it has   made any independent effort to identify any such rights.  Information   on the procedures with respect to rights in RFC documents can be   found inBCP 78 andBCP 79.   Copies of IPR disclosures made to the IETF Secretariat and any   assurances of licenses to be made available, or the result of an   attempt made to obtain a general license or permission for the use of   such proprietary rights by implementers or users of this   specification can be obtained from the IETF on-line IPR repository athttp://www.ietf.org/ipr.   The IETF invites any interested party to bring to its attention any   copyrights, patents or patent applications, or other proprietary   rights that may cover technology that may be required to implement   this standard.  Please address the information to the IETF at ietf-   ipr@ietf.org.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Carlson & Winslow           Standards Track                    [Page 10]