idnits 2.17.1 draft-irtf-nmrg-sming-inet-modules-01.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 10 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There are 14 instances of lines with control characters in the document. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 199 has weird spacing: '... octets cont...' == Line 215 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 (November 24, 2000) is 8526 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) == Outdated reference: A later version (-07) exists of draft-irtf-nmrg-sming-04 ** Downref: Normative reference to an Experimental draft: draft-irtf-nmrg-sming (ref. '1') ** Obsolete normative reference: RFC 2851 (ref. '3') (Obsoleted by RFC 3291) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 2 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: May 25, 2001 TU Braunschweig 5 K. McCloghrie 6 Cisco Systems 7 November 24, 2000 9 SMIng Internet Protocol Core Modules 10 draft-irtf-nmrg-sming-inet-modules-01 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other documents 24 at any time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on May 25, 2001. 35 Abstract 37 This memo presents SMIng modules that introduce commonly used 38 Internet Protocol specific data definitions. They are provided so 39 that other SMIng modules that would otherwise define their own 40 representations can import them from a common place. 42 The IRTF-NMRG-INET module defines types and classes for representing 43 Internet Protocol specific information. It builds on RFC 2851 and 44 extends it in several ways. 46 The IRTF-NMRG-INET-FILTER module extends the IRTF-NMRG-INET module 47 by providing generic definitions for typical IP packet filters. 49 Copyright Notice 50 Copyright (C) The Internet Society (2000). All Rights Reserved. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. IRTF-NMRG-INET . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. IRTF-NMRG-INET-FILTER . . . . . . . . . . . . . . . . . . . . 8 57 4. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 60 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 62 A. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . . . 13 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 IRTF-NMRG-INET module provides core SMIng data definitions for 72 the Internet Protocol suite. This module is derived from [3]. 74 The IRTF-NMRG-INET-FILTER module provides SMIng data definitions 75 that 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. IRTF-NMRG-INET 83 module IRTF-NMRG-INET { 85 organization "IRTF Network Management Research Group (NMRG)"; 87 contact "Juergen Schoenwaelder 89 TU Braunschweig 90 Bueltenweg 74/75 91 38106 Braunschweig 92 Germany 94 Phone: +49 531 391-3289 95 EMail: schoenw@ibr.cs.tu-bs.de"; 97 description "This module defines core types and classes for 98 the Internet Protocol suite. This document builds 99 upon RFC 2851 and extends it in various ways."; 101 revision { 102 date "2000-11-23"; 103 description "Initial revision, published as RFC XXXX."; 104 }; 106 // 107 // Core type definitions for the Internet Protocol suite. 108 // 110 typedef InetPortNumber { 111 type Unsigned32 (0..65535); 112 description 113 "Represents a 16 bit port number of an Internet 114 transport layer protocol. Port numbers are assigned by 115 IANA. A list of all assignments is available at the 116 following location: 118 http://www.isi.edu/in-notes/iana/assignments/port-numbers"; 119 reference 120 "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960"; 121 }; 123 typedef InetProtocolNumber { 124 type Unsigned32 (0..255); 125 description 126 "Represents an 8 bit protocol number which indicates the 127 next upper-layer protocol used in the data portion of an 128 Internet datagram. Protocol numbers are assigned by 129 IANA. A list of all assignments is available at the 130 following location: 132 http:// 133 www.isi.edu/in-notes/iana/assignments/protocol-numbers"; 134 reference 135 "STD 5 (RFC 791) Section 3.1 and RFC 2460 Section 3."; 136 }; 138 typedef InetDiffServCodePoint { 139 type Unsigned32 (-1, 0..63); 140 description 141 "Represents a 6 bit Differentiated Services Code Point 142 (DSCP). The special value -1 may be used to indicate 143 that the DSCP is not relevant."; 144 reference 145 "RFC 2474"; 146 }; 148 typedef InetAddress { 149 type OctetString; 150 description 151 "Represents a generic IP version neutral Internet address."; 152 }; 154 typedef InetAddressMask { 155 type Unsigned32; 156 description 157 "Represents an address prefix length (traditionally called 158 an address mask) for generic Internet addresses."; 159 }; 161 // 162 // Internet Protocol address types for specific IP versions. 163 // 165 typedef InetAddressType { 166 type Enumeration (unknown(0), ipv4(1), ipv6(2), 167 dns(16)); 168 description 169 "A value that represents a type of Internet address. 171 unknown(0) An unknown address type. This value MUST 172 be used if the value of the corresponding 173 address attribute is a zero-length string. 174 It may also be used to indicate an IP address 175 which is not in one of the formats defined 176 below. 178 ipv4(1) An IPv4 address as defined by the 179 InetAddressIPv4 type. 181 ipv6(2) An IPv6 address as defined by the 182 InetAddressIPv6 type. 184 dns(16) A DNS domain name as defined by the 185 InetAddressDNS type. 187 The type SHOULD NOT be subtyped to support future 188 extensions. It MAY be subtyped in compliance statements 189 in order to require only a subset of these address types 190 for a compliant implementation."; 191 }; 193 typedef InetAddressIPv4 { 194 type InetAddress (4); 195 format "1d.1d.1d.1d"; 196 description 197 "Represents a 32 bit IP version 4 (IPv4) network address: 199 octets contents encoding 200 1-4 IPv4 address network-byte order 202 If there is a corresponding InetAddressType attribute, 203 its value MUST be ipv4(1)."; 204 reference 205 "STD 5 (RFC 791)"; 206 }; 208 typedef InetAddressIPv6 { 209 type InetAddress (16 | 20); 210 format "2x:2x:2x:2x:2x:2x:2x:2x%4d"; 211 description 212 "Represents a 128 bit IPv6 network address plus an 213 optional 32 bit scope identifier: 215 octets contents encoding 216 1-16 IPv6 address network-byte order 217 17-20 scope identifier network-byte order 219 If there is a corresponding InetAddressType attribute, 220 its value MUST be ipv6(2). 222 The scope identifier (bytes 17-20) MUST NOT be present 223 for global IPv6 addresses. For non-global IPv6 addresses 224 (e.g. link-local or site-local addresses), the scope 225 identifier MUST always be present. It contains a link 226 identifier for link-local and a site identifier for 227 site-local IPv6 addresses. 229 The scope identifier MUST disambiguate identical address 230 values. For link-local addresses, the scope identifier will 231 typically be the interface index (ifIndex as defined in the 232 IF-MIB, RFC 2233) of the interface on which the address is 233 configured. 235 The scope identifier may contain the special value 0 236 which refers to the default scope. The default scope 237 may be used in cases where the valid scope identifier 238 is not known (e.g., a management application needs to 239 write a site-local InetAddressIPv6 address without 240 knowing the site identifier value). The default scope 241 SHOULD NOT be used as an easy way out in cases where 242 the scope identifier for a non-global IPv6 address is 243 known."; 244 reference 245 "RFC 2373"; 246 }; 248 typedef InetAddressDNS { 249 type InetAddress (1..255); 250 format "255a"; 251 description 252 "Represents a DNS domain name. The name SHOULD be 253 fully qualified whenever possible. 255 If there is a corresponding InetAddressType attribute, 256 its value MUST be dns(16). 258 The descriptions of attributes of this type must fully 259 describe how (and when) such names are to be resolved 260 to IP addresses."; 261 }; 263 // 264 // Core class definitions for the Internet Protocol suite. 265 // 267 class InetNetworkEndpoint { 268 attribute InetAddressType type { 269 access readwrite; 270 description 271 "The type of this Internet Protocol endpoint."; 272 }; 273 attribute InetAddress address { 274 typemap type { 275 map ipv4 InetAddressIPv4; 276 map ipv6 InetAddressIPv6; 277 map dns InetAddressDNS; 278 }; 279 access readwrite; 280 description 281 "The address of this Internet Protocol endpoint. 283 An address value is always interpreted within the 284 context of the type value. The type attribute defines 285 the context."; 286 }; 287 description 288 "This class defines a generic Internet Protocol endpoint 289 at the network layer."; 290 }; 292 class InetTransportEndpoint { 293 attribute InetNetworkEndpoint address { 294 description 295 "The network layer endpoint."; 296 }; 297 attribute InetPortNumber port { 298 description 299 "The transport layer port number."; 300 }; 301 description 302 "This class defines a generic transport layer endpoint for 303 the Internet Protocol suite."; 304 }; 306 class InetSubnet { 307 attribute InetNetworkEndpoint endpoint { 308 description 309 "A network layer endpoint within the Internet 310 Protocol subnet."; 311 } 312 attribute InetAddressMask mask { 313 description 314 "The address mask which identifies the subnet 315 portion of the address of the network layer 316 endpoint."; 317 }; 318 description 319 "This class defines a generic Internet Protocol subnet."; 320 }; 322 class InetPortNumberRange { 323 attribute InetPortNumber start { 324 access readwrite; 325 description 326 "The first port number in the port range."; 327 }; 328 attribute InetPortNumber end { 329 access readwrite; 330 description 331 "The last port number in the port range."; 332 }; 333 description 334 "This class represents a range of consecutive Internet 335 transport layer port numbers. The start and end port 336 numbers are included in the range of consecutive port 337 numbers."; 338 }; 340 }; 342 3. IRTF-NMRG-INET-FILTER 344 module IRTF-NMRG-INET-FILTER { 346 import IRTF-NMRG-INET (InetProtocolNumber, 347 InetDiffServCodePoint, 348 InetPortNumberRange, 349 InetSubnet); 350 import IRTF-NMRG-SMING (Counter64, 351 DisplayString255); 353 organization "IRTF Network Management Research Group (NMRG)"; 355 contact "Juergen Schoenwaelder 357 TU Braunschweig 358 Bueltenweg 74/75 359 38106 Braunschweig 360 Germany 362 Phone: +49 531 391-3289 363 EMail: schoenw@ibr.cs.tu-bs.de"; 365 description "This module defines core filter classes for 366 the Internet protocol suite."; 368 revision { 369 date "2000-11-23"; 370 description "Initial revision."; 371 }; 373 class Filter { 374 attribute DisplayString255 name { 375 access readwrite; 376 description 377 "The administratively assigned name of the filter."; 378 }; 379 attribute Counter64 packets { 380 access readonly; 381 units "packets"; 382 "The number of packets matching this filter."; 383 }; 384 attribute Counter64 bytes { 385 access readonly; 386 units "bytes"; 387 description 388 "The number of bytes contained in packets matching 389 this filter."; 390 }; 391 description 392 "A generic filter. Classes derived from this generic filter 393 must introduce additional attributes which define the 394 filter parameters."; 395 }; 397 class InetFilter : Filter { 398 attribute InetSubnet srcSubNet { 399 description 400 "The subnet to match against the packet's 401 source address."; 402 }; 403 attribute InetSubnet dstSubNet { 404 description 405 "The subnet to match against the packet's 406 destination address."; 408 }; 409 attribute InetPortRange srcPortRange { 410 description 411 "The port range to match against the packet's 412 source port." 413 }; 414 attribute InetPortRange dstPortRange { 415 description 416 "The port range to match against the packet's 417 destination port."; 418 }; 419 attribute InetProtocolNumber protocol { 420 access readwrite; 421 description 422 "The protocol number to match against the packet's 423 Internet Protocol version. A value of zero 424 matches any IP version."; 425 }; 426 attribute InetDiffServCodePoint dscp { 427 access readwrite; 428 description 429 "The value that the DSCP in the packet must have to 430 match this entry. A value of -1 indicates that a 431 specific DSCP value has not been defined and thus all 432 DSCP values are considered a match."; 433 } 434 description 435 "This class represents a generic Internet Protocol filter. 436 Classes derived from this class may add attributes which 437 define further filter criteria."; 438 }; 440 }; 442 4. Usage Examples 444 The following example shows how a TCP connection might be modelled. 445 The class definition below could be used to derive an IP version 446 independent MIB for representing open TCP connections. 448 module IRTF-NMRG-TCP { 450 import IRTF-NMRG-INET (InetTransportEndpoint); 452 // ... 454 typedef TcpConnectionState { 455 type Enumeration (closed(1), listen(2), synSent(3), 456 synReceived(4), established(5), 457 finWait1(6), finWait2(7), closeWait(8), 458 lastAck(9), closing(10), timeWait(11)); 459 description 460 "The state of a TCP connection."; 461 reference 462 "STD 7 (RFC 793)"; 463 }; 465 typedef TcpConnectionCtrl { 466 type Enumeration (none(0), delete(1)); 467 description 468 "The enumerated numbers defined by this type allow to control 469 TCP connections. The value none(0) will be reported whenever 470 an attribute of this type is read. 472 The only value which may be written is delete(1). If a 473 management station writes the value delete(1), then this 474 has the effect of deleting the TCB (as defined in RFC 793) 475 of the corresponding connection on the managed node, 476 resulting in immediate termination of the connection. 478 As an implementation-specific option, a RST segment may be 479 sent from the managed node to the other TCP endpoint (note 480 however that RST segments are not sent reliably)."; 481 }; 483 class TcpConnection { 484 attribute InetTransportEndpoint local { 485 description 486 "The local endpoint of the TCP connection."; 487 }; 488 attribute InetTransportEndpoint remote { 489 description 490 "The remote endpoint of the TCP connection."; 491 }; 492 attribute TcpConnectionState state { 493 access readonly; 494 description 495 "The current state of the TCP connection."; 496 }; 497 attribute TcpConnectionCtrl ctrl { 498 access readwrite; 499 description 500 "A control which allows to change the state of the 501 TCP connection."; 502 }; 503 description 504 "This class contains information about a particular current 505 TCP connection."; 507 }; 508 }; 510 5. Security Considerations 512 This module does not define any management objects. Instead, it 513 defines a set of SMIng types and classes which may be used by other 514 SMIng modules to define management objects. These data definitions 515 have no security impact on the Internet. 517 6. Acknowledgments 519 This document was produced by the Network Management Research Group 520 (NMRG) of the Internet Research Task Force (IRTF). 522 Some definitions in this document are derived from RFC 2851 [3], 523 which was written by M. Daniele, B. Haberman, S. Routhier and J. 524 Schoenwaelder. 526 References 528 [1] Strauss, F., Schoenwaelder, J., McCloghrie, K., "SMIng - Next 529 Generation Structure of Management Information", 530 draft-irtf-nmrg-sming-04.txt, November 2000. 532 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 533 Levels", RFC 2119, BCP 14, March 1997. 535 [3] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J., 536 "Textual Conventions for Internet Network Addresses", RFC 2851, 537 June 2000. 539 Authors' Addresses 541 Frank Strauss 542 TU Braunschweig 543 Bueltenweg 74/75 544 38106 Braunschweig 545 Germany 547 Phone: +49 531 391-3266 548 EMail: strauss@ibr.cs.tu-bs.de 549 URI: http://www.ibr.cs.tu-bs.de/ 550 Juergen Schoenwaelder 551 TU Braunschweig 552 Bueltenweg 74/75 553 38106 Braunschweig 554 Germany 556 Phone: +49 531 391-3289 557 EMail: schoenw@ibr.cs.tu-bs.de 558 URI: http://www.ibr.cs.tu-bs.de/ 560 Keith McCloghrie 561 Cisco Systems 562 170 West Tasman Drive 563 San Jose, CA 95134-1706 564 USA 566 Phone: +1 408 526 5260 567 EMail: kzm@cisco.com 568 URI: http://www.cisco.com/ 570 Appendix A. OPEN ISSUES 572 1. There might be more core type or class definitions that should 573 go into the IRTF-NMRG-SMING-INET module. 574 2. The filters probably need more work to cover more cases. 575 3. Is it useful to include more examples, e.g. on the usage of 576 filters or subnets? 577 4. Does the InetDiffServCodePoint type definition really belong 578 into this module? 579 5. 255a or 255t? Length restriction? 580 6. Check the attribute identifiers and descriptions of 581 InetTransportEndpoint and InetSubnet: when should the term 582 endpoint be used, and when address? Should an InetProtocolNumber 583 attribute be added to InetTransportEndpoint? 585 Full Copyright Statement 587 Copyright (C) The Internet Society (2000). All Rights Reserved. 589 This document and translations of it may be copied and furnished to 590 others, and derivative works that comment on or otherwise explain it 591 or assist in its implmentation may be prepared, copied, published 592 and distributed, in whole or in part, without restriction of any 593 kind, provided that the above copyright notice and this paragraph 594 are included on all such copies and derivative works. However, this 595 document itself may not be modified in any way, such as by removing 596 the copyright notice or references to the Internet Society or other 597 Internet organizations, except as needed for the purpose of 598 developing Internet standards in which case the procedures for 599 copyrights defined in the Internet Standards process must be 600 followed, or as required to translate it into languages other than 601 English. 603 The limited permissions granted above are perpetual and will not be 604 revoked by the Internet Society or its successors or assigns. 606 This document and the information contained herein is provided on an 607 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 608 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 609 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 610 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 611 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.