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