idnits 2.17.1 draft-scharf-tcpm-yang-tcp-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 11 instances of too long lines in the document, the longest one being 114 characters in excess of 72. ** The abstract seems to contain references ([RFC4022]), 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 == Line 279 has weird spacing: '...Address ine...' == Line 288 has weird spacing: '...essType ine...' == Line 297 has weird spacing: '...essType ine...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 11, 2018) is 2022 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 793 (Obsoleted by RFC 9293) == Outdated reference: A later version (-36) exists of draft-ietf-netconf-netconf-client-server-07 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-20 Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM M. Scharf 3 Internet-Draft Hochschule Esslingen 4 Intended status: Standards Track October 11, 2018 5 Expires: April 14, 2019 7 Transmission Control Protocol (TCP) YANG Model 8 draft-scharf-tcpm-yang-tcp-00 10 Abstract 12 This document specifies a base YANG model for TCP on devices that are 13 configured by network management protocols. The YANG model follows 14 the standard TCP-MIB [RFC4022]. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 14, 2019. 33 Copyright Notice 35 Copyright (c) 2018 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (https://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Why a YANG Model for TCP? . . . . . . . . . . . . . . . . 3 52 1.2. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 4 53 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 54 3. Overview of the YANG Model for TCP . . . . . . . . . . . . . 5 55 3.1. Model Design . . . . . . . . . . . . . . . . . . . . . . 5 56 3.2. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 6 57 4. TCP YANG Model . . . . . . . . . . . . . . . . . . . . . . . 7 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 19 62 7.2. Informative References . . . . . . . . . . . . . . . . . 21 63 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22 66 1. Introduction 68 The Transmission Control Protocol (TCP) [RFC0793] is used by several 69 control and management protocols in the Internet. Therefore, TCP is 70 implemented on network elements that can be configured via network 71 management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. 72 This document specifies a YANG data model [RFC6020][RFC7950] for 73 configuring and operating TCP on network elements that support YANG 74 data models. 76 Many protocol stacks on Internet hosts use other methods to configure 77 TCP, such as operating system configuration or policies. Such TCP 78 stacks typically cannot be configured by network management protocols 79 such as NETCONF or RESTCONF. This document only applies to network 80 elements that use YANG data models. 82 This document is related to other standardization efforts. A 83 Management Information Base (MIB) for the Transmission Control 84 Protocol (TCP) has been standardized [RFC4022], and various managed 85 network devices support the TCP-MIB. A MIB providing extended 86 statistics for TCP is also available [RFC4898]. In addition, there 87 are also MIBs for UDP [RFC4113] and SCTP [RFC3873]. 89 This documents defines a YANG data model for configuration and 90 operational state of a TCP implementation. The model focuses on 91 fundamental and standard TCP functions. The model can be augmented 92 to address more advanced or implementation-specific TCP features. 94 1.1. Why a YANG Model for TCP? 96 [[Editor's node: This section shall be removed or reworded in later 97 versions of the document.]] 99 This section summarizes reasons why the specification of a YANG model 100 for TCP could be useful to maintain TCP's utility. 102 As more and more network elements can be managed by management 103 protocols such as NETCONF or RESTCONF, network elements may need a 104 YANG model for TCP stack configuration and operation. This could in 105 particular apply to network elements that support the TCP-MIB 106 [RFC4022] but migrate to management by NETCONF or RESTCONF. In such 107 cases, one option would be to translate the TCP-MIB into a YANG 108 model, for instance using the translation described in [RFC6643]. 109 However, such a translated YANG model neither allows configuration, 110 nor is the content up-to-date. For instance, the TCP-MIB refers to 111 standards that have been obsoleted. 113 Given the advantages of YANG, there are also many ongoing efforts to 114 define YANG models. An increasing number of YANG models include TCP 115 and TCP-related parameters for specific usage scenarios. Examples 116 are: 118 o TCP connection properties such as use of keep-alives can be 119 configured by [I-D.ietf-netconf-netconf-client-server]. 121 o TCP header attributes are modeled in [I-D.ietf-netmod-acl-model]. 123 o TCP-related configuration of a NAT is defined in 124 [I-D.ietf-opsawg-nat-yang]. 126 It is possible that further YANG models would include aspects of or 127 relate to TCP stack configuration. An example could be YANG models 128 for other TCP-based protocols running on network elements. Instead 129 of specifying TCP configuration separately for each use cases, a 130 better alternative may be to define a common YANG model for TCP, from 131 which definitions and objects could be reused as needed. 133 The intention of this document is to explore whether a YANG model for 134 TCP is useful, and if so, what such a model would include (and what 135 not). 137 This document targets the TCPM working group as the TCPM charter 138 includes work on "interfaces that maintain TCP's utility". The YANG 139 model deals with the network management interface of a TCP 140 implementation. The interface used for data transfer between an 141 application and the TCP stack is outside the scope of this document. 143 1.2. Open Issues 145 [[Editor's node: This section shall be removed in later versions of 146 the document.]] 148 There are many open questions on the scope of this document that need 149 discussion and community feedback: 151 o Scope: TCP stacks can typically be customized by configuration, 152 including implementation-specific internal behavior. A standard 153 YANG model should focus on fundamental TCP parameters that are 154 independent of the internals of an implementation, that are 155 available in all or most implementations, and that matter for 156 network management. This set of TCP configuration parameters 157 needs to be determined. Additional implementation-specific 158 configuration could be added by augmentation of the YANG model and 159 would not require standardization. 161 o Backward compatibility: There may be implementations that support 162 the TCP-MIB [RFC4022], possibly in addition to YANG models. In 163 such cases, one option could be to translate the TCP-MIB [RFC4022] 164 into an equivalent YANG model. The TCP-MIB is not up-to-date. 165 Additions could be needed to reflect e.g. the progress of TCP 166 standards. It is an open question whether a YANG model would need 167 "backward-compatibility" to TCP-MIB entries, and, if so, if this 168 is needed for all TCP-MIB entries. 170 o General definitions: A TCP model could perhaps include general 171 YANG type definitions and groupings for TCP. They could be reused 172 by other YANG models. Having a common definition of TCP-related 173 attributes could ensure consistency. It is an open question 174 whether definitions in a TCP model would indeed be used by other 175 YANG models. 177 o Extended statistics: It needs to be decided whether extended 178 statistics [RFC4898] would be in scope of a TCP YANG model. 180 o Suggested MIB additions: Extensions to the TCP-MIB [RFC4022] have 181 been suggested, e.g., in [RFC5482]. A YANG model could possibly 182 take into account such proposed extensions. 184 o Cross-layer functionality: The TCP configuration may have 185 dependencies on other protocols. It needs to be figured out if 186 and how this can be modelled. An example could be enabling of TCP 187 keep-alives, which should be off by default [RFC1122]. 189 o Alignment: Further discussion is needed on alignment of a TCP YANG 190 model with other transport protocols. This would include UDP and 191 SCTP. 193 o Status of [RFC4022]: Standardization of a YANG model does not 194 affect an existing MIB. As a result, updating or deprecating 195 [RFC4022] may not be necessary even if a YANG model for TCP is 196 standardized. However, more analysis is needed on how future 197 versions of this I-D would relate to or reference [RFC4022]. 199 o Implementation aspects: Implementation aspects of a YANG model for 200 TCP need further analysis. 202 o Authoring: If there is a need for similarity to the TCP-MIB, 203 authors and contributors to [RFC4022] could/should be added as 204 authors or contributors to this document. 206 2. Requirements Language 208 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 209 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 210 "OPTIONAL" in this document are to be interpreted as described in BCP 211 14 [RFC2119] [RFC8174] when, and only when, they appear in all 212 capitals, as shown here. 214 3. Overview of the YANG Model for TCP 216 [[Editor's node: This section should to be improved in follow-up 217 versions of this document.]] 219 3.1. Model Design 221 [[Editor's node: In potential follow-up versions of this document, 222 this section will discuss the design of the TCP YANG model.]] 224 A standard YANG data model for TCP should follow the Network 225 Management Datastore Architecture (NMDA) [RFC8342]. 227 The YANG model in the -00 version of this document has been 228 translated from the TCP-MIB [RFC4022] without modifications (apart 229 from removing outdated meta-data). The motivation of using the 230 standard TCP-MIB definitions as a baseline for -00 is to facilitate 231 the tracking of potential changes in later versions of this 232 specification, as far as this is needed. 234 The TCP-MIB defined in [RFC4022] consists of several objects and two 235 tables: 237 o Parameters of a TCP protocol engine. These include parameters 238 such as the retransmission algorithm in use and the retransmission 239 timeout values. 241 o Statistics of a TCP protocol engine. These include counters for 242 the number of active/passive opens, input/output segments, and 243 errors. 245 o A TCP connection table provides access to status information for 246 all TCP connections handled by a TCP protocol engine. In 247 addition, the table reports identification of the operating system 248 level processes that handle the TCP connections. 250 o A TCP listener table provides access to information about all TCP 251 listening endpoints known by a TCP protocol engine. And as with 252 the connection table, this table also reports the identification 253 of the operating system level processes that handle this listening 254 TCP endpoint. 256 The extended statistics defined in [RFC4898] have been omitted in the 257 initial version of this specification. They can be added as needed. 259 3.2. Tree Diagram 261 [[Editor's node: This section is TBD.]] 263 module: TCP-MIB 264 +--rw tcp 265 +--ro tcpRtoAlgorithm? enumeration 266 +--ro tcpRtoMin? int32 267 +--ro tcpRtoMax? int32 268 +--ro tcpMaxConn? int32 269 +--ro tcpActiveOpens? yang:counter32 270 +--ro tcpPassiveOpens? yang:counter32 271 +--ro tcpAttemptFails? yang:counter32 272 +--ro tcpEstabResets? yang:counter32 273 +--ro tcpCurrEstab? yang:gauge32 274 +--ro tcpInSegs? yang:counter32 275 +--ro tcpOutSegs? yang:counter32 276 +--ro tcpRetransSegs? yang:counter32 277 x--rw tcpConnEntry* [tcpConnLocalAddress tcpConnLocalPort tcpConnRemAddress tcpConnRemPort] 278 | x--rw tcpConnState? enumeration 279 | x--ro tcpConnLocalAddress inet:ipv4-address 280 | x--ro tcpConnLocalPort int32 281 | x--ro tcpConnRemAddress inet:ipv4-address 282 | x--ro tcpConnRemPort int32 283 +--ro tcpInErrs? yang:counter32 284 +--ro tcpOutRsts? yang:counter32 285 +--ro tcpHCInSegs? yang:counter64 286 +--ro tcpHCOutSegs? yang:counter64 287 +--rw tcpConnectionEntry* [tcpConnectionLocalAddressType tcpConnectionLocalAddress tcpConnectionLocalPort tcpConnectionRemAddressType tcpConnectionRemAddress tcpConnectionRemPort] 288 | +--ro tcpConnectionLocalAddressType inet-address:InetAddressType 289 | +--ro tcpConnectionLocalAddress inet-address:InetAddress 290 | +--ro tcpConnectionLocalPort inet-address:InetPortNumber 291 | +--ro tcpConnectionRemAddressType inet-address:InetAddressType 292 | +--ro tcpConnectionRemAddress inet-address:InetAddress 293 | +--ro tcpConnectionRemPort inet-address:InetPortNumber 294 | +--rw tcpConnectionState? enumeration 295 | +--ro tcpConnectionProcess? uint32 296 +--rw tcpListenerEntry* [tcpListenerLocalAddressType tcpListenerLocalAddress tcpListenerLocalPort] 297 +--ro tcpListenerLocalAddressType inet-address:InetAddressType 298 +--ro tcpListenerLocalAddress inet-address:InetAddress 299 +--ro tcpListenerLocalPort inet-address:InetPortNumber 300 +--ro tcpListenerProcess? uint32 302 4. TCP YANG Model 304 [[Editor's node: This section is TBD.]] 306 The following YANG module has been generated by smidump 0.4.8 using 307 the command "smidump -f yang TCP-MIB". Improvements to the 308 translated YANG model are planed for future versions of this 309 specification. The -00 version of this model is just published as a 310 baseline and to enable tracking of changes in later versions of the 311 memo. 313 file "ietf-tcp-translated@2005-02-18.yang" 314 module TCP-MIB { 316 /*** NAMESPACE / PREFIX DEFINITION ***/ 318 namespace "urn:ietf:params:xml:ns:yang:smiv2:TCP-MIB"; 319 prefix "tcp-mib"; 321 /*** LINKAGE (IMPORTS / INCLUDES) ***/ 323 import INET-ADDRESS-MIB { prefix "inet-address"; } 324 import inet-types { prefix "inet"; } 325 import yang-types { prefix "yang"; } 327 /*** META INFORMATION ***/ 329 organization 330 "TBD"; 332 contact 333 "TBD"; 335 description 336 "TBD"; 338 revision "2005-02-18" { 339 description 340 "IP version neutral revision, published as RFC 4022."; 341 } 342 revision "1994-11-01" { 343 description 344 "Initial SMIv2 version, published as RFC 2012."; 345 } 346 revision "1991-03-31" { 347 description 348 "The initial revision of this MIB module was part of 349 MIB-II."; 350 } 352 container tcp { 354 leaf tcpRtoAlgorithm { 355 type enumeration { 356 enum other { value 1; } 357 enum constant { value 2; } 358 enum rsre { value 3; } 359 enum vanj { value 4; } 360 enum rfc2988 { value 5; } 361 } 362 config false; 363 description 364 "The algorithm used to determine the timeout value used for 365 retransmitting unacknowledged octets."; 366 } 368 leaf tcpRtoMin { 369 type int32 { 370 range "0..2147483647"; 371 } 372 units "milliseconds"; 373 config false; 374 description 375 "The minimum value permitted by a TCP implementation for 376 the retransmission timeout, measured in milliseconds. 377 More refined semantics for objects of this type depend 378 on the algorithm used to determine the retransmission 379 timeout; in particular, the IETF standard algorithm 380 rfc2988(5) provides a minimum value."; 381 } 383 leaf tcpRtoMax { 384 type int32 { 385 range "0..2147483647"; 386 } 387 units "milliseconds"; 388 config false; 389 description 390 "The maximum value permitted by a TCP implementation for 391 the retransmission timeout, measured in milliseconds. 392 More refined semantics for objects of this type depend 393 on the algorithm used to determine the retransmission 394 timeout; in particular, the IETF standard algorithm 395 rfc2988(5) provides an upper bound (as part of an 396 adaptive backoff algorithm)."; 397 } 399 leaf tcpMaxConn { 400 type int32 { 401 range "-1..2147483647"; 402 } 403 config false; 404 description 405 "The limit on the total number of TCP connections the entity 406 can support. In entities where the maximum number of 407 connections is dynamic, this object should contain the 408 value -1."; 409 } 411 leaf tcpActiveOpens { 412 type yang:counter32; 413 config false; 414 description 415 "The number of times that TCP connections have made a direct 416 transition to the SYN-SENT state from the CLOSED state. 418 Discontinuities in the value of this counter are 419 indicated via discontinuities in the value of sysUpTime."; 420 } 422 leaf tcpPassiveOpens { 423 type yang:counter32; 424 config false; 425 description 426 "The number of times TCP connections have made a direct 427 transition to the SYN-RCVD state from the LISTEN state. 429 Discontinuities in the value of this counter are 430 indicated via discontinuities in the value of sysUpTime."; 431 } 433 leaf tcpAttemptFails { 434 type yang:counter32; 435 config false; 436 description 437 "The number of times that TCP connections have made a direct 438 transition to the CLOSED state from either the SYN-SENT 439 state or the SYN-RCVD state, plus the number of times that 440 TCP connections have made a direct transition to the 441 LISTEN state from the SYN-RCVD state. 443 Discontinuities in the value of this counter are 444 indicated via discontinuities in the value of sysUpTime."; 445 } 447 leaf tcpEstabResets { 448 type yang:counter32; 449 config false; 450 description 451 "The number of times that TCP connections have made a direct 452 transition to the CLOSED state from either the ESTABLISHED 453 state or the CLOSE-WAIT state. 455 Discontinuities in the value of this counter are 456 indicated via discontinuities in the value of sysUpTime."; 457 } 459 leaf tcpCurrEstab { 460 type yang:gauge32; 461 config false; 462 description 463 "The number of TCP connections for which the current state 464 is either ESTABLISHED or CLOSE-WAIT."; 465 } 467 leaf tcpInSegs { 468 type yang:counter32; 469 config false; 470 description 471 "The total number of segments received, including those 472 received in error. This count includes segments received 473 on currently established connections. 475 Discontinuities in the value of this counter are 476 indicated via discontinuities in the value of sysUpTime."; 477 } 479 leaf tcpOutSegs { 480 type yang:counter32; 481 config false; 482 description 483 "The total number of segments sent, including those on 484 current connections but excluding those containing only 485 retransmitted octets. 487 Discontinuities in the value of this counter are 488 indicated via discontinuities in the value of sysUpTime."; 489 } 491 leaf tcpRetransSegs { 492 type yang:counter32; 493 config false; 494 description 495 "The total number of segments retransmitted; that is, the 496 number of TCP segments transmitted containing one or more 497 previously transmitted octets. 499 Discontinuities in the value of this counter are 500 indicated via discontinuities in the value of sysUpTime."; 501 } 502 /* XXX table comments here XXX */ 504 list tcpConnEntry { 506 key "tcpConnLocalAddress tcpConnLocalPort 507 tcpConnRemAddress tcpConnRemPort"; 508 status deprecated; 509 description 510 "A conceptual row of the tcpConnTable containing information 511 about a particular current IPv4 TCP connection. Each row 512 of this table is transient in that it ceases to exist when 513 (or soon after) the connection makes the transition to the 514 CLOSED state."; 516 leaf tcpConnState { 517 type enumeration { 518 enum closed { value 1; } 519 enum listen { value 2; } 520 enum synSent { value 3; } 521 enum synReceived { value 4; } 522 enum established { value 5; } 523 enum finWait1 { value 6; } 524 enum finWait2 { value 7; } 525 enum closeWait { value 8; } 526 enum lastAck { value 9; } 527 enum closing { value 10; } 528 enum timeWait { value 11; } 529 enum deleteTCB { value 12; } 530 } 531 config true; 532 status deprecated; 533 description 534 "The state of this TCP connection. 536 The only value that may be set by a management station is 537 deleteTCB(12). Accordingly, it is appropriate for an agent 538 to return a `badValue' response if a management station 539 attempts to set this object to any other value. 541 If a management station sets this object to the value 542 deleteTCB(12), then the TCB (as defined in [RFC793]) of 543 the corresponding connection on the managed node is 544 deleted, resulting in immediate termination of the 545 connection. 547 As an implementation-specific option, a RST segment may be 548 sent from the managed node to the other TCP endpoint (note, 549 however, that RST segments are not sent reliably)."; 550 } 552 leaf tcpConnLocalAddress { 553 type inet:ipv4-address; 554 config false; 555 status deprecated; 556 description 557 "The local IP address for this TCP connection. In the case 558 of a connection in the listen state willing to 559 accept connections for any IP interface associated with the 560 node, the value 0.0.0.0 is used."; 561 } 563 leaf tcpConnLocalPort { 564 type int32 { 565 range "0..65535"; 566 } 567 config false; 568 status deprecated; 569 description 570 "The local port number for this TCP connection."; 571 } 573 leaf tcpConnRemAddress { 574 type inet:ipv4-address; 575 config false; 576 status deprecated; 577 description 578 "The remote IP address for this TCP connection."; 579 } 581 leaf tcpConnRemPort { 582 type int32 { 583 range "0..65535"; 584 } 585 config false; 586 status deprecated; 587 description 588 "The remote port number for this TCP connection."; 589 } 590 } 592 leaf tcpInErrs { 593 type yang:counter32; 594 config false; 595 description 596 "The total number of segments received in error (e.g., bad 597 TCP checksums). 599 Discontinuities in the value of this counter are 600 indicated via discontinuities in the value of sysUpTime."; 601 } 603 leaf tcpOutRsts { 604 type yang:counter32; 605 config false; 606 description 607 "The number of TCP segments sent containing the RST flag. 609 Discontinuities in the value of this counter are 610 indicated via discontinuities in the value of sysUpTime."; 611 } 613 leaf tcpHCInSegs { 614 type yang:counter64; 615 config false; 616 description 617 "The total number of segments received, including those 618 received in error. This count includes segments received 620 on currently established connections. This object is 621 the 64-bit equivalent of tcpInSegs. 623 Discontinuities in the value of this counter are 624 indicated via discontinuities in the value of sysUpTime."; 625 } 627 leaf tcpHCOutSegs { 628 type yang:counter64; 629 config false; 630 description 631 "The total number of segments sent, including those on 632 current connections but excluding those containing only 633 retransmitted octets. This object is the 64-bit 634 equivalent of tcpOutSegs. 636 Discontinuities in the value of this counter are 637 indicated via discontinuities in the value of sysUpTime."; 638 } 640 /* XXX table comments here XXX */ 642 list tcpConnectionEntry { 643 key "tcpConnectionLocalAddressType 644 tcpConnectionLocalAddress tcpConnectionLocalPort 645 tcpConnectionRemAddressType tcpConnectionRemAddress 646 tcpConnectionRemPort"; 647 description 648 "A conceptual row of the tcpConnectionTable containing 649 information about a particular current TCP connection. 650 Each row of this table is transient in that it ceases to 651 exist when (or soon after) the connection makes the 652 transition to the CLOSED state."; 654 leaf tcpConnectionLocalAddressType { 655 type inet-address:InetAddressType; 656 config false; 657 description 658 "The address type of tcpConnectionLocalAddress."; 659 } 661 leaf tcpConnectionLocalAddress { 662 type inet-address:InetAddress; 663 config false; 664 description 665 "The local IP address for this TCP connection. The type 666 of this address is determined by the value of 667 tcpConnectionLocalAddressType. 669 As this object is used in the index for the 670 tcpConnectionTable, implementors should be 671 careful not to create entries that would result in OIDs 672 with more than 128 subidentifiers; otherwise the information 673 cannot be accessed by using SNMPv1, SNMPv2c, or SNMPv3."; 674 } 676 leaf tcpConnectionLocalPort { 677 type inet-address:InetPortNumber; 678 config false; 679 description 680 "The local port number for this TCP connection."; 681 } 683 leaf tcpConnectionRemAddressType { 684 type inet-address:InetAddressType; 685 config false; 686 description 687 "The address type of tcpConnectionRemAddress."; 688 } 689 leaf tcpConnectionRemAddress { 690 type inet-address:InetAddress; 691 config false; 692 description 693 "The remote IP address for this TCP connection. The type 694 of this address is determined by the value of 695 tcpConnectionRemAddressType. 697 As this object is used in the index for the 698 tcpConnectionTable, implementors should be 699 careful not to create entries that would result in OIDs 700 with more than 128 subidentifiers; otherwise the information 701 cannot be accessed by using SNMPv1, SNMPv2c, or SNMPv3."; 702 } 704 leaf tcpConnectionRemPort { 705 type inet-address:InetPortNumber; 706 config false; 707 description 708 "The remote port number for this TCP connection."; 709 } 711 leaf tcpConnectionState { 712 type enumeration { 713 enum closed { value 1; } 714 enum listen { value 2; } 715 enum synSent { value 3; } 716 enum synReceived { value 4; } 717 enum established { value 5; } 718 enum finWait1 { value 6; } 719 enum finWait2 { value 7; } 720 enum closeWait { value 8; } 721 enum lastAck { value 9; } 722 enum closing { value 10; } 723 enum timeWait { value 11; } 724 enum deleteTCB { value 12; } 725 } 726 config true; 727 description 728 "The state of this TCP connection. 730 The value listen(2) is included only for parallelism to the 731 old tcpConnTable and should not be used. A connection in 732 LISTEN state should be present in the tcpListenerTable. 734 The only value that may be set by a management station is 735 deleteTCB(12). Accordingly, it is appropriate for an agent 736 to return a `badValue' response if a management station 737 attempts to set this object to any other value. 739 If a management station sets this object to the value 740 deleteTCB(12), then the TCB (as defined in [RFC793]) of 741 the corresponding connection on the managed node is 742 deleted, resulting in immediate termination of the 743 connection. 745 As an implementation-specific option, a RST segment may be 746 sent from the managed node to the other TCP endpoint (note, 747 however, that RST segments are not sent reliably)."; 748 } 750 leaf tcpConnectionProcess { 751 type uint32; 752 config false; 753 description 754 "The system's process ID for the process associated with 755 this connection, or zero if there is no such process. This 756 value is expected to be the same as HOST-RESOURCES-MIB:: 757 hrSWRunIndex or SYSAPPL-MIB::sysApplElmtRunIndex for some 758 row in the appropriate tables."; 759 } 760 } 762 /* XXX table comments here XXX */ 764 list tcpListenerEntry { 766 key "tcpListenerLocalAddressType tcpListenerLocalAddress 767 tcpListenerLocalPort"; 768 description 769 "A conceptual row of the tcpListenerTable containing 770 information about a particular TCP listener."; 772 leaf tcpListenerLocalAddressType { 773 type inet-address:InetAddressType; 774 config false; 775 description 776 "The address type of tcpListenerLocalAddress. The value 777 should be unknown (0) if connection initiations to all 778 local IP addresses are accepted."; 779 } 781 leaf tcpListenerLocalAddress { 782 type inet-address:InetAddress; 783 config false; 784 description 785 "The local IP address for this TCP connection. 787 The value of this object can be represented in three 788 possible ways, depending on the characteristics of the 789 listening application: 791 1. For an application willing to accept both IPv4 and 792 IPv6 datagrams, the value of this object must be 793 ''h (a zero-length octet-string), with the value 794 of the corresponding tcpListenerLocalAddressType 795 object being unknown (0). 797 2. For an application willing to accept only IPv4 or 798 IPv6 datagrams, the value of this object must be 799 '0.0.0.0' or '::' respectively, with 800 tcpListenerLocalAddressType representing the 801 appropriate address type. 803 3. For an application which is listening for data 804 destined only to a specific IP address, the value 805 of this object is the specific local address, with 806 tcpListenerLocalAddressType representing the 807 appropriate address type. 809 As this object is used in the index for the 810 tcpListenerTable, implementors should be 811 careful not to create entries that would result in OIDs 812 with more than 128 subidentifiers; otherwise the information 813 cannot be accessed, using SNMPv1, SNMPv2c, or SNMPv3."; 814 } 816 leaf tcpListenerLocalPort { 817 type inet-address:InetPortNumber; 818 config false; 819 description 820 "The local port number for this TCP connection."; 821 } 823 leaf tcpListenerProcess { 824 type uint32; 825 config false; 826 description 827 "The system's process ID for the process associated with 828 this listener, or zero if there is no such process. This 829 value is expected to be the same as HOST-RESOURCES-MIB:: 830 hrSWRunIndex or SYSAPPL-MIB::sysApplElmtRunIndex for some 831 row in the appropriate tables."; 832 } 833 } 834 } 836 } /* end of module TCP-MIB */ 837 839 5. IANA Considerations 841 [[Editor's node: This section will be completed in follow-up versions 842 of this document.]] 844 6. Security Considerations 846 The YANG module specified in this document defines a schema for data 847 that is designed to be accessed via network management protocols such 848 as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 849 is the secure transport layer, and the mandatory-to-implement secure 850 transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 851 is HTTPS, and the mandatory-to-implement secure transport is TLS 852 [RFC8446]. 854 The Network Configuration Access Control Model (NACM) [RFC8341] 855 provides the means to restrict access for particular NETCONF or 856 RESTCONF users to a preconfigured subset of all available NETCONF or 857 RESTCONF protocol operations and content. 859 7. References 861 7.1. Normative References 863 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 864 RFC 793, DOI 10.17487/RFC0793, September 1981, 865 . 867 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 868 Communication Layers", STD 3, RFC 1122, 869 DOI 10.17487/RFC1122, October 1989, 870 . 872 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 873 Requirement Levels", BCP 14, RFC 2119, 874 DOI 10.17487/RFC2119, March 1997, 875 . 877 [RFC4022] Raghunarayan, R., Ed., "Management Information Base for 878 the Transmission Control Protocol (TCP)", RFC 4022, 879 DOI 10.17487/RFC4022, March 2005, 880 . 882 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 883 the Network Configuration Protocol (NETCONF)", RFC 6020, 884 DOI 10.17487/RFC6020, October 2010, 885 . 887 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 888 and A. Bierman, Ed., "Network Configuration Protocol 889 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 890 . 892 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 893 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 894 . 896 [RFC6643] Schoenwaelder, J., "Translation of Structure of Management 897 Information Version 2 (SMIv2) MIB Modules to YANG 898 Modules", RFC 6643, DOI 10.17487/RFC6643, July 2012, 899 . 901 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 902 RFC 7950, DOI 10.17487/RFC7950, August 2016, 903 . 905 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 906 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 907 . 909 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 910 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 911 May 2017, . 913 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 914 Access Control Model", STD 91, RFC 8341, 915 DOI 10.17487/RFC8341, March 2018, 916 . 918 [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., 919 and R. Wilton, "Network Management Datastore Architecture 920 (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, 921 . 923 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 924 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 925 . 927 7.2. Informative References 929 [I-D.ietf-netconf-netconf-client-server] 930 Watsen, K., "NETCONF Client and Server Models", draft- 931 ietf-netconf-netconf-client-server-07 (work in progress), 932 September 2018. 934 [I-D.ietf-netmod-acl-model] 935 Jethanandani, M., Agarwal, S., Huang, L., and D. Blair, 936 "Network Access Control List (ACL) YANG Data Model", 937 draft-ietf-netmod-acl-model-20 (work in progress), October 938 2018. 940 [I-D.ietf-opsawg-nat-yang] 941 Boucadair, M., Sivakumar, S., Jacquenet, C., Vinapamula, 942 S., and Q. Wu, "A YANG Module for Network Address 943 Translation (NAT) and Network Prefix Translation (NPT)", 944 draft-ietf-opsawg-nat-yang-17 (work in progress), 945 September 2018. 947 [LIBSMI] University of Braunschweig, "libsmi - A Library to Access 948 SMI MIB Information", 2014, 949 . 951 [RFC3873] Pastor, J. and M. Belinchon, "Stream Control Transmission 952 Protocol (SCTP) Management Information Base (MIB)", 953 RFC 3873, DOI 10.17487/RFC3873, September 2004, 954 . 956 [RFC4113] Fenner, B. and J. Flick, "Management Information Base for 957 the User Datagram Protocol (UDP)", RFC 4113, 958 DOI 10.17487/RFC4113, June 2005, 959 . 961 [RFC4898] Mathis, M., Heffner, J., and R. Raghunarayan, "TCP 962 Extended Statistics MIB", RFC 4898, DOI 10.17487/RFC4898, 963 May 2007, . 965 [RFC5482] Eggert, L. and F. Gont, "TCP User Timeout Option", 966 RFC 5482, DOI 10.17487/RFC5482, March 2009, 967 . 969 Appendix A. Acknowledgements 971 The YANG model used in version -00 of the draft has been converted 972 from [RFC4022] by the LIBSMI library [LIBSMI]. 974 Author's Address 976 Michael Scharf 977 Hochschule Esslingen - University of Applied Sciences 978 Flandernstr. 11 979 Esslingen 73732 980 Germany 982 Email: michael.scharf@hs-esslingen.de