idnits 2.17.1 draft-ietf-mip4-udptunnel-mib-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 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 lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2009) is 5540 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 normative reference: RFC 3344 (Obsoleted by RFC 5944) -- No information found for draft-ietf-mip4-rfc2006bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-mip4-rfc2006bis' Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Mobility for IPv4 Working Group Hans Sjostrand 2 Internet Draft Transmode 3 Intended status: Proposed standard February 23, 2009 5 The Definitions of Managed Objects for 6 Mobile IP UDP Tunneling 7 draft-ietf-mip4-udptunnel-mib-02 9 Status of this Memo 11 This Internet-Draft is submitted to IETF in full conformance with the 12 provisions of BCP 78 and BCP 79. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html 30 This Internet-Draft will expire on August 23, 2009. 32 Copyright Notice 34 Copyright (c) 2009 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents in effect on the date of 39 publication of this document (http://trustee.ietf.org/licenseinfo). 40 Please review these documents carefully, as they describe your rights 41 and restrictions with respect to this document. 43 Abstract 45 This memo defines the Management Information Base (MIB) for use with 46 network management protocols in TCP/IP-based internets. In 47 particular, it describes managed objects used for managing the Mobile 48 Node, Foreign Agent and Home Agent when Mobile IP Traversal of 49 Network Address Translation (NAT) Devices are used. 51 Table of Contents 53 1. Introduction...................................................3 54 2. The Internet-Standard Management Framework.....................3 55 3. Conventions....................................................3 56 4. Structure of the MIB...........................................3 57 4.1. Structure of the Mobile IP UDP Tunneling..................3 58 4.2. MIB Groups................................................4 59 5. Mobile IP UDP Tunnel MIB Definitions...........................5 60 6. Security Considerations.......................................11 61 7. IANA Considerations...........................................11 62 8. References....................................................12 63 8.1. Normative References.....................................12 64 8.2. Informative References...................................12 65 APPENDIX A: Changes in draft versions............................13 66 A.1. Changes in draft-ietf-mip4-udptunnel-mib-00..............13 67 A.2. Changes in draft-ietf-mip4-udptunnel-mib-02..............13 68 Author's Address.................................................14 70 1. Introduction 72 This memo defines a portion of the Management Information Base (MIB) 73 for use with network management protocols in the Internet community. 74 In particular, it describes managed objects used for managing the 75 Mobile Node, Foreign Agent and Home Agent when Mobile IP Traversal of 76 Network Address Translation (NAT) Devices are used. 78 2. The Internet-Standard Management Framework 80 For a detailed overview of the documents that describe the current 81 Internet-Standard Management Framework, please refer to section 7 of 82 RFC 3410 [RFC3410]. 84 Managed objects are accessed via a virtual information store, termed 85 the Management Information Base or MIB. MIB objects are generally 86 accessed through the Simple Network Management Protocol (SNMP). 87 Objects in the MIB are defined using the mechanisms defined in the 88 Structure of Management Information (SMI). This memo specifies a MIB 89 module that is compliant to the SMIv2, which is described in STD 58, 90 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 91 [RFC2580]. 93 3. Conventions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC2119 [RFC2119]. 99 4. Structure of the MIB 101 This memo defines a portion of the Management Information Base (MIB) 102 for the use with network management protocols in the Internet 103 community. In particular, it describes managed objects for the 104 Mobile IP Traversal of Network Address Translation (NAT) Devices as 105 defined in [RFC3519]. 107 4.1. Structure of the Mobile IP UDP Tunneling 109 The Mobile IP Traversal of Network Address Translation (NAT) Devices 110 specification [RFC3519] specifies a few managed entities. These are 111 the behavior to force and accept udp tunneling, and the configuration 112 of the keepalive timers. 114 The Mobile IP Traversal of Network Address Translation (NAT) Devices 115 specification [RFC3519] also specifies a new error code for 116 "Requested UDP tunnel encapsulation unavailable". Therefore a counter 117 object for this error code is also included in this mib module. 119 Further, it's good practice to include object to enable and disable 120 the MIP UDP tuning completely. 122 Configuration of MIP UDP tunneling has been deployed in various 123 vendor implementations for years. Field experience have shown that 124 it's indeed a good idea to always use UDP tunneling instead if the 125 original Mobile IP tunneling methods. Therefore, an object is added 126 in the HA to always force the use of UDP tunneling to all UDP 127 tunneling capable nodes, regardless of F-flag or outcome of NAT test. 129 4.2. MIB Groups 131 Objects in this MIB are arranged into groups. Each group is related 132 to the Mobile IP entities Mobile Node, Foreign Agent and Home Agent. 133 The Mobile IP entities Mobile Node, Foreign Agent and Home Agent are 134 described in [RFC3344]. 136 The managed objects in this document extend the management of the 137 Mobile IP entities Mobile Node, Foreign Agent and Home Agent as 138 described in [I-D.ietf-mip4-rfc2006bis]. 140 5. Mobile IP UDP Tunnel MIB Definitions 142 MIP-UDPTUNNEL-MIB DEFINITIONS ::= BEGIN 144 IMPORTS 145 Counter32, Unsigned32, MODULE-IDENTITY, 146 OBJECT-TYPE, mib-2 147 FROM SNMPv2-SMI -- [RFC2578] 148 TruthValue 149 FROM SNMPv2-TC -- [RFC2579] 150 MODULE-COMPLIANCE, OBJECT-GROUP 151 FROM SNMPv2-CONF; -- [RFC2580] 153 mipUdpTunnelMIB MODULE-IDENTITY 154 LAST-UPDATED "200902230000Z" 155 ORGANIZATION "IETF Mobility for IPv4 Group" 156 CONTACT-INFO 157 "Hans Sjostrand 158 Transmode 159 hans.sjostrand@transmode.com 161 Comments about this document should be emailed 162 directly to the Mip4 working group mailing list at 163 mip4@ietf.org" 165 DESCRIPTION 166 "The MIB module for configuring and displaying Mobile 167 IP Traversal of Network Address Translation (NAT) 168 Devices information. 170 Copyright (C) IETF Trust (2009). This version 171 of this MIB module is part of RFC yyyy; see the RFC 172 itself for full legal notices." 174 REVISION "200902230000Z" 175 DESCRIPTION 176 "Initial version issued as part of RFC yyyy." 177 -- RFC Ed.: replace yyyy with actual RFC number & remove this note 179 ::= { mib-2 XXX } 180 -- RFC Ed.: replace XXX with IANA-assigned number & remove this note 182 mipUdpTunnelMIBObjects OBJECT IDENTIFIER ::= { mipUdpTunnelMIB 1 } 184 mnUdpTunnel OBJECT IDENTIFIER ::= { mipUdpTunnelMIBObjects 1 } 185 haUdpTunnel OBJECT IDENTIFIER ::= { mipUdpTunnelMIBObjects 2 } 186 faUdpTunnel OBJECT IDENTIFIER ::= { mipUdpTunnelMIBObjects 3 } 187 -- ================================================================= 188 -- mnUdpTunnel Group 190 mnUdpTunnelEnable OBJECT-TYPE 191 SYNTAX TruthValue 192 MAX-ACCESS read-write 193 STATUS current 194 DESCRIPTION 195 "This parameter enables and disables the RFC 3519 UDP 196 tunneling function in the MN completely." 197 DEFVAL { true } 198 ::= { mnUdpTunnel 1 } 200 mnUdpTunnelForce OBJECT-TYPE 201 SYNTAX TruthValue 202 MAX-ACCESS read-write 203 STATUS current 204 DESCRIPTION 205 "This parameter enables (or disables) the MN to set 206 the F (force) flag. It indicates that the mobile 207 node wants to use traversal regardless of the 208 outcome of NAT detection performed by the home agent." 209 REFERENCE 210 "RFC3519, MIP Traversal of NAT Devices, Section 3.1.1" 211 DEFVAL { false } 212 ::= { mnUdpTunnel 2 } 214 mnUdpTunnelKeepaliveInterval OBJECT-TYPE 215 SYNTAX Unsigned32 216 UNITS "seconds" 217 MAX-ACCESS read-write 218 STATUS current 219 DESCRIPTION 220 "Defines the default NAT keepalive interval that the 221 mobile node will use in the case that the HA does 222 not impose another value by setting the Keepalive 223 Interval in the UDP Tunnel Reply Extension." 224 REFERENCE 225 "RFC3519, MIP Traversal of NAT Devices, Section 4.9" 226 DEFVAL { 110 } 227 ::= { mnUdpTunnel 3 } 229 -- ================================================================= 230 -- haUdpTunnel Group 231 haUdpTunnelEnable OBJECT-TYPE 232 SYNTAX TruthValue 233 MAX-ACCESS read-write 234 STATUS current 235 DESCRIPTION 236 "This parameter enables and disables the RFC 3519 UDP 237 tunneling function in the HA completely." 238 DEFVAL { true } 239 ::= { haUdpTunnel 1 } 241 haUdpTunnelKeepaliveInterval OBJECT-TYPE 242 SYNTAX Unsigned32 243 UNITS "seconds" 244 MAX-ACCESS read-write 245 STATUS current 246 DESCRIPTION 247 "This parameter sets the keepalive interval override. 248 Normally, the MN uses the keepalive time that was 249 configured using UDP tunneling and sending 250 keepalive messages. The HA can override this 251 configured keepalive time by setting a new 252 interval value for this parameter to a value other 253 than zero." 254 REFERENCE 255 "RFC3519, MIP Traversal of NAT Devices, Section 3.2" 256 DEFVAL { 0 } 257 ::= { haUdpTunnel 2 } 259 haUdpTunnelForce OBJECT-TYPE 260 SYNTAX TruthValue 261 MAX-ACCESS read-write 262 STATUS current 263 DESCRIPTION 264 "This parameter enables and disables the HA forcing all 265 connections from MNs which support RFC 3519 UDP 266 tunneling to use tunneling whether or not the 267 presence of a NAT is detected." 268 REFERENCE 269 "RFC3519, MIP Traversal of NAT Devices, Section 6.3" 270 DEFVAL { false } 271 ::= { haUdpTunnel 3 } 273 haUdpTunnelEncapUnavail OBJECT-TYPE 274 SYNTAX Counter32 275 MAX-ACCESS read-only 276 STATUS current 277 DESCRIPTION 278 "Total number of Registration Requests denied by the 279 home agent -- Requested UDP tunnel encapsulation 280 unavailable (code 142)." 281 REFERENCE 282 "RFC3519, MIP Traversal of NAT Devices, Section 3.5" 283 ::= { haUdpTunnel 4 } 285 -- ================================================================= 286 -- faUdpTunnel Group 288 faUdpTunnelEnable OBJECT-TYPE 289 SYNTAX TruthValue 290 MAX-ACCESS read-write 291 STATUS current 292 DESCRIPTION 293 "This parameter enables and disables the RFC 3519 UDP 294 tunneling function in the FA completely." 295 DEFVAL { true } 296 ::= { faUdpTunnel 1 } 298 faUdpTunnelForce OBJECT-TYPE 299 SYNTAX TruthValue 300 MAX-ACCESS read-write 301 STATUS current 302 DESCRIPTION 303 "This parameter enables (or disables) the FA to set 304 the F (force) flag. It indicates that the foreign 305 agent wants to use traversal regardless of the 306 outcome of NAT detection performed by the home agent." 307 REFERENCE 308 "RFC3519, MIP Traversal of NAT Devices, Section 3.1.1" 309 DEFVAL { false } 310 ::= { faUdpTunnel 2 } 312 faUdpTunnelKeepaliveInterval OBJECT-TYPE 313 SYNTAX Unsigned32 314 UNITS "seconds" 315 MAX-ACCESS read-write 316 STATUS current 317 DESCRIPTION 318 "Defines the default NAT keepalive interval that the 319 foreign agent will use in the case that the HA does 320 not impose another value by setting the Keepalive 321 Interval in the UDP Tunnel Reply Extension." 322 REFERENCE 323 "RFC3519, MIP Traversal of NAT Devices, Section 4.9" 325 DEFVAL { 110 } 326 ::= { faUdpTunnel 3 } 328 -- ================================================================= 329 -- MIP Conformance Statements 331 mipUdpTunnelConformance 332 OBJECT IDENTIFIER ::= { mipUdpTunnelMIB 2 } 334 mipUdpTunnelGroups 335 OBJECT IDENTIFIER ::= { mipUdpTunnelConformance 1 } 336 mipUdpTunnelCompliances 337 OBJECT IDENTIFIER ::= { mipUdpTunnelConformance 2 } 339 -- 340 -- compliance statements 341 -- 343 mipUdpTunnelCompliance MODULE-COMPLIANCE 344 STATUS current 345 DESCRIPTION 346 "The compliance statement for SNMPv2 entities which 347 implement the Mobile IP UDP Tunnel MIB." 348 MODULE 350 GROUP mnUdpTunnelGroup 351 DESCRIPTION 352 "This group is mandatory for a mobile node." 354 GROUP haUdpTunnelGroup 355 DESCRIPTION 356 "This group is mandatory for a home agent." 358 GROUP faUdpTunnelGroup 359 DESCRIPTION 360 "This group is mandatory for a foreign agent." 362 ::= { mipUdpTunnelCompliances 1 } 364 -- 365 -- Units of conformance 366 -- 368 mnUdpTunnelGroup OBJECT-GROUP 369 OBJECTS { mnUdpTunnelEnable, mnUdpTunnelForce, 370 mnUdpTunnelKeepaliveInterval } 371 STATUS current 372 DESCRIPTION 373 "A collection of objects providing management 374 information for theuse of UDP tunneling according to 375 RFC3519 within a mobile node." 376 ::= { mipUdpTunnelGroups 1 } 378 haUdpTunnelGroup OBJECT-GROUP 379 OBJECTS { haUdpTunnelEnable, haUdpTunnelForce, 380 haUdpTunnelKeepaliveInterval, 381 haUdpTunnelEncapUnavail } 382 STATUS current 383 DESCRIPTION 384 "A collection of objects providing management 385 information for theuse of UDP tunneling according to 386 RFC3519 within a home agent." 387 ::= { mipUdpTunnelGroups 2 } 389 faUdpTunnelGroup OBJECT-GROUP 390 OBJECTS { faUdpTunnelEnable, faUdpTunnelForce, 391 faUdpTunnelKeepaliveInterval } 392 STATUS current 393 DESCRIPTION 394 "A collection of objects providing management 395 information for theuse of UDP tunneling according to 396 RFC3519 within a foreign agent." 397 ::= { mipUdpTunnelGroups 3 } 399 END 400 6. Security Considerations 402 Assuming that secure network management (such as SNMP v3) is 403 implemented, the objects represented in this MIB do not pose a threat 404 to the security of the network. 406 There are a number of management objects defined in this MIB that 407 have a MAX-ACCESS clause of read-write. Such objects may be 408 considered sensitive or vulnerable in some network environments. The 409 support for SET operations in a non-secure environment without proper 410 protection can have a negative effect on network operations. 412 SNMP versions prior to SNMPv3 did not include adequate security. Even 413 if the network itself is secure (for example by using IPsec), even 414 then, there is no control as to who on the secure network is allowed 415 to access and GET/SET (read/change/create/delete) the objects in this 416 MIB module. 418 It is RECOMMENDED that implementers consider the security features as 419 provided by the SNMPv3 framework (see [RFC3410], section 8), 420 including full support for the SNMPv3 cryptographic mechanisms (for 421 authentication and privacy). 423 Further, deployment of SNMP versions prior to SNMPv3 is NOT 424 RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 425 enable cryptographic security. It is then a customer/operator 426 responsibility to ensure that the SNMP entity giving access to an 427 instance of this MIB module is properly configured to give access to 428 the objects only to those principals (users) that have legitimate 429 rights to indeed GET or SET (change/create/delete) them. 431 7. IANA Considerations 433 The IANA is requested to assign a value for "XXX" under the 'mib-2' 434 subtree and to record the assignment in the SMI Numbers registry. 436 Note to RFC Editor. When the assignment has been made, the RFC Editor 437 is asked to replace "XXX" in this document with the assigned value 438 (here and in the MIB module) and to remove this note. 440 8. References 442 8.1. Normative References 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, March 1997. 447 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 448 Rose, M. and S. Waldbusser, "Structure of Management 449 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 450 1999. 452 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 453 Rose, M. and S. Waldbusser, "Textual Conventions for 454 SMIv2", STD 58, RFC 2579, April 1999. 456 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 457 Rose, M. and S. Waldbusser, "Conformance Statements for 458 SMIv2", STD 58, RFC 2580, April 1999. 460 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 461 August 2002. 463 [RFC3519] H. Levkowetz and S. Vaarala, "Mobile IP Traversal of 464 Network Address Translation (NAT) Devices", RFC 3519, April 465 2003 467 [I-D.ietf-mip4-rfc2006bis] K. Leung, R. Rathi and H. Sjostrand, "The 468 Definitions of Managed Objects for IP Mobility Support 469 using SMIv2, revised", Work in progress 471 8.2. Informative References 473 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 474 "Introduction and Applicability Statements for Internet- 475 Standard Management Framework", RFC 3410, December 2002. 477 APPENDIX A: Changes in draft versions 479 Note to RFC Editor. At time of publication, this appendix should be 480 removed. 482 A.1. Changes in draft-ietf-mip4-udptunnel-mib-00 484 Changes compared with draft-sjostrand-mip4-udptunnel-mib-01 which was 485 accepted as WG doc in Prague March 21, 2007. 487 - Minor boilerplate updates, date changes, version numbers, speling 488 errors etc. 490 - Added reference clauses to RFC3519 where applicable 492 - Removed "haUdpTunnelPermitMnForce". It was meant to provide 493 configuration to an ambiguous SHOULD in RFC3519, section 3.1.1 but I 494 think it created more ambiguity than it clarified. 496 - Clarified that IANA shall handle mipMIB OID, in 497 http://www.iana.org/assignments/smi-numbers. IANA considerations 498 chapter written and open issue about OID placement removed. 500 A.2. Changes in draft-ietf-mip4-udptunnel-mib-02 502 Changes compared with draft-ietf-mip4-udptunnel-mib-01 (which just 503 had editorial updates compared with the 00-version). 505 - Changed OID root from {mipMIB X} to {mib-2 XXX} according to 506 RFC4181 recommendations. And updated IANA considerations accordingly. 508 - Updated boilerplate according to "Legal Provisions Relating to IETF 509 Documents" from IETF Trust 511 - Removed open issue about default values, the values has been like 512 this now for 2 years and no other suggestions have been made. 514 - Updated contact data. 516 Author's Address 518 Hans Sjostrand 519 Transmode 520 Jakobsdalsvagen 17 521 126 53 Hagersten 522 Sweden 523 Phone: +46 8 410 88 000 524 Email: hans.sjostrand@transmode.com 526 Acknowledgment 528 Funding for the RFC Editor function is currently provided by the IETF 529 Administrative Support Activity (IASA).