idnits 2.17.1 draft-schoenw-snmp-ether-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 371. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 348. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 355. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 361. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == The 'Obsoletes: ' line in the draft header should list only the _numbers_ of the RFCs which will be obsoleted by this document (if approved); it should not include the word 'RFC' in the list. -- The abstract seems to indicate that this document obsoletes RFC1089, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (September 21, 2006) is 6426 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) == Missing Reference: 'RFC3414' is mentioned on line 251, but not defined == Missing Reference: 'RFC3415' is mentioned on line 252, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 4133 (Obsoleted by RFC 6933) -- Obsolete informational reference (is this intentional?): RFC 1089 (Obsoleted by RFC 4789) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Schoenwaelder 3 Internet-Draft International University Bremen 4 Obsoletes: RFC1089 (if approved) T. Jeffree 5 Expires: March 25, 2007 Consultant 6 September 21, 2006 8 Simple Network Management Protocol (SNMP) over IEEE 802 Networks 9 draft-schoenw-snmp-ether-02.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on March 25, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document specifies how Simple Network Management Protocol (SNMP) 43 messages can be transmitted directly over IEEE 802 networks. 45 This document obsoletes RFC 1089. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 51 3. SNMP over IEEE 802 Networks . . . . . . . . . . . . . . . . . 5 52 3.1. Serialization . . . . . . . . . . . . . . . . . . . . . . 5 53 3.2. Well-known Values . . . . . . . . . . . . . . . . . . . . 5 54 3.3. IEEE 802.3 Frame Format . . . . . . . . . . . . . . . . . 6 55 4. Relationship to Other MIB Modules . . . . . . . . . . . . . . 6 56 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 57 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 63 Intellectual Property and Copyright Statements . . . . . . . . . . 11 65 1. Introduction 67 This document specifies how Simple Network Management Protocol (SNMP) 68 messages can be transmitted directly over IEEE 802 networks. For a 69 detailed overview of the documents that describe the Internet- 70 Standard management framework, please refer to section 7 of RFC 3410 71 [RFC3410]. This document supplements the standard SNMP transport 72 mappings defined in RFC 3417 [RFC3417]. 74 This document obsoletes RFC 1089. 76 Managed objects are accessed via a virtual information store, termed 77 the Management Information Base or MIB. MIB objects are generally 78 accessed through the Simple Network Management Protocol (SNMP). 79 Objects in the MIB are defined using the mechanisms defined in the 80 Structure of Management Information (SMI). This memo specifies a MIB 81 module that is compliant to the SMIv2, which is described in STD 58, 82 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 83 [RFC2580]. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 2. Definitions 91 SNMP-IEEE802-TM-MIB DEFINITIONS ::= BEGIN 93 IMPORTS 94 MODULE-IDENTITY, OBJECT-IDENTITY, snmpModules, snmpDomains 95 FROM SNMPv2-SMI; 97 snmpIeee802TmMib MODULE-IDENTITY 98 LAST-UPDATED "200605290000Z" 99 ORGANIZATION "IETF Operations and Management Area" 100 CONTACT-INFO 101 "Juergen Schoenwaelder (Editor) 102 International University Bremen 103 P.O. Box 750 561 104 28725 Bremen, Germany 106 Phone: +49 421 200-3587 107 EMail: j.schoenwaelder@iu-bremen.de 109 Send comments to ." 110 DESCRIPTION 111 "This MIB module defines the SNMP over IEEE 802 112 transport mapping. 114 Copyright (C) The Internet Society (2006). This version 115 of this MIB module is part of RFC XXXX; see the RFC 116 itself for full legal notices." 117 REVISION "200605290000Z" 118 DESCRIPTION 119 "The initial version, published as RFC XXXX." 120 -- RFC Ed.: replace XXXX with actual RFC number & remove this note 121 ::= { snmpModules xxx } 122 -- RFC Ed.: replace xxx with IANA-assigned number & remove this note 124 snmpIeee802Domain OBJECT-IDENTITY 125 STATUS current 126 DESCRIPTION 127 "The SNMP over IEEE 802 networks transport domain. The 128 corresponding transport address is of type MacAddress 129 as defined in the SNMPv2-TC module (RFC 2579)." 130 REFERENCE "RFC 2579" 131 ::= { snmpDomains xxx } 132 -- RFC Ed.: replace xxx with IANA-assigned number & remove this note 133 END 135 3. SNMP over IEEE 802 Networks 137 This is an optional transport mapping. 139 SNMP over IEEE 802 networks has some inherent restrictions. Using 140 the SNMP over IEEE 802 transport mapping restricts messages to a 141 single logical IEEE 802 LAN, bridged LAN or VLAN. Furthermore, only 142 a single SNMP engine can be addressed on a given IEEE 802 network 143 interface. In particular, command generators and notification 144 receivers as well as command responders and notification originators 145 must share a single transport endpoint. 147 3.1. Serialization 149 SNMP messages are serialized as described in Section 8 of RFC 3417 150 [RFC3417]. The resulting serialized message is shipped in the data 151 portion of an IEEE LAN MAC frame. 153 3.2. Well-known Values 155 Serialized SNMP messages are sent in IEEE 802.3 frames with an 156 Ethernet type field of 33100 (hexadecimal 814C). 158 When serialized SNMP messages are sent in IEEE 802.3 frames (and in 159 other IEEE 802 MAC frame types that can natively represent Ethernet 160 type values), an Ethernet type field value of 33100 (hexadecimal 161 814C) is used as the link layer protocol identifier. In IEEE 802 162 LANs that use LLC as the means of link layer protocol identification, 163 such as IEEE 802.11 Wireless LANs, the SNAP encapsulation method 164 described in subclause 10.5 "Encapsulation of Ethernet frames over 165 LLC" in [IEEE802] is used. 167 When an SNMP entity uses this transport mapping, it MUST be capable 168 of accepting SNMP messages up to and including 484 octets in size. 169 It is recommended that implementations be capable of accepting 170 messages of up to 1472 octets in size. Implementation of larger 171 values is encouraged whenever possible. 173 3.3. IEEE 802.3 Frame Format 175 0 1 176 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | Destination | 179 +- -+ 180 | Ethernet | 181 +- -+ 182 | Address | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Source | 185 +- -+ 186 | Ethernet | 187 +- -+ 188 | Address | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 |1 0 0 0 0 0 0 1 0 1 0 0 1 1 0 0| 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | SNMP | 193 +- -+ 194 / message ... / 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 (Each tic mark represents one bit.) 199 4. Relationship to Other MIB Modules 201 Several core SNMP MIB modules use TDomain/TAddress pairs to identify 202 SNMP transport endpoints. The SNMP-TARGET-MIB [RFC3413] uses 203 TDomain/TAddress pairs to identify targets that can be used as 204 notification receivers. TDomain/TAddress pairs are used by the 205 NOTIFICATION-LOG-MIB [RFC3014] to record the source from which a 206 notification was received. The ENTITY-MIB [RFC4133] uses TDomain/ 207 TAddress pairs to provide the transport endpoint of logical entities. 209 The MIB module contained in this document introduces the object 210 identifier constant snmpIeee802Domain. This constant can be assigned 211 to an object of type TDomain to identify an SNMP over IEEE 802 212 endpoint, in which case the corresponding TAddress will have a value 213 that conforms to the MacAddress textual convention. By providing 214 these definitions, it is possible to use the generic MIB modules to 215 refer to SNMP over IEEE 802 endpoints. 217 5. IANA Considerations 218 IANA has to make a MIB OID assignment under the snmpModules branch 219 for the SNMP-IEEE802-TM-MIB module. 221 IANA has to assign an OID value below snmpDomains for the transport 222 domain. This requires to first setup a registry for OIDs under 223 snmpDomains. At the point of this writing, the following assignments 224 already exist: 226 Prefix: iso.org.dod.internet.snmpv2.snmpDomains (1.3.6.1.6.1) 228 Decimal Name Description References 229 ------- ---- ----------- ---------- 230 1 snmpUDPDomain SNMP over UDP [RFC3417] 231 2 snmpCLNSDomain SNMP over CLNS [RFC3417] 232 3 snmpCONSDomain SNMP over CONS [RFC3417] 233 4 snmpDDPDomain SNMP over DDP [RFC3417] 234 5 snmpIPXDomain SNMP over IPX [RFC3417] 236 For new assignments a specification is required as per [RFC2434]. 238 6. Security Considerations 240 This module does not define any management objects. Instead, it 241 defines an OBJECT-IDENTIFIER which may be used by other MIB modules 242 to identify a SNMP transport mapping. Meaningful security 243 considerations can only be written in the MIB modules that define 244 management objects. The MIB module in this document has therefore no 245 impact on the security of the Internet. 247 SNMPv1 and SNMPv2c messages are not considered secure. It is 248 recommended that the implementors consider the use of SNMPv3 messages 249 and the security features as provided by the SNMPv3 framework. 250 Specifically, the use of the User-based Security Model STD 62, RFC 251 3414 [RFC3414] and the View-based Access Control Model STD 62, RFC 252 3415 [RFC3415] is recommended. 254 It is then a customer/user responsibility to ensure that the SNMP 255 entity giving access to a MIB is properly configured to give access 256 to the objects only to those principals (users) that have legitimate 257 rights to indeed GET or SET (change) them. 259 7. Acknowledgments 261 The original SNMP over Ethernet definition was written by Marty 262 Schoffstall, Chuck Davin, Mark Fedor, and Jeff Case and published as 263 RFC 1089 [RFC1089]. 265 Bert Wijnen and Dan Romascanu provided guidance on many aspects of 266 this revised specification. David Harrington provided useful 267 comments that improved the presentation. 269 8. References 271 8.1. Normative References 273 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 274 Requirement Levels", BCP 14, RFC 2119, March 1997. 276 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 277 Rose, M., and S. Waldbusser, "Structure of Management 278 Information Version 2 (SMIv2)", STD 58, RFC 2578, 279 April 1999. 281 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 282 Rose, M., and S. Waldbusser, "Textual Conventions for 283 SMIv2", STD 58, RFC 2579, April 1999. 285 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 286 Rose, M., and S. Waldbusser, "Conformance Statements for 287 SMIv2", STD 58, RFC 2580, April 1999. 289 [RFC3417] Presuhn (Editor), R., "Transport Mappings for the Simple 290 Network Management Protocol (SNMP)", STD 62, RFC 3417, 291 December 2002. 293 [IEEE802] "IEEE Standard for Local Area Networks: Overview and 294 Architecture", IEEE Std. 802-2001. 296 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 297 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 298 October 1998. 300 8.2. Informative References 302 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 303 "Introduction and Applicability Statements for Internet- 304 Standard Management Framework", RFC 3410, December 2002. 306 [RFC3413] Levi, D., Meyer, P., and B. Stewart, "Simple Network 307 Management Protocol (SNMP) Applications", RFC 3413, 308 December 2002. 310 [RFC3014] Kavasseri, R., "Notification Log MIB", RFC 3014, 311 November 2000. 313 [RFC4133] Bierman, A. and K. McCloghrie, "Entity MIB (Version 3)", 314 RFC 4133, August 2005. 316 [RFC1089] Schoffstall, M., Davin, C., Fedor, M., and J. Case, "SNMP 317 over Ethernet", RFC 1089, February 1989. 319 Authors' Addresses 321 Juergen Schoenwaelder 322 International University Bremen 323 Campus Ring 1 324 28725 Bremen 325 Germany 327 Phone: +49 421 200-3587 328 Email: j.schoenwaelder@iu-bremen.de 330 Tony Jeffree 331 Consultant 332 11a Poplar Grove 333 Sale, Cheshire, M33 3AX 334 United Kingdom 336 Phone: +44-161-973-4278 337 Email: tony@jeffree.co.uk 339 Intellectual Property Statement 341 The IETF takes no position regarding the validity or scope of any 342 Intellectual Property Rights or other rights that might be claimed to 343 pertain to the implementation or use of the technology described in 344 this document or the extent to which any license under such rights 345 might or might not be available; nor does it represent that it has 346 made any independent effort to identify any such rights. Information 347 on the procedures with respect to rights in RFC documents can be 348 found in BCP 78 and BCP 79. 350 Copies of IPR disclosures made to the IETF Secretariat and any 351 assurances of licenses to be made available, or the result of an 352 attempt made to obtain a general license or permission for the use of 353 such proprietary rights by implementers or users of this 354 specification can be obtained from the IETF on-line IPR repository at 355 http://www.ietf.org/ipr. 357 The IETF invites any interested party to bring to its attention any 358 copyrights, patents or patent applications, or other proprietary 359 rights that may cover technology that may be required to implement 360 this standard. Please address the information to the IETF at 361 ietf-ipr@ietf.org. 363 Disclaimer of Validity 365 This document and the information contained herein are provided on an 366 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 367 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 368 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 369 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 370 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 371 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 373 Copyright Statement 375 Copyright (C) The Internet Society (2006). This document is subject 376 to the rights, licenses and restrictions contained in BCP 78, and 377 except as set forth therein, the authors retain all their rights. 379 Acknowledgment 381 Funding for the RFC Editor function is currently provided by the 382 Internet Society.