idnits 2.17.1 draft-shishio-softwire-rfc4087update-00.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC5969], [RFC4087]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document date (July 10, 2012) is 4307 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: 'RFC4087' is mentioned on line 162, but not defined == Missing Reference: 'RFC5969' is mentioned on line 132, but not defined == Missing Reference: 'RFC1701' is mentioned on line 92, but not defined == Missing Reference: 'RFC1702' is mentioned on line 92, but not defined == Missing Reference: 'RFC2003' is mentioned on line 92, but not defined == Missing Reference: 'RFC2004' is mentioned on line 93, but not defined == Missing Reference: 'RFC2661' is mentioned on line 93, but not defined == Missing Reference: 'RFC2637' is mentioned on line 94, but not defined == Missing Reference: 'RFC2341' is mentioned on line 95, but not defined == Missing Reference: 'RFC1234' is mentioned on line 95, but not defined == Missing Reference: 'RFC2107' is mentioned on line 96, but not defined == Missing Reference: 'RFC2893' is mentioned on line 96, but not defined ** Obsolete undefined reference: RFC 2893 (Obsoleted by RFC 4213) == Missing Reference: 'RFC1241' is mentioned on line 88, but not defined == Missing Reference: 'RFC6333' is mentioned on line 132, but not defined == Missing Reference: 'RFC6145' is mentioned on line 129, but not defined ** Obsolete undefined reference: RFC 6145 (Obsoleted by RFC 7915) == Missing Reference: 'TODO' is mentioned on line 488, but not defined == Unused Reference: 'RFC2629' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 465, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) Summary: 5 errors (**), 0 flaws (~~), 20 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Tsuchiya, Ed. 3 Internet-Draft J. Qin 4 Intended status: Standards Track Cisco Systems 5 Expires: January 11, 2013 July 10, 2012 7 IP TUNNEL MIB Extention for softwire 8 draft-shishio-softwire-rfc4087update-00 10 Abstract 12 This memo defines a Management Information Base (MIB) module for use 13 with network management protocols in the Internet community. In 14 particular,it describes managed objects used for managing tunnels of 15 any type over IPv4 and IPv6 networks. 17 IP TUNNEL MIB[RFC4087] provides provisioning capability for IPv4 and 18 IPv6 tunnel by SNMP. But it is not eqnough to support modern tunnel 19 protocol such as 6rd[RFC5969] and MAP[draft-ietf-softwire-map]. The 20 document describes extention of IP TUNNEL MIB[RFC4087] to support 21 6rd[RFC5969] and MAP[draft-ietf-softwire-map]. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 11, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. The Internet-Standard Management Framework . . . . . . . . . . 3 59 3. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 4 62 5.1. Relationship to the SNMPv2-MIB . . . . . . . . . . . . . . 4 63 5.2. Relationship to the IF-MIB . . . . . . . . . . . . . . . . 4 64 5.3. Relationship to the IP TUNNEL MIB . . . . . . . . . . . . 4 65 5.4. MIB modules required for IMPORTS . . . . . . . . . . . . . 5 66 6. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 69 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 71 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 11.1. Normative References . . . . . . . . . . . . . . . . . . . 10 73 11.2. Informative References . . . . . . . . . . . . . . . . . . 11 74 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 75 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 11 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 78 1. Introduction 80 IP TUNNEL MIB[RFC4087] are used for managing tunnels of any type over 81 IPv4 and IPv6 networks, including Generic Routing Encapslation 82 (GRE)[RFC1701,RFC1702],IP-in-IP[RFC2003], Minimal Encapsulation 83 [RFC2004], Layer 2 Tunneling Protocol (L2TP) [RFC2661], Point-to- 84 Point Tunneling Protocol (PPTP) [RFC2637], Layer 2 Forwarding (L2F) 85 [RFC2341], UDP (e.g., [RFC1234]), Ascend Tunnel Management Protocol 86 (ATMP) [RFC2107], and IPv6-in-IPv4 [RFC2893] tunnels, among others. 87 Over the past several years, there has been a number of "tunneling" 88 protocols specified by the IETF (see [RFC1241] for an early 89 discussion of the model and examples). This document describes a 90 Management Information Base (MIB) module used for managing tunnels of 91 any type over IPv4 and IPv6 networks, including Generic Routing 92 Encapsulation (GRE) [RFC1701,RFC1702], IP-in-IP [RFC2003], Minimal 93 Encapsulation [RFC2004], Layer 2 Tunneling Protocol (L2TP) [RFC2661], 94 Point-to-Point Tunneling Protocol (PPTP) [RFC2637], Layer 2 95 Forwarding (L2F) [RFC2341], UDP (e.g., [RFC1234]), Ascend Tunnel 96 Management Protocol (ATMP) [RFC2107], and IPv6-in-IPv4 [RFC2893] 97 tunnels, among others. 99 This documents describes how to support IPv6 Rapid Deployment (6rd) 100 [RFC5969] and Mapping of Address and Port 101 (MAP)[draft-ietf-softwire-map] in IP TUNNEL MIB. 103 2. The Internet-Standard Management Framework 105 For a detailed overview of the documents that describe the current 106 Internet-Standard Management Framework, please refer to section 7 of 107 RFC 3410 [RFC3410]. 109 Managed objects are accessed via a virtual information store, termed 110 the Management Information Base or MIB. MIB objects are generally 111 accessed through the Simple Network Management Protocol (SNMP). 112 Objects in the MIB are defined using the mechanisms defined in the 113 Structure of Management Information (SMI). This memo specifies a MIB 114 module that is compliant to the SMIv2, which is described in STD 58, 115 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 116 [RFC2580]. 118 3. Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 4. Overview 126 IP TUNNEL MIB [RFC4087] are using provisioning for tunnel protocol, 127 but could not support 6rd [RFC5969] and MAP [draft-ietf-softwire-map] 128 due to lack of parameters. But MAP [draft-ietf-softwire-map] has 129 compativility with DS-Lite [RFC6333] and stateless NAT64 [RFC6145]. 130 Therefore if TUNNEL MIB once supports 6rd [RFC5969] and 131 MAP[draft-ietf-softwire-map],it could manage many type of modern 132 tunnels such as 6rd [RFC5969], MAP-T/MAP-E, DS-Lite [RFC6333], and 133 XLAT464 CLAT [draft-ietf-v6ops-464xlat]. 135 5. Structure of the MIB Module 137 The MIB module specified herein provides one way to manage the 6rd 138 and MAP devices thorough SNMP. 140 5.1. Relationship to the SNMPv2-MIB 142 The 'system' group in the SNMPv2-MIB [RFC3418] is defined as being 143 mandatory for all systems, and the objects apply to the entity as a 144 whole. The 'system' group provides identification of the management 145 entity and certain other system-wide data. The SAMPLE-MIB does not 146 duplicate those objects. 148 5.2. Relationship to the IF-MIB 150 The Interface MIB [RFC2863] requires that any MIB module which is an 151 adjunct of the Interface MIB clarify specific areas within the 152 Interface MIB. These areas were intentionally left vague in the 153 Interface MIB to avoid over constraining the MIB, thereby precluding 154 management of certain media-types. 156 Section 4 of [RFC2863] enumerates several areas which a media- 157 specific MIB must clarify. The implementor is referred to [RFC2863] 158 in order to understand the general intent of these areas. 160 5.3. Relationship to the IP TUNNEL MIB 162 The IP Tunnel MIB [RFC4087] contains objects common to all IP 163 tunnels, including 6rd/MAP Additionally, tunnel encapsulation 164 specific MIB (like what is defined in this document) extend the IP 165 tunnel MIB to further describe encapsulation specific information. 167 for example: 169 6rd case 170 6rd prefix, 6rd Prefix Length, IPv4Mask Length 172 MAP case 174 rule IPv6 prefix, rule IPv6 prefix Length, rule IPv4 prefix , rule 175 IPv4 prefix length, EA-bit length, PSID 177 tunnel method, BR address, source addresss could use tunnelIfEntry. 179 TunnelIfEntry ::= SEQUENCE { 180 tunnelIfLocalAddress IpAddress, -- deprecated 181 tunnelIfRemoteAddress IpAddress, -- deprecated 182 tunnelIfEncapsMethod IANAtunnelType, 183 tunnelIfHopLimit Integer32, 184 tunnelIfSecurity INTEGER, 185 tunnelIfTOS Integer32, 186 tunnelIfFlowLabel IPv6FlowLabelOrAny, 187 tunnelIfAddressType InetAddressType, 188 tunnelIfLocalInetAddress InetAddress, 189 tunnelIfRemoteInetAddress InetAddress, 190 tunnelIfEncapsLimit Integer32 191 } 193 tunnelIfEncapsMethod must be sixRd(xx), MAPT(xx) and MAPE(xx). 195 tunnelIfRemoteInetAddress must be BR address for CE. When 6rd, it 196 would be IPv4 address. When MAP-T and MAP-E, it would be IPv6 197 address. 0.0.0.0 :: would be used for BR. TunnelIfXEntry would use 198 for another prametors . 200 5.4. MIB modules required for IMPORTS 202 The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], 203 SNMPv2-TC [RFC2579], SNMPv2-CONF [RFC2580], and IF-MIB [RFC2863] 205 6. Definitions 207 tunnelIfXTable OBJECT-TYPE 208 SYNTAX SEQUENCE OF TunnelIfXEntry 209 MAX-ACCESS read-write 210 STATUS current 211 DESCRIPTION 212 "This table contains additional objects for the tunnel 213 interface table." 214 ::= { tunnel xx } 216 tunnelIfXEntry OBJECT-TYPE 217 SYNTAX TunnelIfXEntry 218 MAX-ACCESS read-write 219 STATUS current 220 DESCRIPTION 221 "An entry containing additional information applicable to a 222 particular tunnel interface." 223 INDEX { ifIndex } 224 ::= { tunnelIfXTable 1 } 226 TunnelIfXEntry ::= SEQUENCE { 227 SamPrex InetAddress, 228 SamLength Integer32 229 BasePrex InetAddress, 230 BaseLength Integer32 231 EAbit Integer32 232 PSID Integer32 233 } 234 } 236 SamPrefix OBJECT-TYPE 237 SYNTAX InetAddress 238 MAX-ACCESS read-write 239 STATUS current 240 DESCRIPTION 241 "Stateless Adress Mapping Prex IPv4 for MAP,IPv6 for 6rd" 242 := { TunnelIfXEntry 1 } 244 SamLength OBJECT-TYPE 245 SYNTAX Integer32(0..127) 246 MAX-ACCESS read-write 247 STATUS current 248 DESCRIPTION 249 "Stateless Adress Mapping length IPv4(0-31) for MAP,IPv6(0-127) for 6rd" 250 := { TunnelIfXEntry 2 } 252 BasePrefix OBJECT-TYPE 253 SYNTAX InetAddress 254 MAX-ACCESS read-write 255 STATUS current 256 DESCRIPTION 257 "rule IPv6 prefix for MAP, IPv4 address for 6rd" 258 := { TunnelIfXEntry 3 } 260 BaseLength OBJECT-TYPE 261 SYNTAX InetAddress 262 MAX-ACCESS read-write 263 STATUS current 264 DESCRIPTION 265 "rule IPv6 prefix for MAP, IPv4 address for 6rd" 266 := { TunnelIfXEntry 4 } 268 EAbit OBJECT-TYPE 269 SYNTAX Integer32(0..127) 270 MAX-ACCESS read-write 271 STATUS current 272 DESCRIPTION 273 "rule IPv6 prefix length for MAP, IPv4MaskLength for 6rd" 274 := { TunnelIfXEntry 5 } 276 PSID OBJECT-TYPE 277 SYNTAX Integer32(0..127) 278 MAX-ACCESS read-write 279 STATUS current 280 DESCRIPTION 281 "EA bit for MAP,0 must be for 6rd" 282 := { TunnelIfXEntry 6 } 284 END 286 tunnelIfXTable OBJECT-TYPE 287 SYNTAX SEQUENCE OF TunnelIfXEntry 288 MAX-ACCESS read-write 289 STATUS current 290 DESCRIPTION 291 "This table contains additional objects for the tunnel 292 interface table." 293 ::= { tunnel xx } 295 tunnelIfXEntry OBJECT-TYPE 296 SYNTAX TunnelIfXEntry 297 MAX-ACCESS read-write 298 STATUS current 299 DESCRIPTION 300 "An entry containing additional information applicable to a 301 particular tunnel interface." 302 INDEX { ifIndex } 303 ::= { tunnelIfXTable 1 } 305 TunnelIfXEntry ::= SEQUENCE { 306 SamPrex InetAddress, 307 SamLength Integer32 308 BasePrex InetAddress, 309 BaseLength Integer32 310 EAbit Integer32 311 PSID Integer32 312 } 313 } 315 SamPrefix OBJECT-TYPE 316 SYNTAX InetAddress 317 MAX-ACCESS read-write 318 STATUS current 319 DESCRIPTION 320 "Stateless Adress Mapping Prex IPv4 for MAP,IPv6 for 6rd" 321 := { TunnelIfXEntry 1 } 323 SamLength OBJECT-TYPE 324 SYNTAX Integer32(0..127) 325 MAX-ACCESS read-write 326 STATUS current 327 DESCRIPTION 328 "Stateless Adress Mapping length IPv4(0-31) for MAP,IPv6(0-127) for 6rd" 329 := { TunnelIfXEntry 2 } 331 BasePrefix OBJECT-TYPE 332 SYNTAX InetAddress 333 MAX-ACCESS read-write 334 STATUS current 335 DESCRIPTION 336 "rule IPv6 prefix for MAP, IPv4 address for 6rd" 337 := { TunnelIfXEntry 3 } 339 BaseLength OBJECT-TYPE 340 SYNTAX InetAddress 341 MAX-ACCESS read-write 342 STATUS current 343 DESCRIPTION 344 "rule IPv6 prefix for MAP, IPv4 address for 6rd" 345 := { TunnelIfXEntry 4 } 347 EAbit OBJECT-TYPE 348 SYNTAX Integer32(0..127) 349 MAX-ACCESS read-write 350 STATUS current 351 DESCRIPTION 352 "rule IPv6 prefix length for MAP, IPv4MaskLength for 6rd" 353 := { TunnelIfXEntry 5 } 355 PSID OBJECT-TYPE 356 SYNTAX Integer32(0..127) 357 MAX-ACCESS read-write 358 STATUS current 359 DESCRIPTION 360 "EA bit for MAP,0 must be for 6rd" 361 := { TunnelIfXEntry 6 } 363 END 365 7. Security Considerations 367 There are a number of management objects defined in this MIB module 368 with a MAX-ACCESS clause of read-write and/or read-create. Such 369 objects may be considered sensitive or vulnerable in some network 370 environments. The support for SET operations in a non-secure 371 environment without proper protection can have a negative effect on 372 network operations. These are the tables and objects and their 373 sensitivity/vulnerability: 375 There are no management objects defined in this MIB module that have 376 a MAX-ACCESS clause of read-write and/or read-create. So, if this 377 MIB module is implemented correctly, then there is no risk that an 378 intruder can alter or create any management objects of this MIB 379 module via direct SNMP SET operations. 381 Some of the readable objects in this MIB module (i.e., objects with a 382 MAX-ACCESS other than not-accessible) may be considered sensitive or 383 vulnerable in some network environments. It is thus important to 384 control even GET and/or NOTIFY access to these objects and possibly 385 to even encrypt the values of these objects when sending them over 386 the network via SNMP. These are the tables and objects and their 387 sensitivity/vulnerability: 389 o SNMP versions prior to SNMPv3 did not include adequate security. 390 Even if the network itself is secure (for example by using IPSec), 391 even then, there is no control as to who on the secure network is 392 allowed to access and GET/SET (read/change/create/delete) the 393 objects in this MIB module. 395 It is RECOMMENDED that implementers consider the security features as 396 provided by the SNMPv3 framework (see [RFC3410], section 8), 397 including full support for the SNMPv3 cryptographic mechanisms (for 398 authentication and privacy). 400 Further, deployment of SNMP versions prior to SNMPv3 is NOT 401 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 402 enable cryptographic security. It is then a customer/operator 403 responsibility to ensure that the SNMP entity giving access to an 404 instance of this MIB module is properly configured to give access to 405 the objects only to those principals (users) that have legitimate 406 rights to indeed GET or SET (change/create/delete) them. 408 8. IANA Considerations 410 The MIB module in this document uses the following IANA-assigned 411 OBJECT IDENTIFIER values recorded in the SMI Numbers registry: 413 Descriptor OBJECT IDENTIFIER value 414 ---------- ----------------------- 416 TunnelIXEntry { tunnel XXX } 418 IANAtunnelType ::= TEXTUAL-CONVENTION 419 SYNTAX INTEGER { 421 sixRd ("XX") -- 6rd encapsulation 422 MAPT ("XX") -- MAP-T encapsulation 423 MAPE ("XX") -- MAP-T encapsulation 424 } 426 9. Contributors 428 This template is based on contributions from the MIb Doctors, 429 especially Juergen Schoenwaelder, Dave Perkins, C.M.Heard and Randy 430 Presuhn. 432 10. Acknowledgements 434 Thanks to Marshall Rose for developing the XML2RFC format. 436 11. References 438 11.1. Normative References 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 443 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 444 Schoenwaelder, Ed., "Structure of Management Information 445 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 447 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 448 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 449 STD 58, RFC 2579, April 1999. 451 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 452 "Conformance Statements for SMIv2", STD 58, RFC 2580, 453 April 1999. 455 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 456 June 1999. 458 [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group 459 MIB", RFC 2863, June 2000. 461 [RFC3418] Presuhn, R., "Management Information Base (MIB) for the 462 Simple Network Management Protocol (SNMP)", STD 62, 463 RFC 3418, December 2002. 465 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 466 Documents", BCP 111, RFC 4181, September 2005. 468 11.2. Informative References 470 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 471 "Introduction and Applicability Statements for Internet- 472 Standard Management Framework", RFC 3410, December 2002. 474 Appendix A. Change Log 476 The following changes have been made from draft-xxx-xxx-xxx-12 . 478 [TODO] replace this list with your own list 480 1. Updated the introductry boilerplate text, the security 481 considerations section and the references to comply with the 482 current IETF standards and guidelines. 484 2. Additions and clarifications in various description clauses. 486 Appendix B. Open Issues 488 [TODO] This list of open issues should be cleared and removed before 489 this document hits the IESG. 491 1. Contributor addresses need to be updated 493 Authors' Addresses 495 Shishio Tsuchiya (editor) 496 Cisco Systems 497 Midtown Tower, 9-7-1,Akasaka 498 Minato-Ku, Tokyo 107-6227 499 Japan 501 Phone: +81 3 6434 6543 502 Email: shtsuchi@cisco.com 504 Jacni Qin 505 Cisco Systems 506 Shanghai 507 China 509 Phone: 510 Email: jacni@jacni.com