| v6ops | A. Servin |
| Internet-Draft | LACNIC |
| Intended status: Informational | M. Rocha |
| Expires: January 16, 2014 | Redes de Interconexion Universitaria Asoc. Civil (ARIU) |
| July 15, 2013 |
Monitoring Dual Stack/IPv6-only Networks and Services
draft-servin-v6ops-monitor-ds-ipv6-01
This document describes a set of recommendations and guidelines to help operators to monitor dual stack and IPv6-only networks. The document describes how to monitor these networks using SNMP, Flow Analyzers and other means.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 16, 2014.
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Network and services monitoring become more important as we rely more on them for our critical operations. Depending of the complexity of our monitor solution we would be able to have more control and information from our network and services. Among other things, a good monitor solution allows to::
All these make sense when we monitor our network responsibly trying to cover all the variables. In the context of this memo, it means that we should monitor our services and networks running IPv6 as we have/had done in the IPv4 world..
There are many documents and guides explaining how to deploy IPv6 networks and services but there are so few that describe in detail how to monitor them. This document tries to encompass a set of recommendations and guidelines to help network and system administrators to monitor dual-stack/IPv6-only network and services.
In this section we describe SNMP and IPFIX as protocols able to manage IP devices and to monitor a variety of data from dual stack and IPv6-only networks. We also discuss traffic analyzers as other tools to monitor IP networks.
It is important to understand the difference between IPv6 Transport vs. IPv6 data. In other words, protocols for monitor network infrastructure such as SNMP or IPFIX can send IPv6 collected data (e.g. the count of forwarded packets of an interface, flow information) using either IPv4 or IPv6 transport.
It is important to note that some node implementations would only send data (either IPv4 or IPv6) over IPv4 networks. Nevertheless these are implementation limitations not related to the monitoring protocol.
Simple Network Management Protocol (SNMP) defines the protocol suite to monitor and manage IP networks. SNMP works over UDP that allows it to work over IPv4 or IPv6 networks. However, the definitions that allow SNMP to collect data from IP devices know as "Management Information Base" (MIB) had to be modified from the original specifications. The most used versions of SNMP are Version 1 and Version 2 [RFC1441]. Version 3 is defined in [RFC3411].
SNMP MIB was defined in [RFC1156] and extended by [RFC1158]. Later it was modified by [RFC1213] in 1990 and in 1996 deprecated by RFCs [RFC2011], [RFC2012] and [RFC2013] that separated the MIB in IP, TCP and UDP. However all these modifications did not considered IPv6 yet. It was until [RFC2465] and [RFC2466] that MIB definitions were specified for IPv6 and ICMPv6. These RFCs described a dissociated definition for IPv4 and IPv6. The last MIB definitions came in 2006 when [RFC4292] (IP-Forwarding) and [RFC4293] (IP-MIB) defined an unified set of managed objects independent of the IP version.
Today there are many agent and collector implementations that support [RFC4292] and [RFC4293]. Nevertheless not all of them support them over IPv6 transport and IPv4 has to be used.
Knowing the packet count that goes in and out from an interface it is very important but many times is not enough to detect faults or to get more detailed traffic information about the network. Netflow and IP Flow Information Export (IPFIX) [RFC5101] and [RFC5102] are protocols that monitor the IP flows passing through network devices. An IP flow is a sequence of packets identified by a common set of attributes such as IP Source Address, IP Destination Address, Source Port, Destination Port, Layer 3 protocol type, Class of service, etc.
Netflow is a protocol developed by Cisco Systems and version 9 is described in the informational [RFC3594]. Other vendors have adopted equivalent technology such as Jflow (Juniper Networks), Cflowd (Alcatel-Lucent) and SFlow (sFlow.org consortium).
Netflow defines nine versions from which version 5 is the most common and only versions 9 and 10 support IPv6. Versions 9 and 10 are commonly known as the base of IPFIX. Although Netflow version 9 supports the collection of IPv6 flows, not all implementations of agents and collectors support IPv6 transport and IPv4 has to be used.
Sflow is defined in [RFC3176] and it is very similar to netflow and IPFIX. It differs basically in the method to collect flow information. In the case of Sflow, it uses statistical packet-based sampling of switched flows and time-based sampling. The Sflow version described in [RFC3176] supports IPv4 and IPv6 address families.
IPFIX architecture and message format is defined in RFC5101 [RFC5101]and RFC5102 [RFC5102] defines its information model. From the operational standpoint of this document IPFIX and Netflow v9 are not very different and there is not much more to say besides that IPFIX as a relatively new protocol has not been widely implemented. For this reason finding an implementation supporting IPv6 transport may be hard to find.
Besides SNMP and Flow analyzers IPv6 can be monitored using a variety of network/traffic analyzers. These devices come in a variety of flavors and some are open source or free and can be installed in commodity hardware, some other are expensive and run on specialized equipment. Commonly they are installed using promiscuous port that mirror all the network traffic or they are installed somewhere in the network where they can inspect most of the traffic.
Network/traffic analyzers are a quick way to inspect IPv6 traffic, however they may have scalability and privacy issues which make them unsuitable for large networks.
When SNMP and flow tools are not available in the network device and traffic analyzers are not suitable as a long term solution it may be possible to use in-house development or other tools to access networks devices and parse command line instructions that monitor IPv6 traffic. This solution could be used as well in IPv6 only networks when the device implementation does not support IPv6 transit to deliver monitoring data.
TBD, In this section we will discuss the use of Software Defined Network (SDN) for the purposes of gathering data from the network.
TBD. In this section we will discuss the implications to use of link-local, ULAs and Global Unicast Addresses for the purpose of monitor network infrastructure.
Beyond the traffic that goes through the network, network operators require to monitor other services such HTTP servers, email infrastructure, DNS, sensors, etc.
Besides network information, network operators require to know other variables that could affect the good operation of the network. Dual stack networks pose an important challenge to network and system administrators. In principle we are talking about two different networks that may have different paths and users may perceive a difference in quality. Furthermore, thanks to Happy Eye Balls RFC6555 [RFC6555] that improves the user experience, service operators may have no idea to which protocol users are connected. This impose the need to monitor two networks and two set of services such as HTTP servers, email infrastructure, DNS, etc. to guarantee the service expectations from users.
In order to monitor service uptime and performance, it is common to use service probes that frequently poll a specific service to verify its reachability. Most of the time this probes are configured to access a service using a Fully Qualified Domain Name (FQDN) but sometimes literals are used as well.
To monitor services using FQDNs with A and AAAA records network/system administrator must be aware that they do not have a guarantee that the probe is using IPv4 or IPv6 transport unless is forced to do so. Some tools provide configuration or execution flags to force the use of IPv4 or IPv6 transport. To guarantee a reliable monitoring strategy, we recommend using those flags to set up two monitor instances, one for each address family. Needless to say that in case of using literals instead of FQDNs, a new service monitor instance using an IPv6 address must be added.
We mentioned that one possible solution to discriminate between IPv4 and IPv6 services is to use some of the flags provided by the monitoring tool to force a connection either in IPv4 or IPv6. Depending of the tool used, this option may not be always available. To address this restriction it is possible to use a special FQDN with only an A record to force an IPv4 connection and a different FQDN with only an AAAA record for IPv6.
For example suppose that the main organization website has the name www.example.com. The name www.example.com would have A and AAAA records as normally, however it would also contain an A record of the form www.v4-test.example.com pointing to its IPv4 address and an AAAA record www.v6-test.example.com point to the IPv6 address of the service. Other variants may be www.v6.example.com, www-v4.example.com, etc. As these FQDNs are meant to be only internally the selection of which to use is left to the network operator.
Bear in mind that using this alternative may introduce an extra overhead related to DNS management and should be used only when strictly necessary.
The critical path to monitor IPv6 data on dual-stack networks is the device support of the IPv6 only MIBs ([RFC2465], [RFC2466], [RFC2452] and [RFC2454]), the unified MIBs ([RFC4293], [RFC4022], [RFC4113] and [RFC4292] or flow tools as Netflow 9 or IPFIX. As long as these protocols are supported, the device can be monitor using IPv4 or IPv6 transport. However, in IPv6-only networks supporting IPv6 data monitoring is not enough. In order to work it is critical for the device or collector to support the delivery or polling data using IPv6 transport.
For SNMP data there are a variety of agents and collectors that support IPv6 MIBs (IPv6 and Protocol Independent) using IPv6 transport. Nevertheless still exist devices that do not support neither IPv6 MIBs nor IPv6 transport of monitoring data.
With respect of flow tools, the authors of this document are aware of only a few implementations that support IPv6 transport.
Even though the end of IPv4 is near, there are still many network devices that cannot provide any type of IPv6 monitor data. In other cases the device can provide some sort of data through command line interfaces or in the best scenario through out the old IPv6 MIBs and using only IPv4 transit for delivery.
Still many network devices do not support to collect or send data related to IPv6. Also, some implementations are not widely tested and they may not support IPv6 monitoring correctly. For example, there were in the past cases where network devices did not correctly reported data collected from interface counters as they only counted packets that were process switched. Eventually this bug was fixed to include hardware-processed packets. It will still possible to find more of these types of bugs whilst IPv6 support mature. For that reason we recommend to network operators to always double check the IPv6 data retrieved from SNMP agents and interface counters at least for a short period of time. As the IPv6 support moves forward and matures, this practice would be less important in the future.
From the security stand point, monitoring IPv4, IPv6 or Dual Stack networks is no different and the same preventions have to be taken. In order to protect SNMP agents, Network Monitoring Systems (NMS), flow collectors, network analyzers, etc. operators are advised to use a variety of methods such as access list, separate networks for management and monitoring, avoid the use of clear text access, etc.
None.
We would like to thank Humberto Galiza, Alejandro Acosta, Sofia Silva, Diego Lopez, Ariel Weher, and Christian O'Flaherty for their questions, suggestions, reviews and comments. Also we would like to thank the LACNOG community for the informal comments that gave us during the meetings.