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
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
|
Network Working Group D. Thaler
Request for Comments: 4087 Microsoft
Obsoletes: 2667 June 2005
Category: Standards Track
IP Tunnel MIB
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.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This memo defines a Management Information Base (MIB) module for use
with network management protocols in the Internet community. In
particular, it describes managed objects used for managing tunnels of
any type over IPv4 and IPv6 networks. Extension MIB modules may be
designed for managing protocol-specific objects. Likewise, extension
MIB modules may be designed for managing security-specific objects.
This MIB module does not support tunnels over non-IP networks.
Management of such tunnels may be supported by other MIB modules.
This memo obsoletes RFC 2667.
1. Introduction
Over the past several years, there has been a number of "tunneling"
protocols specified by the IETF (see [RFC1241] for an early
discussion of the model and examples). This document describes a
Management Information Base (MIB) module used for managing tunnels of
any type over IPv4 and IPv6 networks, including Generic Routing
Encapsulation (GRE) [RFC1701,RFC1702], IP-in-IP [RFC2003], Minimal
Encapsulation [RFC2004], Layer 2 Tunneling Protocol (L2TP) [RFC2661],
Point-to-Point Tunneling Protocol (PPTP) [RFC2637], Layer 2
Forwarding (L2F) [RFC2341], UDP (e.g., [RFC1234]), Ascend Tunnel
Management Protocol (ATMP) [RFC2107], and IPv6-in-IPv4 [RFC2893]
tunnels, among others.
Thaler Standards Track [Page 1]
^L
RFC 4087 IP Tunnel MIB June 2005
Extension MIB modules may be designed for managing protocol-specific
objects. Likewise, extension MIB modules may be designed for
managing security-specific objects (e.g., IPsec [RFC2401]), and
traffic conditioner [RFC2474] objects.
2. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
3. Overview
This MIB module contains two current tables and one deprecated table.
The current tables are:
o the Tunnel Interface Table, containing information on the tunnels
known to a router; and
o the Tunnel Inet Config Table, which can be used for dynamic
creation of tunnels, and also provides a mapping from endpoint
addresses to the current interface index value.
The version of this MIB module that appeared in RFC 2667 contained
the Tunnel Config Table, which mapped IPv4 endpoint addresses to
interface indexes. It is now deprecated in favor of the Tunnel Inet
Config Table.
3.1. Relationship to the Interfaces MIB
This section clarifies the relationship of this MIB module to the
Interfaces MIB [RFC2863]. Several areas of correlation are addressed
in the following subsections. The implementor is referred to the
Interfaces MIB document in order to understand the general intent of
these areas.
Thaler Standards Track [Page 2]
^L
RFC 4087 IP Tunnel MIB June 2005
3.1.1. Layering Model
Each logical interface (physical or virtual) has an ifEntry in the
Interfaces MIB [RFC2863]. Tunnels are handled by creating a logical
interface (ifEntry) for each tunnel. These are then correlated,
using the ifStack table of the Interfaces MIB, to those interfaces on
which the local IPv4 or IPv6 addresses of the tunnels are configured.
The basic model, therefore, looks something like this (for example):
| | | | | |
+--+ +---+ +--+ +---+ | |
|IP-in-IP| | GRE | | |
| tunnel | | tunnel | | |
+--+ +---+ +--+ +---+ | |
| | | | | | <== attachment to underlying
+--+ +---------+ +----------+ +--+ interfaces, to be provided
| Physical interface | by ifStack table
+--------------------------------+
3.1.2. ifRcvAddressTable
The ifRcvAddressTable usage can be defined in the MIB modules
defining the encapsulation below the network layer, and holds the
local IP addresses on which decapsulation will occur. For example,
if IP-in-IP encapsulation is being used, the ifRcvAddressTable can be
defined by IP-in-IP. If it is not specified, the default is that one
entry will exist for the tunnel interface, where ifRcvAddressAddress
contains the local IP address used for encapsulation/decapsulation
(i.e., tunnelIfLocalInetAddress in the Tunnel Interface Table).
3.1.3. ifEntry
IfEntries are defined in the MIB modules defining the encapsulation
below the network layer. For example, if IP-in-IP encapsulation [20]
is being used, the ifEntry is defined by IP-in-IP.
The ifType of a tunnel should be set to "tunnel" (131). An entry in
the IP Tunnel MIB module will exist for every ifEntry with this
ifType. An implementation of the IP Tunnel MIB module may allow
ifEntries to be created via the tunnelConfigTable. Creating a tunnel
will also add an entry in the ifTable and in the tunnelIfTable, and
deleting a tunnel will likewise delete the entry in the ifTable and
the tunnelIfTable.
The use of two different tables in this MIB module was an important
design decision. Traditionally, ifIndex values are chosen by agents,
and are permitted to change across restarts. Allowing row creation
directly in the Tunnel Interface Table, indexed by ifIndex, would
Thaler Standards Track [Page 3]
^L
RFC 4087 IP Tunnel MIB June 2005
complicate row creation and/or cause interoperability problems (if
each agent had special restrictions on ifIndex). Instead, a separate
table is used that is indexed only by objects over which the manager
has control. Namely, these are the addresses of the tunnel endpoints
and the encapsulation protocol. Finally, an additional manager-
chosen ID is used in the index to support protocols such as L2F which
allow multiple tunnels between the same endpoints.
4. Definitions
TUNNEL-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE, transmission,
Integer32, IpAddress FROM SNMPv2-SMI -- [RFC2578]
RowStatus, StorageType FROM SNMPv2-TC -- [RFC2579]
MODULE-COMPLIANCE,
OBJECT-GROUP FROM SNMPv2-CONF -- [RFC2580]
InetAddressType,
InetAddress FROM INET-ADDRESS-MIB -- [RFC4001]
IPv6FlowLabelOrAny FROM IPV6-FLOW-LABEL-MIB -- [RFC3595]
ifIndex,
InterfaceIndexOrZero FROM IF-MIB -- [RFC2863]
IANAtunnelType FROM IANAifType-MIB; -- [IFTYPE]
tunnelMIB MODULE-IDENTITY
LAST-UPDATED "200505160000Z" -- May 16, 2005
ORGANIZATION "IETF IP Version 6 (IPv6) Working Group"
CONTACT-INFO
" Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
EMail: dthaler@microsoft.com"
DESCRIPTION
"The MIB module for management of IP Tunnels,
independent of the specific encapsulation scheme in
use.
Copyright (C) The Internet Society (2005). This
version of this MIB module is part of RFC 4087; see
the RFC itself for full legal notices."
Thaler Standards Track [Page 4]
^L
RFC 4087 IP Tunnel MIB June 2005
REVISION "200505160000Z" -- May 16, 2005
DESCRIPTION
"IPv4-specific objects were deprecated, including
tunnelIfLocalAddress, tunnelIfRemoteAddress, the
tunnelConfigTable, and the tunnelMIBBasicGroup.
Added IP version-agnostic objects that should be used
instead, including tunnelIfAddressType,
tunnelIfLocalInetAddress, tunnelIfRemoteInetAddress,
the tunnelInetConfigTable, and the
tunnelIMIBInetGroup.
The new tunnelIfLocalInetAddress and
tunnelIfRemoteInetAddress objects are read-write,
rather than read-only.
Updated DESCRIPTION clauses of existing version-
agnostic objects (e.g., tunnelIfTOS) that contained
IPv4-specific text to cover IPv6 as well.
Added tunnelIfFlowLabel for tunnels over IPv6.
The encapsulation method was previously an INTEGER
type, and is now an IANA-maintained textual
convention.
Published as RFC 4087."
REVISION "199908241200Z" -- August 24, 1999
DESCRIPTION
"Initial version, published as RFC 2667."
::= { transmission 131 }
tunnelMIBObjects OBJECT IDENTIFIER ::= { tunnelMIB 1 }
tunnel OBJECT IDENTIFIER ::= { tunnelMIBObjects 1 }
-- the IP Tunnel MIB-Group
--
-- a collection of objects providing information about
-- IP Tunnels
tunnelIfTable OBJECT-TYPE
SYNTAX SEQUENCE OF TunnelIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The (conceptual) table containing information on
configured tunnels."
Thaler Standards Track [Page 5]
^L
RFC 4087 IP Tunnel MIB June 2005
::= { tunnel 1 }
tunnelIfEntry OBJECT-TYPE
SYNTAX TunnelIfEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) containing the information
on a particular configured tunnel."
INDEX { ifIndex }
::= { tunnelIfTable 1 }
TunnelIfEntry ::= SEQUENCE {
tunnelIfLocalAddress IpAddress, -- deprecated
tunnelIfRemoteAddress IpAddress, -- deprecated
tunnelIfEncapsMethod IANAtunnelType,
tunnelIfHopLimit Integer32,
tunnelIfSecurity INTEGER,
tunnelIfTOS Integer32,
tunnelIfFlowLabel IPv6FlowLabelOrAny,
tunnelIfAddressType InetAddressType,
tunnelIfLocalInetAddress InetAddress,
tunnelIfRemoteInetAddress InetAddress,
tunnelIfEncapsLimit Integer32
}
tunnelIfLocalAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The address of the local endpoint of the tunnel
(i.e., the source address used in the outer IP
header), or 0.0.0.0 if unknown or if the tunnel is
over IPv6.
Since this object does not support IPv6, it is
deprecated in favor of tunnelIfLocalInetAddress."
::= { tunnelIfEntry 1 }
tunnelIfRemoteAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"The address of the remote endpoint of the tunnel
(i.e., the destination address used in the outer IP
header), or 0.0.0.0 if unknown, or an IPv6 address, or
Thaler Standards Track [Page 6]
^L
RFC 4087 IP Tunnel MIB June 2005
the tunnel is not a point-to-point link (e.g., if it
is a 6to4 tunnel).
Since this object does not support IPv6, it is
deprecated in favor of tunnelIfRemoteInetAddress."
::= { tunnelIfEntry 2 }
tunnelIfEncapsMethod OBJECT-TYPE
SYNTAX IANAtunnelType
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The encapsulation method used by the tunnel."
::= { tunnelIfEntry 3 }
tunnelIfHopLimit OBJECT-TYPE
SYNTAX Integer32 (0 | 1..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The IPv4 TTL or IPv6 Hop Limit to use in the outer IP
header. A value of 0 indicates that the value is
copied from the payload's header."
::= { tunnelIfEntry 4 }
tunnelIfSecurity OBJECT-TYPE
SYNTAX INTEGER {
none(1), -- no security
ipsec(2), -- IPsec security
other(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The method used by the tunnel to secure the outer IP
header. The value ipsec indicates that IPsec is used
between the tunnel endpoints for authentication or
encryption or both. More specific security-related
information may be available in a MIB module for the
security protocol in use."
::= { tunnelIfEntry 5 }
tunnelIfTOS OBJECT-TYPE
SYNTAX Integer32 (-2..63)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The method used to set the high 6 bits (the
Thaler Standards Track [Page 7]
^L
RFC 4087 IP Tunnel MIB June 2005
differentiated services codepoint) of the IPv4 TOS or
IPv6 Traffic Class in the outer IP header. A value of
-1 indicates that the bits are copied from the
payload's header. A value of -2 indicates that a
traffic conditioner is invoked and more information
may be available in a traffic conditioner MIB module.
A value between 0 and 63 inclusive indicates that the
bit field is set to the indicated value.
Note: instead of the name tunnelIfTOS, a better name
would have been tunnelIfDSCPMethod, but the existing
name appeared in RFC 2667 and existing objects cannot
be renamed."
::= { tunnelIfEntry 6 }
tunnelIfFlowLabel OBJECT-TYPE
SYNTAX IPv6FlowLabelOrAny
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The method used to set the IPv6 Flow Label value.
This object need not be present in rows where
tunnelIfAddressType indicates the tunnel is not over
IPv6. A value of -1 indicates that a traffic
conditioner is invoked and more information may be
available in a traffic conditioner MIB. Any other
value indicates that the Flow Label field is set to
the indicated value."
::= { tunnelIfEntry 7 }
tunnelIfAddressType OBJECT-TYPE
SYNTAX InetAddressType
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The type of address in the corresponding
tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress
objects."
::= { tunnelIfEntry 8 }
tunnelIfLocalInetAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The address of the local endpoint of the tunnel
(i.e., the source address used in the outer IP
header). If the address is unknown, the value is
Thaler Standards Track [Page 8]
^L
RFC 4087 IP Tunnel MIB June 2005
0.0.0.0 for IPv4 or :: for IPv6. The type of this
object is given by tunnelIfAddressType."
::= { tunnelIfEntry 9 }
tunnelIfRemoteInetAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The address of the remote endpoint of the tunnel
(i.e., the destination address used in the outer IP
header). If the address is unknown or the tunnel is
not a point-to-point link (e.g., if it is a 6to4
tunnel), the value is 0.0.0.0 for tunnels over IPv4 or
:: for tunnels over IPv6. The type of this object is
given by tunnelIfAddressType."
::= { tunnelIfEntry 10 }
tunnelIfEncapsLimit OBJECT-TYPE
SYNTAX Integer32 (-1 | 0..255)
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The maximum number of additional encapsulations
permitted for packets undergoing encapsulation at this
node. A value of -1 indicates that no limit is
present (except as a result of the packet size)."
REFERENCE "RFC 2473, section 4.1.1"
::= { tunnelIfEntry 11 }
tunnelConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF TunnelConfigEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The (conceptual) table containing information on
configured tunnels. This table can be used to map a
set of tunnel endpoints to the associated ifIndex
value. It can also be used for row creation. Note
that every row in the tunnelIfTable with a fixed IPv4
destination address should have a corresponding row in
the tunnelConfigTable, regardless of whether it was
created via SNMP.
Since this table does not support IPv6, it is
deprecated in favor of tunnelInetConfigTable."
::= { tunnel 2 }
Thaler Standards Track [Page 9]
^L
RFC 4087 IP Tunnel MIB June 2005
tunnelConfigEntry OBJECT-TYPE
SYNTAX TunnelConfigEntry
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"An entry (conceptual row) containing the information
on a particular configured tunnel.
Since this entry does not support IPv6, it is
deprecated in favor of tunnelInetConfigEntry."
INDEX { tunnelConfigLocalAddress,
tunnelConfigRemoteAddress,
tunnelConfigEncapsMethod,
tunnelConfigID }
::= { tunnelConfigTable 1 }
TunnelConfigEntry ::= SEQUENCE {
tunnelConfigLocalAddress IpAddress,
tunnelConfigRemoteAddress IpAddress,
tunnelConfigEncapsMethod IANAtunnelType,
tunnelConfigID Integer32,
tunnelConfigIfIndex InterfaceIndexOrZero,
tunnelConfigStatus RowStatus
}
tunnelConfigLocalAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The address of the local endpoint of the tunnel, or
0.0.0.0 if the device is free to choose any of its
addresses at tunnel establishment time.
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigLocalAddress."
::= { tunnelConfigEntry 1 }
tunnelConfigRemoteAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The address of the remote endpoint of the tunnel.
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigRemoteAddress."
::= { tunnelConfigEntry 2 }
Thaler Standards Track [Page 10]
^L
RFC 4087 IP Tunnel MIB June 2005
tunnelConfigEncapsMethod OBJECT-TYPE
SYNTAX IANAtunnelType
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"The encapsulation method used by the tunnel.
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigEncapsMethod."
::= { tunnelConfigEntry 3 }
tunnelConfigID OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS deprecated
DESCRIPTION
"An identifier used to distinguish between multiple
tunnels of the same encapsulation method, with the
same endpoints. If the encapsulation protocol only
allows one tunnel per set of endpoint addresses (such
as for GRE or IP-in-IP), the value of this object is
1. For encapsulation methods (such as L2F) which
allow multiple parallel tunnels, the manager is
responsible for choosing any ID which does not
conflict with an existing row, such as choosing a
random number.
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigID."
::= { tunnelConfigEntry 4 }
tunnelConfigIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only
STATUS deprecated
DESCRIPTION
"If the value of tunnelConfigStatus for this row is
active, then this object contains the value of ifIndex
corresponding to the tunnel interface. A value of 0
is not legal in the active state, and means that the
interface index has not yet been assigned.
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigIfIndex."
::= { tunnelConfigEntry 5 }
tunnelConfigStatus OBJECT-TYPE
SYNTAX RowStatus
Thaler Standards Track [Page 11]
^L
RFC 4087 IP Tunnel MIB June 2005
MAX-ACCESS read-create
STATUS deprecated
DESCRIPTION
"The status of this row, by which new entries may be
created, or old entries deleted from this table. The
agent need not support setting this object to
createAndWait or notInService since there are no other
writable objects in this table, and writable objects
in rows of corresponding tables such as the
tunnelIfTable may be modified while this row is
active.
To create a row in this table for an encapsulation
method which does not support multiple parallel
tunnels with the same endpoints, the management
station should simply use a tunnelConfigID of 1, and
set tunnelConfigStatus to createAndGo. For
encapsulation methods such as L2F which allow multiple
parallel tunnels, the management station may select a
pseudo-random number to use as the tunnelConfigID and
set tunnelConfigStatus to createAndGo. In the event
that this ID is already in use and an
inconsistentValue is returned in response to the set
operation, the management station should simply select
a new pseudo-random number and retry the operation.
Creating a row in this table will cause an interface
index to be assigned by the agent in an
implementation-dependent manner, and corresponding
rows will be instantiated in the ifTable and the
tunnelIfTable. The status of this row will become
active as soon as the agent assigns the interface
index, regardless of whether the interface is
operationally up.
Deleting a row in this table will likewise delete the
corresponding row in the ifTable and in the
tunnelIfTable.
Since this object does not support IPv6, it is
deprecated in favor of tunnelInetConfigStatus."
::= { tunnelConfigEntry 6 }
tunnelInetConfigTable OBJECT-TYPE
SYNTAX SEQUENCE OF TunnelInetConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
Thaler Standards Track [Page 12]
^L
RFC 4087 IP Tunnel MIB June 2005
"The (conceptual) table containing information on
configured tunnels. This table can be used to map a
set of tunnel endpoints to the associated ifIndex
value. It can also be used for row creation. Note
that every row in the tunnelIfTable with a fixed
destination address should have a corresponding row in
the tunnelInetConfigTable, regardless of whether it
was created via SNMP."
::= { tunnel 3 }
tunnelInetConfigEntry OBJECT-TYPE
SYNTAX TunnelInetConfigEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An entry (conceptual row) containing the information
on a particular configured tunnel. Note that there is
a 128 subid maximum for object OIDs. Implementers
need to be aware that if the total number of octets in
tunnelInetConfigLocalAddress and
tunnelInetConfigRemoteAddress exceeds 110 then OIDs of
column instances in this table will have more than 128
sub-identifiers and cannot be accessed using SNMPv1,
SNMPv2c, or SNMPv3. In practice this is not expected
to be a problem since IPv4 and IPv6 addresses will not
cause the limit to be reached, but if other types are
supported by an agent, care must be taken to ensure
that the sum of the lengths do not cause the limit to
be exceeded."
INDEX { tunnelInetConfigAddressType,
tunnelInetConfigLocalAddress,
tunnelInetConfigRemoteAddress,
tunnelInetConfigEncapsMethod,
tunnelInetConfigID }
::= { tunnelInetConfigTable 1 }
TunnelInetConfigEntry ::= SEQUENCE {
tunnelInetConfigAddressType InetAddressType,
tunnelInetConfigLocalAddress InetAddress,
tunnelInetConfigRemoteAddress InetAddress,
tunnelInetConfigEncapsMethod IANAtunnelType,
tunnelInetConfigID Integer32,
tunnelInetConfigIfIndex InterfaceIndexOrZero,
tunnelInetConfigStatus RowStatus,
tunnelInetConfigStorageType StorageType
}
tunnelInetConfigAddressType OBJECT-TYPE
Thaler Standards Track [Page 13]
^L
RFC 4087 IP Tunnel MIB June 2005
SYNTAX InetAddressType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address type over which the tunnel encapsulates
packets."
::= { tunnelInetConfigEntry 1 }
tunnelInetConfigLocalAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address of the local endpoint of the tunnel, or
0.0.0.0 (for IPv4) or :: (for IPv6) if the device is
free to choose any of its addresses at tunnel
establishment time."
::= { tunnelInetConfigEntry 2 }
tunnelInetConfigRemoteAddress OBJECT-TYPE
SYNTAX InetAddress
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The address of the remote endpoint of the tunnel."
::= { tunnelInetConfigEntry 3 }
tunnelInetConfigEncapsMethod OBJECT-TYPE
SYNTAX IANAtunnelType
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The encapsulation method used by the tunnel."
::= { tunnelInetConfigEntry 4 }
tunnelInetConfigID OBJECT-TYPE
SYNTAX Integer32 (1..2147483647)
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"An identifier used to distinguish between multiple
tunnels of the same encapsulation method, with the
same endpoints. If the encapsulation protocol only
allows one tunnel per set of endpoint addresses (such
as for GRE or IP-in-IP), the value of this object is
1. For encapsulation methods (such as L2F) which
allow multiple parallel tunnels, the manager is
responsible for choosing any ID which does not
Thaler Standards Track [Page 14]
^L
RFC 4087 IP Tunnel MIB June 2005
conflict with an existing row, such as choosing a
random number."
::= { tunnelInetConfigEntry 5 }
tunnelInetConfigIfIndex OBJECT-TYPE
SYNTAX InterfaceIndexOrZero
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"If the value of tunnelInetConfigStatus for this row
is active, then this object contains the value of
ifIndex corresponding to the tunnel interface. A
value of 0 is not legal in the active state, and means
that the interface index has not yet been assigned."
::= { tunnelInetConfigEntry 6 }
tunnelInetConfigStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this row, by which new entries may be
created, or old entries deleted from this table. The
agent need not support setting this object to
createAndWait or notInService since there are no other
writable objects in this table, and writable objects
in rows of corresponding tables such as the
tunnelIfTable may be modified while this row is
active.
To create a row in this table for an encapsulation
method which does not support multiple parallel
tunnels with the same endpoints, the management
station should simply use a tunnelInetConfigID of 1,
and set tunnelInetConfigStatus to createAndGo. For
encapsulation methods such as L2F which allow multiple
parallel tunnels, the management station may select a
pseudo-random number to use as the tunnelInetConfigID
and set tunnelInetConfigStatus to createAndGo. In the
event that this ID is already in use and an
inconsistentValue is returned in response to the set
operation, the management station should simply select
a new pseudo-random number and retry the operation.
Creating a row in this table will cause an interface
index to be assigned by the agent in an
implementation-dependent manner, and corresponding
rows will be instantiated in the ifTable and the
Thaler Standards Track [Page 15]
^L
RFC 4087 IP Tunnel MIB June 2005
tunnelIfTable. The status of this row will become
active as soon as the agent assigns the interface
index, regardless of whether the interface is
operationally up.
Deleting a row in this table will likewise delete the
corresponding row in the ifTable and in the
tunnelIfTable."
::= { tunnelInetConfigEntry 7 }
tunnelInetConfigStorageType OBJECT-TYPE
SYNTAX StorageType
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The storage type of this row. If the row is
permanent(4), no objects in the row need be writable."
::= { tunnelInetConfigEntry 8 }
-- conformance information
tunnelMIBConformance
OBJECT IDENTIFIER ::= { tunnelMIB 2 }
tunnelMIBCompliances
OBJECT IDENTIFIER ::= { tunnelMIBConformance 1 }
tunnelMIBGroups OBJECT IDENTIFIER ::= { tunnelMIBConformance 2 }
-- compliance statements
tunnelMIBCompliance MODULE-COMPLIANCE
STATUS deprecated
DESCRIPTION
"The (deprecated) IPv4-only compliance statement for
the IP Tunnel MIB.
This is deprecated in favor of
tunnelMIBInetFullCompliance and
tunnelMIBInetReadOnlyCompliance."
MODULE -- this module
MANDATORY-GROUPS { tunnelMIBBasicGroup }
OBJECT tunnelIfHopLimit
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfTOS
MIN-ACCESS read-only
Thaler Standards Track [Page 16]
^L
RFC 4087 IP Tunnel MIB June 2005
DESCRIPTION
"Write access is not required."
OBJECT tunnelConfigStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { tunnelMIBCompliances 1 }
tunnelMIBInetFullCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The full compliance statement for the IP Tunnel MIB."
MODULE -- this module
MANDATORY-GROUPS { tunnelMIBInetGroup }
OBJECT tunnelIfAddressType
SYNTAX InetAddressType { ipv4(1), ipv6(2),
ipv4z(3), ipv6z(4) }
DESCRIPTION
"An implementation is only required to support IPv4
and/or IPv6 addresses. An implementation only needs to
support the addresses it actually supports on the
device."
::= { tunnelMIBCompliances 2 }
tunnelMIBInetReadOnlyCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The read-only compliance statement for the IP Tunnel
MIB."
MODULE -- this module
MANDATORY-GROUPS { tunnelMIBInetGroup }
OBJECT tunnelIfHopLimit
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfTOS
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfFlowLabel
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
Thaler Standards Track [Page 17]
^L
RFC 4087 IP Tunnel MIB June 2005
OBJECT tunnelIfAddressType
SYNTAX InetAddressType { ipv4(1), ipv6(2),
ipv4z(3), ipv6z(4) }
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required.
An implementation is only required to support IPv4
and/or IPv6 addresses. An implementation only needs to
support the addresses it actually supports on the
device."
OBJECT tunnelIfLocalInetAddress
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfRemoteInetAddress
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelIfEncapsLimit
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
OBJECT tunnelInetConfigStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and active is the only
status that needs to be supported."
OBJECT tunnelInetConfigStorageType
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required."
::= { tunnelMIBCompliances 3 }
-- units of conformance
tunnelMIBBasicGroup OBJECT-GROUP
OBJECTS { tunnelIfLocalAddress, tunnelIfRemoteAddress,
tunnelIfEncapsMethod, tunnelIfHopLimit, tunnelIfTOS,
tunnelIfSecurity, tunnelConfigIfIndex, tunnelConfigStatus }
STATUS deprecated
DESCRIPTION
"A collection of objects to support basic management
Thaler Standards Track [Page 18]
^L
RFC 4087 IP Tunnel MIB June 2005
of IPv4 Tunnels. Since this group cannot support
IPv6, it is deprecated in favor of
tunnelMIBInetGroup."
::= { tunnelMIBGroups 1 }
tunnelMIBInetGroup OBJECT-GROUP
OBJECTS { tunnelIfAddressType, tunnelIfLocalInetAddress,
tunnelIfRemoteInetAddress, tunnelIfEncapsMethod,
tunnelIfEncapsLimit,
tunnelIfHopLimit, tunnelIfTOS, tunnelIfFlowLabel,
tunnelIfSecurity, tunnelInetConfigIfIndex,
tunnelInetConfigStatus, tunnelInetConfigStorageType }
STATUS current
DESCRIPTION
"A collection of objects to support basic management
of IPv4 and IPv6 Tunnels."
::= { tunnelMIBGroups 2 }
END
5. IANA Considerations
This document introduces a new IANA-maintained textual convention
(TC) which has been added to the IANAifType-MIB [IFTYPE]. The
initial version of this IANAtunnelType TC can be found in Appendix A.
The current version of the textual convention can be accessed at
http://www.iana.org/assignments/ianaiftype-mib
The assignment policy for IANAtunnelType values should always be
identical to the policy for assigning IANAifType values.
New types of tunnels over IPv4 or IPv6 should not be assigned
IANAifType values. Instead, they should be assigned IANAtunnelType
values and hence reuse the interface type tunnel(131). (Note this
restriction does not apply to "tunnels" which are not over IPv4 or
IPv6.)
Previously, tunnel types that were not point-to-point tunnels were
problematic in that they could not be properly expressed in the
tunnel MIB, and hence were assigned IANAifType values. This document
now corrects this problem, and as a result, IANA has deprecated the
sixToFour(215) IANAifType value in favor of the sixToFour(11)
IANAtunnelType value.
Thaler Standards Track [Page 19]
^L
RFC 4087 IP Tunnel MIB June 2005
6. Security Considerations
There are a number of management objects defined in this MIB module
with a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations.
Unauthorized write access to any of the writable objects could cause
unauthorized creation and/or manipulation of tunnels, resulting in a
denial of service, or redirection of packets to an arbitrary
destination.
Some of the readable objects in this MIB module (i.e., objects with a
MAX-ACCESS other than not-accessible) may be considered sensitive or
vulnerable in some network environments. It is thus important to
control even GET and/or NOTIFY access to these objects and possibly
to even encrypt the values of these objects when sending them over
the network via SNMP.
Unauthorized read access to tunnelIfLocalInetAddress,
tunnelIfRemoteInetAddress, tunnelIfLocalAddress,
tunnelIfRemoteAddress, or any object in the tunnelConfigTable or
tunnelInetConfigTable would reveal information about the tunnel
topology.
SNMP versions prior to SNMPv3 did not include adequate security.
Even if the network itself is secure (for example by using IPSec),
even then, there is no control as to who on the secure network is
allowed to access and GET/SET (read/change/create/delete) the objects
in this MIB module.
It is RECOMMENDED that implementers consider the security features as
provided by the SNMPv3 framework (see [RFC3410], section 8),
including full support for the SNMPv3 cryptographic mechanisms (for
authentication and privacy).
Further, deployment of SNMP versions prior to SNMPv3 is NOT
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to
enable cryptographic security. It is then a customer/operator
responsibility to ensure that the SNMP entity giving access to an
instance of this MIB module is properly configured to give access to
the objects only to those principals (users) that have legitimate
rights to indeed GET or SET (change/create/delete) them.
Thaler Standards Track [Page 20]
^L
RFC 4087 IP Tunnel MIB June 2005
7. Changes Since RFC 2667
IPv4-specific objects were deprecated, including
tunnelIfLocalAddress, tunnelIfRemoteAddress, the tunnelConfigTable,
and the tunnelMIBBasicGroup.
Added IP version-agnostic objects that should be used instead,
including tunnelIfAddressType, tunnelIfLocalInetAddress,
tunnelIfRemoteInetAddress, the tunnelInetConfigTable, and the
tunnelIMIBInetGroup.
The new tunnelIfLocalInetAddress and tunnelIfRemoteInetAddress
objects are read-write, rather than read-only.
Updated DESCRIPTION clauses of existing version-agnostic objects
(e.g., tunnelIfTOS) that contained IPv4-specific text to cover IPv6
as well.
Added tunnelIfFlowLabel for tunnels over IPv6.
The encapsulation method was previously an INTEGER type, and is now
an IANA-maintained textual convention.
8. Acknowledgements
This MIB module was updated based on feedback from the IETF's
Interfaces MIB (IF-MIB), Point-to-Point Protocol Extensions (PPPEXT),
and IPv6 Working Groups. Mike Heard and Ville Nuorvala also provided
valuable MIB guidance on this version.
Thaler Standards Track [Page 21]
^L
RFC 4087 IP Tunnel MIB June 2005
Appendix A: IANA Tunnel Type TC
This appendix defines the initial content of the IANAtunnelType
textual convention. The most up-to-date and current version is
maintained in the IANAifType-MIB.
IANAtunnelType ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"The encapsulation method used by a tunnel. The value
direct indicates that a packet is encapsulated
directly within a normal IP header, with no
intermediate header, and unicast to the remote tunnel
endpoint (e.g., an RFC 2003 IP-in-IP tunnel, or an RFC
1933 IPv6-in-IPv4 tunnel). The value minimal indicates
that a Minimal Forwarding Header (RFC 2004) is
inserted between the outer header and the payload
packet. The value UDP indicates that the payload
packet is encapsulated within a normal UDP packet
(e.g., RFC 1234).
The values sixToFour, sixOverFour, and isatap
indicates that an IPv6 packet is encapsulated directly
within an IPv4 header, with no intermediate header,
and unicast to the destination determined by the 6to4,
6over4, or ISATAP protocol.
The remaining protocol-specific values indicate that a
header of the protocol of that name is inserted
between the outer header and the payload header.
The assignment policy for IANAtunnelType values is
identical to the policy for assigning IANAifType
values."
SYNTAX INTEGER {
other(1), -- none of the following
direct(2), -- no intermediate header
gre(3), -- GRE encapsulation
minimal(4), -- Minimal encapsulation
l2tp(5), -- L2TP encapsulation
pptp(6), -- PPTP encapsulation
l2f(7), -- L2F encapsulation
udp(8), -- UDP encapsulation
atmp(9), -- ATMP encapsulation
msdp(10), -- MSDP encapsulation
sixToFour(11), -- 6to4 encapsulation
sixOverFour(12), -- 6over4 encapsulation
isatap(13), -- ISATAP encapsulation
Thaler Standards Track [Page 22]
^L
RFC 4087 IP Tunnel MIB June 2005
teredo(14) -- Teredo encapsulation
}
Normative References
[IFTYPE] Internet Assigned Numbers Authority, "IANAifType-MIB",
http://www.iana.org/assignments/ianaiftype-mib.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Structure of Management
Information Version 2 (SMIv2)", STD 58, RFC 2578, April
1999.
[RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Textual Conventions for
SMIv2", STD 58, RFC 2579, April 1999.
[RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M., and S. Waldbusser, "Conformance Statements for
SMIv2", STD 58, RFC 2580, April 1999.
[RFC2863] McCloghrie, K. and F. Kastenholz. "The Interfaces Group
MIB", RFC 2863, June 2000.
[RFC3595] Wijnen, B., "Textual Conventions for IPv6 Flow Label",
RFC 3595, September 2003.
[RFC4001] Daniele, M., Haberman, B., Routhier, S., and J.
Schoenwaelder, "Textual Conventions for Internet Network
Addresses", RFC 4001, February 2005.
Informative References
[RFC1234] Provan, D., "Tunneling IPX Traffic through IP Networks",
RFC 1234, June 1991.
[RFC1241] Woodburn, R. and D. Mills, "A Scheme for an Internet
Encapsulation Protocol: Version 1", RFC 1241, July 1991.
[RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
Routing Encapsulation over IPv4 networks", RFC 1702,
October 1994.
Thaler Standards Track [Page 23]
^L
RFC 4087 IP Tunnel MIB June 2005
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[RFC2107] Hamzeh, K., "Ascend Tunnel Management Protocol - ATMP",
RFC 2107, February 1997.
[RFC2341] Valencia, A., Littlewood, M., and T. Kolar. "Cisco Layer
Two Forwarding (Protocol) "L2F"", RFC 2341, May 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black.
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
[RFC2637] Hamzeh, K., Pall, G., Verthein, W. Taarud, J., Little,
W., and G. Zorn, "Point-to-Point Tunneling Protocol",
RFC 2637, July 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2893] Gilligan, R. and E. Nordmark. "Transition Mechanisms for
IPv6 Hosts and Routers", RFC 2893, August 2000.
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
Author's Address
Dave Thaler
Microsoft Corporation
One Microsoft Way
Redmond, WA 98052-6399
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Thaler Standards Track [Page 24]
^L
RFC 4087 IP Tunnel MIB June 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 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 in BCP 78 and BCP 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 at
http://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.
Thaler Standards Track [Page 25]
^L
|