idnits 2.17.1 draft-ietf-netmod-ip-cfg-07.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 -- The document date (November 15, 2012) is 4180 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-05 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 4941 (Obsoleted by RFC 8981) ** Obsolete normative reference: RFC 6021 (Obsoleted by RFC 6991) == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-04 Summary: 3 errors (**), 0 flaws (~~), 3 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 November 15, 2012 5 Expires: May 19, 2013 7 A YANG Data Model for IP Management 8 draft-ietf-netmod-ip-cfg-07 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 May 19, 2013. 32 Copyright Notice 34 Copyright (c) 2012 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 116 | | +--rw (subnet)? 117 | | +--:(prefix-length) 118 | | | +--rw ip:prefix-length? uint8 119 | | +--:(netmask) 120 | | +--rw ip:netmask? inet:ipv4-address 121 | +--rw neighbor [ip] 122 | +--rw ip inet:ipv4-address 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 130 | +--rw prefix-length? uint8 131 +--rw neighbor [ip] 132 | +--rw ip inet:ipv6-address 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 [RFC6021] 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@2012-11-15.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 2012-11-15 { 249 description 250 "Initial revision."; 251 reference 252 "RFC XXXX: A YANG Data Model for IP Configuration"; 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; 324 description 325 "The IPv4 address on the interface."; 326 } 327 choice subnet { 328 default prefix-length; 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. 334 The default subnet is a prefix-length of 32."; 335 leaf prefix-length { 336 type uint8 { 337 range "0..32"; 338 } 339 default 32; 340 description 341 "The length of the subnet prefix."; 342 } 343 leaf netmask { 344 if-feature ipv4-non-contiguous-netmasks; 345 type inet:ipv4-address; 346 description 347 "The subnet specified as a netmask."; 348 } 349 } 350 } 351 list neighbor { 352 key "ip"; 353 description 354 "A list of mappings from IPv4 355 addresses to physical addresses. 357 Entries in this list are used as static entries in the 358 ARP cache."; 359 reference 360 "RFC 826: An Ethernet Address Resolution Protocol"; 362 leaf ip { 363 type inet:ipv4-address; 364 description 365 "The IPv4 address of a neighbor node."; 366 } 367 leaf phys-address { 368 type yang:phys-address; 369 description 370 "The physical level address of the neihgbor node."; 371 } 372 } 374 } 375 container ipv6 { 376 presence "Configure IPv6 on this interface."; 377 description 378 "Parameters for the IPv6 address family."; 380 leaf enabled { 381 type boolean; 382 default true; 383 description 384 "Controls if IPv6 is enabled or disabled on this 385 interface."; 386 } 387 leaf forwarding { 388 type boolean; 389 default false; 390 description 391 "Controls if IPv6 packet forwarding is enabled or disabled 392 on this interface."; 393 reference 394 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6) 395 Section 6.2.1, IsRouter"; 396 } 397 leaf mtu { 398 type uint32 { 399 range "1280..max"; 400 } 401 units octets; 402 description 403 "The size, in octets, of the largest IPv6 packet that the 404 interface will send and receive. 406 The server may restrict the allowed values for this leaf 407 depending on the interface's type. 409 If this leaf is not configured, the operationally used mtu 410 depends on the interface's type."; 411 reference 412 "RFC 2460: IPv6 Specification 413 Section 5"; 414 } 415 list address { 416 key "ip"; 417 description 418 "The list of IPv6 addresses on the interface."; 420 leaf ip { 421 type inet:ipv6-address; 422 description 423 "The IPv6 address on the interface."; 424 } 425 leaf prefix-length { 426 type uint8 { 427 range "0..128"; 428 } 429 default 128; 430 description 431 "The length of the subnet prefix."; 432 } 433 } 434 list neighbor { 435 key "ip"; 436 description 437 "A list of mappings from IPv6 438 addresses to physical addresses. 440 Entries in this list are used as static entries in the 441 Neighbor Cache."; 442 reference 443 "RFC 4861: Neighbor Discovery for IP version 6 (IPv6)"; 445 leaf ip { 446 type inet:ipv6-address; 447 description 448 "The IPv6 address of a neighbor node."; 449 } 450 leaf phys-address { 451 type yang:phys-address; 452 description 453 "The physical level address of the neighbor node."; 454 } 455 } 456 leaf dup-addr-detect-transmits { 457 type uint32; 458 default 1; 459 description 460 "The number of consecutive Neighbor Solicitation messages 461 sent while performing Duplicate Address Detection on a 462 tentative address. A value of zero indicates that 463 Duplicate Address Detection is not performed on 464 tentative addresses. A value of one indicates a single 465 transmission with no follow-up retransmissions."; 466 reference 467 "RFC 4862: IPv6 Stateless Address Autoconfiguration"; 468 } 469 container autoconf { 470 description 471 "Parameters to control the autoconfiguration of IPv6 472 addresses, as described in RFC 4862."; 474 reference 475 "RFC 4862: IPv6 Stateless Address Autoconfiguration"; 477 leaf create-global-addresses { 478 type boolean; 479 default true; 480 description 481 "If enabled, the host creates global addresses as 482 described in section 5.5 of RFC 4862."; 483 reference 484 "RFC 4862: IPv6 Stateless Address Autoconfiguration"; 485 } 486 leaf create-temporary-addresses { 487 if-feature ipv6-privacy-autoconf; 488 type boolean; 489 default false; 490 description 491 "If enabled, the host creates temporary addresses as 492 described in RFC 4941."; 493 reference 494 "RFC 4941: Privacy Extensions for Stateless Address 495 Autoconfiguration in IPv6"; 496 } 497 leaf temporary-valid-lifetime { 498 if-feature ipv6-privacy-autoconf; 499 type uint32; 500 units "seconds"; 501 default 604800; 502 description 503 "The time period during which the temporary address 504 is valid."; 505 reference 506 "RFC 4941: Privacy Extensions for Stateless Address 507 Autoconfiguration in IPv6 508 - TEMP_VALID_LIFETIME"; 509 } 510 leaf temporary-preferred-lifetime { 511 if-feature ipv6-privacy-autoconf; 512 type uint32; 513 units "seconds"; 514 default 86400; 515 description 516 "The time period during which the temporary address is 517 preferred."; 518 reference 519 "RFC 4941: Privacy Extensions for Stateless Address 520 Autoconfiguration in IPv6 521 - TEMP_PREFERED_LIFETIME"; 523 } 524 } 525 } 526 } 527 } 529 531 5. IANA Considerations 533 This document registers a URI in the IETF XML registry [RFC3688]. 534 Following the format in RFC 3688, the following registration is 535 requested to be made. 537 URI: urn:ietf:params:xml:ns:yang:ietf-ip 539 Registrant Contact: The NETMOD WG of the IETF. 541 XML: N/A, the requested URI is an XML namespace. 543 This document registers a YANG module in the YANG Module Names 544 registry [RFC6020]. 546 name: ietf-ip 547 namespace: urn:ietf:params:xml:ns:yang:ietf-ip 548 prefix: ip 549 reference: RFC XXXX 551 6. Security Considerations 553 The YANG module defined in this memo is designed to be accessed via 554 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 555 secure transport layer and the mandatory-to-implement secure 556 transport is SSH [RFC6242]. 558 There are a number of data nodes defined in the YANG module which are 559 writable/creatable/deletable (i.e., config true, which is the 560 default). These data nodes may be considered sensitive or vulnerable 561 in some network environments. Write operations (e.g., edit-config) 562 to these data nodes without proper protection can have a negative 563 effect on network operations. These are the subtrees and data nodes 564 and their sensitivity/vulnerability: 566 ipv4/enabled and ipv6/enabled: These leafs are used to enable or 567 disable IPv4 and IPv6 on a specific interface. By enabling a 568 protocol on an interface, an attacker might be able to create an 569 unsecured path into a node (or through it if routing is also 570 enabled). By disabling a protocol on an interface, an attacker 571 might be able to force packets to be routed through some other 572 interface or deny access to some or all of the network via that 573 protocol. 575 ipv4/address and ipv6/address: These lists specify the configured IP 576 addresses on an interface. By modifying this information, an 577 attacker can cause a node to either ignore messages destined to it 578 or accept (at least at the IP layer) messages it would otherwise 579 ignore. The use of filtering or security associations may reduce 580 the potential damage in the latter case. 582 ipv4/forwarding and ipv6/forwarding: These leafs allow a client to 583 enable or disable the forwarding functions on the entity. By 584 disabling the forwarding functions, an attacker would possibly be 585 able to deny service to users. By enabling the forwarding 586 functions, an attacker could open a conduit into an area. This 587 might result in the area providing transit for packets it 588 shouldn't or might allow the attacker access to the area bypassing 589 security safeguards. 591 ipv6/autoconf: The leafs in this branch control the 592 autoconfiguration of IPv6 addresses and in particular whether 593 temporary addresses are used or not. By modifying the 594 corresponding leafs, an attacker might impact the addresses used 595 by a node and thus indirectly the privacy of the users using the 596 node. 598 ipv4/mtu and ipv6/mtu: Setting these leafs to very small values can 599 be used to slow down interfaces. 601 7. Acknowledgments 603 The author wishes to thank Ladislav Lhotka, Juergen Schoenwaelder, 604 and Dave Thaler for their helpful comments. 606 8. References 608 8.1. Normative References 610 [I-D.ietf-netmod-interfaces-cfg] 611 Bjorklund, M., "A YANG Data Model for Interface 612 Configuration", draft-ietf-netmod-interfaces-cfg-05 (work 613 in progress), July 2012. 615 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 616 September 1981. 618 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 619 Requirement Levels", BCP 14, RFC 2119, March 1997. 621 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 622 (IPv6) Specification", RFC 2460, December 1998. 624 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 625 January 2004. 627 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 628 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 629 September 2007. 631 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 632 Address Autoconfiguration", RFC 4862, September 2007. 634 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 635 Extensions for Stateless Address Autoconfiguration in 636 IPv6", RFC 4941, September 2007. 638 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 639 Network Configuration Protocol (NETCONF)", RFC 6020, 640 October 2010. 642 [RFC6021] Schoenwaelder, J., "Common YANG Data Types", RFC 6021, 643 October 2010. 645 8.2. Informative References 647 [I-D.ietf-netmod-routing-cfg] 648 Lhotka, L., "A YANG Data Model for Routing Configuration", 649 draft-ietf-netmod-routing-cfg-04 (work in progress), 650 July 2012. 652 [RFC0826] Plummer, D., "Ethernet Address Resolution Protocol: Or 653 converting network protocol addresses to 48.bit Ethernet 654 address for transmission on Ethernet hardware", STD 37, 655 RFC 826, November 1982. 657 [RFC4293] Routhier, S., "Management Information Base for the 658 Internet Protocol (IP)", RFC 4293, April 2006. 660 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 661 Bierman, "Network Configuration Protocol (NETCONF)", 662 RFC 6241, June 2011. 664 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 665 Shell (SSH)", RFC 6242, June 2011. 667 Appendix A. Example: NETCONF reply 669 This section gives an example of a reply to the NETCONF request 670 for a device that implements the data model defined in this document. 672 675 676 678 679 eth0 680 ethernetCsmacd 681 0 682 2 683 684
685 192.0.2.1 686 24 687
688 689 690 1280 691
692 2001:DB8::1 693 32 694
695 0 696 697 698 699 700 702 Author's Address 704 Martin Bjorklund 705 Tail-f Systems 707 Email: mbj@tail-f.com