idnits 2.17.1 draft-ietf-softwire-map-mib-05.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 (December 17, 2015) is 3050 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: June 19, 2016 B. Liu 6 Huawei Technologies Co., Ltd 7 J. Dong 8 Y. Chen 9 Tsinghua University 10 December 17, 2015 12 Definitions of Managed Objects for MAP-E 13 draft-ietf-softwire-map-mib-05 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 (MAP-E) 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 June 19, 2016. 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 . . . . . . . . . . . . . . . . . . . . . 11 78 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 79 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 80 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 9.1. Normative References . . . . . . . . . . . . . . . . . . 12 82 9.2. Informative References . . . . . . . . . . . . . . . . . 12 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 85 1. Introduction 87 MAP [RFC7597] is a stateless mechanism for running IPv4 over 88 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 MAP Border 123 Relay (BR) devices in 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 [RFC7597], the mapping rules are 136 divided into two categories, which are Basic Mapping Rule (BMR), and 137 Forwarding Mapping Rule (FMR). 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 below. 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, mib-2, 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 "201512180000Z" 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 "201512180000Z" 213 DESCRIPTION 214 "Initial version. Published as RFC xxxx." 215 --RFC Ed.: RFC-edtitor pls fill in xxxx 216 ::= { mib-2 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 REFERENCE 340 "PSID: section 3 of RFC 7597." 341 ::= { mapRuleEntry 8 } 343 mapRulePSIDLen OBJECT-TYPE 344 SYNTAX Integer32 345 MAX-ACCESS read-create 346 STATUS current 347 DESCRIPTION 348 "The bit length value of the number of significant bits in 349 the PSID field. When it is set to 0, the PSID 350 field is to be ignored.." 351 ::= { mapRuleEntry 9 } 353 mapRuleOffset OBJECT-TYPE 354 SYNTAX Unsigned32(0..15) 355 MAX-ACCESS read-create 356 STATUS current 357 DESCRIPTION 358 "Bit length value of the number of significant bits in 359 the PSID field. When it is set to 0, the PSID 360 field is to be ignored.." 361 ::= { mapRuleEntry 10 } 363 mapRuleEALen OBJECT-TYPE 364 SYNTAX Integer32 365 MAX-ACCESS read-create 366 STATUS current 367 DESCRIPTION 368 "The length of the Embedded-Address (EA) defined in 369 mapping rule which will be assigned to CE." 370 REFERENCE 371 "EA: section 3 of RFC 7597." 372 ::= { mapRuleEntry 11 } 374 mapRuleType OBJECT-TYPE 375 SYNTAX Integer32 376 MAX-ACCESS read-create 377 STATUS current 378 DESCRIPTION 379 "The type of the mapping rule. A value of 0 means it 380 is a BMR; a non-zero value means it is a FMR." 381 REFERENCE 382 "BMR, FMR: section 5 of RFC 7597." 383 ::= { mapRuleEntry 12 } 385 mapSecurityCheckTable OBJECT-TYPE 386 SYNTAX SEQUENCE OF MapSecurityCheckEntry 387 MAX-ACCESS not-accessible 388 STATUS current 389 DESCRIPTION 390 "The (conceptual) table containing information on 391 MAP security checks. This table can be used to statistic 392 the number of invalid packets that been identified" 393 ::= { mapSecurityCheck 1 } 395 mapSecurityCheckEntry OBJECT-TYPE 396 SYNTAX MapSecurityCheckEntry 397 MAX-ACCESS not-accessible 398 STATUS current 399 DESCRIPTION 400 "Each entry in this table contains the information on a 401 particular MAP SecurityCheck." 402 INDEX { ifIndex } 403 ::= { mapSecurityCheckTable 1 } 405 MapSecurityCheckEntry ::= 406 SEQUENCE { 407 mapSecurityCheckInvalidv4 Counter64, 408 mapSecurityCheckInvalidv6 Counter64 410 } 412 mapSecurityCheckInvalidv4 OBJECT-TYPE 413 SYNTAX Counter64 414 MAX-ACCESS accessible-for-notify 415 STATUS current 416 DESCRIPTION 417 "The CE SHOULD check that MAP received packets' 418 transport-layer destination port number is in the range 419 configured by MAP for the CE. So this object indicate 420 the number of the invalid IPv4 packets received by the 421 MAP." 422 ::= { mapSecurityCheckEntry 1 } 424 mapSecurityCheckInvalidv6 OBJECT-TYPE 425 SYNTAX Counter64 426 MAX-ACCESS accessible-for-notify 427 STATUS current 428 DESCRIPTION 429 "The BR MUST perform a validation of the consistency of 430 the source IPv6 address and source port number for the 431 packet using BMR. So this object indicate the number of 432 the invalid IPv6 packets received by the BR." 433 ::= { mapSecurityCheckEntry 2 } 435 -- Conformance Information 436 mapMIBConformance OBJECT IDENTIFIER ::= {mapMIB 2} 437 mapMIBCompliances OBJECT IDENTIFIER ::= { mapMIBConformance 1 } 438 mapMIBGroups OBJECT IDENTIFIER ::= { mapMIBConformance 2 } 440 -- compliance statements 441 mapMIBCompliance MODULE-COMPLIANCE 442 STATUS current 443 DESCRIPTION 444 " Describes the minimal requirements for conformance 445 to the MAP-E MIB." 446 MODULE -- this module 447 MANDATORY-GROUPS { mapMIBRuleGroup , mapMIBSecurityGroup } 448 ::= { mapMIBCompliances 1 } 450 -- Units of Conformance 451 mapMIBRuleGroup OBJECT-GROUP 452 OBJECTS { 453 mapRuleIPv6PrefixType, 454 mapRuleIPv6Prefix, 455 mapRuleIPv6PrefixLen, 456 mapRuleIPv4PrefixType, 457 mapRuleIPv4Prefix, 458 mapRuleIPv4PrefixLen, 459 mapRulePSID, 460 mapRulePSIDLen, 461 mapRuleOffset, 462 mapRuleEALen, 463 mapRuleType } 464 STATUS current 465 DESCRIPTION 466 " The collection of this objects are used to give the 467 information of mapping rules in MAP-E." 468 ::= { mapMIBGroups 1 } 470 mapMIBSecurityGroup OBJECT-GROUP 471 OBJECTS { 472 mapSecurityCheckInvalidv4, 473 mapSecurityCheckInvalidv6 } 474 STATUS current 475 DESCRIPTION 476 " The collection of this objects are used to give the 477 information on MAP security checks." 478 ::= { mapMIBGroups 2 } 480 END 482 6. IANA Considerations 484 The MIB module in this document uses the following IANA-assigned 485 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 487 Descriptor OBJECT IDENTIFIER value 488 ---------- ----------------------- 489 MAP-E-MIB { mib-2 XXX } 491 7. Security Considerations 493 The MAP-E MIB module can be used for configuration of certain 494 objects, and anything that can be configured can be incorrectly 495 configured, with potentially disastrous results. Because this MIB 496 module reuses the IP tunnel MIB, the security considerations for 497 these MIBs are also applicable to the MAP-E MIB. 499 SNMP versions prior to SNMPv3 did not include adequate security. 500 Even if the network itself is secure (for example by using IPSec), 501 even then, there is no control as to who on the secure network is 502 allowed to access and GET/SET (read/change/create/delete) the objects 503 in this MIB module. 505 It is RECOMMENDED that implementers consider the security features as 506 provided by the SNMPv3 framework (see [RFC3410] , section 8), 507 including full support for the SNMPv3 cryptographic mechanisms (for 508 authentication and privacy). 510 Further, deployment of SNMP versions prior to SNMPv3 is NOT 511 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 512 enable cryptographic security. It is then a customer/operator 513 responsibility to ensure that the SNMP entity giving access to an 514 instance of this MIB module is properly configured to give access to 515 the objects only to those principals (users) that have legitimate 516 rights to indeed GET or SET (change/create/delete) them. 518 8. Acknowledgements 520 The authors would like to thank for valuable comments from David 521 Harrington, Mark Townsley, and Shishio Tsuchiya. 523 This document was produced using the xml2rfc tool [RFC2629]. 525 9. References 526 9.1. Normative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, 530 DOI 10.17487/RFC2119, March 1997, 531 . 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, 536 DOI 10.17487/RFC2578, April 1999, 537 . 539 [RFC2580] McCloghrie, K., Ed., Perkins, D., Ed., and J. 540 Schoenwaelder, Ed., "Conformance Statements for SMIv2", 541 STD 58, RFC 2580, DOI 10.17487/RFC2580, April 1999, 542 . 544 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 545 MIB", RFC 2863, DOI 10.17487/RFC2863, June 2000, 546 . 548 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 549 Schoenwaelder, "Textual Conventions for Internet Network 550 Addresses", RFC 4001, DOI 10.17487/RFC4001, February 2005, 551 . 553 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 554 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 555 Port with Encapsulation (MAP-E)", RFC 7597, 556 DOI 10.17487/RFC7597, July 2015, 557 . 559 9.2. Informative References 561 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 562 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 563 STD 58, RFC 2579, DOI 10.17487/RFC2579, April 1999, 564 . 566 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 567 DOI 10.17487/RFC2629, June 1999, 568 . 570 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 571 "Introduction and Applicability Statements for Internet- 572 Standard Management Framework", RFC 3410, 573 DOI 10.17487/RFC3410, December 2002, 574 . 576 Authors' Addresses 578 Yu Fu 579 CNNIC 580 No.4 South 4th Street, Zhongguancun 581 Beijing 100190 582 P.R. China 584 Email: fuyu@cnnic.cn 586 Sheng Jiang 587 Huawei Technologies Co., Ltd 588 Q14, Huawei Campus, No.156 Beiqing Road 589 Hai-Dian District, Beijing, 100095 590 P.R. China 592 Email: jiangsheng@huawei.com 594 Bing Liu 595 Huawei Technologies Co., Ltd 596 Q14, Huawei Campus, No.156 Beiqing Road 597 Hai-Dian District, Beijing, 100095 598 P.R. China 600 Email: leo.liubing@huawei.com 602 Jiang Dong 603 Tsinghua University 604 Department of Computer Science, Tsinghua University 605 Beijing 100084 606 P.R. China 608 Email: knight.dongjiang@gmail.com 609 Yuchi Chen 610 Tsinghua University 611 Department of Computer Science, Tsinghua University 612 Beijing 100084 613 P.R. China 615 Email: flashfoxmx@gmail.com