Browse Prior Art Database

PPP Vendor Extensions (RFC2153)

IP.com Disclosure Number: IPCOM000002710D
Original Publication Date: 1997-May-01
Included in the Prior Art Database: 2019-Feb-15
Document File: 8 page(s) / 8K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

W. Simpson: AUTHOR

Related Documents

10.17487/RFC2153: DOI

Abstract

The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols. This document provides information for the Internet community. It does not specify an Internet standard of any kind.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 36% of the total text.

Network Working Group W. Simpson Request for Comments: 2153 DayDreamer Updates: RFCs 1661, 1962 May 1997 Category: Informational

PPP Vendor Extensions

Status of this Memo

This document provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Abstract

The Point-to-Point Protocol (PPP) [1] provides a standard method for transporting multi-protocol datagrams over point-to-point links. PPP defines an extensible Link Control Protocol (LCP) for establishing, configuring, and testing the data-link connection; and a family of Network Control Protocols (NCPs) for establishing and configuring different network-layer protocols.

This document defines a general mechanism for proprietary vendor extensions.

Simpson Informational [Page i]

RFC 2153 PPP vendor extensions May 1997

Table of Contents

1. Control Packets ....................................... 1 1.1 Vendor Specific Packet .......................... 1

2. Configuration Options ................................. 3 2.1 Vendor-Specific Option .......................... 3

3. Organizationally Unique Identifiers ................... 4

SECURITY CONSIDERATIONS ...................................... 5

REFERENCES ................................................... 5

CONTACTS ..................................................... 6

Simpson Informational [Page ii]

RFC 2153 PPP vendor extensions May 1997

1. Control Packets

The Packet format and basic facilities are already defined for LCP [1] and related NCPs.

Up-to-date values of the LCP Code field are specified in the most recent "Assigned Numbers" [2]. This document concerns the following values:

0 Vendor Specific

1.1. Vendor Specific Packet

Description

Some implementors might not need nor want to publish their proprietary algorithms and attributes. This mechanism is available to specify these without encumbering the IANA with proprietary number requests.

Vendor Specific packets MAY be sent at any time, including before LCP has reached the Opened state.

The sender transmits a LCP or NCP packet with the Code field set to 0 (Vendor Specific), the Identifier field set, the local Magic-Number (if any) inserted, the OUI and Kind fields set, and the Value(s) field filled with any desired data, but not exceeding the default MRU minus twelve.

Receipt of a Vendor Specific packet causes the RXR or RUC event. The response to the Vendor Specific packet is vender specific.

Receipt of a Code-Reject for the packet SHOULD generate the RXJ+ (permitted) event.

Rationale:

This is defined as general feature of all PPP Control Protocols, to avoid future conflicts in vendor secretly self-assigned Code numbers.

A summary of the Vendor Specific packet format is shown below. The fields are transmitted from left to right.

Simpson Informational [Page 1]

RFC 2153 PPP vendor extensions May 1997

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+...

Processing...
Loading...