]> 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-ATI, 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 set of YANG models necessary for managing NETCONF-enabled Residential Gateway (RG) devices.

This document defines the requirements and specifies the necessary YANG models for managing RG devices using NETCONF and YANG . Implementing NETCONF on RG 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 RG YANG 'Device profile' that can be used as a reference for operators and implementors who are adding YANG management capabilities to their devices.

Residential Gateway; provides access between a customer's LAN connected devices and their ISP's network. In the context of this document, the RG device implements NETCONF/YANG. This document focuses on the type of Residential Gateway that typically exists between the Internet Service Provider access line and residential customer home, performing functions such as those described in . 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 RG management, but are not currently known to be in development at the time of writing.

The following requirements are necessary for basic RG hardware management.

The RG YANG implementation MUST provide a model for the management of hardware.

Existing RFCs: None Work In Progress: A YANG Data Model for Hardware Management: To Be Defined (and SDOs that might be responsible for the standards) None

A RG 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. 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 RG interface management functionality. The RG YANG implementation MUST implement general interface management. The RG YANG implementation MUST enable the configuration and management (incl operational information) 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 RG YANG implementation MUST provide support for optical parameter configuration for the Ethernet WAN interface YANG model. The RG YANG implementation MUST provide a model for the management of hardware.

Existing RFCs: YANG Data Model for Interface Management . IANA Interface Type YANG Module . Work In Progress: IEEE 802.1q YANG Model Interface VLAN YANG Data Models: . Common Interface Extension YANG Data Models: YANG Model for the PPP Protocol: A YANG Data Model for Hardware Management: To Be Defined (and SDOs that might be responsible for the standards) Ethernet WAN (IEEE/BBF) Ethernet 802.1ag (IEEE) Ethernet LAN (IEEE/BBF) WLAN (802.11a/b/n/g/ac) (IEEE/WFA/BBF)

The following requirements are necessary for the management and configuration of IPv4 and IPv6. The RG YANG implementation MUST enable the configuration and management of IPv4 addresses and associated parameters on L3 interfaces. The RG YANG implementation MUST enable the configuration and management of IPv6 addresses and associated parameters on L3 interfaces. The RG YANG implementation MUST allow for the configuration of differentiated services related parameters on its 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 RG 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 RG YANG implementation MUST include YANG models for the management of static IPv4/IPv6 routes. The RG YANG implementation MUST provide support for the management of Protocol Independent Multicast (PIM). The RG 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(s).

The following requirements are necessary for management of the RG's NETCONF Server. The RG YANG implementation MUST provide support for management and configuration of its local NETCONF server using the NETCONF protocol. The RG 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 RG YANG implementation MUST be able to retrieve NETCONF server configuration automatically during the bootstrap process (ZeroTouch). The RG 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 RG YANG implementation MUST provide support for management of its DHCPv4 server, which typically runs at the IPv4 LAN side. The RG YANG implementation MUST provide support for the management of its DHCPv6 server, which can run at the IPv6 LAN side. The RG YANG implementation MUST provide support for the management of its DHCPv6 client, which typically runs at the IPv6 WAN side. The RG YANG implementation MUST provide support for the management of its DHCPv6 Prefix Delegation configuration (as a requesting router). The RG YANG implementation MUST provide support for the management of SLAAC for stateless IPv6 configuration (as router on its LAN interfaces).

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

The following requirements are necessary for NAT Management. The RG 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 RG YANG implementation must include configuration and management for 6rd . The RG YANG implementation must include configuration and management for DS-Lite . The RG YANG implementation must include configuration and management for Lightweight 4over6 . The RG YANG implementation must include configuration and management for MAP-E . The RG 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. (IETF) DHCP 4o6 client: May be combined in DHCPv6 YANG model as a feature. (IETF) DNS64. (IETF) Stateless NAT64 (required for MAP-T and 464xlat). (IETF)

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

Existing RFCs: NTP Client: Work In Progress: None To Be Defined: SIP/VoIP Client. (IETF) Web server, used by the customer for configuring their RG. (?) NTP server. (IETF) SSH server. (IETF)

The following requirements are necessary for management of security components. The RG YANG implementation MUST provide support for the management of IPv4 firewall and ACL functions. The RG 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) (IETF?) Parental controls (?)

The following requirements are necessary to perform remote RG Software file transfer and software upgrades. The RG 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 RG 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. (BBF?)

A NETCONF/YANG managed RG 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; &rfc6470; &rfc6020; &rfc6022; &rfc6241; &rfc7277; &rfc7223; &rfc7224; &rfc7317; &rfc7659; &rfc8022; &rfc8071;