idnits 2.17.1 draft-ietf-v6ops-monitor-ds-ipv6-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 14, 2013) is 3901 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 1158 (Obsoleted by RFC 1213) -- Obsolete informational reference (is this intentional?): RFC 2011 (Obsoleted by RFC 4293) -- Obsolete informational reference (is this intentional?): RFC 2012 (Obsoleted by RFC 4022) -- Obsolete informational reference (is this intentional?): RFC 2013 (Obsoleted by RFC 4113) -- Obsolete informational reference (is this intentional?): RFC 2452 (Obsoleted by RFC 4022, RFC 8096) -- Obsolete informational reference (is this intentional?): RFC 2454 (Obsoleted by RFC 4113, RFC 8096) -- Obsolete informational reference (is this intentional?): RFC 2465 (Obsoleted by RFC 4293, RFC 8096) -- Obsolete informational reference (is this intentional?): RFC 2466 (Obsoleted by RFC 4293, RFC 8096) -- Obsolete informational reference (is this intentional?): RFC 5101 (Obsoleted by RFC 7011) -- Obsolete informational reference (is this intentional?): RFC 5102 (Obsoleted by RFC 7012) -- Obsolete informational reference (is this intentional?): RFC 6555 (Obsoleted by RFC 8305) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops A. Servin 3 Internet-Draft LACNIC 4 Intended status: Informational M. Rocha 5 Expires: February 15, 2014 Redes de Interconexion 6 Universitaria Asoc. Civil (ARIU) 7 August 14, 2013 9 Monitoring Dual Stack/IPv6-only Networks and Services 10 draft-ietf-v6ops-monitor-ds-ipv6-00 12 Abstract 14 This document describes a set of recommendations and guidelines to 15 help operators to monitor dual stack and IPv6-only networks. The 16 document describes how to monitor these networks using SNMP, Flow 17 Analyzers and other means. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 15, 2014. 36 Copyright Notice 38 Copyright (c) 2013 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Network Monitoring . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Transport vs. Data . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Simple Network Management Protocol . . . . . . . . . . . . 4 57 2.3. Flow Analyzers . . . . . . . . . . . . . . . . . . . . . . 4 58 2.3.1. Netflow . . . . . . . . . . . . . . . . . . . . . . . 4 59 2.3.2. Sflow . . . . . . . . . . . . . . . . . . . . . . . . 5 60 2.3.3. IPFIX . . . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3.4. Network/Traffic Analyzers . . . . . . . . . . . . . . 5 62 2.4. Command line interface tools . . . . . . . . . . . . . . . 5 63 2.5. Software Defined Networks . . . . . . . . . . . . . . . . 5 64 3. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 4. Application Monitoring . . . . . . . . . . . . . . . . . . . . 6 66 4.1. Services . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 4.2. FQDN as connection discriminator . . . . . . . . . . . . . 6 68 5. IPv6-Only Networks . . . . . . . . . . . . . . . . . . . . . . 7 69 6. Operational Challenges . . . . . . . . . . . . . . . . . . . . 7 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 73 10. Informative References . . . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 76 1. Introduction 78 Network and services monitoring become more important as we rely more 79 on them for our critical operations. Depending of the complexity of 80 our monitor solution we would be able to have more control and 81 information from our network and services. Among other things, a 82 good monitor solution allows to:: 84 o Detect and avoid network incidents 86 o Determine which actions may solve a network incident 88 o Execute recovery and contingency plans 90 All these make sense when we monitor our network responsibly trying 91 to cover all the variables. In the context of this memo, it means 92 that we should monitor our services and networks running IPv6 as we 93 have/had done in the IPv4 world.. 95 There are many documents and guides explaining how to deploy IPv6 96 networks and services but there are so few that describe in detail 97 how to monitor them. This document tries to encompass a set of 98 recommendations and guidelines to help network and system 99 administrators to monitor dual-stack/IPv6-only network and services. 101 2. Network Monitoring 103 In this section we describe SNMP and IPFIX as protocols able to 104 manage IP devices and to monitor a variety of data from dual stack 105 and IPv6-only networks. We also discuss traffic analyzers as other 106 tools to monitor IP networks. 108 2.1. Transport vs. Data 110 It is important to understand the difference between IPv6 Transport 111 vs. IPv6 data. In other words, protocols for monitor network 112 infrastructure such as SNMP or IPFIX can send IPv6 collected data 113 (e.g. the count of forwarded packets of an interface, flow 114 information) using either IPv4 or IPv6 transport. 116 It is important to note that some node implementations would only 117 send data (either IPv4 or IPv6) over IPv4 networks. Nevertheless 118 these are implementation limitations not related to the monitoring 119 protocol. 121 2.2. Simple Network Management Protocol 123 Simple Network Management Protocol (SNMP) defines the protocol suite 124 to monitor and manage IP networks. SNMP works over UDP that allows 125 it to work over IPv4 or IPv6 networks. However, the definitions that 126 allow SNMP to collect data from IP devices know as "Management 127 Information Base" (MIB) had to be modified from the original 128 specifications. The most used versions of SNMP are Version 1 and 129 Version 2 [RFC1441]. Version 3 is defined in [RFC3411]. 131 SNMP MIB was defined in [RFC1156] and extended by [RFC1158]. Later 132 it was modified by [RFC1213] in 1990 and in 1996 deprecated by RFCs 133 [RFC2011], [RFC2012] and [RFC2013] that separated the MIB in IP, TCP 134 and UDP. However all these modifications did not considered IPv6 135 yet. It was until [RFC2465] and [RFC2466] that MIB definitions were 136 specified for IPv6 and ICMPv6. These RFCs described a dissociated 137 definition for IPv4 and IPv6. The last MIB definitions came in 2006 138 when [RFC4292] (IP-Forwarding) and [RFC4293] (IP-MIB) defined an 139 unified set of managed objects independent of the IP version. 141 Today there are many agent and collector implementations that support 142 [RFC4292] and [RFC4293]. Nevertheless not all of them support them 143 over IPv6 transport and IPv4 has to be used. 145 2.3. Flow Analyzers 147 Knowing the packet count that goes in and out from an interface it is 148 very important but many times is not enough to detect faults or to 149 get more detailed traffic information about the network. Netflow and 150 IP Flow Information Export (IPFIX) [RFC5101] and [RFC5102] are 151 protocols that monitor the IP flows passing through network devices. 152 An IP flow is a sequence of packets identified by a common set of 153 attributes such as IP Source Address, IP Destination Address, Source 154 Port, Destination Port, Layer 3 protocol type, Class of service, etc. 156 2.3.1. Netflow 158 Netflow is a protocol developed by Cisco Systems and version 9 is 159 described in the informational [RFC3594]. Other vendors have adopted 160 equivalent technology such as Jflow (Juniper Networks), Cflowd 161 (Alcatel-Lucent) and SFlow (sFlow.org consortium). 163 Netflow defines nine versions from which version 5 is the most common 164 and only versions 9 and 10 support IPv6. Versions 9 and 10 are 165 commonly known as the base of IPFIX. Although Netflow version 9 166 supports the collection of IPv6 flows, not all implementations of 167 agents and collectors support IPv6 transport and IPv4 has to be used. 169 2.3.2. Sflow 171 Sflow is defined in [RFC3176] and it is very similar to netflow and 172 IPFIX. It differs basically in the method to collect flow 173 information. In the case of Sflow, it uses statistical packet-based 174 sampling of switched flows and time-based sampling. The Sflow 175 version described in [RFC3176] supports IPv4 and IPv6 address 176 families. 178 2.3.3. IPFIX 180 IPFIX architecture and message format is defined in RFC5101 181 [RFC5101]and RFC5102 [RFC5102] defines its information model. From 182 the operational standpoint of this document IPFIX and Netflow v9 are 183 not very different and there is not much more to say besides that 184 IPFIX as a relatively new protocol has not been widely implemented. 185 For this reason finding an implementation supporting IPv6 transport 186 may be hard to find. 188 2.3.4. Network/Traffic Analyzers 190 Besides SNMP and Flow analyzers IPv6 can be monitored using a variety 191 of network/traffic analyzers. These devices come in a variety of 192 flavors and some are open source or free and can be installed in 193 commodity hardware, some other are expensive and run on specialized 194 equipment. Commonly they are installed using promiscuous port that 195 mirror all the network traffic or they are installed somewhere in the 196 network where they can inspect most of the traffic. 198 Network/traffic analyzers are a quick way to inspect IPv6 traffic, 199 however they may have scalability and privacy issues which make them 200 unsuitable for large networks. 202 2.4. Command line interface tools 204 When SNMP and flow tools are not available in the network device and 205 traffic analyzers are not suitable as a long term solution it may be 206 possible to use in-house development or other tools to access 207 networks devices and parse command line instructions that monitor 208 IPv6 traffic. This solution could be used as well in IPv6 only 209 networks when the device implementation does not support IPv6 transit 210 to deliver monitoring data. 212 2.5. Software Defined Networks 214 TBD, In this section we will discuss the use of Software Defined 215 Network (SDN) for the purposes of gathering data from the network. 217 3. Addressing 219 TBD. In this section we will discuss the implications to use of 220 link-local, ULAs and Global Unicast Addresses for the purpose of 221 monitor network infrastructure. 223 4. Application Monitoring 225 Beyond the traffic that goes through the network, network operators 226 require to monitor other services such HTTP servers, email 227 infrastructure, DNS, sensors, etc. 229 4.1. Services 231 Besides network information, network operators require to know other 232 variables that could affect the good operation of the network. Dual 233 stack networks pose an important challenge to network and system 234 administrators. In principle we are talking about two different 235 networks that may have different paths and users may perceive a 236 difference in quality. Furthermore, thanks to Happy Eye Balls 237 RFC6555 [RFC6555] that improves the user experience, service 238 operators may have no idea to which protocol users are connected. 239 This impose the need to monitor two networks and two set of services 240 such as HTTP servers, email infrastructure, DNS, etc. to guarantee 241 the service expectations from users. 243 In order to monitor service uptime and performance, it is common to 244 use service probes that frequently poll a specific service to verify 245 its reachability. Most of the time this probes are configured to 246 access a service using a Fully Qualified Domain Name (FQDN) but 247 sometimes literals are used as well. 249 To monitor services using FQDNs with A and AAAA records network/ 250 system administrator must be aware that they do not have a guarantee 251 that the probe is using IPv4 or IPv6 transport unless is forced to do 252 so. Some tools provide configuration or execution flags to force the 253 use of IPv4 or IPv6 transport. To guarantee a reliable monitoring 254 strategy, we recommend using those flags to set up two monitor 255 instances, one for each address family. Needless to say that in case 256 of using literals instead of FQDNs, a new service monitor instance 257 using an IPv6 address must be added. 259 4.2. FQDN as connection discriminator 261 We mentioned that one possible solution to discriminate between IPv4 262 and IPv6 services is to use some of the flags provided by the 263 monitoring tool to force a connection either in IPv4 or IPv6. 265 Depending of the tool used, this option may not be always available. 266 To address this restriction it is possible to use a special FQDN with 267 only an A record to force an IPv4 connection and a different FQDN 268 with only an AAAA record for IPv6. 270 For example suppose that the main organization website has the name 271 www.example.com. The name www.example.com would have A and AAAA 272 records as normally, however it would also contain an A record of the 273 form www.v4-test.example.com pointing to its IPv4 address and an AAAA 274 record www.v6-test.example.com point to the IPv6 address of the 275 service. Other variants may be www.v6.example.com, www- 276 v4.example.com, etc. As these FQDNs are meant to be only internally 277 the selection of which to use is left to the network operator. 279 Bear in mind that using this alternative may introduce an extra 280 overhead related to DNS management and should be used only when 281 strictly necessary. 283 5. IPv6-Only Networks 285 The critical path to monitor IPv6 data on dual-stack networks is the 286 device support of the IPv6 only MIBs ([RFC2465], [RFC2466], [RFC2452] 287 and [RFC2454]), the unified MIBs ([RFC4293], [RFC4022], [RFC4113] and 288 [RFC4292] or flow tools as Netflow 9 or IPFIX. As long as these 289 protocols are supported, the device can be monitor using IPv4 or IPv6 290 transport. However, in IPv6-only networks supporting IPv6 data 291 monitoring is not enough. In order to work it is critical for the 292 device or collector to support the delivery or polling data using 293 IPv6 transport. 295 For SNMP data there are a variety of agents and collectors that 296 support IPv6 MIBs (IPv6 and Protocol Independent) using IPv6 297 transport. Nevertheless still exist devices that do not support 298 neither IPv6 MIBs nor IPv6 transport of monitoring data. 300 With respect of flow tools, the authors of this document are aware of 301 only a few implementations that support IPv6 transport. 303 6. Operational Challenges 305 Even though the end of IPv4 is near, there are still many network 306 devices that cannot provide any type of IPv6 monitor data. In other 307 cases the device can provide some sort of data through command line 308 interfaces or in the best scenario through out the old IPv6 MIBs and 309 using only IPv4 transit for delivery. 311 Still many network devices do not support to collect or send data 312 related to IPv6. Also, some implementations are not widely tested 313 and they may not support IPv6 monitoring correctly. For example, 314 there were in the past cases where network devices did not correctly 315 reported data collected from interface counters as they only counted 316 packets that were process switched. Eventually this bug was fixed to 317 include hardware-processed packets. It will still possible to find 318 more of these types of bugs whilst IPv6 support mature. For that 319 reason we recommend to network operators to always double check the 320 IPv6 data retrieved from SNMP agents and interface counters at least 321 for a short period of time. As the IPv6 support moves forward and 322 matures, this practice would be less important in the future. 324 7. Security Considerations 326 From the security stand point, monitoring IPv4, IPv6 or Dual Stack 327 networks is no different and the same preventions have to be taken. 328 In order to protect SNMP agents, Network Monitoring Systems (NMS), 329 flow collectors, network analyzers, etc. operators are advised to use 330 a variety of methods such as access list, separate networks for 331 management and monitoring, avoid the use of clear text access, etc. 333 8. IANA Considerations 335 None. 337 9. Acknowledgements 339 We would like to thank Humberto Galiza, Alejandro Acosta, Sofia 340 Silva, Diego Lopez, Ariel Weher, and Christian O'Flaherty for their 341 questions, suggestions, reviews and comments. Also we would like to 342 thank the LACNOG community for the informal comments that gave us 343 during the meetings. 345 10. Informative References 347 [RFC1156] McCloghrie, K. and M. Rose, "Management Information Base 348 for network management of TCP/IP-based internets", 349 RFC 1156, May 1990. 351 [RFC1158] Rose, M., "Management Information Base for network 352 management of TCP/IP-based internets: MIB-II", RFC 1158, 353 May 1990. 355 [RFC1213] McCloghrie, K. and M. Rose, "Management Information Base 356 for Network Management of TCP/IP-based internets:MIB-II", 357 STD 17, RFC 1213, March 1991. 359 [RFC1441] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 360 "Introduction to version 2 of the Internet-standard 361 Network Management Framework", RFC 1441, April 1993. 363 [RFC2011] McCloghrie, K., "SNMPv2 Management Information Base for 364 the Internet Protocol using SMIv2", RFC 2011, 365 November 1996. 367 [RFC2012] McCloghrie, K., "SNMPv2 Management Information Base for 368 the Transmission Control Protocol using SMIv2", RFC 2012, 369 November 1996. 371 [RFC2013] McCloghrie, K., "SNMPv2 Management Information Base for 372 the User Datagram Protocol using SMIv2", RFC 2013, 373 November 1996. 375 [RFC2452] Daniele, M., "IP Version 6 Management Information Base for 376 the Transmission Control Protocol", RFC 2452, 377 December 1998. 379 [RFC2454] Daniele, M., "IP Version 6 Management Information Base for 380 the User Datagram Protocol", RFC 2454, December 1998. 382 [RFC2465] Haskin, D. and S. Onishi, "Management Information Base for 383 IP Version 6: Textual Conventions and General Group", 384 RFC 2465, December 1998. 386 [RFC2466] Haskin, D. and S. Onishi, "Management Information Base for 387 IP Version 6: ICMPv6 Group", RFC 2466, December 1998. 389 [RFC3176] Phaal, P., Panchen, S., and N. McKee, "InMon Corporation's 390 sFlow: A Method for Monitoring Traffic in Switched and 391 Routed Networks", RFC 3176, September 2001. 393 [RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An 394 Architecture for Describing Simple Network Management 395 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 396 December 2002. 398 [RFC3594] Duffy, P., "PacketCable Security Ticket Control Sub-Option 399 for the DHCP CableLabs Client Configuration (CCC) Option", 400 RFC 3594, September 2003. 402 [RFC4022] Raghunarayan, R., "Management Information Base for the 403 Transmission Control Protocol (TCP)", RFC 4022, 404 March 2005. 406 [RFC4113] Fenner, B. and J. Flick, "Management Information Base for 407 the User Datagram Protocol (UDP)", RFC 4113, June 2005. 409 [RFC4292] Haberman, B., "IP Forwarding Table MIB", RFC 4292, 410 April 2006. 412 [RFC4293] Routhier, S., "Management Information Base for the 413 Internet Protocol (IP)", RFC 4293, April 2006. 415 [RFC5101] Claise, B., "Specification of the IP Flow Information 416 Export (IPFIX) Protocol for the Exchange of IP Traffic 417 Flow Information", RFC 5101, January 2008. 419 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 420 Meyer, "Information Model for IP Flow Information Export", 421 RFC 5102, January 2008. 423 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 424 Dual-Stack Hosts", RFC 6555, April 2012. 426 Authors' Addresses 428 Arturo Servin 429 LACNIC 430 Rambla Republica de Mexico 6125 431 Montevideo 11300 432 Uruguay 434 Phone: +598 2604 2222 435 Email: aservin@lacnic.net 437 Mariela Rocha 438 Redes de Interconexion Universitaria Asoc. Civil (ARIU) 439 Maipu 645 - 4to Piso 440 Buenos Aires 441 Argentina 443 Email: mrocha@riu.edu.ar