1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
|
<pre>Network Working Group W. Simpson
Request for Comments: 2153 DayDreamer
Updates: RFCs <a href="./rfc1661">1661</a>, <a href="./rfc1962">1962</a> May 1997
Category: Informational
<span class="h1">PPP Vendor Extensions</span>
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) [<a href="#ref-1" title=""The Point-to-Point Protocol (PPP)"">1</a>] 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.
<span class="grey">Simpson Informational [Page i]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-ii" ></span>
<span class="grey"><a href="./rfc2153">RFC 2153</a> PPP vendor extensions May 1997</span>
Table of Contents
<a href="#section-1">1</a>. Control Packets ....................................... <a href="#page-1">1</a>
<a href="#section-1.1">1.1</a> Vendor Specific Packet .......................... <a href="#page-1">1</a>
<a href="#section-2">2</a>. Configuration Options ................................. <a href="#page-3">3</a>
<a href="#section-2.1">2.1</a> Vendor-Specific Option .......................... <a href="#page-3">3</a>
<a href="#section-3">3</a>. Organizationally Unique Identifiers ................... <a href="#page-4">4</a>
SECURITY CONSIDERATIONS ...................................... <a href="#page-5">5</a>
REFERENCES ................................................... <a href="#page-5">5</a>
CONTACTS ..................................................... <a href="#page-6">6</a>
<span class="grey">Simpson Informational [Page ii]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-1" ></span>
<span class="grey"><a href="./rfc2153">RFC 2153</a> PPP vendor extensions May 1997</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Control Packets</span>
The Packet format and basic facilities are already defined for LCP
[<a href="#ref-1" title=""The Point-to-Point Protocol (PPP)"">1</a>] and related NCPs.
Up-to-date values of the LCP Code field are specified in the most
recent "Assigned Numbers" [<a href="#ref-2" title=""Assigned Numbers"">2</a>]. This document concerns the following
values:
0 Vendor Specific
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Vendor Specific Packet</span>
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.
<span class="grey">Simpson Informational [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc2153">RFC 2153</a> PPP vendor extensions May 1997</span>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Kind |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value(s) ...
+-+-+-+-+-+-+-+-+
Code
0 for Vendor Specific
Identifier
The Identifier field MUST be changed for each Vendor Specific
packet sent.
Length
>= 12
When the Length is twelve, no Value(s) field is present.
Magic-Number
The Magic-Number field is four octets and aids in detecting links
that are in the looped-back condition. Until the Magic-Number
Configuration Option has been successfully negotiated, the Magic-
Number MUST be transmitted as zero. See the Magic-Number
Configuration Option for further explanation.
OUI
three octets. The vendor's Organizationally Unique Identifier.
The bits within the octet are in canonical order, and the most
significant octet is transmitted first.
Kind
one octet. Indicates a sub-type for the OUI. There is no
standardization for this field. Each OUI implements its own
values.
The Kind field may be extended by the vendor to include zero or
more octets of the Value(s) field.
<span class="grey">Simpson Informational [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc2153">RFC 2153</a> PPP vendor extensions May 1997</span>
Value(s)
Zero or more octets. The details are implementation specific.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Configuration Options</span>
The Configuration Option format and basic options are already defined
for LCP [<a href="#ref-1" title=""The Point-to-Point Protocol (PPP)"">1</a>].
Up-to-date values of the LCP Option Type field are specified in the
most recent "Assigned Numbers" [<a href="#ref-2" title=""Assigned Numbers"">2</a>]. This document concerns the
following values:
0 Vendor-Specific
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Vendor-Specific Option</span>
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.
Before accepting this option, the implementation must verify that
the Organizationally Unique Identifier and Kind specify a known
mechanism, and that any vendor specific negotiation values are
fully understood.
Rationale:
This is defined as general feature of all PPP Control Protocols,
to avoid future conflicts in vendor secretly self-assigned Type
numbers.
A summary of the Vendor-Specific Configuration Option format is shown
below. The fields are transmitted from left to right.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | OUI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Kind | Value(s) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
<span class="grey">Simpson Informational [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc2153">RFC 2153</a> PPP vendor extensions May 1997</span>
Type
0
Length
>= 6
When the Length is six, no Value(s) field is present.
OUI
three octets. The vendor's Organizationally Unique Identifier.
The bits within the octet are in canonical order, and the most
significant octet is transmitted first.
Kind
one octet. Indicates a sub-type for the OUI. There is no
standardization for this field. Each OUI implements its own
values.
The Kind field may be extended by the vendor to include zero or
more octets of the Value(s) field.
Value(s)
Zero or more octets. The details are implementation specific.
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Organizationally Unique Identifiers</span>
The three-octet Organizationally Unique Identifier (OUI) identifies
an organization that administers the meaning of the message. This
OUI is based on IEEE 802 vendor assignments.
IEEE contact details for assignment of an OUI are given in [RFC-
1700]. Vendors that desire to use their IEEE 802 OUI for PPP Vendor
Extensions should also register the OUI with IANA.
In the alternative, a vendor that does not otherwise need an IEEE
assigned OUI can request a PPP specific OUI from IANA. This OUI
shall be assigned from the 'CF0000' series. This has both the
"locally-assigned" and "broadcast/multicast" bits set to 1; that is,
the least significant two bits of the most significant octet are both
set to 1.
Appearance in memory, bits transmitted right-to-left within octets,
<span class="grey">Simpson Informational [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc2153">RFC 2153</a> PPP vendor extensions May 1997</span>
octets transmitted left-to-right:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 1 1 1 1|x x x x x x x x|x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Multicast
Local
Rationale:
This is defined for vendors that are not able to use IEEE
assignments, such as software-only vendors.
It is not clear how the IEEE assigns blocks. In some instances,
the "locally-assigned" bit is known to have been used.
However, multicast has no meaning in PPP. Therefore, an IEEE
assigned OUI would have the multicast bit cleared to 0.
The 'CF0000' series was arbitrarily chosen to match the PPP NLPID
'CF', as a matter of mnemonic convenience.
Security Considerations
Security issues are not discussed in this document.
References
[<a id="ref-1">1</a>] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, <a href="./rfc1661">RFC 1661</a>, DayDreamer, July 1994.
[<a id="ref-2">2</a>] Reynolds, J.K., Postel, J.B., "Assigned Numbers", <a href="./rfc1700">RFC-1700</a>,
July 1992.
<span class="grey">Simpson Informational [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc2153">RFC 2153</a> PPP vendor extensions May 1997</span>
Contacts
Comments about this document should be discussed on the ietf-
ppp@merit.edu mailing list.
This document was reviewed by the Point-to-Point Protocol Working
Group of the Internet Engineering Task Force (IETF). The working
group can be contacted via the current chair:
Karl Fox
Ascend Communications
655 Metro Place South, Suite 379
Dublin, Ohio 43017
karl@Ascend.com
Questions about this document can also be directed to:
William Allen Simpson
DayDreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
wsimpson@UMich.edu
wsimpson@GreenDragon.com (preferred)
Simpson Informational [Page 6]
</pre>
|
