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
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
|
<pre>Network Working Group SNMPv2 Working Group
Request for Comments: 1906 J. Case
Obsoletes: <a href="./rfc1449">1449</a> SNMP Research, Inc.
Category: Standards Track K. McCloghrie
Cisco Systems, Inc.
M. Rose
Dover Beach Consulting, Inc.
S. Waldbusser
International Network Services
January 1996
<span class="h1">Transport Mappings for Version 2 of the</span>
<span class="h1">Simple Network Management Protocol (SNMPv2)</span>
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.
Table of Contents
<a href="#section-1">1</a>. Introduction ................................................ <a href="#page-2">2</a>
<a href="#section-1.1">1.1</a> A Note on Terminology ...................................... <a href="#page-2">2</a>
<a href="#section-2">2</a>. Definitions ................................................. <a href="#page-3">3</a>
<a href="#section-3">3</a>. SNMPv2 over UDP ............................................. <a href="#page-5">5</a>
<a href="#section-3.1">3.1</a> Serialization .............................................. <a href="#page-5">5</a>
<a href="#section-3.2">3.2</a> Well-known Values .......................................... <a href="#page-5">5</a>
<a href="#section-4">4</a>. SNMPv2 over OSI ............................................. <a href="#page-6">6</a>
<a href="#section-4.1">4.1</a> Serialization .............................................. <a href="#page-6">6</a>
<a href="#section-4.2">4.2</a> Well-known Values .......................................... <a href="#page-6">6</a>
<a href="#section-5">5</a>. SNMPv2 over DDP ............................................. <a href="#page-6">6</a>
<a href="#section-5.1">5.1</a> Serialization .............................................. <a href="#page-6">6</a>
<a href="#section-5.2">5.2</a> Well-known Values .......................................... <a href="#page-6">6</a>
<a href="#section-5.3">5.3</a> Discussion of AppleTalk Addressing ......................... <a href="#page-7">7</a>
<a href="#section-5.3.1">5.3.1</a> How to Acquire NBP names ................................. <a href="#page-8">8</a>
<a href="#section-5.3.2">5.3.2</a> When to Turn NBP names into DDP addresses ................ <a href="#page-8">8</a>
<a href="#section-5.3.3">5.3.3</a> How to Turn NBP names into DDP addresses ................. <a href="#page-8">8</a>
<a href="#section-5.3.4">5.3.4</a> What if NBP is broken .................................... <a href="#page-9">9</a>
<a href="#section-6">6</a>. SNMPv2 over IPX ............................................. <a href="#page-9">9</a>
<a href="#section-6.1">6.1</a> Serialization .............................................. <a href="#page-9">9</a>
<a href="#section-6.2">6.2</a> Well-known Values .......................................... <a href="#page-9">9</a>
<a href="#section-7">7</a>. Proxy to SNMPv1 ............................................. <a href="#page-10">10</a>
<a href="#section-8">8</a>. Serialization using the Basic Encoding Rules ................ <a href="#page-10">10</a>
<a href="#section-8.1">8.1</a> Usage Example .............................................. <a href="#page-11">11</a>
<span class="grey">SNMPv2 Working Group Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc1906">RFC 1906</a> Transport Mappings for SNMPv2 January 1996</span>
<a href="#section-9">9</a>. Security Considerations ..................................... <a href="#page-11">11</a>
<a href="#section-10">10</a>. Editor's Address ........................................... <a href="#page-12">12</a>
<a href="#section-11">11</a>. Acknowledgements ........................................... <a href="#page-12">12</a>
<a href="#section-12">12</a>. References ................................................. <a href="#page-13">13</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
A management system contains: several (potentially many) nodes, each
with a processing entity, termed an agent, which has access to
management instrumentation; at least one management station; and, a
management protocol, used to convey management information between
the agents and management stations. Operations of the protocol are
carried out under an administrative framework which defines
authentication, authorization, access control, and privacy policies.
Management stations execute management applications which monitor and
control managed elements. Managed elements are devices such as
hosts, routers, terminal servers, etc., which are monitored and
controlled via access to their management information.
The management protocol, version 2 of the Simple Network Management
Protocol [<a href="#ref-1" title=""Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)"">1</a>], may be used over a variety of protocol suites. It is
the purpose of this document to define how the SNMPv2 maps onto an
initial set of transport domains. Other mappings may be defined in
the future.
Although several mappings are defined, the mapping onto UDP is the
preferred mapping. As such, to provide for the greatest level of
interoperability, systems which choose to deploy other mappings
should also provide for proxy service to the UDP mapping.
<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. A Note on Terminology</span>
For the purpose of exposition, the original Internet-standard Network
Management Framework, as described in RFCs 1155 (STD 16), 1157 (STD
15), and 1212 (STD 16), is termed the SNMP version 1 framework
(SNMPv1). The current framework is termed the SNMP version 2
framework (SNMPv2).
<span class="grey">SNMPv2 Working Group Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc1906">RFC 1906</a> Transport Mappings for SNMPv2 January 1996</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Definitions</span>
SNMPv2-TM DEFINITIONS ::= BEGIN
IMPORTS
OBJECT-IDENTITY, snmpDomains, snmpProxys
FROM SNMPv2-SMI
TEXTUAL-CONVENTION
FROM SNMPv2-TC;
-- SNMPv2 over UDP over IPv4
snmpUDPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMPv2 over UDP transport domain. The corresponding
transport address is of type SnmpUDPAddress."
::= { snmpDomains 1 }
SnmpUDPAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d.1d.1d.1d/2d"
STATUS current
DESCRIPTION
"Represents a UDP address:
octets contents encoding
1-4 IP-address network-byte order
5-6 UDP-port network-byte order
"
SYNTAX OCTET STRING (SIZE (6))
-- SNMPv2 over OSI
snmpCLNSDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMPv2 over CLNS transport domain. The corresponding
transport address is of type SnmpOSIAddress."
::= { snmpDomains 2 }
snmpCONSDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMPv2 over CONS transport domain. The corresponding
transport address is of type SnmpOSIAddress."
::= { snmpDomains 3 }
<span class="grey">SNMPv2 Working Group Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc1906">RFC 1906</a> Transport Mappings for SNMPv2 January 1996</span>
SnmpOSIAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "*1x:/1x:"
STATUS current
DESCRIPTION
"Represents an OSI transport-address:
octets contents encoding
1 length of NSAP 'n' as an unsigned-integer
(either 0 or from 3 to 20)
2..(n+1) NSAP concrete binary representation
(n+2)..m TSEL string of (up to 64) octets
"
SYNTAX OCTET STRING (SIZE (1 | 4..85))
-- SNMPv2 over DDP
snmpDDPDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMPv2 over DDP transport domain. The corresponding
transport address is of type SnmpNBPAddress."
::= { snmpDomains 4 }
SnmpNBPAddress ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"Represents an NBP name:
octets contents encoding
1 length of object 'n' as an unsigned integer
2..(n+1) object string of (up to 32) octets
n+2 length of type 'p' as an unsigned integer
(n+3)..(n+2+p) type string of (up to 32) octets
n+3+p length of zone 'q' as an unsigned integer
(n+4+p)..(n+3+p+q) zone string of (up to 32) octets
For comparison purposes, strings are case-insensitive All
strings may contain any octet other than 255 (hex ff)."
SYNTAX OCTET STRING (SIZE (3..99))
-- SNMPv2 over IPX
snmpIPXDomain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The SNMPv2 over IPX transport domain. The corresponding
<span class="grey">SNMPv2 Working Group Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc1906">RFC 1906</a> Transport Mappings for SNMPv2 January 1996</span>
transport address is of type SnmpIPXAddress."
::= { snmpDomains 5 }
SnmpIPXAddress ::= TEXTUAL-CONVENTION
DISPLAY-HINT "4x.1x:1x:1x:1x:1x:1x.2d"
STATUS current
DESCRIPTION
"Represents an IPX address:
octets contents encoding
1-4 network-number network-byte order
5-10 physical-address network-byte order
11-12 socket-number network-byte order
"
SYNTAX OCTET STRING (SIZE (12))
-- for proxy to SNMPv1 (<a href="./rfc1157">RFC 1157</a>)
rfc1157Proxy OBJECT IDENTIFIER ::= { snmpProxys 1 }
rfc1157Domain OBJECT-IDENTITY
STATUS current
DESCRIPTION
"The transport domain for SNMPv1 over UDP. The
corresponding transport address is of type SnmpUDPAddress."
::= { rfc1157Proxy 1 }
-- ::= { rfc1157Proxy 2 } this OID is obsolete
END
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. SNMPv2 over UDP</span>
This is the preferred transport mapping.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Serialization</span>
Each instance of a message is serialized (i.e., encoded according to
the convention of [<a href="#ref-1" title=""Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)"">1</a>]) onto a single UDP[2] datagram, using the
algorithm specified in <a href="#section-8">Section 8</a>.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. Well-known Values</span>
It is suggested that administrators configure their SNMPv2 entities
acting in an agent role to listen on UDP port 161. Further, it is
suggested that notification sinks be configured to listen on UDP port
<span class="grey">SNMPv2 Working Group Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc1906">RFC 1906</a> Transport Mappings for SNMPv2 January 1996</span>
162.
When an SNMPv2 entity uses this transport mapping, it must be capable
of accepting messages that are at least 484 octets in size.
Implementation of larger values is encouraged whenever possible.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. SNMPv2 over OSI</span>
This is an optional transport mapping.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Serialization</span>
Each instance of a message is serialized onto a single TSDU [<a href="#ref-3" title="(June">3</a>,<a href="#ref-4" title="(December">4</a>] for
the OSI Connectionless-mode Transport Service (CLTS), using the
algorithm specified in <a href="#section-8">Section 8</a>.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Well-known Values</span>
It is suggested that administrators configure their SNMPv2 entities
acting in an agent role to listen on transport selector "snmp-l"
(which consists of six ASCII characters), when using a CL-mode
network service to realize the CLTS. Further, it is suggested that
notification sinks be configured to listen on transport selector
"snmpt-l" (which consists of seven ASCII characters, six letters and
a hyphen) when using a CL-mode network service to realize the CLTS.
Similarly, when using a CO-mode network service to realize the CLTS,
the suggested transport selectors are "snmp-o" and "snmpt-o", for
agent and notification sink, respectively.
When an SNMPv2 entity uses this transport mapping, it must be capable
of accepting messages that are at least 484 octets in size.
Implementation of larger values is encouraged whenever possible.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. SNMPv2 over DDP</span>
This is an optional transport mapping.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. Serialization</span>
Each instance of a message is serialized onto a single DDP datagram
[<a href="#ref-5" title="A. Oppenheimer">5</a>], using the algorithm specified in <a href="#section-8">Section 8</a>.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. Well-known Values</span>
SNMPv2 messages are sent using DDP protocol type 8. SNMPv2 entities
acting in an agent role listens on DDP socket number 8, whilst
notification sinks listen on DDP socket number 9.
<span class="grey">SNMPv2 Working Group Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc1906">RFC 1906</a> Transport Mappings for SNMPv2 January 1996</span>
Administrators must configure their SNMPv2 entities acting in an
agent role to use NBP type "SNMP Agent" (which consists of ten ASCII
characters), whilst notification sinks must be configured to use NBP
type "SNMP Trap Handler" (which consists of seventeen ASCII
characters).
The NBP name for agents and notification sinks should be stable - NBP
names should not change any more often than the IP address of a
typical TCP/IP node. It is suggested that the NBP name be stored in
some form of stable storage.
When an SNMPv2 entity uses this transport mapping, it must be capable
of accepting messages that are at least 484 octets in size.
Implementation of larger values is encouraged whenever possible.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. Discussion of AppleTalk Addressing</span>
The AppleTalk protocol suite has certain features not manifest in the
TCP/IP suite. AppleTalk's naming strategy and the dynamic nature of
address assignment can cause problems for SNMPv2 entities that wish
to manage AppleTalk networks. TCP/IP nodes have an associated IP
address which distinguishes each from the other. In contrast,
AppleTalk nodes generally have no such characteristic. The network-
level address, while often relatively stable, can change at every
reboot (or more frequently).
Thus, when SNMPv2 is mapped over DDP, nodes are identified by a
"name", rather than by an "address". Hence, all AppleTalk nodes that
implement this mapping are required to respond to NBP lookups and
confirms (e.g., implement the NBP protocol stub), which guarantees
that a mapping from NBP name to DDP address will be possible.
In determining the SNMP identity to register for an SNMPv2 entity, it
is suggested that the SNMP identity be a name which is associated
with other network services offered by the machine.
NBP lookups, which are used to map NBP names into DDP addresses, can
cause large amounts of network traffic as well as consume CPU
resources. It is also the case that the ability to perform an NBP
lookup is sensitive to certain network disruptions (such as zone
table inconsistencies) which would not prevent direct AppleTalk
communications between two SNMPv2 entities.
Thus, it is recommended that NBP lookups be used infrequently,
primarily to create a cache of name-to-address mappings. These
cached mappings should then be used for any further SNMP traffic. It
is recommended that SNMPv2 entities acting in a manager role should
maintain this cache between reboots. This caching can help minimize
<span class="grey">SNMPv2 Working Group Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc1906">RFC 1906</a> Transport Mappings for SNMPv2 January 1996</span>
network traffic, reduce CPU load on the network, and allow for (some
amount of) network trouble shooting when the basic name-to-address
translation mechanism is broken.
<span class="h4"><a class="selflink" id="section-5.3.1" href="#section-5.3.1">5.3.1</a>. How to Acquire NBP names</span>
An SNMPv2 entity acting in a manager role may have a pre-configured
list of names of "known" SNMPv2 entities acting in an agent role.
Similarly, an SNMPv2 entity acting in a manager role might interact
with an operator. Finally, an SNMPv2 entity acting in a manager role
might communicate with all SNMPv2 entities acting in an agent role in
a set of zones or networks.
<span class="h4"><a class="selflink" id="section-5.3.2" href="#section-5.3.2">5.3.2</a>. When to Turn NBP names into DDP addresses</span>
When an SNMPv2 entity uses a cache entry to address an SNMP packet,
it should attempt to confirm the validity mapping, if the mapping
hasn't been confirmed within the last T1 seconds. This cache entry
lifetime, T1, has a minimum, default value of 60 seconds, and should
be configurable.
An SNMPv2 entity acting in a manager role may decide to prime its
cache of names prior to actually communicating with another SNMPv2
entity. In general, it is expected that such an entity may want to
keep certain mappings "more current" than other mappings, e.g., those
nodes which represent the network infrastructure (e.g., routers) may
be deemed "more important".
Note that an SNMPv2 entity acting in a manager role should not prime
its entire cache upon initialization - rather, it should attempt
resolutions over an extended period of time (perhaps in some pre-
determined or configured priority order). Each of these resolutions
might, in fact, be a wildcard lookup in a given zone.
An SNMPv2 entity acting in an agent role must never prime its cache.
Such an entity should do NBP lookups (or confirms) only when it needs
to send an SNMP trap. When generating a response, such an entity
does not need to confirm a cache entry.
<span class="h4"><a class="selflink" id="section-5.3.3" href="#section-5.3.3">5.3.3</a>. How to Turn NBP names into DDP addresses</span>
If the only piece of information available is the NBP name, then an
NBP lookup should be performed to turn that name into a DDP address.
However, if there is a piece of stale information, it can be used as
a hint to perform an NBP confirm (which sends a unicast to the
network address which is presumed to be the target of the name
lookup) to see if the stale information is, in fact, still valid.
<span class="grey">SNMPv2 Working Group Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc1906">RFC 1906</a> Transport Mappings for SNMPv2 January 1996</span>
An NBP name to DDP address mapping can also be confirmed implicitly
using only SNMP transactions. For example, an SNMPv2 entity acting
in a manager role issuing a retrieval operation could also retrieve
the relevant objects from the NBP group [<a href="#ref-6" title=""AppleTalk Management Information Base"">6</a>] for the SNMPv2 entity
acting in an agent role. This information can then be correlated
with the source DDP address of the response.
<span class="h4"><a class="selflink" id="section-5.3.4" href="#section-5.3.4">5.3.4</a>. What if NBP is broken</span>
Under some circumstances, there may be connectivity between two
SNMPv2 entities, but the NBP mapping machinery may be broken, e.g.,
o the NBP FwdReq (forward NBP lookup onto local attached network)
mechanism might be broken at a router on the other entity's
network; or,
o the NBP BrRq (NBP broadcast request) mechanism might be broken
at a router on the entity's own network; or,
o NBP might be broken on the other entity's node.
An SNMPv2 entity acting in a manager role which is dedicated to
AppleTalk management might choose to alleviate some of these failures
by directly implementing the router portion of NBP. For example,
such an entity might already know all the zones on the AppleTalk
internet and the networks on which each zone appears. Given an NBP
lookup which fails, the entity could send an NBP FwdReq to the
network in which the agent was last located. If that failed, the
station could then send an NBP LkUp (NBP lookup packet) as a directed
(DDP) multicast to each network number on that network. Of the above
(single) failures, this combined approach will solve the case where
either the local router's BrRq-to-FwdReq mechanism is broken or the
remote router's FwdReq-to-LkUp mechanism is broken.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. SNMPv2 over IPX</span>
This is an optional transport mapping.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. Serialization</span>
Each instance of a message is serialized onto a single IPX datagram
[<a href="#ref-7" title="(June">7</a>], using the algorithm specified in <a href="#section-8">Section 8</a>.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. Well-known Values</span>
SNMPv2 messages are sent using IPX packet type 4 (i.e., Packet
Exchange Protocol).
<span class="grey">SNMPv2 Working Group Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc1906">RFC 1906</a> Transport Mappings for SNMPv2 January 1996</span>
It is suggested that administrators configure their SNMPv2 entities
acting in an agent role to listen on IPX socket 36879 (900f
hexadecimal). Further, it is suggested that notification sinks be
configured to listen on IPX socket 36880 (9010 hexadecimal)
When an SNMPv2 entity uses this transport mapping, it must be capable
of accepting messages that are at least 546 octets in size.
Implementation of larger values is encouraged whenever possible.
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Proxy to SNMPv1</span>
In order to provide proxy to SNMPv1 [<a href="#ref-8" title=""Simple Network Management Protocol"">8</a>], it may be useful to define a
transport domain, rfc1157Domain, which indicates the transport
mapping for SNMP messages as defined in <a href="./rfc1157">RFC 1157</a>. Section 3.1 of [<a href="#ref-9" title=""Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework"">9</a>]
specifies the behavior of the proxy agent.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Serialization using the Basic Encoding Rules</span>
When the Basic Encoding Rules [<a href="#ref-10" title="International Organization for Standardization. International Standard 8825">10</a>] are used for serialization:
(1) When encoding the length field, only the definite form is used; use
of the indefinite form encoding is prohibited. Note that when
using the definite-long form, it is permissible to use more than
the minimum number of length octets necessary to encode the length
field.
(2) When encoding the value field, the primitive form shall be used for
all simple types, i.e., INTEGER, OCTET STRING, and OBJECT
IDENTIFIER (either IMPLICIT or explicit). The constructed form of
encoding shall be used only for structured types, i.e., a SEQUENCE
or an IMPLICIT SEQUENCE.
(3) When encoding an object whose syntax is described using the BITS
construct, the value is encoded as an OCTET STRING, in which all
the named bits in (the definition of) the bitstring, commencing
with the first bit and proceeding to the last bit, are placed in
bits 8 to 1 of the first octet, followed by bits 8 to 1 of each
subsequent octet in turn, followed by as many bits as are needed of
the final subsequent octet, commencing with bit 8. Remaining bits,
if any, of the final octet are set to zero on generation and
ignored on receipt.
These restrictions apply to all aspects of ASN.1 encoding, including
the message wrappers, protocol data units, and the data objects they
contain.
<span class="grey">SNMPv2 Working Group Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc1906">RFC 1906</a> Transport Mappings for SNMPv2 January 1996</span>
<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Usage Example</span>
As an example of applying the Basic Encoding Rules, suppose one
wanted to encode an instance of the GetBulkRequest-PDU [<a href="#ref-1" title=""Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)"">1</a>]:
[<a id="ref-5">5</a>] IMPLICIT SEQUENCE {
request-id 1414684022,
non-repeaters 1,
max-repetitions 2,
variable-bindings {
{ name sysUpTime,
value { unspecified NULL } },
{ name ipNetToMediaPhysAddress,
value { unspecified NULL } },
{ name ipNetToMediaType,
value { unspecified NULL } }
}
}
Applying the BER, this would be encoded (in hexadecimal) as:
[<a id="ref-5">5</a>] IMPLICIT SEQUENCE a5 82 00 39
INTEGER 02 04 52 54 5d 76
INTEGER 02 01 01
INTEGER 02 01 02
SEQUENCE 30 2b
SEQUENCE 30 0b
OBJECT IDENTIFIER 06 07 2b 06 01 02 01 01 03
NULL 05 00
SEQUENCE 30 0d
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 02
NULL 05 00
SEQUENCE 30 0d
OBJECT IDENTIFIER 06 09 2b 06 01 02 01 04 16 01 04
NULL 05 00
Note that the initial SEQUENCE is not encoded using the minimum
number of length octets. (The first octet of the length, 82,
indicates that the length of the content is encoded in the next two
octets.)
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
Security issues are not discussed in this memo.
<span class="grey">SNMPv2 Working Group Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc1906">RFC 1906</a> Transport Mappings for SNMPv2 January 1996</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Editor's Address</span>
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
US
Phone: +1 408 526 5260
EMail: kzm@cisco.com
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Acknowledgements</span>
This document is the result of significant work by the four major
contributors:
Jeffrey D. Case (SNMP Research, case@snmp.com)
Keith McCloghrie (Cisco Systems, kzm@cisco.com)
Marshall T. Rose (Dover Beach Consulting, mrose@dbc.mtview.ca.us)
Steven Waldbusser (International Network Services, stevew@uni.ins.com)
In addition, the contributions of the SNMPv2 Working Group are
acknowledged. In particular, a special thanks is extended for the
contributions of:
Alexander I. Alten (Novell)
Dave Arneson (Cabletron)
Uri Blumenthal (IBM)
Doug Book (Chipcom)
Kim Curran (Bell-Northern Research)
Jim Galvin (Trusted Information Systems)
Maria Greene (Ascom Timeplex)
Iain Hanson (Digital)
Dave Harrington (Cabletron)
Nguyen Hien (IBM)
Jeff Johnson (Cisco Systems)
Michael Kornegay (Object Quest)
Deirdre Kostick (AT&T Bell Labs)
David Levi (SNMP Research)
Daniel Mahoney (Cabletron)
Bob Natale (ACE*COMM)
Brian O'Keefe (Hewlett Packard)
Andrew Pearson (SNMP Research)
Dave Perkins (Peer Networks)
Randy Presuhn (Peer Networks)
Aleksey Romanov (Quality Quorum)
Shawn Routhier (Epilogue)
Jon Saperia (BGS Systems)
<span class="grey">SNMPv2 Working Group Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc1906">RFC 1906</a> Transport Mappings for SNMPv2 January 1996</span>
Bob Stewart (Cisco Systems, bstewart@cisco.com), chair
Kaj Tesink (Bellcore)
Glenn Waters (Bell-Northern Research)
Bert Wijnen (IBM)
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. References</span>
[<a id="ref-1">1</a>] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Protocol Operations for Version 2 of the Simple
Network Management Protocol (SNMPv2)", <a href="./rfc1905">RFC 1905</a>, January 1996.
[<a id="ref-2">2</a>] Postel, J., "User Datagram Protocol", STD 6, <a href="./rfc768">RFC 768</a>,
USC/Information Sciences Institute, August 1980.
[<a id="ref-3">3</a>] Information processing systems - Open Systems Interconnection -
Transport Service Definition, International Organization for
Standardization. International Standard 8072, (June, 1986).
[<a id="ref-4">4</a>] Information processing systems - Open Systems Interconnection -
Transport Service Definition - Addendum 1: Connectionless-mode
Transmission, International Organization for Standardization.
International Standard 8072/AD 1, (December, 1986).
[<a id="ref-5">5</a>] G. Sidhu, R. Andrews, A. Oppenheimer, Inside AppleTalk (second
edition). Addison-Wesley, 1990.
[<a id="ref-6">6</a>] Waldbusser, S., "AppleTalk Management Information Base", <a href="./rfc1243">RFC 1243</a>,
Carnegie Mellon University, July 1991.
[<a id="ref-7">7</a>] Network System Technical Interface Overview. Novell, Inc, (June,
1989).
[<a id="ref-8">8</a>] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network
Management Protocol", STD 15, <a href="./rfc1157">RFC 1157</a>, SNMP Research, Performance
Systems International, MIT Laboratory for Computer Science, May
1990.
[<a id="ref-9">9</a>] SNMPv2 Working Group, Case, J., McCloghrie, K., Rose, M., and
S. Waldbusser, "Coexistence between Version 1 and Version 2 of the
Internet-standard Network Management Framework", <a href="./rfc1908">RFC 1908</a>,
January 1996.
[<a id="ref-10">10</a>] Information processing systems - Open Systems Interconnection -
Specification of Basic Encoding Rules for Abstract Syntax Notation
One (ASN.1), International Organization for Standardization.
International Standard 8825, December 1987.
SNMPv2 Working Group Standards Track [Page 13]
</pre>
|
