idnits 2.17.1 draft-ietf-softwire-map-mib-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 17, 2015) is 3235 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) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Y. Fu 3 Internet-Draft CNNIC 4 Intended status: Standards Track S. Jiang 5 Expires: December 19, 2015 B. Liu 6 Huawei Technologies Co., Ltd 7 J. Dong 8 Y. Chen 9 Tsinghua University 10 June 17, 2015 12 Definitions of Managed Objects for MAP-E 13 draft-ietf-softwire-map-mib-04 15 Abstract 17 This memo defines a portion of the Management Information Base (MIB) 18 for using with network management protocols in the Internet 19 community. In particular, it defines managed objects for MAP 20 encapsulation mode. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on December 19, 2015. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 2. The Internet-Standard Management Framework . . . . . . . . . 3 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 4. Structure of the MIB Module . . . . . . . . . . . . . . . . . 3 72 4.1. The mapMIBObjects . . . . . . . . . . . . . . . . . . . . 3 73 4.1.1. The mapRule Subtree . . . . . . . . . . . . . . . . . 3 74 4.1.2. The mapSecurityCheck Subtree . . . . . . . . . . . . 3 75 4.2. The mapMIBConformance Subtree . . . . . . . . . . . . . . 4 76 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 9.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 85 1. Introduction 87 MAP [I-D.ietf-softwire-map] is a stateless mechanism for running IPv4 88 over IPv6-only infrastructure. In particular, it includes two mode, 89 translation mode or encapsulation mode. For the encapsulation mode, 90 it provides an automatic tunnelling mechanism for providing IPv4 91 connectivity service to end users over a service provider's IPv6 92 network 94 This document defines a portion of the Management Information Base 95 (MIB) for use with network management protocols in the Internet 96 community. This MIB module would be used for monitoring the devices 97 in the MAP scenario, especially, for the encapsulation mode. 99 2. The Internet-Standard Management Framework 101 For a detailed overview of the documents that describe the current 102 Internet-Standard Management Framework, please refer to section 7 of 103 [RFC3410]. 105 Managed objects are accessed via a virtual information store, termed 106 the Management Information Base or MIB. MIB objects are generally 107 accessed through the Simple Network Management Protocol (SNMP). 108 Objects in the MIB are defined using the mechanisms defined in the 109 Structure of Management Information (SMI). This memo specifies a MIB 110 module that is compliant to the SMIv2, which is described in 111 [RFC2578], [RFC2579] and [RFC2580]. 113 3. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 117 "OPTIONAL" in this document are to be interpreted as described in 118 [RFC2119]. 120 4. Structure of the MIB Module 122 The MAP-E MIB provides a way to configure and monitor the devices in 123 MAP encapsulation mode through SNMP. 125 MAP-E MIB is configurable on a per-interface basis. It depends on 126 several parts of the IF-MIB[RFC2863]. 128 4.1. The mapMIBObjects 130 4.1.1. The mapRule Subtree 132 The mapRule subtree describes managed objects used for managing the 133 multiple mapping rules in the MAP encapsulation mode. 135 According to the MAP specification, the mapping rules are divided 136 into two categories, which are BMR (Basic Mapping Rule), and FMR 137 (Forwarding Mapping Rule). 139 4.1.2. The mapSecurityCheck Subtree 141 The mapSecurityCheck subtree is to statistic the number of invalid 142 packets that have been identified. There are two kind of invalid 143 packets which are defined in the MAP specification as the following. 145 - The BR MUST perform a validation of the consistency of the source 146 IPv6 address and source port number for the packet using BMR. 148 - The CE SHOULD check that MAP received packets' transport-layer 149 destination port number is in the range configured by MAP for the CE. 151 4.2. The mapMIBConformance Subtree 153 The mapMIBConformance subtree provides conformance information of MIB 154 objects. 156 5. Definitions 158 MAP-E-MIB DEFINITIONS ::= BEGIN 160 IMPORTS 161 MODULE-IDENTITY, OBJECT-TYPE, transmission, 162 Integer32, Unsigned32, Counter64 163 FROM SNMPv2-SMI 164 ifIndex 165 FROM IF-MIB 166 InetAddressType, InetAddress, 167 InetAddressPrefixLength 168 FROM INET-ADDRESS-MIB 169 OBJECT-GROUP, MODULE-COMPLIANCE 170 FROM SNMPv2-CONF; 172 mapMIB MODULE-IDENTITY 173 LAST-UPDATED "201506170000Z" 174 ORGANIZATION 175 "IETF Softwire Working Group" 176 CONTACT-INFO 177 "Yu Fu 178 CNNIC 179 No.4 South 4th Street, Zhongguancun 180 Beijing, P.R. China 100190 181 EMail: fuyu@cnnic.cn 183 Sheng Jiang 184 Huawei Technologies Co., Ltd 185 Huawei Building, 156 Beiqing Rd., Hai-Dian District 186 Beijing, P.R. China 100095 187 EMail: jiangsheng@huawei.com 189 Bing Liu 190 Huawei Technologies Co., Ltd 191 Huawei Building, 156 Beiqing Rd., Hai-Dian District 192 Beijing, P.R. China 100095 193 EMail: leo.liubing@huawei.com 195 Jiang Dong 196 Tsinghua University 197 Department of Computer Science, Tsinghua University 198 Beijing 100084 199 P.R. China 200 Email: knight.dongjiang@gmail.com 202 Yuchi Chen 203 Tsinghua University 204 Department of Computer Science, Tsinghua University 205 Beijing 100084 206 P.R. China 207 Email: chenycmx@gmail.com" 209 DESCRIPTION 210 "The MIB module is defined for management of objects in the 211 MAP-E BRs or CEs." 212 REVISION "201506170000Z" 213 DESCRIPTION 214 "Initial version. Published as RFC xxxx." 215 --RFC Ed.: RFC-edtitor pls fill in xxxx 216 ::= { transmission xxx } 217 --xxx to be replaced withIANA-assigned value 219 mapMIBObjects OBJECT IDENTIFIER ::= {mapMIB 1} 221 mapRule OBJECT IDENTIFIER 222 ::= { mapMIBObjects 1 } 224 mapSecurityCheck OBJECT IDENTIFIER 225 ::= { mapMIBObjects 2 } 227 mapRuleTable OBJECT-TYPE 228 SYNTAX SEQUENCE OF MapRuleEntry 229 MAX-ACCESS not-accessible 230 STATUS current 231 DESCRIPTION 232 "The (conceptual) table containing rule Information of 233 specific mapping rule. It can also be used for row 234 creation." 235 ::= { mapRule 1 } 237 mapRuleEntry OBJECT-TYPE 238 SYNTAX MapRuleEntry 239 MAX-ACCESS not-accessible 240 STATUS current 241 DESCRIPTION 242 "Each entry in this table contains the information on a 243 particular mapping rule." 244 INDEX { mapRuleID } 245 ::= { mapRuleTable 1 } 247 MapRuleEntry ::= 248 SEQUENCE { 249 mapRuleID Integer32, 250 mapRuleIPv6PrefixType InetAddressType, 251 mapRuleIPv6Prefix InetAddress, 252 mapRuleIPv6PrefixLen InetAddressPrefixLength, 253 mapRuleIPv4PrefixType InetAddressType, 254 mapRuleIPv4Prefix InetAddress, 255 mapRuleIPv4PrefixLen InetAddressPrefixLength, 256 mapRulePSID Integer32, 257 mapRulePSIDLen Integer32, 258 mapRuleOffset Unsigned32, 259 mapRuleEALen Integer32, 260 mapRuleType Integer32 261 } 263 mapRuleID OBJECT-TYPE 264 SYNTAX Integer32 (1..2147483647) 265 MAX-ACCESS not-accessible 266 STATUS current 267 DESCRIPTION 268 "An identifier used to distinguish the multiple mapping 269 rule which is unique with each CE in the same BR." 270 ::= { mapRuleEntry 1 } 272 mapRuleIPv6PrefixType OBJECT-TYPE 273 SYNTAX InetAddressType 274 MAX-ACCESS read-create 275 STATUS current 276 DESCRIPTION 277 "In this object, it MUST be set to the value of 2 to 278 present IPv6 type. It complies the textule convention 279 of IPv6 address defined in [RFC4001]." 280 ::= { mapRuleEntry 2 } 282 mapRuleIPv6Prefix OBJECT-TYPE 283 SYNTAX InetAddress 284 MAX-ACCESS read-create 285 STATUS current 286 DESCRIPTION 287 "The IPv6 prefix defined in mapping rule which will be 288 assigned to CE ." 290 ::= { mapRuleEntry 3 } 292 mapRuleIPv6PrefixLen OBJECT-TYPE 293 SYNTAX InetAddressPrefixLength 294 MAX-ACCESS read-create 295 STATUS current 296 DESCRIPTION 297 "The length of the IPv6 prefix defined in the mapping rule. 298 As a parameter for mapping rule, it will be also assigned 299 to CE." 300 ::= { mapRuleEntry 4 } 302 mapRuleIPv4PrefixType OBJECT-TYPE 303 SYNTAX InetAddressType 304 MAX-ACCESS read-create 305 STATUS current 306 DESCRIPTION 307 "In this object, it MUST be set to the value of 1 to 308 present IPv4 type. It complies the textual convention 309 of IPv6 address defined in [RFC4001]." 310 ::= { mapRuleEntry 5 } 312 mapRuleIPv4Prefix OBJECT-TYPE 313 SYNTAX InetAddress 314 MAX-ACCESS read-create 315 STATUS current 316 DESCRIPTION 317 " The IPv4 prefix defined in mapping rule which will be 318 assigned to CE." 319 ::= { mapRuleEntry 6 } 321 mapRuleIPv4PrefixLen OBJECT-TYPE 322 SYNTAX InetAddressPrefixLength 323 MAX-ACCESS read-create 324 STATUS current 325 DESCRIPTION 326 "The length of the IPv4 prefix defined in the mapping 327 rule. As a parameter for mapping rule, it will be also 328 assigned to CE." 329 ::= { mapRuleEntry 7 } 331 mapRulePSID OBJECT-TYPE 332 SYNTAX Integer32 333 MAX-ACCESS read-create 334 STATUS current 335 DESCRIPTION 336 "The PSID value algorithmically identifies a set of 337 ports assigned to a CE." 339 ::= { mapRuleEntry 8 } 341 mapRulePSIDLen OBJECT-TYPE 342 SYNTAX Integer32 343 MAX-ACCESS read-create 344 STATUS current 345 DESCRIPTION 346 "The bit length value of the number of significant bits in 347 the PSID field. When it is set to 0, the PSID 348 field is to be ignored.." 349 ::= { mapRuleEntry 9 } 351 mapRuleOffset OBJECT-TYPE 352 SYNTAX Unsigned32(0..15) 353 MAX-ACCESS read-create 354 STATUS current 355 DESCRIPTION 356 "Bit length value of the number of significant bits in 357 the PSID field. When it is set to 0, the PSID 358 field is to be ignored.." 359 ::= { mapRuleEntry 10 } 361 mapRuleEALen OBJECT-TYPE 362 SYNTAX Integer32 363 MAX-ACCESS read-create 364 STATUS current 365 DESCRIPTION 366 "The length of the Embedded-Address (EA) defined in 367 mapping rule which will be assigned to CE." 368 ::= { mapRuleEntry 11 } 370 mapRuleType OBJECT-TYPE 371 SYNTAX Integer32 372 MAX-ACCESS read-create 373 STATUS current 374 DESCRIPTION 375 "The type of the mapping rule. A value of 0 means it 376 is a BMR; a non-zero value means it is a FMR." 377 ::= { mapRuleEntry 12 } 379 mapSecurityCheckTable OBJECT-TYPE 380 SYNTAX SEQUENCE OF MapSecurityCheckEntry 381 MAX-ACCESS not-accessible 382 STATUS current 383 DESCRIPTION 384 "The (conceptual) table containing information on 385 MAP security checks. This table can be used to statistic 386 the number of invalid packets that been identified" 388 ::= { mapSecurityCheck 1 } 390 mapSecurityCheckEntry OBJECT-TYPE 391 SYNTAX MapSecurityCheckEntry 392 MAX-ACCESS not-accessible 393 STATUS current 394 DESCRIPTION 395 "Each entry in this table contains the information on a 396 particular MAP SecurityCheck." 397 INDEX { ifIndex } 398 ::= { mapSecurityCheckTable 1 } 400 MapSecurityCheckEntry ::= 401 SEQUENCE { 402 mapSecurityCheckInvalidv4 Counter64, 403 mapSecurityCheckInvalidv6 Counter64 405 } 407 mapSecurityCheckInvalidv4 OBJECT-TYPE 408 SYNTAX Counter64 409 MAX-ACCESS accessible-for-notify 410 STATUS current 411 DESCRIPTION 412 "The CE SHOULD check that MAP received packets' 413 transport-layer destination port number is in the range 414 configured by MAP for the CE. So this object indicate 415 the number of the invalid IPv4 packets received by the 416 MAP." 417 ::= { mapSecurityCheckEntry 1 } 419 mapSecurityCheckInvalidv6 OBJECT-TYPE 420 SYNTAX Counter64 421 MAX-ACCESS accessible-for-notify 422 STATUS current 423 DESCRIPTION 424 "The BR MUST perform a validation of the consistency of 425 the source IPv6 address and source port number for the 426 packet using BMR. So this object indicate the number of 427 the invalid IPv6 packets received by the BR." 428 ::= { mapSecurityCheckEntry 2 } 430 -- Conformance Information 431 mapMIBConformance OBJECT IDENTIFIER ::= {mapMIB 2} 432 mapMIBCompliances OBJECT IDENTIFIER ::= { mapMIBConformance 1 } 433 mapMIBGroups OBJECT IDENTIFIER ::= { mapMIBConformance 2 } 435 -- compliance statements 436 mapMIBCompliance MODULE-COMPLIANCE 437 STATUS current 438 DESCRIPTION 439 " Describes the minimal requirements for conformance 440 to the MAP-E MIB." 441 MODULE -- this module 442 MANDATORY-GROUPS { mapMIBRuleGroup , mapMIBSecurityGroup } 443 ::= { mapMIBCompliances 1 } 445 -- Units of Conformance 446 mapMIBRuleGroup OBJECT-GROUP 447 OBJECTS { 448 mapRuleIPv6PrefixType, 449 mapRuleIPv6Prefix, 450 mapRuleIPv6PrefixLen, 451 mapRuleIPv4PrefixType, 452 mapRuleIPv4Prefix, 453 mapRuleIPv4PrefixLen, 454 mapRulePSID, 455 mapRulePSIDLen, 456 mapRuleOffset, 457 mapRuleEALen, 458 mapRuleType } 459 STATUS current 460 DESCRIPTION 461 " The collection of this objects are used to give the 462 information of mapping rules in MAP-E." 463 ::= { mapMIBGroups 1 } 465 mapMIBSecurityGroup OBJECT-GROUP 466 OBJECTS { 467 mapSecurityCheckInvalidv4, 468 mapSecurityCheckInvalidv6 } 469 STATUS current 470 DESCRIPTION 471 " The collection of this objects are used to give the 472 information on MAP security checks." 473 ::= { mapMIBGroups 2 } 475 END 477 6. IANA Considerations 479 The MIB module in this document uses the following IANA-assigned 480 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 482 Descriptor OBJECT IDENTIFIER value 483 ---------- ----------------------- 484 MAP-E-MIB { transmission XXX } 486 7. Security Considerations 488 The MAP-E MIB module can be used for configuration of certain 489 objects, and anything that can be configured can be incorrectly 490 configured, with potentially disastrous results. Because this MIB 491 module reuses the IP tunnel MIB, the security considerations for 492 these MIBs are also applicable to the MAP-E MIB. 494 SNMP versions prior to SNMPv3 did not include adequate security. 495 Even if the network itself is secure (for example by using IPSec), 496 even then, there is no control as to who on the secure network is 497 allowed to access and GET/SET (read/change/create/delete) the objects 498 in this MIB module. 500 It is RECOMMENDED that implementers consider the security features as 501 provided by the SNMPv3 framework (see [RFC3410] , section 8), 502 including full support for the SNMPv3 cryptographic mechanisms (for 503 authentication and privacy). 505 Further, deployment of SNMP versions prior to SNMPv3 is NOT 506 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 507 enable cryptographic security. It is then a customer/operator 508 responsibility to ensure that the SNMP entity giving access to an 509 instance of this MIB module is properly configured to give access to 510 the objects only to those principals (users) that have legitimate 511 rights to indeed GET or SET (change/create/delete) them. 513 8. Acknowledgements 515 The authors would like to thank for valuable comments from David 516 Harrington, Mark Townsley, and Shishio Tsuchiya. 518 This document was produced using the xml2rfc tool [RFC2629]. 520 9. References 522 9.1. Normative References 524 [I-D.ietf-softwire-map] 525 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 526 Murakami, T., and T. Taylor, "Mapping of Address and Port 527 with Encapsulation (MAP)", draft-ietf-softwire-map-13 528 (work in progress), March 2015. 530 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 531 Requirement Levels", BCP 14, RFC 2119, March 1997. 533 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 534 Schoenwaelder, Ed., "Structure of Management Information 535 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 537 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 538 "Conformance Statements for SMIv2", STD 58, RFC 2580, 539 April 1999. 541 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 542 MIB", RFC 2863, June 2000. 544 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 545 Schoenwaelder, "Textual Conventions for Internet Network 546 Addresses", RFC 4001, February 2005. 548 9.2. Informative References 550 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 551 Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 552 58, RFC 2579, April 1999. 554 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 555 June 1999. 557 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 558 "Introduction and Applicability Statements for Internet- 559 Standard Management Framework", RFC 3410, December 2002. 561 Authors' Addresses 563 Yu Fu 564 CNNIC 565 No.4 South 4th Street, Zhongguancun 566 Beijing 100190 567 P.R. China 569 Email: fuyu@cnnic.cn 570 Sheng Jiang 571 Huawei Technologies Co., Ltd 572 Q14, Huawei Campus, No.156 Beiqing Road 573 Hai-Dian District, Beijing, 100095 574 P.R. China 576 Email: jiangsheng@huawei.com 578 Bing Liu 579 Huawei Technologies Co., Ltd 580 Q14, Huawei Campus, No.156 Beiqing Road 581 Hai-Dian District, Beijing, 100095 582 P.R. China 584 Email: leo.liubing@huawei.com 586 Jiang Dong 587 Tsinghua University 588 Department of Computer Science, Tsinghua University 589 Beijing 100084 590 P.R. China 592 Email: knight.dongjiang@gmail.com 594 Yuchi Chen 595 Tsinghua University 596 Department of Computer Science, Tsinghua University 597 Beijing 100084 598 P.R. China 600 Email: flashfoxmx@gmail.com