draft-ietf-anima-stable-connectivity-05.txt   draft-ietf-anima-stable-connectivity-06.txt 
ANIMA T. Eckert, Ed. ANIMA T. Eckert, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational M. Behringer Intended status: Informational M. Behringer
Expires: February 3, 2018 August 2, 2017 Expires: March 21, 2018 September 17, 2017
Using Autonomic Control Plane for Stable Connectivity of Network OAM Using Autonomic Control Plane for Stable Connectivity of Network OAM
draft-ietf-anima-stable-connectivity-05 draft-ietf-anima-stable-connectivity-06
Abstract Abstract
OAM (Operations, Administration and Maintenance - as per BCP161, OAM (Operations, Administration and Maintenance - as per BCP161,
[RFC6291]) processes for data networks are often subject to the [RFC6291]) processes for data networks are often subject to the
problem of circular dependencies when relying on connectivity problem of circular dependencies when relying on connectivity
provided by the network to be managed for the OAM purposes. provided by the network to be managed for the OAM purposes.
Provisioning while bringing up devices and networks tends to be more Provisioning while bringing up devices and networks tends to be more
difficult to automate than service provisioning later on, changes in difficult to automate than service provisioning later on, changes in
skipping to change at page 1, line 38 skipping to change at page 1, line 38
connectivity is not subject to aforementioned circular dependencies. connectivity is not subject to aforementioned circular dependencies.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 3, 2018. This Internet-Draft will expire on March 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
skipping to change at page 17, line 13 skipping to change at page 17, line 13
for this, so these ULA prefixes must not be used. for this, so these ULA prefixes must not be used.
According to RFC4193 section 4.4, PTR records for ULA addresses According to RFC4193 section 4.4, PTR records for ULA addresses
should not be installed into the global DNS (no guaranteed should not be installed into the global DNS (no guaranteed
ownership). Hence also the need to rely on voluntary lists (and in ownership). Hence also the need to rely on voluntary lists (and in
prior paragraph) to make the use of an ULA prefix globally known. prior paragraph) to make the use of an ULA prefix globally known.
Nevertheless, some legacy OAM applications running across the ACP may Nevertheless, some legacy OAM applications running across the ACP may
rely on reverse DNS lookup for authentication of requests (eg: TFTP rely on reverse DNS lookup for authentication of requests (eg: TFTP
for download of network firmware/config/software). Operators may for download of network firmware/config/software). Operators may
therefore use split horizon DNS to provide global PTR records for therefore need to use a private DNS setup for the ACP ULA addresses.
their own ULA prefixes only into their own domain to continue relying This is the same setup that would be necessary for using RFC1918
on this method. Given the security of the ACP, this may even addresses in DNS. See for example [RFC1918] section 5, last
increase the security of such legacy methods. paragraph. In [RFC6950] section 4, these setups are discussed in
more detail.
Any current and future protocols must rely on secure end-to-end Any current and future protocols must rely on secure end-to-end
communications (TLS/DTLS) and identification and authentication via communications (TLS/DTLS) and identification and authentication via
the certificates assigned to both ends. This is enabled by the the certificates assigned to both ends. This is enabled by the
certificate mechanisms of the ACP. certificate mechanisms of the ACP.
If DNS and especially reverse DNS are set up, then it should be set If DNS and especially reverse DNS are set up, then it should be set
up in an automated fashion, linked to the autonomic registrar backend up in an automated fashion, linked to the autonomic registrar backend
so that the DNS and reverse DNS records are actually derived from the so that the DNS and reverse DNS records are actually derived from the
subject name elements of the ACP device certificates in the same way subject name elements of the ACP device certificates in the same way
skipping to change at page 18, line 7 skipping to change at page 18, line 7
the design and early testing. Many people contributed to the aspects the design and early testing. Many people contributed to the aspects
described in this document, including in alphabetical order: BL described in this document, including in alphabetical order: BL
Balaji, Steinthor Bjarnason, Yves Herthoghs, Sebastian Meissner, Ravi Balaji, Steinthor Bjarnason, Yves Herthoghs, Sebastian Meissner, Ravi
Kumar Vadapalli. The author would also like to thank Michael Kumar Vadapalli. The author would also like to thank Michael
Richardson, James Woodyatt and Brian Carpenter for their review and Richardson, James Woodyatt and Brian Carpenter for their review and
comments. Special thanks to Sheng Jiang and Mohamed Boucadair for comments. Special thanks to Sheng Jiang and Mohamed Boucadair for
their thorough review. their thorough review.
7. Change log [RFC Editor: Please remove] 7. Change log [RFC Editor: Please remove]
05: Integrated fixes from Brian Carpenters review. Details on 06: changed "split-horizon" term to "private-DNS" and reworded the
semantic/structural changes: paragraph about it.
05: Integrated fixes from Brian Carpenters review. See github
draft-ietf-anima-stable-connectivity/04-brian-carpenter-review-
reply.txt. Details on semantic/structural changes:
* Folded most comments back into draft-ietf-anima-autonomic- * Folded most comments back into draft-ietf-anima-autonomic-
control-plane-09 because this stable connectivity draft was control-plane-09 because this stable connectivity draft was
suggesting things that are better written out and standardized suggesting things that are better written out and standardized
in the ACP document. in the ACP document.
* Section on simultaneous ACP and data plane connectivity section * Section on simultaneous ACP and data plane connectivity section
reduced/rewritten because of this. reduced/rewritten because of this.
* Re-emphasized security model of ACP - ACP-connect can not * Re-emphasized security model of ACP - ACP-connect can not
skipping to change at page 19, line 21 skipping to change at page 19, line 25
address prefix selection and DNS for ACP. Title change to address prefix selection and DNS for ACP. Title change to
emphasize focus on OAM. Expanded abstract. emphasize focus on OAM. Expanded abstract.
individual-00: Initial version. individual-00: Initial version.
8. References 8. References
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-08 (work in progress), July 2017. plane-09 (work in progress), August 2017.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-07 (work in progress), July 2017. keyinfra-07 (work in progress), July 2017.
[I-D.ietf-anima-grasp] [I-D.ietf-anima-grasp]
Bormann, C., Carpenter, B., and B. Liu, "A Generic Bormann, C., Carpenter, B., and B. Liu, "A Generic
Autonomic Signaling Protocol (GRASP)", draft-ietf-anima- Autonomic Signaling Protocol (GRASP)", draft-ietf-anima-
skipping to change at page 20, line 7 skipping to change at page 20, line 11
[ITUT] International Telecommunication Union, "Architecture and [ITUT] International Telecommunication Union, "Architecture and
specification of data communication network", specification of data communication network",
ITU-T Recommendation G.7712/Y.1703, Noevember 2001. ITU-T Recommendation G.7712/Y.1703, Noevember 2001.
This is the earliest but superceeded version of the This is the earliest but superceeded version of the
series. See REC-G.7712 Home Page [1] for current series. See REC-G.7712 Home Page [1] for current
versions. versions.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<http://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets", and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>. <https://www.rfc-editor.org/info/rfc1918>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <http://www.rfc-editor.org/info/rfc4191>. November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<http://www.rfc-editor.org/info/rfc4193>. <https://www.rfc-editor.org/info/rfc4193>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <https://www.rfc-editor.org/info/rfc5246>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6 NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <http://www.rfc-editor.org/info/rfc6146>. April 2011, <https://www.rfc-editor.org/info/rfc6146>.
[RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu,
D., and S. Mansfield, "Guidelines for the Use of the "OAM" D., and S. Mansfield, "Guidelines for the Use of the "OAM"
Acronym in the IETF", BCP 161, RFC 6291, Acronym in the IETF", BCP 161, RFC 6291,
DOI 10.17487/RFC6291, June 2011, DOI 10.17487/RFC6291, June 2011,
<http://www.rfc-editor.org/info/rfc6291>. <https://www.rfc-editor.org/info/rfc6291>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
January 2012, <http://www.rfc-editor.org/info/rfc6347>. January 2012, <https://www.rfc-editor.org/info/rfc6347>.
[RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and [RFC6418] Blanchet, M. and P. Seite, "Multiple Interfaces and
Provisioning Domains Problem Statement", RFC 6418, Provisioning Domains Problem Statement", RFC 6418,
DOI 10.17487/RFC6418, November 2011, DOI 10.17487/RFC6418, November 2011,
<http://www.rfc-editor.org/info/rfc6418>. <https://www.rfc-editor.org/info/rfc6418>.
[RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node [RFC6434] Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node
Requirements", RFC 6434, DOI 10.17487/RFC6434, December Requirements", RFC 6434, DOI 10.17487/RFC6434, December
2011, <http://www.rfc-editor.org/info/rfc6434>. 2011, <https://www.rfc-editor.org/info/rfc6434>.
[RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for [RFC6518] Lebovitz, G. and M. Bhatia, "Keying and Authentication for
Routing Protocols (KARP) Design Guidelines", RFC 6518, Routing Protocols (KARP) Design Guidelines", RFC 6518,
DOI 10.17487/RFC6518, February 2012, DOI 10.17487/RFC6518, February 2012,
<http://www.rfc-editor.org/info/rfc6518>. <https://www.rfc-editor.org/info/rfc6518>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6 "Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://www.rfc-editor.org/info/rfc6724>. <https://www.rfc-editor.org/info/rfc6724>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple "TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>. <https://www.rfc-editor.org/info/rfc6824>.
[RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba,
"Architectural Considerations on Application Features in
the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013,
<https://www.rfc-editor.org/info/rfc6950>.
[RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A., [RFC7575] Behringer, M., Pritikin, M., Bjarnason, S., Clemm, A.,
Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic Carpenter, B., Jiang, S., and L. Ciavaglia, "Autonomic
Networking: Definitions and Design Goals", RFC 7575, Networking: Definitions and Design Goals", RFC 7575,
DOI 10.17487/RFC7575, June 2015, DOI 10.17487/RFC7575, June 2015,
<http://www.rfc-editor.org/info/rfc7575>. <https://www.rfc-editor.org/info/rfc7575>.
[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address [RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address
Mappings for Stateless IP/ICMP Translation", RFC 7757, Mappings for Stateless IP/ICMP Translation", RFC 7757,
DOI 10.17487/RFC7757, February 2016, DOI 10.17487/RFC7757, February 2016,
<http://www.rfc-editor.org/info/rfc7757>. <https://www.rfc-editor.org/info/rfc7757>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont, [RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915, "IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016, DOI 10.17487/RFC7915, June 2016,
<http://www.rfc-editor.org/info/rfc7915>. <https://www.rfc-editor.org/info/rfc7915>.
Authors' Addresses Authors' Addresses
Toerless Eckert (editor) Toerless Eckert (editor)
Futurewei Technologies Inc. Futurewei Technologies Inc.
2330 Central Expy 2330 Central Expy
Santa Clara 95050 Santa Clara 95050
USA USA
Email: tte+ietf@cs.fau.de Email: tte+ietf@cs.fau.de
Michael H. Behringer Michael H. Behringer
 End of changes. 25 change blocks. 
29 lines changed or deleted 38 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/