idnits 2.17.1 draft-vyncke-vdv-v6ops-conf-stats-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([Google], [Cisco], [Tata]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2009) is 5521 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops Working Group E. Vyncke 3 Internet-Draft G. Van de Velde 4 Intended status: Informational Cisco Systems 5 Expires: September 9, 2009 March 8, 2009 7 IPv6 Deployment and Statistics at a Conference 8 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. This document may contain material 14 from IETF Documents or IETF Contributions published or made publicly 15 available before November 10, 2008. The person(s) controlling the 16 copyright in some of this material may not have granted the IETF 17 Trust the right to allow modifications of such material outside the 18 IETF Standards Process. Without obtaining an adequate license from 19 the person(s) controlling the copyright in such materials, this 20 document may not be modified outside the IETF Standards Process, and 21 derivative works of it may not be created outside the IETF Standards 22 Process, except to format it for publication as an RFC or to 23 translate it into languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on September 9, 2009. 43 Copyright Notice 45 Copyright (c) 2009 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents in effect on the date of 50 publication of this document (http://trustee.ietf.org/license-info). 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. 54 Abstract 56 During the Cisco [Cisco] European networkers Conference 2009 that ran 57 from 26th to 29th January in Barcelona native IPv6 was added to the 58 traditional IPv4 infrastructure. During this conference the 3500 59 attendees had dual stack access to both IPv4 and IPv6 simultaneously. 60 The goal of this IPv6 deployment project was to gather usage 61 statistics in a situation where the end-user just wants to access 62 his/her enterprise VPN or simply get onto the Internet. The 63 collected statistics are not only useful per se but this document 64 presents easy ways to measure the quality of the IPv6 connectivity 65 offered on such events. In essence the users were not conducting 66 IPv6 technology tests, but were just using Internet services. The 67 statistics collected give some pieces of information on the size and 68 impact of IPv6 onto the normal userbase and will also derive the 69 importance of IPv6 onto the infrastructiure and end-user operating 70 systems and firewall technologies. The experiment ran in 71 collaboration with Google [Google] and Tata-Communications [Tata]. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 76 2. Conference Topology Summary . . . . . . . . . . . . . . . . . . 4 77 3. Testing Steps and Procedure . . . . . . . . . . . . . . . . . . 5 78 4. Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 4.1. Round-Trip Time . . . . . . . . . . . . . . . . . . . . . . 6 80 4.2. Stats for IPv6 Traffic to the Internet . . . . . . . . . . 6 81 4.3. IPv6 DHCP Clients . . . . . . . . . . . . . . . . . . . . . 6 82 4.4. IPv6 Neighbours . . . . . . . . . . . . . . . . . . . . . . 7 83 4.5. DNS Requests . . . . . . . . . . . . . . . . . . . . . . . 7 84 4.6. Web Server Access . . . . . . . . . . . . . . . . . . . . . 7 85 4.7. Netflow Information . . . . . . . . . . . . . . . . . . . . 7 86 4.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 5. Areas for Improvements . . . . . . . . . . . . . . . . . . . . 8 88 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 90 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 96 1. Introduction 98 Traditionally there is at this conference in Europe about 3500 99 attendees. The nature of the attendees is technical with a heavy 100 focus on networkes and 90% will have a laptop but will not use them 101 all the time (lack of time and lack of electrical power). The main 102 elements the attendees expect from the network infrastructure is that 103 its stable and easy accessible. The attendees use the network 104 Infrastructure to access their enterprise network via a VPN and 105 Internet content (hotels, restaurants, email, etc..). 107 During the conference, about 10% of the users were made aware at the 108 IPv6 session slots that IPv6 connectivity was available in native 109 dual stack, however, the vast majority did not make special efforts 110 to run IPv6 or even enable IPv6 on their end-user PC's. 112 The experiment was run in three steps: (1) Networkers infrastructure 113 was enabled for dual stack, (2) The local DNS server was white-listed 114 by Google as content provider to give AAAA records for Google content 115 and (3) the Router Advertisements were set to ask the users to use 116 DHCPv6 for address configuration (M-flag) instead of IPv6 Stateless 117 Address Autoconfiguration (SLAAC). Each of the steps was run with a 118 lenght of 24 hours. 120 This paper gives a summary insight in the statistics and the topology 121 used for the IPv6 connectivity during each step. It also reports 122 that everything kept working as expected and that the end-users were 123 not aware they were using IPv6 as a foundation communication protocol 124 in addition to IPv4: it was completely transparent for them. 126 2. Conference Topology Summary 128 The Network infrastructure at Cisco European Networkers conference is 129 deployed in a four-storey building. For each floor has a dedicated 130 routed IPv4 subnet available with a dedicated number of RFC 1918 IPv4 131 addresses. These addresses are translated at the edge of the network 132 from private into a public address by a Network Address Translator. 133 The wireless Access Points do also have smart services installed 134 including end-system security (captive portal) and inter-AP roaming 135 capability. 137 For the IPv6 infrastructure, it was selected to create a single 138 Layer-2 domain for the full Networkers conference spanning all 4 139 floors. In contrast, the number of stations per floor is not an 140 issue with an IPv6 /64 subnet. This made the IPv6 deployment more 141 simpler, eventhough it was needed to add some Ethernet protocol type 142 filtering in place at the layer 2 of the OSI layer to separate IPv4 143 from IPv6: on the same topology (4 wireless LAN), there was both a 4 144 IPv4 subnets and a single IPv6 subnet. 146 At the edge of network, an IPv6 router provided IPv6 connectivity 147 through an IPv6-in-IPv4 tunnel to Tata Communication POP in Paris. 148 Note: initially we were planning for a real native dual-stack 149 connectivity over the local loop, but it appeared a too costly option 150 when only a very small incremental budget is available (like almost 0 151 USD incremental cost). It was because of the kind sponsorship of 152 Tata Communications that IPv6 was made available at zero incremental 153 cost involved towards the conference leadership. 155 To gather statistics from the deployment Netflow v9 and SNMP were 156 used as well as regular shell access to network equipments. For the 157 management, an old laptop was used running a Linux distribution. The 158 statistics and traffic data from the event can be found 159 http://www.cisconetworkers6.com/. A graphical representation of the 160 topology can be found at http://www.cisconetworkers6.com/network/. 162 The same Linux laptop run a DNS server and was offering the 163 statistics over HTTP access. All HTTP accesses were logged including 164 the User-Agent header in order to collect statistics about the 165 browser and the operating system. The HTTP 64 aware [HTTP-64AWARE] 166 technique was also used to force stations to bypass the address 167 selection policy and use IPv6. 169 The Following applications were used as supporting infrastructure: 170 (1) MRTG (SNMP poll) [MRTG], (2) NFsen (supporting Netflow v9 with 171 IPv6 support) [NFSen], (3) NDPMON (to monitor ND activities) 172 [NDPMON], (4) RAMOND (to monitor RA activities) [RAMOND], DHCPv6 173 Server (Cisco IOS DHCPv6 Server). 175 3. Testing Steps and Procedure 176 o Monday 26th of January 9:00: the MRTG & Netflow collector are 177 connected to the Network; 178 o Tuesday 27th in the late afternoon, Google applies the DNS-trick 179 and starts serving A & AAAA to all laptops using the local DNS 180 server (only announced over DHCPv6) 181 o Wednesday 28th in the morning, the local DHCPv4 also serves a 182 Google-trick-enabled DNS servers to all DHCPv4 clients, i.e., all 183 laptops actually received the A and AAAA for Google 184 o Wednesday 28th 16:00, Router Advertisements include the M-flag for 185 a few minutes; 186 o Thursday 29th 9:0, RA includes the M-flag all day; 187 o Thursday 29th 14:00, RA prefix is advertised with a calendar 188 lifetime to 16:15; 190 o Thursday 29th 16:15, no more IPv6 traffic (thanks to RA prefix 191 expiration), the router & collector are removed from the site; 193 4. Statistics 195 4.1. Round-Trip Time 197 The RTT was measured with ICMP echo requests & replies to 198 www.google.com and www.6net.org over IPv6. In general the time to 199 google remained constant from the conference (65 msec), while the RTT 200 to 6net was lower 50% until the AAAA to Google was enabled 201 (potentially due to higher IPv6 traffic load?). 203 The RTT to Google was also measured over IPv4 (average 64 msec, peak 204 218 msec) and IPv6 (average 65 msec, peak 72 msec). The use of a 205 6-in-4 tunnel was not really impacting the latency to access Google 206 if we assume that ICMP is a good measurement methodology. 208 4.2. Stats for IPv6 Traffic to the Internet 210 What can be seen in the graphs at 211 http://www.cisconetworkers6.com/mrtg/tunnel.html for the 6-in-4 212 tunnel is that there was a continuous growth in IPv6 traffic. There 213 was many less people on Monday than on the rest of the week due to 214 the conference organization and agenda. 216 Monday the inbound traffic (Internet to the conference) was around 217 100kbps, Tuesday 400kbps, Wednesday 1.5Mbps and Thursday also around 218 1.5 Mbps. 220 Outbound (conference to the Internet) can be seen for the 6-in-4 221 tunnel; there was also ongoing growth in IPv6 traffic. Monday the 222 traffic was low and around 10kbps, Tuesday 50kbps, Wednesday 100kbps 223 and Thursday also around 100kbps. 225 4.3. IPv6 DHCP Clients 227 Details to be found at 228 http://www.cisconetworkers6.com/mrtg/dhcpv6.html. From day 1, the 229 Cisco IOS router was configured as a DHCPv6 IA server. However, only 230 from Wednesday onwards, the M-bit was set in the Router 231 Advertisements. This setting had a very interresting result because 232 it made the number of DHCPv6 assigned addresses grow from 4 to a 233 total 151 systems using DHCPv6 IPv6 address allocation. This is a 234 clear indication that there were only 4 laptops with a IPv6 stack 235 always trying to use statefull DHCPv6 while the vast majority of the 236 laptops were only using RA for SLAAC. It can be assumed that the 237 majority of the laptops were running Microsoft Windows XP or Vista. 239 4.4. IPv6 Neighbours 241 Details regarding the amount of IPv6 neighbors of the router can be 242 found at http://www.cisconetworkers6.com/mrtg/neighbours.html. The 243 neighbors were split in two categories based on the IPv6 address: 244 link-local or global addresses. 246 A couple of interesting observations: 247 o the number of IPv6 neighbors grew on every single day during the 248 conference, with a high peak on Wednesday 28th January. 249 o many systems had IPv6 enabled (555 stations) as seen by the Link- 250 local neighborships, however at maximum 358 were actually using 251 IPv6 to access the Internet. 252 o the number of link-local neighbors was similar on all days (except 253 on Monday because there were less attendees). But, the number of 254 global address neighbors changed dramatically on Wednesday morning 255 when the AAAA for Google was served: it doubled from 180 to 358. 257 4.5. DNS Requests 259 The traffic of DNS requests was also measured: 6 DNS requests/sec 260 over IPv4 and 2 DNS requets/sec over IPv6. This is probably linked 261 to the OS used on the laptops where the majority was probably Windows 262 XP which only use IPv4 for DNS access. 264 4.6. Web Server Access 266 In order to collect operating system information of the attendees, a 267 challenge was announced in order to attract users on a dual-stack web 268 server. Based on the number of attendees and the number of IPv6 269 neighbors, it is clear that the number of visitors (about 100) was 270 only a small parts of the local IPv6 hosts (about 555) or even 271 attendees (about 3,500). 272 o IPv6-enabled visitors: 20 *nix, 20 Microsoft Windows XP, 16 273 Microsoft Windows CE (smart-phones), 16 Apple Mac OS/X, 13 274 Microsoft Windows Vista, 6 Symbian (smart-phones) 275 o IPv4-only visitors: 70 Microsoft Windows XP, 13 Apple Mac OS/X, 9 276 Windows Vista and 25 *nic 278 4.7. Netflow Information 280 Based on Netflow information, some data-points were collected over 281 the 4 days: 282 o The IPv6 protocols: 84% for TCP, 10% for ICMPv6, the rest (7%) for 283 UDP. There were also a very small amount of IPv6 datagrams with 284 59 (No Next Header for IPv6): 73 packets on a total of more than 285 8.7 millions. 286 o The layer-4 ports: 31% for NNTP, 30% for HTTP, 11% for SSH, 5% for 287 HTTPS, 3% for DNS. The rest was not clearly identified. This may 288 not be statiscally significant, but, the HTTP traffic went from 289 22% to 42% as soon as the AAAA for Google was served. 290 o The Internet hosts: 31% for 2001:888::119 (newszilla6.xs4all.nl), 291 7% for 2001:4860:0:1001::68 (Google), 5% for 2001:4860:0:1001::53 292 (Google), 5% for a site in the .NO domain, 5% for a site in the 293 .SE domain, 2% for a site in a .CZ domain (as the addresses seem 294 to relate to a non-public site, the authors preferred to keep 295 those addresses non-public as well). 297 4.8. Security 299 RAMOND and NDPMON detected not a single attack against the Neighbor 300 Discovery Protocol. 302 5. Areas for Improvements 304 A couple of areas for improvement have been identified after the 305 experiment: 306 o Compare the Netflow information for IPv4 and IPv6. 307 o Collect information about all the operating systems (both IPv4 and 308 IPv6), this could be done by sniffing the HTTP traffic and 309 collecting the User-Agent. This measurement will probably require 310 some legal advice in some countries... 312 6. IANA Considerations 314 There are no extra IANA consideration for this document. 316 7. Security Considerations 318 There are no extra Security consideration for this document. 320 8. Acknowledgements 322 Many thanks go to Tata Communications and Yves Poppe for the 323 sponsorship of the IPv6 Connectivity. We would also like to thank 324 Erik Kline and Lorenzo Colitti from Google to have supported the 325 deployment to enable AAAA DNS records for the Networkers Conference. 326 All of this experimenting would not of been possible without the help 327 from Cisco Networkers NOC team under leadership of Andy Phillips. 329 9. References 331 9.1. Normative References 333 9.2. Informative References 335 [Tata] "Tata Communications 336 (http://www.tatacommunications.com/)". 338 [Google] "Google (http://www.google.com/)". 340 [Cisco] "Cisco Systems (http://www.cisco.com)". 342 [MRTG] Oetiker, Tobi., "The Multi Router Traffic Grapher 343 (http://oss.oetiker.ch/mrtg/)". 345 [NFSen] "NfSen - Netflow Sensor (http://nfsen.sourceforge.net/)". 347 [NDPMON] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor 348 (http://ndpmon.sourceforge.net/)". 350 [RAMOND] Morse, James., "RAMOND (http://ramond.sourceforge.net/), 351 University of Southampton". 353 [HTTP-64AWARE] 354 Vyncke, E., "IPv6 Connectivity Check and Redirection by 355 HTTP Servers", 2008, . 358 Authors' Addresses 360 Eric Vyncke 361 Cisco Systems 362 De Kleetlaan 6a 363 Diegem 1831 364 Belgium 366 Phone: +32 2 778 4677 367 Email: evyncke@cisco.com 368 Gunter Van de Velde 369 Cisco Systems 370 De Kleetlaan 6a 371 Diegem 1831 372 Belgium 374 Phone: +32 2704 5473 375 Email: gunter@cisco.com