]> Deutsche Telekom AG

CTO-ATI, Landgrabenweg 151 Bonn NRW 53227 Germany ian.farrer@telekom.de

Deutsche Telekom AG

CTO-ATI, Landgrabenweg 151 Bonn NRW 53227 Germany sunqi.ietf@gmail.com

Deutsche Telekom AG

CTO-IPT, Landgrabenweg 151 Bonn NRW 53227 Germany sladjana.zoric@telekom.de

T-Systems

mikael.abrahamsson@t-systems.se

OPS area NETMOD WG This document collects together the YANG models necessary for managing NETCONF-enabled Customer Premises Equipment (CPE) devices.

This document defines the requirements and specifies the necessary YANG models for managing residential CPE devices using NETCONF and YANG. Implementing NETCONF on CPE devices, along with the relevant YANG models, provides operators with a flexible and extensible management interface. Many of the YANG models referenced here are in various stages in the development process. In some cases there is currently no existing work. The aim of this document is to catalog which models are necessary, and for each referenced YANG model, provide information about the current status of the existing work. It is intended as a 'living document', which will be updated as the required / referenced YANG models progress. Once finalised, the goal of the document is to serve as a CPE YANG 'Device profile' that can be used as a reference for operators and implementors who are adding YANG management capabilities to their devices.

Customer Premises Equipment; provides access between a customer's LAN connected devices and their ISP's network. In the context of this document, the CPE device implements NETCONF/YANG. This document focuses on the type of residential CPE that typically exists between the Internet Service Provider access line and residential customer home, doing similar functions that for example lists. Lists YANG models defined in published RFCs. YANG models under development in active Internet Drafts, or relevant documents being produced by SDOs other than the IETF. YANG models that are identified as necessary for CPE management, but are not currently known to be in development at the time of writing.

A CPE has a number of network interfaces, usually including some of the following interface types: Ethernet LAN, Ethernet WAN, Ethernet 802.1q, Ethernet 802.1ag, and WLAN (802.11a/b/n/g/ac). defines a YANG model for general interface management, which identifies these (and other) interface types. However, Ethernet standardisation is carried out by the IEEE, so it is probable where YANG models for managing these interfaces would be developed. NB - The list of interface types necessary for a complete, general HGW model needs to include xDSL (BBF) and DOCSIS (ITU) interfaces. These will be included in a future version of this document.

The following requirements are necessary for basic CPE management functionality. The CPE YANG implementation MUST implement general interface management. The CPE YANG implementation MUST enable the configuration and management for the following interface types: Ethernet LAN Ethernet 802.1q Ethernet 802.1ag (including Ethernet CFM) Ethernet WAN WLAN (802.11a/b/n/g/ac) The CPE YANG implementation MUST provide support for optical parameter configuration for the Ethernet WAN interface YANG model.

Existing RFCs: YANG Data Model for Interface Management . IANA Interface Type YANG Module . Work In Progress: IEEE 802.1q YANG Model Common Interface Extension YANG Data Models: . Interface VLAN YANG Data Models: . To Be Defined: Ethernet WAN Ethernet 802.1ag Ethernet LAN WLAN (802.11a/b/n/g/ac)

The following requirements are necessary for the management and configuration of IPv4 and IPv6. The CPE YANG implementation MUST enable the configuration and management of IPv4 addresses and associated parameters on L3 interfaces. The CPE YANG implementation MUST enable the configuration and management of IPv6 addresses and associated parameters on L3 interfaces.

Existing RFCs: YANG Data Model for IP Management . Work In Progress: YANG Model for DiffServ: . To Be Defined: None

The following requirements are necessary for routing management. The CPE YANG implementation MUST provide support for the configuration and management of relevant IPv4/IPv6 dynamic routing protocols (for instance the ones relevant to IETF HOMENET WG). The CPE YANG implementation MUST include YANG models for the management of static IPv4/IPv6 routes. The CPE YANG implementation MUST provide support for the management of Protocol Independent Multicast (PIM). The CPE YANG implementation MUST provide support for the management of static multicast routes.

Existing RFCs: None Work In Progress: YANG Data Model for Routing Management: . YANG model for static IPv4/IPv6 route: Appendix B in . YANG Data Model for ISIS protocol: . YANG model for PIM: . YANG model for IGMP and MLD: . To Be Defined: Static Multicast Route What is the HOMENET relevant dynamic routing protocol.

The following requirements are necessary for management of the CPE's NETCONF Server. The CPE YANG implementation MUST provide support for management and configuration of its local NETCONF server using the NETCONF protocol. The CPE YANG implementation MUST provide support for the base notification function in order to allow a NETCONF client to retrieve notifications for common system events. The CPE YANG implementation MUST be able to retrieve NETCONF server configuration automatically during the bootstrap process (ZeroTouch). The CPE YANG implementation as a NETCONF server MUST provide support for the Call Home function so that a secure connection to a NETCONF client can be initiated.

Existing RFCs: YANG Module for NETCONF Monitoring: . NETCONF Base Notifications: . Work In Progress: ZeroTouch: . NETCONF Call Home: . NETCONF Server Configuration Models: . To Be Defined: None

The following requirements are necessary for management of DHCP, SLAAC and ND. The CPE YANG implementation MUST provide support for management of its DHCPv4 server, which typically runs at the IPv4 LAN side. The CPE YANG implementation MUST provide support for the management of its DHCPv6 server, which can run at the IPv6 LAN side. The CPE YANG implementation MUST provide support for the management of its DHCPv6 client, which typically runs at the IPv6 WAN side. The CPE YANG implementation MUST provide support for the management of its DHCPv6 Prefix Delegation configuration (as a requesting router). The CPE YANG implementation MUST provide support for the management of SLAAC for stateless IPv6 configuration.

Existing RFCs: None Work In Progress: YANG models for DHCPv4: . YANG Data Model for DHCPv6 Configuration: . To Be Defined: YANG model for SLAAC (Router Advertisement) YANG model for Neighbour Discovery Protocol (NDP) YANG model for DHCPv6 Prefix Delegation (requesting router) YANG model for IPCP. YANG model for IPv6CP.

The following requirements are necessary for NAT Management. The CPE YANG implementation MUST provide support for management of NAT44 configuration, as well as NAPT44 configuration.

Existing RFCs: None Work In Progress: YANG Data Model for NAT44 and stateful NAT64 function . To Be Defined: None

The following requirements are necessary for management of IPv6 Transition Mechanisms. The CPE YANG implementation must include configuration and management for 6rd . The CPE YANG implementation must include configuration and management for DS-Lite . The CPE YANG implementation must include configuration and management for Lightweight 4over6 . The CPE YANG implementation must include configuration and management for MAP-E . The CPE YANG implementation must include configuration and management for MAP-T .

Existing RFCs: None Work In Progress: YANG model for IPv4-in-IPv6 Softwire: . YANG Data Model for the DS-Lite Address Family Transition Router (AFTR): . To Be Defined: YANG model for 6rd. DHCP 4o6 client: May be combined in DHCPv6 YANG model as a feature. DNS64 Stateless NAT64 (required for MAP-T and 464xlat).

The following requirements are necessary for management of specific services which the CPE may offer. The CPE YANG implementation MUST provide support for the management of a SIP client. The CPE YANG implementation MUST provide support for the management of a the CPEs Web server (used to provide a local management interface). The CPE YANG implementation MUST provide support for the management of an NTP client and server. The CPE YANG implementation MUST provide support for the management of the SSH server.

Existing RFCs: NTP Client: Work In Progress: None To Be Defined: SIP Client Web server, used by the customer for configuring their CPE device. NTP server SSH server

The following requirements are necessary for management of security components. The CPE YANG implementation MUST provide support for the management of IPv4 firewall and ACL functions. The CPE YANG implementation MUST provide support for the management of IPv6 firewall and ACL functions.

Existing RFCs: None Work In Progress: IPv4 Firewall configuration: IPv6 Firewall configuration: Access Control List (ACL): To Be Defined: IPv4/v6 Firewall (if needed in addition to the above) Parental controls

The following requirements are necessary to perform remote CPE Software file transfer and software upgrades. The CPE implementation must provide a YANG model for the upgrade of firmware and software packages in order to fix bugs, enable new features, and resolve security issues. The CPE YANG implementation MUST enable RPCs for file transfer in order to retrieve files from an operator-managed data centre, or upload logging.

Existing RFCs: None Work In Progress: File transfer: To Be Defined: YANG model for firmware upgrade RPCs

A NETCONF/YANG managed CPE should follow the for enabling and managing IPv4/IPv6 firewalls. Security considerations from the related documents should be followed.

There are no IANA considerations for this document.

The authors would like to thank xxx for their contributions to this work.

&rfc2119; &rfc7277; &rfc7223; &rfc7224; &rfc6470; &rfc6022; &rfc7317;