Testing Teredo
• 27 min read
How well does Teredo perform? This article reports on an exploration of Teredo performance using the 1x1 gif test technique.
Articles
Likes on articles
Geoff Huston AM is the Chief Scientist at APNIC, where he undertakes research on topics associated with Internet infrastructure, IP technologies, and address distribution policies. From 1995 to 2005, Geoff was the Chief Internet Scientist at Telstra, where he provided a leading role in the construction and further development of Telstra's Internet service offerings, both in Australia and as part of Telstra's global operations. Prior to Telstra, Mr Huston worked at the Australian National University, where he led the initial construction of the Internet in Australia in the late 1980s as the Technical Manager of the Australian Academic and Research Network. He has authored a number of books dealing with IP technology, as well as numerous papers and columns. He was a member of the Internet Architecture Board from 1999 until 2005 and served as its Executive Director from 2001 to 2005. He is an active member of the Internet Engineering Task Force, where he currently chairs two Working Groups. He served on the Board of Trustees of the Internet Society from 1992 until 2001 and served a term as Chair of the Board in 1999. He has served on the Board of the Public Internet Registry and also on the Executive Council of APNIC. He chaired the Internet Engineering and Planning Group from 1992 until 2005.
Website: http://www.potaroo.net/
• 27 min read
How well does Teredo perform? This article reports on an exploration of Teredo performance using the 1x1 gif test technique.
• 1 min read
This study, done by Geoff Huston and George Michaelson from the APNIC is looking at the level of background traffic observed in networks 14/8 and 223/8.
• 23 min read
1.0.0.0/8 has been assigned by IANA to APNIC on 19 January 2010, for use for as public unicast space for further address allocations and assignments. Before starting to allocate and assign from this range, APNIC has undertaken a study into 1.0.0.0/8.
There have been some refinements to BBR (see https://datatracker.ietf.org/meeting/102/materials/slides-102-iccrg-an-update-on-bbr-work-at-google-00) that appear to make it a more socially friendly flow control protocol. So if the RedHat release uses BBRv2 then its possible that you will see a protocol that attempts to balance its network pressures with those of loss-based protocols in a fairer manner.
“Hi Geoff, I already seen your presentation in APRICOT 2017 ( slide and youtube ) Can you tell me how to check the most active ipv6 prefixes for the last day,week or month? Thanks in advance,”
Thanks for your question. For IPv4 prefixes: http://bgpupdates.potaroo.net/instability/bgpupd.html For IPv6 it's: http://bgpupdates.potaroo.net/instability/v6-bgpupd.html Thee reports are updated every 24 hours
No, things have not changed tremendously. In fact, not much has changed at all over the past three years from the data set I have, so I'm unsure what data you have used to form that observation. Today, the overall use of Google's PDNS service in the Internet spans some 14% of the total user population. See http://stats.labs.apnic.net/dnssec/XA?c=XA&x=1&g=1&r=1&w=1&q=0 The level of use of this service is highest in Western, Middle and Eastern Africa, Oceania and Southern Africa. The lowest levels of use are found in western and northern Europe, East Asia, and Australia and New Zealand. (see the country table at the URL given above)
Hi Todd, It's always difficult to say what happened from a distance and probably only Dyn (or presumably the attackers) have direct knowledge of what happened and the rest of use can only speculate. It appears to be a pretty safe assumption that Mirai was used, and the source code of Mirai contains a smorgasbord of potential attacks, of which generating DNS queries is just one. So two weeks later it looks like its reasonable to assume that the attack contained a notable DNS component. More to the point, I was wondering if we could use the DNS (and potentially DNSSEC) to protect itself from DNS-based attack incidents and, if so, how we could do so.
Showing 4 comment(s)