idnits 2.17.1 draft-ietf-softwire-map-mib-03.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 15, 2014) is 3392 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) == Unused Reference: 'RFC3411' is defined on line 518, but no explicit reference was found in the text == Unused Reference: 'RFC4087' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 535, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-softwire-map-12 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 0 errors (**), 0 flaws (~~), 6 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 S. Jiang 4 Intended status: Standards Track B. Liu 5 Expires: June 18, 2015 Huawei Technologies Co., Ltd 6 J. Dong 7 Y. Chen 8 Tsinghua University 9 December 15, 2014 11 Definitions of Managed Objects for MAP-E 12 draft-ietf-softwire-map-mib-03 14 Abstract 16 This memo defines a portion of the Management Information Base (MIB) 17 for using with network management protocols in the Internet 18 community. In particular, it defines managed objects for MAP 19 encapsulation mode. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on June 18, 2015. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 68 2. The Internet-Standard Management Framework . . . . . . . . . 3 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. Structure of the MIB Module . . . . . . . . . . . . . . . . . 3 71 4.1. The mapMIBObjects . . . . . . . . . . . . . . . . . . . . 3 72 4.1.1. The mapRule Subtree . . . . . . . . . . . . . . . . . 3 73 4.1.2. The mapSecurityCheck Subtree . . . . . . . . . . . . 3 74 4.2. The mapMIBConformance Subtree . . . . . . . . . . . . . . 4 75 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 80 8.2. Informative References . . . . . . . . . . . . . . . . . 12 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 83 1. Introduction 85 MAP [I-D.ietf-softwire-map] is a stateless mechanism for running IPv4 86 over IPv6-only infrastructure. In particular, it includes two mode, 87 translation mode or encapsulation mode. For the encapsulation mode, 88 it provides an automatic tunnelling mechanism for providing IPv4 89 connectivity service to end users over a service provider's IPv6 90 network 92 This document defines a portion of the Management Information Base 93 (MIB) for use with network management protocols in the Internet 94 community. This MIB module may be used for monitoring the devices in 95 the MAP scenario, especially, for the encapsulation mode. 97 2. The Internet-Standard Management Framework 99 For a detailed overview of the documents that describe the current 100 Internet-Standard Management Framework, please refer to section 7 of 101 [RFC3410]. 103 Managed objects are accessed via a virtual information store, termed 104 the Management Information Base or MIB. MIB objects are generally 105 accessed through the Simple Network Management Protocol (SNMP). 106 Objects in the MIB are defined using the mechanisms defined in the 107 Structure of Management Information (SMI). This memo specifies a MIB 108 module that is compliant to the SMIv2, which is described in 109 [RFC2578], [RFC2579] and [RFC2580]. 111 3. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in 116 [RFC2119]. 118 4. Structure of the MIB Module 120 The MAP-E MIB provides a way to configure and manage the devices in 121 MAP encapsulation mode through SNMP. 123 MAP-E MIB is configurable on a per-interface basis. It depends on 124 several parts of the IF-MIB[RFC2863]. 126 4.1. The mapMIBObjects 128 4.1.1. The mapRule Subtree 130 The mapRule subtree describes managed objects used for managing the 131 multiple mapping rules in the MAP encapsulation mode. 133 According to the MAP specification, the mapping rules are divided 134 into two categories, which are BMR (Basic Mapping Rule), and FMR 135 (Forwarding Mapping Rule). 137 4.1.2. The mapSecurityCheck Subtree 139 The mapSecurityCheck subtree is to statistic the number of invalid 140 packets that been identified. There are two kind of invalid packets 141 which are defined in the MAP specification as the following. 143 - The BR MUST perform a validation of the consistency of the source 144 IPv6 address and source port number for the packet using BMR. 146 - The CE SHOULD check that MAP received packets' transport-layer 147 destination port number is in the range configured by MAP for the CE. 149 4.2. The mapMIBConformance Subtree 151 The mapMIBConformance subtree provides conformance information of MIB 152 objects. 154 5. Definitions 156 MAP-E-MIB DEFINITIONS ::= BEGIN 158 IMPORTS 159 MODULE-IDENTITY, OBJECT-TYPE, transmission, 160 Integer32, Counter64 161 FROM SNMPv2-SMI 162 ifIndex 163 FROM IF-MIB 164 InetAddressType, InetAddress, 165 InetPortNumber, InetAddressPrefixLength 166 FROM INET-ADDRESS-MIB 167 OBJECT-GROUP, MODULE-COMPLIANCE 168 FROM SNMPv2-CONF; 170 mapMIB MODULE-IDENTITY 171 LAST-UPDATED "201412150000Z" - December 15, 2014 172 ORGANIZATION "IETF Softwire Working Group" 173 CONTACT-INFO 174 "Yu Fu 175 Huawei Technologies Co., Ltd 176 Huawei Building, 156 Beiqing Rd., Hai-Dian District 177 Beijing, P.R. China 100095 178 EMail: eleven.fuyu@huawei.com 180 Sheng Jiang 181 Huawei Technologies Co., Ltd 182 Huawei Building, 156 Beiqing Rd., Hai-Dian District 183 Beijing, P.R. China 100095 184 EMail: jiangsheng@huawei.com 186 Bing Liu 187 Huawei Technologies Co., Ltd 188 Huawei Building, 156 Beiqing Rd., Hai-Dian District 189 Beijing, P.R. China 100095 190 EMail: leo.liubing@huawei.com 192 Jiang Dong 193 Tsinghua University 194 Department of Computer Science, Tsinghua University 195 Beijing 100084 196 P.R. China 197 Email: knight.dongjiang@gmail.com 199 Yuchi Chen 200 Tsinghua University 201 Department of Computer Science, Tsinghua University 202 Beijing 100084 203 P.R. China 204 Email: chenycmx@gmail.com" 206 DESCRIPTION 207 "The MIB module is defined for management of objects in the 208 MAP-E BRs or CEs." 209 REVISION "201412150000Z" 210 DESCRIPTION 211 "Initial version. Published as RFC xxxx." 212 --RFC Ed.: RFC-edtitor pls fill in xxxx 213 ::= { transmission xxx } 214 --xxx to be replaced withIANA-assigned value 216 mapMIBObjects OBJECT IDENTIFIER ::= {mapMIB 1} 218 mapRule OBJECT IDENTIFIER 219 ::= { mapMIBObjects 1 } 221 mapSecurityCheck OBJECT IDENTIFIER 222 ::= { mapMIBObjects 2 } 224 mapRuleTable OBJECT-TYPE 225 SYNTAX SEQUENCE OF MapRuleEntry 226 MAX-ACCESS not-accessible 227 STATUS current 228 DESCRIPTION 229 "The (conceptual) table containing rule Information of 230 specific mapping rule. It can also be used for row 231 creation." 232 ::= { mapRule 1 } 234 mapRuleEntry OBJECT-TYPE 235 SYNTAX MapRuleEntry 236 MAX-ACCESS not-accessible 237 STATUS current 238 DESCRIPTION 239 "Each entry in this table contains the information on a 240 particular mapping rule." 241 INDEX { mapRuleID } 243 ::= { mapRuleTable 1 } 245 MapRuleEntry ::= 246 SEQUENCE { 247 mapRuleID Integer32, 248 mapRuleIPv6PrefixType InetAddressType, 249 mapRuleIPv6Prefix InetAddress, 250 mapRuleIPv6PrefixLen InetAddressPrefixLength, 251 mapRuleIPv4PrefixType InetAddressType, 252 mapRuleIPv4Prefix InetAddress, 253 mapRuleIPv4PrefixLen InetAddressPrefixLength, 254 mapRuleStartPort InetPortNumber, 255 mapRuleEndPort InetPortNumber, 256 mapRuleEALen Integer32, 257 mapRuleType Integer32 258 } 260 mapRuleID OBJECT-TYPE 261 SYNTAX Integer32 (1..2147483647) 262 MAX-ACCESS not-accessible 263 STATUS current 264 DESCRIPTION 265 "An identifier used to distinguish the multiple mapping 266 rule which is unique with each CE in the same BR." 267 ::= { mapRuleEntry 1 } 269 mapRuleIPv6PrefixType OBJECT-TYPE 270 SYNTAX InetAddressType 271 MAX-ACCESS read-create 272 STATUS current 273 DESCRIPTION 274 "In this object, it MUST be set to the value of 2 to 275 present IPv6 type. It complies the textule convention 276 of IPv6 address defined in [RFC4001]." 277 ::= { mapRuleEntry 2 } 279 mapRuleIPv6Prefix OBJECT-TYPE 280 SYNTAX InetAddress 281 MAX-ACCESS read-create 282 STATUS current 283 DESCRIPTION 284 "The IPv6 prefix defined in mapping rule which will be 285 assigned to CE ." 286 ::= { mapRuleEntry 3 } 288 mapRuleIPv6PrefixLen OBJECT-TYPE 289 SYNTAX InetAddressPrefixLength 290 MAX-ACCESS read-create 291 STATUS current 292 DESCRIPTION 293 "The length of the IPv6 prefix defined in the mapping rule. 294 As a parameter for mapping rule, it will be also assigned 295 to CE." 296 ::= { mapRuleEntry 4 } 298 mapRuleIPv4PrefixType OBJECT-TYPE 299 SYNTAX InetAddressType 300 MAX-ACCESS read-create 301 STATUS current 302 DESCRIPTION 303 "In this object, it MUST be set to the value of 1 to 304 present IPv4 type. It complies the textual convention 305 of IPv6 address defined in [RFC4001]." 306 ::= { mapRuleEntry 5 } 308 mapRuleIPv4Prefix OBJECT-TYPE 309 SYNTAX InetAddress 310 MAX-ACCESS read-create 311 STATUS current 312 DESCRIPTION 313 " The IPv4 prefix defined in mapping rule which will be 314 assigned to CE." 315 ::= { mapRuleEntry 6 } 317 mapRuleIPv4PrefixLen OBJECT-TYPE 318 SYNTAX InetAddressPrefixLength 319 MAX-ACCESS read-create 320 STATUS current 321 DESCRIPTION 322 "The length of the IPv4 prefix defined in the mapping 323 rule. As a parameter for mapping rule, it will be also 324 assigned to CE." 325 ::= { mapRuleEntry 7 } 327 mapRuleStartPort OBJECT-TYPE 328 SYNTAX InetPortNumber 329 MAX-ACCESS read-create 330 STATUS current 331 DESCRIPTION 332 "The start port number of the port range derived 333 from the mapping rule which will be assigned to CE." 334 ::= { mapRuleEntry 8 } 336 mapRuleEndPort OBJECT-TYPE 337 SYNTAX InetPortNumber 338 MAX-ACCESS read-create 339 STATUS current 340 DESCRIPTION 341 " The end port number of the port range derived 342 from the mapping rule which will be assigned to CE." 343 ::= { mapRuleEntry 9 } 345 mapRuleEALen OBJECT-TYPE 346 SYNTAX Integer32 347 MAX-ACCESS read-create 348 STATUS current 349 DESCRIPTION 350 "The length of the Embedded-Address (EA) defined in 351 mapping rule which will be assigned to CE." 352 ::= { mapRuleEntry 10 } 354 mapRuleType OBJECT-TYPE 355 SYNTAX Integer32 356 MAX-ACCESS read-create 357 STATUS current 358 DESCRIPTION 359 "The type of the mapping rule. A value of 0 means it 360 is a BMR; a non-zero value means it is a FMR." 361 ::= { mapRuleEntry 11 } 363 mapSecurityCheckTable OBJECT-TYPE 364 SYNTAX SEQUENCE OF MapSecurityCheckEntry 365 MAX-ACCESS not-accessible 366 STATUS current 367 DESCRIPTION 368 "The (conceptual) table containing information on 369 MAP security checks. This table can be used to statistic 370 the number of invalid packets that been identified" 371 ::= { mapSecurityCheck 1 } 373 mapSecurityCheckEntry OBJECT-TYPE 374 SYNTAX MapSecurityCheckEntry 375 MAX-ACCESS not-accessible 376 STATUS current 377 DESCRIPTION 378 "Each entry in this table contains the information on a 379 particular MAP SecurityCheck." 380 INDEX { ifIndex } 381 ::= { mapSecurityCheckTable 1 } 383 MapSecurityCheckEntry ::= 384 SEQUENCE { 385 mapSecurityCheckInvalidv4 Counter64, 386 mapSecurityCheckInvalidv6 Counter64 388 } 390 mapSecurityCheckInvalidv4 OBJECT-TYPE 391 SYNTAX Counter64 392 MAX-ACCESS accessible-for-notify 393 STATUS current 394 DESCRIPTION 395 "The CE SHOULD check that MAP received packets' 396 transport-layer destination port number is in the range 397 configured by MAP for the CE. So this object indicate 398 the number of the invalid IPv4 packets received by the 399 MAP." 400 ::= { mapSecurityCheckEntry 1 } 402 mapSecurityCheckInvalidv6 OBJECT-TYPE 403 SYNTAX Counter64 404 MAX-ACCESS accessible-for-notify 405 STATUS current 406 DESCRIPTION 407 "The BR MUST perform a validation of the consistency of 408 the source IPv6 address and source port number for the 409 packet using BMR. So this object indicate the number of 410 the invalid IPv6 packets received by the BR." 411 ::= { mapSecurityCheckEntry 2 } 413 -- Conformance Information 414 mapMIBConformance OBJECT IDENTIFIER ::= {mapMIB 2} 415 mapMIBCompliances OBJECT IDENTIFIER ::= { mapMIBConformance 1 } 416 mapMIBGroups OBJECT IDENTIFIER ::= { mapMIBConformance 2 } 418 -- compliance statements 419 mapMIBCompliance MODULE-COMPLIANCE 420 STATUS current 421 DESCRIPTION 422 " Describes the minimal requirements for conformance 423 to the MAP-E MIB." 424 MODULE -- this module 425 MANDATORY-GROUPS { mapMIBRuleGroup , mapMIBSecurityGroup } 426 ::= { mapMIBCompliances 1 } 428 -- Units of Conformance 429 mapMIBRuleGroup OBJECT-GROUP 430 OBJECTS { 431 mapRuleIPv6PrefixType, 432 mapRuleIPv6Prefix, 433 mapRuleIPv6PrefixLen, 434 mapRuleIPv4PrefixType, 435 mapRuleIPv4Prefix, 436 mapRuleIPv4PrefixLen, 437 mapRuleStartPort, 438 mapRuleEndPort, mapRuleEALen, 439 mapRuleType } 440 STATUS current 441 DESCRIPTION 442 " The collection of this objects are used to give the 443 information of mapping rules in MAP-E." 444 ::= { mapMIBGroups 1 } 446 mapMIBSecurityGroup OBJECT-GROUP 447 OBJECTS { 448 mapSecurityCheckInvalidv4, 449 mapSecurityCheckInvalidv6 } 450 STATUS current 451 DESCRIPTION 452 " The collection of this objects are used to give the 453 information on MAP security checks." 454 ::= { mapMIBGroups 2 } 456 END 458 6. IANA Considerations 460 The MIB module in this document uses the following IANA-assigned 461 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 463 Descriptor OBJECT IDENTIFIER value 464 ---------- ----------------------- 465 MAP-E-MIB { transmission XXX } 467 7. Security Considerations 469 The MAP-E MIB module can be used for configuration of certain 470 objects, and anything that can be configured can be incorrectly 471 configured, with potentially disastrous results. Because this MIB 472 module reuses the IP tunnel MIB, the security considerations for 473 these MIBs are also applicable to the MAP-E MIB. 475 SNMP versions prior to SNMPv3 did not include adequate security. 476 Even if the network itself is secure (for example by using IPSec), 477 even then, there is no control as to who on the secure network is 478 allowed to access and GET/SET (read/change/create/delete) the objects 479 in this MIB module. 481 It is RECOMMENDED that implementers consider the security features as 482 provided by the SNMPv3 framework (see [RFC3410] [RFC3410], section 483 8), including full support for the SNMPv3 cryptographic mechanisms 484 (for authentication and privacy). 486 Further, deployment of SNMP versions prior to SNMPv3 is NOT 487 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 488 enable cryptographic security. It is then a customer/operator 489 responsibility to ensure that the SNMP entity giving access to an 490 instance of this MIB module is properly configured to give access to 491 the objects only to those principals (users) that have legitimate 492 rights to indeed GET or SET (change/create/delete) them. 494 8. References 496 8.1. Normative References 498 [I-D.ietf-softwire-map] 499 Troan, O., Dec, W., Li, X., Bao, C., Matsushima, S., 500 Murakami, T., and T. Taylor, "Mapping of Address and Port 501 with Encapsulation (MAP)", draft-ietf-softwire-map-12 502 (work in progress), November 2014. 504 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 505 Requirement Levels", BCP 14, RFC 2119, March 1997. 507 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 508 Schoenwaelder, Ed., "Structure of Management Information 509 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 511 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 512 "Conformance Statements for SMIv2", STD 58, RFC 2580, 513 April 1999. 515 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 516 MIB", RFC 2863, June 2000. 518 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 519 Architecture for Describing Simple Network Management 520 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 521 December 2002. 523 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 524 Schoenwaelder, "Textual Conventions for Internet Network 525 Addresses", RFC 4001, February 2005. 527 [RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005. 529 8.2. Informative References 531 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 532 Schoenwaelder, Ed., "Textual Conventions for SMIv2", STD 533 58, RFC 2579, April 1999. 535 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 536 June 1999. 538 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 539 "Introduction and Applicability Statements for Internet- 540 Standard Management Framework", RFC 3410, December 2002. 542 Authors' Addresses 544 Yu Fu 545 Huawei Technologies Co., Ltd 546 Q14, Huawei Campus, No.156 Beiqing Road 547 Hai-Dian District, Beijing, 100095 548 P.R. China 549 Email: eleven.fuyu@huawei.com 551 Sheng Jiang 552 Huawei Technologies Co., Ltd 553 Q14, Huawei Campus, No.156 Beiqing Road 554 Hai-Dian District, Beijing, 100095 555 P.R. China 556 Email: jiangsheng@huawei.com 558 Bing Liu 559 Huawei Technologies Co., Ltd 560 Q14, Huawei Campus, No.156 Beiqing Road 561 Hai-Dian District, Beijing, 100095 562 P.R. China 563 Email: leo.liubing@huawei.com 564 Jiang Dong 565 Tsinghua University 566 Department of Computer Science, Tsinghua University 567 Beijing 100084 568 P.R. China 569 Email: knight.dongjiang@gmail.com 571 Yuchi Chen 572 Tsinghua University 573 Department of Computer Science, Tsinghua University 574 Beijing 100084 575 P.R. China 576 Email: flashfoxmx@gmail.com