idnits 2.17.1
draft-ietf-sming-inet-modules-02.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** The document seems to lack separate sections for Informative/Normative
References. All references will be assumed normative when checking for
downward references.
** There are 18 instances of too long lines in the document, the longest
one being 3 characters in excess of 72.
** There are 10 instances of lines with control characters in the document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== Line 240 has weird spacing: '... octets cont...'
== Line 256 has weird spacing: '... octets cont...'
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (July 20, 2001) is 8308 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Possible downref: Normative reference to a draft: ref. '1'
** Obsolete normative reference: RFC 2851 (ref. '3') (Obsoleted by RFC 3291)
Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group F. Strauss
3 Internet-Draft J. Schoenwaelder
4 Expires: January 18, 2002 TU Braunschweig
5 July 20, 2001
7 SMIng Internet Protocol Core Modules
8 draft-ietf-sming-inet-modules-02
10 Status of this Memo
12 This document is an Internet-Draft and is in full conformance with
13 all provisions of Section 10 of RFC2026.
15 Internet-Drafts are working documents of the Internet Engineering
16 Task Force (IETF), its areas, and its working groups. Note that
17 other groups may also distribute working documents as Internet-
18 Drafts.
20 Internet-Drafts are draft documents valid for a maximum of six months
21 and may be updated, replaced, or obsoleted by other documents at any
22 time. It is inappropriate to use Internet-Drafts as reference
23 material or to cite them other than as "work in progress."
25 The list of current Internet-Drafts can be accessed at
26 http://www.ietf.org/ietf/1id-abstracts.txt.
28 The list of Internet-Draft Shadow Directories can be accessed at
29 http://www.ietf.org/shadow.html.
31 This Internet-Draft will expire on January 18, 2002.
33 Copyright Notice
35 Copyright (C) The Internet Society (2001). All Rights Reserved.
37 Abstract
39 This memo presents SMIng modules that introduce commonly used
40 Internet Protocol specific data definitions. They are provided so
41 that other SMIng modules that would otherwise define their own
42 representations can import them from a common place.
44 The IETF-INET module defines types and classes for representing
45 Internet Protocol specific information. It builds on RFC 2851 and
46 extends it in several ways.
48 The IETF-INET-FILTER module extends the IETF-INET module by providing
49 generic definitions for typical IP packet filters.
51 Table of Contents
53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
54 2. IETF-INET . . . . . . . . . . . . . . . . . . . . . . . . . . 3
55 3. IETF-INET-FILTER . . . . . . . . . . . . . . . . . . . . . . . 9
56 4. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . 11
57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
58 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
59 References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
60 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
61 A. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . . . 14
62 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15
64 1. Introduction
66 SMIng [1] modules frequently need to represent Internet Protocol
67 specific information such as IP addresses. This memo contains SMIng
68 modules which define a core set of SMIng types and classes to be
69 imported by other SMIng modules.
71 The IETF-INET module provides core SMIng data definitions for the
72 Internet Protocol suite. This module is derived from [3].
74 The IETF-INET-FILTER module provides SMIng data definitions that
75 model Internet Protocol filters and components thereof.
77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
79 document are to be interpreted as described in [2].
81 2. IETF-INET
83 module IETF-INET {
85 organization "IETF Next Generation Structure of
86 Management Information Working Group (SMING)";
88 contact "Juergen Schoenwaelder
90 TU Braunschweig
91 Bueltenweg 74/75
92 38106 Braunschweig
93 Germany
95 Phone: +49 531 391-3289
96 EMail: schoenw@ibr.cs.tu-bs.de";
98 description "This module defines core types and classes for
99 the Internet Protocol suite. This document builds
100 upon RFC 2851 and extends it in various ways.";
102 revision {
103 date "2001-03-02";
104 description "Initial revision, published as RFC &rfc.number;.";
105 };
107 //
108 // Core type definitions for the Internet Protocol suite.
109 //
111 typedef InetPortNumber {
112 type Unsigned32 (0..65535);
113 description
114 "Represents a 16 bit port number of an Internet
115 transport layer protocol. Port numbers are assigned by
116 IANA. A list of all assignments is available from
117 .
119 The value zero is object-specific and must be defined as
120 part of the description of any object which uses this
121 syntax. Examples of the usage of zero might include
122 situations where a port number is unknown, or when the
123 value zero is used as a wildcard in a filter.";
124 reference
125 "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960";
126 };
128 typedef InetProtocolNumber {
129 type Unsigned32 (0..255);
130 description
131 "Represents an 8 bit protocol number which indicates the
132 next upper-layer protocol used in the data portion of an
133 Internet datagram. Protocol numbers are assigned by
134 IANA. A list of all assignments is available at the
135 from ".;
136 reference
137 "STD 5 (RFC 791) Section 3.1 and RFC 2460 Section 3.";
138 };
140 typedef InetDiffServCodePoint {
141 type Unsigned32 (-1, 0..63);
142 description
143 "Represents a 6 bit Differentiated Services Code Point
144 (DSCP). The special value -1 may be used to indicate
145 e.g. a wildnot in a filter.";
146 reference
147 "RFC 2474";
148 };
150 typedef InetAddress {
151 type OctetString;
152 description
153 "Represents a generic IP version neutral Internet address.";
154 };
156 typedef InetAddressPrefixLength {
157 type Unsigned32;
158 description
159 "Denotes the length of a generic Internet network address
160 prefix. A value of n corresponds to an IP address mask
161 which has n contiguous 1-bits from the most significant
162 bit (MSB) and all other bits set to 0.
164 InetAddressPrefixLength values that are larger than
165 the maximum length of an IP address for a specific
166 InetAddressType are treated as the maximum significant
167 value applicable for the InetAddressType. The maximum
168 significant value is 32 for the InetAddressType
169 'ipv4(1)' and 128 for the InetAddressType 'ipv6(2)'.
170 The maximum significant value for the InetAddressType
171 'dns(16)' is 0.
173 The value zero is object-specific and must be defined as
174 part of the description of any object which uses this
175 syntax. Examples of the usage of zero might include
176 situations where the Internet network address prefix
177 is unknown or does not apply.";
178 };
180 typedef InetAutonomousSystemNumber {
181 type Unsigned32;
182 description
183 "Represents an autonomous system number which identifies an
184 Autonomous System (AS). An AS is a set of routers under a
185 single technical administration, using an interior gateway
186 protocol and common metrics to route packets within the AS,
187 and using an exterior gateway protocol to route packets to
188 other ASs'. IANA maintains the AS number space and has
189 delegated large parts to the regional registries.
191 Autonomous system numbers are currently limited to 16 bits
192 (0..65535). There is however work in progress to enlarge the
193 autonomous system number space to 32 bits. This textual
194 convention therefore uses an Unsigned32 value without a
195 range restriction in order to support a larger autonomous
196 system number space.";
197 reference
198 "RFC 1771, RFC 1930";
199 };
201 //
202 // Internet Protocol address types for specific IP versions.
203 //
205 typedef InetAddressType {
206 type Enumeration (unknown(0), ipv4(1), ipv6(2),
207 dns(16));
209 description
210 "A value that represents a type of Internet address.
212 unknown(0) An unknown address type. This value MUST
213 be used if the value of the corresponding
214 address attribute is a zero-length string.
215 It may also be used to indicate an IP address
216 which is not in one of the formats defined
217 below.
219 ipv4(1) An IPv4 address as defined by the
220 InetAddressIPv4 type.
222 ipv6(2) An IPv6 address as defined by the
223 InetAddressIPv6 type.
225 dns(16) A DNS domain name as defined by the
226 InetAddressDNS type.
228 The type SHOULD NOT be subtyped to support future
229 extensions. It MAY be subtyped in compliance statements
230 in order to require only a subset of these address types
231 for a compliant implementation.";
232 };
234 typedef InetAddressIPv4 {
235 type InetAddress (4);
236 format "1d.1d.1d.1d";
237 description
238 "Represents a 32 bit IP version 4 (IPv4) network address:
240 octets contents encoding
241 1-4 IPv4 address network-byte order
243 If there is a corresponding InetAddressType attribute,
244 its value MUST be ipv4(1).";
245 reference
246 "STD 5 (RFC 791)";
247 };
249 typedef InetAddressIPv6 {
250 type InetAddress (16 | 20);
251 format "2x:2x:2x:2x:2x:2x:2x:2x%4d";
252 description
253 "Represents a 128 bit IPv6 network address plus an
254 optional 32 bit scope identifier:
256 octets contents encoding
257 1-16 IPv6 address network-byte order
258 17-20 scope identifier network-byte order
260 If there is a corresponding InetAddressType attribute,
261 its value MUST be ipv6(2).
263 The scope identifier (bytes 17-20) MUST NOT be present
264 for global IPv6 addresses. For non-global IPv6 addresses
265 (e.g. link-local or site-local addresses), the scope
266 identifier MUST always be present. It contains a link
267 identifier for link-local and a site identifier for
268 site-local IPv6 addresses.
270 The scope identifier MUST disambiguate identical address
271 values. For link-local addresses, the scope identifier will
272 typically be the interface index (ifIndex as defined in the
273 IF-MIB, RFC 2233) of the interface on which the address is
274 configured.
276 The scope identifier may contain the special value 0
277 which refers to the default scope. The default scope
278 may be used in cases where the valid scope identifier
279 is not known (e.g., a management application needs to
280 write a site-local InetAddressIPv6 address without
281 knowing the site identifier value). The default scope
282 SHOULD NOT be used as an easy way out in cases where
283 the scope identifier for a non-global IPv6 address is
284 known.";
285 reference
286 "RFC 2373";
287 };
289 typedef InetAddressDNS {
290 type InetAddress (1..255);
291 format "255a";
292 description
293 "Represents a DNS domain name. The name SHOULD be
294 fully qualified whenever possible.
296 If there is a corresponding InetAddressType attribute,
297 its value MUST be dns(16).
299 The descriptions of attributes of this type must fully
300 describe how (and when) such names are to be resolved
301 to IP addresses.";
302 };
304 //
305 // Core class definitions for the Internet Protocol suite.
306 //
308 class InetNetworkEndpoint {
309 attribute InetAddressType type {
310 access readwrite;
311 description
312 "The type of this Internet Protocol endpoint.";
313 };
314 attribute InetAddress address {
315 typemap type {
316 map ipv4 InetAddressIPv4;
317 map ipv6 InetAddressIPv6;
318 map dns InetAddressDNS;
319 };
320 access readwrite;
321 description
322 "The address of this Internet Protocol endpoint.
324 An address value is always interpreted within the
325 context of the type value. The type attribute defines
326 the context.";
327 };
328 description
329 "This class defines a generic Internet Protocol endpoint
330 at the network layer.";
331 };
333 class InetTransportEndpoint {
334 attribute InetNetworkEndpoint address {
335 description
336 "The network layer endpoint.";
337 };
338 attribute InetPortNumber port {
339 description
340 "The transport layer port number.";
341 };
342 description
343 "This class defines a generic transport layer endpoint for
344 the Internet Protocol suite.";
345 };
347 class InetSubnet {
348 attribute InetNetworkEndpoint endpoint {
349 description
350 "A network layer endpoint within the Internet
351 Protocol subnet.";
352 }
353 attribute InetAddressPrefixLength prefix {
354 description
355 "The address prefix which identifies the subnet
356 portion of the address of the network layer
357 endpoint.";
358 };
359 description
360 "This class defines a generic Internet Protocol subnet.";
361 };
363 class InetPortNumberRange {
364 attribute InetPortNumber start {
365 access readwrite;
366 description
367 "The first port number in the port range.";
368 };
369 attribute InetPortNumber end {
370 access readwrite;
371 description
372 "The last port number in the port range.";
373 };
374 description
375 "This class represents a range of consecutive Internet
376 transport layer port numbers. The start and end port
377 numbers are included in the range of consecutive port
378 numbers.";
379 };
381 };
383 3. IETF-INET-FILTER
385 module IETF-INET-FILTER {
387 import IETF-INET (InetProtocolNumber,
388 InetDiffServCodePoint,
389 InetPortNumberRange,
390 InetSubnet);
391 import IETF-SMING (Counter64,
392 DisplayString255);
394 organization "IETF Next Generation Structure of
395 Management Information Working Group (SMING)";
397 contact "Juergen Schoenwaelder
399 TU Braunschweig
400 Bueltenweg 74/75
401 38106 Braunschweig
402 Germany
404 Phone: +49 531 391-3289
405 EMail: schoenw@ibr.cs.tu-bs.de";
407 description "This module defines core filter classes for
408 the Internet protocol suite.";
410 revision {
411 date "2001-03-02";
412 description "Initial revision, published as RFC &rfc.number;.";
413 };
415 class Filter {
416 attribute DisplayString255 name {
417 access readwrite;
418 description
419 "The administratively assigned name of the filter.";
420 };
421 attribute Counter64 packets {
422 access readonly;
423 units "packets";
424 "The number of packets matching this filter.";
425 };
426 attribute Counter64 bytes {
427 access readonly;
428 units "bytes";
429 description
430 "The number of bytes contained in packets matching
431 this filter.";
432 };
433 description
434 "A generic filter. Classes derived from this generic filter
435 must introduce additional attributes which define the
436 filter parameters.";
437 };
439 class InetFilter : Filter {
440 attribute InetSubnet srcSubNet {
441 description
442 "The subnet to match against the packet's
443 source address.";
444 };
445 attribute InetSubnet dstSubNet {
446 description
447 "The subnet to match against the packet's
448 destination address.";
449 };
450 attribute InetPortRange srcPortRange {
451 description
452 "The port range to match against the packet's
453 source port."
454 };
455 attribute InetPortRange dstPortRange {
456 description
457 "The port range to match against the packet's
458 destination port.";
459 };
460 attribute InetProtocolNumber protocol {
461 access readwrite;
462 description
463 "The protocol number to match against the packet's
464 Internet Protocol version. A value of zero
465 matches any IP version.";
466 };
467 attribute InetDiffServCodePoint dscp {
468 access readwrite;
469 description
470 "The value that the DSCP in the packet must have to
471 match this entry. A value of -1 indicates that a
472 specific DSCP value has not been defined and thus all
473 DSCP values are considered a match.";
474 }
475 description
476 "This class represents a generic Internet Protocol filter.
477 Classes derived from this class may add attributes which
478 define further filter criteria.";
479 };
481 };
483 4. Usage Examples
485 The following example shows how a TCP connection might be modelled.
486 The class definition below could be used to derive an IP version
487 independent MIB for representing open TCP connections.
489 module IETF-TCP {
491 import IETF-INET (InetTransportEndpoint);
493 // ...
495 typedef TcpConnectionState {
496 type Enumeration (closed(1), listen(2), synSent(3),
497 synReceived(4), established(5),
498 finWait1(6), finWait2(7), closeWait(8),
499 lastAck(9), closing(10), timeWait(11));
500 description
501 "The state of a TCP connection.";
502 reference
503 "STD 7 (RFC 793)";
504 };
506 typedef TcpConnectionCtrl {
507 type Enumeration (none(0), delete(1));
508 description
509 "The enumerated numbers defined by this type allow to control
510 TCP connections. The value none(0) will be reported whenever
511 an attribute of this type is read.
513 The only value which may be written is delete(1). If a
514 management station writes the value delete(1), then this
515 has the effect of deleting the TCB (as defined in RFC 793)
516 of the corresponding connection on the managed node,
517 resulting in immediate termination of the connection.
519 As an implementation-specific option, a RST segment may be
520 sent from the managed node to the other TCP endpoint (note
521 however that RST segments are not sent reliably).";
522 };
524 class TcpConnection {
525 attribute InetTransportEndpoint local {
526 description
527 "The local endpoint of the TCP connection.";
528 };
529 attribute InetTransportEndpoint remote {
530 description
531 "The remote endpoint of the TCP connection.";
532 };
533 attribute TcpConnectionState state {
534 access readonly;
535 description
536 "The current state of the TCP connection.";
537 };
538 attribute TcpConnectionCtrl ctrl {
539 access readwrite;
540 description
541 "A control which allows to change the state of the
542 TCP connection.";
544 };
545 description
546 "This class contains information about a particular current
547 TCP connection.";
548 };
549 };
551 5. Security Considerations
553 This module does not define any management objects. Instead, it
554 defines a set of SMIng types and classes which may be used by other
555 SMIng modules to define management objects. These data definitions
556 have no security impact on the Internet.
558 6. Acknowledgments
560 Some definitions in this document are derived from RFC 2851 [3],
561 which was written by M. Daniele, B. Haberman, S. Routhier and J.
562 Schoenwaelder.
564 References
566 [1] Strauss, F. and J. Schoenwaelder, "SMIng - Next Generation
567 Structure of Management Information", draft-ietf-sming-02.txt,
568 July 2001.
570 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
571 Levels", RFC 2119, BCP 14, March 1997.
573 [3] Daniele, M., Haberman, B., Routhier, S. and J. Schoenwaelder,
574 "Textual Conventions for Internet Network Addresses", RFC 2851,
575 June 2000.
577 Authors' Addresses
579 Frank Strauss
580 TU Braunschweig
581 Bueltenweg 74/75
582 38106 Braunschweig
583 Germany
585 Phone: +49 531 391-3266
586 EMail: strauss@ibr.cs.tu-bs.de
587 URI: http://www.ibr.cs.tu-bs.de/
588 Juergen Schoenwaelder
589 TU Braunschweig
590 Bueltenweg 74/75
591 38106 Braunschweig
592 Germany
594 Phone: +49 531 391-3289
595 EMail: schoenw@ibr.cs.tu-bs.de
596 URI: http://www.ibr.cs.tu-bs.de/
598 Appendix A. OPEN ISSUES
600 What else is missing? - There might be more core type or class
601 definitions that should go into the IETF-SMING-INET module.
603 Are the filters sufficiently flexible? - The filters probably need
604 more work to cover more cases. Should the IETF-INET-FILTER module
605 become a separate document?
607 More examples needed? - Is it useful to include more examples, e.g.
608 on the usage of filters or subnets?
610 Dscp Definition - Does the InetDiffServCodePoint type definition
611 really belong into this module?
613 InetAddressDNS Format - 255a or 255t? Length restriction?
615 Usage of the terms Endpoint and Address - Check the attribute
616 identifiers and descriptions of InetTransportEndpoint and
617 InetSubnet: when should the term endpoint be used, and when
618 address?
620 InetProtocolNumber and InetTransportEndpoint - Should an
621 InetProtocolNumber attribute be added to the
622 InetTransportEndpoint?
624 Undocumented typemap keyword - This feature needs more work. We
625 either define such a type casting mechanism or we add a real
626 discriminated union to the SMIng type system.
628 Full Copyright Statement
630 Copyright (C) The Internet Society (2001). All Rights Reserved.
632 This document and translations of it may be copied and furnished to
633 others, and derivative works that comment on or otherwise explain it
634 or assist in its implementation may be prepared, copied, published
635 and distributed, in whole or in part, without restriction of any
636 kind, provided that the above copyright notice and this paragraph are
637 included on all such copies and derivative works. However, this
638 document itself may not be modified in any way, such as by removing
639 the copyright notice or references to the Internet Society or other
640 Internet organizations, except as needed for the purpose of
641 developing Internet standards in which case the procedures for
642 copyrights defined in the Internet Standards process must be
643 followed, or as required to translate it into languages other than
644 English.
646 The limited permissions granted above are perpetual and will not be
647 revoked by the Internet Society or its successors or assigns.
649 This document and the information contained herein is provided on an
650 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
651 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
652 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
653 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
654 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
656 Acknowledgement
658 Funding for the RFC Editor function is currently provided by the
659 Internet Society.