Lessons fro IPv6 day, 2011
•Download as KEY, PDF•
0 likes•742 views
IPv6 day in 2011 was a global trial of the new Internet Protocol IPv6. Major websites participated to demonstrate preparedness for increased Internet growth. The University of Cambridge participated and found that IPv6 requests were low level at around 1-3% for most services. Tunnels like 6to4 caused some issues as they allowed addresses not on the local network. The event concluded that IPv6 day was essentially a non-event, and therefore a success, demonstrating readiness for the full transition.
More Related Content
Viewers also liked
Viewers also liked (13)
Similar to Lessons fro IPv6 day, 2011
Similar to Lessons fro IPv6 day, 2011 (20)
Recently uploaded
Recently uploaded (20)
Lessons fro IPv6 day, 2011
- 1. Lessons from IPv6 day, 2011 Jon Warbrick University of Cambridge Computing Service jw35@cam.ac.uk / @jw35
- 5. Objective “ On 8 June, 2011, top websites and Internet service providers around the world joined together for a successful global-scale trial of the new Internet Protocol, IPv6. By providing a coordinated 24-hour “test flight”, the event helped demonstrate that major websites around the world are well-positioned for the move to a global IPv6-enabled Internet, enabling its continued exponential growth. ” http://www.worldipv6day.org/
- 6. Participants ...and at least 1,000 more
- 8. Auto-configuration • You may have an address without knowing it! • The router you got it from may not work • If it’s not registered, it’s not in cam.ac.uk or ox.ac.uk • Auto-config not suitable for servers
- 9. v4 service != v6 service • Separate name address mapping • Application layer - e.g.Virtual hosting • May not respond
- 10. Packet filters and firewalls
- 13. Log Analysis “2001:630:212:8::d:a0” does not match /d{1,3}.d{1,3}.d{1,3}.d{1,3}/
- 15. Fragmentation and ICMP6 The magic number is 1280
- 16. Old (and not-so-old) software
- 17. So, the plan... • E-mail (*.hermes.cam.ac.uk, mx.cam.ac.uk) • Web servers (www.cam.ac.uk, [web-]search.cam.ac.uk, Raven (authentication)) • The Streaming Media Service • The DNS servers • Training booking
- 18. So, the plan... • E-mail (*.hermes.cam.ac.uk, mx.cam.ac.uk) • Web servers (www.cam.ac.uk, [web-]search.cam.ac.uk, Raven (authentication)) • The Streaming Media Service • The DNS servers • Training booking
- 19. On the day... Internal access to external resources
- 20. On the day... Access to internal resources
- 21. IPv6 proportions www.cam 1.5% requests 0.55% logins Hermes Webmail 0.46% requests Hermes IMAP 0.15% logins Hermes POP 0.04% logins Hermes SMTP 0.25% messages PP Switch 3.1% messages mx.cam 1.0% messages
- 22. www.cam: top 10 countries 2619 UCS STAFF 1373 China 1290 Brazil 835 JANET 630 UNIVERSITY 420 United Kingdom 293 United States 171 Greece 123 France 110 Czech Republic 8,351 requests total, from 230 clients, 28 countries
- 23. The trouble with tunnels • www.cam: 50 clients, 630 requests over 6to4 • 36 clients from within the University • 20% of smtp.hermes messages
- 24. 131.111.10.33 6to4 IPv4 2002:836f:a21:: 192:88:99.1 IPv6 IPv6 packets inside IPv4 Router for 2002::/16
- 25. Tunnel issues • 6to4 hosts can advertise themselves as routers • 6to4 only works for machines with public addresses • Teredo supports privately addressed machines using 2001:0::/32 • Both mean that machines on your network can have addresses not on your network!
- 26. The bottom line: • IPv6 day was an almost complete non-event
- 27. The bottom line: • IPv6 day was an almost complete non-event • And so a success
- 28. The bottom line: • IPv6 day was an almost complete non-event • And so a success • And so, almost exactly a year later ...
- 29. 6th June 2012
- 32. That’s it If you have been, thanks for listening
Editor's Notes
- This talk covers some of the things we leant as a result of participating in World IPv6 Day on 8th June 2011. It’s presented from a server administrator’s point of view and, while it mentions assorted network-level issues, it doesn’t go into particular detail. In particular it’s not a guide to setting up an IPv6-capable network, nor a primer on what IPv6 is.\n
- We are probably all used to IPv4. Been around for ages. Critically uses 32 bits to represent addresses, normally written as four dot-separated octets, each expressed in decimal. Trouble is, the world is running out of IPv4 addresses (all the ‘spare’ has now been allocated for use, though there are still lots of addresses not actually being used). IPv4 is only surviving thanks to extensive use of RFC1918 ‘private’ addresses, though their properties mean that ever increasingly complicated workarounds are needed to support their continued use.\n
- IPv6, on the other hand, uses 128 bits to represent addresses (and note that doesn’t mean that the address space is only four times bigger...), normally written in hexadecimal as multiple 16-bit blocks separated by ‘:’ and with rules allowing runs of zeroes to be omitted. \n\nThe two protocols have quite a few other differences, some of which we’ll come on to, but the longer addresses are the ones you see first. But note lesson number 1: trying to use IPv6 as if it was just ‘IPv4 with longer addresses’ is doomed to failure.\n\n
- So, what was IPv6 day all about?\n
- Here’s what the Internet Society (who suggested and promoted the idea) had to say on the subject.\n
- Here are some of the big players who started it off by promising to take part. Most of these already made their services available over IPv6, though not by default. In the end, at least 1,000 other providers, including the University of Cambridge, also joined in.\n\n
- We gave this some thought in advance, and identified a number of things that we’d need to worry about...\n
- IPv4 (at least in Cambridge where DHCP - especially dynamic DHCP - has always been considered a bit iffy) needs manual configuration: address, netmask, router, etc. \n\nv6, on the other hand, will by default try to configure itself. Connect any modern OS to many IPv6-capable networks and the machine will acquire a globally-routable address. Common schemes are EUI-64 and ‘privacy addresses’ (RFC 4941).\n\nThis difference can lead to some surprises.\n
- The DNS handles name<->IPv4 mapping separately to name<->IPv6 mapping So there&#x2019;s no guarantee that you&#x2019;ll hit the same server, never mind the same service, over v6 as over v4. Setting things up like this may lead to madness, but can sometimes be useful. \n\nIPv6 config may be needed at an application level - for example Apache needs to know what IP addresses it&#x2019;s doing name-based virtual hosting on and so will need to know about v6 addresses as well as v4 ones.\n\nIf an advertised v6 address isn&#x2019;t responding (perhaps because the v6 interface is down) but the corresponding v4 interface is responding then clients will tend to try v6 and only fall back to v4 after a timeout. The symptoms can look VERY like server or network overload!\n
- Packet filters and firewalls will need new configuration for v6 - default will probably be to block everything or allow everything, neither of which will probably be what you want.\n
- It&#x2019;s tempting to consider a machine with a RFC 1918 private IPv4 address behind a NAT service to be more secure that a publicly addressed one, because it can&#x2019;t be poked directly from the outside. Private v6 addresses do exist (&#x2018;Unique Local Addresses&#x2019; (ULAs)), but they are not widely deployed because they are typically a solution to an address shortage and we are not short of v6 addresses. \n\nSo, stick a v4 privately-addressed machine on a subnet that also supports v6 and it will probably be out there exposed on the public Internet with a global address. This may come as a surprise. \n
- It&#x2019;s common to setup inter-host communications (e.g. web server to database) to use the localhost interface and to limit connections to this to prevent external meddling. But if you enable v6 on such a machine then internal connection may happen via the v6 local interface on ::1 and not the v4 one on 127.0.0.1. If your rules don&#x2019;t take this into account you may find that you can&#x2019;t talk to yourself.\n
- Rather a lot of log analysis software may be assuming that IP addresses in logs will look like 131.111.10.33, and may be &#x2018;surprised&#x2019; to find ones that look like 2001:630:212:8080::80:0. How they react will vary, but ignoring such entries (perhaps silently), or stoping dead on the first one are both possibilities.\n
- ...and once we got into actually doing the necessary configuration we found some others:\n
- If an IPv6 router finds it has a packet that&#x2019;s too big to send over a particular link it drops the packet and sends a &#x2018;Packet too big&#x2019; ICMP6 message to the packet&#x2019;s origin, which is expected to resend it smaller. If anyone foolishly blocks those ICMP6 messages then this won&#x2019;t work, and you&#x2019;ll find that you can successfully send small packets but not full size ones. In a web context, this can mean that clients can open connections and successfully send requests, but can&#x2019;t receive responses (which are typically much bigger). IPv6 requires that all links carry at least 1280 byte packets (c.f. 1500 byte packets typically used on Ethernet) and there is some evidence that the big providers are artificially limiting themselves to 1280 bytes, presumably to avoid this problem.\n\n[IPv4 also has fragmentation, but it handled on a per-link basis, rather than end-to-end. It too can cause problems, but these are now largely understood and normally avoided, and in any case not often seen by clients]\n\nAuto-configuration (mentioned above) also relies on ICMP6 so if you block that you may loose all your addresses too!\n
- Even though it&#x2019;s been around for a while, IPv6 is still changing quite rapidly, and even &#x2018;current&#x2019; software may not be keeping up. For example all but the most recent point release of the version of MacOS current on IPv6 Day had a bug that was likely to affect some users. SuSE Linux Enterprise 10 (old, but still in support) has some failings in its v6 support that caused us problems.\n
- The core of the CUDN already supports IPv6, as does JANET, but only a few University edge networks have enabled it (UCS, Astronomy, Computer Lab, SRCF, ...). \n\nThe plan was to enable IPv6 on all these services for Pv6 day...\n
- ...but inevitably some fell by the wayside. We did manage the rest.\n
- No known problems experienced by any University clients accessing v6-enabled services.\n
- A small but significant number of people accessed our v6 enabled services, apparently successfully. \n
- OK, not exactly big numbers. Services mainly offered to internal clients likely to be low because of the small number of internal clients with IPv6 connectivity. For services also accessed from outside (www.cam, mx.cam) ~1% of accesses were over v6.\n
- China/Brazil probably high because the developing world has disproportionately fewer IPv4 addresses then US/Europe, etc., because by the time they wanted them the shortage was already becoming apparent and allocation rules were tightened. Such countries are likely to already be deploying v6 to cope with this.\n
- Because of the disconnect between IPv4 and IPv6, various people have created systems what will, automatically or with manual configuration, allow v4 and v6 hosts to communicate or allow a pair of v6 hosts that don&#x2019;t have v6 connectivity between them to communicate. &#x2018;6to4&#x2019; is one such, and a common bug is that machines will sometimes chose an IPv6 connection via one of these &#x2018;transitional technologies&#x2019; in favor of a &#x2018;real&#x2019; IPv4 connection. For example lots of clients in the University contacted www.cam and smtp.hermes over 6to4 even though all those clients will have had viable IPv4 routes to the same servers. \n\nThis causes some problems.\n
- 6to4 is really clever, and here&#x2019;s a diagram of how it works. You might want to look at the Wikipedia description for more detail: http://en.wikipedia.org/wiki/6to4 \n\nThe critical points are that a 6to4 host ends up with an entirely usable IPv6 address in the 6to4 range 2002::/16, and if it wishes can offer to route other address in that range on behalf of other clients on the same subnet (thus bringing IPv6 support to a network that wouldn&#x2019;t otherwise have it). But all this depends on connections that are probably crossing the institution boundary and which are probably being offered on a &#x2018;best efforts&#x2019; basis at best.\n
- So now you have machines on your network that are using IPv6 addresses from a range that you don&#x2019;t expect. Any access control by IP address is likely to be messed up by this. Worse, since 6to4 machines can advertise themselves as IPv6 routers to other machines, the existence of a machine doing this can easily affect other machines on the same subnet.\n\nWe saw this effect on IPv6 Day. Part way through the day a department mail server suddenly started using a 6to4 connection being offered by a workstation on the same network. Unfortunately it was forwarding mail to the central mail switch which refused to accept it because it wasn&#x2019;t (apparently) coming from a machine in the University. Fortunately this was easily fixed, and didn&#x2019;t result in a loss of mail, but does suggest that a significant barrier to wider Pv6 deployment may turn out to be these very &#x2018;transitional&#x2019; technologies that were designed to make it easier.\n
- \n
- \n
- \n
- IPv6 launch day. Much like in 2011, lots of big players turned on IPv6 on their services. Unlike in 2011, they didn&#x2019;t turn it off.\n
- Here&#x2019;s ww.google.com advertising a v6 address. At least back in work on my v6-enabled desktop, this is how I now connect to Google.\n\n
- My plan is to enable dual-stack V4/v6 on new services from day one, and probably to add v6 on exiting services as and when they get replaced or significantly changed.\n
- \n