idnits 2.17.1 draft-ietf-softwire-mesh-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 : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 14 characters in excess of 72. ** The abstract seems to contain references ([RFC5565]), 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 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 (September 9, 2013) is 3881 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: 'RFC2863' is mentioned on line 229, but not defined == Missing Reference: 'RFC4087' is mentioned on line 195, but not defined == Missing Reference: 'RFC4001' is mentioned on line 230, but not defined == Unused Reference: 'RFC2223' is defined on line 637, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC4181' is defined on line 647, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 4925 ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) -- Obsolete informational reference (is this intentional?): RFC 2223 (Obsoleted by RFC 7322) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwire Y. Cui 3 Internet-Draft J. Dong 4 Intended status: Standards Track P. Wu 5 Expires: March 13, 2014 M. Xu 6 Tsinghua University 7 A. Yla-Jaaski 8 Aalto University 9 September 9, 2013 11 Softwire Mesh Management Information Base (MIB) 12 draft-ietf-softwire-mesh-mib-04 14 Abstract 16 This memo defines a portion of the Management Information Base (MIB) 17 for use with network management protocols in the Internet community. 18 In particular it defines objects for managing softwire mesh 19 [RFC5565]. 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 March 13, 2014. 38 Copyright Notice 40 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. The Internet-Standard Management Framework . . . . . . . . . . 3 69 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 4. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 5. Structure of the MIB Module . . . . . . . . . . . . . . . . . 3 72 5.1. The swmSupportedTunnlTable Subtree . . . . . . . . . . . . 3 73 5.2. The swmEncapsTable Subtree . . . . . . . . . . . . . . . . 4 74 5.3. The swmBGPNeighborTable Subtree . . . . . . . . . . . . . 4 75 5.4. The swmMIBConformance Subtree . . . . . . . . . . . . . . 4 76 6. Relationship to Other MIB Modules . . . . . . . . . . . . . . 4 77 6.1. Relationship to the IF-MIB . . . . . . . . . . . . . . . . 4 78 6.2. Relationship to the IP Tunnel MIB . . . . . . . . . . . . 5 79 6.3. MIB modules required for IMPORTS . . . . . . . . . . . . . 5 80 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 82 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 11.1. Normative References . . . . . . . . . . . . . . . . . . . 13 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 14 88 1. Introduction 90 Softwire mesh framework RFC 5565 [RFC5565] is a tunneling mechanism 91 that enables the connectivity between islands of IPv4 networks across 92 single IPv6 backbone and vice versa. In softwire mesh, extended 93 multiprotocol-BGP (MP-BGP)is used to set up tunnels and advertise 94 prefixes among address family border routers (AFBRs). 96 This memo defines a portion of the Management Information Base (MIB) 97 for use with network management protocols in the Internet community. 98 In particular it defines objects for managing softwire mesh 99 [RFC5565]. 101 2. The Internet-Standard Management Framework 103 For a detailed overview of the documents that describe the current 104 Internet-Standard Management Framework, please refer to section 7 of 105 RFC 3410 [RFC3410]. 107 Managed objects are accessed via a virtual information store, termed 108 the Management Information Base or MIB. MIB objects are generally 109 accessed through the Simple Network Management Protocol (SNMP). They 110 are defined using the mechanisms stated in the Structure of 111 Management Information (SMI). This memo specifies a MIB module that 112 is compliant to the SMIv2, which is described in STD 58, RFC 2578 113 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 115 3. Terminology 117 This document uses terminology from softwire problem statement RFC 118 4925 [RFC4925] and softwire mesh framework RFC 5565 [RFC5565]. 120 4. Conventions 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 5. Structure of the MIB Module 128 The softwire mesh MIB provides a method to configure and manage the 129 softwire mesh objects through SNMP. 131 5.1. The swmSupportedTunnlTable Subtree 133 Since the AFBR need to negotiate with BGP peer what kind of tunnel 134 they will use, it should firstly announce the types of tunnels it 135 supports. The swmSupportedTunnlTable subtree provides the 136 information. According to section 4 of RFC 5512 [RFC5512], current 137 softwire mesh tunnel types include IP-IP, GRE and L2TPv3. 139 5.2. The swmEncapsTable Subtree 141 The swmEncapsTable subtree provides softwire mesh NLRI-NH information 142 about the AFBR. It keeps the mapping between the E-IP prefix and the 143 I-IP address of the next hop. The mappings determine which I-IP 144 destination address will be used to encapsulate the received packet's 145 according to its E-IP destination address. The definitions of E-IP 146 and I-IP are explained in section 4.1 of RFC 5565[RFC5565]. 148 5.3. The swmBGPNeighborTable Subtree 150 The subtree provides the softwire mesh BGP neighbor information of an 151 AFBR. It includes the address of the softwire mesh BGP peer, and the 152 kind of tunnel that the AFBR would use to communicate with this BGP 153 peer. 155 5.4. The swmMIBConformance Subtree 157 The subtree provides the conformance information of MIB objects. 159 6. Relationship to Other MIB Modules 161 6.1. Relationship to the IF-MIB 163 The Interfaces MIB [RFC2863] defines generic managed objects for 164 managing interfaces. Each logical interface (physical or virtual) 165 has an ifEntry. Tunnels are handled by creating logical interfaces 166 (ifEntry). Being a tunnel, softwire mesh has an entry in the 167 Interface MIB, as well as an entry in IP Tunnel MIB. Those 168 corresponding entries are indexed by ifIndex. 170 The ifOperStatus in the ifTable would be used to represents whether 171 the mesh function of the AFBR has been triggered. If the software 172 mesh capability is negotiated during the BGP OPEN phase, the mesh 173 function is considered to be started, and the ifOperStatus is "up". 174 Otherwise the ifOperStatus is "down". 176 In the case of IPv4-over-IPv6 softwire mesh tunnel, the ifInUcastPkts 177 counts the number of IPv6 packets which are sent to the virtual 178 interface for decapsulation into IPv4. The ifOutUcastPkts counts the 179 number of IPv6 packets which are generated by encapsulating IPv4 180 packets sent to the virtual interface. Particularly, if these IPv4 181 packets need fragmentation, ifOutUcastPkts counts the number of 182 packets after fragmentation. 184 In the case of IPv6-over-IPv4 softwire mesh tunnel, the ifInUcastPkts 185 counts the number of IPv4 packets, which are sent to the virtual 186 interface for decapsulation into IPv6. The ifOutUcastPkts counts the 187 number of IPv4 packets, which are generated by encapsulating IPv6 188 packets sent to the virtual interface. Particularly, if these IPv6 189 packets need to be fragmented, tifOutUcastPkts counts the number of 190 packets after fragmentation. Similar definition applies to other 191 counting objects in ifTable. 193 6.2. Relationship to the IP Tunnel MIB 195 The IP Tunnel MIB [RFC4087] contains objects applicable to all IP 196 tunnels, including softwire mesh. Meanwhile, Softwire Mesh MIB 197 extends the IP tunnel MIB to further describe encapsulation-specific 198 information. 200 Running a point to multi-point tunnel, it is necessary for a softwire 201 mesh AFBR to maintain an encapsulation table, used to perform correct 202 "forwarding" among AFBRs. This forwarding function on an AFBR is 203 performed by using the E-IP destination address to look up in the 204 encapsulation table for the I-IP encapsulation destination address. 205 An AFBR also needs to know the BGP peer information of the other 206 AFBRs, so that it can negotiate the NLRI-NH information and the 207 tunnel parameters with them. 209 Softwire mesh MIB requires the implementation of the IP Tunnel MIB. 210 The tunnelIfEncapsMethod in the tunnelIfEntry should be set to 211 softwireMesh("xx"), and corresponding entry in the softwire mesh MIB 212 module will be presented for the tunnelIfEntry. The 213 tunnelIfRemoteInetAddress must be set to 0.0.0.0 for IPv4 or :: for 214 IPv6 because it is a point to multi-point tunnel. 216 The tunnelIfAddressType in the tunnelIfTable represents the type of 217 address in the corresponding tunnelIfLocalInetAddress and 218 tunnelIfRemoteInetAddress objects. The tunnelIfAddressType is 219 identical to swmEncapsIIPDstType in softwire mesh, which can support 220 either IPv4-over-IPv6 or IPv6-over-IPv4. When the 221 swmEncapsEIPDstType is IPv6 and the swmEncapsIIPDstType is IPv4, the 222 tunnel type is IPv6-over-IPv4; When the swmEncapsEIPDstType is IPv4 223 and the swmEncapsIIPDstType is IPv6, the encapsulation mode would be 224 IPv4-over-IPv6. 226 6.3. MIB modules required for IMPORTS 228 The following MIB module IMPORTS objects from SNMPv2-SMI [RFC2578], 229 SNMPv2-CONF [RFC2580], IF-MIB [RFC2863] and INET-ADDRESS-MIB 230 [RFC4001]. 232 7. Definitions 234 SOFTWIRE-MESH-MIB DEFINITIONS ::= BEGIN 236 IMPORTS 237 MODULE-IDENTITY, OBJECT-TYPE, transmission FROM SNMPv2-SMI 239 OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF 241 InetAddress, InetAddressType, InetAddressPrefixLength FROM INET-ADDRESS-MIB 243 ifIndex FROM IF-MIB 245 IANAtunnelType FROM IANAifType-MIB; 247 swmMIB MODULE-IDENTITY 248 LAST-UPDATED "201309030000Z" -- September 3, 2013 249 ORGANIZATION "Softwire Working Group" 250 CONTACT-INFO " 252 Yong Cui 253 Email: yong@csnet1.cs.tsinghua.edu.cn 255 Jiang Dong 256 Email: dongjiang@csnet1.cs.tsinghua.edu.cn 258 Peng Wu 259 Email: weapon@csnet1.cs.tsinghua.edu.cn 261 Mingwei Xu 262 Email: xmw@cernet.edu.cn 264 Antti Yla-Jaaski 265 Email: antti.yla-jaaski@aalto.fi 267 Email comments directly to the softwire WG Mailing 268 List at softwires@ietf.org 269 " 271 DESCRIPTION 272 "This MIB module contains managed object definitions for 273 the softwire mesh framework." 275 REVISION "201309030000Z" 276 DESCRIPTION 277 "The MIB module is defined for management of object in 278 the Softwire mesh framework." 279 ::= { transmission 999 } --999 to be replaced with correct value 281 swmMIBObjects OBJECT IDENTIFIER ::= { swmMIB 1 } 283 -- swmSupportedTunnelTable 284 swmSupportedTunnelTable OBJECT-TYPE 285 SYNTAX SEQUENCE OF SwmSupportedTunnelEntry 286 MAX-ACCESS not-accessible 287 STATUS current 288 DESCRIPTION 289 "A table of objects that shows what kind of tunnels 290 can be supported by the AFBR." 291 ::= { swmMIBObjects 1 } 293 swmSupportedTunnelEntry OBJECT-TYPE 294 SYNTAX SwmSupportedTunnelEntry 295 MAX-ACCESS not-accessible 296 STATUS current 297 DESCRIPTION 298 "A set of objects that show what kind of tunnels 299 can be supported in the AFBR. If the AFBR supports 300 multiple tunnel types, the swmSupportedTunnelTable 301 would have several entries." 302 INDEX { swmSupportedTunnelType } 303 ::= { swmSupportedTunnelTable 1 } 305 SwmSupportedTunnelEntry ::= SEQUENCE { 306 swmSupportedTunnelType IANAtunnelType 307 } 309 swmSupportedTunnelType OBJECT-TYPE 310 SYNTAX IANAtunnelType 311 MAX-ACCESS read-only 312 STATUS current 313 DESCRIPTION 314 "Represents the tunnel type that the AFBR support. " 315 ::= { swmSupportedTunnelEntry 1 } 316 -- end of swmSupportedTunnelTable 318 --swmEncapsTable 319 swmEncapsTable OBJECT-TYPE 320 SYNTAX SEQUENCE OF SwmEncapsEntry 321 MAX-ACCESS not-accessible 322 STATUS current 323 DESCRIPTION 324 "A table of objects that display and control the 325 softwire mesh encapsulation information." 326 ::= { swmMIBObjects 2 } 328 swmEncapsEntry OBJECT-TYPE 329 SYNTAX SwmEncapsEntry 330 MAX-ACCESS not-accessible 331 STATUS current 332 DESCRIPTION 333 "A table of objects that manage the softwire mesh I-IP 334 encapsulation destination based on the E-IP destination prefix." 335 INDEX { ifIndex, 336 swmEncapsEIPDstType, 337 swmEncapsEIPDst, 338 swmEncapsEIPMask 339 } 340 ::= { swmEncapsTable 1 } 342 SwmEncapsEntry ::= SEQUENCE { 343 swmEncapsEIPDstType InetAddressType, 344 swmEncapsEIPDst InetAddress, 345 swmEncapsEIPMask InetAddressPrefixLength, 346 swmEncapsIIPDstType InetAddressType, 347 swmEncapsIIPDst InetAddress 348 } 350 swmEncapsEIPDstType OBJECT-TYPE 351 SYNTAX InetAddressType 352 MAX-ACCESS not-accessible 353 STATUS current 354 DESCRIPTION 355 "This object specifies the address type used for 356 swmEncapsEIPDst. It is different from the tunnelIfAddressType 357 in the tunnelIfTable." 358 ::= { swmEncapsEntry 1 } 360 swmEncapsEIPDst OBJECT-TYPE 361 SYNTAX InetAddress 362 MAX-ACCESS not-accessible 363 STATUS current 364 DESCRIPTION 365 "The E-IP destination prefix, which is 366 used for I-IP encapsulation destination looking up." 367 ::= { swmEncapsEntry 2 } 369 swmEncapsEIPMask OBJECT-TYPE 370 SYNTAX InetAddressPrefixLength 371 MAX-ACCESS not-accessible 372 STATUS current 373 DESCRIPTION 374 "The prefix length of E-IP destination address." 375 ::= { swmEncapsEntry 3 } 377 swmEncapsIIPDstType OBJECT-TYPE 378 SYNTAX InetAddressType 379 MAX-ACCESS read-only 380 STATUS current 381 DESCRIPTION 382 "This object specifies the address type used for 383 swmEncapsIIPDst.It is the same as the tunnelIfAddressType 384 in the tunnelIfTable." 385 ::= { swmEncapsEntry 4 } 387 swmEncapsIIPDst OBJECT-TYPE 388 SYNTAX InetAddress 389 MAX-ACCESS read-only 390 STATUS current 391 DESCRIPTION 392 "The I-IP destination address, which is used as the encapsulation 393 destination for the corresponding E-IP prefix. Since the 394 tunnelIfRemoteInetAddress in the tunnelIfTable should be 0.0.0.0 or ::, 395 swmEncapIIPDst should be the destination address used in the outer 396 IP header." 397 ::= { swmEncapsEntry 5 } 398 -- End of swmEncapsTable 400 -- swmBGPNeighborTable 401 swmBGPNeighborTable OBJECT-TYPE 402 SYNTAX SEQUENCE OF SwmBGPNeighborEntry 403 MAX-ACCESS not-accessible 404 STATUS current 405 DESCRIPTION 406 "A table of objects that display the softwire mesh 407 BGP neighbor information." 408 ::= { swmMIBObjects 3 } 410 swmBGPNeighborEntry OBJECT-TYPE 411 SYNTAX SwmBGPNeighborEntry 412 MAX-ACCESS not-accessible 413 STATUS current 414 DESCRIPTION 415 "A set of objects that display the softwire mesh 416 BGP neighbor information." 417 INDEX { 418 ifIndex, 419 swmBGPNeighborInetAddressType, 420 swmBGPNeighborInetAddress 421 } 422 ::= { swmBGPNeighborTable 1 } 424 SwmBGPNeighborEntry ::= SEQUENCE { 425 swmBGPNeighborInetAddressType InetAddressType, 426 swmBGPNeighborInetAddress InetAddress, 427 swmBGPNeighborTunnelType IANAtunnelType 428 } 430 swmBGPNeighborInetAddressType OBJECT-TYPE 431 SYNTAX InetAddressType 432 MAX-ACCESS not-accessible 433 STATUS current 434 DESCRIPTION 435 "This object specifies the address type used for 436 swmBGPNeighborInetAddress." 437 ::= { swmBGPNeighborEntry 1 } 439 swmBGPNeighborInetAddress OBJECT-TYPE 440 SYNTAX InetAddress 441 MAX-ACCESS read-only 442 STATUS current 443 DESCRIPTION 444 "The address of the ABFR's BGP neighbor. The 445 address type is the same as the tunnelIfAddressType 446 in the tunnelIfTable." 447 ::= { swmBGPNeighborEntry 2 } 449 swmBGPNeighborTunnelType OBJECT-TYPE 450 SYNTAX IANAtunnelType 451 MAX-ACCESS read-only 452 STATUS current 453 DESCRIPTION 454 "Represents the type of tunnel that the 455 AFBR chooses to transmit traffic with another AFBR/BGP neighbor." 456 ::= { swmBGPNeighborEntry 3 } 457 -- End of swmBGPNeighborTable 459 -- conformance information 460 swmMIBConformance 461 OBJECT IDENTIFIER ::= { swmMIB 2 } 462 swmMIBCompliances 463 OBJECT IDENTIFIER ::= { swmMIBConformance 1 } 464 swmMIBGroups 465 OBJECT IDENTIFIER ::= { swmMIBConformance 2 } 467 -- compliance statements 468 swmMIBCompliance MODULE-COMPLIANCE 469 STATUS current 470 DESCRIPTION 471 "Describes the requirements for conformance to the softwire 472 mesh MIB. 474 The following index objects cannot be added as OBJECT 475 clauses but nevertheless have the compliance 476 requirements: 477 " 478 -- OBJECT swmEncapsEIPDstType 479 -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } 480 -- DESCRIPTION 481 -- "An implementation is required to support 482 -- global IPv4 and/or IPv6 addresses, depending 483 -- on its support for IPv4 and IPv6." 485 -- OBJECT swmEncapsEIPDst 486 -- SYNTAX InetAddress (SIZE(4|16)) 487 -- DESCRIPTION 488 -- "An implementation is required to support 489 -- global IPv4 and/or IPv6 addresses, depending 490 -- on its support for IPv4 and IPv6." 492 -- OBJECT swmEncapsEIPMask 493 -- SYNTAX InetAddressPrefixLength (ipv4(1),ipv4z(3),ipv6(2),ipv6z(2)) 494 -- DESCRIPTION 495 -- "An implementation is required to support 496 -- global IPv4 and/or IPv6 addresses, depending 497 -- on its support for IPv4 and IPv6." 499 -- OBJECT swmBGPNeighborInetAddressType 500 -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } 501 -- DESCRIPTION 502 -- "An implementation is required to support 503 -- global IPv4 and/or IPv6 addresses, depending 504 -- on its support for IPv4 and IPv6." 506 -- OBJECT swmBGPNeighborInetAddress 507 -- SYNTAX InetAddress (SIZE(4|16)) 508 -- DESCRIPTION 509 -- "An implementation is required to support 510 -- global IPv4 and/or IPv6 addresses, depending 511 -- on its support for IPv4 and IPv6." 513 MODULE -- this module 514 MANDATORY-GROUPS { 515 swmSupportedTunnelGroup, 516 swmEncapsGroup, 517 swmBGPNeighborGroup 518 } 519 ::= { swmMIBCompliances 1 } 521 swmSupportedTunnelGroup OBJECT-GROUP 522 OBJECTS { 523 swmSupportedTunnelType 524 } 525 STATUS current 526 DESCRIPTION 527 "The collection of objects which are used to show 528 what kind of tunnel the AFBR supports." 529 ::= { swmMIBGroups 1 } 531 swmEncapsGroup OBJECT-GROUP 532 OBJECTS { 533 swmEncapsEIPDst, 534 swmEncapsEIPMask, 535 swmEncapsIIPDst 536 } 537 STATUS current 538 DESCRIPTION 539 "The collection of objects which are used to display 540 softwire mesh encapsulation information." 541 ::= { swmMIBGroups 2 } 543 swmBGPNeighborGroup OBJECT-GROUP 544 OBJECTS { 545 swmBGPNeighborInetAddress, 546 swmBGPNeighborTunnelType 547 } 548 STATUS current 549 DESCRIPTION 550 "The collection of objects which are used to display 551 softwire mesh BGP neighbor information." 552 ::= { swmMIBGroups 3 } 554 END 556 8. Security Considerations 558 The swmMIB module can be used for configuration of certain objects, 559 and anything that can be configured can be incorrectly configured, 560 with potentially disastrous results. Because this MIB module reuses 561 the IP tunnel MIB, the security considerations of the IP tunnel MIB 562 is also applicable to the Softwire mesh MIB. 564 SNMP versions prior to SNMPv3 did not include adequate security. 565 Even if the network itself is secure (for example by using IPsec), 566 even then, there is no control as to who on the secure network is 567 allowed to access and GET/SET (read/change/create/delete) the objects 568 in this MIB module. 570 It is RECOMMENDED that implementers consider the security features as 571 provided by the SNMPv3 framework (see [RFC3410], section 8), 572 including full support for the SNMPv3 cryptographic mechanisms (for 573 authentication and privacy). 575 Further, deployment of SNMP versions prior to SNMPv3 is NOT 576 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 577 enable cryptographic security. It is then a customer/operator's 578 responsibility to ensure that the SNMP entity giving access to an 579 instance of this MIB module is properly configured to give access to 580 the objects only to those principals (users) that have legitimate 581 rights to indeed GET or SET (change/create/delete) them. 583 9. IANA Considerations 585 The MIB module in this document uses the following IANA-assigned 586 OBJECT IDENTIFIER values recorded in the SMI Numbers registry, and 587 the following IANA-assigned tunnelType values recorded in the 588 IANAtunnelType-MIB registry: 590 Descriptor OBJECT IDENTIFIER value 591 ---------- ----------------------- 592 swmMIB { transmission XXX } 594 IANAtunnelType ::= TEXTUAL-CONVENTION 595 SYNTAX INTEGER { 597 softwireMesh ("XX") -- softwire Mesh tunnel 599 } 601 10. Acknowledgements 603 The authors would like to thank Dave Thaler, Jean-Philippe Dionne, Qi 604 Sun, Sheng Jiang, Yu Fu for their valuable comments. 606 11. References 608 11.1. Normative References 610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, March 1997. 613 [RFC2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. 614 Schoenwaelder, Ed., "Structure of Management Information 615 Version 2 (SMIv2)", STD 58, RFC 2578, April 1999. 617 [RFC2579] McCloghrie, K., Ed., Perkins, D., Ed., and J. 618 Schoenwaelder, Ed., "Textual Conventions for SMIv2", 619 STD 58, RFC 2579, April 1999. 621 [RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder, 622 "Conformance Statements for SMIv2", STD 58, RFC 2580, 623 April 1999. 625 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 626 Problem Statement", RFC 4925, July 2007. 628 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 629 Subsequent Address Family Identifier (SAFI) and the BGP 630 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 632 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 633 Framework", RFC 5565, June 2009. 635 11.2. Informative References 637 [RFC2223] Postel, J. and J. Reynolds, "Instructions to RFC Authors", 638 RFC 2223, October 1997. 640 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 641 "Introduction and Applicability Statements for Internet- 642 Standard Management Framework", RFC 3410, December 2002. 644 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 645 June 1999. 647 [RFC4181] Heard, C., "Guidelines for Authors and Reviewers of MIB 648 Documents", BCP 111, RFC 4181, September 2005. 650 Authors' Addresses 652 Yong Cui 653 Tsinghua University 654 Department of Computer Science, Tsinghua University 655 Beijing 100084 656 P.R.China 658 Phone: +86-10-6260-3059 659 EMail: yong@csnet1.cs.tsinghua.edu.cn 660 Jiang Dong 661 Tsinghua University 662 Department of Computer Science, Tsinghua University 663 Beijing 100084 664 P.R.China 666 Phone: +86-10-6278-5822 667 EMail: dongjiang@csnet1.cs.tsinghua.edu.cn 669 Peng Wu 670 Tsinghua University 671 Department of Computer Science, Tsinghua University 672 Beijing 100084 673 P.R.China 675 Phone: +86-10-6278-5822 676 EMail: weapon@csnet1.cs.tsinghua.edu.cn 678 Mingwei Xu 679 Tsinghua University 680 Department of Computer Science, Tsinghua University 681 Beijing 100084 682 P.R.China 684 Phone: +86-10-6278-5822 685 EMail: xmw@cernet.edu.cn 687 Antti Yla-Jaaski 688 Aalto University 689 Konemiehentie 2 690 Espoo 02150 691 Finland 693 Phone: +358-40-5954222 694 EMail: antti.yla-jaaski@aalto.fi