idnits 2.17.1 draft-ietf-netmod-ip-cfg-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 130 has weird spacing: '...-length uin...' -- The document date (February 11, 2013) is 4091 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) == Outdated reference: A later version (-16) exists of draft-ietf-netmod-interfaces-cfg-09 == Outdated reference: A later version (-03) exists of draft-ietf-netmod-rfc6021-bis-00 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-04 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Bjorklund 3 Internet-Draft Tail-f Systems 4 Intended status: Standards Track February 11, 2013 5 Expires: August 15, 2013 7 A YANG Data Model for IP Management 8 draft-ietf-netmod-ip-cfg-09 10 Abstract 12 This document defines a YANG data model for management of IP 13 implementations. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on August 15, 2013. 32 Copyright Notice 34 Copyright (c) 2013 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 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. IP Data Model . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Relationship to IP-MIB . . . . . . . . . . . . . . . . . . . . 6 53 4. IP configuration YANG Module . . . . . . . . . . . . . . . . . 7 54 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 55 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 56 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 58 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 59 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 60 Appendix A. Example: NETCONF reply . . . . . . . . . . . . 21 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 63 1. Introduction 65 This document defines a YANG [RFC6020] data model for management of 66 IP implementations. 68 The initial version of this data model focuses on configuration 69 parameters for interfaces. Future revisions of this data model might 70 add other kinds of IP parameters. 72 Parameters to manage IP routing are defined in 73 [I-D.ietf-netmod-routing-cfg]. 75 1.1. Terminology 77 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 79 "OPTIONAL" in this document are to be interpreted as described in BCP 80 14, [RFC2119]. 82 The following terms are defined in [RFC6241] and are not redefined 83 here: 85 o client 87 o server 89 The following terms are defined in [RFC6020] and are not redefined 90 here: 92 o augment 94 o data model 96 o data node 98 2. IP Data Model 100 The module "ietf-ip" augments the "interface" list defined in the 101 "ietf-interfaces" module [I-D.ietf-netmod-interfaces-cfg] with the 102 following data nodes, where square brackets are used to enclose a 103 list's keys, and "?" means that the node is optional. Choice and 104 case nodes are enclosed in parenthesis, and a case node is marked 105 with a colon (":"). 107 +--rw if:interfaces 108 +--rw if:interface [name] 109 ... 110 +--rw ipv4? 111 | +--rw enabled? boolean 112 | +--rw forwarding? boolean 113 | +--rw mtu? uint16 114 | +--rw address [ip] 115 | | +--rw ip inet:ipv4-address-no-zone 116 | | +--rw (subnet) 117 | | +--:(prefix-length) 118 | | | +--rw ip:prefix-length? uint8 119 | | +--:(netmask) 120 | | +--rw ip:netmask? yang:dotted-quad 121 | +--rw neighbor [ip] 122 | +--rw ip inet:ipv4-address-no-zone 123 | +--rw phys-address? yang:phys-address 124 +--rw ipv6? 125 +--rw enabled? boolean 126 +--rw forwarding? boolean 127 +--rw mtu? uint32 128 +--rw address [ip] 129 | +--rw ip inet:ipv6-address-no-zone 130 | +--rw prefix-length uint8 131 +--rw neighbor [ip] 132 | +--rw ip inet:ipv6-address-no-zone 133 | +--rw phys-address? yang:phys-address 134 +--rw dup-addr-detect-transmits? uint32 135 +--rw autoconf 136 +--rw create-global-addresses? boolean 137 +--rw create-temporary-addresses? boolean 138 +--rw temporary-valid-lifetime? uint32 139 +--rw temporary-preferred-lifetime? uint32 141 The data model defines two containers, "ipv4" and "ipv6", 142 representing the IPv4 and IPv6 address families. In each container, 143 there is a leaf "enabled" that controls if the address family is 144 enabled on that interface, and a leaf "forwarding" that controls if 145 ip packet forwarding for the address family is enabled on the 146 interface. In each container, there is also a list of addresses, and 147 a list of mappings from ip addresses to physical addresses. 149 3. Relationship to IP-MIB 151 If the device implements IP-MIB [RFC4293], each entry in the "ipv4/ 152 address" and "ipv6/address" lists is mapped to one ipAddressEntry, 153 where the ipAddressIfIndex refers to the "address" entry's interface. 155 The IP-MIB defines objects to control IPv6 Router Advertisement. The 156 corresponding YANG data nodes are defined in 157 [I-D.ietf-netmod-routing-cfg]. 159 The entries in "ipv4/neighbor" and "ipv6/neighbor" are mapped to 160 ipNetToPhysicalTable. 162 The object ipAddressStatus is writable in the IP-MIB but does not 163 represent configuration, and is thus not mapped to the YANG module. 165 The following table lists the YANG data nodes with corresponding 166 objects in the IP-MIB. 168 +-----------------+-----------------------------------+ 169 | YANG data node | IP-MIB object | 170 +-----------------+-----------------------------------+ 171 | ipv4/enabled | ipv4InterfaceEnableStatus | 172 | ipv4/address | ipAddressEntry | 173 | ipv4/address/ip | ipAddressAddrType / ipAddressAddr | 174 | ipv4/neighbor | ipNetToPhysicalTable | 175 | ipv6/enabled | ipv6InterfaceEnableStatus | 176 | ipv6/forwarding | ipv6InterfaceForwarding | 177 | ipv6/address | ipAddressEntry | 178 | ipv6/address/ip | ipAddressAddrType / ipAddressAddr | 179 | ipv6/neighbor | ipNetToPhysicalTable | 180 +-----------------+-----------------------------------+ 182 Mapping of YANG data nodes to IP-MIB objects 184 4. IP configuration YANG Module 186 This module imports typedefs from [I-D.ietf-netmod-rfc6021-bis] and 187 [I-D.ietf-netmod-interfaces-cfg], and references [RFC0791], 188 [RFC0826], [RFC2460], [RFC4861], [RFC4862], and [RFC4941]. 190 RFC Ed.: update the date below with the date of RFC publication and 191 remove this note. 193 file "ietf-ip@2013-02-11.yang" 195 module ietf-ip { 197 namespace "urn:ietf:params:xml:ns:yang:ietf-ip"; 198 prefix ip; 200 import ietf-interfaces { 201 prefix if; 202 } 203 import ietf-inet-types { 204 prefix inet; 205 } 206 import ietf-yang-types { 207 prefix yang; 208 } 210 organization 211 "IETF NETMOD (NETCONF Data Modeling Language) Working Group"; 213 contact 214 "WG Web: 215 WG List: 217 WG Chair: David Kessens 218 220 WG Chair: Juergen Schoenwaelder 221 223 Editor: Martin Bjorklund 224 "; 226 description 227 "This module contains a collection of YANG definitions for 228 configuring IP implementations. 230 Copyright (c) 2012 IETF Trust and the persons identified as 231 authors of the code. All rights reserved. 233 Redistribution and use in source and binary forms, with or 234 without modification, is permitted pursuant to, and subject 235 to the license terms contained in, the Simplified BSD License 236 set forth in Section 4.c of the IETF Trust's Legal Provisions 237 Relating to IETF Documents 238 (http://trustee.ietf.org/license-info). 240 This version of this YANG module is part of RFC XXXX; see 241 the RFC itself for full legal notices."; 243 // RFC Ed.: replace XXXX with actual RFC number and remove this 244 // note. 246 // RFC Ed.: update the date below with the date of RFC publication 247 // and remove this note. 248 revision 2013-02-11 { 249 description 250 "Initial revision."; 251 reference 252 "RFC XXXX: A YANG Data Model for IP Management"; 253 } 255 /* Features */ 257 feature ipv4-non-contiguous-netmasks { 258 description 259 "Indicates support for configuring non-contiguous 260 subnet masks."; 261 } 263 feature ipv6-privacy-autoconf { 264 description 265 "Indicates support for Privacy Extensions for Stateless Address 266 Autoconfiguration in IPv6."; 267 reference 268 "RFC 4941: Privacy Extensions for Stateless Address 269 Autoconfiguration in IPv6"; 270 } 272 /* Data nodes */ 274 augment "/if:interfaces/if:interface" { 275 description 276 "Parameters for configuring IP on interfaces. 278 If an interface is not capable of running IP, the server 279 must not allow the client to configure these parameters."; 281 container ipv4 { 282 presence "Configure IPv4 on this interface."; 283 description 284 "Parameters for the IPv4 address family."; 286 leaf enabled { 287 type boolean; 288 default true; 289 description 290 "Controls if IPv4 is enabled or disabled on this 291 interface."; 292 } 293 leaf forwarding { 294 type boolean; 295 default false; 296 description 297 "Controls if IPv4 packet forwarding is enabled or disabled 298 on this interface."; 299 } 300 leaf mtu { 301 type uint16 { 302 range "68..max"; 303 } 304 units octets; 305 description 306 "The size, in octets, of the largest IPv4 packet that the 307 interface will send and receive. 309 The server may restrict the allowed values for this leaf 310 depending on the interface's type. 312 If this leaf is not configured, the operationally used mtu 313 depends on the interface's type."; 314 reference 315 "RFC 791: Internet Protocol"; 316 } 317 list address { 318 key "ip"; 319 description 320 "The list of IPv4 addresses on the interface."; 322 leaf ip { 323 type inet:ipv4-address-no-zone; 324 description 325 "The IPv4 address on the interface."; 326 } 327 choice subnet { 328 mandatory true; 329 description 330 "The subnet can be specified as a prefix-length, or, 331 if the server supports non-contiguous netmasks, as 332 a netmask."; 333 leaf prefix-length { 334 type uint8 { 335 range "0..32"; 336 } 337 description 338 "The length of the subnet prefix."; 339 } 340 leaf netmask { 341 if-feature ipv4-non-contiguous-netmasks; 342 type yang:dotted-quad; 343 description 344 "The subnet specified as a netmask."; 345 } 346 } 347 } 348 list neighbor { 349 key "ip"; 350 description 351 "A list of mappings from IPv4 352 addresses to physical addresses. 354 Entries in this list are used as static entries in the 355 ARP cache."; 356 reference 357 "RFC 826: An Ethernet Address Resolution Protocol"; 359 leaf ip { 360 type inet:ipv4-address-no-zone; 361 description 362 "The IPv4 address of a neighbor node."; 363 } 364 leaf phys-address { 365 type yang:phys-address; 366 description 367 "The physical level address of the neihgbor node."; 368 } 369 } 371 } 372 container ipv6 { 373 presence "Configure IPv6 on this interface."; 374 description 375 "Parameters for the IPv6 address family."; 377 leaf enabled { 378 type boolean; 379 default true; 380 description 381 "Controls if IPv6 is enabled or disabled on this 382 interface."; 383 } 384 leaf forwarding { 385 type boolean; 386 default false; 387 description 388 "Controls if IPv6 packet forwarding is enabled or disabled 389 on this interface."; 390 reference 391 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) 392 Section 6.2.1, IsRouter"; 393 } 394 leaf mtu { 395 type uint32 { 396 range "1280..max"; 397 } 398 units octets; 399 description 400 "The size, in octets, of the largest IPv6 packet that the 401 interface will send and receive. 403 The server may restrict the allowed values for this leaf 404 depending on the interface's type. 406 If this leaf is not configured, the operationally used mtu 407 depends on the interface's type."; 408 reference 409 "RFC 2460: IPv6 Specification 410 Section 5"; 411 } 412 list address { 413 key "ip"; 414 description 415 "The list of IPv6 addresses on the interface."; 417 leaf ip { 418 type inet:ipv6-address-no-zone; 419 description 420 "The IPv6 address on the interface."; 421 } 422 leaf prefix-length { 423 type uint8 { 424 range "0..128"; 426 } 427 mandatory true; 428 description 429 "The length of the subnet prefix."; 430 } 431 } 432 list neighbor { 433 key "ip"; 434 description 435 "A list of mappings from IPv6 436 addresses to physical addresses. 438 Entries in this list are used as static entries in the 439 Neighbor Cache."; 440 reference 441 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)"; 443 leaf ip { 444 type inet:ipv6-address-no-zone; 445 description 446 "The IPv6 address of a neighbor node."; 447 } 448 leaf phys-address { 449 type yang:phys-address; 450 description 451 "The physical level address of the neighbor node."; 452 } 453 } 454 leaf dup-addr-detect-transmits { 455 type uint32; 456 default 1; 457 description 458 "The number of consecutive Neighbor Solicitation messages 459 sent while performing Duplicate Address Detection on a 460 tentative address. A value of zero indicates that 461 Duplicate Address Detection is not performed on 462 tentative addresses. A value of one indicates a single 463 transmission with no follow-up retransmissions."; 464 reference 465 "RFC 4862: IPv6 Stateless Address Autoconfiguration"; 466 } 467 container autoconf { 468 description 469 "Parameters to control the autoconfiguration of IPv6 470 addresses, as described in RFC 4862."; 471 reference 472 "RFC 4862: IPv6 Stateless Address Autoconfiguration"; 474 leaf create-global-addresses { 475 type boolean; 476 default true; 477 description 478 "If enabled, the host creates global addresses as 479 described in section 5.5 of RFC 4862."; 480 reference 481 "RFC 4862: IPv6 Stateless Address Autoconfiguration"; 482 } 483 leaf create-temporary-addresses { 484 if-feature ipv6-privacy-autoconf; 485 type boolean; 486 default false; 487 description 488 "If enabled, the host creates temporary addresses as 489 described in RFC 4941."; 490 reference 491 "RFC 4941: Privacy Extensions for Stateless Address 492 Autoconfiguration in IPv6"; 493 } 494 leaf temporary-valid-lifetime { 495 if-feature ipv6-privacy-autoconf; 496 type uint32; 497 units "seconds"; 498 default 604800; 499 description 500 "The time period during which the temporary address 501 is valid."; 502 reference 503 "RFC 4941: Privacy Extensions for Stateless Address 504 Autoconfiguration in IPv6 505 - TEMP_VALID_LIFETIME"; 506 } 507 leaf temporary-preferred-lifetime { 508 if-feature ipv6-privacy-autoconf; 509 type uint32; 510 units "seconds"; 511 default 86400; 512 description 513 "The time period during which the temporary address is 514 preferred."; 515 reference 516 "RFC 4941: Privacy Extensions for Stateless Address 517 Autoconfiguration in IPv6 518 - TEMP_PREFERED_LIFETIME"; 519 } 520 } 521 } 523 } 524 } 526 528 5. IANA Considerations 530 This document registers a URI in the IETF XML registry [RFC3688]. 531 Following the format in RFC 3688, the following registration is 532 requested to be made. 534 URI: urn:ietf:params:xml:ns:yang:ietf-ip 536 Registrant Contact: The NETMOD WG of the IETF. 538 XML: N/A, the requested URI is an XML namespace. 540 This document registers a YANG module in the YANG Module Names 541 registry [RFC6020]. 543 name: ietf-ip 544 namespace: urn:ietf:params:xml:ns:yang:ietf-ip 545 prefix: ip 546 reference: RFC XXXX 548 6. Security Considerations 550 The YANG module defined in this memo is designed to be accessed via 551 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 552 secure transport layer and the mandatory-to-implement secure 553 transport is SSH [RFC6242]. 555 There are a number of data nodes defined in the YANG module which are 556 writable/creatable/deletable (i.e., config true, which is the 557 default). These data nodes may be considered sensitive or vulnerable 558 in some network environments. Write operations (e.g., edit-config) 559 to these data nodes without proper protection can have a negative 560 effect on network operations. These are the subtrees and data nodes 561 and their sensitivity/vulnerability: 563 ipv4/enabled and ipv6/enabled: These leafs are used to enable or 564 disable IPv4 and IPv6 on a specific interface. By enabling a 565 protocol on an interface, an attacker might be able to create an 566 unsecured path into a node (or through it if routing is also 567 enabled). By disabling a protocol on an interface, an attacker 568 might be able to force packets to be routed through some other 569 interface or deny access to some or all of the network via that 570 protocol. 572 ipv4/address and ipv6/address: These lists specify the configured IP 573 addresses on an interface. By modifying this information, an 574 attacker can cause a node to either ignore messages destined to it 575 or accept (at least at the IP layer) messages it would otherwise 576 ignore. The use of filtering or security associations may reduce 577 the potential damage in the latter case. 579 ipv4/forwarding and ipv6/forwarding: These leafs allow a client to 580 enable or disable the forwarding functions on the entity. By 581 disabling the forwarding functions, an attacker would possibly be 582 able to deny service to users. By enabling the forwarding 583 functions, an attacker could open a conduit into an area. This 584 might result in the area providing transit for packets it 585 shouldn't or might allow the attacker access to the area bypassing 586 security safeguards. 588 ipv6/autoconf: The leafs in this branch control the 589 autoconfiguration of IPv6 addresses and in particular whether 590 temporary addresses are used or not. By modifying the 591 corresponding leafs, an attacker might impact the addresses used 592 by a node and thus indirectly the privacy of the users using the 593 node. 595 ipv4/mtu and ipv6/mtu: Setting these leafs to very small values can 596 be used to slow down interfaces. 598 7. Acknowledgments 600 The author wishes to thank Ladislav Lhotka, Juergen Schoenwaelder, 601 and Dave Thaler for their helpful comments. 603 8. References 605 8.1. Normative References 607 [I-D.ietf-netmod-interfaces-cfg] 608 Bjorklund, M., "A YANG Data Model for Interface 609 Configuration", draft-ietf-netmod-interfaces-cfg-09 (work 610 in progress), July 2012. 612 [I-D.ietf-netmod-rfc6021-bis] 613 Schoenwaelder, J., "Common YANG Data Types", 614 draft-ietf-netmod-rfc6021-bis-00 (work in progress), 615 Feb 2013. 617 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 618 September 1981. 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, March 1997. 623 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 624 (IPv6) Specification", RFC 2460, December 1998. 626 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 627 January 2004. 629 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 630 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 631 September 2007. 633 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 634 Address Autoconfiguration", RFC 4862, September 2007. 636 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 637 Extensions for Stateless Address Autoconfiguration in 638 IPv6", RFC 4941, September 2007. 640 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 641 Network Configuration Protocol (NETCONF)", RFC 6020, 642 October 2010. 644 8.2. Informative References 646 [I-D.ietf-netmod-routing-cfg] 647 Lhotka, L., "A YANG Data Model for Routing Configuration", 648 draft-ietf-netmod-routing-cfg-04 (work in progress), 649 July 2012. 651 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 652 converting network protocol addresses to 48.bit Ethernet 653 address for transmission on Ethernet hardware", STD 37, 654 RFC 826, November 1982. 656 [RFC4293] Routhier, S., "Management Information Base for the 657 Internet Protocol (IP)", RFC 4293, April 2006. 659 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 660 Bierman, "Network Configuration Protocol (NETCONF)", 661 RFC 6241, June 2011. 663 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 664 Shell (SSH)", RFC 6242, June 2011. 666 Appendix A. Example: NETCONF reply 668 This section gives an example of a reply to the NETCONF request 669 for a device that implements the data model defined in this document. 671 674 675 677 678 eth0 679 ethernetCsmacd 680 0 681 2 682 683
684 192.0.2.1 685 24 686
687 688 689 1280 690
691 2001:DB8::1 692 32 693
694 0 695 696 697 698 699 701 Author's Address 703 Martin Bjorklund 704 Tail-f Systems 706 Email: mbj@tail-f.com