One document matched: draft-servin-v6ops-monitor-ds-ipv6-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC1157 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1157.xml">
<!ENTITY RFC1441 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1441.xml">
<!ENTITY RFC1158 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1158.xml">
<!ENTITY RFC1156 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1156.xml">
<!ENTITY RFC1213 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1213.xml">
<!ENTITY RFC2011 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2011.xml">
<!ENTITY RFC2012 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2012.xml">
<!ENTITY RFC2465 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2465.xml">
<!ENTITY RFC2466 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2466.xml">
<!ENTITY RFC4292 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4292.xml">
<!ENTITY RFC4293 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4293.xml">
<!ENTITY RFC2013 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2013.xml">
<!ENTITY RFC3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml">
<!ENTITY RFC5102 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5102.xml">
<!ENTITY RFC5101 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5101.xml">
<!ENTITY RFC3594 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3594.xml">
<!ENTITY RFC6555 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6555.xml">
<!ENTITY RFC2452 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2452.xml">
<!ENTITY RFC2454 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2454.xml">
<!ENTITY RFC4022 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4022.xml">
<!ENTITY RFC4113 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4113.xml">
<!ENTITY RFC3176 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3176.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" docName="draft-servin-v6ops-monitor-ds-ipv6-00" ipr="trust200902">
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="Abbreviated Title">Monitoring Dual Stack/IPv6-only Networks and Services</title>
<author fullname="Arturo Servin" initials="A." surname="Servin">
<organization>LACNIC</organization>
<address>
<postal>
<street>Rambla Republica de Mexico 6125</street>
<city>Montevideo</city>
<code>11300</code>
<country>Uruguay</country>
</postal>
<phone>+598 2604 2222</phone>
<email>aservin@lacnic.net</email>
</address>
</author>
<author fullname="Mariela Rocha" initials="M." surname="Rocha">
<organization>Redes de Interconexion Universitaria Asoc. Civil (ARIU)</organization>
<address>
<postal>
<street>Maipu 645 - 4to Piso</street>
<city>Buenos Aires</city>
<country>Argentina</country>
</postal>
<email>mrocha@riu.edu.ar </email>
</address>
</author>
<date month="July" year="2013" />
<area></area>
<workgroup>v6ops</workgroup>
<keyword>IPv6, operations, monitoring, snmp</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>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.
A good monitor solution allows to: </t>
<t><list style="symbols">
<t>Detect and avoid problems</t>
<t>Determinate which actions may solve a problem</t>
<t>Execute recovery and contingency plans </t>
</list>
</t>
<t>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 not only need to correctly
monitor our services and networks as we have done in the IPv4 world, but that we need
it for IPv6 as well. </t>
<t>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. </t>
</section>
<section title="Network Monitoring">
<t>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. </t>
<section title="Transport vs. Data">
<t> It is important to understand the difference between IPv6 Transport vs. IPv6 data. That is
that protocols for monitor network infrastructure such as SNMP or IPFIX can send IPv6 monitored
data (e.g. the count of forwarded packets of an interface) using either IPv4 or IPv6 transport.</t>
<t>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.</t>
</section>
<section title="Simple Network Management Protocol">
<t>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 <xref target="RFC1441">Version 2</xref>. Version 3 is defined in
<xref target="RFC3411"/>.</t>
<t>SNMP MIB was defined in <xref target="RFC1156"/> and extended by
<xref target="RFC1158"/>. Later it was modified by <xref target="RFC1213"/>
in 1990 and in 1996 deprecated by RFCs <xref target="RFC2011"/>, <xref target="RFC2012"/>
and <xref target="RFC2013"/> that separated the MIB in IP, TCP
and UDP. However all these modifications did not considered IPv6 yet. It was until <xref target="RFC2465"/>
and <xref target="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 <xref target="RFC4292"/> (IP-Forwarding) and <xref target="RFC4293"/>
(IP-MIB) defined an unified set of managed objects independent of the IP version. </t>
<t>Today there are many agent and collector implementations that support <xref target="RFC4292"/>
and <xref target="RFC4293"/>. Nevertheless not all of them support them over IPv6 transport
and IPv4 has to be used.</t>
</section>
<section title="Flow Analyzers">
<t>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) <xref target="RFC5101"/> and
<xref target="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.
</t>
<section title="Netflow">
<t>Netflow is a protocol developed by Cisco Systems and version 9 is described in the informational
<xref target="RFC3594"/>. Other vendors have adopted equivalent technology such as Jflow
(Juniper Networks), Cflowd (Alcatel-Lucent) and SFlow (sFlow.org consortium). </t>
<t>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.
</t>
</section>
<section title="Sflow">
<t>Sflow is defined in <xref target="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 <xref target="RFC3176"/> supports IPv4 and IPv6 address families.</t>
</section>
<section title="IPFIX">
<t>IPFIX architecture and message format is defined in <xref target="RFC5101">RFC5101</xref>and
<xref target="RFC5102">RFC5102</xref> 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.
</t>
</section>
<section title="Network/Traffic Analyzers">
<t>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.</t>
<t>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.</t>
</section>
<section title="Command line interface tools">
<t> 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.
</t>
</section>
</section>
</section>
<section title="Application Monitoring">
<t> Beyond the traffic that goes through the network, network operators require to monitor other
services such HTTP servers, email infrastructure, DNS, sensors, etc.</t>
<section title="Services">
<t>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 <xref target="RFC6555">RFC6555</xref> 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.
</t>
<t>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.
</t>
<t>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.</t>
</section>
<section title="FQDN as connection discriminator">
<t>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.
</t>
<t>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. </t>
<t>Bear in mind that using this alternative may introduce an extra overhead related to DNS management
and should be used only when strictly necessary.</t>
</section>
</section>
<section title="IPv6-Only Networks">
<t>The critical path to monitor IPv6 data on dual-stack networks is the device support of the IPv6
only MIBs (<xref target="RFC2465"/>, <xref target="RFC2466"/>,
<xref target="RFC2452"/> and <xref target="RFC2454"/>), the unified MIBs
(<xref target="RFC4293"/>, <xref target="RFC4022"/>,
<xref target="RFC4113"/> and <xref target="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.
</t>
<t>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.</t>
<t>With respect of flow tools, the authors of this document are aware of only a few implementations that
support IPv6 transport.</t>
</section>
<section title="Operational Challenges">
<t>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.</t>
<t>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.
</t>
</section>
<section title="Security Considerations">
<t>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.
</t>
</section>
<section anchor="iana" title="IANA Considerations">
<t>None.</t>
</section>
</middle>
<back>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC1441;
&RFC1158;
&RFC1156;
&RFC1213;
&RFC2011;
&RFC2012;
&RFC2013;
&RFC2452;
&RFC2454;
&RFC2465;
&RFC2466;
&RFC4292;
&RFC4022;
&RFC4113;
&RFC4293;
&RFC3411;
&RFC5101;
&RFC5102;
&RFC3594;
&RFC6555;
&RFC3176;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 12:53:29 |