idnits 2.17.1 draft-ietf-l2tpext-keyed-v6-tunnel-yang-02.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 179 has weird spacing: '...ieValue uin...' -- The document date (October 28, 2016) is 2736 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 6536 (Obsoleted by RFC 8341) ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 l2tpext Working Group Q. Sun 3 Internet-Draft I. Farrer 4 Intended status: Standards Track Deutsche Telekom AG 5 Expires: May 1, 2017 B. Liu 6 Huawei Technologies 7 G. Heron 8 Cisco Systems 9 October 28, 2016 11 A YANG Data Model for Keyed IPv6 Tunnels 12 draft-ietf-l2tpext-keyed-v6-tunnel-yang-02 14 Abstract 16 This document defines a YANG data model for the configuration and 17 management of Keyed IPv6 tunnels. The data model includes both 18 configuration and state data. Due to the stateless nature of keyed 19 IPv6 tunnels, a model for NETCONF notifications is not necessary. 21 Requirements Language 23 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 24 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 25 document are to be interpreted as described in [RFC2119]. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 1, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1.1. Requirements Notations . . . . . . . . . . . . . . . 3 64 1.1.2. NETCONF Terms . . . . . . . . . . . . . . . . . . . . 3 65 1.1.3. YANG Terms . . . . . . . . . . . . . . . . . . . . . 3 66 1.1.4. Tree Diagrams . . . . . . . . . . . . . . . . . . . . 3 67 2. YANG Model Overview . . . . . . . . . . . . . . . . . . . . . 4 68 3. Keyed IPv6 Tunnel YANG Tree Diagrams . . . . . . . . . . . . 4 69 4. Keyed IPv6 Tunnel YANG Model . . . . . . . . . . . . . . . . 6 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 72 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 74 8.1. Normative References . . . . . . . . . . . . . . . . . . 13 75 8.2. Informative References . . . . . . . . . . . . . . . . . 14 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 Keyed IPv6 Tunnels [I-D.ietf-l2tpext-keyed-ipv6-tunnel] defines a 81 mechanism for transporting L2 Ethernet frames over IPv6 using L2TPv3 82 tunnel encapsulation with a mandatory 64-bit cookie. It is a static 83 layer 2 tunnelling mechanism that leverages IPv6's vast number of IP 84 addresses to uniquely identify each tunnel, instead of using the 85 L2TPv3 Session ID as the differentiator (as defined in [RFC3931]). 86 The layer 2 circuit is mapped to an IPv6 address on the network side 87 so typically, there is one session per-tunnel. 89 Since the L2TPv3 control plane is not used by Keyed IPv6 tunnels, the 90 parameters for building a Keyed IPv6 tunnel need to be pre-configured 91 on the two tunnel endpoint devices. NETCONF [RFC6241]/YANG [RFC6020] 92 provide mechanisms for such configuration. This document defines a 93 YANG data model for the configuration and management of Keyed IPv6 94 Tunnels. 96 1.1. Terminology 98 1.1.1. Requirements Notations 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 1.1.2. NETCONF Terms 106 The following terms are defined in [RFC6241] and are not redefined 107 here: 109 o Client 110 o Server 111 o Operation 113 1.1.3. YANG Terms 115 The following terms are defined in [RFC6020] and are not redefined 116 here: 118 o configuration data 119 o data node 120 o data tree 121 o module 122 o namespace 123 o YANG 125 1.1.4. Tree Diagrams 127 A simplified graphical representation of the data model is provided 128 in this document. The meaning of the symbols in these diagrams is as 129 follows: 131 o Brackets "[" and "]" enclose list keys. 132 o Abbreviations before data node names: "rw" means configuration 133 data (read-write), and "ro" means state data (read-only). 134 o Symbols after data node names: "?" means an optional node, "!" 135 means a presence container, and "*" denotes a list and leaf-list. 136 o Parentheses enclose choice and case nodes, and case nodes are also 137 marked with a colon (":"). 138 o Ellipsis ("...") stands for the contents of subtrees that are not 139 shown. 141 2. YANG Model Overview 143 The YANG model comprises of two modules, one for configuration and 144 one for state. To correctly identify a tunnel and create the mapping 145 between the L2 circuit and the IPv6 address, the tuple of source 146 interface, local IPv6 address and remote IPv6 address MUST be unique. 147 Because Session ID is not mandatory for a Keyed IPv6 tunnel to 148 function, Session ID related parameters are optional in the model. 149 Cookies MUST be 64-bit long according to Section 3 of 150 [I-D.ietf-l2tpext-keyed-ipv6-tunnel]. The requirement for 64-bit 151 cookie constrains interoperability with existing RFC3931 152 implementations to those configured with a 64-bit cookie. 154 The data model also includes read-only counters so that statistics 155 for sent and received octets and packets, received packets with 156 errors, and packets that could not be sent due to errors can be read. 158 This model defines three features for OAM parameters. Those features 159 enable devices to perform related OAM operations on the tunnel if 160 related functions are supported. 162 3. Keyed IPv6 Tunnel YANG Tree Diagrams 164 This section describes the tree diagram for the Keyed IPv6 Tunnel 165 YANG model: 167 module: ietf-keyed-v6-tunnel 168 +--rw tunnelConfigurations 169 | +--rw tunnelConfiguration* [tunnelName] 170 | | +--rw tunnelName string 171 | | +--rw srcInterface if:interface-ref 172 | | +--rw localIPv6 inet:ipv6-address 173 | | +--rw remoteIPv6 inet:ipv6-address 174 | | +--rw localSessionId? uint32 175 | | +--rw remoteSessionId? uint32 176 | | +--rw localCookies 177 | | | +--rw localCookie* [cookieName] 178 | | | +--rw cookieName string 179 | | | +--rw cookieValue uint64 180 | | +--rw remoteCookie uint64 181 | | +--rw retainFCS? empty 182 | | +--rw enable-vccv! 183 | | | +--rw enable-bfd? empty 184 | | +--rw enable-bfd? empty 185 | +--rw disable-pmtu? empty 186 | +--rw enable-fragmentation! 187 | | +--rw fragment-mru? uint16 188 | +--rw enable-sequencing empty 189 +--ro tunnelStates 190 +--ro tunnelState* [tunnelName] 191 +--ro tunnelName string 192 +--ro sentPacket? yang:zero-based-counter64 193 +--ro sentByte? yang:zero-based-counter64 194 +--ro rcvdPacket? yang:zero-based-counter64 195 +--ro rcvdByte? yang:zero-based-counter64 196 +--ro droppedPacket? yang:zero-based-counter64 197 +--ro droppedByte? yang:zero-based-counter64 198 +--ro fragmentCounter? yang:zero-based-counter64 200 Figure 1: Keyed IPv6 Tunnel Tree 202 The data model defines a configuration container and a state 203 container. 205 In the configuration container, "srcInterface" is used to identify a 206 L2 circuit endpoint. "localIPv6" and "remoteIPv6" respectively hold 207 the local (source) and remote (destination) IPv6 addresses for the 208 tunnel. The tuple of srcInterface and localIPv6 uniquely identify a 209 tunnel endpoint. If a virtual interface is used, the tuple of 210 localIPv6 and remoteIPv6 MUST also be unique. "localCookie" is a 211 list containing two cookies: one is the newly configured cookie, and 212 the other is previously configured. This is used for the purpose of 213 correctly receiving packets while changing cookies. 215 Nodes are defined for FCS-Retention, VCCV, BFD, VCCV-BFD and 216 fragmentation, so that devices supporting all or some of these 217 features can be configured. 219 4. Keyed IPv6 Tunnel YANG Model 221 This module imports typedefs from [RFC6991] and [RFC7223]. 223 file "ietf-keyed-v6-tunnel@2016-03-21.yang" 224 module ietf-keyed-v6-tunnel { 225 yang-version 1.1; 226 namespace "urn:ietf:params:xml:ns:yang:ietf-keyed-v6-tunnel"; 227 prefix k6tun; 229 import ietf-interfaces { 230 prefix if; 231 } 232 import ietf-inet-types { 233 prefix inet; 234 } 235 import ietf-yang-types { 236 prefix yang; 237 } 239 organization "IETF l2tpext Working Group"; 241 contact 242 "qui.sun@external.telekom.de 243 ian.farrer@telekom.de 244 leo.liubing@huawei.com 245 giheron@cisco.com 246 "; 248 description 249 "Keyed IPv6 L2TPv3 Tunnel"; 251 revision 2016-03-21 { 252 description 253 "Added sequencing feature"; 254 reference 255 "draft-ietf-l2tpext-keyed-v6-tunnel-yang-01"; 256 } 258 revision 2015-07-06 { 259 description 260 "General clean-up" 261 ; 262 reference 263 "draft-sun-l2tpext-keyed-v6-tunnel-yang-01"; 264 } 266 revision 2015-03-09 { 267 description 268 "Initial version. 269 "; 270 reference 271 "draft-sun-l2tpext-keyed-v6-tunnel-yang-00"; 272 } 274 /* 275 * features 276 */ 277 feature FCS-Retention { 278 description 279 "Device supports the retention of frame check sequence (FCS) 280 as per Section 4.7 of RFC4720"; 281 } 282 feature VCCV { 283 description 284 "Device supports the Pseudowire Virtual Circuit Connectivity 285 Verification (VCCV) as per RFC5085"; 286 } 287 feature BFD { 288 description 289 "Device supports BFD over the tunnel as per RFC5883"; 290 } 291 feature VCCV-BFD { 292 description 293 "Device supports BFD over VCCV as per RFC5885"; 294 } 295 feature l2tpv3-fragmentation { 296 description 297 "Device supports L2TPv3 fragmentation as per RFC4623"; 298 } 299 feature l2tpv3-sequencing { 300 description 301 "Device supports frame sequencing as per section 4.6.1 of 302 RFC3931"; 303 } 305 /* 306 * typedefs 307 */ 309 /* 310 * groupings 311 */ 313 /* 314 * config parameters 315 */ 316 container tunnelConfigurations { 317 list tunnelConfiguration { 318 key "tunnelName"; 319 unique "srcInterface remoteIPv6"; 320 unique "localIPv6 remoteIPv6"; 321 leaf tunnelName { 322 type string; 323 description "name for this keyed tunnel"; 324 } 325 leaf srcInterface { 326 type if:interface-ref; 327 mandatory true; 328 description 329 "Source interface that identifies the L2 circuit 330 endpoint."; 331 } 332 leaf localIPv6 { 333 type inet:ipv6-address; 334 mandatory true; 335 description "IPv6 address for local end of keyed tunnel"; 336 } 337 leaf remoteIPv6 { 338 type inet:ipv6-address; 339 mandatory true; 340 description "IPv6 address for remote end of keyed tunnel"; 341 } 342 leaf localSessionId { 343 type uint32; 344 default 0xFFFFFFFF; 345 description 346 "As the IPv6 address is used to determine the tunnel 347 and there is a single session per tunnel, the Session ID 348 can be ignored upon receipt. For compatibility with 349 other tunnel termination platforms supporting two-stage 350 resolution (IPv6 address + Session ID), the Session ID 351 is configured with a random value other than all zeros. 352 If both ends support one-stage (IPv6 address), then 353 the Session ID is recommended to be set to all ones."; 354 } 355 leaf remoteSessionId { 356 type uint32; 357 default 0xFFFFFFFF; 358 description 359 "Since IPv6 address is used to determine the tunnel 360 and there is one session per tunnel, the Session ID 361 can be ignored upon receipt. For compatibility with 362 other tunnel termination platforms supporting two-stage 363 resolution (IPv6 address + Session ID) the Session ID 364 is configured with a random value other than all zeros. 365 If both ends support one-stage (IPv6 address), then 366 the Session ID is recommended to be set to all ones."; 367 } 368 container localCookies { 369 list localCookie { 370 key "cookieName"; 371 leaf cookieName { 372 type string; 373 description "name identifying this cookie"; 374 } 375 min-elements 2; 376 max-elements 2; 377 leaf cookieValue { 378 type uint64; 379 mandatory true; 380 description "value of this cookie"; 381 } 382 description 383 "List of local cookies - must contain two entries at 384 all times to enable lossless cookie rollover"; 385 } 386 description 387 "The length of cookie MUST be 64-bit. It MUST be 388 possible to change the cookie value at any time 389 in a manner that does not drop any legitimate 390 tunneled packets - i.e. the receiver 391 must accept a received cookie matching either 392 value during a change of cookie value."; 393 } 394 leaf remoteCookie { 395 type uint64; 396 mandatory true; 397 description 398 "The length of cookie MUST be 64-bit. A single 399 remote cookie is used for sending packets."; 400 } 401 leaf retainFCS { 402 if-feature FCS-Retention; 403 type empty; 404 description 405 "If this parameter is present, the router is configued 406 to retain FCS. Any such router MUST retain the FCS 407 for all frames sent over that tunnel. 408 "; 409 } 410 container enable-vccv { 411 if-feature VCCV; 412 presence "Enable VCCV [RFC5085]"; 413 leaf enable-bfd { 414 if-feature VCCV-BFD; 415 type empty; 416 description "Enable VCCV-BFD [RFC5885]."; 417 } 418 description "Enable VCCV [RFC5085]"; 419 } 420 leaf enable-bfd { 421 if-feature BFD; 422 type empty; 423 description 424 "Enable BFD over the tunnel [RFC5883]."; 425 } 426 leaf disable-pmtu { 427 type empty; 428 description "Disable IPv6 PMTU discovery [RFC1981]"; 429 } 430 container enable-fragmentation { 431 if-feature l2tpv3-fragmentation; 432 presence "Enable L2TPv3 fragmentation [RFC4623]"; 433 leaf fragment-mru { 434 type uint16; 435 description "Explicit override for fragmentation MRU"; 436 } 437 description 438 "Default is to fragment to PMTU (or 1500 if PMTU is 439 disabled) minus 52 octets for the encapsulation 440 overhead"; 441 } 442 leaf enable-sequencing { 443 if-feature l2tpv3-sequencing; 444 type empty; 445 description 446 "Enable L2TPv3 sequencing [RFC3931 section 4.6.1]"; 447 } 448 description 449 "keyed-v6-tunnel typically supports one l2tpv3 session 450 per tunnel. The srcInterface and localIPv6 both uniquely 451 identify a tunnel endpoint. If a virtual interface 452 is used, the localIPv6 and remoteIPv6 as a pair MUST 453 also be unique. 454 "; 456 } 457 description 458 "container for list of keyed-v6-tunnel entries"; 459 } 460 container tunnelStates { 461 config false; 462 list tunnelState { 463 key "tunnelName"; 464 leaf tunnelName { 465 type string; 466 description "name of this keyed tunnel"; 467 } 468 leaf sentPacket { 469 type yang:zero-based-counter64; 470 description 471 "counter for the number of packets sent over tunnel"; 472 } 473 leaf sentByte { 474 type yang:zero-based-counter64; 475 description 476 "counter for total sent bytes (of inner packets)"; 477 } 478 leaf rcvdPacket { 479 type yang:zero-based-counter64; 480 description 481 "counter for number of valid packets received from 482 tunnel"; 483 } 484 leaf rcvdByte { 485 type yang:zero-based-counter64; 486 description 487 "counter for total received bytes (of inner packets)"; 488 } 489 leaf droppedPacket { 490 type yang:zero-based-counter64; 491 description 492 "Counter for number of dropped packets matching this 493 tunnel (e.g. due to invalid received cookie, 494 insufficient resources to process)."; 495 } 496 leaf droppedByte { 497 type yang:zero-based-counter64; 498 description 499 "Counter for total dropped bytes (of inner packets)"; 500 } 501 leaf fragmentCounter { 502 type yang:zero-based-counter64; 503 description 504 "Counter for number of received fragments"; 505 } 506 description "per-tunnel statistics"; 507 } 508 description "container for list of tunnel statistics"; 509 } 510 } 511 513 5. Security Considerations 515 The YANG module defined in this memo is designed to be accessed via 516 the NETCONF protocol [RFC6241]. The lowest NETCONF layer is the 517 secure transport layer and the mandatory to implement secure 518 transport is SSH [RFC6242]. The NETCONF access control model 519 [RFC6536] provides the means to restrict access for particular 520 NETCONF users to a pre-configured subset of all available NETCONF 521 protocol operations and content. 523 There are a number of data nodes defined in this YANG module which 524 are writable/creatable/deletable (i.e. config true, which is the 525 default). These data nodes may be considered sensitive or vulnerable 526 in some network environments. Write operations (e.g. edit-config) to 527 these data nodes without proper protection can have a negative effect 528 on network operations. These are the subtrees and data nodes and 529 their sensitivity/vulnerability: 531 /tunnelConfigurations/tunnelConfiguration: Could allow traffic to be 532 redirected, (man-in-the-middle attack) or mis-configured (denial-of- 533 service attack). 535 Some of the readable data nodes in this YANG module may be considered 536 sensitive or vulnerable in some network environments. It is thus 537 important to control read access (e.g. via get, get-config or 538 notification) to these data nodes. These are the subtrees and data 539 nodes and their sensitivity/vulnerability: 541 /tunnelConfigurations/tunnelConfiguration: Could allow an attacker to 542 inject spoofed traffic into the network. 544 /tunnelStates/tunnelState: Could allow an attacker to get 545 unauthorized access to tunnel usage information. 547 6. IANA Considerations 549 This document registers the following YANG modules in the "YANG 550 Module Names" registry [RFC6020]. 552 name: ietf-keyed-v6-tunnel 553 namespace: urn:ietf:params:xml:ns:yang:ietf-keyed-v6-tunnel 554 prefix: k6tun 555 reference: TBD 557 7. Acknowledgements 559 The authors would like to thank Haoxing Shen for his valuable 560 comments. 562 8. References 564 8.1. Normative References 566 [I-D.ietf-l2tpext-keyed-ipv6-tunnel] 567 Konstantynowicz, M., Heron, G., Schatzmayr, R., and W. 568 Henderickx, "Keyed IPv6 Tunnel", draft-ietf-l2tpext-keyed- 569 ipv6-tunnel-07 (work in progress), October 2016. 571 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 572 Requirement Levels", BCP 14, RFC 2119, 573 DOI 10.17487/RFC2119, March 1997, 574 . 576 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 577 the Network Configuration Protocol (NETCONF)", RFC 6020, 578 DOI 10.17487/RFC6020, October 2010, 579 . 581 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 582 and A. Bierman, Ed., "Network Configuration Protocol 583 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 584 . 586 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 587 Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011, 588 . 590 [RFC6536] Bierman, A. and M. Bjorklund, "Network Configuration 591 Protocol (NETCONF) Access Control Model", RFC 6536, 592 DOI 10.17487/RFC6536, March 2012, 593 . 595 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 596 RFC 6991, DOI 10.17487/RFC6991, July 2013, 597 . 599 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 600 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 601 . 603 8.2. Informative References 605 [RFC3931] Lau, J., Ed., Townsley, M., Ed., and I. Goyret, Ed., 606 "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", 607 RFC 3931, DOI 10.17487/RFC3931, March 2005, 608 . 610 Authors' Addresses 612 Qi Sun 613 Deutsche Telekom AG 614 CTO-ATI,Landgrabenweg 151 615 Bonn, NRW 53227 616 Germany 618 Email: qui.sun@external.telekom.de 620 Ian Farrer 621 Deutsche Telekom AG 622 CTO-ATI,Landgrabenweg 151 623 Bonn, NRW 53227 624 Germany 626 Email: ian.farrer@telekom.de 628 Bing Liu 629 Huawei Technologies 630 Q14, Huawei Campus, No.156 Beiqing Road 631 Beijing, Hai-Dian District 100095 632 P.R. China 634 Email: leo.liubing@huawei.com 636 Giles Heron 637 Cisco Systems 638 9-11 New Square, Bedfont Lakes 639 Feltham, Middlesex TW14 8HA 640 United Kingdom 642 Email: giheron@cisco.com