Some discussion starters from APRICOT 37
Hi all, I recently had the pleasure of attending APRICOT 37 (many thanks to the NZNOG and InternetNZ folks, and others, who made this possible!) and felt that there were some interesting topics discussed that may be worth bringing back to the NZNOG community. Here's an unsorted and terse list of some things I thought worthwhile: -> We need to stop looking at Alexa's "top 100" websites for IPv6 support and being disappointed - we need to be looking at a much smaller proportion of the "top sites" as this is where "all of the traffic" is actually going. Facebook, YouTube, Google, Wikipedia, Akamai and GGC cache nodes. It's a port 80 world and a few sites dominate :) -> Some big providers (T-Mobile, Telstra AU) talked about having rolled out IPv6 in various forms (single stack v6, dual stack with CGNAT on v4 and native v6) to their mobile subscriber base with approximately no support impact. A common theme: "We need to test IPv6 before deploying it!" "What testing did you do with IPv4?" "None" "Well do that with IPv6 too!" -> Paraphrasing: "Customers don't know what IPv4 is to begin with, so they sure don't know or care what IPv6 is." -> These operators reported seeing /40%/ of the traffic on any given subscriber where dual stack was available going straight out to the native v6 Internet! This is a huge win if you're looking at deploying CGNAT as it means approximately half as much state needs to be kept on your expensive CGNAT boxes, and half as much traffic is being molested on the way from the customer to the 'net :) It also means you should definitely be rolling out dual stack alongside your CGNAT :) -> 464XLAT (http://tools.ietf.org/html/rfc6877) looks like it's about to be a big deal in the mobile IPv6 space. In short, 464XLAT allows for phones to run single stack native IPv6 while applications on the phone can continue to access v4 literals etc if required. Makes use of a clever combination of existing technologies. Only Android 4.3+ supports this so far, but more phone support shouldn't be far away. To me this looks like it would be a killer feature to have on fixed line CPEs, though I am unclear how it would interact with the type of NAT these CPEs typically perform (though this ought not be too far away from a tethering scenario on a phone). -> Geoff Huston's closing presentation on the state of BGP in 2013 contained some interesting measurements and insights about how worried we should be able router performance and so on. The video (https://www.youtube.com/watch?feature=player_detailpage&v=e4N9ELoM76M#t=1798) and slides (https://conference.apnic.net/data/37/2014-02-27-bgp2013_1392943641.pdf) are worth a look if you have ~ 20 minutes. Since the NZNOG list has been more alive of late, I'd welcome discussion on any of these points as certainly there is plenty here that is relevant to NZ :) -- Michael Fincham System Administrator, Unleash Office: 0800 750 250
On Mon, 10 Mar 2014 15:02:35 +1300, Michael Fincham wrote:
-> These operators reported seeing /40%/ of the traffic on any given subscriber where dual stack was available going straight out to the native v6 Internet!
Further confirmation of this: Over the last 12 weeks, about 30% of the traffic on my home LAN has been native IPv6 :) -- Michael
On Sun, Mar 9, 2014 at 7:02 PM, Michael Fincham
-> We need to stop looking at Alexa's "top 100" websites for IPv6 support and being disappointed - we need to be looking at a much smaller proportion of the "top sites" as this is where "all of the traffic" is actually going. Facebook, YouTube, Google, Wikipedia, Akamai and GGC cache nodes. It's a port 80 world and a few sites dominate :
For some stats I presented recently: 29% of alexa top 100 websites have IPv6 13.8% of alexa top 1000 websites have IPv6 5.6% of alexa top 10,000 websites have IPv6 5.6% of alexa top 1,000,000 websites have IPv6 Top 10 Alexa sites = 60% with IPv6. With sites number 2,3 and 91 (facebook, youtube, netflix; in north america anyway) accounting for around 60% of network traffic - this is which higher IPv6 stats can be seen :)
participants (2)
-
Michael Fincham
-
Tom Paseka