Network Working GroupJ. Schoenwaelder Internet-DraftF. Strauss Internet-Draft J. Schoenwaelder Expires: May11,25, 2001 TU Braunschweig K. McCloghrie Cisco Systems November10,24, 2000 SMIng Internet Protocol Core Modulesdraft-irtf-nmrg-sming-inet-modules-00.txtdraft-irtf-nmrg-sming-inet-modules-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed athttp://www.ietf.org/ietf/1id-abstracts.txthttp://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on May11,25, 2001. Abstract This memodefinespresents SMIng[1]modulesforthat introduce commonly used Internetnetwork layer addressing information. The intent isProtocol specific data definitions. They are provided so thatthese definitions will be imported and used inother SMIng modules that would otherwise define their ownrepresentations. This documentrepresentations can import them from a common place. The IRTF-NMRG-INET module defines types and classes for representing Internet Protocol specific information. It builds on RFC 2851[3]and extends it inmanyseveral ways. The IRTF-NMRG-INET-FILTER module extends the IRTF-NMRG-INET module by providing generic definitions for typical IP packet filters. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Table of Contents 1.IRTF-NMRG-INETIntroduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IRTF-NMRG-INET . . . . . . . . . . . . . . . . . . . . . . . . 3 3. IRTF-NMRG-INET-FILTER . . . . . . . . . . . . . . . . . . . . 83.4. Usage Examples . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . .10 4.12 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .1112 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 A. OPEN ISSUES . . . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction SMIng [1] modules frequently need to represent Internet Protocol specific information such as IP addresses. This memo contains SMIng modules which define a core set of SMIng types and classes to be imported by other SMIng modules. The IRTF-NMRG-INET module provides core SMIng data definitions for the Internet Protocol suite. This module is derived from [3]. The IRTF-NMRG-INET-FILTER module provides SMIng data definitions that model Internet Protocol filters and components thereof. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [2]. 2. IRTF-NMRG-INET module IRTF-NMRG-INET { organization "IRTF Network Management Research Group(NMRG), Network Management Group, TU Braunschweig";(NMRG)"; contact "Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531391-3266391-3289 EMail: schoenw@ibr.cs.tu-bs.de"; description "This module defines core types and classes for the InternetprotocolProtocol suite. This document builds upon RFC 2851 and extends it in variousways."ways."; revision { date"2000-11-10";"2000-11-23"; description "Initialrevision.";revision, published as RFC XXXX."; }; // //coreCore type definitions for the Internet Protocolsuitesuite. // typedefInetPortInetPortNumber { type Unsigned32 (0..65535); description "Represents a 16 bit port number of an Internet transport layerprotocol.";protocol. Port numbers are assigned by IANA. A list of all assignments is available at the following location: http://www.isi.edu/in-notes/iana/assignments/port-numbers"; reference "STD 6 (RFC 768), STD 7 (RFC 793) and RFC 2960"; }; typedefInetProtocolInetProtocolNumber { type Unsigned32 (0..255); description "Represents an 8 bit protocol number which indicates the next upper-layer protocol used in the data portion of an Internet datagram. Protocol(IP) protocol number.";numbers are assigned by IANA. A list of all assignments is available at the following location: http:// www.isi.edu/in-notes/iana/assignments/protocol-numbers"; reference "STD 5 (RFC 791) Section 3.1 and RFC 2460 Section 3."; }; typedef InetDiffServCodePoint { type Unsigned32 (-1, 0..63); description "Represents a 6 bit Differentiated Services Code Point (DSCP). The special value -1 may be used to indicate that the DSCP is not relevant."; reference "RFC 2474"; }; typedef InetAddress { type OctetString; description "Represents a generic IP version neutral Internet address."; }; typedef InetAddressMask { type Unsigned32; description "Represents an address prefix length (traditionally called an address mask) for generic Internet addresses."; }; // // Internet Protocol address types for specific IPversionsversions. // typedef InetAddressType { type Enumeration (unknown(0), ipv4(1), ipv6(2), dns(16)); description "A value that represents a type of Internet address. unknown(0) An unknown address type. This value MUST be used if the value of the corresponding addressobjectattribute is a zero-length string. It may also be used to indicate an IP address which is not in one of the formats defined below. ipv4(1) An IPv4 address as defined by the InetAddressIPv4 type. ipv6(2) An IPv6 address as defined by the InetAddressIPv6 type. dns(16) A DNS domain name as defined by the InetAddressDNS type. The type SHOULD NOT be subtypedin object type definitionsto support future extensions. It MAY be subtyped in compliance statements in order to require only a subset of these address types for a compliant implementation."; }; typedef InetAddressIPv4 { type InetAddress (4); format "1d.1d.1d.1d"; description "Represents a 32 bit IP version 4 (IPv4) network address: octets contents encoding 1-4 IPv4 address network-byte order If there is a corresponding InetAddressType attribute, its value MUST be ipv4(1)."; reference "STD 5 (RFC 791)"; }; typedef InetAddressIPv6 { type InetAddress (16 | 20); format "2x:2x:2x:2x:2x:2x:2x:2x%4d"; description "Representsana 128 bit IPv6 networkaddress:address plus an optional 32 bit scope identifier: octets contents encoding 1-16 IPv6 address network-byte order 17-20 scope identifier network-byte order If there is a corresponding InetAddressType attribute, its value MUST be ipv6(2). The scope identifier (bytes 17-20) MUST NOT be present for global IPv6 addresses. For non-global IPv6 addresses (e.g. link-local or site-local addresses), the scope identifier MUST always be present. It contains a link identifier for link-local and a site identifier for site-local IPv6 addresses. The scope identifier MUST disambiguate identical address values. For link-local addresses, the scope identifier will typically be the interface index (ifIndex as defined in the IF-MIB, RFC 2233) of the interface on which the address is configured. The scope identifier may contain the special value 0 which refers to the default scope. The default scope may be used in cases where the valid scope identifier is not known (e.g., a management application needs to write a site-local InetAddressIPv6 address without knowing the site identifier value). The default scope SHOULD NOT be used as an easy way out in cases where the scope identifier for a non-global IPv6 address is known."; reference "RFC 2373"; }; typedef InetAddressDNS { type InetAddress (1..255); format "255a"; description "Represents a DNS domain name. The name SHOULD be fully qualified whenever possible. If there is a corresponding InetAddressType attribute, its value MUST be dns(16). The descriptions ofobjectsattributes of this type must fully describe how (and when) such names are to be resolved to IP addresses."; }; // //genericCore class definitions for the Internet Protocolendpointssuite. // classInetEndpointInetNetworkEndpoint { attribute InetAddressType type { access readwrite; description "The type of this Internet Protocol endpoint."; }; attribute InetAddress address { typemap type { map ipv4InetAddressIPv4,InetAddressIPv4; map ipv6InetAddressIPv6,InetAddressIPv6; map dnsInetAddressDNSInetAddressDNS; }; access readwrite; description "The address of this Internet Protocol endpoint. An address value is always interpreted within the context of the type value. The type attribute defines the context."; }; description"...";."This class defines a generic Internet Protocol endpoint at the network layer."; };// //class InetTransportEndpoint { attribute InetNetworkEndpoint address { description "The network layer endpoint."; }; attribute InetPortNumber port { description "The transport layer port number."; }; description "This class defines a generic transport layer endpoint for the Internet Protocolsubnets //suite."; }; class InetSubnet { attributeInetEndpointInetNetworkEndpoint endpoint {access readwrite;description"An"A network layer endpointinwithin the Internet Protocol subnet."; } attribute InetAddressMask mask {access readwrite;description "The address mask which identifies the subnet portion of the address of the network layer endpoint."; }; description"...";. }; // //"This class defines a generic Internet Protocoltransport layer endpoints //subnet."; }; classInetTransportEndpointInetPortNumberRange { attributeInetEndpoint addressInetPortNumber start { access readwrite; description"";"The first port number in the port range."; }; attributeInetPort port;InetPortNumber end { access readwrite; description"";"The last port number in the port range."; }; description"...";."This class represents a range of consecutive Internet transport layer port numbers. The start and end port numbers are included in the range of consecutive port numbers."; }; };2.3. IRTF-NMRG-INET-FILTER module IRTF-NMRG-INET-FILTER { import IRTF-NMRG-INET(InetPort,(InetProtocolNumber, InetDiffServCodePoint, InetPortNumberRange, InetSubnet); import IRTF-NMRG-SMING (Counter64, DisplayString255); organization "IRTF Network Management Research Group(NMRG), Network Management Group, TU Braunschweig";(NMRG)"; contact "Juergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531391-3266391-3289 EMail: schoenw@ibr.cs.tu-bs.de"; description "This module defines core filter classes for the Internet protocol suite."; revision { date"2000-11-10";"2000-11-23"; description "Initial revision."; }; classInetPortRangeFilter { attributeInetPort startDisplayString255 name { access readwrite; description "Thefirst port number inadministratively assigned name of theport range.";filter."; }; attributeInetPort endCounter64 packets { accessreadwrite; descriptionreadonly; units "packets"; "Thelast portnumberin the port range.";of packets matching this filter."; }; attribute Counter64 bytes { access readonly; units "bytes"; description"This class represents a range"The number ofconsecutive Internet transport layer port numbers. The start and end port numbers are includedbytes contained in packets matching this filter."; }; description "A generic filter. Classes derived from this generic filter must introduce additional attributes which define therange of consecutive port numbers.";filter parameters."; }; classBaseFilterInetFilter : Filter { attributeDisplayString nameInetSubnet srcSubNet {access readwrite;description"...";"The subnet to match against the packet's source address."; }; attributeCounter64 byteCountInetSubnet dstSubNet { description "The subnet to match against the packet's destination address."; }; attribute InetPortRange srcPortRange { description "The port range to match against the packet's source port." }; attribute InetPortRange dstPortRange { description "The port range to match against the packet's destination port."; }; attribute InetProtocolNumber protocol { accessreadonly;readwrite; description"...";"The protocol number to match against the packet's Internet Protocol version. A value of zero matches any IP version."; }; attributeCounter64 packetCountInetDiffServCodePoint dscp { accessreadonly;readwrite; description"...";"The value that the DSCP in the packet must have to match this entry. A value of -1 indicates that a specific DSCP value has not been defined and thus all DSCP values are considered a match."; } description "This class represents a generic Internet Protocol filter. Classes derived from this class may add attributes which define further filter criteria."; }; }; 4. Usage Examples The following example shows how a TCP connection might be modelled. The classFiveTupleFilter : BaseFilterdefinition below could be used to derive an IP version independent MIB for representing open TCP connections. module IRTF-NMRG-TCP {attribute InetSubnet srcSubNetimport IRTF-NMRG-INET (InetTransportEndpoint); // ... typedef TcpConnectionState { type Enumeration (closed(1), listen(2), synSent(3), synReceived(4), established(5), finWait1(6), finWait2(7), closeWait(8), lastAck(9), closing(10), timeWait(11)); description"..."; //"The state of a TCP connection."; reference "STD 7 (RFC 793)"; }; typedef TcpConnectionCtrl { type Enumeration (none(0), delete(1)); descriptionoptional?!"The enumerated numbers defined by this type allow to control TCP connections. The value none(0) will be reported whenever an attribute of this type is read. The only value which may be written is delete(1). If a management station writes the value delete(1), then this has the effect of deleting the TCB (as defined in RFC 793) of the corresponding connection on the managed node, resulting in immediate termination of the connection. As an implementation-specific option, a RST segment may be sent from the managed node to the other TCP endpoint (note however that RST segments are not sent reliably)."; }; class TcpConnection { attributeInetSubnet dstSubNetInetTransportEndpoint local { description"...";"The local endpoint of the TCP connection."; }; attributeInetPortRange srcPortRangeInetTransportEndpoint remote { description"...";"The remote endpoint of the TCP connection."; }; attributeInetPortRange dstPortRangeTcpConnectionState state { access readonly; description"...";"The current state of the TCP connection."; }; attributeInetProtocol protocolTcpConnectionCtrl ctrl { access readwrite; description"...";"A control which allows to change the state of the TCP connection."; }; description "This class contains information about a particular current TCP connection."; }; };3.5. Security Considerations This module does not define any management objects. Instead, it defines a set of SMIng types and classes which may be used by other SMIng modules to define management objects.MeaningfulThese data definitions have no securityconsiderations can only be written inimpact on themodules that define management objects. 4.Internet. 6. AcknowledgmentsTheThis documentbuilds onwas produced by the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). Some definitions in this document are derived from RFC 2851 [3], which was written by M. Daniele, B. Haberman, S. Routhier and J. Schoenwaelder.The authors would like to thank Randy Bush, Richard Draves, Mark Ellison, Bill Fenner, Jun-ichiro Hagino, Tim Jenkins, Glenn Mansfield, Keith McCloghrie, Thomas Narten, Erik Nordmark, Peder Chr. Norgaard, Randy Presuhn, Andrew Smith, Dave Thaler, Kenneth White, Bert Wijnen, and Brian Zill for their comments and suggestions.References [1] Strauss, F., Schoenwaelder, J., McCloghrie, K., "SMIng -A newNext Generation Structure of Management Information",Octoberdraft-irtf-nmrg-sming-04.txt, November 2000. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [3] Daniele, M., Haberman, B., Routhier, S., Schoenwaelder, J., "Textual Conventions for Internet Network Addresses", RFC 2851, June 2000. Authors' AddressesJuergen SchoenwaelderFrank Strauss TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531391-3289391-3266 EMail:schoenw@ibr.cs.tu-bs.destrauss@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/Frank StraussJuergen Schoenwaelder TU Braunschweig Bueltenweg 74/75 38106 Braunschweig Germany Phone: +49 531391-3266391-3289 EMail:strauss@ibr.cs.tu-bs.deschoenw@ibr.cs.tu-bs.de URI: http://www.ibr.cs.tu-bs.de/ Keith McCloghrie Cisco Systems 170 West Tasman Drive San Jose, CA 95134-1706 USA Phone: +1 408 526 5260 EMail: kzm@cisco.com URI: http://www.cisco.com/ Appendix A. OPEN ISSUES 1. There might be more core type or class definitions that should go into the IRTF-NMRG-SMING-INET module. 2. The filters probably need more work to cover more cases. 3. Is it useful to include more examples, e.g. on the usage of filters or subnets? 4. Does the InetDiffServCodePoint type definition really belong into this module? 5. 255a or 255t? Length restriction? 6. Check the attribute identifiers and descriptions of InetTransportEndpoint and InetSubnet: when should the term endpoint be used, and when address? Should an InetProtocolNumber attribute be added to InetTransportEndpoint? Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.