idnits 2.17.1 draft-faq-netmod-cpe-yang-profile-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 16, 2015) is 3114 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.perrault-behave-natv2-mib' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 607, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-boucadair-softwire-dslite-yang-02 == Outdated reference: A later version (-42) exists of draft-ietf-isis-yang-isis-cfg-06 == Outdated reference: A later version (-17) exists of draft-ietf-netconf-call-home-11 == Outdated reference: A later version (-09) exists of draft-ietf-netconf-server-model-08 == Outdated reference: A later version (-29) exists of draft-ietf-netconf-zerotouch-03 == Outdated reference: A later version (-21) exists of draft-ietf-netmod-acl-model-03 == Outdated reference: A later version (-25) exists of draft-ietf-netmod-routing-cfg-19 == Outdated reference: A later version (-07) exists of draft-liu-dhc-dhcp-yang-model-01 == Outdated reference: A later version (-02) exists of draft-mcallister-pim-yang-00 == Outdated reference: A later version (-07) exists of draft-sivakumar-yang-nat-03 == Outdated reference: A later version (-05) exists of draft-sun-softwire-yang-04 == Outdated reference: A later version (-01) exists of draft-wilton-netmod-intf-ext-yang-00 == Outdated reference: A later version (-04) exists of draft-wilton-netmod-intf-vlan-yang-00 ** Obsolete normative reference: RFC 7223 (Obsoleted by RFC 8343) ** Obsolete normative reference: RFC 7277 (Obsoleted by RFC 8344) Summary: 2 errors (**), 0 flaws (~~), 17 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETMOD WG I. Farrer 3 Internet-Draft Q. Sun 4 Intended status: Informational S. Zoric 5 Expires: April 18, 2016 Deutsche Telekom AG 6 M. Abrahamsson 7 T-Systems 8 October 16, 2015 10 YANG Models Required for Managing Customer Premises Equipment (CPE) 11 Devices 12 draft-faq-netmod-cpe-yang-profile-00 14 Abstract 16 This document collects together the YANG models necessary for 17 managing NETCONF-enabled Customer Premises Equipment (CPE) devices. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 18, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Management Requirements . . . . . . . . . . . . . . . . . . . 3 56 3.1. Interfaces . . . . . . . . . . . . . . . . . . . . . . . 3 57 3.1.1. Requirements . . . . . . . . . . . . . . . . . . . . 4 58 3.1.2. Development Status of Relevant YANG Models . . . . . 4 59 3.2. IP Management . . . . . . . . . . . . . . . . . . . . . . 5 60 3.2.1. Requirements . . . . . . . . . . . . . . . . . . . . 5 61 3.2.2. Development of Relevant YANG Models . . . . . . . . . 5 62 3.3. Routing and Multicast Management . . . . . . . . . . . . 5 63 3.3.1. Requirements . . . . . . . . . . . . . . . . . . . . 5 64 3.3.2. Development of Relevant YANG Models . . . . . . . . . 6 65 3.4. CPE NETCONF Server Management . . . . . . . . . . . . . . 6 66 3.4.1. Requirements . . . . . . . . . . . . . . . . . . . . 6 67 3.4.2. Development Status of Relevant YANG Models . . . . . 6 68 3.5. DHCP/SLAAC/ND Management . . . . . . . . . . . . . . . . 7 69 3.5.1. Requirements . . . . . . . . . . . . . . . . . . . . 7 70 3.5.2. Development Status of Relevant YANG Models . . . . . 7 71 3.6. NAT Management . . . . . . . . . . . . . . . . . . . . . 8 72 3.6.1. Requirements . . . . . . . . . . . . . . . . . . . . 8 73 3.6.2. Development Status of Relevant YANG Models . . . . . 8 74 3.7. IPv6 Transition Mechanisms Management . . . . . . . . . . 8 75 3.7.1. Requirements . . . . . . . . . . . . . . . . . . . . 8 76 3.7.2. Development of Relevant YANG Models . . . . . . . . . 9 77 3.8. Management of Specific Services . . . . . . . . . . . . . 9 78 3.8.1. Requirements . . . . . . . . . . . . . . . . . . . . 9 79 3.8.2. Development of Relevant YANG Models . . . . . . . . . 9 80 3.9. Management of Security Components . . . . . . . . . . . . 10 81 3.9.1. Requirements . . . . . . . . . . . . . . . . . . . . 10 82 3.9.2. Development of Relevant YANG Models . . . . . . . . . 10 83 3.10. Remote CPE Software Upgrade . . . . . . . . . . . . . . . 10 84 3.10.1. Requirements . . . . . . . . . . . . . . . . . . . . 10 85 3.10.2. Development of Relevant YANG Models . . . . . . . . 11 86 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 87 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 88 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 89 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 90 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 91 7.2. Informative References . . . . . . . . . . . . . . . . . 14 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 94 1. Introduction 96 This document defines the requirements and specifies the necessary 97 YANG models for managing residential CPE devices using NETCONF and 98 YANG. Implementing NETCONF on CPE devices, along with the relevant 99 YANG models, provides operators with a flexible and extensible 100 management interface. 102 Many of the YANG models referenced here are in various stages in the 103 development process. In some cases there is currently no existing 104 work. The aim of this document is to catalog which models are 105 necessary, and for each referenced YANG model, provide information 106 about the current status of the existing work. It is intended as a 107 'living document', which will be updated as the required / referenced 108 YANG models progress. Once finalised, the goal of the document is to 109 serve as a CPE YANG 'Device profile' that can be used as a reference 110 for operators and implementors who are adding YANG management 111 capabilities to their devices. 113 2. Terminology 115 CPE Customer Premises Equipment; provides access 116 between a customer's LAN connected devices and 117 their ISP's network. In the context of this 118 document, the CPE device implements NETCONF/YANG. 119 This document focuses on the type of residential 120 CPE that typically exists between the Internet 121 Service Provider access line and residential 122 customer home, doing similar functions that for 123 example [RFC7084] lists. 124 Existing RFCs Lists YANG models defined in published RFCs. 125 Work In Progress YANG models under development in active Internet 126 Drafts, or relevant documents being produced by 127 SDOs other than the IETF. 128 To Be Defined YANG models that are identified as necessary for 129 CPE management, but are not currently known to be 130 in development at the time of writing. 132 3. Management Requirements 134 3.1. Interfaces 136 A CPE has a number of network interfaces, usually including some of 137 the following interface types: Ethernet LAN, Ethernet WAN, Ethernet 138 802.1q, Ethernet 802.1ag, and WLAN (802.11a/b/n/g/ac). [RFC7223] 139 defines a YANG model for general interface management, which 140 identifies these (and other) interface types. However, Ethernet 141 standardisation is carried out by the IEEE, so it is probable where 142 YANG models for managing these interfaces would be developed. 144 NB - The list of interface types necessary for a complete, general 145 HGW model needs to include xDSL (BBF) and DOCSIS (ITU) interfaces. 146 These will be included in a future version of this document. 148 3.1.1. Requirements 150 The following requirements are necessary for basic CPE management 151 functionality. 153 INT-1: The CPE YANG implementation MUST implement general interface 154 management. 155 INT-2: The CPE YANG implementation MUST enable the configuration and 156 management for the following interface types: 157 o Ethernet LAN 158 o Ethernet 802.1q 159 o Ethernet 802.1ag (including Ethernet CFM) 160 o Ethernet WAN 161 o WLAN (802.11a/b/n/g/ac) 162 INT-3: The CPE YANG implementation MUST provide support for optical 163 parameter configuration for the Ethernet WAN interface YANG 164 model. 166 3.1.2. Development Status of Relevant YANG Models 168 Existing RFCs: 170 o YANG Data Model for Interface Management [RFC7223]. 171 o IANA Interface Type YANG Module [RFC7224]. 173 Work In Progress: 175 o IEEE 802.1q YANG Model [IEEE-ETH-YANG] 176 o Common Interface Extension YANG Data Models: 177 [I-D.wilton-netmod-intf-ext-yang]. 178 o Interface VLAN YANG Data Models: 179 [I-D.wilton-netmod-intf-vlan-yang]. 181 To Be Defined: 183 o Ethernet WAN 184 o Ethernet 802.1ag 185 o Ethernet LAN 186 o WLAN (802.11a/b/n/g/ac) 188 3.2. IP Management 190 3.2.1. Requirements 192 The following requirements are necessary for the management and 193 configuration of IPv4 and IPv6. 195 IP-1: The CPE YANG implementation MUST enable the configuration and 196 management of IPv4 addresses and associated parameters on L3 197 interfaces. 198 IP-2: The CPE YANG implementation MUST enable the configuration and 199 management of IPv6 addresses and associated parameters on L3 200 interfaces. 202 3.2.2. Development of Relevant YANG Models 204 Existing RFCs: 206 o YANG Data Model for IP Management [RFC7277]. 208 Work In Progress: 210 o YANG Model for DiffServ: [I-D.asechoud-netmod-diffserv-model]. 212 To Be Defined: 214 o None 216 3.3. Routing and Multicast Management 218 3.3.1. Requirements 220 The following requirements are necessary for routing management. 222 ROUT-1: The CPE YANG implementation MUST provide support for the 223 configuration and management of relevant IPv4/IPv6 dynamic 224 routing protocols (for instance the ones relevant to IETF 225 HOMENET WG). 226 ROUT-2: The CPE YANG implementation MUST include YANG models for the 227 management of static IPv4/IPv6 routes. 228 ROUT-3: The CPE YANG implementation MUST provide support for the 229 management of Protocol Independent Multicast (PIM). 230 ROUT-4: The CPE YANG implementation MUST provide support for the 231 management of static multicast routes. 233 3.3.2. Development of Relevant YANG Models 235 Existing RFCs: 237 o None 239 Work In Progress: 241 o YANG Data Model for Routing Management: 242 [I-D.ietf-netmod-routing-cfg]. 243 o YANG model for static IPv4/IPv6 route: Appendix B in 244 [I-D.ietf-netmod-routing-cfg]. 245 o YANG Data Model for ISIS protocol: [I-D.ietf-isis-yang-isis-cfg]. 246 o YANG model for PIM: [I-D.mcallister-pim-yang]. 247 o YANG model for IGMP and MLD: [I-D.liu-pim-igmp-mld-yang]. 249 To Be Defined: 251 o Static Multicast Route 252 o What is the HOMENET relevant dynamic routing protocol. 254 3.4. CPE NETCONF Server Management 256 3.4.1. Requirements 258 The following requirements are necessary for management of the CPE's 259 NETCONF Server. 261 NETCONF-1: The CPE YANG implementation MUST provide support for 262 management and configuration of its local NETCONF server 263 using the NETCONF protocol. 264 NETCONF-2: The CPE YANG implementation MUST provide support for the 265 base notification function in order to allow a NETCONF 266 client to retrieve notifications for common system 267 events. 268 NETCONF-3: The CPE YANG implementation MUST be able to retrieve 269 NETCONF server configuration automatically during the 270 bootstrap process (ZeroTouch). 271 NETCONF-4: The CPE YANG implementation as a NETCONF server MUST 272 provide support for the Call Home function so that a 273 secure connection to a NETCONF client can be initiated. 275 3.4.2. Development Status of Relevant YANG Models 277 Existing RFCs: 279 o YANG Module for NETCONF Monitoring: [RFC6022]. 280 o NETCONF Base Notifications: [RFC6470]. 282 Work In Progress: 284 o ZeroTouch: [I-D.ietf-netconf-zerotouch]. 285 o NETCONF Call Home: [I-D.ietf-netconf-call-home]. 286 o NETCONF Server Configuration Models: 287 [I-D.ietf-netconf-server-model]. 289 To Be Defined: 291 o None 293 3.5. DHCP/SLAAC/ND Management 295 3.5.1. Requirements 297 The following requirements are necessary for management of DHCP, 298 SLAAC and ND. 300 V6CONF-1: The CPE YANG implementation MUST provide support for 301 management of its DHCPv4 server, which typically runs at 302 the IPv4 LAN side. 303 V6CONF-2: The CPE YANG implementation MUST provide support for the 304 management of its DHCPv6 server, which can run at the IPv6 305 LAN side. 306 V6CONF-3: The CPE YANG implementation MUST provide support for the 307 management of its DHCPv6 client, which typically runs at 308 the IPv6 WAN side. 309 V6CONF-4: The CPE YANG implementation MUST provide support for the 310 management of its DHCPv6 Prefix Delegation configuration 311 (as a requesting router). 312 V6CONF-5: The CPE YANG implementation MUST provide support for the 313 management of SLAAC for stateless IPv6 configuration. 315 3.5.2. Development Status of Relevant YANG Models 317 Existing RFCs: 319 o None 321 Work In Progress: 323 o YANG models for DHCPv4: [I-D.liu-dhc-dhcp-yang-model]. 324 o YANG Data Model for DHCPv6 Configuration: 325 [I-D.cui-dhc-dhcpv6-yang]. 327 To Be Defined: 329 o YANG model for SLAAC (Router Advertisement) 330 o YANG model for Neighbour Discovery Protocol (NDP) 331 o YANG model for DHCPv6 Prefix Delegation (requesting router) 332 o YANG model for IPCP. 333 o YANG model for IPv6CP. 335 3.6. NAT Management 337 3.6.1. Requirements 339 The following requirements are necessary for NAT Management. 341 NAT-1: The CPE YANG implementation MUST provide support for 342 management of NAT44 configuration, as well as NAPT44 343 configuration. 345 3.6.2. Development Status of Relevant YANG Models 347 Existing RFCs: 349 o None 351 Work In Progress: 353 o YANG Data Model for NAT44 and stateful NAT64 function 354 [I-D.sivakumar-yang-nat]. 356 To Be Defined: 358 o None 360 3.7. IPv6 Transition Mechanisms Management 362 3.7.1. Requirements 364 The following requirements are necessary for management of IPv6 365 Transition Mechanisms. 367 TRAN-2: The CPE YANG implementation must include configuration and 368 management for 6rd [RFC5969]. 369 TRAN-2: The CPE YANG implementation must include configuration and 370 management for DS-Lite [RFC6333]. 371 TRAN-3: The CPE YANG implementation must include configuration and 372 management for Lightweight 4over6 [RFC7596]. 373 TRAN-4: The CPE YANG implementation must include configuration and 374 management for MAP-E [RFC7597]. 375 TRAN-5: The CPE YANG implementation must include configuration and 376 management for MAP-T [RFC7599]. 378 3.7.2. Development of Relevant YANG Models 380 Existing RFCs: 382 o None 384 Work In Progress: 386 o YANG model for IPv4-in-IPv6 Softwire: [I-D.sun-softwire-yang]. 387 o YANG Data Model for the DS-Lite Address Family Transition Router 388 (AFTR): [I-D.boucadair-softwire-dslite-yang]. 390 To Be Defined: 392 o YANG model for 6rd. 393 o DHCP 4o6 client: May be combined in DHCPv6 YANG model as a 394 feature. 395 o DNS64 396 o Stateless NAT64 (required for MAP-T and 464xlat). 398 3.8. Management of Specific Services 400 3.8.1. Requirements 402 The following requirements are necessary for management of specific 403 services which the CPE may offer. 405 SERVICE-1: The CPE YANG implementation MUST provide support for the 406 management of a SIP client. 407 SERVICE-2: The CPE YANG implementation MUST provide support for the 408 management of a the CPEs Web server (used to provide a 409 local management interface). 410 SERVICE-3: The CPE YANG implementation MUST provide support for the 411 management of an NTP client and server. 412 SERVICE-4: The CPE YANG implementation MUST provide support for the 413 management of the SSH server. 415 3.8.2. Development of Relevant YANG Models 417 Existing RFCs: 419 o NTP Client: [RFC7317] 421 Work In Progress: 423 o None 425 To Be Defined: 427 o SIP Client 428 o Web server, used by the customer for configuring their CPE device. 429 o NTP server 430 o SSH server 432 3.9. Management of Security Components 434 3.9.1. Requirements 436 The following requirements are necessary for management of security 437 components. 439 SEC-1: The CPE YANG implementation MUST provide support for the 440 management of IPv4 firewall and ACL functions. 441 SEC-1: The CPE YANG implementation MUST provide support for the 442 management of IPv6 firewall and ACL functions. 444 3.9.2. Development of Relevant YANG Models 446 Existing RFCs: 448 o None 450 Work In Progress: 452 o IPv4 Firewall configuration: [I-D.ietf-netmod-acl-model] 453 o IPv6 Firewall configuration: [I-D.ietf-netmod-acl-model] 454 o Access Control List (ACL): [I-D.ietf-netmod-acl-model] 456 To Be Defined: 458 o IPv4/v6 Firewall (if needed in addition to the above) 459 o Parental controls 461 3.10. Remote CPE Software Upgrade 463 3.10.1. Requirements 465 The following requirements are necessary to perform remote CPE 466 Software file transfer and software upgrades. 468 SWUPG-1: The CPE implementation must provide a YANG model for the 469 upgrade of firmware and software packages in order to fix 470 bugs, enable new features, and resolve security issues. 471 SWUPG-2: The CPE YANG implementation MUST enable RPCs for file 472 transfer in order to retrieve files from an operator- 473 managed data centre, or upload logging. 475 3.10.2. Development of Relevant YANG Models 477 Existing RFCs: 479 o None 481 Work In Progress: 483 o File transfer: [I-D.sf-netmod-file-transfer-yang] 485 To Be Defined: 487 o YANG model for firmware upgrade RPCs 489 4. Security Considerations 491 A NETCONF/YANG managed CPE should follow the Section 3.9 for enabling 492 and managing IPv4/IPv6 firewalls. Security considerations from the 493 related documents should be followed. 495 5. IANA Considerations 497 There are no IANA considerations for this document. 499 6. Acknowledgements 501 The authors would like to thank xxx for their contributions to this 502 work. 504 7. References 506 7.1. Normative References 508 [I-D.asechoud-netmod-diffserv-model] 509 Choudhary, A., Shah, S., Jethanandani, M., Liu, B., and N. 510 Strahle, "YANG Model for Diffserv", draft-asechoud-netmod- 511 diffserv-model-03 (work in progress), June 2015. 513 [I-D.boucadair-softwire-dslite-yang] 514 Boucadair, M., Jacquenet, C., and S. Sivakumar, "YANG Data 515 Model for the DS-Lite Address Family Transition Router 516 (AFTR)", draft-boucadair-softwire-dslite-yang-02 (work in 517 progress), September 2015. 519 [I-D.cui-dhc-dhcpv6-yang] 520 Cui, Y., Wang, H., Sun, L., Lemon, T., and I. Farrer, 521 "YANG Data Model for DHCPv6 Configuration", draft-cui-dhc- 522 dhcpv6-yang-04 (work in progress), September 2015. 524 [I-D.ietf-isis-yang-isis-cfg] 525 Litkowski, S., Yeung, D., Lindem, A., Zhang, J., and L. 526 Lhotka, "YANG Data Model for ISIS protocol", draft-ietf- 527 isis-yang-isis-cfg-06 (work in progress), September 2015. 529 [I-D.ietf-netconf-call-home] 530 Watsen, K., "NETCONF Call Home and RESTCONF Call Home", 531 draft-ietf-netconf-call-home-11 (work in progress), 532 September 2015. 534 [I-D.ietf-netconf-server-model] 535 Watsen, K. and J. Schoenwaelder, "NETCONF Server and 536 RESTCONF Server Configuration Models", draft-ietf-netconf- 537 server-model-08 (work in progress), October 2015. 539 [I-D.ietf-netconf-zerotouch] 540 Watsen, K., Clarke, J., and M. Abrahamsson, "Zero Touch 541 Provisioning for NETCONF Call Home (ZeroTouch)", draft- 542 ietf-netconf-zerotouch-03 (work in progress), July 2015. 544 [I-D.ietf-netmod-acl-model] 545 Bogdanovic, D., Sreenivasa, K., Huang, L., and D. Blair, 546 "Network Access Control List (ACL) YANG Data Model", 547 draft-ietf-netmod-acl-model-03 (work in progress), June 548 2015. 550 [I-D.ietf-netmod-routing-cfg] 551 Lhotka, L. and A. Lindem, "A YANG Data Model for Routing 552 Management", draft-ietf-netmod-routing-cfg-19 (work in 553 progress), May 2015. 555 [I-D.liu-dhc-dhcp-yang-model] 556 Liu, B. and K. Lou, "A YANG Data Model for DHCP 557 Configuration", draft-liu-dhc-dhcp-yang-model-01 (work in 558 progress), July 2015. 560 [I-D.liu-pim-igmp-mld-yang] 561 Liu, Y. and F. Guo, "Yang Model for Internet Group 562 Management Protocol (IGMP) and Multicast Listener 563 Discovery (MLD)", draft-liu-pim-igmp-mld-yang-01 (work in 564 progress), March 2015. 566 [I-D.mcallister-pim-yang] 567 Liu, X., McAllister, P., and A. Peter, "A YANG data model 568 for Protocol-Independent Multicast (PIM)", draft- 569 mcallister-pim-yang-00 (work in progress), July 2015. 571 [I-D.perrault-behave-natv2-mib] 572 Perreault, S., Tsou, T., Sivakumar, S., and T. Taylor, 573 "Definitions of Managed Objects for Network Address 574 Translators (NAT)", draft-perrault-behave-natv2-mib-05 575 (work in progress), June 2015. 577 [I-D.sf-netmod-file-transfer-yang] 578 Sun, Q. and I. Farrer, "A YANG Data Model for Transferring 579 Files", draft-sf-netmod-file-transfer-yang-00 (work in 580 progress), March 2015. 582 [I-D.sivakumar-yang-nat] 583 Sivakumar, S., Boucadair, M., and S. <>, "YANG Data Model 584 for Network Address Translation (NAT)", draft-sivakumar- 585 yang-nat-03 (work in progress), September 2015. 587 [I-D.sun-softwire-yang] 588 Sun, Q., Wang, H., Cui, Y., Farrer, I., Boucadair, M., and 589 R. Asati, "YANG Data Model for IPv4-in-IPv6 Softwire", 590 draft-sun-softwire-yang-04 (work in progress), October 591 2015. 593 [I-D.wilton-netmod-intf-ext-yang] 594 Wilton, R., Ball, D., Singh, T., and S. Sivaraj, "Common 595 Interface Extension YANG Data Models", draft-wilton- 596 netmod-intf-ext-yang-00 (work in progress), July 2015. 598 [I-D.wilton-netmod-intf-vlan-yang] 599 Wilton, R., Ball, D., Singh, T., and S. Sivaraj, 600 "Interface VLAN YANG Data Models", draft-wilton-netmod- 601 intf-vlan-yang-00 (work in progress), July 2015. 603 [IEEE-ETH-YANG] 604 "IEEE 802.1q YANG Model", 605 . 607 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 608 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 609 RFC2119, March 1997, 610 . 612 [RFC6022] Scott, M. and M. Bjorklund, "YANG Module for NETCONF 613 Monitoring", RFC 6022, DOI 10.17487/RFC6022, October 2010, 614 . 616 [RFC6470] Bierman, A., "Network Configuration Protocol (NETCONF) 617 Base Notifications", RFC 6470, DOI 10.17487/RFC6470, 618 February 2012, . 620 [RFC7223] Bjorklund, M., "A YANG Data Model for Interface 621 Management", RFC 7223, DOI 10.17487/RFC7223, May 2014, 622 . 624 [RFC7224] Bjorklund, M., "IANA Interface Type YANG Module", RFC 625 7224, DOI 10.17487/RFC7224, May 2014, 626 . 628 [RFC7277] Bjorklund, M., "A YANG Data Model for IP Management", RFC 629 7277, DOI 10.17487/RFC7277, June 2014, 630 . 632 [RFC7317] Bierman, A. and M. Bjorklund, "A YANG Data Model for 633 System Management", RFC 7317, DOI 10.17487/RFC7317, August 634 2014, . 636 7.2. Informative References 638 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 639 Infrastructures (6rd) -- Protocol Specification", RFC 640 5969, DOI 10.17487/RFC5969, August 2010, 641 . 643 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 644 Stack Lite Broadband Deployments Following IPv4 645 Exhaustion", RFC 6333, DOI 10.17487/RFC6333, August 2011, 646 . 648 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 649 Requirements for IPv6 Customer Edge Routers", RFC 7084, 650 DOI 10.17487/RFC7084, November 2013, 651 . 653 [RFC7596] Cui, Y., Sun, Q., Boucadair, M., Tsou, T., Lee, Y., and I. 654 Farrer, "Lightweight 4over6: An Extension to the Dual- 655 Stack Lite Architecture", RFC 7596, DOI 10.17487/RFC7596, 656 July 2015, . 658 [RFC7597] Troan, O., Ed., Dec, W., Li, X., Bao, C., Matsushima, S., 659 Murakami, T., and T. Taylor, Ed., "Mapping of Address and 660 Port with Encapsulation (MAP-E)", RFC 7597, DOI 10.17487/ 661 RFC7597, July 2015, 662 . 664 [RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., 665 and T. Murakami, "Mapping of Address and Port using 666 Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 667 2015, . 669 Authors' Addresses 671 Ian Farrer 672 Deutsche Telekom AG 673 CTO-ATI, Landgrabenweg 151 674 Bonn, NRW 53227 675 Germany 677 Email: ian.farrer@telekom.de 679 Qi Sun 680 Deutsche Telekom AG 681 CTO-ATI, Landgrabenweg 151 682 Bonn, NRW 53227 683 Germany 685 Email: sunqi.ietf@gmail.com 687 Sladjana Zoric 688 Deutsche Telekom AG 689 CTO-IPT, Landgrabenweg 151 690 Bonn, NRW 53227 691 Germany 693 Email: sladjana.zoric@telekom.de 695 Mikael Abrahamsson 696 T-Systems 698 Email: mikael.abrahamsson@t-systems.se