draft-ietf-anima-stable-connectivity-04.txt   draft-ietf-anima-stable-connectivity-05.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: January 28, 2018 July 27, 2017 Expires: February 3, 2018 August 2, 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-04 draft-ietf-anima-stable-connectivity-05
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 during device/network bring up tends to be far less easy
to automate than service provisioning later on, changes in core Provisioning while bringing up devices and networks tends to be more
network functions impacting reachability may not be easy to be difficult to automate than service provisioning later on, changes in
automated either because of ongoing connectivity requirements for the core network functions impacting reachability cannot be automated
OAM, and widely used OAM protocols are not secure enough to be because of ongoing connectivity requirements for the OAM equipment
itself, and widely used OAM protocols are not secure enough to be
carried across the network without security concerns. carried across the network without security concerns.
This document describes how to integrate OAM with the autonomic This document describes how to integrate OAM processes with the
control plane (ACP) in Autonomic Networks (AN) to provide stable and autonomic control plane (ACP) in Autonomic Networks (AN) in order to
secure connectivity for conducting OAM. This connectivity is not provide stable and secure connectivity for those OAM processes. This
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 http://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 January 28, 2018. This Internet-Draft will expire on February 3, 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 (http://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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Self dependent OAM Connectivity . . . . . . . . . . . . . 2 1.1. Self dependent OAM Connectivity . . . . . . . . . . . . . 2
1.2. Data Communication Networks (DCNs) . . . . . . . . . . . 3 1.2. Data Communication Networks (DCNs) . . . . . . . . . . . 3
1.3. Leveraging the ACP . . . . . . . . . . . . . . . . . . . 4 1.3. Leveraging the ACP . . . . . . . . . . . . . . . . . . . 4
2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Stable Connectivity for Centralized OAM . . . . . . . . . 4 2.1. Stable Connectivity for Centralized OAM . . . . . . . . . 4
2.1.1. Simple Connectivity for Non-ACP capable NMS Hosts . . 5 2.1.1. Simple Connectivity for Non-ACP capable NMS Hosts . . 5
2.1.2. Challenges and Limitation of Simple Connectivity . . 6 2.1.2. Challenges and Limitation of Simple Connectivity . . 6
2.1.3. Simultaneous ACP and Data Plane Connectivity . . . . 7 2.1.3. Simultaneous ACP and Data Plane Connectivity . . . . 7
2.1.4. IPv4-only NMS Hosts . . . . . . . . . . . . . . . . . 9 2.1.4. IPv4-only NMS Hosts . . . . . . . . . . . . . . . . . 8
2.1.5. Path Selection Policies . . . . . . . . . . . . . . . 10 2.1.5. Path Selection Policies . . . . . . . . . . . . . . . 11
2.1.6. Autonomic NOC Device/Applications . . . . . . . . . . 12 2.1.6. Autonomic NOC Device/Applications . . . . . . . . . . 12
2.1.7. Encryption of data-plane connections . . . . . . . . 12 2.1.7. Encryption of data-plane connections . . . . . . . . 13
2.1.8. Long Term Direction of the Solution . . . . . . . . . 13 2.1.8. Long Term Direction of the Solution . . . . . . . . . 14
2.2. Stable Connectivity for Distributed Network/OAM . . . . . 14 2.2. Stable Connectivity for Distributed Network/OAM . . . . . 15
3. Security Considerations . . . . . . . . . . . . . . . . . . . 14 3. Architectural Considerations . . . . . . . . . . . . . . . . 15
4. No IPv4 for ACP . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. No IPv4 for ACP . . . . . . . . . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 17 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Change log [RFC Editor: Please remove] . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
1.1. Self dependent OAM Connectivity 1.1. Self dependent OAM Connectivity
OAM (Operations, Administration and Maintenance - as per BCP161, OAM (Operations, Administration and Maintenance - as per BCP161,
[RFC6291]) for data networks is often subject to the problem of [RFC6291]) for data networks is often subject to the problem of
circular dependencies when relying on the connectivity service circular dependencies when relying on the connectivity service
provided by the network to be managed. OAM can easily but provided by the network to be managed. OAM can easily but
unintentionally break the connectivity required for its own unintentionally break the connectivity required for its own
skipping to change at page 6, line 36 skipping to change at page 6, line 40
2.1.2. Challenges and Limitation of Simple Connectivity 2.1.2. Challenges and Limitation of Simple Connectivity
This simple connectivity of non-autonomic NMS hosts suffers from a This simple connectivity of non-autonomic NMS hosts suffers from a
range of challenges (that is, operators may not be able to do it this range of challenges (that is, operators may not be able to do it this
way) or limitations (that is, operator cannot achieve desired goals way) or limitations (that is, operator cannot achieve desired goals
with this setup). The following list summarizes these challenges and with this setup). The following list summarizes these challenges and
limitations. The following sections describe additional mechanisms limitations. The following sections describe additional mechanisms
to overcome them. to overcome them.
Note that these challenges and limitations exist because ACP is Note that these challenges and limitations exist because ACP is
primarily designed to support distributed ASA in the most lightweight primarily designed to support distributed ASA (Autonomic Service
Agent, a piece of autonomic software) in the most lightweight
fashion, but not mandatorily require support for additional fashion, but not mandatorily require support for additional
mechanisms to best support centralized NOC operations. It is this mechanisms to best support centralized NOC operations. It is this
document that describes additional (short term) workarounds and (long document that describes additional (short term) workarounds and (long
term) extensions. term) extensions.
1. (Limitation) NMS hosts cannot directly probe whether the desired 1. (Limitation) NMS hosts cannot directly probe whether the desired
so called 'data-plane' network connectivity works because they do so called 'data-plane' network connectivity works because they do
not directly have access to it. This problem is similar to not directly have access to it. This problem is similar to
probing connectivity for other services (such as VPN services) probing connectivity for other services (such as VPN services)
that they do not have direct access to, so the NOC may already that they do not have direct access to, so the NOC may already
skipping to change at page 7, line 18 skipping to change at page 7, line 20
3. (Limitation) Performance of the ACP will be limited versus normal 3. (Limitation) Performance of the ACP will be limited versus normal
'data-plane' connectivity. The setup of the ACP will often 'data-plane' connectivity. The setup of the ACP will often
support only non-hardware accelerated forwarding. Running a support only non-hardware accelerated forwarding. Running a
large amount of traffic through the ACP, especially for tasks large amount of traffic through the ACP, especially for tasks
where it is not necessary will reduce its performance/ where it is not necessary will reduce its performance/
effectiveness for those operations where it is necessary or effectiveness for those operations where it is necessary or
highly desirable. See Section 2.1.5 for candidate solutions. highly desirable. See Section 2.1.5 for candidate solutions.
4. (Limitation) Security of the ACP is reduced by exposing the ACP 4. (Limitation) Security of the ACP is reduced by exposing the ACP
natively (and unencrypted) into a LAN in the NOC where the NOC natively (and unencrypted) into a subnet in the NOC where the NOC
devices are attached to it. See Section 2.1.7 for candidate devices are attached to it. See Section 2.1.7 for candidate
solutions. solutions.
These four problems can be tackled independently of each other by These four problems can be tackled independently of each other by
solution improvements. Combining some of these solutions solution improvements. Combining some of these solutions
improvements together can lead towards a candiate long term solution. improvements together can lead towards a candiate long term solution.
2.1.3. Simultaneous ACP and Data Plane Connectivity 2.1.3. Simultaneous ACP and Data Plane Connectivity
Simultaneous connectivity to both ACP and data-plane can be achieved Simultaneous connectivity to both ACP and data-plane can be achieved
in a variety of ways. If the data-plane is IPv4-only, then any in a variety of ways. If the data-plane is IPv4-only, then any
method for dual-stack attachment of the NOC device/application will method for dual-stack attachment of the NOC device/application will
suffice: IPv6 connectivity from the NOC provides access via the ACP, suffice: IPv6 connectivity from the NOC provides access via the ACP,
IPv4 will provide access via the data-plane. If as explained above IPv4 will provide access via the data-plane. If as explained above
in the simple case, an autonomic device supports native attachment to in the simple case, an autonomic device supports native attachment to
the ACP, and the existing NOC setup is IPv4 only, then it could be the ACP, and the existing NOC setup is IPv4 only, then it could be
sufficient to attach the ACP device(s) as the IPv6 default router to sufficient to attach the ACP device(s) as the IPv6 default router to
the NOC LANs and keep the existing IPv4 default router setup the NOC subnet and keep the existing IPv4 default router setup
unchanged. unchanged.
If the data-plane of the network is also supporting IPv6, then the If the data-plane of the network is also supporting IPv6, then the
NOC devices that need access to the ACP should have a dual-homing most compatible setup for NOC devices is to have two IPv6 interfaces.
IPv6 setup. One option is to make the NOC devices multi-homed with One virtual ((e.g. via IEEE 802.1Q [IEEE802.1Q]) or physical
one logical or physical IPv6 interface connecting to the data-plane, interface connecting to a data-plane subnet, and another into an ACP
and another into the ACP. The LAN that provides access to the ACP connect subnet as specified in the ACP connection section of
should then be given an IPv6 prefix that shares a common prefix with [I-D.ietf-anima-autonomic-control-plane]. That document also
the IPv6 ULA (see [RFC4193]) of the ACP so that the standard IPv6 specifies how the NOC devices can receive autoconfigured addressing
interface selection rules on the NOC host would result in the desired and routes towards the ACP connect subnet if it supports [RFC6724]
automatic selection of the right interface: towards the ACP facing and [RFC4191].
interface for connections to ACP addresses, and towards the data-
plane interface for anything else. If this cannot be achieved
automatically, then it needs to be done via IPv6 static routes in the
NOC host.
Providing two virtual (e.g. dot1q subnet) connections into NOC hosts
may be seen as an undesired complexity. In that case the routing
policy to provide access to both ACP and data-plane via IPv6 needs to
happen in the NOC network itself: The NMS host gets a single
attachment interface but still with the same two IPv6 addresses as in
before - one for use towards the ACP, one towards the data-plane.
The first-hop router connecting to the NMS host would then have
separate interfaces: one towards the data-plane, one towards the ACP.
Routing of traffic from NMS hosts would then have to be based on the
source IPv6 address of the host: Traffic from the address designated
for ACP use would get routed towards the ACP, traffic from the
designated data-plane address towards the data-plane.
In the simple case, we get the following topology: Existing NMS hosts
connect via an existing NOClan and existing first hop Rtr1 to the
data-plane. Rtr1 is not made autonomic, but instead the edge router
of the Autonomic network ANrtr is attached via a separate interface
to Rtr1 and ANrtr provides access to the ACP via ACPaccessLan. Rtr1
is configured with the above described IPv6 source routing policies
and the NOC-app-devices are given the secondary IPv6 address for
connectivity into the ACP.
--... (data-plane)
NOC-app-device(s) -- NOClan -- Rtr1
--- ACPaccessLan -- ANrtr ... (ACP)
Figure 1
If Rtr1 was to be upgraded to also implement Autonomic Networking and
the ACP, the picture would change as follows:
---- ... (data-plane)
NOC-app-device(s) ---- NOClan --- ANrtr1
. . ---- ... (ACP)
\-/
(ACP to data-plane loopback)
Figure 2 Configuring a second interface on a NOC host may be impossible or be
seen as undesired complexity. In that case the ACP edge device needs
to provide support for a "Combined ACP and Data Plane interface" as
also described in the ACP connect section of
[I-D.ietf-anima-autonomic-control-plane]. This setup may not work
with autoconfiguration and all NOC host network stacks due to
limitations in those network stacks. They need to be able to perform
RFC6724 source address selection rule 5.5 including caching of next-
hop information. See the ACP document text for more details.
In this case, ANrtr1 would have to implement some more advanced For security reasons, it is not considered appropriate in the ACP
routing such as cross-VRF routing because the data-plane and ACP are document to connect a non-ACP router to an ACP connect interface.
most likely run via separate VRFs. A workaround without additional The reason is that the ACP is a secured network domain and all NOC
software functionality could be a physical external loopback cable devices connecting via ACP connect interfaces are also part of that
into two ports of ANrtr1 to connect the data-plane and ACP VRF as secure domain - the main difference is that the physical link between
shown in the picture. A (virtual) software loopback between the ACP the ACP edge device and the NOC devices is not authenticated/
and data plane VRF would of course be the better solution. encrypted and therefore needs to be physically secured. If the
secure ACP was extendable via untrusted routers then it would be a
lot more verify the secure domain assertion. Therefore the ACP edge
devices are not supposed to redistribute routes from non-ACP routers
into the ACP.
2.1.4. IPv4-only NMS Hosts 2.1.4. IPv4-only NMS Hosts
ACP does not support IPv4: Single stack IPv6 management of the ACP does not support IPv4: Single stack IPv6 management of the
network via ACP and (as needed) data plane. Independent of whether network via ACP and (as needed) data plane. Independent of whether
the data plane is dual-stack, has IPv4 as a service or is single the data plane is dual-stack, has IPv4 as a service or is single
stack IPv6. Dual plane management, IPv6 for ACP, IPv4 for the data stack IPv6. Dual plane management, IPv6 for ACP, IPv4 for the data
plane is likewise an architecturally simple option. plane is likewise an architecturally simple option.
The downside of this architectural decision is the potential need for The implication of this architectural decision is the potential need
short-term workarounds when the operational practices in a network for short-term workarounds when the operational practices in a
that cannot meet these target expectations. This section motivates network do not yet meet these target expectations. This section
when and why these workarounds may be necessary and describes them. explains when and why these workarounds may be operationally
All the workarounds described in this section are HIGHLY UNDESIRABLE. necessary and describes them. However, the long term goal is to
The only recommended solution is to enable IPv6 on NMS hosts. upgrade all NMS hosts to native IPv6, so the workarounds described in
this section should not be considered permanent.
Most network equipment today supports IPv6 but it is by far not Most network equipment today supports IPv6 but it is by far not
ubiquitously supported in NOC backend solutions (HW/SW), especially ubiquitously supported in NOC backend solutions (HW/SW), especially
not in the product space for enterprises. Even when it is supported, not in the product space for enterprises. Even when it is supported,
there are often additional limitations or issues using it in a dual there are often additional limitations or issues using it in a dual
stack setup or the operator mandates for simplicity single stack for stack setup or the operator mandates for simplicity single stack for
all operations. For these reasons an IPv4 only management plane is all operations. For these reasons an IPv4 only management plane is
still required and common practice in many enterprises. Without the still required and common practice in many enterprises. Without the
desire to leverage the ACP, this required and common practice is not desire to leverage the ACP, this required and common practice is not
a problem for those enterprises even when they run dual stack in the a problem for those enterprises even when they run dual stack in the
network. We document these workarounds here because it is a short network. We discuss these workarounds here because it is a short
term deployment challenge specific to the operations of the ACP. term deployment challenge specific to the operations of the ACP.
To bridge an IPv4 only management plane with the ACP, IPv4 to IPv6 To connect IPv4 only management plane devices/applications with the
NAT can be used. This NAT setup could for example be done in Rt1r1 ACP, some form of IP/ICMP translation of packets IPv4<->IPv6 is
in above picture to also support IPv4 only NMS hots connected to necessary. The basic mechanisms for this are defined in SIIT
NOClan. ([RFC7915]). There are multiple solutions using this mechanisms. To
understand the possible solutions, we consider the requirements:
To support connections initiated from IPv4 only NMS hosts towards the 1. NMS hosts need to be able to initiate connections to any ACP
ACP of network devices, it is necessary to create a static mapping of device for management purposes. Examples include provisioning
ACP IPv6 addresses into an unused IPv4 address space and dynamic or via Netconf/(SSH), SNMP poll operations or just diagnostics via
static mapping of the IPv4 NOC application device address (prefix) SSH connections from operators. Every ACP device/function that
into IPv6 routed in the ACP. The main issue in this setup is the needs to be reachable from NMS hosts needs to have a separate
mapping of all ACP IPv6 addresses to IPv4. Without further network IPv4 address.
intelligence, this needs to be a 1:1 address mapping because the
prefix used for ACP IPv6 addresses is too long to be mapped directly
into IPv4 on a prefix basis.
One could implement in router software dynamic mappings by leveraging 2. ACP devices need to be able to initiate connections to NMS hosts
DNS, but it seems highly undesirable to implement such complex for example to initiate NTP or radius/diameter connections, send
technologies for something that ultimately is a temporary problem syslog or SNMP trap or initiate Netconf Call Home connections
(IPv4 only NMS hosts). With today's operational directions it is after bootstrap. Every NMS host needs to have a separate IPv6
likely more preferable to automate the setup of 1:1 NAT mappings in address reachable from the ACP. When connections from ACP
that NAT router as part of the automation process of network device devices are made to NMS hosts, the IPv4 source address of these
enrollment into the ACP. connections as seen by the NMS Host must also be unique per ACP
device and the same address as in (1) to maintain the same
addressing simplicity as in a native IPv4 deployment. For
example in syslog, the source-IP address of a logging device is
used to identify it, and if the device shows problems, an
operator might want to SSH into the device to diagnose it.
The ACP can also be used for connections initiated by the network Because of these requirements, the necessary and sufficient set of
device into the NMS hosts. For example, syslog from autonomic solutions are those that provide 1:1 mapping of IPv6 ACP addresses
devices. In this case, static mappings of the NMS hosts IPv4 into IPv4 space and 1:1 mapping of IPv4 NMS host space into IPv6 (for
addresses are required. This can easily be done with a static prefix use in the ACP). This means that stateless SIIT based solutions are
mapping into IPv6. sufficient and preferred.
Note that ACP devices may use multiple IPv6 addresses in the ACP
based on which Sub-Scheme they use. For example in the Zone Sub-
Scheme, an ACP device could use two addresses, one with the last
address bit (V-bit) 0 and one with 1. Both addresses may need to be
reachable thought the IPv6/IPv4 address translation.
The need to allocate for every ACP device one or multiple IPv4
addresses should not be a problem if - as we assume - the NMS hosts
can use private IPv4 address space ([RFC1918]). Nevertheless even
with RFC1918 address space it is important that the ACP IPv6
addresses can efficiently be mapped into IPv4 address space without
too much waste.
The currently most flexible mapping scheme to achieve this is
[RFC7757] because it allows configured IPv4 <-> IPv6 prefix mapping.
Assume the ACP uses the Zone Addressing Sub-Scheme and there are 3
registrars. In the Zone Addressing Sub-Scheme, there is for each
registrar a constant /112 prefix for which in RFC7757 an EAM
(Explicit Address Mapping) into a /16 (eg: RFC1918) prefix into IPv4
can be configured. Within the registrars /112 prefix, Device-Numbers
for devices are sequentially assigned: with V-bit effectively two
numbers are assigned per ACP device. This also means that if IPv4
address space is even more constrained, and it is known that a
registrar will never need the full /15 extent of Device-Numbers, then
a longer than /112 prefix can be configured into the EAM to use less
IPv4 space.
When using the Vlong Addressing Sub-Scheme, it is unlikely that one
wants or need to translate the full /8 or /16 bits of addressing
space per ACP device into IPv4. In this case, the EAM rules of
dropping trailing bits can be used to map only N bits of the V-bits
into IPv4. This does imply though that only V-addresses that differ
in those high-order N V-bits can be distinguished on the IPv4 side.
Likewise, the IPv4 address space used for NMS hosts can easily be
mapped into an ACP prefix assigned to an ACP connect interface.
A full specification of a solution to perform SIIT in conjunction
with ACP connect following the considerations below is outside the
scope of this document.
To be in compliance with security expectations, SIIT has to to happen
on the ACP edge device itself so that ACP security considerations can
be taken into account. Eg: that IPv4 only NMS hosts can be dealt
with exactly like IPv6 hosts connected to an ACP connect interface.
Note that prior solutions such as NAT64 ([RFC6146]) may equally be
useable to translate between ACP IPv6 address space and NMS Hosts
IPv4 address space, and that as workarounds this can also be done on
non ACP Edge Devices connected to an ACP connect interface. The
details vary depending on implementation because the options to
configure address mappings vary widely. Outside of EAM, there are no
standardized solutions that allow for mapping of prefixes, so it will
most likely be necessary to explicitly map every individual (/128)
ACP device address to an IPv4 address. Such an approach should use
automation/scripting where these address translation entries are
created dynamically whenever an ACP device is enrolled or first
connected to the ACP network.
Overall, the use of NAT is especially subject to the ROI (Return On Overall, the use of NAT is especially subject to the ROI (Return On
Investment) considerations, but the methods described here may not be Investment) considerations, but the methods described here may not be
too different from the same problems encountered totally independent too different from the same problems encountered totally independent
of AN/ACP when some parts of the network are to introduce IPv6 but of AN/ACP when some parts of the network are to introduce IPv6 but
NMS hosts are not (yet) upgradeable. NMS hosts are not (yet) upgradeable.
2.1.5. Path Selection Policies 2.1.5. Path Selection Policies
As mentioned above, the ACP is not expected to have high performance As mentioned above, the ACP is not expected to have high performance
skipping to change at page 13, line 39 skipping to change at page 14, line 26
2.1.8. Long Term Direction of the Solution 2.1.8. Long Term Direction of the Solution
If we consider what potentially could be the most lightweight and If we consider what potentially could be the most lightweight and
autonomic long term solution based on the technologies described autonomic long term solution based on the technologies described
above, we see the following direction: above, we see the following direction:
1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the 1. NMS hosts should at least support IPv6. IPv4/IPv6 NAT in the
network to enable use of ACP is long term undesirable. Having network to enable use of ACP is long term undesirable. Having
IPv4 only applications automatically leverage IPv6 connectivity IPv4 only applications automatically leverage IPv6 connectivity
via host-stack translation may be an option but the operational via host-stack translation may be an option but this has not been
viability of this approach is not well enough understood. investigated yet.
2. Build the ACP as a lightweight application for NMS hosts so ACP 2. Build the ACP as a lightweight application for NMS hosts so ACP
extends all the way into the actual NMS hosts. extends all the way into the actual NMS hosts.
3. Leverage and as necessary enhance MPTCP with automatic dual- 3. Leverage and as necessary enhance MPTCP with automatic dual-
connectivity: If an MPTCP unaware application is using ACP connectivity: If an MPTCP unaware application is using ACP
connectivity, the policies used should add subflow(s) via the connectivity, the policies used should add subflow(s) via the
data-plane and prefer them. data-plane and prefer them.
4. Consider how to best map NMS host desires to underlying transport 4. Consider how to best map NMS host desires to underlying transport
skipping to change at page 14, line 31 skipping to change at page 15, line 23
protocol does this with functional elements usually called "Hello" protocol does this with functional elements usually called "Hello"
mechanisms and with often protocol specific security mechanisms. mechanisms and with often protocol specific security mechanisms.
KARP (Keying and Authentication for Routing Protocols, see [RFC6518]) KARP (Keying and Authentication for Routing Protocols, see [RFC6518])
has tried to start provide common directions and therefore reduce the has tried to start provide common directions and therefore reduce the
re-invention of at least some of the security aspects, but it only re-invention of at least some of the security aspects, but it only
covers routing-protocols and it is unclear how well it applicable to covers routing-protocols and it is unclear how well it applicable to
a potentially wider range of network distributed agents such as those a potentially wider range of network distributed agents such as those
performing distributed OAM. The ACP can help in these cases. performing distributed OAM. The ACP can help in these cases.
3. Security Considerations 3. Architectural Considerations
3.1. No IPv4 for ACP
The ACP is targeted to be IPv6 only, and the prior explanations in
this document show that this can lead to some complexity when having
to connect IPv4 only NOC solutions, and that it will be impossible to
leverage the ACP when the OAM agents on an ACP network device do not
support IPv6. Therefore, the question was raised whether the ACP
should optionally also support IPv4.
The decision not to include IPv4 for ACP as something that is
considered in the use cases in this document is because of the
following reasons:
In SP networks that have started to support IPv6, often the next
planned step is to consider moving out IPv4 from a native transport
as just a service on the edge. There is no benefit/need for multiple
parallel transport families within the network, and standardizing on
one reduces OPEX and improves reliability. This evolution in the
data plane makes it highly unlikely that investing development cycles
into IPv4 support for ACP will have a longer term benefit or enough
critical short-term use-cases. Support for IPv4-only for ACP is
purely a strategic choice to focus on the known important long term
goals.
In other type of networks as well, we think that efforts to support
autonomic networking is better spent in ensuring that one address
family will be support so all use cases will long-term work with it,
instead of duplicating effort into IPv4. Especially because auto-
addressing for the ACP with IPv4 would be more complex than in IPv6
due to the IPv4 addressing space.
4. Security Considerations
In this section, we discuss only security considerations not covered In this section, we discuss only security considerations not covered
in the appropriate sub-sections of the solutions described. in the appropriate sub-sections of the solutions described.
Even though ACPs are meant to be isolated, explicit operator Even though ACPs are meant to be isolated, explicit operator
misconfiguration to connect to insecure OAM equipment and/or bugs in misconfiguration to connect to insecure OAM equipment and/or bugs in
ACP devices may cause leakage into places where it is not expected. ACP devices may cause leakage into places where it is not expected.
Mergers/Acquisitions and other complex network reconfigurations Mergers/Acquisitions and other complex network reconfigurations
affecting the NOC are typical examples. affecting the NOC are typical examples.
ULA addressing as proposed in this document is preferred over ACP prefix addresses are ULA addresses. Using these addresses also
globally reachable addresses because it is not routed in the global for NOC devices as proposed in this document is not only necessary
Internet and will therefore be subject to more filtering even in for above explained simple routing functionality but it is also more
places where specific ULA addresses are being used. secure than global IPv6 addresses. ULA addresses are not routed in
the global Internet and will therefore be subject to more filtering
even in places where specific ULA addresses are being used. Packets
are therefore less likely to leak to be successfully injected into
the isolated ACP environment.
Random ULA addressing provides more than sufficient protection The random nature of a ULA prefix provides strong protection against
against address collision even though there is no central assignment address collision even though there is no central assignment
authority. This is helped by the expectation, that ACPs are never authority. This is helped by the expectation, that ACPs are never
expected to connect all together, but only few ACPs may ever need to expected to connect all together, but only few ACPs may ever need to
connect together, e.g. when mergers and aquisitions occur. connect together, e.g. when mergers and aquisitions occur.
If packets with unexpected ULA addresses are seen and one expects The ACP specification demands that only packets from configured ACP
them to be from another networks ACP from which they leaked, then prefixes are permitted from ACP connect interfaces. It also requires
some form of ULA prefix registration (not allocation) can be that RPL root ACP devices need to be able to diagnose unknown ACP
beneficial. Some voluntary registries exist, for example destination addresses.
https://www.sixxs.net/tools/grh/ula/, although none of them is
preferable because of being operated by some recognized authority.
If an operator would want to make its ULA prefix known, it might need
to register it with multiple existing registries.
ULA Centrally assigned ULA addresses (ULA-C) was an attempt to To help diagnose packets that unexpectedly leaked for example from
introduce centralized registration of randomly assigned addresses and another ACP (that was meant to be deployed separately), it can be
potentially even carve out a different ULA prefix for such addresses. useful to voluntarily list your own the ULA ACP prefixes in one of
This proposal is currently not proceeding, and it is questionable the sites on the Internet, for example
whether the stable connectivity use case provides sufficient https://www.sixxs.net/tools/grh/ula/. Note that this does not
motivation to revive this effort. constitute registration and if you want to ensure that your leaked
ACP packets can be recognized to come from you, you may need to list
your prefixes in multiple of those sites.
Using current registration options implies that there will not be Note that there is a provision in [RFC4193] for non-locally assigned
reverse DNS mapping for ACP addresses. For that one will have to address space (L bit = 0), but there is no existing standardization
rely on looking up the unknown/unexpected network prefix in the for this, so these ULA prefixes must not be used.
registry to determine the owner of these addresses.
Reverse DNS resolution may be beneficial for specific already According to RFC4193 section 4.4, PTR records for ULA addresses
deployed insecure legacy protocols on NOC OAM systems that intend to should not be installed into the global DNS (no guaranteed
communicate via the ACP (e.g. TFTP) and leverages reverse-DNS for ownership). Hence also the need to rely on voluntary lists (and in
authentication. Given how the ACP provides path security except prior paragraph) to make the use of an ULA prefix globally known.
potentially for the last-hop in the NOC, the ACP does make it easier
to extend the lifespan of such protocols in a secure fashion as far Nevertheless, some legacy OAM applications running across the ACP may
to just the transport is concerned. The ACP does not make reverse rely on reverse DNS lookup for authentication of requests (eg: TFTP
DNS lookup a secure authentication method though. Any current and for download of network firmware/config/software). Operators may
future protocols must rely on secure end-to-end communications (TLS/ therefore use split horizon DNS to provide global PTR records for
DTLS) and identification and authentication via the certificates their own ULA prefixes only into their own domain to continue relying
assigned to both ends. This is enabled by the certificate mechanisms on this method. Given the security of the ACP, this may even
of the ACP. increase the security of such legacy methods.
Any current and future protocols must rely on secure end-to-end
communications (TLS/DTLS) and identification and authentication via
the certificates assigned to both ends. This is enabled by the
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
as the autonomic devices themselves will derive their ULA addresses as the autonomic devices themselves will derive their ULA addresses
from their certificates to ensure correct and consistent DNS entries. from their certificates to ensure correct and consistent DNS entries.
If an operator feels that reverse DNS records are beneficial to its If an operator feels that reverse DNS records are beneficial to its
own operations but that they should not be made available publically own operations but that they should not be made available publically
for "security" by concealment reasons, then the case of ACP DNS for "security" by concealment reasons, then the case of ACP DNS
entries is probably one of the least problematic use cases for split- entries is probably one of the least problematic use cases for split-
DNS: The ACP DNS names are only needed for the NMS hosts intending to DNS: The ACP DNS names are only needed for the NMS hosts intending to
use the ACP - but not network wide across the enterprise. use the ACP - but not network wide across the enterprise.
4. No IPv4 for ACP
The ACP is targeted to be IPv6 only, and the prior explanations in
this document show that this can lead to some complexity when having
to connect IPv4 only NOC solutions, and that it will be impossible to
leverage the ACP when the OAM agents on an ACP network device do not
support IPv6. Therefore, the question was raised whether the ACP
should optionally also support IPv4.
The decision not to include IPv4 for ACP as something that is
considered in the use cases in this document is because of the
following reasons:
In SP networks that have started to support IPv6, often the next
planned step is to consider moving out IPv4 from a native transport
as just a service on the edge. There is no benefit/need for multiple
parallel transport families within the network, and standardizing on
one reduces OPEX and improves reliability. This evolution in the
data plane makes it highly unlikely that investing development cycles
into IPv4 support for ACP will have a longer term benefit or enough
critical short-term use-cases. Support for IPv4-only for ACP is
purely a strategic choice to focus on the known important long term
goals.
In other type of networks as well, we think that efforts to support
autonomic networking is better spent in ensuring that one address
family will be support so all use cases will long-term work with it,
instead of duplicating effort into IPv4. Especially because auto-
addressing for the ACP with IPv4 would be more complex than in IPv6
due to the IPv4 addressing space.
5. IANA Considerations 5. IANA Considerations
This document requests no action by IANA. This document requests no action by IANA.
6. Acknowledgements 6. Acknowledgements
This work originated from an Autonomic Networking project at cisco This work originated from an Autonomic Networking project at cisco
Systems, which started in early 2010 including customers involved in Systems, which started in early 2010 including customers involved in
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]
04: Integrated fixes from Mohamed Boucadairs review. 05: Integrated fixes from Brian Carpenters review. Details on
semantic/structural changes:
03: Integrated fixes from Shepherd review (Sheng Jiang). * Folded most comments back into draft-ietf-anima-autonomic-
control-plane-09 because this stable connectivity draft was
suggesting things that are better written out and standardized
in the ACP document.
* Section on simultaneous ACP and data plane connectivity section
reduced/rewritten because of this.
* Re-emphasized security model of ACP - ACP-connect can not
arbitrarily extend ACP routing domain.
* Re-wrote much of NMS section to be less suggestive and more
descriptive, avoiding the term NAT and referring to relevant
RFCs (SIIT etc.).
* Main additional text in IPv4 section is about explaining how we
suggest to use EAM (Explicit Address Mapping) which actuall
would well work with the Zone and Vlong Addressing Sub-Schemes
of ACP.
* Moved, but not changed section of "why no IPv4 in ACP" before
IANA considerations to make structure of document more logical.
* Refined security considerations: explained how optional ULA
prefix listing on Internet is only for diagnostic purposes.
Explained how this is useful because DNS must not be used.
Explained how split horizon DNS can be used nevertheless.
04: Integrated fixes from Mohamed Boucadairs review (thorough
textual review).
03: Integrated fixes from thorough Shepherd review (Sheng Jiang).
01: Refresh timeout. Stable document, change in author 01: Refresh timeout. Stable document, change in author
association. association.
01: Refresh timeout. Stable document, no changes. 01: Refresh timeout. Stable document, no changes.
00: Changed title/dates. 00: Changed title/dates.
individual-02: Updated references. individual-02: Updated references.
skipping to change at page 18, line 11 skipping to change at page 19, line 40
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-
grasp-15 (work in progress), July 2017. grasp-15 (work in progress), July 2017.
[I-D.ietf-anima-reference-model] [I-D.ietf-anima-reference-model]
Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L., Behringer, M., Carpenter, B., Eckert, T., Ciavaglia, L.,
Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A Pierre, P., Liu, B., Nobre, J., and J. Strassner, "A
Reference Model for Autonomic Networking", draft-ietf- Reference Model for Autonomic Networking", draft-ietf-
anima-reference-model-04 (work in progress), July 2017. anima-reference-model-04 (work in progress), July 2017.
[IEEE802.1Q]
International Telecommunication Union, "802.1Q-2014 - IEEE
Standard for Local and metropolitan area networks -
Bridges and Bridged Networks", 2014.
[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, June 2008. ITU-T Recommendation G.7712/Y.1703, Noevember 2001.
This is the earliest but superceeded version of the
series. See REC-G.7712 Home Page [1] for current
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>. <http://www.rfc-editor.org/info/rfc1034>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.,
and E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996,
<http://www.rfc-editor.org/info/rfc1918>.
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191,
November 2005, <http://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>. <http://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>. <http://www.rfc-editor.org/info/rfc5246>.
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful
NAT64: Network Address and Protocol Translation from IPv6
Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146,
April 2011, <http://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>. <http://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, <http://www.rfc-editor.org/info/rfc6347>.
skipping to change at page 19, line 5 skipping to change at page 21, line 10
[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, <http://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>. <http://www.rfc-editor.org/info/rfc6518>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<http://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>. <http://www.rfc-editor.org/info/rfc6824>.
[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>. <http://www.rfc-editor.org/info/rfc7575>.
[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address
Mappings for Stateless IP/ICMP Translation", RFC 7757,
DOI 10.17487/RFC7757, February 2016,
<http://www.rfc-editor.org/info/rfc7757>.
[RFC7915] Bao, C., Li, X., Baker, F., Anderson, T., and F. Gont,
"IP/ICMP Translation Algorithm", RFC 7915,
DOI 10.17487/RFC7915, June 2016,
<http://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
 End of changes. 36 change blocks. 
189 lines changed or deleted 304 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/